[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjOiBc3NiMRQJC6EsVosKOWmXiskqb0up6b5MOxCKSCBQ@mail.gmail.com>
Date: Mon, 11 Apr 2022 19:47:44 -1000
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Mikulas Patocka <mpatocka@...hat.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH] stat: don't fail if the major number is >= 256
On Mon, Apr 11, 2022 at 7:41 PM Christoph Hellwig <hch@...radead.org> wrote:
>
> And that is easily fixed by using a lower major for the block dynamic
> dev_t. In theory userspace should be able to copy with any major for
> it, but I fear something might break so we could make it configurable.
We actually have a ton of major numbers free, although it's not
obvious because of the whole "they are used by character devices, not
block devices" issue.
Ie 4-6, 12, 14, 19 are all free, afaik.
But yeah, somebody might have a static /dev for some odd embedded case, I guess.
That said, it really does look like we just return -EOVERFLOW much too
eagerly, for stupid and bad reasons.
Considering that BLOCK_EXT_MAJOR has been 259 since 2008, and this is
the first time anybody has hit this, I don't think there's much reason
to change that major number when the whole error case seems to have
been largely a mistake to begin with.
Linus
Powered by blists - more mailing lists