On Thu, Jan 27, 2022 at 09:25:48AM +0100, Michal Hocko wrote: > On Thu 27-01-22 06:59:50, Manfred Spraul wrote: > > Hi Andrew, > > > > On 1/27/22 03:53, Andrew Morton wrote: > > > On Wed, 22 Dec 2021 20:48:28 +0100 Manfred Spraul <manfred@xxxxxxxxxxxxxxxx> wrote: > > > > > > > One codepath in find_alloc_undo() calls kvfree() while holding a spinlock. > > > > Since vfree() can sleep this is a bug. > > > > > > > > Previously, the code path used kfree(), and kfree() is safe to be called > > > > while holding a spinlock. > > > > > > > > Minghao proposed to fix this by updating find_alloc_undo(). > > > > > > > > Alternate proposal to fix this: Instead of changing find_alloc_undo(), > > > > change kvfree() so that the same rules as for kfree() apply: > > > > Having different rules for kfree() and kvfree() just asks for bugs. > > > > > > > > Disadvantage: Releasing vmalloc'ed memory will be delayed a bit. > > > I know we've been around this loop a bunch of times and deferring was > > > considered. But I forget the conclusion. IIRC, mhocko was involved? > > > > I do not remember a mail from mhocko. > > I do not remember either. > > > > > Shakeel proposed to use the approach from Chi. > > > > Decision: https://marc.info/?l=linux-kernel&m=164132032717757&w=2 > > And I would agree with Shakeel and go with the original change to the > ipc code. That is trivial and without any other side effects like this > one. I bet nobody has evaluated what the undconditional deferred freeing > has. At least changelog doesn't really dive into that more than a very > vague statement that this will happen. > Absolutely agree here. Especially that changing the kvfree() will not look stable. After applying the https://www.spinics.net/lists/linux-mm/msg282264.html we will be able to use vfree() from atomic anyway. -- Vlad Rezki
