From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) (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 4F6AB224D6 for ; Sun, 7 Jun 2026 22:16:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780870593; cv=none; b=QdU63NGTpDSSMtjDOETVII8zhG2vk9hAPYCayGtPyqrWmSUN1Y+nBo/VDOW6br3O+7z4g2pOvTibVhzjczOSqq2MIc/Fh6HhdMmZBOb7uFqO5V9mhDK95PWLTIBCIXXJgXGsV6oOmYjBhf3am83hpQYSFYXeBJzUQMaMuPtKL8k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780870593; c=relaxed/simple; bh=qR7CBVfGLJ+l3yhncFwZwl2bA7rd9F5cfCualskyvn4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hfm81bz+scmSD2Bhyx0tm40KD6wgeihDQ7UOLKuSta5+Mo1YBnTnGEWIYE4TeFY4tnr73psKZ6MneSRy1kxLUZO2wnTTVtDn8NwBG3bn+Ye1PKu55NYJCJbt41hfOp1mM6We3I2k7giBdDJ53kWfpQGv0/fyInc/0U6hdx3Zap0= 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=yx878YQa; arc=none smtp.client-ip=209.85.167.172 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="yx878YQa" Received: by mail-oi1-f172.google.com with SMTP id 5614622812f47-4865e953031so4131851b6e.0 for ; Sun, 07 Jun 2026 15:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20251104.gappssmtp.com; s=20251104; t=1780870591; x=1781475391; darn=vger.kernel.org; h=content-transfer-encoding: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; bh=psqd04aJkP7QA3jViji8W91dqePEua5iJRalD0aVCuA=; b=yx878YQasoUwNtvV+3rsQZ4opCqnIkkVIPqGaOo2TPkJ2b2M+fhGGEKZtIrjmR95Eb X+YDIXjpLgg7Z9qqoGatV391zURfR1OlDC3GIyVrta/vUO6g4LyCrxipzJmxKz7KF2Mj bAosA+An0lvhi27qw+cJTzy22f3E4X8ydm1EIMaZdqdMxGhXNs7txGbjexQrMJ3IwV/K wZNVqkFMsPFZl0waIHHdtlyj4xAfBzZK2I5s11lj8YJK8ZToaO1V8atl/rYUasWHH6D4 3cwSJ3/cEq0onIPWhvoXCg7JQMw6/ZGNH5kBq6u/rvHalBneTaA05Qp0cVc8YO/cInZm UDeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780870591; x=1781475391; h=content-transfer-encoding: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; bh=psqd04aJkP7QA3jViji8W91dqePEua5iJRalD0aVCuA=; b=MIuWemgVdL4rwJpHGaQu5hBs9xbhiPIv6biWCvNp3Mc4DZDQf4dyGzChC2iH2blESZ ppojiyCveQS29RG4Ky6lqBZjHKkwJGlbhCBRPgRAs/O6f+P6pOmAf/WYLlXvwQaj13aT 1Ap8G/NLbr5czzXckcIlxxjljuOP9QoECdR68/6/nSZv2v7mjcJj+ZIm0IUAes6vUQgX QISf4FSnPaZajHu4YcgG/zhfSdUfmXEsojVcTaE9wckYL0G1r0xnT0EV7aUe6vVfgBuo Y4/uOtzBA0kDj60xe0EZ2g9cxkRrKA/hptZ/dqg2rrtcpdUFwookpU7KOAtblvjRD3N5 vFAg== X-Forwarded-Encrypted: i=1; AFNElJ//MqpqGFFBjEnRKpQoUnHGzaYczYQ9wk/BqevGJ/Rs6ygVJPSRsJe/K142Dhi5E4eGxPHhFSznW0fjKKc=@vger.kernel.org X-Gm-Message-State: AOJu0YzHPoM9a81nax/2Brz9+yNjuMl8rRY3CjrW8Qy+pdVzb+Pwhgim Lmc7COEY91i5kanefth/yP59gfxHEVEXPpjPrff5292Ku4yPg0MsIvXHcHt78Kfy7e4= X-Gm-Gg: Acq92OGCPajHZ+3u5kCMDbbQuyS3yvml3XI4PjM6/cPRac/9LXX6TE+75gqweR1bcmD LnvWQkFGduTEKjyiIYKYJs/UtAbxosckmmo60V0EnoAnTtCCqkDpFFfivDXtODy6mRVGVu2JHr1 sq0+NGk0FXw0ySKf2IsbUAb7J8yAmMbwpBvriQUFcwFbULTJwVCV6ZgGz4nqq7c0BAdcbCrpDcI eY1sTuxwrb2r9mrpDOK1fiMPZRWgSWDhQ2njyOlU33NUjJfA65zWBeo7kV7JGfhNt7uJPPTKtiq iBSRReD42zDeO3EgVGZYWuatAfTWnZfK5cK+fIPyy8+CZXV2WSaVRQzJpSttsjrFiqdVsZ0ONU5 yt3VIVEpFkamGTrFfobJDeNt0xJcO39x5/xZULxpJ7+TtPFqcxvU93H3cxDv4mdY2b0cQzix+Cm tkweAGypmXACd5dpMmprKEGvIzhT8btamHLY4V7vi3ueU/tCrUPK27avowBQ9aQxp9l+fxX+yi0 mUfxCZVyWur0lwO/aYt X-Received: by 2002:a05:6808:144a:b0:485:7c72:bd08 with SMTP id 5614622812f47-48692f559c8mr4920542b6e.33.1780870591316; Sun, 07 Jun 2026 15:16:31 -0700 (PDT) Received: from [192.168.1.150] ([198.8.77.157]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e6e74696b7sm10900126a34.3.2026.06.07.15.16.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2026 15:16:30 -0700 (PDT) Message-ID: Date: Sun, 7 Jun 2026 16:16:30 -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] test/recv-bundle-pbuf-len-poison: add regression test for pbuf len corruption To: Nyakundi Emmanuel Cc: federico.brasili@gmail.com, io-uring@vger.kernel.org, linux-kernel@vger.kernel.org References: <1fd2ea63-c128-4641-9565-dbafd97de612@kernel.dk> <20260607221114.135950-1-nyariboemmanuel8@gmail.com> Content-Language: en-US From: Jens Axboe In-Reply-To: <20260607221114.135950-1-nyariboemmanuel8@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 6/7/26 4:10 PM, Nyakundi Emmanuel wrote: > A failed IORING_RECVSEND_BUNDLE receive on a non-INC provided-buffer > ring can persistently corrupt the buffer descriptor length. When the > receive fails with -EAGAIN, the kernel writes the requested length into > buf->len during buffer selection but never restores it on failure. > > A later unrelated IORING_OP_READ using the same buffer group then > consumes the corrupted length, returning fewer bytes than expected. > > This test reproduces the issue as reported by Federico Brasili. Thanks, but I already wrote one, which also tests the much more important aspect of the kernel change - that the reported CQE completion reports the right amount without truncating the buffer length when no bytes have been transferred. And once again, it's not _corrupting_ the buffer length. It's shrinking it, which is unexpected and should not happen, but there's no corruption taking place. I'm dubious on how much AI koolaid was used in reproducing the test case and report? That said, it is something we should fix, as the kernel should not be changing the buffer length for this case. -- Jens Axboe