From: Pavel Begunkov <asml.silence@gmail.com>
To: Jens Axboe <axboe@kernel.dk>, Victor Stewart <v@nametag.social>
Cc: io-uring <io-uring@vger.kernel.org>
Subject: Re: [BUG? liburing] io_uring_register_files_update with liburing 2.0 on 5.13.17
Date: Sun, 19 Sep 2021 12:56:03 +0100 [thread overview]
Message-ID: <370104bd-b78d-1730-e7f4-6ea7c5ad50ef@gmail.com> (raw)
In-Reply-To: <36866fef-a38f-9d7d-0c85-b4c37a8279ce@kernel.dk>
On 9/18/21 11:21 PM, Jens Axboe wrote:
> On 9/18/21 3:55 PM, Victor Stewart wrote:
>>> BTW, this could be incorporated into io_uring_register_files and
>>> io_uring_register_files_tags(), might not be a bad idea in general. Just
>>> have it check rlim.rlim_cur for RLIMIT_NOFILE, and if it's smaller than
>>> 'nr_files', then bump it. That'd hide it nicely, instead of throwing a
>>> failure.
>>
>> the implicit bump sounds like a good idea (at least in theory?).
>
> Can you try current liburing -git? Remove your own RLIMIT_NOFILE and
> just verify that it works. I pushed a change for it.
Sounds like it pretty easy can be a very unexpected behaviour. Do many
libraries / etc. implicitly tinker with it?
>> another thing i think might be a good idea is an io_uring
>> change/migration log that we update with every kernel release covering
>> new features but also new restrictions/requirements/tweaks etc.
>
> Yes, that is a good idea. The man pages do tend to reference what
> version included what, but a highlight per release would be a great idea
> to have without having to dig for it.
>
>> something that would take 1 minute to skim and see if relevant.
>>
>> because at this point to stay fully updated requires reading all of the
>> mailing list or checking pulls on your branch + running to binaries
>> to see if anything breaks.
>
> Question is where to post it? Because I would post it here anyway...
Good idea. We need it in a single file to be useful
liburing/changelog.txt?
--
Pavel Begunkov
next prev parent reply other threads:[~2021-09-19 11:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-18 13:41 [BUG? liburing] io_uring_register_files_update with liburing 2.0 on 5.13.17 Victor Stewart
2021-09-18 14:41 ` Jens Axboe
2021-09-18 20:13 ` Victor Stewart
2021-09-18 20:26 ` Jens Axboe
2021-09-18 20:38 ` Jens Axboe
2021-09-18 21:55 ` Victor Stewart
2021-09-18 22:21 ` Jens Axboe
2021-09-18 23:19 ` Victor Stewart
2021-09-18 23:23 ` Victor Stewart
2021-09-18 23:37 ` Jens Axboe
2021-09-18 23:40 ` Jens Axboe
2021-09-19 4:15 ` Vito Caputo
2021-09-19 14:16 ` Jens Axboe
2021-09-20 12:51 ` Victor Stewart
2021-09-20 13:10 ` Jens Axboe
2021-09-20 13:19 ` Victor Stewart
2021-09-19 11:56 ` Pavel Begunkov [this message]
2021-09-19 14:24 ` Jens Axboe
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=370104bd-b78d-1730-e7f4-6ea7c5ad50ef@gmail.com \
--to=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=v@nametag.social \
/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;
as well as URLs for NNTP newsgroup(s).