[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG48ez00KA3tjeccDCeqmgHyppTLEr+UkrB=QaQ-FX-cTY3aCA@mail.gmail.com>
Date: Thu, 20 Feb 2020 15:54:25 +0100
From: Jann Horn <jannh@...gle.com>
To: David Howells <dhowells@...hat.com>
Cc: Al Viro <viro@...iv.linux.org.uk>, raven@...maw.net,
Miklos Szeredi <mszeredi@...hat.com>,
Christian Brauner <christian@...uner.io>,
Linux API <linux-api@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 01/19] vfs: syscall: Add fsinfo() to query filesystem
information [ver #16]
On Thu, Feb 20, 2020 at 12:04 PM David Howells <dhowells@...hat.com> wrote:
> Jann Horn <jannh@...gle.com> wrote:
>
> > > +int fsinfo_string(const char *s, struct fsinfo_context *ctx)
> > ...
> > Please add a check here to ensure that "ret" actually fits into the
> > buffer (and use WARN_ON() if you think the check should never fire).
> > Otherwise I think this is too fragile.
>
> How about:
>
> int fsinfo_string(const char *s, struct fsinfo_context *ctx)
> {
> unsigned int len;
> char *p = ctx->buffer;
> int ret = 0;
> if (s) {
> len = strlen(s);
> if (len > ctx->buf_size - 1)
> len = ctx->buf_size;
> if (!ctx->want_size_only) {
> memcpy(p, s, len);
> p[len] = 0;
I think this is off-by-one? If len was too big, it is set to
ctx->buf_size, so in that case this effectively becomes
`ctx->buffer[ctx->buf_size] = 0`, which is one byte out of bounds,
right?
Maybe use something like `len = min_t(size_t, strlen(s), ctx->buf_size-1)` ?
Looks good apart from that, I think.
> }
> ret = len;
> }
> return ret;
> }
[...]
> > > + return ctx->usage;
> >
> > It is kind of weird that you have to return the ctx->usage everywhere
> > even though the caller already has ctx...
>
> At this point, it's only used and returned by fsinfo_attributes() and really
> is only for the use of the attribute getter function.
>
> I could, I suppose, return the amount of data in ctx->usage and then preset it
> for VSTRUCT-type objects. Unfortunately, I can't make the getter return void
> since it might have to return an error.
Yeah, then you'd be passing around the error separately from the
length... I don't know whether that'd make things better or worse.
[...]
> > > +struct fsinfo_attribute {
> > > + unsigned int attr_id; /* The ID of the attribute */
> > > + enum fsinfo_value_type type:8; /* The type of the attribute's value(s) */
> > > + unsigned int flags:8;
> > > + unsigned int size:16; /* - Value size (FSINFO_STRUCT) */
> > > + unsigned int element_size:16; /* - Element size (FSINFO_LIST) */
> > > + int (*get)(struct path *path, struct fsinfo_context *params);
> > > +};
> >
> > Why the bitfields? It doesn't look like that's going to help you much,
> > you'll just end up with 6 bytes of holes on x86-64:
>
> Expanding them to non-bitfields will require an extra 10 bytes, making the
> struct 8 bytes bigger with 4 bytes of padding. I can do that if you'd rather.
Wouldn't this still have the same total size?
struct fsinfo_attribute {
unsigned int attr_id; /* 0x0-0x3 */
enum fsinfo_value_type type; /* 0x4-0x7 */
u8 flags; /* 0x8-0x8 */
/* 1-byte hole */
u16 size; /* 0xa-0xb */
u16 element_size; /* 0xc-0xd */
/* 2-byte hole */
int (*get)(...); /* 0x10-0x18 */
};
But it's not like I really care about this detail all that much, feel
free to leave it as-is.
Powered by blists - more mailing lists