Re: [Bug 213785] New: hugetlbfs scrambles mode when sticky bit is set

[Mike Kravetz <mike.kravetz@oracle.com>]

Add David, Al

On 7/20/21 3:07 PM, Andrew Morton wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=213785
>>
>>            Summary: hugetlbfs scrambles mode when sticky bit is set
>>            Product: Memory Management
>>            Version: 2.5
>>     Kernel Version: >4.19 (certainly >= 5.4)
>>         Regression: Yes
>>
>> I noticed the following strange behaviour with hugetlbfs mounts for kernel
>> versions something north of 4.19, but certainly since 5.4:
>>
>> when the mode= option of the mount has the sticky bit set, the mode of the
>> mount point gets scrambled.
>>
>> To test the following command line can be used:
>> mkdir -p /tmp/tlbtest && mount -t hugetlbfs -o mode=.... none /tmp/tlbtest &&
>> stat -c 'mode: %04a' /tmp/tlbtest
>>
>> For kernel versions <= 4.19 or if the first byte of mode is 0, stat outputs
>> what was set using "-o mode".
>>
>> But on newer kernel versions if the first byte of mode is 1 the output of stat
>> is as follows (input -> output):
>> 1700 -> 1244
>> 1750 -> 1326
>> 1770 -> 1352
>> 1775 -> 1357
>> 1777 -> 1361
>>
>> The behaviour is reproducible across different kernel versions and
>> architectures (5.4.47-amd64, 5.9.8-amd64, 5.10.40-ppc64el, 5.12.15-amd64).

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".

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.

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?  
-- 
Mike Kravetz