On Mon, Feb 10, 2020 at 01:52:26PM +0000, Mateusz Guzik wrote:
M> Author: mjg
M> Date: Mon Feb 10 13:52:25 2020
M> New Revision: 357728
M> URL: https://svnweb.freebsd.org/changeset/base/357728
M> 
M> Log:
M>   Tidy up zpcpu_replace*
M>   
M>   - only compute the target address once
M>   - remove spurious type casting, zpcpu_get already return the correct type
M>   
M>   While here add missing newlines to other routines.
M> 
M> Modified:
M>   head/sys/sys/pcpu.h
M> 
M> Modified: head/sys/sys/pcpu.h
M> 
==============================================================================
M> --- head/sys/sys/pcpu.h      Mon Feb 10 13:24:14 2020        (r357727)
M> +++ head/sys/sys/pcpu.h      Mon Feb 10 13:52:25 2020        (r357728)
M> @@ -245,32 +245,41 @@ extern struct pcpu *cpuid_to_pcpu[];
M>   * If you need atomicity use xchg.
M>   * */
M>  #define zpcpu_replace(base, val) ({                                 \
M> -    __typeof(val) _old = *(__typeof(base))zpcpu_get(base);          \
M> -    *(__typeof(val) *)zpcpu_get(base) = val;                        \
M> +    __typeof(val) *_ptr = zpcpu_get(base);                          \
M> +    __typeof(val) _old;                                             \
M> +                                                                    \
M> +    _old = *_ptr;                                                   \
M> +    *_ptr = val;                                                    \
M>      _old;                                                           \
M>  })

I think this function must have only protected variant that asserts
that curthread->td_critnest is on.

zpcpu_get() sometimes can be used without critical section, when we
are fine with getting a value from a different CPU.

However, can't imagine a situation where migrating during a replace
operation is acceptable.

-- 
Gleb Smirnoff
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to