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