Thread (67 messages) 67 messages, 9 authors, 2020-02-21

Re: [PATCH 01/19] vfs: syscall: Add fsinfo() to query filesystem information [ver #16]

From: Darrick J. Wong <hidden>
Date: 2020-02-20 15:31:34
Also in: linux-fsdevel, lkml

On Thu, Feb 20, 2020 at 03:54:25PM +0100, Jann Horn wrote:
On Thu, Feb 20, 2020 at 12:04 PM David Howells [off-list ref] wrote:
quoted
Jann Horn [off-list ref] wrote:
quoted
quoted
+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.
quoted
                        }
                        ret = len;
                }
                return ret;
        }
[...]
quoted
quoted
quoted
+       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.

[...]
quoted
quoted
quoted
+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.
I was thinking, why not just have unsigned int flags from the start?
That replaces the padding holes with usable flag space, though I guess
this is in-core only so I'm not that passionate.  I doubt we're going to
have millions of fsinfo attributes. :)

--D
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help