mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Boqun Feng <boqun.feng@gmail.com>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@arndb.de>,
	akpm@linux-foundation.org, albert@sifive.com,
	yamada.masahiro@socionext.com, mmarek@suse.com,
	will.deacon@arm.com, peterz@infradead.org, mingo@redhat.com,
	daniel.lezcano@linaro.org, tglx@linutronix.de,
	jason@lakedaemon.net, marc.zyngier@arm.com,
	gregkh@linuxfoundation.org, jslaby@suse.com, davem@davemloft.net,
	mchehab@kernel.org, sfr@canb.auug.org.au, fweisbec@gmail.com,
	viro@zeniv.linux.org.uk, mcgrof@kernel.org, dledford@redhat.com,
	bart.vanassche@sandisk.com, sstabellini@kernel.org,
	daniel.vetter@ffwll.ch, mpe@ellerman.id.au, msalter@redhat.com,
	nicolas.dichtel@6wind.com, james.hogan@imgtec.com,
	paul.gortmaker@windriver.com, linux@roeck-us.net,
	heiko.carstens@de.ibm.com, schwidefsky@de.ibm.com,
	linux-kernel@vger.kernel.org, patches@groups.riscv.org
Subject: Re: [PATCH 10/17] RISC-V: Atomic and Locking Code
Date: Wed, 12 Jul 2017 20:40:49 +0800	[thread overview]
Message-ID: <20170712124049.i7taml22aat2bcgt@tardis> (raw)
In-Reply-To: <20170712013130.14792-11-palmer@dabbelt.com>

