Bug 1219366

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