From nobody Tue Apr 7 09:35:47 2026 Received: from sender-of-o55.zoho.eu (sender-of-o55.zoho.eu [136.143.169.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A20803D331C for ; Fri, 13 Mar 2026 18:11:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.169.55 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773425463; cv=pass; b=IxEdG/RNqMLz5ys2gRgv/cE3j7ud4n8M+XPR7na9VcQQcfO9SjI4XQfuZG5m7HrvK+CNoAF7fgT3DclfN9O3aunF4DdDdPt7ejcEPSBOfC8hIqMJnJTK8Q6xGSsZEtgTmBJyyuW/UNaL++WV7A+E+6r19hn1pY2be4mKCeqQz5E= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773425463; c=relaxed/simple; bh=Kc/3AKIpwTzSkyARNIxZFhYv6buQLTsMNPDjGT35jOo=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=syFKTubbJuFmywqIcAuoIBbuXEsCDo2bBnMB61lkwjjD986NP1KOaekTnPgKgHQen7N0adKg81taNLmGsgySZ96ubeogoB/tim+JCYSOjWo/fnVxmRbNpfCtGbjvE2uKAw90vgmxHj/arCcI6ydANia+gzqxrcX4nj8Zer2YqTo= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=objecting.org; spf=pass smtp.mailfrom=objecting.org; dkim=pass (1024-bit key) header.d=objecting.org header.i=objecting@objecting.org header.b=cIhwmImR; arc=pass smtp.client-ip=136.143.169.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=objecting.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=objecting.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=objecting.org header.i=objecting@objecting.org header.b="cIhwmImR" ARC-Seal: i=1; a=rsa-sha256; t=1773425443; cv=none; d=zohomail.eu; s=zohoarc; b=Hq1Fo1wrzq5Swt9L6WunKco2N00mB/Kvk4MoEXX98C3Rz1PraaclfDfOIEo1iSFyDvBVXQEC7pjTyGlKC23DpuBO0yy+/0XGc1dxzwcW1GJ72CbrB9kilwDiZEZIVL0uQ9Nqx+DZrIZBICyeEgzK/9fxe4ZVr5o51TJLXDY72Ek= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1773425443; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=qjNsFUrMiANXtVwfgqUllgON46nJBxUf5dbGwwSm1RY=; b=g8uXpGNsOUrn8Xkv1iruNjEcuOlyrBRT119kaVCsJFTBAguN4f2n7iOlJqOh2oLCFnCAm3e92W5EMdrZXsoxP1/TJcUGeib6LY2ZFw6OTLN9dC8S/HAEj4kAVcK8vmUnGFpS/nu0Ps3cjYDVmrtUaNPbx7fViLTMnklqj3fW1Oc= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=objecting.org; spf=pass smtp.mailfrom=objecting@objecting.org; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1773425443; s=zmail; d=objecting.org; i=objecting@objecting.org; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To; bh=qjNsFUrMiANXtVwfgqUllgON46nJBxUf5dbGwwSm1RY=; b=cIhwmImRf0tlhHMw708SognLTq9rSV0U6PDnJ+qvYHpp7XjCP/wGbMNjobdCaxRY dpPrB9VIKdBzGs+lZS7vsLMvB7MaWYhsP2DCZDSbvAazZuvjJp/sfmgrODrOP3GyGnn 1RTtRZHzuBh2aBi40u+lsqxARce5WrT7AGIEhuHo= Received: by mx.zoho.eu with SMTPS id 1773425441062377.8134339982736; Fri, 13 Mar 2026 19:10:41 +0100 (CET) From: Josh Law To: Andrew Morton , Alexander Viro Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, Josh Law Subject: [PATCH 1/7] lib/iov_iter: fix missing allocation failure check in iov_iter_extract_bvec_pages() Date: Fri, 13 Mar 2026 18:10:32 +0000 Message-Id: <20260313181038.30018-2-objecting@objecting.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260313181038.30018-1-objecting@objecting.org> References: <20260313181038.30018-1-objecting@objecting.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External Content-Type: text/plain; charset="utf-8" When iterating bvec pages for direct I/O submission on a block device under heavy memory pressure, want_pages_array() can return 0 if the internal kvmalloc_objs() call fails. Every other call site in the file (iter_folioq_get_pages, iter_xarray_get_pages, iov_iter_extract_kvec_pages, iov_iter_extract_user_pages, __iov_iter_get_pages_alloc) checks for this and returns -ENOMEM, but iov_iter_extract_bvec_pages() does not. When the allocation fails, *pages is left NULL and maxpages is set to 0, but the while loop still enters because bi.bi_size is nonzero. The subsequent (*pages)[k++] =3D bv.bv_page dereferences the NULL pointer, causing a kernel oops. This was found through code review comparing the error handling patterns across all want_pages_array() call sites in the file and noticing the one that was inconsistent. Add the same !maxpages check present at every other call site. Signed-off-by: Josh Law --- lib/iov_iter.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/iov_iter.c b/lib/iov_iter.c index 0a63c7fba313..852f9ed40e5c 100644 --- a/lib/iov_iter.c +++ b/lib/iov_iter.c @@ -1628,6 +1628,8 @@ static ssize_t iov_iter_extract_bvec_pages(struct iov= _iter *i, bi.bi_bvec_done =3D skip; =20 maxpages =3D want_pages_array(pages, maxsize, skip, maxpages); + if (!maxpages) + return -ENOMEM; =20 while (bi.bi_size && bi.bi_idx < i->nr_segs) { struct bio_vec bv =3D bvec_iter_bvec(i->bvec, bi); --=20 2.34.1 From nobody Tue Apr 7 09:35:47 2026 Received: from sender-of-o55.zoho.eu (sender-of-o55.zoho.eu [136.143.169.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A21163D333E for ; Fri, 13 Mar 2026 18:11:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.169.55 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773425463; cv=pass; b=PsElcmckQ1W6WZJPnBMmG01JFoZ5DJsQDJxbZIYkdFkAZgBibwn1KbH7poyLKgEX5q7WU5roDdSc1ELHDXtRVawTfeCxCx1HavIiVf1AkoQsaD5jFZdq7sS5ooaph9WwGfHVM242T5r9sWWCNBzqG1h/Qohc6TgNkTxgL2A1p0U= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773425463; c=relaxed/simple; bh=CQlXvEUAm5j1LubDGqz5a/eiOfy/QmxgSX0sKhPEFXU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=pgbuIx5EPxCiihDwB1JBMDDSrAy706s8Q9QuzC26bZKlRwKcLX5bIir1dKZanfzvL51nVN2MqVSgVheM1bkvqO75YHmRHCQQ9zo6c8GzJIxirDLhe51TYA6/QSNfesAST7s3YfPzHvez7g9zsuA9VnHaAbmhl/O8pBZAmiHKZVw= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=objecting.org; spf=pass smtp.mailfrom=objecting.org; dkim=pass (1024-bit key) header.d=objecting.org header.i=objecting@objecting.org header.b=MaaAD/sJ; arc=pass smtp.client-ip=136.143.169.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=objecting.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=objecting.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=objecting.org header.i=objecting@objecting.org header.b="MaaAD/sJ" ARC-Seal: i=1; a=rsa-sha256; t=1773425443; cv=none; d=zohomail.eu; s=zohoarc; b=jx2449L/xNchG+MsHfvoRVzn4OuKxQavrmo6CcVDJKgnJ1iSYJLMz7RNS5maWGRQ4d7MGBH5BksGsIFhZ0fpLJKr+K0qbzhRuxm3TlEpofA7QMLMQ4pt0yzOpthRnRa80q/m6Tir5aC9g1ATvIv2BC8stdxreFRRpCM3jvxRdR4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1773425443; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=lJBr918jvjyndyx8jpHpTm+m8/8Mw2Gu7Xnd8DjPVu8=; b=X/TKHZ01oNeibvINGsIPzYcbYHHix6gVVTtefFxryWQDF/nutt6PSr/lQbESBur8wCDRJaukEmQbnuQDCFTmIzAqYxy0tF8aLOzBtU3ubEdyHwj4WfN9bBdGonMF2EY5jXvCkjNgOx24v97HwaqJ+dSWxlj7/MIXdPGg/S6bb8Y= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=objecting.org; spf=pass smtp.mailfrom=objecting@objecting.org; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1773425443; s=zmail; d=objecting.org; i=objecting@objecting.org; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding:Reply-To; bh=lJBr918jvjyndyx8jpHpTm+m8/8Mw2Gu7Xnd8DjPVu8=; b=MaaAD/sJPlpwspNM1nZmmhYI0RRL+Yw4zsl7hLQHTKQJj1pokiJgRKkIiJcJ0FvG JK+SSuWKxvsEmtxXUWHuxIkWkm4NmowC/YCIwe9zoaey4j4om8ErIGZyZxLAulQN94D gpeNA1zTdkp4uMogzKnpiWr5BYgz/SIuiGupRDp4= Received: by mx.zoho.eu with SMTPS id 1773425441750178.6543463140457; Fri, 13 Mar 2026 19:10:41 +0100 (CET) From: Josh Law To: Andrew Morton , Alexander Viro Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, Josh Law Subject: [PATCH 2/7] lib/iov_iter: add NULL check on folioq->prev in iov_iter_folioq_revert() Date: Fri, 13 Mar 2026 18:10:33 +0000 Message-Id: <20260313181038.30018-3-objecting@objecting.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260313181038.30018-1-objecting@objecting.org> References: <20260313181038.30018-1-objecting@objecting.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External When a network filesystem using folio_queue-backed iterators (e.g. ceph or NFS with folioq read paths) hits a short read and calls iov_iter_revert() to wind the iterator back, the revert walks backwards through the folio_queue linked list via folioq->prev. If the unroll amount exceeds the data preceding the current position =E2=80=94 possible w= hen a splice or sendfile operation miscalculates the revert distance after a partial transfer =E2=80=94 the walk reaches the head of the queue where prev is NULL, and the subsequent folioq_nr_slots(NULL) dereferences it. This was found through code review examining the revert paths: the bvec and iovec revert loops have the same class of unbounded backward walk, but the folioq case is the easiest to reach in practice because folio_queue chains have an explicit NULL-terminated prev pointer. Add a NULL check and early return when folioq->prev is NULL to prevent the oops. Signed-off-by: Josh Law --- lib/iov_iter.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/iov_iter.c b/lib/iov_iter.c index 852f9ed40e5c..325669b103ed 100644 --- a/lib/iov_iter.c +++ b/lib/iov_iter.c @@ -600,6 +600,8 @@ static void iov_iter_folioq_revert(struct iov_iter *i, = size_t unroll) size_t fsize; =20 if (slot =3D=3D 0) { + if (!folioq->prev) + return; folioq =3D folioq->prev; slot =3D folioq_nr_slots(folioq); } --=20 2.34.1 From nobody Tue Apr 7 09:35:47 2026 Received: from sender-of-o55.zoho.eu (sender-of-o55.zoho.eu [136.143.169.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 66BBD3DBD78 for ; Fri, 13 Mar 2026 18:11:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.169.55 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773425464; cv=pass; b=EGDsfH8HiGi2su5gMDHU2Y1Comk7b/MXjfgxqXUnvmO3YsHphCsDfK4X1BDPbGfbO91Puof/lCNQdmVpRvKMA5E2znJMufEhgfTnxO7v/3ZYa4NfYPCIUREr+q4a1rnGXGFbQVq4W6ycNPySAIQDAeOTFVCerpdbMafSDHQG4UE= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773425464; c=relaxed/simple; bh=IFLiBLH2CQlJfYJQUH1DiMqZU4G90xmzuB1KhGFsVR4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=gvZX9/79sB0hbg8WkP9A1o0p3PNdu0WtY/p9g+ZdTLsNiqhzBiAsqACgPZP/D9ZB95jAOI601fqccGI/ma6cx7eKpP6YG1qrN7LT9h5g3ZEmcnR8ofNun5iLR+RZ6YFmaN9c4nDaPqpTQKNomokRIlSIlUve8kGwODq0IRuCEwQ= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=objecting.org; spf=pass smtp.mailfrom=objecting.org; dkim=pass (1024-bit key) header.d=objecting.org header.i=objecting@objecting.org header.b=WRcFEG4d; arc=pass smtp.client-ip=136.143.169.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=objecting.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=objecting.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=objecting.org header.i=objecting@objecting.org header.b="WRcFEG4d" ARC-Seal: i=1; a=rsa-sha256; t=1773425445; cv=none; d=zohomail.eu; s=zohoarc; b=LIkC9eU3Vy41CSlU4P9hKNIa/+2tAiFJnc/Hh/W9wuqowgWlGKBMQPyxyjtwp0b1Xmv0u3nVjVVmReqtUN7VvMwrDQyX4yCd9MtLKDidATkZSL5uovjSbnXNuIbr/Js3MIoGqv6QP4OxbwWOOcLjM3SIl7+6B/XC7jqlugLLDWc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1773425445; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=Q2wEFWHClElXL8mEWY3utSjA7/avsVmLg4tZS6cFKYo=; b=RFMzj+6LlNVWBdukgoBSriHR66jw62/3/oC3XQIZE5cwmXiSTJlo0m3ERS0wnTfAdGo4MNEgisgkv7Mo//4agl0LsRJgghPUiZ6NPO9f4jqHgez13D+4fnQoVkDLP6+4UN4hCH/xwBq29S45M6f7ohGYhflWA3+MyLI7+4gBV4g= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=objecting.org; spf=pass smtp.mailfrom=objecting@objecting.org; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1773425445; s=zmail; d=objecting.org; i=objecting@objecting.org; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding:Reply-To; bh=Q2wEFWHClElXL8mEWY3utSjA7/avsVmLg4tZS6cFKYo=; b=WRcFEG4dmjAbFZ1LMoCIMgSiJiGJPvDnPPynUPAfURSGiQLxfdAl6axTHd48g30W ySBh/z4RChKDuZjq74W/zDVpDeZlCzqILvHNWNgHZ+T4DLwLC2FqozTXMU/bwYcbPUQ V/19QRgJASTp6KuzA6UKjxL//CLvlUKktuHrAH1U= Received: by mx.zoho.eu with SMTPS id 1773425442308668.2028255196005; Fri, 13 Mar 2026 19:10:42 +0100 (CET) From: Josh Law To: Andrew Morton , Alexander Viro Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, Josh Law Subject: [PATCH 3/7] lib/iov_iter: fix misplaced parenthesis in iov_iter_restore() kvec check Date: Fri, 13 Mar 2026 18:10:34 +0000 Message-Id: <20260313181038.30018-4-objecting@objecting.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260313181038.30018-1-objecting@objecting.org> References: <20260313181038.30018-1-objecting@objecting.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External When restoring a kvec-backed iterator after a short write in a kernel socket sendmsg path (e.g. an NFS client resending an RPC call), the WARN_ON_ONCE guard fires a spurious warning on every first call. The closing parenthesis of WARN_ON_ONCE is after !iter_is_ubuf(i), leaving !iov_iter_is_kvec(i) as a separate && operand outside the macro: WARN_ON_ONCE(!bvec && !iovec && !ubuf) && !kvec For kvec iterators this evaluates as WARN_ON_ONCE(true) && false =E2=80=94 = the warning fires but the return is skipped, so execution proceeds correctly. The warning is the only visible symptom, but it is confusing and may mask real issues. Found through code review of the operator precedence in the condition expression and confirmed by tracing the macro expansion. Move the closing parenthesis to include the kvec check inside WARN_ON_ONCE so the warning only fires for genuinely unsupported iterator types. Signed-off-by: Josh Law --- lib/iov_iter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/iov_iter.c b/lib/iov_iter.c index 325669b103ed..6a7959bfc849 100644 --- a/lib/iov_iter.c +++ b/lib/iov_iter.c @@ -1471,7 +1471,7 @@ EXPORT_SYMBOL_GPL(import_ubuf); void iov_iter_restore(struct iov_iter *i, struct iov_iter_state *state) { if (WARN_ON_ONCE(!iov_iter_is_bvec(i) && !iter_is_iovec(i) && - !iter_is_ubuf(i)) && !iov_iter_is_kvec(i)) + !iter_is_ubuf(i) && !iov_iter_is_kvec(i))) return; i->iov_offset =3D state->iov_offset; i->count =3D state->count; --=20 2.34.1 From nobody Tue Apr 7 09:35:47 2026 Received: from sender-of-o55.zoho.eu (sender-of-o55.zoho.eu [136.143.169.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 56A8F3DCDAC for ; Fri, 13 Mar 2026 18:11:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.169.55 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773425465; cv=pass; b=oNvF+c/qCicza1O4iAHgRPT9qDxY/hdMKP5bMCFUbcXpYGx6EfEHRW+v98sT62JXnnV5adpvtIR7oChIp/i928ExI3AN5R0mksGKDu9iASpXQB//JeLNRMW/FfrU9j05Km+QrzyRQK6VOsCelhoNge+UuFpioM2U8DOGI6s94/c= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773425465; c=relaxed/simple; bh=1U4L4TfcbRab7SatP+1BuE2zH2ZJnR8M+vOCHxFgBl8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=YNLmYT3lqWF9p+51PORHMK59PHw6YBLiDNxfGAU2ylZVeBjH/beYne7G5G7g5KI0gWrBleFhtPpE7aYYuBTz/YCwuACigy3plNfXup+GsRCMlDRkDjMdY/smNP70wN18hhPfYqRr2qX2uwFsCefIpLE3sepONhKy6IlFeg27RTM= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=objecting.org; spf=pass smtp.mailfrom=objecting.org; dkim=pass (1024-bit key) header.d=objecting.org header.i=objecting@objecting.org header.b=QJip/cJE; arc=pass smtp.client-ip=136.143.169.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=objecting.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=objecting.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=objecting.org header.i=objecting@objecting.org header.b="QJip/cJE" ARC-Seal: i=1; a=rsa-sha256; t=1773425446; cv=none; d=zohomail.eu; s=zohoarc; b=EhYE5MtklV+Z9S4xhoGwpoGE72BHmhcYBMD29hMZaGD2u40j6oJwch0LDsm2QzbPMDrTLNonGHgCIMHtU+RdTu80VMrE/1068XdXiXDVbemfGJmqdfrseZzOQEVmbycHmeMkFpkTUH0S4Qiw4N7m+XEzDDSDghH2+5zEthkqlLE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1773425446; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=SBmsvc6Cb9SLMhMKC+imSsbrYFq42BLCcQ1QkHJf4LQ=; b=lNXUhXjFLOYY/BYiNIBiab8VPSlwFVkXXhrkDIjg9OWAnk1xEn/3+oEJ1ROmTpUK6n5tiTcDKK12A3ED2nZ9xm3km7FdJu3N7e8lJdjjasJ/vVs+fEUWy6HWLXgl57f17c38yBVKbS+Euv7dS15wxj22S5EccjQG9YgZfTHD/c8= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=objecting.org; spf=pass smtp.mailfrom=objecting@objecting.org; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1773425446; s=zmail; d=objecting.org; i=objecting@objecting.org; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding:Reply-To; bh=SBmsvc6Cb9SLMhMKC+imSsbrYFq42BLCcQ1QkHJf4LQ=; b=QJip/cJEbDWZF9myzyGca45qWWTxQcQ2MQQtKcjxVAD6KCr1Gwj0wetfIel4Xzyu vvThw5DnSpBlEy4k9bJFlXlfJuQ8makWG5imwhLecBrVMWPFHkynj/aCqjDtKGXt6Ao 7tBUVe9AlcaoYKEtYgThJ5jK6bEiZCXKqMwKm9gI= Received: by mx.zoho.eu with SMTPS id 1773425442879181.11812605213493; Fri, 13 Mar 2026 19:10:42 +0100 (CET) From: Josh Law To: Andrew Morton , Alexander Viro Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, Josh Law Subject: [PATCH 4/7] lib/iov_iter: account for iov_offset in iov_iter_single_seg_count() folioq path Date: Fri, 13 Mar 2026 18:10:35 +0000 Message-Id: <20260313181038.30018-5-objecting@objecting.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260313181038.30018-1-objecting@objecting.org> References: <20260313181038.30018-1-objecting@objecting.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External When the block layer calls iov_iter_single_seg_count() to size a segment for a folioq-backed iterator =E2=80=94 as happens during large buffered writes through cachefiles or fscache =E2=80=94 the function returns the full folio size without subtracting iov_offset. After a partial transfer has advanced iov_offset into the middle of a folio, this over-reports the remaining data in the current segment. The iovec and bvec paths both subtract iov_offset (e.g. iter_iov(i)->iov_len - i->iov_offset), but the folioq path omits it. Found by reviewing the function for consistency across iterator types and comparing each branch's treatment of iov_offset. Subtract iov_offset from the folio size to match the behavior of the other iterator types. Signed-off-by: Josh Law --- lib/iov_iter.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/iov_iter.c b/lib/iov_iter.c index 6a7959bfc849..375512beefc5 100644 --- a/lib/iov_iter.c +++ b/lib/iov_iter.c @@ -682,7 +682,8 @@ size_t iov_iter_single_seg_count(const struct iov_iter = *i) } if (unlikely(iov_iter_is_folioq(i))) return !i->count ? 0 : - umin(folioq_folio_size(i->folioq, i->folioq_slot), i->count); + umin(folioq_folio_size(i->folioq, i->folioq_slot) - i->iov_offset, + i->count); return i->count; } EXPORT_SYMBOL(iov_iter_single_seg_count); --=20 2.34.1 From nobody Tue Apr 7 09:35:47 2026 Received: from sender-of-o55.zoho.eu (sender-of-o55.zoho.eu [136.143.169.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 25D65361652 for ; Fri, 13 Mar 2026 18:11:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.169.55 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773425462; cv=pass; b=hfePnlSxDhFwt6Y4HszquSHz6B7vUXL4QDRfGC4s1tgLwoW5VVWzpUhUdPFIuAXXqoD4CbJAxyDNyBan0fLicNV8a+Etslr61e/GtkjMkpPTcScLgtKXY8R1qiuprrfw66u6buceL71UsfkXcosz4RQCxg9DPTziOHsdRexOz3A= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773425462; c=relaxed/simple; bh=djYHWh5797V5FFMCTTT8D+SX719WAsRUsR06ws370Oc=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=KuPGMZGQmoYEb6oKTeBMTZq1zH5lxF5YisywJa8Y04LNn84C5hXf1JOlag9p8CmrnAw3J3Vi6Cv81Th4i7eU2UB0AZZghk70+j4IGma3laU8vO3/Oine5/8N/t2IVaBYYXB7YSE53J1L0yhsqQ9Gqewpp3m6cndRIezRVBQx7Zw= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=objecting.org; spf=pass smtp.mailfrom=objecting.org; dkim=pass (1024-bit key) header.d=objecting.org header.i=objecting@objecting.org header.b=Jt5DlSnW; arc=pass smtp.client-ip=136.143.169.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=objecting.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=objecting.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=objecting.org header.i=objecting@objecting.org header.b="Jt5DlSnW" ARC-Seal: i=1; a=rsa-sha256; t=1773425445; cv=none; d=zohomail.eu; s=zohoarc; b=Ft5wvn2YlO3FAA0HXu8fqLV/PKOpVGq8xYFS2CELi38tgzhdWj3jZkwMpDP3hV0djfPPUWSE4fe4qXjPsi+yIJ4g+AzprpOmidcBFl3U017CEksm/G+RGLmWuyeBgf8qeKyDAYxL+QicqCHuTVj3GNdferxR86FwTn3glVZxeZM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1773425445; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=orO1a/zODaBIJYN0vC2FaQCr3Has8dtmh84CnFyWWEY=; b=Go1dqoRvaR+OZ3lec31+uCxNqQqinWKJvXQfnz+mhMxX6Aui1/BSmXtPz107iAzln4ulcjzvJ6xsT/QPdJr8G03MUV7RF/dVTwBKSZ/7zBXw8d8L3o7LIzGvZ/BRph8bl82ETl5n++w6zdNG55nSpxw/8xCV9dUNoxBNF05gbOk= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=objecting.org; spf=pass smtp.mailfrom=objecting@objecting.org; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1773425445; s=zmail; d=objecting.org; i=objecting@objecting.org; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding:Reply-To; bh=orO1a/zODaBIJYN0vC2FaQCr3Has8dtmh84CnFyWWEY=; b=Jt5DlSnWZ28ZzIRI/1ZhHQw9ejQNU9J7LYvKWu7l8sRxi+i4/ygSkb7pzcqYNDox hAo78DdShsF8+64TXP7ag3RJ0qkveNYEIM3hjA8n+ZUDvAaKAtdGk7Ev4NYS75WDOhY EG12+pShTYgfl4R0lYhrPTZ+18vUKpxmqgIlUrSM= Received: by mx.zoho.eu with SMTPS id 1773425443427459.1214546636411; Fri, 13 Mar 2026 19:10:43 +0100 (CET) From: Josh Law To: Andrew Morton , Alexander Viro Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, Josh Law Subject: [PATCH 5/7] lib/iov_iter: account for iov_offset in iov_iter_gap_alignment() Date: Fri, 13 Mar 2026 18:10:36 +0000 Message-Id: <20260313181038.30018-6-objecting@objecting.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260313181038.30018-1-objecting@objecting.org> References: <20260313181038.30018-1-objecting@objecting.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External When the block layer checks gap alignment constraints for a partially consumed iovec iterator =E2=80=94 as can happen during large direct I/O submissions that get split across multiple bio's =E2=80=94 iov_iter_gap_ali= gnment() uses the raw iov_base and iov_len of the first segment without adjusting for iov_offset. This reports the alignment of already-consumed data rather than the remaining portion, which can cause the block layer to apply incorrect gap alignment restrictions. Found by comparing the first-segment handling in iov_iter_gap_alignment() against iov_iter_alignment_iovec(), which correctly applies iov_offset via its skip variable. Apply iov_offset to the base address and length of the first segment so that gap alignment reflects the actual remaining data. Signed-off-by: Josh Law --- lib/iov_iter.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/lib/iov_iter.c b/lib/iov_iter.c index 375512beefc5..18561108aa3a 100644 --- a/lib/iov_iter.c +++ b/lib/iov_iter.c @@ -883,14 +883,16 @@ unsigned long iov_iter_gap_alignment(const struct iov= _iter *i) =20 for (k =3D 0; k < i->nr_segs; k++) { const struct iovec *iov =3D iter_iov(i) + k; - if (iov->iov_len) { - unsigned long base =3D (unsigned long)iov->iov_base; + size_t skip =3D k ? 0 : i->iov_offset; + size_t len =3D iov->iov_len - skip; + if (len) { + unsigned long base =3D (unsigned long)iov->iov_base + skip; if (v) // if not the first one res |=3D base | v; // this start | previous end - v =3D base + iov->iov_len; - if (size <=3D iov->iov_len) + v =3D base + len; + if (size <=3D len) break; - size -=3D iov->iov_len; + size -=3D len; } } return res; --=20 2.34.1 From nobody Tue Apr 7 09:35:47 2026 Received: from sender-of-o55.zoho.eu (sender-of-o55.zoho.eu [136.143.169.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AC35F3D6496 for ; Fri, 13 Mar 2026 18:11:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.169.55 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773425464; cv=pass; b=pKeFUySvXNmdUdn5hSXWv50+sG7mGIY+PJw22Cwo2WXuqpbn0yab3xw/m3NDgc7B285pb9Wa00EhU5ZdJE0saWX6TvsKRsxEhcoNnVif+UfZBfqmU/CuhRBtIs3NNkLjZErdX05DERURZShe6cZmCHx6qWSwteU2mtA7f73p3c8= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773425464; c=relaxed/simple; bh=ye++yCaIi++/JUm3r7TUbvt9fyJotOECRprcKn02vCc=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=T3X0OsM41BTZNuM5JQjdAR4QJMGlfNgfl5ydcKRUz0OfzkuAKTihaNIH4FVYGb0PWVunMsD7nO11tNnJzom4vTJEiX01mHmkY8h9SFJqTxcGDBYF8bNqZsrzhGnewtm+WsbD7iUCLp9h1KAlr0hb/MQjaE7TfG9bhajgYwrxjvA= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=objecting.org; spf=pass smtp.mailfrom=objecting.org; dkim=pass (1024-bit key) header.d=objecting.org header.i=objecting@objecting.org header.b=dEV+2uLb; arc=pass smtp.client-ip=136.143.169.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=objecting.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=objecting.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=objecting.org header.i=objecting@objecting.org header.b="dEV+2uLb" ARC-Seal: i=1; a=rsa-sha256; t=1773425445; cv=none; d=zohomail.eu; s=zohoarc; b=TOGDleYAhSqUoQSR4A9ZvswaPVJYXVvQfirhiVtVN0djwZqUwG4tgP8RtpvF2cPRfGiBVCtMa3k3KE92pk0Bm8RYML8MWRvtcl6eOjei2zURlbmJDvqKZvMBB3jXIXIIXY/xMdUn9nJHdPvqljATmyvVk5FKZopCaBXnaId+J1c= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1773425445; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=bokNmjYprG9JKLLdcrb8B4GkUZ4kLxoTVOtpOc28ExI=; b=g197aCltpWFysutiXQm2vBT7+/OXcZZn62yCNGJmQ3M3x5xvdhlyFS/eRGUdsMofXCpJuWMsB++YK9NspcbeQ8ECBDDVRKic46HqIJCk9o+46dt+LUay+Vao7ACDc4DfXiAf3Z89KHHjcScuec3zdJk3yn5RyA6/4Hmpy2/eI/Q= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=objecting.org; spf=pass smtp.mailfrom=objecting@objecting.org; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1773425445; s=zmail; d=objecting.org; i=objecting@objecting.org; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding:Reply-To; bh=bokNmjYprG9JKLLdcrb8B4GkUZ4kLxoTVOtpOc28ExI=; b=dEV+2uLb4sRA3wtFtcNe//xiIN5bxsZpLOeASQp6iyjOkAkzEMp7gQ6Ly4+j5K3Z jwf5c9mOB/DkxFnag/Ksa2U9qbhwR/kYl3H8XBwOsKk7AoMVbRN6BUEA7Bhj1yjivfA O8U98jEmQcPDsihNZlxyVNvb3PXBhV/n9X3UkAyE= Received: by mx.zoho.eu with SMTPS id 1773425444055232.31153927404955; Fri, 13 Mar 2026 19:10:44 +0100 (CET) From: Josh Law To: Andrew Morton , Alexander Viro Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, Josh Law Subject: [PATCH 6/7] lib/iov_iter: guard iov_iter_alignment() against zero-count iovec/bvec iterators Date: Fri, 13 Mar 2026 18:10:37 +0000 Message-Id: <20260313181038.30018-7-objecting@objecting.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260313181038.30018-1-objecting@objecting.org> References: <20260313181038.30018-1-objecting@objecting.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External When a direct I/O path calls iov_iter_alignment() on an iterator that has already been fully consumed (count =3D=3D 0) =E2=80=94 which can occur = when the block layer re-checks alignment after draining all bytes =E2=80=94 the iov_iter_alignment_iovec() and iov_iter_alignment_bvec() helpers enter their do-while loops unconditionally. With count =3D=3D 0 and a non-zero first segment length, the subtraction size -=3D len wraps the unsigned size_t to a large value, causing the loop to walk off the end of the iov/bvec array and read garbage memory. The ubuf path already guards against this (checking if (size) before accessing the buffer), but the iovec and bvec paths do not. Found by reviewing the function for consistent handling of edge cases across all iterator types, noting the ubuf path's explicit zero check had no equivalent in the other branches. Add count =3D=3D 0 guards in iov_iter_alignment() before calling into the iovec and bvec helpers, matching the ubuf path's behavior. Signed-off-by: Josh Law --- lib/iov_iter.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/iov_iter.c b/lib/iov_iter.c index 18561108aa3a..a5bb4fbd9d38 100644 --- a/lib/iov_iter.c +++ b/lib/iov_iter.c @@ -853,10 +853,10 @@ unsigned long iov_iter_alignment(const struct iov_ite= r *i) =20 /* iovec and kvec have identical layouts */ if (likely(iter_is_iovec(i) || iov_iter_is_kvec(i))) - return iov_iter_alignment_iovec(i); + return i->count ? iov_iter_alignment_iovec(i) : 0; =20 if (iov_iter_is_bvec(i)) - return iov_iter_alignment_bvec(i); + return i->count ? iov_iter_alignment_bvec(i) : 0; =20 /* With both xarray and folioq types, we're dealing with whole folios. */ if (iov_iter_is_folioq(i)) --=20 2.34.1 From nobody Tue Apr 7 09:35:47 2026 Received: from sender-of-o55.zoho.eu (sender-of-o55.zoho.eu [136.143.169.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F04443DBD79 for ; Fri, 13 Mar 2026 18:11:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.169.55 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773425464; cv=pass; b=Bz638gq/inG6El19OqB/9hvm6SkPHYqEkIgH7ObOQovq0awwieB8MbxSoIHJb4UyvSTPb8/1I16b7owvJcIHuZZoiGUVNoa4tb3aXT3xiMlqYoN/Tm2j1kYw8zpjWuvYmVJry2lQOG9LCWVuMw5UkxkiZJ60YkDFQpvxrFWcpNM= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773425464; c=relaxed/simple; bh=68sInYsoicDg0TLV4PCCCLWw+QLSpuXwS5sMTXmXnKA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=k4OK+HI8lN01EIGrGY5khS+ehewV0MD98jpa0kLS3A3AV+YIGXNvrrZbbv+xuUOIs3aaxJrw89GTMPOjD8RfwAAYxwsxFCVWq2WhzfHNpWG2RzTEpOrmEeTSRotSIVc3lGuysuc83fglxgfWpSGthAg2+sLN2J240SQMI+cbn8g= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=objecting.org; spf=pass smtp.mailfrom=objecting.org; dkim=pass (1024-bit key) header.d=objecting.org header.i=objecting@objecting.org header.b=HnVsUK0c; arc=pass smtp.client-ip=136.143.169.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=objecting.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=objecting.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=objecting.org header.i=objecting@objecting.org header.b="HnVsUK0c" ARC-Seal: i=1; a=rsa-sha256; t=1773425447; cv=none; d=zohomail.eu; s=zohoarc; b=OXMNEI/QJQqqDKhlhjLKwo8dObuTOmewG5jl6r2uAaN9TBMKxb+8eGQa76C4lL4djlnlX8/THmCSBQuRtJVGzZDQNKfJq58VqhKZgyvGftOa77P+aiYiwepb/V10Ek6JS2sC5w/vAgBLZ0dZEw16sUhOlxNSj+/uIhafLFjqBLk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1773425447; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=JlnqFE/JwVAb0ZfMLbMBz0yidWm8ctSkmiGTlsgGfqE=; b=VdktjdFdqzqvRtPpwilaX3xT5oQ6W+WUDo0g2Avgzo7AB7R6thP7vawE6MAJYytZhoiS1d/7AS8knw2PZdf/qBQ6hGP6p969lHdyjTUpYCu0ZqVcbsJVvMtdHSCdYMGT5ImIWQFJhX6Oqfu81suUgK/JVokS4ZEkSwNv+cowlJg= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=objecting.org; spf=pass smtp.mailfrom=objecting@objecting.org; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1773425447; s=zmail; d=objecting.org; i=objecting@objecting.org; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To; bh=JlnqFE/JwVAb0ZfMLbMBz0yidWm8ctSkmiGTlsgGfqE=; b=HnVsUK0cNYMvA4JMAH5JUPbPxj8ZNkvAUuSVZu8EGLGiE1upWRZbOcS3jXWHjCsa W5besZAEUQUA81aEH9hInddIlLnVmHhhe6LBOJXalEBiJinjYmpDY0eb6qvx9t9y10S +xl+m5p69ly9/bmHYZNUGN7qZT7RKh06HeZieJdE= Received: by mx.zoho.eu with SMTPS id 1773425444622119.22191903532143; Fri, 13 Mar 2026 19:10:44 +0100 (CET) From: Josh Law To: Andrew Morton , Alexander Viro Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, Josh Law Subject: [PATCH 7/7] lib/iov_iter: add missing should_fail_usercopy() in copy_to_user_iter_mc() Date: Fri, 13 Mar 2026 18:10:38 +0000 Message-Id: <20260313181038.30018-8-objecting@objecting.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260313181038.30018-1-objecting@objecting.org> References: <20260313181038.30018-1-objecting@objecting.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External Content-Type: text/plain; charset="utf-8" When running fault injection tests (CONFIG_FAULT_INJECTION_USERCOPY) against DAX/pmem read paths, the machine-check variant copy_to_user_iter_mc() is not covered because it skips the should_fail_usercopy() check that the normal copy_to_user_iter() has. This means the dax_copy_to_iter() code path used for pmem reads cannot be exercised by the usercopy fault injector, leaving a gap in test coverage for a path that has its own distinct error handling (it must not retry on #MC). Found by auditing all copy_to_user/copy_from_user helper variants in the file for consistent use of the fault injection hook and noticing copy_to_user_iter_mc() was the only one without it. Add the same should_fail_usercopy() check that copy_to_user_iter() has. Signed-off-by: Josh Law --- lib/iov_iter.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/iov_iter.c b/lib/iov_iter.c index a5bb4fbd9d38..89e04066f737 100644 --- a/lib/iov_iter.c +++ b/lib/iov_iter.c @@ -204,6 +204,8 @@ static __always_inline size_t copy_to_user_iter_mc(void __user *iter_to, size_t progress, size_t len, void *from, void *priv2) { + if (should_fail_usercopy()) + return len; if (access_ok(iter_to, len)) { from +=3D progress; instrument_copy_to_user(iter_to, from, len); --=20 2.34.1