[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a3b70874-a3a0-4e28-9673-3d39ace4d669@redhat.com>
Date: Fri, 22 Nov 2024 12:21:41 +0100
From: David Hildenbrand <david@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Suren Baghdasaryan <surenb@...gle.com>, akpm@...ux-foundation.org,
andrii@...nel.org, jannh@...gle.com, Liam.Howlett@...cle.com,
lorenzo.stoakes@...cle.com, vbabka@...e.cz, mhocko@...nel.org,
shakeel.butt@...ux.dev, hannes@...xchg.org, willy@...radead.org,
brauner@...nel.org, oleg@...hat.com, arnd@...db.de,
richard.weiyang@...il.com, zhangpeng.00@...edance.com, linmiaohe@...wei.com,
viro@...iv.linux.org.uk, hca@...ux.ibm.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] seqlock: add raw_seqcount_try_begin
On 22.11.24 12:19, Peter Zijlstra wrote:
> On Fri, Nov 22, 2024 at 12:10:29PM +0100, David Hildenbrand wrote:
>
>> In gup_fast(), we simply do
>>
>> seq = raw_read_seqcount(¤t->mm->write_protect_seq);
>> if (seq & 1)
>> return 0;
>>
>> Should we be using that there as well?
>>
>> if (!raw_seqcount_try_begin(¤t->mm->write_protect_seqs, seq))
>> return 0;
>
> Might as well. A quick grep doesn't find me another instance of this
> pattern, but does find me something 'funny' in net/netfilter/x_tables.c.
> Let's pretend I didn't see that for now ... *sigh*
:)
I'm also not 100% sure about barriers in gup_fast() around the
raw_seqcount .... and I'm pretending I didn't see any of that as well ...
>
> Want me to stick a patch like this on, or do you want to do that later,
> when the dust has settled?
Feel free to add a patch to just change that as well, it's an easy change.
For this patch
Reviewed-by: David Hildenbrand <david@...hat.com>
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists