Messages in this thread | | | Date | Wed, 19 Aug 2015 00:47:14 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH v2] devpts: allow mounting with uid/gid of uint32_t |
| |
On Wed, 19 Aug 2015 09:24:31 +0200 Dongsu Park <dpark@posteo.net> wrote:
> > unsigned long uidl; > > > > rc = kstrtoul(uidstr, 0, &uidl); > > uidval = uidl; > > That's a good point. I'll do it. > > > > + if (rc) > > > return -EINVAL; > > > > I don't get it. From my reading, kstrtouint->parse_integer() returns > > "number of characters parsed or -E". So this code won't work. But > > presumably it *does* work, so why? > > It's probably because kstrtouint() returns just 0 on success. > That's what functions in the call chain of kstrtouint() -> kstrtoull() -> > _kstrtoull() -> _parse_integer() are actually doing. > _parse_integer() actually returns rv, i.e. number of characters parsed. > But after that, if there's no error, _kstrtoull() simply returns 0.
whoa, wait, I was looking at the -mm tree which changes kstrtouint():
static inline int __must_check kstrtouint(const char *s, unsigned int base, unsigned int *res) { return parse_integer(s, base | PARSE_INTEGER_NEWLINE, res); }
and
* Return number of characters parsed or -E. ... */ #define parse_integer(s, base, val) \
Alexey, doesn't this mean that code which does
if (kstrtouint(...)) return -EFOO;
will break? Is it intended that parse_integer-convert-*.patch will fix every callsite in the kernel? If so, how do we know there haven't been concurrent additions in -next which need review/conversion? Let alone out-of-tree things...
| |