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 976BEC4321E for ; Sat, 26 Nov 2022 03:28:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 915E96B0071; Fri, 25 Nov 2022 22:28:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8C5F26B0073; Fri, 25 Nov 2022 22:28:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 78D5C6B0074; Fri, 25 Nov 2022 22:28:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 6998F6B0071 for ; Fri, 25 Nov 2022 22:28:52 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 398AB40923 for ; Sat, 26 Nov 2022 03:28:52 +0000 (UTC) X-FDA: 80174161704.07.0A5A64F Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by imf14.hostedemail.com (Postfix) with ESMTP id B8D63100008 for ; Sat, 26 Nov 2022 03:28:49 +0000 (UTC) Received: by mail-pf1-f177.google.com with SMTP id a16so5207527pfg.4 for ; Fri, 25 Nov 2022 19:28:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.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=j5Q0CkdkqL9ImdAVIDGKbxO6HhGOHH4+dcxvWGaloTI=; b=vQcrIjz+iAM4/+6KK9dOteBewZBvvuRjY78MAP7M2DIEwDl8oHKd3zWvIBxPymedBf w5Rl+FKB5mm8EamXRDV2s8ZYZC+OjgCQw1bcgYORXysDXExH5CA7rLzA/KYSrSm1Ki66 4ckYtkPBNi9EFEaqe2ZXhZpQ5igywGjXmEqbiEfDl9f9b92Tj8X8uNIC99qorP1ATkTH o3j9q5Nl6x0hT7VrvpvS/cc8j6q1tTP3NQWvdftuplhsVIwaKyBSymofiBuEpuqtp3KT c4HcAoi1GGw845MdrJMfDChzoMSR0m3RJMQC5vrR4sE/NwzJNDaGvNfDHE+iM6vBibim EprQ== 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=j5Q0CkdkqL9ImdAVIDGKbxO6HhGOHH4+dcxvWGaloTI=; b=c7FfH++PWGBDc95F2b68pO2oURA5JHl70HmH2s4xwrBdssgv/CZgFzEL5s2qYzcYDd e0+dSPz8PrAHRlrKxsY6bDoxrZmPa9amK3w6w/oxa+PIBmIBXATU5Z7RkMSQO8D5wpB+ FiYvoYKk2xoe2DRVPWb3tJ/kg1NSS8S0EOjV1zWVEVeSnijL8XBj6nmCGTSDLGouywh7 LmuzFbMgvnGhIb4goUKP4fmvIFyDgDHVMNB9KGyMwHK8GPQSOav6dA3mnJNKvj316Gpg pWzVAhQK1DTVMYI0qp3MaaOkJhGs6tlxGPpeBjQd6TqRGBbbcju7rrx6sFSdKHeS+yiM l1hA== X-Gm-Message-State: ANoB5pkg3YQ2ae4D2wu4mZ7O89i4o04Ov8vx4XZ/3hzxesoBomDxqIWq GidLH640wKZ+IlxuTy7yafM5DiFTaNUT7B/oS7pumg== X-Google-Smtp-Source: AA0mqf6YrmynoSeLWrq1OCN23+0Rw6OG8maifO+H3HCjpykKHdKuyYwAhZaS6xlcO7VtSexNJ9pGce/dN9tHv7AhpWA= X-Received: by 2002:a05:6a00:c5:b0:56b:a4f6:e030 with SMTP id e5-20020a056a0000c500b0056ba4f6e030mr23264033pfj.85.1669433328402; Fri, 25 Nov 2022 19:28:48 -0800 (PST) MIME-Version: 1.0 References: <20221125070959.49027-1-zhangjiachen.jaycee@bytedance.com> <20221125165242.a33918e30cc9dc70750ed95f@linux-foundation.org> In-Reply-To: <20221125165242.a33918e30cc9dc70750ed95f@linux-foundation.org> From: Jiachen Zhang Date: Sat, 26 Nov 2022 11:28:37 +0800 Message-ID: Subject: Re: [External] Re: [PATCH] filemap: Fix some misleading comments To: Andrew Morton Cc: "Matthew Wilcox (Oracle)" , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, xieyongji@bytedance.com 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=1669433330; 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=j5Q0CkdkqL9ImdAVIDGKbxO6HhGOHH4+dcxvWGaloTI=; b=8JZ5gQHxCWHh04+7YgnVLUN7+Lv5CmEZZM9g9ZmFr5AYMInAWYWNpa4gL0kVPXOCn2oQt3 BO+814c1+eJJ64dUQ93AQ5v/+z3UVOPAdxAoyLigRqX+Jxupy/yeB6Riw13eD9ivhDOKy0 HkAOv2CRph0ptVyZujdc78ruMgE0gP0= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=vQcrIjz+; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf14.hostedemail.com: domain of zhangjiachen.jaycee@bytedance.com designates 209.85.210.177 as permitted sender) smtp.mailfrom=zhangjiachen.jaycee@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669433330; a=rsa-sha256; cv=none; b=D/+Gai0U4N4zk7BOWopGrN40/Xkfb6xIOTvhfsSnsJbah1V1H2zgSam57UYgzoK9LsGVAe ta2rOUewFpFm//954zASKz+2WHpOYl9Votj05+qtPsldv3CMgO5Q0mCD211FipsJZVvXZm MshOFUAqhdWpQBdGIvwP3U4e8F2Y/58= X-Rspam-User: Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=vQcrIjz+; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf14.hostedemail.com: domain of zhangjiachen.jaycee@bytedance.com designates 209.85.210.177 as permitted sender) smtp.mailfrom=zhangjiachen.jaycee@bytedance.com X-Stat-Signature: hyrtenkfweq81nf7cdw5f83quhj4hft8 X-Rspamd-Queue-Id: B8D63100008 X-Rspamd-Server: rspam08 X-HE-Tag: 1669433329-103528 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 Sat, Nov 26, 2022 at 8:52 AM Andrew Morton wrote: > > On Fri, 25 Nov 2022 15:09:59 +0800 Jiachen Zhang 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