Bugzilla – Bug 1219366
[Build 50.1] Sysctl_user_max_fanotify_marks changes from 16144 to 16140
Last modified: 2024-02-18 06:40:24 UTC
##Description The value below is different from the one from build 45.1 based on my test. [I used all sysctl parameters from build 45.1 as a baseline] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% # Test messages # Sysctl_user_max_fanotify_marks # failure: expected: 16144 returned: 16140 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Can I ask for dev's kindly help to double check if it is expected value? ## Observation openQA test in scenario sle-15-SP6-Online-x86_64-sles-sys-param-check@64bit fails in [Sysctl](https://openqa.suse.de/tests/13365481/modules/Sysctl/steps/935) ## Test suite description https://gitlab.suse.de/qa-css/sys-param-check ## Reproducible Fails since (at least) Build [47.2](https://openqa.suse.de/tests/13320150) ## Expected result Last good: (unknown) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Online&machine=64bit&test=sles-sys-param-check&version=15-SP6)
I am not sure we can get fix precise number for user_max_fanotify_marks, current case will broken sooner or later when kernel make update on memory/inode related implementation or some config change(Lead inode size change). Following parameters used for calculate the user_max_fanotify_marks: -qemu's ram size -high memory size(config or not) -sizeof(struct inode) Kernel code part(If i guess correctly): static int __init fanotify_user_setup(void) { struct sysinfo si; int max_marks; si_meminfo(&si); /* * Allow up to 1% of addressable memory to be accounted for per user * marks limited to the range [8192, 1048576]. mount and sb marks are * a lot cheaper than inode marks, but there is no reason for a user * to have many of those, so calculate by the cost of inode marks. */ max_marks = (((si.totalram - si.totalhigh) / 100) << PAGE_SHIFT) / INODE_MARK_COST; max_marks = clamp(max_marks, FANOTIFY_OLD_DEFAULT_MAX_MARKS, FANOTIFY_DEFAULT_MAX_USER_MARKS); ... init_user_ns.ucount_max[UCOUNT_FANOTIFY_MARKS] = max_marks; ```
(In reply to WEI GAO from comment #1) > I am not sure we can get fix precise number for user_max_fanotify_marks, > current case will broken sooner or later when kernel make update on > memory/inode related implementation or some config change(Lead inode size > change). I agree that we cannot use a fixed value due to the reason above. The small fraction like this report is expected among different kernels and configs, and it must be acceptable. Adding Goldwyn to Cc, in case filesystem team can take a deeper look.
As Wei Gao pointed out in comment#1 , assuming a specific 16024%0.5 value without taking into account system memory metrics (and upper/lower bounds) used by the kernel doesn't make much sense as a unit test. I propose that the test is changed to merely check that the value lies within the clamp(FANOTIFY_OLD_DEFAULT_MAX_MARKS, FANOTIFY_DEFAULT_MAX_USER_MARKS) range, e.g.: --- a/tests/sles-15-SP6/sysctl.robot +++ b/tests/sles-15-SP6/sysctl.robot @@ -1910,8 +1910,8 @@ Sysctl_net_ipv6_icmp_error_anycast_as_unicast Sysctl_user_max_fanotify_groups Sysctl Check Param Int user.max_fanotify_groups 128 Sysctl_user_max_fanotify_marks - [Documentation] Depends of the RAM resources bsc#1183339#c11 - Sysctl Check Param Int user.max_fanotify_marks 16144 + [Documentation] Depends of the RAM resources bsc#1183339#c11 bsc#1219366 + Sysctl Check Param Int user.max_fanotify_marks 8192 1048576 Sysctl_user_max_inotify_instances Sysctl Check Param Int user.max_inotify_instances 128 Sysctl_user_max_inotify_watches
(In reply to David Disseldorp from comment #5) > As Wei Gao pointed out in comment#1 , assuming a specific 16024%0.5 value > without taking into account system memory metrics (and upper/lower bounds) > used by the kernel doesn't make much sense as a unit test. Actually it's only the Tumbleweed/sysctl.robot that carries the +-%0.5 threshold. sles-15-SP6/sysctl.robot is fixed at 16144. > > I propose that the test is changed to merely check that the value lies > within the clamp(FANOTIFY_OLD_DEFAULT_MAX_MARKS, > FANOTIFY_DEFAULT_MAX_USER_MARKS) range, e.g.: Proposed upstream via https://github.com/ddiss/sys-param-check/pull/new/sysctl_fanotify
Thanks all for your kindly help! https://github.com/openSUSE/sys-param-check/pull/13, the test passed with the changes now http://openqa.suse.de/tests/13539531