From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f46.google.com (mail-oo1-f46.google.com [209.85.161.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6CA0F2236EE for ; Wed, 19 Aug 2026 20:53:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787172838; cv=none; b=i2AEEOMximC2InS2GQ0zB3QitT9FreXFO9yu/35bwBUuEhfM5WK3Bc/UK/ut8LdAu7ZNU16i5UaWr3owq3HPWSAgkzrNRobZDNDbdB4lZz178/ZNaprtmN0XDECuJ2T/8DcYYOfAti/pdS21zluD+G4CBhC24Arcq8lQleijLF4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787172838; c=relaxed/simple; bh=9COjZBjMNWPO66tZjXBlEbkfK1lABv+uJewU4IkvCLA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=R7Zl8XGd58qsKw6axlbg/SuHtHS9JRq/S9qfaqRceV/e/sOUFDsSNyrdHHlfePEYf5YxSkHwTpkJ0ViROIwcRlhqlMeHJYMphAwdeY27hCC5Mrgcyb6o+lo2vDlEYXVXTNU4Q9vM1MXQzkCWSghy3adtuNiM3ycdS+unN7s715s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20251104.gappssmtp.com header.i=@kernel-dk.20251104.gappssmtp.com header.b=h/HxTYnN; arc=none smtp.client-ip=209.85.161.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel-dk.20251104.gappssmtp.com header.i=@kernel-dk.20251104.gappssmtp.com header.b="h/HxTYnN" Received: by mail-oo1-f46.google.com with SMTP id 006d021491bc7-6ac83a09781so138901eaf.1 for ; Wed, 19 Aug 2026 13:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20251104.gappssmtp.com; s=20251104; t=1787172835; x=1787777635; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=PpLEkKOKUwZ5t98OnGDW7134XoHRGbaaW2RNRtHE9rc=; b=h/HxTYnNJYJN9HTajfGS/sMJboOH7uF8/GNT9stKPox2vaDuTILy+eAOK1Dgt2JqmO UEtqSh1VQDWKMInax+o5x8kJMxLjRnt3qiOP9JHPjbY/PrjJsdnP7i72OYCmxbAjySC6 KVKYnE0KUnTi6hcH8UM2gxpjCqBW6B26YfNXWt+AdswlDz7ieqa0+0qTPCFRaeXdn7GP oAIfbZn6NEBBB6IQk2z0xPBfpFrku3itSbXJpUXHboBogO7kluu6uzK7VOHkXBcZms2D NiwyBCVRQpQ+NSLzWCyCoDcYyvCKZLsQ+jAQ/ct6xlKIbWcq11HfiEeINadqslM9lPzK j53A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787172835; x=1787777635; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=PpLEkKOKUwZ5t98OnGDW7134XoHRGbaaW2RNRtHE9rc=; b=GbuONI8BTJZkVhe9z8wRIsil+skLvxhEGk37Zk2huioiRHkLQ6I7Jz6IrIAiBasuth HLY3CzKTd6CnGiEFHWf9RP5DFkJRZ+/RN70kvAOf9G7tqJMud2Nr/ju9im8stcADQV6P 7GKZs92ko6WvbIMlfhCOZTW+ttcWr0heXKfllYw265DyuOWw1fMsdTHahG0EW6LwhyAB SAyNFA9NOS50bN2Xq9GUVq4vx+yN0Cv48aLtWy8lCPaVLep7WCqLHtR4WpWiIc0hdo3j 3tx+IGZ3mzrV1ATaErmtwrview3gRh8uzZcY38NAnlKNdGAiFXjvYmvMBsgLUcFm1OL6 Q1bQ== X-Forwarded-Encrypted: i=1; AHgh+RoPOmcX5WilcHaPt8gFF0ghZK38Gl+6eVzkD5i8tiBC6LGQDhzkU8M5XkC9tw85K8v5rXvehAi+sJu0LJI=@vger.kernel.org X-Gm-Message-State: AOJu0YyeWf7ENdU1uZS6S0ZraQJbD0c0INuZfHCBkpW1wDFmZGgPRG48 MPSlJEwjpempjlgLrIPWAV/BmcXwvjI/saBDUaVmDOJzsYcIqoJV8P6+Z+neK2Hvp7Y= X-Gm-Gg: AR+sD11Ox7PZEOgt1oOeUJmkiSRCAp+Tluzb0nIgao8XGnhm6O1WPW1YAq9kYxxWfEu iva4+JNpEiwYFCqq0PFa2198BB5QsGDzQn67XSHQ417l9ThN1hRvsZbfGP2w6E9uVXaARgwSrHb gRZwKKP4rK55d47KGrVUPQYLknBht3drOJILuwl5WSsArXpIydoeI3OU7sj9nLGDwQPqwiPJ302 X8sXvrSYrno9cBit+kWQC4mXQ0YL3L3UTGw/zCyQDobSy4RrBGAszqs7uTHlgDGbQ4VheIqz4Cg wQ9kOkIGq8TJFUVFFsTtAxA5RON2Yl8W6QhvFQJQfWliOJZ7XYmERBMg5Sv6UCLws6nWNVo8TnD HmYk0MAcyA+rIy2OuUiCRGQPP0c2IPnyAw/cNdybDxc18nTgcaQsZOOIfDf/t1O4TCIU35kH2cZ P64TcwSdcbAAlj6J3XfulIBYbBnCjN7XZ3FqjfFeNL0CkSjuB1rj0N9GN+xB/X5ZQu5cpmsI3vc ceDNScgiJxflvIiJ4nNDLIfJE5w6pQGV4iXNRABaizLL2gOaO8= X-Received: by 2002:a05:6820:2211:b0:6b1:3270:23b1 with SMTP id 006d021491bc7-6b148fe8629mr1648344eaf.5.1787172835333; Wed, 19 Aug 2026 13:53:55 -0700 (PDT) Received: from [192.168.1.102] ([96.43.243.2]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-6b13cb51ebdsm2839413eaf.3.2026.08.19.13.53.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Aug 2026 13:53:53 -0700 (PDT) Message-ID: <8671f4fb-e9fd-4f1a-bb2d-bfba7bf1bceb@kernel.dk> Date: Wed, 19 Aug 2026 14:53:52 -0600 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH AUTOSEL 7.0] io_uring/wait: honour caller's time namespace for IORING_ENTER_ABS_TIMER To: Sasha Levin Cc: patches@lists.linux.dev, stable@vger.kernel.org, Maoyi Xie , Pavel Begunkov , Maoyi Xie , io-uring@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260520111944.3424570-1-sashal@kernel.org> <20260520111944.3424570-26-sashal@kernel.org> <5a50c3f5-a5ef-4b2b-821c-5858d8b1ac13@kernel.dk> <8e853555-604e-46e5-8e25-a5f80b88e51c@kernel.dk> Content-Language: en-US From: Jens Axboe In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 8/19/26 11:19 AM, Sasha Levin wrote: > 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 >>>>>> >>>>>> [ 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. Appreciate it! > 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? I think that sounds like a great move in the right direction. As you probably recall, one of my big objections was lack of response when issues were flagged. If one per cycle makes that easier for you to deal with, then I'm all for it. Ideally I'd want AUTOSEL to work _exactly_ like the other patches that were grabbed for that stable release. Sent out the same way, at the same time, and responsive when issues are raised. If you only want to do one AUTOSEL per cycle, then IMHO it should be timed with the regular sending out of patches picked for the next stable release. If we have 2 separate things going on still, then that's annoying for maintainers to deal with. If I was doing this, I'd have AUTOSEL be EXACTLY the same thing as normal stable picks, work the same way, with the only difference being that they would have the AUTOSEL marker in the subject line. -- Jens Axboe