| Message ID | 165637625215.37717.9592144816249092137.stgit@donald.themaw.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | vfs: fix a couple of mount table handling problems | expand |
On Tue, Jun 28, 2022 at 08:30:52AM +0800, Ian Kent wrote: > Parsing an fs string that has zero length should result in the parameter > being set to NULL so that downstream processing handles it correctly. > For example, the proc mount table processing should print "(none)" in > this case to preserve mount record field count, but if the value points > to the NULL string this doesn't happen. Hmmm... And what happens if you feed that to ->parse_param(), which calls fs_parse(), which decides that param->key looks like a name of e.g. u32 option and calls fs_param_is_u32() to see what's what? OOPS is a form of rejection, I suppose, but...
On 29/6/22 01:55, Al Viro wrote: > On Tue, Jun 28, 2022 at 08:30:52AM +0800, Ian Kent wrote: >> Parsing an fs string that has zero length should result in the parameter >> being set to NULL so that downstream processing handles it correctly. >> For example, the proc mount table processing should print "(none)" in >> this case to preserve mount record field count, but if the value points >> to the NULL string this doesn't happen. > Hmmm... And what happens if you feed that to ->parse_param(), which > calls fs_parse(), which decides that param->key looks like a name of e.g. > u32 option and calls fs_param_is_u32() to see what's what? OOPS is a form > of rejection, I suppose, but... Oh ... yes, would you be ok with an update that moves the "param.type = fs_value_is_string;" inside the above else clause? Ian
On 29/6/22 09:06, Ian Kent wrote: > > On 29/6/22 01:55, Al Viro wrote: >> On Tue, Jun 28, 2022 at 08:30:52AM +0800, Ian Kent wrote: >>> Parsing an fs string that has zero length should result in the >>> parameter >>> being set to NULL so that downstream processing handles it correctly. >>> For example, the proc mount table processing should print "(none)" in >>> this case to preserve mount record field count, but if the value points >>> to the NULL string this doesn't happen. >> Hmmm... And what happens if you feed that to ->parse_param(), which >> calls fs_parse(), which decides that param->key looks like a name of >> e.g. >> u32 option and calls fs_param_is_u32() to see what's what? OOPS is a >> form >> of rejection, I suppose, but... > > Oh ... yes, would you be ok with an update that moves the > > "param.type = fs_value_is_string;" inside the above else > > clause? Looks like I'll need to use a type other than fs_value_is_string so I can identify the case in those conversion functions when there's no value for the parameter. I'm tempted to use fs_value_is_flag since it's already present but a new type of fs_value_is_empty is probably better. What do you think about doing it like this and that type naming too? Ian
diff --git a/fs/fs_context.c b/fs/fs_context.c index 24ce12f0db32..4c735d0ce3cb 100644 --- a/fs/fs_context.c +++ b/fs/fs_context.c @@ -175,9 +175,13 @@ int vfs_parse_fs_string(struct fs_context *fc, const char *key, }; if (value) { - param.string = kmemdup_nul(value, v_size, GFP_KERNEL); - if (!param.string) - return -ENOMEM; + if (!v_size) + param.string = NULL; + else { + param.string = kmemdup_nul(value, v_size, GFP_KERNEL); + if (!param.string) + return -ENOMEM; + } param.type = fs_value_is_string; }
Parsing an fs string that has zero length should result in the parameter being set to NULL so that downstream processing handles it correctly. For example, the proc mount table processing should print "(none)" in this case to preserve mount record field count, but if the value points to the NULL string this doesn't happen. Signed-off-by: Ian Kent <raven@themaw.net> --- fs/fs_context.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)