From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) (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 D66552DF128 for ; Fri, 5 Dec 2025 23:28:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764977318; cv=none; b=BuUz8B+nBD4+/WvIVV2h7VB54PI+rDmUwAIJCoM8vbYIPS6Qj3pV78rXWA26WggWUzANMbOvR8RlKFhaIB0C2HY3N4XJ6qWuslPlrXVNWMmB8NnLpED7ld9Cbb3XnLpBUXziK+YLP/gThGB3aMKX80jMummcHu36jsMO8mJkTTs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764977318; c=relaxed/simple; bh=Z90VoTeUAdtCFcfScKtg62fwuhlURfr0B3vhl1oj69g=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=isdbvB2fzhhzKvetfLTnXS5E8x6DYeHoWTuqJ23Hd/yX3cJQccLTTJziVp3KmTXY2b/NDmDp9qFTDTuBI/QrAktd3NAby+MOeKAggOYJDdF7DetJgzYPktNZ/eW2tm3Qg5JWH3KXHdFZbsPvaY6NiZh2ceHpphfqEyOlzs4O2cU= 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=Pg6ecarF; arc=none smtp.client-ip=209.85.160.180 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="Pg6ecarF" Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-4eda057f3c0so22742021cf.2 for ; Fri, 05 Dec 2025 15:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764977312; x=1765582112; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ZntIJKUAXObju8s18woAqbYsOVOV+83j3OU8C8k2zhc=; b=Pg6ecarFGuS0rD8CYyN/qGS03ZL0iA3mJPhKDVZG6N1vPcPy3AdIjWBP0YEXVrd2Vn hwRXc4dlCGrba+GjqaSz2y8o1ZGssXyKfsMDqn4hp4M9mfmebkWfWAGvhMqrVM6quvBR q5B+WId3LS6LOIXCHFUSKOrSbab75Br2gFjnA4XPMVKZxYpgQAAMsPnXzlkF+CEjVDWY 33h7okcD/7KwnA/wpW3u3fI/IKFd3P3lvU5+HzdARI0gTwtQmDkAeb1PZ5Uc81o3QgbF W08AK8rMDC+0MNlN8G5AxI9pOVARUlMc+5wvQRgKWxvk28Fr5DNtd6Ai8p7utdmi/kU7 uQ5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764977312; x=1765582112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ZntIJKUAXObju8s18woAqbYsOVOV+83j3OU8C8k2zhc=; b=BaFCkANhbwmPZ01ORtPBLD1M6jxs4tTMzoAFrNKnA/rticRYY32bd3x3K++KF05f2/ oamwe4ZX69+ABm4X6t/R/9DVB/V3mJLCDV/QnV3zO452HMSbcML1H6b9YxS2Ya5PgfFn EdymMbGXCVZvOV/0XBJY4tLgPuW8z7Ew2BxtXVRZTH3JBdxjMa3vWO/0980rqPZ9HZJ0 j+wLoN0yOo4sSo1zGVO0Hx+N8UtDf7OqCzsRhGzqW/+9yZMCaV1LZZBvWfwnlQglSyuM tCVIA60QC6zdY5Guj94HZm6kQx/qyOMV99beC0OiDTqd5jmTCnGYWiKlha7UudCGWj2y pIMQ== X-Forwarded-Encrypted: i=1; AJvYcCX/rbdoHBw2cp6uZz92YbhDKZ3IzeVPiRvhmxAtyEdO4LkD+ONguBQkVF4ESpDsjIZtgfzLRMOIWMoiM6L5@vger.kernel.org X-Gm-Message-State: AOJu0YxtOUTQi5tjCuX1Fp0CuaNXpDjIFj4W4i/6p3twvfJ7r8rCyXPd o6Fta27rwXkhpcom/9hzGO53o9ZUMmgrWUSA2eC8kp7VF5Tpht4Ot0B8tPrFX5/JCBhGrmq8eNz N2nP3uc1xa+h0S5zcxg56qA35NRRUFhk= X-Gm-Gg: ASbGnctWBhiSRoSsOl8wKrt3GbJXqUzxHA6wya8udQddu+l0r6PA+qB8UhziLeuXxL/ IR3v1Q8eYBzqFTPDYsfcq/b2NMdAsui7nW51H43+ByHk+ZgmqQkI+EdTKASwvNKkSoyhOpa7S+x fdPhmESmbkWrL7vn5PSfR/HP2aC7N/jVUCnCZ823bHHUC+uMEOSOGNBzawitc7MhSnBxgnMHm/I jFNhPvyC5VtSli2W+uEQooS+ezWwM+3CFVrDuyScfQn3fPb911BRRagvuAZ19UHQ32aJQ== X-Google-Smtp-Source: AGHT+IEHO/BbyvwXOm2Ad6NW0GPg9WjWd8aAwArvsDQjzJwIOr+XxxAV41Ns4Ichas3RvHPNKWaCRaMV0evnwufGIb8= X-Received: by 2002:a05:622a:4c16:b0:4ee:418a:73cd with SMTP id d75a77b69052e-4f03fe2895cmr12857431cf.36.1764977312130; Fri, 05 Dec 2025 15:28:32 -0800 (PST) Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20251203003526.2889477-1-joannelkoong@gmail.com> <20251203003526.2889477-10-joannelkoong@gmail.com> In-Reply-To: From: Joanne Koong Date: Fri, 5 Dec 2025 15:28:21 -0800 X-Gm-Features: AWmQ_bk3JsZW9L6JFhEbJfFK7vovI6J03e6MDpVp2W0GjvO3-ZBO3PmowzI6Zv8 Message-ID: Subject: Re: [PATCH v1 09/30] io_uring: add io_uring_cmd_import_fixed_index() To: Caleb Sander Mateos Cc: miklos@szeredi.hu, axboe@kernel.dk, bschubert@ddn.com, asml.silence@gmail.com, io-uring@vger.kernel.org, xiaobing.li@samsung.com, linux-fsdevel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 5, 2025 at 8:56=E2=80=AFAM Caleb Sander Mateos wrote: > > On Thu, Dec 4, 2025 at 10:56=E2=80=AFAM Joanne Koong wrote: > > > > On Wed, Dec 3, 2025 at 1:44=E2=80=AFPM Caleb Sander Mateos > > wrote: > > > > > > On Tue, Dec 2, 2025 at 4:36=E2=80=AFPM Joanne Koong wrote: > > > > > > > > Add a new helper, io_uring_cmd_import_fixed_index(). This takes in = a > > > > buffer index. This requires the buffer table to have been pinned > > > > beforehand. The caller is responsible for ensuring it does not use = the > > > > returned iter after the buffer table has been unpinned. > > > > > > > > This is a preparatory patch needed for fuse-over-io-uring support, = as > > > > the metadata for fuse requests will be stored at the last index, wh= ich > > > > will be different from the sqe's buffer index. > > > > > > > > Signed-off-by: Joanne Koong > > > > --- > > > > include/linux/io_uring/cmd.h | 10 ++++++++++ > > > > io_uring/rsrc.c | 31 +++++++++++++++++++++++++++++++ > > > > io_uring/rsrc.h | 2 ++ > > > > io_uring/uring_cmd.c | 11 +++++++++++ > > > > 4 files changed, 54 insertions(+) > > > > > > > > diff --git a/io_uring/rsrc.c b/io_uring/rsrc.c > > > > index 67331cae0a5a..b6dd62118311 100644 > > > > --- a/io_uring/rsrc.c > > > > +++ b/io_uring/rsrc.c > > > > @@ -1156,6 +1156,37 @@ int io_import_reg_buf(struct io_kiocb *req, = struct iov_iter *iter, > > > > return io_import_fixed(ddir, iter, node->buf, buf_addr, len= ); > > > > } > > > > > > > > +int io_import_reg_buf_index(struct io_kiocb *req, struct iov_iter = *iter, > > > > + u16 buf_index, int ddir, unsigned issue= _flags) > > > > +{ > > > > + struct io_ring_ctx *ctx =3D req->ctx; > > > > + struct io_rsrc_node *node; > > > > + struct io_mapped_ubuf *imu; > > > > + > > > > + io_ring_submit_lock(ctx, issue_flags); > > > > + > > > > + if (buf_index >=3D req->ctx->buf_table.nr || > > > > > > This condition is already checked in io_rsrc_node_lookup() below. > > > > I think we still need this check here to differentiate between -EINVAL > > if buf_index is out of bounds and -EFAULT if the buf index was not out > > of bounds but the lookup returned NULL. > > Is there a reason you prefer EINVAL over EFAULT? EFAULT seems > consistent with the errors returned from registered buffer lookups in > other cases. To me -EINVAL makes sense because the error stems from the user passing in an invalid argument (eg a buffer index that exceeds the number of buffers registered to the table). The comment in errno-base.h for EINVAL is "Invalid argument". The EFAULT use for the other cases (eg io_import_reg_buf) makes sense because it might be the case that for whatever reason the req->buf_index isn't found in the table but isn't attributable to having passed in an invalid index. Thanks, Joanne > > Best, > Caleb >