From: Anisse Astier <anisse@astier.eu>
To: mcgrof@kernel.org
Cc: axboe@kernel.dk, hare@suse.de, hch@lst.de, jeffm@suse.com,
kzak@redhat.com, linux-block@vger.kernel.org,
ming.lei@redhat.com, snitzer@redhat.com
Subject: Re: [PATCH] block: default BLOCK_LEGACY_AUTOLOAD to y
Date: Wed, 28 Dec 2022 17:55:47 +0100 [thread overview]
Message-ID: <20221228165547.27502-1-anisse@astier.eu> (raw)
In-Reply-To: <YhlI4bKqYpknNgBa@bombadil.infradead.org>
Hi,
On Fri, 25 Feb 2022 13:23:45 -0800, Luis Chamberlain wrote:
> On Fri, Feb 25, 2022 at 07:14:40PM +0100, Christoph Hellwig wrote:
> > As Luis reported, losetup currently doesn't properly create the loop
> > device without this if the device node already exists because old
> > scripts created it manually. So default to y for now and remove the
> > aggressive removal schedule.
> >
> > Reported-by: Luis Chamberlain <mcgrof@kernel.org>
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> I'm saddened by the fact that we're not going to get an idea of how far
> and wide the stupid mknod prior to modprobe use is by making this
> as y default even though I know this is the right thing to do.
>
> I think our ownly measure of success here is to really push
> Linux distributions to start disabling BLOCK_LEGACY_AUTOLOAD
> and getting their help to see what burts into flames.
I just spent some time bisecting another thing that regresses without
BLOCK_LEGACY_AUTOLOAD (which was disabled here): mdadm software raid
auto-assemble on boot (with udev).
I think it's because it tries to open /dev/md127 and then fails since it's not
created automatically.
Regards,
Anisse
prev parent reply other threads:[~2022-12-28 17:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-25 18:14 [PATCH] block: default BLOCK_LEGACY_AUTOLOAD to y Christoph Hellwig
2022-02-25 18:37 ` Chaitanya Kulkarni
2022-02-25 20:31 ` Jens Axboe
2022-02-25 21:23 ` Luis Chamberlain
2022-12-28 16:55 ` Anisse Astier [this message]
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=20221228165547.27502-1-anisse@astier.eu \
--to=anisse@astier.eu \
--cc=axboe@kernel.dk \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=jeffm@suse.com \
--cc=kzak@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=ming.lei@redhat.com \
--cc=snitzer@redhat.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.