From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 EA4EA3A1685 for ; Mon, 11 May 2026 12:44:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778503463; cv=none; b=k7VQsXmCa6LwP0DNrENnyuwyT8mBznBhFEsiZownSvkoXIwtaLst3BQSoJKe1MhtY0OVM7sFZcPOLJRty4SaQ1UKIY8lLhaiEkKwIkDbFYXK+YaXu1s8JSOGp13omKeb4TeX5cDMEWqhqJYAznGMRZGHlj3kOI0UDl7R1ULqrg0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778503463; c=relaxed/simple; bh=TQYRPqIuRJ9SBiARipZkoDO1NSpzuzn031P9qW8s+s4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Zp87+jH9aDa0RdEqX4tNI7GMMwQnKe7PYzcLQ/q4zPauKooUdTm50UkEbGSLGbhJ4bwhwejrh3uTacePq6uOzGqg6xvPtFhjhXLWLSh1qzwTFyz67ZxSlk0Yf5QCbk8Ajc/uqKchrnp3pFzQoeeFnw3QkvEPdiuY0UonqyO/ZkA= 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=hJRLNy0h; arc=none smtp.client-ip=209.85.128.54 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="hJRLNy0h" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-488ba840146so37949045e9.1 for ; Mon, 11 May 2026 05:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778503460; x=1779108260; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=bHitmBP8USNGMLAXOmkdJpRqduMwp3sFGN+yTzeTwUQ=; b=hJRLNy0hBaxFCD4No9t+y/tW2i9OPHQhf3lAU+DOutMQRT2W3mYGNkAWKky69b2CMs tq0oHUjHKeOrxHTC3EWAtikrZgMwVYbnzsAGLdkrL8BkzeJ0LSCmK43jR+UZx9yNfw4+ BV73GvLRsYKeSz0zcEf8p+XnJl9FDL0tyiBjuEi/9O3jPyYrMAjCNe2QN8lYblVI4JUO gOy3NFpOi+LlkrJKPOqWrnLoZDjWsc2tg3HN2aEL8rn1QpZBdbd+9d7a2+EulxiIiyYP +Yedbbc2SPBeAIHIxJyziA75GwygqDx7/q6WymlwBjDEXc8LO1EFDdSCJvoKXX19UO40 3I6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778503460; x=1779108260; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bHitmBP8USNGMLAXOmkdJpRqduMwp3sFGN+yTzeTwUQ=; b=jbmW70IlQhAgQ80kJZ9bakNQ5JyyO8Ik153V4X3aNz6lkdu0ldegglVyIRB+ZjCoGN PkuVUNGBD+mJPOZ/GOlAFY8vC5CxSZ/oTKXfhRORfaQnwVZ1YA2Wi9HziVfbH6Lsnxgu hD02d8+AJTRorHyf2ixzcG2ax3VSXzsK5y9l6spmCIH639tgU4P8X5t/Q5Tl+hTZZNRr 4QoqPiIkrHf4L4JU9aAF56HAG5Tci6InaFjcz6VPVlM/ftTpFrzwWKZ0Lbmtt5M4eNR2 9rULDAkBMbTSCw9DBxltZrHVRk9jfqStND+1uWy/11GokRLrjgU8ZYXtIbsN84CKHWc7 svFA== X-Forwarded-Encrypted: i=1; AFNElJ9im1VlQYZZ06JkZfRyNLhI6MtvIvcFuclWbpFlNZtAyaK7TNqcxx3ZyDQFYZ+pNctO6BofRdwApbMzEgw=@vger.kernel.org X-Gm-Message-State: AOJu0YwC4x+AmcYdMxqWxAzrC5SYYIG96rN4WX6bY2S3GSgYqMGZOZgo 7MhgieyhpXXatsdh9aaxQR54YnCqt4gg7cnt8S+YoLZnbMJ9ietZuTPe X-Gm-Gg: Acq92OGz5/sJiuPvJlA+7LyNeELJgcr1+sBm2X5Ehmx8mdXf5zbLKjHtm0nNjr3gm1c npcarlnYc86mR6oCRZxUdCgNdSp5+CL+ZgIu6RUe6GFz8yOL7TdVkGBCfuImhcakDtsIXzRJDFi UCYbSm7Q9hCPfDqmPdqTf3vFspNC7zOMwKi/LLV5r5CA2qqAK3UlB83Mv869pJVHjXu/gbEu3n+ hzoJAcGtSu/rj8jE9x0qatlMqIy+oEBFnOqNhR9je+g+JsHGhiJLtWgmQE8RYt7M0c31gQUqhkT F5RqroliNxi4DuE5oF95riytSL4Dr2wTVjvihBQAdjYFyGQeN3DeaR5oO8VlZ+AwgzbVuN4NFBB pTp2kQTPVwcmF82TmDNXHTJq+VsHO+vSfizzXC/+3XxE6TUVFFaWRXWOwW8K0ylEjOZgVie8z6u vgC4znD6n9GAUIQEhxZtpe8TAwhp0hmS5p5CMXMAx8eIopwbpA0+UPdONyTB2uKeXkjyTTXALWR weHwZ/1it+D X-Received: by 2002:a05:600c:3548:b0:485:3abe:ab86 with SMTP id 5b1f17b1804b1-48e51e0a6a2mr360497845e9.4.1778503459729; Mon, 11 May 2026 05:44:19 -0700 (PDT) Received: from fedora ([185.193.234.8]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48e702e6d41sm234731455e9.7.2026.05.11.05.44.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 May 2026 05:44:19 -0700 (PDT) Date: Mon, 11 May 2026 13:44:17 +0100 From: Vishal Moola To: Tal Zussman Cc: "Matthew Wilcox (Oracle)" , Jan Kara , Andrew Morton , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/filemap: fix page_cache_prev_miss() when no hole is found Message-ID: References: <20260510-prev_miss_fix-v1-1-755bb123145a@columbia.edu> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260510-prev_miss_fix-v1-1-755bb123145a@columbia.edu> On Sun, May 10, 2026 at 05:54:17PM -0400, Tal Zussman wrote: > page_cache_prev_miss() is documented to return a value outside the > searched range when no gap is found. However, the no-gap-found path > returns xas.xa_index, which after a successful loop is the first index > in the range. As such, that index is misreported as a gap. > > The sole caller, page_cache_sync_ra(), uses the return value to estimate > the cached run preceding a sequential read. In some cases, the buggy > return value can undercount the contiguous range by one, shrinking the > readahead window or pushing borderline requests into the > small-random-read branch. > > Mirror the fix in commit bbcaee20e03e ("readahead: fix return value of > page_cache_next_miss() when no hole is found"): preserve max_scan in a > separate variable across the loop and return `index - max_scan` from the > no-gap-found path. IMO, this way of fixing it hurts the readability. I'd prefer something similar to the fix in the original commit. Or... > - while (max_scan--) { > + while (nr--) { > void *entry = xas_prev(&xas); > if (!entry || xa_is_value(entry)) > - break; > + return xas.xa_index; > if (xas.xa_index == ULONG_MAX) > - break; > + return ULONG_MAX; > } If I understand this correctly, couldn't we just do something like: if (!max_scan) return xas.xa_index - 1; > - return xas.xa_index; > + return index - max_scan; > } > EXPORT_SYMBOL(page_cache_prev_miss); > > > --- > base-commit: e9dd96806dbc2d50a66770b6a86962bd5d601153 > change-id: 20260510-prev_miss_fix-fcb308472131 > > Best regards, > -- > Tal Zussman >