public inbox for [email protected]
 help / color / mirror / Atom feed
From: Daniele Salvatore Albano <[email protected]>
To: Pavel Begunkov <[email protected]>
Cc: Victor Stewart <[email protected]>, io-uring <[email protected]>
Subject: Re: [Bug] io_uring_register_files_update broken
Date: Thu, 1 Jul 2021 17:01:43 +0300	[thread overview]
Message-ID: <CAKq9yRgJFU84ZqjA_05WBs9J5NQnH1c4G+NUXj41mV_v+wDJ5Q@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>

On Thu, 1 Jul 2021 at 00:28, Pavel Begunkov <[email protected]> wrote:
>
> On 6/30/21 10:14 PM, Victor Stewart wrote:
> > i'm fairly confident there is something broken with
> > io_uring_register_files_update,
> > especially the offset parameter.
> >
> > when trying to update a single fd, and getting a successful result of
> > 1, proceeding
> > operations with IOSQE_FIXED_FILE fail with -9. but if i update all of
> > the fds with
> > then my recv operations succeed, but close still fails with -9.
> >
> > on Clear LInux 5.12.13-1050.native
>
> Thanks for letting know, I'll take a look
>
>
> > here's a diff for liburing send_recv test, to demonstrate this.
> >
> > diff --git a/test/send_recv.c b/test/send_recv.c
> > index 19adbdd..492b591 100644
> > --- a/test/send_recv.c
> > +++ b/test/send_recv.c
> > @@ -27,6 +27,8 @@ static char str[] = "This is a test of send and recv
> > over io_uring!";
> >  #      define io_uring_prep_recv io_uring_prep_read
> >  #endif
> >
> > +static int *fds;
> > +
> >  static int recv_prep(struct io_uring *ring, struct iovec *iov, int *sock,
> >                      int registerfiles)
> >  {
> > @@ -54,17 +56,28 @@ static int recv_prep(struct io_uring *ring, struct
> > iovec *iov, int *sock,
> >                 goto err;
> >         }
> >
> > +       fds = malloc(100 * sizeof(int));
> > +       memset(fds, 0xff, sizeof(int) * 100);
> > +
> >         if (registerfiles) {
> > -               ret = io_uring_register_files(ring, &sockfd, 1);
> > +               ret = io_uring_register_files(ring, fds, 100);
> >                 if (ret) {
> >                         fprintf(stderr, "file reg failed\n");
> >                         goto err;
> >                 }
> > -               use_fd = 0;
> > -       } else {
> > -               use_fd = sockfd;
> > +
> > +               fds[sockfd] = sockfd;
> > +               int result = io_uring_register_files_update(ring,
> > sockfd, fds, 1);
> > +
> > +               if (result != 1)
> > +               {
> > +                       fprintf(stderr, "file update failed\n");
> > +                       goto err;
> > +               }
> >         }
> >
> > +       use_fd = sockfd;
> > +
> >         sqe = io_uring_get_sqe(ring);
> >         io_uring_prep_recv(sqe, use_fd, iov->iov_base, iov->iov_len, 0);
> >         if (registerfiles)
> >
>
> --
> Pavel Begunkov
I sent an email a while ago to raise a question about a potential bug
related to close.

Looks like the close doesn't support registered files (although I saw
some code within a patch from Jens to fix it while I was
investigating).

Attached below

On Fri, 21 May 2021 at 21:28, Daniele Salvatore Albano
<[email protected]> wrote:
>
> Hi,
>
> Is there any specific reason for which io_close_prep returns EBADF if
> using REQ_F_FIXED_FILE?
>
> I discovered my software was failing to close sockets when using fixed
> files a while ago but I put it to the side, initially thinking it was
> a bug I introduced in my code.
> In recent days I picked it up again and after investigating it, it
> looks like that, instead, that's the expected behaviour.
>
> From what I see, although the behaviour was slightly changed with a
> couple of commits (ie. with
> https://github.com/torvalds/linux/commit/cf3040ca55f2085b0a372a620ee2cb93ae19b686
> ) the io_close_prep have had this behaviour from the very beginning
> https://github.com/torvalds/linux/commit/b5dba59e0cf7e2cc4d3b3b1ac5fe81ddf21959eb
> .
>
> @Jens during my researches I have also found
> https://lkml.org/lkml/2020/5/7/1575 where there is a patch that
> allows, at least from what it looks like at a first glance, fixed
> files with io_close_prep but seems that the email thread died there.
>
> Shouldn't the close op match the behaviour of the other I/O related
> ops when it comes to fds?
>
> If there aren't specific reasons, happy to look into it and write a patch.
>
>
> Thanks,
> Daniele

  reply	other threads:[~2021-07-01 14:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-30 21:14 [Bug] io_uring_register_files_update broken Victor Stewart
2021-06-30 21:27 ` Pavel Begunkov
2021-07-01 14:01   ` Daniele Salvatore Albano [this message]
2021-07-01 14:31     ` Pavel Begunkov
2021-07-01 14:50 ` Pavel Begunkov
2021-07-01 15:46   ` Victor Stewart
2021-07-02  0:20     ` Pavel Begunkov

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=CAKq9yRgJFU84ZqjA_05WBs9J5NQnH1c4G+NUXj41mV_v+wDJ5Q@mail.gmail.com \
    [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