All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.