Linux io-uring development
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: patches@lists.linux.dev, stable@vger.kernel.org,
	Maoyi Xie <maoyixie.tju@gmail.com>,
	Pavel Begunkov <asml.silence@gmail.com>,
	Maoyi Xie <maoyi.xie@ntu.edu.sg>,
	io-uring@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH AUTOSEL 7.0] io_uring/wait: honour caller's time namespace for IORING_ENTER_ABS_TIMER
Date: Wed, 19 Aug 2026 13:19:51 -0400	[thread overview]
Message-ID: <aoXlt3pcqsqfp52s@laps> (raw)
In-Reply-To: <afe1ad86-3454-4092-88d0-bd9753a1b2c8@kernel.dk>

On Sat, May 23, 2026 at 08:55:43AM -0600, Jens Axboe wrote:
>On 5/23/26 8:45 AM, Sasha Levin wrote:
>> On Sat, May 23, 2026 at 08:23:13AM -0600, Jens Axboe wrote:
>>> On 5/20/26 5:40 AM, Jens Axboe wrote:
>>>> On 5/20/26 5:18 AM, Sasha Levin wrote:
>>>>> From: Maoyi Xie <maoyixie.tju@gmail.com>
>>>>>
>>>>> [ Upstream commit 45d2b37a37ab98484693533496395c610a2cab96 ]
>>>>>
>>>>> io_uring_enter() with IORING_ENTER_ABS_TIMER takes an absolute
>>>>> timespec from the caller via ext_arg->ts. It arms an ABS mode
>>>>> hrtimer in __io_cqring_wait_schedule(). The conversion path in
>>>>> io_uring/wait.c parses ext_arg->ts inline rather than going
>>>>> through io_parse_user_time(). It therefore does not pick up the
>>>>> time namespace conversion added by the previous patch.
>>>>
>>>> Once again - If you auto-pick this one, please also do the other one in
>>>> the series, 9cc6bac1bebf8310d2950d1411a91479e86d69a1. Makes no sense to
>>>> do just one of them.
>>>
>>> And once again, no reply. What is going on with stable these days?
>>
>> Jens, as I've mentioned in the previous mail, I handle the AUTOSEL
>> mails weeks after I originally sent them out for reviews.
>
>And you think that's working fine? I would suggest that's a terrible
>process. How are maintainers supposed to deal with that? Patches x and y
>are autoselected and an email is sent out. Maintainers react to that,
>either saying "no don't pick X" or "if you pick Y, please also do Z".
>The expectation would then be a reply that says "ok, doing that" or
>whatever might be appropriate there. Instead, it's just silence. And now
>I have to follow-up MULTIPLE times to ensure the right thing is being
>done. We're about 2 weeks into this particular incidence, and
>hilariously, I still have no idea what the state is on your end. Did it
>get dropped? Did the other one I asked for get picked up? Nobody knows!

Hey Jens,

So I took some time to figure it out, and I want to try out a slightly different process to address the concerns you've raised.

Instead of weekly AUTOSEL dumps, I'm just going to do them for a given release
after Linus tags it (so I'm going to do all of 7.2 in one go), about a week
after the release, and targetting just the LTS trees to reduce the number of
commits we backport.

This will make it easier for me to handle the volume of mails, and also reduce
the number of reviews folks do since we can skip the most recent stable (not
LTS) tree.

What are your thoughts on this change?

-- 
Thanks,
Sasha

  parent reply	other threads:[~2026-08-19 17:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260520111944.3424570-1-sashal@kernel.org>
2026-05-20 11:18 ` [PATCH AUTOSEL 7.0-6.6] io_uring: hold uring_lock when walking link chain in io_wq_free_work() Sasha Levin
2026-05-20 11:18 ` [PATCH AUTOSEL 7.0] io_uring/wait: honour caller's time namespace for IORING_ENTER_ABS_TIMER Sasha Levin
2026-05-20 11:40   ` Jens Axboe
2026-05-23 14:23     ` Jens Axboe
2026-05-23 14:45       ` Sasha Levin
2026-05-23 14:55         ` Jens Axboe
2026-05-23 15:06           ` Sasha Levin
2026-08-19 17:19           ` Sasha Levin [this message]
2026-08-19 20:53             ` Jens Axboe
2026-05-20 11:19 ` [PATCH AUTOSEL 7.0] io_uring: defer linked-timeout chain splice out of hrtimer context Sasha Levin
2026-05-20 11:19 ` [PATCH AUTOSEL 7.0-6.18] io_uring: validate user-controlled cq.head in io_cqe_cache_refill() Sasha Levin
2026-05-20 11:19 ` [PATCH AUTOSEL 7.0] io_uring: hold uring_lock across io_kill_timeouts() in cancel path Sasha Levin
2026-05-20 11:19 ` [PATCH AUTOSEL 7.0-6.12] io_uring/fdinfo: translate SqThread PID through caller's pid_ns Sasha Levin
     [not found] <20260511221931.2370053-1-sashal@kernel.org>
2026-05-11 22:19 ` [PATCH AUTOSEL 7.0] io_uring/wait: honour caller's time namespace for IORING_ENTER_ABS_TIMER Sasha Levin
2026-05-12 15:47   ` Jens Axboe
2026-05-15 14:04     ` Jens Axboe
2026-05-15 14:11       ` Sasha Levin

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=aoXlt3pcqsqfp52s@laps \
    --to=sashal@kernel.org \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maoyi.xie@ntu.edu.sg \
    --cc=maoyixie.tju@gmail.com \
    --cc=patches@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    /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