[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2cfe35d4-3220-dd60-88d3-90b86eb5084a@colorfullife.com>
Date: Mon, 3 Jan 2022 18:17:58 +0100
From: Manfred Spraul <manfred@...orfullife.com>
To: Jiri Slaby <jirislaby@...nel.org>, cgel.zte@...il.com,
Andrew Morton <akpm@...ux-foundation.org>
Cc: stable@...r.kernel.org, arnd@...db.de, chi.minghao@....com.cn,
dbueso@...e.de, linux-kernel@...r.kernel.org,
rdunlap@...radead.org, shakeelb@...gle.com, unixbhaskar@...il.com,
vvs@...tuozzo.com, zealci@....com.cn
Subject: Re: [PATCH v2] ipc/sem: do not sleep with a spin lock held
Hi Jiri,
On 1/3/22 10:27, Jiri Slaby wrote:
> On 23. 12. 21, 4:12, cgel.zte@...il.com wrote:
>> From: Minghao Chi <chi.minghao@....com.cn>
>>
>> We can't call kvfree() with a spin lock held, so defer it.
>
> Sorry, defer what?
>
First drop the spinlock, then call kvfree().
> There are attempts to fix kvfree instead, not sure which of these
> approaches (fix kvfree or its callers) won in the end?
>
Exactly. We have three options - but noone volunteered yet to decide:
- change ipc/sem.c [minimal change]
- change kvfree() to use vfree_atomic() [would also fix other changes
that did s/kfree/kvfree/]
- Modify the vma handling so that it becomes safe to call vfree() while
holding a spinlock. [perfect approach, but I'm concerned about side effects]
--
Manfred
Powered by blists - more mailing lists