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
