[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YSnnXdKLvxEY8yay@infradead.org>
Date: Sat, 28 Aug 2021 08:35:57 +0100
From: Christoph Hellwig <hch@...radead.org>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: Christoph Hellwig <hch@...radead.org>, 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 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.
Powered by blists - more mailing lists