Message ID | 20221125070959.49027-1-zhangjiachen.jaycee@bytedance.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp3821601wrr; Thu, 24 Nov 2022 23:15:23 -0800 (PST) X-Google-Smtp-Source: AA0mqf5PsWbBXNbUM4Y6p/sV7UcOIPpl9NI/kuG6RHuXfX7Vj5p7JZLXI5sFkDc7GrWPkzckr5U3 X-Received: by 2002:a05:6402:4:b0:463:cb99:5c8 with SMTP id d4-20020a056402000400b00463cb9905c8mr33428914edu.395.1669360523282; Thu, 24 Nov 2022 23:15:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669360523; cv=none; d=google.com; s=arc-20160816; b=042r/k3bMcTV1rFkgNqSOIy19fh2xm7SEcfhAQXsEX8UH8ferj0gYUiC6cEcBdKLEe C+P/LXHbm8gLNoMdC9PN08e0PGpq5TeyMMILx9dR/O05cJ8MFRt6UsXfFxHD+unZ5XAI FkcjShfgbRzdJ4sscYzKu5+9p4KwmzABShDkxlk+pLZ/pc0ljZuAA2fAmFiXW0xGRC/m p87O138zY947XtxM6i00+rvBYUAXuE4+Mv7s4nsH8QvNguBREuIHbKFYYx0g5m3eTPia Uu/7MOfaWddlEMKivyHCyMsnQvEpx1i9MGUrpEttv8bW6qu3xnOOEeuwx+Tr/w/OVv+h tsmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=lpI09D4mWcHJ7/K+doiGSv8YTaJguLCmdZoe5Iuc0aI=; b=YjxTQnMNVF998xV2GHzyHql9gx9xSuTaBhz4SUEbBP8eXpgee8DSYixG5R26hBYmT3 V86joMZ4fcY3Zh31SNSJzlEYeUxicBD1LWQanWWX3yNM9xZtNqBZJ4vKI6wxme9Xpb0Z gPlYFeoO2fIecjAaY+N9jPo517bx8Tun6o7Cu/RP44WU8JYfTJ2lVcun3oUAkiX4gwby RYysMKiAZU2l/UZTAyg6bYwLNYieDJbloiJ6Oyx5DEud0RzmzMvh8YQhphD82RLIRgTh KZ7KFZyp635osqvIlMxAg0wCEc1gZLZTBv0axSPzUamI6go+CP6XIhz+jrt4AvUvz8+h rNPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=Dp9qdYV3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k20-20020a508ad4000000b00461c43d1113si1791922edk.569.2022.11.24.23.14.58; Thu, 24 Nov 2022 23:15:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=Dp9qdYV3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229469AbiKYHKh (ORCPT <rfc822;zxc52fgh@gmail.com> + 99 others); Fri, 25 Nov 2022 02:10:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36518 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229455AbiKYHKg (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 25 Nov 2022 02:10:36 -0500 Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78BC6218A9 for <linux-kernel@vger.kernel.org>; Thu, 24 Nov 2022 23:10:35 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id jn7so3214777plb.13 for <linux-kernel@vger.kernel.org>; Thu, 24 Nov 2022 23:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=lpI09D4mWcHJ7/K+doiGSv8YTaJguLCmdZoe5Iuc0aI=; b=Dp9qdYV3Qk2KwfyXvm+XfGzKSUxj0sUur9Ht8R5nXrw3GNf57sNHPQO1lNfJ/yj5ks ixg6x1HISo5F3qibG9UOBzghU/3isXfTPfG4g+x8+xMdBVSY1OHeJ9t7P0Wv9USubbbP UrYZzT5galnrH7u280HXSGOXCA7/cGSIdN+zsa9PPRI1YTjBzgolztLkYZaHENa14AZI dl388W8iHhl+E3sJz1VZq+9TXkYe6QZQKYQlo+rd/gZUP9rbL+X50IlBbFf/3adj1nWA Uan/AzmsYhiABaYo8ywM4yGvKm5k1/C1Br5pVoAxnFPJgKHLqMeUxJU9v0pgG2LvIvW8 cDTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lpI09D4mWcHJ7/K+doiGSv8YTaJguLCmdZoe5Iuc0aI=; b=QZnYlzlLpaJkqK6KrRH1qqRYT7M3VKAwtCast3tD8XE4YKE8A2XzgUK/rammUgIjx3 N1FemkMknLvwzRfNNXIBuNM1DTNXLOtXH4u/Z0h84ysPa2pwcOM228EXsbSRWwgj4ZfX rq5fmdZPdhD1JPTKpk0KmYMd2cktwLX5bZkZOfxUvOqdqNJatXd4gqR0cFnGjD74KLND PL8U4QZePsj0XsnN87H9qKjKQxnlkJb/uIl100qGR6lpGkdm8P4mpYIVkKDnTGrjkJkU ltXcPSrA9Lne8QMi1g17SFJoyJMB0AQRkeWqqcjFYVmdFAwo4bXt2na+7mcEQV0jBzoS iHeQ== X-Gm-Message-State: ANoB5pnWQWHmDxM21jyXM+cqxgP758mZqgj2s/uO6m/K4V3xA2rgC+xX P3NXAckm/zXLm5u1gH0IsLw5nA== X-Received: by 2002:a17:902:c611:b0:189:58a6:851d with SMTP id r17-20020a170902c61100b0018958a6851dmr6900338plr.146.1669360234978; Thu, 24 Nov 2022 23:10:34 -0800 (PST) Received: from localhost.localdomain ([139.177.225.238]) by smtp.gmail.com with ESMTPSA id a5-20020a170902710500b0017d97d13b18sm2555352pll.65.2022.11.24.23.10.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Nov 2022 23:10:34 -0800 (PST) From: Jiachen Zhang <zhangjiachen.jaycee@bytedance.com> To: "Matthew Wilcox (Oracle)" <willy@infradead.org>, Andrew Morton <akpm@linux-foundation.org> Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, xieyongji@bytedance.com, Jiachen Zhang <zhangjiachen.jaycee@bytedance.com> Subject: [PATCH] filemap: Fix some misleading comments Date: Fri, 25 Nov 2022 15:09:59 +0800 Message-Id: <20221125070959.49027-1-zhangjiachen.jaycee@bytedance.com> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750451380087318798?= X-GMAIL-MSGID: =?utf-8?q?1750451380087318798?= |
Series |
filemap: Fix some misleading comments
|
|
Commit Message
Jiachen Zhang
Nov. 25, 2022, 7:09 a.m. UTC
The users of filemap_write_and_wait_range() and file_write_and_wait_range()
interfaces should set the lend parameter to LLONG_MAX, rather than -1, to
indicate they want to writeback to the very end-of-file, as several kernel
code paths are checking the 'wbc->range_end == LLONG_MAX' conditions.
Signed-off-by: Jiachen Zhang <zhangjiachen.jaycee@bytedance.com>
---
mm/filemap.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
Comments
On Fri, 25 Nov 2022 15:09:59 +0800 Jiachen Zhang <zhangjiachen.jaycee@bytedance.com> wrote: > The users of filemap_write_and_wait_range() and file_write_and_wait_range() > interfaces should set the lend parameter to LLONG_MAX, rather than -1, to > indicate they want to writeback to the very end-of-file, as several kernel > code paths are checking the 'wbc->range_end == LLONG_MAX' conditions. Unclear. LLONG_MAX differs from -1 on 64-bit and differs differently on 32-bit. > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -661,7 +661,8 @@ EXPORT_SYMBOL_GPL(filemap_range_has_writeback); > * Write out and wait upon file offsets lstart->lend, inclusive. > * > * Note that @lend is inclusive (describes the last byte to be written) so > - * that this function can be used to write to the very end-of-file (end = -1). > + * that this function can be used to write to the very end-of-file (@lend = > + * LLONG_MAX). > * The write(2) manpage says "According to POSIX.1, if count is greater than SSIZE_MAX, the result is implementation-defined; see NOTES for the upper limit on Linux." And filemap_fdatawrite_wbc() enforces LONG_MAX, which differs from LLONG_MAX on 32-bit. I suspect more research is needed here.
On Sat, Nov 26, 2022 at 8:52 AM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Fri, 25 Nov 2022 15:09:59 +0800 Jiachen Zhang <zhangjiachen.jaycee@bytedance.com> wrote: > > > The users of filemap_write_and_wait_range() and file_write_and_wait_range() > > interfaces should set the lend parameter to LLONG_MAX, rather than -1, to > > indicate they want to writeback to the very end-of-file, as several kernel > > code paths are checking the 'wbc->range_end == LLONG_MAX' conditions. > > Unclear. LLONG_MAX differs from -1 on 64-bit and differs differently > on 32-bit. > I think whether using -1 or LLONG_MAX causes no difference if there is no other code comparing 'wbc->range_end == LLONG_MAX'. There is no case in the kernel code using -1 for now, but maybe we'd better fix the misleading comments to prevent future misuse. > > --- a/mm/filemap.c > > +++ b/mm/filemap.c > > @@ -661,7 +661,8 @@ EXPORT_SYMBOL_GPL(filemap_range_has_writeback); > > * Write out and wait upon file offsets lstart->lend, inclusive. > > * > > * Note that @lend is inclusive (describes the last byte to be written) so > > - * that this function can be used to write to the very end-of-file (end = -1). > > + * that this function can be used to write to the very end-of-file (@lend = > > + * LLONG_MAX). > > * > > The write(2) manpage says "According to POSIX.1, if count is greater > than SSIZE_MAX, the result is implementation-defined; see NOTES for the > upper limit on Linux." And filemap_fdatawrite_wbc() enforces LONG_MAX, > which differs from LLONG_MAX on 32-bit. > > I suspect more research is needed here. The reason 'wbc.nr_to_write' might be set to LONG_MAX for filemap_fdatawrite_wbc() might be because 'nr_to_write' is defined as the 'long' type. Maybe it should be fine as 'lend' and 'range_end' are defined as type 'off_t'. Thanks, Jiachen
diff --git a/mm/filemap.c b/mm/filemap.c index 65eee6ec1066..c6d066a39425 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -661,7 +661,8 @@ EXPORT_SYMBOL_GPL(filemap_range_has_writeback); * Write out and wait upon file offsets lstart->lend, inclusive. * * Note that @lend is inclusive (describes the last byte to be written) so - * that this function can be used to write to the very end-of-file (end = -1). + * that this function can be used to write to the very end-of-file (@lend = + * LLONG_MAX). * * Return: error status of the address space. */ @@ -758,7 +759,8 @@ EXPORT_SYMBOL(file_check_and_advance_wb_err); * Write out and wait upon file offsets lstart->lend, inclusive. * * Note that @lend is inclusive (describes the last byte to be written) so - * that this function can be used to write to the very end-of-file (end = -1). + * that this function can be used to write to the very end-of-file (@lend = + * LLONG_MAX). * * After writing out and waiting on the data, we check and advance the * f_wb_err cursor to the latest value, and return any errors detected there.