[<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
 
