Re: [linux-next:master] [selftests] 5b45a75377: kernel-selftests.uevent.uevent_filtering.fail

[Javier Carrasco <javier.carrasco.cruz@gmail.com>]

Hi,

On 26.10.23 09:11, kernel test robot wrote:
> 
> 
> Hello,
> 
> kernel test robot noticed "kernel-selftests.uevent.uevent_filtering.fail" on:
> 
> commit: 5b45a753776be5d21cf395ec97e81c9187fbeaca ("selftests: uevent filtering: fix return on error in uevent_listener")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> 
> [test failed on linux-next/master 2030579113a1b1b5bfd7ff24c0852847836d8fd1]
> 
> in testcase: kernel-selftests
> version: kernel-selftests-x86_64-60acb023-1_20230329
> with following parameters:
> 
> 	group: group-03
> 
> 
> 
> compiler: gcc-12
> test machine: 36 threads 1 sockets Intel(R) Core(TM) i9-10980XE CPU @ 3.00GHz (Cascade Lake) with 32G memory
> 
> (please refer to attached dmesg/kmsg for entire log/backtrace)
> 
> 
> we also noticed this issue does not always happen. as below, we saw 15 failures
> out of 50 runs. however, parent keeps passing.
> 
> 
> 37013b557b7f39e6 5b45a753776be5d21cf395ec97e
> ---------------- ---------------------------
>        fail:runs  %reproduction    fail:runs
>            |             |             |
>            :50          30%          15:50    kernel-selftests.uevent.uevent_filtering.fail
> 
> 
> 
> 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@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202310261454.46082aaa-oliver.sang@intel.com
> 
> 
> 
> TAP version 13
> 1..1
> # timeout set to 300
> # selftests: uevent: uevent_filtering
> # TAP version 13
> # 1..1
> # # Starting 1 tests from 1 test cases.
> # #  RUN           global.uevent_filtering ...
> # add@/devices/virtual/mem/fullACTION=addDEVPATH=/devices/virtual/mem/fullSUBSYSTEM=memSYNTH_UUID=0MAJOR=1MINOR=7DEVNAME=fullDEVMODE=0666SEQNUM=3532
> # add@/devices/virtual/mem/fullACTION=addDEVPATH=/devices/virtual/mem/fullSUBSYSTEM=memSYNTH_UUID=0MAJOR=1MINOR=7DEVNAME=fullDEVMODE=0666SEQNUM=3546
> # add@/devices/virtual/mem/fullACTION=addDEVPATH=/devices/virtual/mem/fullSUBSYSTEM=memSYNTH_UUID=0MAJOR=1MINOR=7DEVNAME=fullDEVMODE=0666SEQNUM=3556
> # add@/devices/virtual/mem/fullACTION=addDEVPATH=/devices/virtual/mem/fullSUBSYSTEM=memSYNTH_UUID=0MAJOR=1MINOR=7DEVNAME=fullDEVMODE=0666SEQNUM=3585
> # add@/devices/virtual/mem/fullACTION=addDEVPATH=/devices/virtual/mem/fullSUBSYSTEM=memSYNTH_UUID=0MAJOR=1MINOR=7DEVNAME=fullDEVMODE=0666SEQNUM=3595
> # No buffer space available - Failed to receive uevent
> # # uevent_filtering.c:479:uevent_filtering:Expected 0 (0) == ret (-1)
> # # uevent_filtering: Test failed at step #10
> # #          FAIL  global.uevent_filtering
> # not ok 1 global.uevent_filtering
> # # FAILED: 0 / 1 tests passed.
> # # Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
> not ok 1 selftests: uevent: uevent_filtering # exit=1
> 
> 
> 
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20231026/202310261454.46082aaa-oliver.sang@intel.com
> 
> 
> 
What is apparently happening here is that the test returns now a proper
error value in the uevent_listener function. In this case recvmsg() is
returning ENOBUFS - No buffer space available. This occurs because
buf[_UEVENT_BUFFER_SIZE] is not big enough, being _UEVENT_BUFFER_SIZE =
(2048 *2).

Therefore the error is not in the fix commit as such because the error
was happening and it was not returned properly (previously ret was
assigned to -1 but it was not returned).

The obvious fix would be a larger buffer, but when I see de definition
of UEVENT_BUFFER_SIZE in kobject.h, its value is just 2048. Then I
wonder why 2048 *2 was used in the first place, why that is not enough
and what size is then meaningful.

After a quick search I found a discussion on Bugzilla about the
UEVENT_BUFFER_SIZE being resized to 4096:

https://bugzilla.kernel.org/show_bug.cgi?id=207695

But apparently it has not been resized upstream.

Best regards,
Javier Carrasco