On 7/21/21 4:57 AM, Matthew Wilcox wrote: > 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 >> >> 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) > Thanks Matthew! That looks to be exactly what is needed. -- Mike Kravetz
