All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, Jan Kara <jack@suse.cz>,
	axboe@kernel.dk, yuyufen@huawei.com, 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: Mon, 20 Apr 2020 13:58:56 +0200	[thread overview]
Message-ID: <20200420115856.GA12115@lst.de> (raw)
In-Reply-To: <e02b7cdc-f29a-916c-d923-224a1b312485@redhat.com>

On Mon, Apr 20, 2020 at 01:41:57PM +0200, Hans de Goede wrote:
> AFAICT for vboxsf the bdi-name can be anything as long as it is unique, hence
> the "vboxsf-" prefix to make this unique vs other block-devices and the
> ".%d" postfix is necessary because the same export can be mounted multiple
> times (without using bind mounts), see:
> https://github.com/jwrdegoede/vboxsf/issues/3

Shouldn't vboxsf switch to get_tree_single instead of get_tree_nodev?
Having two independent dentry trees for a single actual file system
can be pretty dangerous.

>
> The presence of the source inside the bdi-name is only for informational
> purposes really, so truncating that should be fine, maybe switch to:
>
> "vboxsf%d-%s" as format string and swap the sbi->bdi_id and fc->source
> in the args, then if we truncate anything it will be the source (which
> as said is only there for informational purposes) and the name will
> still be guaranteed to be unique.

Can we just switch to vboxsf%d where %d іs a simple monotonically
incrementing count?  That is what various other file systems (e.g. ceph)
do.

  reply	other threads:[~2020-04-20 11:59 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-16 16:54 bdi: fix use-after-free for dev_name(bdi->dev) v2 Christoph Hellwig
2020-04-16 16:54 ` [PATCH 1/8] bdi: move bdi_dev_name out of line Christoph Hellwig
2020-04-18 15:35   ` Bart Van Assche
2020-04-16 16:54 ` [PATCH 2/8] bdi: use bdi_dev_name() to get device name Christoph Hellwig
2020-04-18 15:37   ` Bart Van Assche
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 [this message]
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
2020-04-16 16:54 ` [PATCH 4/8] driver core: remove device_create_vargs Christoph Hellwig
2020-04-16 16:54 ` [PATCH 5/8] bdi: unexport bdi_register_va Christoph Hellwig
2020-04-18 15:41   ` Bart Van Assche
2020-04-16 16:54 ` [PATCH 6/8] bdi: remove bdi_register_owner Christoph Hellwig
2020-04-18 15:43   ` Bart Van Assche
2020-04-16 16:54 ` [PATCH 7/8] bdi: simplify bdi_alloc Christoph Hellwig
2020-04-18 15:44   ` Bart Van Assche
2020-04-16 16:54 ` [PATCH 8/8] bdi: remove the name field in struct backing_dev_info Christoph Hellwig
2020-04-18 15:45   ` Bart Van Assche
  -- strict thread matches above, loose matches on Subject: below --
2020-04-16  7:15 bdi: fix use-after-free for dev_name(bdi->dev) Christoph Hellwig
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
2020-04-16 12:31           ` 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=20200420115856.GA12115@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --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.