public inbox for [email protected]
 help / color / mirror / Atom feed
From: Dylan Yudaken <[email protected]>
To: "[email protected]" <[email protected]>,
	"[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>,
	"[email protected]" <[email protected]>,
	"[email protected]" <[email protected]>,
	"[email protected]" <[email protected]>,
	"[email protected]" <[email protected]>
Subject: Re: Linux 5.19-rc7 liburing test `poll-mshot-overflow.t` and `read-write.t` fail
Date: Thu, 21 Jul 2022 09:48:31 +0000	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On Thu, 2022-07-21 at 06:21 +0700, Ammar Faizi wrote:
> Hello Jens,
> 
> Kernel version:
> 
>    commit ff6992735ade75aae3e35d16b17da1008d753d28
>    Author: Linus Torvalds <[email protected]>
>    Date:   Sun Jul 17 13:30:22 2022 -0700
> 
>        Linux 5.19-rc7
> 
> liburing version:
> 
>    commit 4e6eec8bdea906fe5341c97aef96986d605004e9 (HEAD,
> origin/master, origin/HEAD)
>    Author: Dylan Yudaken <[email protected]>
>    Date:   Mon Jul 18 06:34:29 2022 -0700
> 
>        fix io_uring_recvmsg_cmsg_nexthdr logic
>        
>        io_uring_recvmsg_cmsg_nexthdr was using the payload to
> delineate the end
>        of the cmsg list, but really it needs to use whatever was
> returned by the
>        kernel.
>        
>        Reported-and-tested-by: Jens Axboe <[email protected]>
>        Fixes: 874406f7fb09 ("add multishot recvmsg API")
>        Signed-off-by: Dylan Yudaken <[email protected]>
>        Link:
> https://lore.kernel.org/r/[email protected]
>        Signed-off-by: Jens Axboe <[email protected]>
> 
> Two liburing tests fail:
> 
>    Tests failed:  <poll-mshot-overflow.t> <read-write.t>
>    make[1]: *** [Makefile:237: runtests] Error 1
>    make[1]: Leaving directory '/home/ammarfaizi2/app/liburing/test'
>    make: *** [Makefile:21: runtests] Error 2
> 
> 
>    ammarfaizi2@integral2:~/app/liburing$ uname -a
>    Linux integral2 5.19.0-rc7-2022-07-18 #1 SMP PREEMPT_DYNAMIC Mon
> Jul 18 15:42:27 WIB 2022 x86_64 x86_64 x86_64 GNU/Linux
>    ammarfaizi2@integral2:~/app/liburing$ test/read-write.t
>    cqe res -22, wanted 8192
>    test_buf_select vec failed

What fs are you using? testing on a fresh XFS fs read-write.t works for
me

>    ammarfaizi2@integral2:~/app/liburing$ test/poll-mshot-overflow.t
>    signalled no more!
>    ammarfaizi2@integral2:~/app/liburing$
> 
> JFYI, -22 is -EINVAL.
> 
> read-write.t call trace when calling fprintf(..., "cqe res %d, wanted
> %d\n", ...):
> 
>    #0  ___fprintf_chk (./debug/fprintf_chk.c:25)
>    #1  fprintf (/usr/include/x86_64-linux-gnu/bits/stdio2.h:105)
>    #2  __test_io (read-write.c:181)
>    #3  test_buf_select (read-write.c:577)
>    #4  main (read-write.c:849)
> 
> poll-mshot-overflow.t call trace should be trivial.
> 


poll-mshot-overflow.t tests something that I changed in 5.20, but
actually I do not know if the fix should be backported. Do people have
an opinion here? The backport unfortunately looks like it might be
complex.

The test tests an edge condition with overflow and multishot polls.
Overflow will actually change the ordering of CQEs, such that you might
get a CQE without IORING_CQE_F_MORE and then later receive one with
IORING_CQE_F_MORE set.

This is a real problem for strict ordered API's like recv (which is why
I fixed it), but for poll it's unclear to me if it is a big enough
problem and needs backporting. Certainly I think it has been this way
for a long time and no one has complained?



  reply	other threads:[~2022-07-21  9:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-20 23:21 Linux 5.19-rc7 liburing test `poll-mshot-overflow.t` and `read-write.t` fail Ammar Faizi
2022-07-21  9:48 ` Dylan Yudaken [this message]
2022-07-21 10:41   ` Ammar Faizi
2022-07-21 12:05     ` Dylan Yudaken
2022-07-21 13:08       ` Ammar Faizi
2022-07-21 13:14         ` Dylan Yudaken

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3489ef4e810b822d6fdb0948ef7fdaeb5547eeba.camel@fb.com \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox