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 249DBE7717D for ; Fri, 13 Dec 2024 07:27:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 865F36B0083; Fri, 13 Dec 2024 02:27:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EEB46B0085; Fri, 13 Dec 2024 02:27:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68F456B0088; Fri, 13 Dec 2024 02:27:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 473266B0083 for ; Fri, 13 Dec 2024 02:27:15 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C19614337B for ; Fri, 13 Dec 2024 07:27:14 +0000 (UTC) X-FDA: 82889102982.17.EB4145E Received: from mx0a-0064b401.pphosted.com (mx0a-0064b401.pphosted.com [205.220.166.238]) by imf15.hostedemail.com (Postfix) with ESMTP id 9A551A0004 for ; Fri, 13 Dec 2024 07:26:41 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of "prvs=20771f2a0e=lizhi.xu@windriver.com" designates 205.220.166.238 as permitted sender) smtp.mailfrom="prvs=20771f2a0e=lizhi.xu@windriver.com"; dmarc=pass (policy=reject) header.from=windriver.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734074820; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zAShO8uOGqFbhf1yPBQKY0prDANs/Am8fj4DNjovf78=; b=7VWR65lLg64jBRYz1LA5HHojX1u2F7OSfaAS8+RlDvFyr3SPR7TJ8GofiiWvh+CK6dvi6L UMbvA9ar6BalsO2/jfMOk7AzlF9dYr9amE9o61E16U2xkXP6C/qK8NKyAnUOj56F9FxzIX chqBXHalwudGHyn2qUB82wtkiRp5Xvg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734074820; a=rsa-sha256; cv=none; b=YvndjnGyG+uLMDGGMYBb9uQWMwOgLuKF2wjFhcEWETo1X615TEW8UKKVBo+yrjSoygbqVb oiWTjP/7YUX5LImPL0sQtF+MTF1kIRWxcWSyD9yKO4FdM7bMjCs83No31UfB1A5N6rGZ/u +HxPoQJW3/mUOvVT0enjWQfEeiMGZrE= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of "prvs=20771f2a0e=lizhi.xu@windriver.com" designates 205.220.166.238 as permitted sender) smtp.mailfrom="prvs=20771f2a0e=lizhi.xu@windriver.com"; dmarc=pass (policy=reject) header.from=windriver.com Received: from pps.filterd (m0250810.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BD51a1L001159; Thu, 12 Dec 2024 23:26:56 -0800 Received: from ala-exchng02.corp.ad.wrs.com (ala-exchng02.wrs.com [147.11.82.254]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 43cx1u6tx5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 12 Dec 2024 23:26:56 -0800 (PST) Received: from ALA-EXCHNG02.corp.ad.wrs.com (147.11.82.254) by ALA-EXCHNG02.corp.ad.wrs.com (147.11.82.254) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.43; Thu, 12 Dec 2024 23:26:55 -0800 Received: from pek-lpd-ccm6.wrs.com (147.11.136.210) by ALA-EXCHNG02.corp.ad.wrs.com (147.11.82.254) with Microsoft SMTP Server id 15.1.2507.43 via Frontend Transport; Thu, 12 Dec 2024 23:26:51 -0800 From: Lizhi Xu To: CC: , , , , , , , , , , Subject: Re: [PATCH] netfs: If didn't read new data then abandon retry Date: Fri, 13 Dec 2024 15:26:51 +0800 Message-ID: <20241213072651.1475826-1-lizhi.xu@windriver.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <2133166.1733759584@warthog.procyon.org.uk> References: <2133166.1733759584@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Authority-Analysis: v=2.4 cv=H/shw/Yi c=1 sm=1 tr=0 ts=675be1c0 cx=c_pps a=K4BcnWQioVPsTJd46EJO2w==:117 a=K4BcnWQioVPsTJd46EJO2w==:17 a=RZcAm9yDv7YA:10 a=20KFwNOVAAAA:8 a=_HjyD2lY4jCciDRJ1kwA:9 X-Proofpoint-ORIG-GUID: 1zFU_zYCelM2ko5GnrQK31GXHGref2uG X-Proofpoint-GUID: 1zFU_zYCelM2ko5GnrQK31GXHGref2uG X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2024-12-13_02,2024-12-12_03,2024-11-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 suspectscore=0 spamscore=0 clxscore=1011 impostorscore=0 adultscore=0 priorityscore=1501 malwarescore=0 bulkscore=0 mlxscore=0 classifier=spam authscore=0 adjust=0 reason=mlx scancount=1 engine=8.21.0-2411120000 definitions=main-2412130051 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 9A551A0004 X-Stat-Signature: 68xqch311ubyzbnh91mf4xnwpzgex98m X-Rspam-User: X-HE-Tag: 1734074801-909197 X-HE-Meta: U2FsdGVkX18bXO+etgXuuwVyVkOJZFGDXnTfUOvFVbyVrBU9iupeKodkmMk4kJbidDrDUtBeOtbX/szqscXpcgHGeD7CwCioqaWD9FSkJ/jod+Po26ZWlLQwmowdu5PdyPSkTFiS0sq/mTYlpkF0Vw+wdxsPZz6ElTi69jWJ5/6iWcyMfrtlsYZ3t8mF5GVLNcAY+FEI4LDAZu0JqLpfVQRy91BwsgpD2WyUyacFsRIEpsd9YDWecBDe6qx2QFBVQek1hPHjRmqyGsYOjmm6zoIm2kU+E1Uf4AMMXmwIlStu4vutCV34sqqQFnav2AeTChmyXjHFx/tEIM7CYCjN+kvLfwd1hKlXWQefixNMi/I/qBtxYCZQyqI78XTvM5wueDzQOQFizyPByg0Wlm19NpAFYowTmvatIIiR5HrvMEKZAeBIVixhcFUjcbFCMSnG6X2bHgxjXQISjxuw1QWTfA7KLCxRxzsXaJxPa+BsOgCjU1252H63CcMz7ZAEfmQrGV8CRgTtSWIQvfMVfKEnIhf+xhbd1NqnNORxWYcZjBrxW/st8jcsjX814px4Ca+Me9++VSNb5D7aaIenoETQT5tOLbbYhShnNDv56TYmCus2kFiz4Dfk+P0IsTiPT4fZVIlkze85L8Efr1qfw9G0Mf9J48mo90Lu/IpAdfSryf/OsXWyZeZR0PjUzWOihBkYaau5/q0wo+RdPQaZmU2Bm3dIPJ0FYQCBucve/A8dpILsqF6zF2cJhvou0UMH9sujBRCEFuai7hYISeF+hloucQCaRusD9O+j/zjFRbkyajQVlptT8d5mAm//0XijOtN23BWgpwLinRTyHM4jeOTiD8+Ndh9SDu82kFtAlGJrGVEWpgvhEGR3kXkul8maGkaT7KYCAwrfmTzKkdJISoJJ9uYgBN+jHFlb8ayHYRgQ80lwPhW9NOtWH6xuqzDIbxYZUXSvSsrANy4G5NJgzgn ENiej3vO eWWBqR927mGcEBSowM30/7BF1mAlFjkNH2Qs/uYWzfKWHnf3NasAHCCKHnxeK0l12D43LWBI7UubQo+hhm68IdqHKxyLoY/iXuH/g/nBpHLjVDA1cnJPVgA4GDNk3yOya8/4uXepVvKqVUg3AM1ilHqktAWJtEYFj6I86zr1+UoFtgKZCaxzOKZTn5onDAb6Ci6nXisz5ZnP4GS+H7NeW7LY9hqYx7gR2PxwF8jj0Ttnh40NyDZTL4Z/90a3EJqNkcgwu4GfsjR3ZRco0n0NX1CQ6J/loIVnFb6kqLS6Y88T0JkIpwoKvBRStWA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000012, 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 Mon, 09 Dec 2024 15:53:04 +0000, David Howells wrote: > David > --- > commit d0906b4a4611709c02de610d3c34d6172aa28aaf > Author: David Howells > Date: Fri Nov 8 11:40:20 2024 +0800 > > netfs: Work around recursion by abandoning retry if nothing read > > syzkaller reported recursion with a loop of three calls (netfs_rreq_assess, > netfs_retry_reads and netfs_rreq_terminated) hitting the limit of the stack > during an unbuffered or direct I/O read. > > There are a number of issues: > > (1) There is no limit on the number of retries. > > (2) A subrequest is supposed to be abandoned if it does not transfer > anything (NETFS_SREQ_NO_PROGRESS), but that isn't checked under all > circumstances. > > (3) The actual root cause, which is this: > > if (atomic_dec_and_test(&rreq->nr_outstanding)) > netfs_rreq_terminated(rreq, ...); > > When we do a retry, we bump the rreq->nr_outstanding counter to > prevent the final cleanup phase running before we've finished > dispatching the retries. The problem is if we hit 0, we have to do > the cleanup phase - but we're in the cleanup phase and end up > repeating the retry cycle, hence the recursion. > > Work around the problem by limiting the number of retries. This is based > on Lizhi Xu's patch[1], and makes the following changes: > > (1) Replace NETFS_SREQ_NO_PROGRESS with NETFS_SREQ_MADE_PROGRESS and make > the filesystem set it if it managed to read or write at least one byte > of data. Clear this bit before issuing a subrequest. Will there be conflicts when reading and writing use the same flag to mark? > > (2) Add a ->retry_count member to the subrequest and increment it any time > we do a retry. > > (3) Remove the NETFS_SREQ_RETRYING flag as it is superfluous with > ->retry_count. If the latter is non-zero, we're doing a retry. > > (4) Abandon a subrequest if retry_count is non-zero and we made no > progress. > > (5) Use ->retry_count in both the write-side and the read-size. BR, Lizhi