[-- Attachment #1: Type: text/plain, Size: 7928 bytes --]

On Tue, Jul 11, 2017 at 06:31:23PM -0700, Palmer Dabbelt wrote:
[...]
> diff --git a/arch/riscv/include/asm/bitops.h b/arch/riscv/include/asm/bitops.h
> new file mode 100644
> index 000000000000..b0a0c76e966a
> --- /dev/null
> +++ b/arch/riscv/include/asm/bitops.h
> @@ -0,0 +1,216 @@
> +/*
> + * Copyright (C) 2012 Regents of the University of California
> + *
> + *   This program is free software; you can redistribute it and/or
> + *   modify it under the terms of the GNU General Public License
> + *   as published by the Free Software Foundation, version 2.
> + *
> + *   This program is distributed in the hope that it will be useful,
> + *   but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *   GNU General Public License for more details.
> + */
> +
> +#ifndef _ASM_RISCV_BITOPS_H
> +#define _ASM_RISCV_BITOPS_H
> +
> +#ifndef _LINUX_BITOPS_H
> +#error "Only <linux/bitops.h> can be included directly"
> +#endif /* _LINUX_BITOPS_H */
> +
> +#include <linux/compiler.h>
> +#include <linux/irqflags.h>
> +#include <asm/barrier.h>
> +#include <asm/bitsperlong.h>
> +
> +#ifndef smp_mb__before_clear_bit
> +#define smp_mb__before_clear_bit()  smp_mb()
> +#define smp_mb__after_clear_bit()   smp_mb()
> +#endif /* smp_mb__before_clear_bit */
> +
> +#include <asm-generic/bitops/__ffs.h>
> +#include <asm-generic/bitops/ffz.h>
> +#include <asm-generic/bitops/fls.h>
> +#include <asm-generic/bitops/__fls.h>
> +#include <asm-generic/bitops/fls64.h>
> +#include <asm-generic/bitops/find.h>
> +#include <asm-generic/bitops/sched.h>
> +#include <asm-generic/bitops/ffs.h>
> +
> +#include <asm-generic/bitops/hweight.h>
> +
> +#if (BITS_PER_LONG == 64)
> +#define __AMO(op)	"amo" #op ".d"
> +#elif (BITS_PER_LONG == 32)
> +#define __AMO(op)	"amo" #op ".w"
> +#else
> +#error "Unexpected BITS_PER_LONG"
> +#endif
> +

So the test_and_{set,change,clear}_bit() have the similar semantics as
cmpxchg(), so

> +#define __test_and_op_bit(op, mod, nr, addr)			\
> +({								\
> +	unsigned long __res, __mask;				\
> +	__mask = BIT_MASK(nr);					\
> +	__asm__ __volatile__ (					\
> +		__AMO(op) " %0, %2, %1"				\

... "aqrl" bit is needed here, and

> +		: "=r" (__res), "+A" (addr[BIT_WORD(nr)])	\
> +		: "r" (mod(__mask)));				\

... "memory" clobber is needed here.

> +	((__res & __mask) != 0);				\
> +})
> +
> +#define __op_bit(op, mod, nr, addr)				\
> +	__asm__ __volatile__ (					\
> +		__AMO(op) " zero, %1, %0"			\
> +		: "+A" (addr[BIT_WORD(nr)])			\
> +		: "r" (mod(BIT_MASK(nr))))
> +
> +/* Bitmask modifiers */
> +#define __NOP(x)	(x)
> +#define __NOT(x)	(~(x))
> +
> +/**
> + * test_and_set_bit - Set a bit and return its old value
> + * @nr: Bit to set
> + * @addr: Address to count from
> + *
> + * This operation is atomic and cannot be reordered.
> + * It may be reordered on other architectures than x86.
> + * It also implies a memory barrier.
> + */
> +static inline int test_and_set_bit(int nr, volatile unsigned long *addr)
> +{
> +	return __test_and_op_bit(or, __NOP, nr, addr);
> +}
> +
> +/**
> + * test_and_clear_bit - Clear a bit and return its old value
> + * @nr: Bit to clear
> + * @addr: Address to count from
> + *
> + * This operation is atomic and cannot be reordered.
> + * It can be reordered on other architectures other than x86.
> + * It also implies a memory barrier.
> + */
> +static inline int test_and_clear_bit(int nr, volatile unsigned long *addr)
> +{
> +	return __test_and_op_bit(and, __NOT, nr, addr);
> +}
> +
> +/**
> + * test_and_change_bit - Change a bit and return its old value
> + * @nr: Bit to change
> + * @addr: Address to count from
> + *
> + * This operation is atomic and cannot be reordered.
> + * It also implies a memory barrier.
> + */
> +static inline int test_and_change_bit(int nr, volatile unsigned long *addr)
> +{
> +	return __test_and_op_bit(xor, __NOP, nr, addr);
> +}
> +
> +/**
> + * set_bit - Atomically set a bit in memory
> + * @nr: the bit to set
> + * @addr: the address to start counting from
> + *
> + * This function is atomic and may not be reordered.  See __set_bit()

This is incorrect, {set,change,clear}_bit() can be reordered, see
Documentation/memory-barriers.txt, they are just relaxed atomics. But I
think you just copy this from x86 code, so maybe x86 code needs help
too, at least claim that's only x86-specific guarantee.

> + * if you do not require the atomic guarantees.
> + *
> + * Note: there are no guarantees that this function will not be reordered
> + * on non x86 architectures, so if you are writing portable code,
> + * make sure not to rely on its reordering guarantees.
> + *
> + * Note that @nr may be almost arbitrarily large; this function is not
> + * restricted to acting on a single-word quantity.
> + */
> +static inline void set_bit(int nr, volatile unsigned long *addr)
> +{
> +	__op_bit(or, __NOP, nr, addr);
> +}
> +
> +/**
> + * clear_bit - Clears a bit in memory
> + * @nr: Bit to clear
> + * @addr: Address to start counting from
> + *
> + * clear_bit() is atomic and may not be reordered.  However, it does
> + * not contain a memory barrier, so if it is used for locking purposes,
> + * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit()
> + * in order to ensure changes are visible on other processors.
> + */
> +static inline void clear_bit(int nr, volatile unsigned long *addr)
> +{
> +	__op_bit(and, __NOT, nr, addr);
> +}
> +
> +/**
> + * change_bit - Toggle a bit in memory
> + * @nr: Bit to change
> + * @addr: Address to start counting from
> + *
> + * change_bit() is atomic and may not be reordered. It may be
> + * reordered on other architectures than x86.
> + * Note that @nr may be almost arbitrarily large; this function is not
> + * restricted to acting on a single-word quantity.
> + */
> +static inline void change_bit(int nr, volatile unsigned long *addr)
> +{
> +	__op_bit(xor, __NOP, nr, addr);
> +}
> +
> +/**
> + * test_and_set_bit_lock - Set a bit and return its old value, for lock
> + * @nr: Bit to set
> + * @addr: Address to count from
> + *
> + * This operation is atomic and provides acquire barrier semantics.
> + * It can be used to implement bit locks.
> + */
> +static inline int test_and_set_bit_lock(
> +	unsigned long nr, volatile unsigned long *addr)
> +{
> +	return test_and_set_bit(nr, addr);

If you want, you can open code an "amoor.aq" here, because
test_and_set_bit_lock() only needs an acquire barrier.

> +}
> +
> +/**
> + * clear_bit_unlock - Clear a bit in memory, for unlock
> + * @nr: the bit to set
> + * @addr: the address to start counting from
> + *
> + * This operation is atomic and provides release barrier semantics.
> + */
> +static inline void clear_bit_unlock(
> +	unsigned long nr, volatile unsigned long *addr)
> +{

You need a smp_mb__before_atomic() here, because clear_bit() is only
relaxed atomic. And clear_bit_unlock() is a release.

Regards,
Boqun

> +	clear_bit(nr, addr);
> +}
> +
> +/**
> + * __clear_bit_unlock - Clear a bit in memory, for unlock
> + * @nr: the bit to set
> + * @addr: the address to start counting from
> + *
> + * This operation is like clear_bit_unlock, however it is not atomic.
> + * It does provide release barrier semantics so it can be used to unlock
> + * a bit lock, however it would only be used if no other CPU can modify
> + * any bits in the memory until the lock is released (a good example is
> + * if the bit lock itself protects access to the other bits in the word).
> + */
> +static inline void __clear_bit_unlock(
> +	unsigned long nr, volatile unsigned long *addr)
> +{
> +	clear_bit(nr, addr);
> +}
> +
> +#undef __test_and_op_bit
> +#undef __op_bit
> +#undef __NOP
> +#undef __NOT
> +#undef __AMO
> +
> +#include <asm-generic/bitops/non-atomic.h>
> +#include <asm-generic/bitops/le.h>
> +#include <asm-generic/bitops/ext2-atomic.h>
> +
> +#endif /* _ASM_RISCV_BITOPS_H */
[...]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2017-07-12 12:41 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-12  1:31 RISC-V Linux Port v6 Palmer Dabbelt
2017-07-12  1:31 ` [PATCH 01/17] lib: Add shared copies of some GCC library routines Palmer Dabbelt
2017-07-12  1:31 ` [PATCH 02/17] pci: Add a generic, weakly-linked pcibios_align_resource Palmer Dabbelt
2017-07-12 13:41   ` Luis R. Rodriguez
2017-07-12 22:50   ` Bjorn Helgaas
2017-07-13 18:30     ` Palmer Dabbelt
2017-07-14  3:19   ` kbuild test robot
2017-07-12  1:31 ` [PATCH 03/17] pci: Add a generic, weakly-linked pcibios_fixup_bus Palmer Dabbelt
2017-07-12  1:31 ` [PATCH 04/17] MAINTAINERS: Add RISC-V Palmer Dabbelt
2017-07-12 11:16   ` James Hogan
2017-07-12 11:31     ` Arnd Bergmann
2017-07-12 14:51       ` [patches] " Jonathan Neuschäfer
2017-07-12  1:31 ` [PATCH 05/17] clocksource: New RISC-V SBI timer driver Palmer Dabbelt
2017-07-12  1:31 ` [PATCH 06/17] irqchip: RISC-V Local Interrupt Controller Driver Palmer Dabbelt
2017-07-12  1:31 ` [PATCH 07/17] irqchip: New RISC-V PLIC Driver Palmer Dabbelt
2017-07-12  1:31 ` [PATCH 08/17] tty: New RISC-V SBI console driver Palmer Dabbelt
2017-07-12  1:31 ` [PATCH 09/17] RISC-V: Init and Halt Code Palmer Dabbelt
2017-07-12  1:31 ` [PATCH 10/17] RISC-V: Atomic and Locking Code Palmer Dabbelt
2017-07-12 12:40   ` Boqun Feng [this message]
2017-07-12 12:44     ` Boqun Feng
2017-07-12 12:49     ` Peter Zijlstra
2017-07-12 17:17     ` Palmer Dabbelt
2017-07-12 13:13   ` Arnd Bergmann
2017-07-12  1:31 ` [PATCH 11/17] RISC-V: Generic library routines and assembly Palmer Dabbelt
2017-07-12  1:31 ` [PATCH 12/17] RISC-V: ELF and module implementation Palmer Dabbelt
2017-07-12  1:31 ` [PATCH 13/17] RISC-V: Task implementation Palmer Dabbelt
2017-07-12  1:31 ` [PATCH 14/17] RISC-V: Device, timer, IRQs, and the SBI Palmer Dabbelt
2017-07-12  1:31 ` [PATCH 15/17] RISC-V: Paging and MMU Palmer Dabbelt
2017-07-12  1:31 ` [PATCH 16/17] RISC-V: User-facing API Palmer Dabbelt
2017-07-12 11:07   ` James Hogan
2017-07-12 16:24     ` Palmer Dabbelt
2017-07-12 17:09       ` James Hogan
2017-07-13 21:50         ` Palmer Dabbelt
2017-07-12  1:31 ` [PATCH 17/17] RISC-V: Build Infastructure Palmer Dabbelt
2017-07-26  2:57   ` [patches] " Jonathan Neuschäfer
2017-07-26  5:20     ` Palmer Dabbelt
2017-07-26  6:52       ` Arnd Bergmann
2017-07-26 18:37       ` Jonathan Neuschäfer
2017-07-12  7:58 ` RISC-V Linux Port v6 Arnd Bergmann
2017-07-12 13:53   ` Luis R. Rodriguez
2017-07-12 17:55   ` Will Deacon
2017-07-12 19:34     ` Arnd Bergmann
  -- strict thread matches above, loose matches on Subject: below --
2017-07-11  1:39 RISC-V Linux Port v5 Palmer Dabbelt
2017-07-11  1:39 ` [PATCH 10/17] RISC-V: Atomic and Locking Code Palmer Dabbelt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170712124049.i7taml22aat2bcgt@tardis \
    --to=boqun.feng@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=albert@sifive.com \
    --cc=arnd@arndb.de \
    --cc=bart.vanassche@sandisk.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=davem@davemloft.net \
    --cc=dledford@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=james.hogan@imgtec.com \
    --cc=jason@lakedaemon.net \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=marc.zyngier@arm.com \
    --cc=mcgrof@kernel.org \
    --cc=mchehab@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mmarek@suse.com \
    --cc=mpe@ellerman.id.au \
    --cc=msalter@redhat.com \
    --cc=nicolas.dichtel@6wind.com \
    --cc=olof@lixom.net \
    --cc=palmer@dabbelt.com \
    --cc=patches@groups.riscv.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=peterz@infradead.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=sfr@canb.auug.org.au \
    --cc=sstabellini@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will.deacon@arm.com \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®