[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YS1HCgP/XdWmMtFN@bombadil.infradead.org>
Date: Mon, 30 Aug 2021 14:00:58 -0700
From: Luis Chamberlain <mcgrof@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: axboe@...nel.dk, martin.petersen@...cle.com, jejb@...ux.ibm.com,
kbusch@...nel.org, sagi@...mberg.me, adrian.hunter@...el.com,
beanhuo@...ron.com, ulf.hansson@...aro.org, avri.altman@....com,
swboyd@...omium.org, agk@...hat.com, snitzer@...hat.com,
josef@...icpanda.com, hare@...e.de, bvanassche@....org,
ming.lei@...hat.com, linux-scsi@...r.kernel.org,
linux-nvme@...ts.infradead.org, linux-mmc@...r.kernel.org,
dm-devel@...hat.com, nbd@...er.debian.org,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 08/10] dm: add add_disk() error handling
On Sat, Aug 28, 2021 at 08:35:57AM +0100, Christoph Hellwig wrote:
> On Fri, Aug 27, 2021 at 11:55:14AM -0700, Luis Chamberlain wrote:
> > > I think the add_disk should just return r. If you look at the
> > > callers they eventualy end up in dm_table_destroy, which does
> > > this cleanup.
> >
> > I don't see it. What part of dm_table_destroy() does this?
>
> Sorry, dm_destroy, not dm_table_destroy. For dm_early_create it's
> trivial as that calls both dm_table_destroy and dm_destroy in the error
> path. The normal table_load case is a separate ioctl, but if that
> fails userspace needs to call the DM_DEV_REMOVE_CMD to cleanup
> the state - similar to any other failure.
I see, ok sure I'll document this on the commit log as its not so
obvious.
Luis
Powered by blists - more mailing lists