Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1008471pxp; Sun, 6 Mar 2022 03:34:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJyrihTcpg9IEgisDQRpUkDMlTrqeTmygqICFXYaTN1lb80zOTiD7YsERRTwlnAd4/nRmnrn X-Received: by 2002:a17:907:608b:b0:6da:8fa8:27e8 with SMTP id ht11-20020a170907608b00b006da8fa827e8mr5541986ejc.168.1646566491402; Sun, 06 Mar 2022 03:34:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646566491; cv=none; d=google.com; s=arc-20160816; b=0U+l6GbamowigejgDDwBBR+p8A4IdPYu9+ZChlFIrT29MEZx3QxBJAJFAq3fscPT7N ZSqgL6VkIqTzAxxropvbvtFHg9dQbSLiMcNWPLOok7EE3XfWCGAFHErqJU8s62hXPpi+ WKhGcjgW9vdQsaUyUzdkbfyakVvk6mHglu5Zfx6kgd/Ef9sCYPDQsWK5vyZmpSYL6mMP YABD7DUaeLmCD3oAvIvI/pt7WCw2AUngXYTBTLViLz1G96984WHkgKUKuShkJDki8DbQ PvQKj5j5/FhCt6gqtvhsjYlAnCc5bgJBtLkT75lKbLEqW9p9Uk36BAj56Ee5qV8pvW/B BVUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id; bh=gQwfiARkfQHvGMICiedjV7sW5fMjePrOpeYaWbynbL4=; b=Tf8aMSafEHerXcwMNXxS52OvCo97z2K+32tNj67tOZ2S64XKCzZPVI9aXU+rwejp16 /gA7RMdKVqNZT7V6JGBXKxq05lO7flPLuPctLXm6n+PJiL7skg/DTSk60fVKaeAI7LWn QaTqyeiAz7FiSZZQ7totc+5jskLRsp3JcLrdd3GXymM/OIJ1SxM9IIRLX2MmfKPHFUOo o6A7APvPwtTIVkOqt9ETtyGCZHS9X7dci3utOHh8hNX1zW6v0fwpP2/rRvOJjXgYtrqD s6dl/MSBoQWfM9RnocpuK/SVoPfM7c9/JG4ZgTw1CA8OQ36mmVWtTrnUCuVU5GJgCNFj TqOA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bv5-20020a170906b1c500b006af8cf4faa7si7007725ejb.122.2022.03.06.03.34.18; Sun, 06 Mar 2022 03:34:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-nfs-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; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231389AbiCFIvK (ORCPT + 99 others); Sun, 6 Mar 2022 03:51:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230026AbiCFIvJ (ORCPT ); Sun, 6 Mar 2022 03:51:09 -0500 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6BFAA6580B; Sun, 6 Mar 2022 00:50:17 -0800 (PST) Received: from kwepemi100002.china.huawei.com (unknown [172.30.72.57]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4KBFXp1MZhz1GBwq; Sun, 6 Mar 2022 16:45:30 +0800 (CST) Received: from kwepemm600015.china.huawei.com (7.193.23.52) by kwepemi100002.china.huawei.com (7.221.188.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Sun, 6 Mar 2022 16:50:14 +0800 Received: from [10.174.176.52] (10.174.176.52) by kwepemm600015.china.huawei.com (7.193.23.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Sun, 6 Mar 2022 16:50:14 +0800 Message-ID: <1789b0d7-edc1-8c66-602b-2ca66de7a2be@huawei.com> Date: Sun, 6 Mar 2022 16:50:13 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Subject: Re: [PATCH -next 2/2] nfs: nfs_file_write() check writeback errors correctly To: Trond Myklebust , "anna@kernel.org" , "smayhew@redhat.com" CC: "linux-nfs@vger.kernel.org" , "liuyongqiang13@huawei.com" , "linux-kernel@vger.kernel.org" , "yi.zhang@huawei.com" , "zhangxiaoxu5@huawei.com" References: <20220305124636.2002383-1-chenxiaosong2@huawei.com> <20220305124636.2002383-3-chenxiaosong2@huawei.com> <461aafe64a56836b8d248556052f8d00b6d37731.camel@hammerspace.com> From: "chenxiaosong (A)" In-Reply-To: <461aafe64a56836b8d248556052f8d00b6d37731.camel@hammerspace.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.176.52] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemm600015.china.huawei.com (7.193.23.52) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE 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: X-Mailing-List: linux-nfs@vger.kernel.org filemap_sample_wb_err() -> errseq_sample() initialise errseq_t variable `since`, the caller of this function will checks for an error using filemap_check_wb_err(since) -> errseq_check(). filemap_sample_wb_err's purpose is just sampling consumed (seen) writeback error to initialise errseq_t variable. I understand that filemap_sample_wb_err()/filemap_check_wb_err() cannot detect the new error between filemap_sample_wb_err() and filemap_check_wb_err(). It would be better using file->f_mapping->wb_err instead of filemap_sample_wb_err() in nfs_file_write() to sample wb_err at that time point. In do_dentry_open(), we just sample consumed(seen) writeback error. It is necessary to consume the writeback error before close() over. There is some cases that writeback error have not been consumed(seen) after close() file over, I think it is unexpected behavior, is this a bug? It is worth noting that fsync() will not be called after close() in nfs. 在 2022/3/6 1:12, Trond Myklebust 写道: > Hmm... Why isn't this considered a bug with filemap_sample_wb_err()? If > what you say is true, then do_dentry_open() could be picking up > existing errors from the filesystem and from the inode and propagating > them to random processes. > > It basically means everyone who cares about correctness of the error > return values needs to do a fsync() immediately after open() in order > to sync up the value in file->f_wb_err. >