Messages in this thread Patch in this message | | | Subject | Re: [PATCH v3] ucounts: add missing data type changes | From | Nathan Chancellor <> | Date | Wed, 4 Aug 2021 13:27:08 -0700 |
| |
Hi Eric,
On 8/4/2021 12:47 PM, Eric W. Biederman wrote: > Nathan Chancellor <nathan@kernel.org> writes: > >> On Fri, Jul 30, 2021 at 08:28:54AM +0200, Sven Schnelle wrote: >>> commit f9c82a4ea89c3 ("Increase size of ucounts to atomic_long_t") >>> changed the data type of ucounts/ucounts_max to long, but missed to >>> adjust a few other places. This is noticeable on big endian platforms >>> from user space because the /proc/sys/user/max_*_names files all >>> contain 0. >>> >>> Fixes: f9c82a4ea89c ("Increase size of ucounts to atomic_long_t") >>> Signed-off-by: Sven Schnelle <svens@linux.ibm.com> >> >> This patch in -next as commit e43fc41d1f7f ("ucounts: add missing data type >> changes") causes Windows Subsystem for Linux to fail to start: >> >> [error 0x8007010b when launching `wsl.exe -d Arch'] Could not access starting >> directory "\\wsl$\Arch\home\nathan" >> >> Specifically, it is the change to max_user_watches in >> fs/notify/inotify/inotify_user.c, as the below diff gets me back to working. >> Unfortunately, I have no additional information to offer beyond that as WSL's >> init is custom and closed source (as far as I am aware) and there are no real >> debugging utilities. > > Could you try this patch and tell us what value is being set? > > The only think I can imagine is that someone wants unlimited watches and > sets the value to a ridiculously large value and the interpretation of > that value winds up being different between int and long. > > This should allow you to read either dmesg or the kernel's log as it > boots up and see what value is being written. From there it should > be relatively straight forward to figure out what is going on.
I applied this diff on top of mine and running 'dmesg |& grep intvec' shows:
[ 0.282500] intvec: dmesg_restrict <- 0 [ 0.282510] intvec: max_user_watches <- 524288
This seems much smaller than INT_MAX so I am not sure how the value could be different between int and long but I am not at all familiar with the sysctl code.
More than happy to continue to test debug patches or provide any additional information as I can.
Cheers, Nathan
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c > index 272f4a272f8c..733c4cfa1f60 100644 > --- a/kernel/sysctl.c > +++ b/kernel/sysctl.c > @@ -975,6 +975,14 @@ int proc_dointvec_minmax(struct ctl_table *table, int write, > .min = (int *) table->extra1, > .max = (int *) table->extra2, > }; > +#if 1 > + size_t lenv = *lenp; > + if (write && (lenv > 0) && (lenv < INT_MAX)) { > + int len = lenv; > + printk(KERN_EMERG "intvec: %s <- %*.*s\n", > + table->procname, len, len, (char *)buffer); > + } > +#endif > return do_proc_dointvec(table, write, buffer, lenp, ppos, > do_proc_dointvec_minmax_conv, ¶m); > } >
| |