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
