On Tue, Jul 20, 2021 at 09:38:48PM -0700, Mike Kravetz wrote: > 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? Probably should follow what shmem does: mm/shmem.c: fsparam_u32oct("mode", Opt_mode), (also several other filesystems)
