[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e2b567bd-5a1d-d19a-a45b-6f48d2292dd3@suse.cz>
Date: Wed, 12 Oct 2022 14:30:15 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Steven Rostedt <rostedt@...dmis.org>, eadavis@...a.com
Cc: syzbot+dfcc5f4da15868df7d4d@...kaller.appspotmail.com,
akpm@...ux-foundation.org, keescook@...omium.org,
linux-kernel@...r.kernel.org, mark.rutland@....com,
mhiramat@...nel.org, syzkaller-bugs@...glegroups.com,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v2] mm: slab, with same context require fs_reclaim lock
On 10/12/22 13:23, Steven Rostedt wrote:
> On Tue, 27 Sep 2022 15:11:34 +0800
> eadavis@...a.com wrote:
>> --- a/mm/slab.c
>> +++ b/mm/slab.c
>> @@ -3275,15 +3275,19 @@ slab_alloc(struct kmem_cache *cachep, struct list_lru *lru, gfp_t flags,
>> bool init = false;
>>
>> flags &= gfp_allowed_mask;
>> + local_irq_save(save_flags);
>
> Please do not do this. Open coding interrupt disabling due to locking
> issues is not the solution. You need to make the locks themselves
> disable interrupts if need be. This breaks PREEMPT_RT, and creates a
> "big kernel lock" situation where there's random interrupts being
> disabled for no apparent reason.
>
> -- Steve
And FWIW the problem was in the calling context of io_uring, not slab code
itself in the first place, see:
https://lore.kernel.org/all/20220929135627.ykivmdks2w5vzrwg@quack3/
Powered by blists - more mailing lists