Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v2] mm/gup: fix try_grab_compound_head() race with
 split_huge_page()
To:     Yang Shi <shy828301@gmail.com>
Cc:     Jann Horn <jannh@google.com>, John Hubbard <jhubbard@nvidia.com>,
        Matthew Wilcox <willy@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linux-MM <linux-mm@kvack.org>,
        kernel list <linux-kernel@vger.kernel.org>,
        "Kirill A . Shutemov" <kirill@shutemov.name>,
        Jan Kara <jack@suse.cz>, stable <stable@vger.kernel.org>
References: <20210615012014.1100672-1-jannh@google.com>
 <50d828d1-2ce6-21b4-0e27-fb15daa77561@nvidia.com>
 <CAG48ez3Vbcvh4AisU7=ukeJeSjHGTKQVd0NOU6XOpRru7oP_ig@mail.gmail.com>
 <CAHbLzkomex+fgC8RyogXu-s5o2UrORMO6D2yTsSXW5Wo5z9WRA@mail.gmail.com>
 <6d21f8cb-4b72-bdec-386c-684ddbcdada1@suse.cz>
 <CAHbLzkpa5MQBtYcRPWu4vNDn=Q8SKStQ-9wKYWogqRrMR3Aonw@mail.gmail.com>
From:   Vlastimil Babka <vbabka@suse.cz>
Message-ID: <2847e923-2366-6a3b-3d76-4513a01981a0@suse.cz>
Date:   Thu, 17 Jun 2021 18:09:16 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CAHbLzkpa5MQBtYcRPWu4vNDn=Q8SKStQ-9wKYWogqRrMR3Aonw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 6/16/21 8:40 PM, Yang Shi wrote:
> On Wed, Jun 16, 2021 at 10:27 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>>
>> On 6/16/21 1:10 AM, Yang Shi wrote:
>> > On Tue, Jun 15, 2021 at 5:10 AM Jann Horn <jannh@google.com> wrote:
>> >>
>> >
>> > It might be possible after Mel's "mm/page_alloc: Allow high-order
>> > pages to be stored on the per-cpu lists" patch
>> > (https://patchwork.kernel.org/project/linux-mm/patch/20210611135753.GC30378@techsingularity.net/).
>>
>> Those would be percpu indeed, but not "lockless, non-atomic", no? They are
>> protected by a local_lock.
> 
> The local_lock is *not* a lock on non-PREEMPT_RT kernel IIUC. It
> disables preempt and IRQ. But preempt disable is no-op on non-preempt
> kernel. IRQ disable can guarantee it is atomic context, but I'm not
> sure if it is equivalent to "atomic freelists" in Jann's context.

Hm right, I thought all locks had the acquire/release semantics, but this one is
just a barrier().