Re: [Bug 213785] New: hugetlbfs: interprets mode as decimal (was: hugetlbfs scrambles mode when sticky bit is set)

[Dennis Camera <bugs+kernel.org@dtnr.ch>]

Dear Mike,

On Tue, 20 Jul 2021 21:38 -0700 Mike Kravetz wrote:
> I took a quick look and believe a change in behavior was caused by
> commit 32021982a324 "Convert the hugetlbfs to use the fs_context
> during mount".

Thanks for taking a look at this issue and pointing to the commit that
introduced this change.
It looks credible.

> Prior to the commit, code processing the mode option used
> match_octal() to convert the command line string to a numeric value.
> Since match_octal expects a string representing an octal value, it
> does
> not require a leading '0'.  As a result, prior to this commit the
> argument 'mode=1700' would result in a mode value of 01700.  After
> the
> commit one must precede octal values with 0.  So, mode=1700 would
> result
> in a mode value of 03244 (& 01777U) = 1244.

I've been racking my brain trying to figure out what was going on, but
the solution is so simple…

> If my analysis is correct, I am not sure how to proceed.  IMO, the
> current behavior is 'more correct'.  However, until v5.1 a preceeding
> 0
> was not required when specifying mode for hugetlbfs.  So, this was
> certainly a change in behavior.  Suggestions?

Generally, I would agree that interpreting integers as decimals is the
correct way, but in the case of file modes I cannot remember having
used or seen modes in anything but octal over all the years I've been
working with Linux.

As I understand Documentation/admin-guide/mm/hugetlbpage.rst the mode
option should be interpreted as octal:
> The mode option sets [the mode] to value & 01777. This value is given
in octal. By default the value 0755 is picked.

Furthermore, I had a look at the POSIX documentation for chmod(1)
(https://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html)
which also interprets all integers as octals.

So my suggestion would be to convert the mode option to a
fsparam_u32oct and if possible backport this change to the supported
>=5.1 kernel versions.

Regards,
Dennis