From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 DAE1246C4AE for ; Thu, 30 Jul 2026 19:16:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785438982; cv=none; b=Mf3dnKhFwOgzVsxLbftOGDvzDKi3eg+E2PSorDvrahS9flNl7v0+wcWJxxiA43JyE4luQJW0LfzRlfN7u7VPW9qmmYLimI1S+gINimKQblJhwMJqoCB0NRTDaCw7Hzz84iISToBvvFLVkpbriWr+HmU/VfVdwTI8cRim/sz1hD4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785438982; c=relaxed/simple; bh=5WHjlG72d+xJLtqAx/ToykbvdBP5gcv1x5UevJqlPeA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=onF2MDUSoU9xtOGJYfGlkIdm15HdSPevPBm3PjoS+AU5pINup+269J4XznfmNzcv1LT85V71F5gm6Q66SvNxKUA3WeUFBY7irX9lzLyGdNaKtGORSHKcxuSbIp6rDLvjJiarPkahjtoauNmHMluIYhjsIPtWqWOHLioA6Hp7lmU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=pWKLjyvU; arc=none smtp.client-ip=209.85.221.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pWKLjyvU" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-472326ca506so48463f8f.2 for ; Thu, 30 Jul 2026 12:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785438963; x=1786043763; 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=xgXPviuoYbN7EB9Py/8KZMntvbdaAe2VnJspeF2bwTo=; b=pWKLjyvUqApeKZOf+YV3YGlJ/HSoUaK8wo2zVPjscdGnrVJ1z5g7m5MWsWUYxXjb10 axNFTrZXmV0o+RjwAJvO5hhNIMs7CyCLf5fs/8YkLbG0POg/PiOpMwXT7aAJTZvI1GQO qAvLmCFJVm1dIqs0B1Ep7VMxIEjM/0W7UEMVlWFp7OHMfpooqXToGOgfxMiP8fuPc9nd r5nZjG0niVDQ0K3trP4RkwWxOZjHmvHrg555PpGCMSGVtnj2+nTvezYC1bEybthBfyHc BWcqiJarzZPljPZ4d0/I91NdcWJtceK0hdycu7mvmFH8FlqXhiYkPKc4S3+XF+O4pD2F LJhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785438963; x=1786043763; 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=xgXPviuoYbN7EB9Py/8KZMntvbdaAe2VnJspeF2bwTo=; b=EPZTE6OhtM8Y0jjlqQfOx1LVxAQseTFDy3JoItLrK13ncputJv/8lZZLK23Zhee/jr zEu0s1xdqIKHHLStwZfd1krlwr+jHZKfMW9cBmBvM6cx+2/F7oEJSSUF9JXqsGMOP6V+ UZuwTQvvzrJQ47ak/w3Wl+92b6zyXD8Kv3qKCrhQ8/+K4F34vjE0j7LS1rMJyXb1JAe1 Or7GrUEf54gjc41KnzWUoxVZbRiVEl3lyDTp+1JTcW6fjDbT/xe+fHAgueTdeoAqW3Qo BQK81ZxaFK72ERe98PBBL7trMkF+ckarHWqk1AdocKebkCaz6TFWTqv+P3VW0jKzEyxv MbEg== X-Forwarded-Encrypted: i=1; AHgh+RrDEXxRteTPSIC4NH0z/nxrBEsyIMSjqDLpWbD8LTv5YUT6cVC/PFK7+rX3Mt8vTWLlDn/55Oj91KoOwRY=@vger.kernel.org X-Gm-Message-State: AOJu0YyyhyDcJWIvM/DXyhCq/azcG80VCgWoxy7d8YByzMbGBHglcBP7 gm+tNORgXstiW6Wo8TSUXkFdbj3qKkilXQ03R7gnxFHoFl1MzHGD+/u4 X-Gm-Gg: AR+sD12sKsUFqhv4Oje4OUQF5YWdAcpRp6Od+9NyYmu0+O+D2BF42reT2h8IIpFr1sK VR5vQzcZOAawUtc5jR4NsqIsxEzj9KMTrBbpg+Bz8NrtrR6FJ/LFKfFqp/jKSlPhkKS0OZCL7S2 3y7tXcG6o3a3J8AM7tcmvdB+GcZArcpqrL7Q9VVUs4Jj0P43CADh4blVVEAw3cC+AAKIrPe0mIV D+R9edjcs4q3DfJEI4mzlubhU9WsHd03oLJXWMdZKt9vAVmp2M/49e+j55W5OlidQPOgDKzz7gt E3svvmDUIV+WOGWDlTeMXFN5wVu/bmvm2SZFxKHlsg+Qd9kCMQK/uDiOB217gKZZ1v+oqXWLaFd rdbjHGmL63xhdRfAcp00bs5UIAU3hp4ayGOcMbU1ynW1weMaJ27niu2zmOlM91+R3lOo7tUBIZI fqqwlqNe9790Xe97nDPXJVpYqy1w5lwqv8Fq7G3LJU9E048XqOTIwhRk0xb/zbbIL1HG/xBe75d LiDBKkVJR1v9YPG6oS3dO2otzDU5J5LveLY/4LWJygroTaV2cBInLr5xPndhwbcx4QI2/TJKLqX 0BQOLQ9HENRBHvoML8oRBZ4lmK4C+ZJLMGhlQlQ= X-Received: by 2002:adf:e18c:0:b0:47f:921f:3a35 with SMTP id ffacd0b85a97d-47fcbb4c6dcmr2947822f8f.37.1785438963078; Thu, 30 Jul 2026 12:16:03 -0700 (PDT) Received: from ?IPV6:2a01:4b00:bd21:4f00:7cc6:d3ca:494:116c? ([2a01:4b00:bd21:4f00:7cc6:d3ca:494:116c]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fc88d6e68sm8231813f8f.7.2026.07.30.12.16.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jul 2026 12:16:02 -0700 (PDT) Message-ID: <7cdc0130-6dca-4e18-8f0e-1e7221fb9853@gmail.com> Date: Thu, 30 Jul 2026 20:16:07 +0100 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] io_uring/zcrx: don't clear master_ctx from the import path To: Woraphat Khiaodaeng , Jens Axboe Cc: David Wei , io-uring@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260730162741.1125-1-worapat.kd2@gmail.com> Content-Language: en-US From: Pavel Begunkov In-Reply-To: <20260730162741.1125-1-worapat.kd2@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/30/26 17:27, Woraphat Khiaodaeng wrote: > import_zcrx() attaches an existing ifq to another ring. It never calls > zcrx_set_ring_ctx() and so never takes the ->master_ctx reference, but > its error path still passes @ctx to zcrx_unregister(), which clears > ->master_ctx and drops its percpu_ref whenever ifq->master_ctx == ctx. > > That condition is reachable. A ring that registers an ifq with a > non-zero event type_mask gets ->master_ctx pointed at itself, and > nothing stops it from exporting that ifq with ZCRX_CTRL_EXPORT and > importing the resulting fd back into the same ring. Failing the import > after the refcount bumps -- an argument page mapped PROT_READ makes the > copy_to_user() in import_zcrx() return -EFAULT -- then clears the > ->master_ctx owned by the original registration, which is still live. > > Refcounts stay balanced and nothing is freed early, so there is no > splat. The ring silently stops receiving ZCRX_EVENT_ALLOC_FAIL and > ZCRX_EVENT_COPY: zcrx_send_notif() returns early on a NULL > ->master_ctx, and ->master_ctx is only ever set on a freshly allocated > ifq, so it cannot be restored without tearing the ring down. Yep, it effectively disables event CQEs. Reviewed-by: Pavel Begunkov ...> diff --git a/io_uring/zcrx.c b/io_uring/zcrx.c > index 76b9b0d54af9e..fea2b27272ec2 100644 > --- a/io_uring/zcrx.c > +++ b/io_uring/zcrx.c > @@ -808,7 +808,8 @@ static int import_zcrx(struct io_ring_ctx *ctx, > scoped_guard(mutex, &ctx->mmap_lock) > xa_erase(&ctx->zcrx_ctxs, id); > err: > - zcrx_unregister(ifq, ctx); > + /* the import path never took the ->master_ctx ref, don't drop it */ nit: I'd say "... it never set ->master_ctx ..." as it's about having a ctx and not references, but it's not worth of respinning. > + zcrx_unregister(ifq, NULL); > return ret; > } -- Pavel Begunkov