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: [ANNOUNCE] v5.14-rc5-rt8
To:     Mike Galbraith <efault@gmx.de>,
        Clark Williams <williams@redhat.com>
Cc:     Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>,
        RT <linux-rt-users@vger.kernel.org>
References: <20210810163731.2qvfuhenolq2gdlv@linutronix.de>
 <20210812151803.52f84aaf@theseus.lan>
 <5f0c793d-5084-4607-8475-209fa7310ba2@suse.cz>
 <20210812162448.26274298@theseus.lan>
 <bb98b54c-6d88-2a56-4998-51a304c19e8c@suse.cz>
 <20210812164440.0426d8b7@theseus.lan>
 <96ceab8e-4bf9-147a-e931-848676003c3f@suse.cz>
 <5dbf6cf9e82ef15ce0febf070608da2d5b128763.camel@gmx.de>
From:   Vlastimil Babka <vbabka@suse.cz>
Message-ID: <c92fc2cb-03cd-d6a2-fb4a-7bc33e94e391@suse.cz>
Date:   Sun, 15 Aug 2021 11:35:53 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <5dbf6cf9e82ef15ce0febf070608da2d5b128763.camel@gmx.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 8/15/21 6:17 AM, Mike Galbraith wrote:
> On Sat, 2021-08-14 at 21:08 +0200, Vlastimil Babka wrote:
>>
>> Aha! That's helpful. Hopefully it's just a small issue where we
>> opportunistically test flags on a page that's protected by the local
>> lock we didn't take yet, and I didn't realize there's the VM_BUG_ON
>> which can trigger if our page went away (which we would have realized
>> after taking the lock).
> 
> Speaking of optimistic peeking perhaps going badly, why is the below
> not true?  There's protection against ->partial going disappearing
> during a preemption... but can't it just as easily appear, so where is
> that protection?

If it appears, it appears, we don't care, we just leave it there and
won't use it.

> If the other side of that window is safe, it could use a comment so
> dummies reading this code don't end up asking mm folks why the heck
> they don't just take the darn lock and be done with it instead of tap
> dancing all around thething :)

Well, with your patch, ->partial might appear just after the unlock, so
does that really change anything?
The point is to avoid the taking the lock if it's almost certain there
will be nothing to gain.

c->partial appearing is easy to just ignore. c->page appearing, while we
got our own page, is worse as there can be only one c->page. But it's
unavoidable, we can't just keep holding the local lock while going to
the page allocator etc. That's why under retry_load_page: we have to
deactivate a c->page that appeared under us...

> ---
>  mm/slub.c |   14 ++++++--------
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2937,17 +2937,16 @@ static void *___slab_alloc(struct kmem_c
> 
>  new_slab:
> 
> +	/*
> +	 * To avoid false negative race with put_cpu_partial() during a
> +	 * preemption, we must call slub_percpu_partial() under lock.
> +	 */
> +	local_lock_irqsave(&s->cpu_slab->lock, flags);
>  	if (slub_percpu_partial(c)) {
> -		local_lock_irqsave(&s->cpu_slab->lock, flags);
>  		if (unlikely(c->page)) {
>  			local_unlock_irqrestore(&s->cpu_slab->lock, flags);
>  			goto reread_page;
>  		}
> -		if (unlikely(!slub_percpu_partial(c))) {
> -			local_unlock_irqrestore(&s->cpu_slab->lock, flags);
> -			/* we were preempted and partial list got empty */
> -			goto new_objects;
> -		}
> 
>  		page = c->page = slub_percpu_partial(c);
>  		slub_set_percpu_partial(c, page);
> @@ -2955,8 +2954,7 @@ static void *___slab_alloc(struct kmem_c
>  		stat(s, CPU_PARTIAL_ALLOC);
>  		goto redo;
>  	}
> -
> -new_objects:
> +	local_unlock_irqrestore(&s->cpu_slab->lock, flags);
> 
>  	freelist = get_partial(s, gfpflags, node, &page);
>  	if (freelist)
> 
>