* Re: [Bug 213785] New: hugetlbfs scrambles mode when sticky bit is set
[not found] <bug-213785-27@https.bugzilla.kernel.org/>
@ 2021-07-20 22:07 ` Andrew Morton
2021-07-21 4:38 ` Mike Kravetz
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Morton @ 2021-07-20 22:07 UTC (permalink / raw)
To: bugs+kernel.org; +Cc: bugzilla-daemon, linux-mm
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 19 Jul 2021 15:34:00 +0000 bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=213785
>
> Bug ID: 213785
> Summary: hugetlbfs scrambles mode when sticky bit is set
> Product: Memory Management
> Version: 2.5
> Kernel Version: >4.19 (certainly >= 5.4)
> Hardware: All
> OS: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> Assignee: akpm@linux-foundation.org
> Reporter: bugs+kernel.org@dtnr.ch
> 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).
>
> --
> You may reply to this email to add a comment.
>
> You are receiving this mail because:
> You are the assignee for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bug 213785] New: hugetlbfs scrambles mode when sticky bit is set
2021-07-20 22:07 ` [Bug 213785] New: hugetlbfs scrambles mode when sticky bit is set Andrew Morton
@ 2021-07-21 4:38 ` Mike Kravetz
2021-07-21 7:59 ` [Bug 213785] New: hugetlbfs: interprets mode as decimal (was: hugetlbfs scrambles mode when sticky bit is set) Dennis Camera
2021-07-21 11:57 ` [Bug 213785] New: hugetlbfs scrambles mode when sticky bit is set Matthew Wilcox
0 siblings, 2 replies; 5+ messages in thread
From: Mike Kravetz @ 2021-07-21 4:38 UTC (permalink / raw)
To: Andrew Morton, bugs+kernel.org, David Howells, Al Viro
Cc: bugzilla-daemon, linux-mm
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bug 213785] New: hugetlbfs: interprets mode as decimal (was: hugetlbfs scrambles mode when sticky bit is set)
2021-07-21 4:38 ` Mike Kravetz
@ 2021-07-21 7:59 ` Dennis Camera
2021-07-21 11:57 ` [Bug 213785] New: hugetlbfs scrambles mode when sticky bit is set Matthew Wilcox
1 sibling, 0 replies; 5+ messages in thread
From: Dennis Camera @ 2021-07-21 7:59 UTC (permalink / raw)
To: Mike Kravetz, Andrew Morton, David Howells, Al Viro
Cc: bugzilla-daemon, linux-mm
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bug 213785] New: hugetlbfs scrambles mode when sticky bit is set
2021-07-21 4:38 ` Mike Kravetz
2021-07-21 7:59 ` [Bug 213785] New: hugetlbfs: interprets mode as decimal (was: hugetlbfs scrambles mode when sticky bit is set) Dennis Camera
@ 2021-07-21 11:57 ` Matthew Wilcox
2021-07-21 17:48 ` Mike Kravetz
1 sibling, 1 reply; 5+ messages in thread
From: Matthew Wilcox @ 2021-07-21 11:57 UTC (permalink / raw)
To: Mike Kravetz
Cc: Andrew Morton, bugs+kernel.org, David Howells, Al Viro,
bugzilla-daemon, linux-mm
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)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bug 213785] New: hugetlbfs scrambles mode when sticky bit is set
2021-07-21 11:57 ` [Bug 213785] New: hugetlbfs scrambles mode when sticky bit is set Matthew Wilcox
@ 2021-07-21 17:48 ` Mike Kravetz
0 siblings, 0 replies; 5+ messages in thread
From: Mike Kravetz @ 2021-07-21 17:48 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Andrew Morton, bugs+kernel.org, David Howells, Al Viro,
bugzilla-daemon, linux-mm
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-07-21 17:48 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-213785-27@https.bugzilla.kernel.org/>
2021-07-20 22:07 ` [Bug 213785] New: hugetlbfs scrambles mode when sticky bit is set Andrew Morton
2021-07-21 4:38 ` Mike Kravetz
2021-07-21 7:59 ` [Bug 213785] New: hugetlbfs: interprets mode as decimal (was: hugetlbfs scrambles mode when sticky bit is set) Dennis Camera
2021-07-21 11:57 ` [Bug 213785] New: hugetlbfs scrambles mode when sticky bit is set Matthew Wilcox
2021-07-21 17:48 ` Mike Kravetz
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.