[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200420074801.GA30795@lst.de>
Date: Mon, 20 Apr 2020 09:48:01 +0200
From: Christoph Hellwig <hch@....de>
To: Bart Van Assche <bvanassche@....org>
Cc: Christoph Hellwig <hch@....de>, Jan Kara <jack@...e.cz>,
axboe@...nel.dk, yuyufen@...wei.com, tj@...nel.org, tytso@....edu,
gregkh@...uxfoundation.org, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/8] bdi: add a ->dev_name field to struct
backing_dev_info
On Sun, Apr 19, 2020 at 06:06:51PM +0200, Christoph Hellwig wrote:
> > (https://lore.kernel.org/linux-block/20200416071519.807660-4-hch@lst.de/)
> > and also to the replies to that patch? This is what I found in the replies:
> > "When driver try to to re-register bdi but without release_bdi(), the old
> > dev_name will be cover directly by the newer in bdi_register_va(). So, I am
> > not sure whether it can cause memory leak for bdi->dev_name."
> >
> > Has it been considered to avoid that leak by freeing bdi->dev_name from
> > unregister_bdi(), e.g. as follows?
>
> We'd need some protection against concurrent accesses as unregister_bdi
> can race with them. But with RCU that could be handled, so let me try
> that.
I looked into it, and while it seems doable I think this goes in the
wrong direction as it pushed the RCU knowledge into the callers. I'd
rather get something like this series in ASAP, and then for 5.8 or 5.9
move the bdi pointer to the gendisk and stop re-registering it and thus
solve the problems root cause for real.
Powered by blists - more mailing lists