On Fri, May 31, 2019 at 7:11 PM Eric Dumazet wrote:
>
> On Fri, May 31, 2019 at 9:29 AM Andrea Parri
> wrote:
> >
> > On Fri, May 31, 2019 at 08:45:47AM -0700, Eric Dumazet wrote:
> > > On 5/31/19 7:45 AM, Herbert Xu wrote:
> >
> > > > In this case the code doesn't need them because an implicit
>
On Fri, May 31, 2019 at 10:11 AM Paul E. McKenney wrote:
>
> On Fri, May 31, 2019 at 08:45:47AM -0700, Eric Dumazet wrote:
> >
> >
> > On 5/31/19 7:45 AM, Herbert Xu wrote:
> > > On Fri, May 31, 2019 at 10:24:08AM +0200, Dmitry Vyukov wrote:
> > >>
> > >> OK, let's call it barrier. But we need mor
On Fri, May 31, 2019 at 08:45:47AM -0700, Eric Dumazet wrote:
>
>
> On 5/31/19 7:45 AM, Herbert Xu wrote:
> > On Fri, May 31, 2019 at 10:24:08AM +0200, Dmitry Vyukov wrote:
> >>
> >> OK, let's call it barrier. But we need more than a barrier here then.
> >
> > READ_ONCE/WRITE_ONCE is not some ma
On Fri, May 31, 2019 at 9:29 AM Andrea Parri
wrote:
>
> On Fri, May 31, 2019 at 08:45:47AM -0700, Eric Dumazet wrote:
> > On 5/31/19 7:45 AM, Herbert Xu wrote:
>
> > > In this case the code doesn't need them because an implicit
> > > barrier() (which is *stronger* than READ_ONCE/WRITE_ONCE) alread
On Fri, May 31, 2019 at 08:45:47AM -0700, Eric Dumazet wrote:
> On 5/31/19 7:45 AM, Herbert Xu wrote:
> > In this case the code doesn't need them because an implicit
> > barrier() (which is *stronger* than READ_ONCE/WRITE_ONCE) already
> > exists in both places.
> I have already explained that t
On 5/31/19 7:45 AM, Herbert Xu wrote:
> On Fri, May 31, 2019 at 10:24:08AM +0200, Dmitry Vyukov wrote:
>>
>> OK, let's call it barrier. But we need more than a barrier here then.
>
> READ_ONCE/WRITE_ONCE is not some magical dust that you sprinkle
> around in your code to make it work without lo
On Fri, May 31, 2019 at 10:24:08AM +0200, Dmitry Vyukov wrote:
>
> OK, let's call it barrier. But we need more than a barrier here then.
READ_ONCE/WRITE_ONCE is not some magical dust that you sprinkle
around in your code to make it work without locks. You need to
understand exactly why you need t
On Wed, May 29, 2019 at 7:48 AM Herbert Xu wrote:
>
> On Wed, May 29, 2019 at 07:43:51AM +0200, Dmitry Vyukov wrote:
> >
> > If fqdir->dead read/write are concurrent, then this still needs to be
> > READ_ONCE/WRITE_ONCE. Ordering is orthogonal to atomicity.
>
> No they do not. READ_ONCE/WRITE_ONC
From: Herbert Xu
Date: Wed, 29 May 2019 13:40:26 +0800
> The smp_store_release call in fqdir_exit cannot protect the setting
> of fqdir->dead as claimed because its memory barrier is only
> guaranteed to be one-way and the barrier precedes the setting of
> fqdir->dead.
>
> IOW it doesn't provide
On 5/28/19 10:40 PM, Herbert Xu wrote:
> I see now that it is actually relying on the barrier/locking
> semantics of call_rcu vs. rcu_read_lock. So the smp_store_release
> and READ_ONCE are simply unnecessary and could be confusing to
> future readers.
>
> ---8<---
> The smp_store_release cal
On Wed, May 29, 2019 at 07:43:51AM +0200, Dmitry Vyukov wrote:
>
> If fqdir->dead read/write are concurrent, then this still needs to be
> READ_ONCE/WRITE_ONCE. Ordering is orthogonal to atomicity.
No they do not. READ_ONCE/WRITE_ONCE are basically a more fine-tuned
version of barrier(). In this
On Wed, May 29, 2019 at 7:40 AM Herbert Xu wrote:
>
> On Tue, May 28, 2019 at 06:31:00AM -0700, Eric Dumazet wrote:
> >
> > This smp_store_release() is a left over of the first version of the patch,
> > where
> > there was no rcu grace period enforcement.
> >
> > I do not believe there is harm le
On Tue, May 28, 2019 at 06:31:00AM -0700, Eric Dumazet wrote:
>
> This smp_store_release() is a left over of the first version of the patch,
> where
> there was no rcu grace period enforcement.
>
> I do not believe there is harm letting this, but if you disagree
> please send a patch ;)
I see no
13 matches
Mail list logo
