From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A939DD12D4B for ; Sun, 10 Nov 2024 17:12:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 954566B00AA; Sun, 10 Nov 2024 12:12:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9050C6B00AD; Sun, 10 Nov 2024 12:12:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7CCC06B00AF; Sun, 10 Nov 2024 12:12:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5FEA96B00AA for ; Sun, 10 Nov 2024 12:12:41 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 817BDA1346 for ; Sun, 10 Nov 2024 17:12:40 +0000 (UTC) X-FDA: 82770826950.17.F3C5806 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf09.hostedemail.com (Postfix) with ESMTP id 72357140006 for ; Sun, 10 Nov 2024 17:12:11 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Qb35O84S; spf=pass (imf09.hostedemail.com: domain of snitzer@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=snitzer@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731258568; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=O85kMsIOm/PZiTQOq1pGGlENN9R9b+1XcqDreV+bz1Q=; b=PwCsXucBQ5ShM1/Wg45ol3aDTCHxi+nZ+ltFXO0Q9tf9AMr9AAAEsqo5Bppp/GuRDuu4NM ZaiWfnBjJJ1Tt2EFi+ute2IwY2rGpB3sPAY6BUqtBfjs0dDcunnmDuL1gFLy/2O2lmkHdE JubZWC6uYe4LRFMn970SLz6NQGmQcu4= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Qb35O84S; spf=pass (imf09.hostedemail.com: domain of snitzer@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=snitzer@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731258568; a=rsa-sha256; cv=none; b=iHCoafXo+USkG1LsJvx+Zwyq5XJAJisjANdBSjBjb/E+D3H9m2+wWS6czGagRb+1JD5Ek7 gy8TUnzqCS6mwS+ojq+/+T4eta7Ceb5FUh/4bgQSwsUGbY2cVIV4pC6zoNNXLlte4aKQ87 QWMzzJ5kuxxmnJ9xgH8y4W2IEpTcOU0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id A2308A40E0B; Sun, 10 Nov 2024 17:10:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8DBC8C4CECD; Sun, 10 Nov 2024 17:12:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1731258757; bh=f+xJQK8qTxKaBoNsqvHUio0u/tyW7z+uPR0etrMifvo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Qb35O84S4/dlUpuzaNYBWgqQZ0NaJ/qIgDwm9VpchJBYt5mTo0XbuF04yYMQeucrf XD2smO2O1cjwLUkRXxD8KH4IKpizNfgZ29dJQBGqqGToDu5V+nvVMpRjxl466IhpLN GaIY+73kLlCkd2Y9mbMLNKLLNEyP2NJLAnZE5p4AIZgMWLyCjiW09eoSqZAbJDbM3O hK1qJaeLxMTtNitUm3MnRVVDAJiZGfnfa+Bdc4EjtRsLK0txO7C788YTqVHe/dC42h ZCejshQd6nEZ8FH1Rg61tTyclNc3uQe3EAFIzFaR5kcOL76Ik0r3iqb56QF4gOaQnW dAwboE0c5bHuA== Date: Sun, 10 Nov 2024 12:12:36 -0500 From: Mike Snitzer To: Matthew Wilcox , Andrew Morton , Christian Brauner Cc: trondmy@kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org Subject: Re: [PATCH RESEND] filemap: Fix bounds checking in filemap_read() Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 72357140006 X-Stat-Signature: zwf4cz1bwak9ax7gfd86wwyq9a7sctdi X-Rspam-User: X-HE-Tag: 1731258731-775777 X-HE-Meta: U2FsdGVkX1/KXW8lLYmrkxGoXvPrJXNGn4q3gJNHW4cNsznB4WqBtCMzl8Wf5u4V+rrEdUorSYrgk0YfMjnxvRTZWe+pu1q/ITht81d6txzXC+BT4qBlckHTG8lzjMxRX8xJ85Fu4oF2OXW0rPhgq5UNu+RGBqH6LyaOTW2WQMhVaNi04Cm8jRJboPwTf0TpZqyGIN7JP30BRMYlw3zPM5xB4oUEQh4c5fxHgHy3ZDk8mFpJZEk/eRMguy4BKZfdfNc07tBUquq9HO6QEntjAOapQQ+tW8sz1BIaAqgVVtsm8eiu6HGHIIVkqhrlidM7uUBO6dk1Kb04Es4hy7kAc5tGgIiq9cQIhbZbIOnpr/zP4gEZ1nZ633IgH6Cz+koq4L9dFn01WokRfuTNq6VZpjw/8h1WUXv06MDuD/5p+oyHAiua1caQmQIOvWsvV7ES9j89M9LqQG5apdT7y9cK3nAXBWf+5oWSPndLEgBmSdWOhI/4+c2EslOWD8nFUOQAOykLdPX6+s/AbQjGq5GmdVZ9tNcwg+aSbmNVVP0PxdZmuw4zHqFUG+EiSIL/Rcw7FciGVpPhL9L4giF1gm2GsM8WV2Da3eZ7a8qRijFlXg5xxRT3YOa/XNjGhCjC83YZsTcpN83yYqJosshxCwHuojs++h5dOkpkiSOIT3RkfD9IYHyDd/L9fUmLK2g0XSAKhAfe8Lv+DhF4RSxf0SC5ALbV0ex+RMkKlRBJ7r3aZkbTGuZHjh1vTR3lJOZHHc6OsDXjSZks5V8ECPFp1bisGog1imIf6VJa+JczpMI9AKhNePqu8ynUZfra5qAsFV22SeBlgWJHeSLLrmZm/CkeshtfUy5AlgfNoj9mef1KOHrqsbH+pJaYm8juKmkNVCt5zQ3cKaM3vg8cMSbtxJEC5kliOcKiLdLinPs2b0bdZFcz1RKkm6pjCOUTAPui58UPsC4tCoNUyjvI/pELYEg BB14+6D5 cIgwvym/N2aORhGHWrxpVAz7bRkYeVhlBwhr4YZpq9Q3Na/hms8wZo5sx2KvJSe+N4iOZPNZsXEbEDjnFP2raQIcYHD7tiYM69MpWaWBQGATamYqqKI/N/1AOhPYABWyD+5g+wJxQmAlIGex06jrp9aEb/37xfXm4uQRTQJiZQAiOlxJk/J6hxZSxHd0Brurfx4yD49rYPPm28HgN8gIjSQjbBOvj8qHWMZtoqQ6o82yVXO+tMcKfsAq6XuCAPxq/hv8w1QhZMDGsIUW/RKkBCNYgdaq4kfCk5PDOkLLQEKTuZhaRdDk8AzQa5DqtNlirWNz56opZHCL3wla0PKHahumm7rBjfqj7Q4MabCkIqS9p+hjzaeUe4MswuLmcgrOHvPOA X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Oct 25, 2024 at 08:32:57AM -0400, trondmy@kernel.org wrote: > From: Trond Myklebust > > If the caller supplies an iocb->ki_pos value that is close to the > filesystem upper limit, and an iterator with a count that causes us to > overflow that limit, then filemap_read() enters an infinite loop. > > This behaviour was discovered when testing xfstests generic/525 with the > "localio" optimisation for loopback NFS mounts. > > Reported-by: Mike Snitzer > Fixes: c2a9737f45e2 ("vfs,mm: fix a dead loop in truncate_inode_pages_range()") > Tested-by: Mike Snitzer > Signed-off-by: Trond Myklebust > --- > mm/filemap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/filemap.c b/mm/filemap.c > index 36d22968be9a..56fa431c52af 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -2625,7 +2625,7 @@ ssize_t filemap_read(struct kiocb *iocb, struct iov_iter *iter, > if (unlikely(!iov_iter_count(iter))) > return 0; > > - iov_iter_truncate(iter, inode->i_sb->s_maxbytes); > + iov_iter_truncate(iter, inode->i_sb->s_maxbytes - iocb->ki_pos); > folio_batch_init(&fbatch); > > do { > -- > 2.47.0 > > Hi, This mm fix is still needed for 6.12. Otherwise we're exposed to an infinite loop that is easily triggered by xfstests generic/525 when running against 6.12's new NFS LOCALIO feature. The irony of the original "dead loop" fix (commit c2a9737f45e2) itself having introduced the potential for infinite loop is amusing. Thanks, Mike