If you use git, you can easily cherry-pick the fix from HardenedBSD:

https://github.com/HardenedBSD/hardenedBSD/commit/e7ee74598b987fdc702614668b7ea85884289cf1

On Tue, Aug 11, 2020 at 02:31:26PM +0200, Mateusz Guzik wrote:
> Hi. This remains unfixed.
> 
> On 8/4/20, Emmanuel Vadot <m...@bidouilliste.com> wrote:
> > On Tue, 4 Aug 2020 13:11:02 -0500
> > Alan Cox <a...@rice.edu> wrote:
> >
> >>
> >> On 8/4/20 10:25 AM, Emmanuel Vadot wrote:
> >> > Author: manu
> >> > Date: Tue Aug  4 15:25:22 2020
> >> > New Revision: 363842
> >> > URL: https://svnweb.freebsd.org/changeset/base/363842
> >> >
> >> > Log:
> >> >    linuxkpi: Add clear_bit_unlock
> >> >
> >> >    This calls clear_bit and adds a memory barrier.
> >> >
> >> >    Sponsored by: The FreeBSD Foundation
> >> >
> >> >    Reviewed by:  hselasky
> >> >    MFC after:    1 week
> >> >    Differential Revision:        https://reviews.freebsd.org/D25943
> >> >
> >> > Modified:
> >> >    head/sys/compat/linuxkpi/common/include/linux/bitops.h
> >> >
> >> > Modified: head/sys/compat/linuxkpi/common/include/linux/bitops.h
> >> > ==============================================================================
> >> > --- head/sys/compat/linuxkpi/common/include/linux/bitops.h       Tue Aug 
> >> >  4
> >> > 15:00:02 2020    (r363841)
> >> > +++ head/sys/compat/linuxkpi/common/include/linux/bitops.h       Tue Aug 
> >> >  4
> >> > 15:25:22 2020    (r363842)
> >> > @@ -275,6 +275,13 @@ find_next_zero_bit(const unsigned long *addr,
> >> > unsigned
> >> >   #define        test_bit(i, a)                                          
> >> >         \
> >> >       !!(READ_ONCE(((volatile const unsigned long *)(a))[BIT_WORD(i)]) &
> >> > BIT_MASK(i))
> >> >
> >> > +static inline void
> >> > +clear_bit_unlock(long bit, volatile unsigned long *var)
> >> > +{
> >> > +        clear_bit(bit, var);
> >> > +        wmb();
> >>
> >>
> >> For an unlock operation, the memory barrier should come before the
> >> clear_bit() call, not after.?? See, for example, the alpha implementation
> >> in Linux.?? Also, the correct "spelling" for this memory barrier in
> >> FreeBSD would be atomic_thread_fence_rel(). See, for example, the
> >> comment at the top of sys/amd64/include/atomic.h.
> >
> >  Ah yes, thanks. I probably got lost looking for the linux implem but
> > that does make sense, I'll fix that probably tomorow.
> >
> >  Thanks.
> >
> >>
> >> > +}
> >> > +
> >> >   static inline int
> >> >   test_and_clear_bit(long bit, volatile unsigned long *var)
> >> >   {
> >
> >
> > --
> > Emmanuel Vadot <m...@bidouilliste.com> <m...@freebsd.org>
> >
> 
> 
> -- 
> Mateusz Guzik <mjguzik gmail.com>
> _______________________________________________
> svn-src-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

GPG Key ID:          0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

Attachment: signature.asc
Description: PGP signature

Reply via email to