From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) (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 79D46339714 for ; Wed, 18 Feb 2026 16:23:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771431812; cv=none; b=FcV73t+RoNrU+FHWFdwXWFPMRM1dm8J+dtqMo6aBjqxvB/L33716njrXSG5Jk5LzGJ3poe74rZcKKYt5t5wtoqZb/vEL2A+ATmv9lPIr7X7SFI8gwuq6NZIl05+W+Ax9fOowpcFXXfjJhih5kJx5lRv5lOxD+zvYWqzxXnsm6Kw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771431812; c=relaxed/simple; bh=bfZFhcAHRhPkfVVfhaEXA5gLrHD+Zf+8i41XB0DkCqE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=MspA50+gNrzBVCALhRu/KD8VCqsU7c8CQzOYavwTSM2//udliWsS4ZEerPBgElia7Gyo3pHxmhMguCOapJN79Xgd/QAe0BLEMqeeAGoYKxaG5F/rLEWoEajGemghoHBgFaxin76rKXJvg4anJgD4y7m9ZK3O08nRxhM9gUbTt2M= 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.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b=pLusIHFP; arc=none smtp.client-ip=209.85.219.51 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.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b="pLusIHFP" Received: by mail-qv1-f51.google.com with SMTP id 6a1803df08f44-896fcfc591eso54275536d6.2 for ; Wed, 18 Feb 2026 08:23:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1771431808; x=1772036608; 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=P6FnkwjeY6brj0/7CWbwbk4xYyhWl9xXSqqcuyfPR0w=; b=pLusIHFPzxd0YRj1NcTuDwiWy+9zQm73TqYATk0nte4kKPJ8T7LYrqZEayQQAVVbMa aedQyHB3DAKzlDzgtAJ8sMQZBBUUhF2nT0u1OJD3SihGpvjFVgZNDhbS3qOg+BlUypQ9 9LbN6mGr5P9YpIrrZRJ+3darWlzkQQicV0rs7F05sPIe3RXI6fLvsph284AGWSHAqwBq WV6Wco+L57UwQdk4JdhVScHRuq8BSWCEielOnLB+fYDeM0F7JvmiXZASuli0sFLFDT1G Ghth0gmRsX3L/bVgDBOvm/GR/lZZfI5Avm11wSPH+kAW2x2ifgaXA+UTKvgHtJgTiyFR 8P+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771431808; x=1772036608; 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=P6FnkwjeY6brj0/7CWbwbk4xYyhWl9xXSqqcuyfPR0w=; b=oFEw/rVBVISjuP3BmkQvF+DiUOJXG1q3mpZwbYgrbEDIJcsSXXlQ4JDhGDK47WIbn8 V9m1mQCbcX2OrtGJAfwA2SCdDISFU0Y+veVJygnrYYALb5/55UvGXOk99bsm0syGPw/j zxfLTqTx7l+ZfLgztJPMBciu19t7vcrj0LolYcgMyHPgk4guiFzS9ojgGa9G/UjUv34y Id8AFXAlnESNwMJV0AQtj9XRVNla+NewESNsmuPxJuqD0g8UY4wS3h4BdLueTQTWBGDy W8XjIIiZ53UQs/oJGguZpJhF7ck6hgvFi/zx4rx9oEWohXG+tGDg3mjOEGpd1Oxgy1yQ i1pg== X-Forwarded-Encrypted: i=1; AJvYcCW16+p6Zfc1sieIEEm9C8nlE1JRzxteTFcpWc4bRIOeziDZsTQPIMvdthZGExy9KD1LRFh/7+A6SoPSBxU=@vger.kernel.org X-Gm-Message-State: AOJu0YwAiQ6442HdIN6134jSZfyxjo8OY4GyShrKk4JKqxgl7WgUnp6r kaA8KmJ1NBAqds6XkjKcnUqewUzr4EZcb+fgb29Ge3RTGRa0reaC5ccNvysARxaEovI= X-Gm-Gg: AZuq6aLPNzShoFg62D1WtDS3mlbwmkNO5IgY1tW6J4pz2RhjBsGUlsNPdImm55XmtiF YwYQuJlkv66h42rFqqouhzB2DPBdGSXAlAI/twkBYG3twXEFWquy2aZ6Cy7n6YwxQV/vZEon/zz q4iTM4tQrh3mvXKl5YdyDgmuG2RDTm7j3wjQNw5ypzGSBkk+gz0Dz+2g4clX/HoBdlM/lAQK6gj ipxJQ93+ZxpzRhnX1W9ITRbuQSijP5blhYeozC5kjSjC8h6DI3AqEPpPl4KuqEp7Ism9lHsH3hu BGAmVUS80Q8jkh785jBu+ECWL+07vvbOsWy9ts/7kisa5RpUmvC1QQhW8lwnWxFy824hGh49PAJ RGrFe5MxD/pbgPDdd+4Bee66+XA7in2UA7HqrT8XO3B0JkMiX0rNxOEIZv1L+zH8SjLWngwy5bM GCI7VXvROCT1IuF5s3Pm4bwqLgfZ4jgIpNICNagHAPxec94yA= X-Received: by 2002:a05:6214:d01:b0:894:85ee:63c7 with SMTP id 6a1803df08f44-89734917c48mr270391536d6.43.1771431807931; Wed, 18 Feb 2026 08:23:27 -0800 (PST) Received: from [172.19.0.48] ([99.196.128.5]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8971cc91eccsm189415026d6.13.2026.02.18.08.23.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Feb 2026 08:23:27 -0800 (PST) Message-ID: <88260480-238c-497c-bccc-aa1023551668@kernel.dk> Date: Wed, 18 Feb 2026 09:23:14 -0700 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 2/3] io_uring/uring_cmd: allow non-iopoll cmds with IORING_SETUP_IOPOLL To: Caleb Sander Mateos , Christoph Hellwig , Keith Busch , Sagi Grimberg Cc: io-uring@vger.kernel.org, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260213032119.1125331-1-csander@purestorage.com> <20260213032119.1125331-3-csander@purestorage.com> Content-Language: en-US From: Jens Axboe In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2/17/26 7:18 PM, Caleb Sander Mateos wrote: > On Thu, Feb 12, 2026 at 7:21?PM Caleb Sander Mateos > wrote: >> >> Currently, creating an io_uring with IORING_SETUP_IOPOLL requires all >> requests issued to it to support iopoll. This prevents, for example, >> using ublk zero-copy together with IORING_SETUP_IOPOLL, as ublk >> zero-copy buffer registrations are performed using a uring_cmd. There's >> no technical reason why these non-iopoll uring_cmds can't be supported. >> They will either complete synchronously or via an external mechanism >> that calls io_uring_cmd_done(), so they don't need to be polled. >> >> Allow uring_cmd requests to be issued to IORING_SETUP_IOPOLL io_urings >> even if their files don't implement ->uring_cmd_iopoll(). For these >> uring_cmd requests, skip initializing struct io_kiocb's iopoll fields, >> don't insert the request into iopoll_list, and take the >> io_req_complete_defer() or io_req_task_work_add() path in >> __io_uring_cmd_done() instead of setting the iopoll_completed flag. Also >> allow io_uring_cmd_mark_cancelable() to be called on these uring_cmds. >> Assert that io_uring_cmd_mark_cancelable() is only called on >> non-IORING_SETUP_IOPOLL io_urings or uring_cmds to files that don't >> implement ->uring_cmd_iopoll(). >> >> Signed-off-by: Caleb Sander Mateos >> --- >> io_uring/io_uring.c | 4 +++- >> io_uring/uring_cmd.c | 11 +++++------ >> 2 files changed, 8 insertions(+), 7 deletions(-) >> >> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c >> index c45af82dda3d..4e68a5168894 100644 >> --- a/io_uring/io_uring.c >> +++ b/io_uring/io_uring.c >> @@ -1417,11 +1417,13 @@ static int io_issue_sqe(struct io_kiocb *req, unsigned int issue_flags) >> >> if (ret == IOU_ISSUE_SKIP_COMPLETE) { >> ret = 0; >> >> /* If the op doesn't have a file, we're not polling for it */ >> - if ((req->ctx->flags & IORING_SETUP_IOPOLL) && def->iopoll_queue) >> + if ((req->ctx->flags & IORING_SETUP_IOPOLL) && >> + def->iopoll_queue && (!io_is_uring_cmd(req) || >> + req->file->f_op->uring_cmd_iopoll)) >> io_iopoll_req_issued(req, issue_flags); >> } >> return ret; >> } >> >> diff --git a/io_uring/uring_cmd.c b/io_uring/uring_cmd.c >> index ee7b49f47cb5..8df52e8f1c1b 100644 >> --- a/io_uring/uring_cmd.c >> +++ b/io_uring/uring_cmd.c >> @@ -108,12 +108,12 @@ void io_uring_cmd_mark_cancelable(struct io_uring_cmd *cmd, >> * Doing cancelations on IOPOLL requests are not supported. Both >> * because they can't get canceled in the block stack, but also >> * because iopoll completion data overlaps with the hash_node used >> * for tracking. >> */ >> - if (ctx->flags & IORING_SETUP_IOPOLL) >> - return; >> + WARN_ON_ONCE(ctx->flags & IORING_SETUP_IOPOLL && >> + req->file->f_op->uring_cmd_iopoll); >> >> if (!(cmd->flags & IORING_URING_CMD_CANCELABLE)) { >> cmd->flags |= IORING_URING_CMD_CANCELABLE; >> io_ring_submit_lock(ctx, issue_flags); >> hlist_add_head(&req->hash_node, &ctx->cancelable_uring_cmd); >> @@ -165,11 +165,12 @@ void __io_uring_cmd_done(struct io_uring_cmd *ioucmd, s32 ret, u64 res2, >> if (req->ctx->flags & IORING_SETUP_CQE_MIXED) >> req->cqe.flags |= IORING_CQE_F_32; >> io_req_set_cqe32_extra(req, res2, 0); >> } >> io_req_uring_cleanup(req, issue_flags); >> - if (req->ctx->flags & IORING_SETUP_IOPOLL) { >> + if (req->ctx->flags & IORING_SETUP_IOPOLL && >> + req->file->f_op->uring_cmd_iopoll) { > > I do worry that the pointer chasing here may be expensive, ->file and > ->f_op could both be uncached. Would it make sense to add a flag to > req->flags to indicate whether a request should actually be IOPOLLed? I think adding a REQ_F flag for that similar to what is done for NOWAIT etc would be a good idea. -- Jens Axboe