[PATCH 28/31] block: replace fmode_t with a block-specific type for block open flags
Christian Brauner
brauner at kernel.org
Wed Jun 7 05:47:06 PDT 2023
On Wed, Jun 07, 2023 at 02:16:58PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 07, 2023 at 11:21:14AM +0200, Christian Brauner wrote:
> > On Tue, Jun 06, 2023 at 09:39:47AM +0200, Christoph Hellwig wrote:
> > > The only overlap between the block open flags mapped into the fmode_t and
> > > other uses of fmode_t are FMODE_READ and FMODE_WRITE. Define a new
> >
> > and FMODE_EXCL afaict
>
> FMODE_EXCL isn't used outside the block layer and removed in the last
> patch.
>
> > > +blk_mode_t file_to_blk_mode(struct file *file)
> > > +{
> > > + blk_mode_t mode = 0;
> > > +
> > > + if (file->f_mode & FMODE_READ)
> > > + mode |= BLK_OPEN_READ;
> > > + if (file->f_mode & FMODE_WRITE)
> > > + mode |= BLK_OPEN_WRITE;
> > > + if (file->f_mode & FMODE_EXCL)
> > > + mode |= BLK_OPEN_EXCL;
> > > + if ((file->f_flags & O_ACCMODE) == 3)
> >
> > I really don't like magic numbers like this.
>
> I don't like them either, but this is just moved around and not new.
>
> > Groan, O_RDONLY being defined as 0 strikes again...
> > Becuase of this quirk we internally map
> >
> > O_RDONLY(0) -> FMODE_READ(1)
> > O_WRONLY(1) -> FMODE_WRITE(2)
> > O_RDWR(3) -> (FMODE_READ | FMODE_WRITE)
>
> O_RDWR is 2.
Yeah, that was a typo. See the other mail I sent right after:
https://lore.kernel.org/all/20230607-kribbeln-dilettanten-b901b57dd962@brauner
>
> > so checking for the raw 3 here is confusing in addition to being a magic
> > number as it could give the impression that what's checked here is
> > (O_WRONLY | O_RDWR) which doesn't make sense...
>
> Well, that is exactly what we check for. This is a 30-ish year old
> quirk only used in the floppy driver.
Ugh, it's f_flags. I misread that as f_mode...
This is rather ugly. Then please, make it explicit and check for
== (O_WRONLY | O_RDWR) and leave a brief comment.
Anything's better than that raw 3 in there. We just had fun with
figuring out why there was a raw coredump in fs/coredump.c 30 years
later.
More information about the linux-um
mailing list