On 12/24/24 9:49 PM, kernel test robot wrote:
Hello,
kernel test robot noticed "libhugetlbfs-test.32bit.gethugepagesizes.fail" on:
commit: d4849629a4b7dcc73764f273e1879e76497acdc7 ("libfs: Replace simple_offset end-of-directory detection")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
[test failed on linux-next/master 8155b4ef3466f0e289e8fcc9e6e62f3f4dceeac2]
in testcase: libhugetlbfs-test
version: libhugetlbfs-test-x86_64-6ddbae4-1_20241102
with following parameters:
pagesize: 2MB
config: x86_64-rhel-9.4-func
compiler: gcc-12
test machine: 128 threads 2 sockets Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz (Ice Lake) with 128G memory
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@xxxxxxxxx>
| Closes: https://lore.kernel.org/oe-lkp/202412251039.eec88248-lkp@xxxxxxxxx
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20241225/202412251039.eec88248-lkp@xxxxxxxxx
gethugepagesize (2M: 32): PASS
gethugepagesize (2M: 64): PASS
gethugepagesizes (2M: 32): FAIL rmdir /tmp/sysfs-fPtma7: Directory not empty <----
gethugepagesizes (2M: 64): PASS
I built libhugetlbfs on my Fedora 40 x86-64 system. The test results:
gethugepagesize (2M: 32): PASS
gethugepagesize (2M: 64): PASS
gethugepagesizes (2M: 32): FAIL rmdir /tmp/sysfs-LcBHPv: Directory not empty
gethugepagesizes (2M: 64): PASS
I also tested after restricting the directory offset range to
3..S32_MAX. All tests pass in that case.
DIR_OFFSET_MAX is returned as the cookie in the last entry in
a directory. The value of this symbolic constant is LONG_MAX.
I suspect that a directory cookie value of LONG_MAX (64-bit)
will be problematic for emulated 32-bit environments. Actually
any directory cookie value larger than U32_MAX is likely to
be difficult in this environment.
fsdevel gurus, any thoughts on how to remedy this?
--
Chuck Lever
