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 ED4C6C433FE for ; Mon, 17 Oct 2022 20:13:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 69D966B0072; Mon, 17 Oct 2022 16:13:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 64DE86B0075; Mon, 17 Oct 2022 16:13:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 517F26B0078; Mon, 17 Oct 2022 16:13:06 -0400 (EDT) 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 4368C6B0072 for ; Mon, 17 Oct 2022 16:13:06 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0F2A81C665E for ; Mon, 17 Oct 2022 20:13:06 +0000 (UTC) X-FDA: 80031540372.27.110F422 Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by imf01.hostedemail.com (Postfix) with ESMTP id B664240047 for ; Mon, 17 Oct 2022 20:13:05 +0000 (UTC) Received: by mail-yb1-f169.google.com with SMTP id 203so14573589ybc.10 for ; Mon, 17 Oct 2022 13:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LaEEWFnklwaZAjd5Tk8/ac4k/IUjI6Kq8GFYJsjy+3o=; b=cQql2FbReTJUOdpvKV9ihGFnEpOtSC1OaajXoy2CU5jiealiv3+VmpDo1tqX9jUD1z IYg4VAAEf3lM/rN0D24izsaat2VIi7sRFIbDYo+QxBv5OEUgynY6XgXnTe3v8jL1StHh PSJpzq33GrbxKAnBBlvPHiAfBPtuWzcP0s5hJHlW4Myga3dtXY9UTXb4ZCfAIXNHSauw +qDoHN0hKjv2mht0lW6spmiuyKv2Ve0TPteX4LsD/MEermqUUsRwrEsqdy1NBuGizFib z++ZG9/61uYHsGdjbwS5BXaQaUnYpzwnIT5vd5y22y1D4llCU7w1TdOs2bMmB6Mp6P/G UccA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LaEEWFnklwaZAjd5Tk8/ac4k/IUjI6Kq8GFYJsjy+3o=; b=cwuZkYaQY+Q2AwA9m1KoVVocDlAIk39EWVoSRbbPqZDXJ2nOKBTCALOSnTK6V8vgMX KcNhYI4jKcmivP09HMtuNsLbD69qZXQJRblkiolphT+9xy2spgUcn/DTYmtVEkDGYSE5 puyZMo1/Fnfe0/4BOj5zF/IVr4rGJRlmTucvUgHe29g0HKdLOTr/+FEbAwKvrc2LIfen eOZBCMqiRLxg1ZHMWx0OtlzqVs/GYBosPh5jZhQtdNBP3uFnv/rXGucnY+XlAlICQof3 32aVQnhRiatyx5nL2gLisb9ymgT/D+oRzO5tK3AsCexI1zEzcz8TaOK+oLL2mJMBYv9F cibw== X-Gm-Message-State: ACrzQf1RvQAeE1wTvxwvOsqm8RaVos50RHT9MvEHlNip8zKQydPtif82 TUBvfD4qTLHSgs6fiE7yXivZSYmxNLBliY2JZHk= X-Google-Smtp-Source: AMsMyM4AHqC2gUZLCsyYa10ZgMYS/rjlu/1xXDPPG9Sfdbx8BHkdeg5leOvnug17ihKOiBbCGtiNTA5vYh/F5synjSY= X-Received: by 2002:a25:4fc1:0:b0:6bc:c570:f99e with SMTP id d184-20020a254fc1000000b006bcc570f99emr10733540ybb.58.1666037584709; Mon, 17 Oct 2022 13:13:04 -0700 (PDT) MIME-Version: 1.0 References: <20221017161800.2003-1-vishal.moola@gmail.com> <20221017161800.2003-2-vishal.moola@gmail.com> In-Reply-To: From: Vishal Moola Date: Mon, 17 Oct 2022 13:12:53 -0700 Message-ID: Subject: Re: [PATCH v3 1/2] filemap: find_lock_entries() now updates start offset To: Matthew Wilcox Cc: akpm@linux-foundation.org, hughd@google.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666037585; 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=LaEEWFnklwaZAjd5Tk8/ac4k/IUjI6Kq8GFYJsjy+3o=; b=KwQlIIaBykO4u4QAxy0v8otG5G1F6YTsQoTzHR13Z8NE4N+TfzPiaNI6Yxg9vLSUzyO6Rx OsErAZh3deJms3gXpGh9+A3FQkliWnVT+i4QA3JpEoj1wPV2Sr2VrVaE5q/cDggD2oQAeq 7xepCAFVlNgrSilJUn4GF3TChYB3gt0= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=cQql2FbR; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666037585; a=rsa-sha256; cv=none; b=F2f9XwJgH4weA4z2CR2+mhAC3OYWHadPp3uPjDiOqR/zrj50u/Y37RWOtCllSzs75cZNAh IQZgUtrFfUF6Y0tBb7aK5xv+n/WVKHwmL8kKsJg1i6Yr2e4tN/GoQ1xUzV7ghlBkeQEwIv PMTqnvVoWm3FRrDr44YJJ8qPGw6CpKY= Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=cQql2FbR; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: B664240047 X-Rspam-User: X-Stat-Signature: r5emsqsf4y175bh338hippsb9fknw7rp X-HE-Tag: 1666037585-502922 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: On Mon, Oct 17, 2022 at 12:43 PM Matthew Wilcox wrote: > > On Mon, Oct 17, 2022 at 12:37:48PM -0700, Vishal Moola wrote: > > On Mon, Oct 17, 2022 at 9:56 AM Matthew Wilcox wrote: > > > > > > On Mon, Oct 17, 2022 at 09:17:59AM -0700, Vishal Moola (Oracle) wrote: > > > > +++ b/mm/shmem.c > > > > @@ -932,21 +932,18 @@ static void shmem_undo_range(struct inode *inode, loff_t lstart, loff_t lend, > > > > > > > > folio_batch_init(&fbatch); > > > > index = start; > > > > - while (index < end && find_lock_entries(mapping, index, end - 1, > > > > + while (index < end && find_lock_entries(mapping, &index, end - 1, > > > > > > Sorry for not spotting this in earlier revisions, but this is wrong. > > > Before, find_lock_entries() would go up to (end - 1) and then the > > > index++ at the end of the loop would increment index to "end", causing > > > the loop to terminate. Now we don't increment index any more, so the > > > condition is wrong. > > > > The condition is correct. Index maintains the exact same behavior. > > If a find_lock_entries() finds a folio, index is set to be directly after > > the last page in that folio, or simply incrementing for a value entry. > > The only time index is not changed at all is when find_lock_entries() > > finds no folios, which is the same as the original behavior as well. > > Uh, right. I had the wrong idea in my head that index wouldn't increase > past end-1, but of course it can. > > > > I suggest just removing the 'index < end" half of the condition. > > > > I hadn't thought about it earlier but this index < end check seems > > unnecessary anyways. If index > end then find_lock_entries() > > shouldn't find any folios which would cause the loop to terminate. > > > > I could send an updated version getting rid of the "index < end" > > condition as well if you would like? > > Something to consider is that if end is 0 then end-1 is -1, which is > effectively infinity, and we'll do the wrong thing? So maybe just > leave it alone, and go with v3 as-is? Yeah in that case find_lock_entries() would definitely do the wrong thing. I was thinking the "end-1" could be replaced with "end" as well as removing the "index < end". But that would change the behavior of the function(s) to now deal with end inclusive rather than exclusive which may or may not be problematic. Considering that I don't see any compelling reason to eliminate the "index < end" condition. I say we go with v3 as-is if there are no problems.