[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa2a06491cf2d90eb35c95042f888cd49df119fe.camel@axis.com>
Date: Wed, 24 May 2023 13:36:39 +0000
From: Vincent Whitchurch <Vincent.Whitchurch@...s.com>
To: Vincent Whitchurch <Vincent.Whitchurch@...s.com>,
"hch@...radead.org" <hch@...radead.org>
CC: kernel <kernel@...s.com>, "vigneshr@...com" <vigneshr@...com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"miquel.raynal@...tlin.com" <miquel.raynal@...tlin.com>,
"richard@....at" <richard@....at>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>
Subject: Re: [PATCH 2/2] ubi: block: Fix deadlock on remove
On Tue, 2023-05-23 at 23:04 -0700, Christoph Hellwig wrote:
> If you imlement ->free_disk, the list_del and kfree can move into
> that, and we don't really care if a new opener raced with the delete.
Moving the kfree() to ->free_disk() works, but the list_del() still
needs to be in ubiblock_remove() since otherwise ubiblock_remove() could
attempt to remove the same device twice.
I assumed the current code really wanted to prevent new openers racing
with delete, but if that is not needed, yes, we don't need to add a
->removing flag if we move the kfree() to ->free_disk(). I'll re-spin
this based on your suggestions. Thanks.
Powered by blists - more mailing lists