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 --]
next prev parent 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®