From: Christoph Hellwig <hch@lst.de>
To: Jan Kara <jack@suse.cz>
Cc: Yufen Yu <yuyufen@huawei.com>, Christoph Hellwig <hch@lst.de>,
axboe@kernel.dk, tj@kernel.org, bvanassche@acm.org,
tytso@mit.edu, gregkh@linuxfoundation.org,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/8] bdi: add a ->dev_name field to struct backing_dev_info
Date: Thu, 16 Apr 2020 14:22:35 +0200 [thread overview]
Message-ID: <20200416122235.GA26982@lst.de> (raw)
In-Reply-To: <20200416121901.GA26483@lst.de>
On Thu, Apr 16, 2020 at 02:19:01PM +0200, Christoph Hellwig wrote:
> On Thu, Apr 16, 2020 at 02:02:23PM +0200, Jan Kara wrote:
> > Yes, that can indeed happen. E.g. I remember that drivers/scsi/sd.c calls
> > device_add_disk() + del_gendisk() repeatedly for one request_queue and that
> > would result in leaking the name (and possibly cause use-after-free
> > issues).
>
> Sd calls device_add_disk once in ->probe, and del_gendisk once in
> sd_remove. Note that sd_probe allocates a new scsi_disk structure and
> a new gendisk everytime, but it does indeed reuse the request_queue
> and thus bdi.
>
> > I think dev_name has to be just a static array inside
> > backing_dev_info which gets overwritten on reregistration. The question is
> > how big should be this array... Some grepping shows that 40 bytes should be
> > enough for everybody except fs/vboxsf/super.c which puts 'fc->source' into
> > the name which can be presumably rather large. Anyway, I'd make it 40 and
> > just truncate it case in case it does not fit. bdi_dev_name() is used for
> > informational purposes anyway...
>
> We could just make it a variable sized array at the end of the structure
> and size it based on the len.
Which doesn't always work as the size might not always be the same.
But I think the fundamental problem is that we are trying to re-register
previous unregistered bdis. We really should not have bdi_alloc
separate from bdi_register and solve this properly.
next prev parent reply other threads:[~2020-04-16 12:22 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-16 7:15 bdi: fix use-after-free for dev_name(bdi->dev) Christoph Hellwig
2020-04-16 7:15 ` [PATCH 1/8] bdi: move bdi_dev_name out of line Christoph Hellwig
2020-04-16 7:52 ` Greg KH
2020-04-16 12:32 ` Jan Kara
2020-04-16 7:15 ` [PATCH 2/8] bdi: use bdi_dev_name() to get device name Christoph Hellwig
2020-04-16 7:52 ` Greg KH
2020-04-16 7:15 ` [PATCH 3/8] bdi: add a ->dev_name field to struct backing_dev_info Christoph Hellwig
2020-04-16 7:52 ` Greg KH
2020-04-16 8:34 ` Yufen Yu
2020-04-16 12:02 ` Jan Kara
2020-04-16 12:19 ` Christoph Hellwig
2020-04-16 12:22 ` Christoph Hellwig [this message]
2020-04-16 12:31 ` Jan Kara
2020-04-16 7:15 ` [PATCH 4/8] driver core: remove device_create_vargs Christoph Hellwig
2020-04-16 7:52 ` Greg KH
2020-04-16 7:15 ` [PATCH 5/8] bdi: unexport bdi_register_va Christoph Hellwig
2020-04-16 7:53 ` Greg KH
2020-04-16 12:03 ` Jan Kara
2020-04-16 7:15 ` [PATCH 6/8] bdi: remove bdi_register_owner Christoph Hellwig
2020-04-16 7:53 ` Greg KH
2020-04-16 12:05 ` Jan Kara
2020-04-16 7:15 ` [PATCH 7/8] bdi: simplify bdi_alloc Christoph Hellwig
2020-04-16 7:54 ` Greg KH
2020-04-16 12:06 ` Jan Kara
2020-04-16 7:15 ` [PATCH 8/8] bdi: remove the name field in struct backing_dev_info Christoph Hellwig
2020-04-16 7:54 ` Greg KH
2020-04-16 12:23 ` Jan Kara
2020-04-16 15:29 ` bdi: fix use-after-free for dev_name(bdi->dev) Jens Axboe
2020-04-16 15:29 ` Christoph Hellwig
2020-04-16 15:30 ` Jens Axboe
-- strict thread matches above, loose matches on Subject: below --
2020-04-16 16:54 bdi: fix use-after-free for dev_name(bdi->dev) v2 Christoph Hellwig
2020-04-16 16:54 ` [PATCH 3/8] bdi: add a ->dev_name field to struct backing_dev_info Christoph Hellwig
2020-04-17 8:59 ` Jan Kara
2020-04-17 13:01 ` Christoph Hellwig
2020-04-20 11:41 ` Hans de Goede
2020-04-20 11:58 ` Christoph Hellwig
2020-04-21 12:42 ` Hans de Goede
2020-04-18 15:40 ` Bart Van Assche
2020-04-19 7:58 ` Christoph Hellwig
2020-04-19 15:29 ` Bart Van Assche
2020-04-19 16:06 ` Christoph Hellwig
2020-04-20 7:48 ` Christoph Hellwig
2020-04-20 9:52 ` Jan Kara
2020-04-20 9:49 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200416122235.GA26982@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=tytso@mit.edu \
--cc=yuyufen@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.