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 lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DC682D35E5D for ; Wed, 6 Nov 2024 02:40:31 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-3.v29.lw.sourceforge.com) by sfs-ml-3.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1t8VyB-0002Ym-L4; Wed, 06 Nov 2024 02:40:31 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-3.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1t8VyA-0002Yd-9r for linux-f2fs-devel@lists.sourceforge.net; Wed, 06 Nov 2024 02:40:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: From:References:To:Subject:Cc:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=sX6RenEb6/B+r2jyxR18w0Q6Fpjt5XtDTXb3aRqB9as=; b=TEo2mc/MO3iFH2woF1o27PdvO8 sDMrBQZBjBOT7mrz+XGRNzVxzfmnR3eSlwCGYH7tNSIRZH2qPzavVcB/qEc/J8P/W+FOYytqVVuy/ 6h0bVgKYvoZUgIk1t6xD5x341B1D9OX3CpgtYdllz5h5EewjOdVMDursYpk5g8V8niBU=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:To: Subject:Cc:MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=sX6RenEb6/B+r2jyxR18w0Q6Fpjt5XtDTXb3aRqB9as=; b=bCWVMJxGNGm/bnhH+n8tllpVkp lG0OPW20+VUu+v7tqWfpE+tjl1hUEVow1YuIXYzbodvfrYkSM7Zd7UNW5q/q+Lf6mxSgTaio/tqn7 EUDEY55Dy842Mq8b23opFKbrmIPdmJdteSzb7OXXCCdJE5hvgaiR7tvXNFGuvxkCzf6M=; Received: from nyc.source.kernel.org ([147.75.193.91]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1t8Vy8-0002M8-QB for linux-f2fs-devel@lists.sourceforge.net; Wed, 06 Nov 2024 02:40:29 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id EC56DA41BE1; Wed, 6 Nov 2024 02:38:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8AB95C4CECF; Wed, 6 Nov 2024 02:40:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730860822; bh=8skSwEKa2BJdI+HdH5Bnq08Ua01XRXyPvb6CEc1N0+o=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=WWXLSvRTbUiPWWKtMytVIOms90KKpuZmDWJjG5XKjv3F4uI0pAzyM1IYTigynUanc EqvLbwa86M5kudGz8nuZbG+NlUIw+TGFetghuLiPIbmCcImZIIJWIHX4oDo8zG85OF ZZYVaAMIDQDEk5EtfhRfpkGr60JvP8PoDFZnU8SJcfzM4kOgZZ0JAC/8YnhdhonLdB ylzR5W2Os02g4AWb3yH2dg3vQAMX4r+Wh7GjnKZITsn9y+jOgCsrMSYnwWATTfFCJN KVimjE8sw7F8EbIdmsRHD5z+uTdR9Fxg2AoouH2PPRFem5z7+5yePqOCbv131hqZMs lg3KzOj4JVdaQ== Message-ID: Date: Wed, 6 Nov 2024 10:40:17 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Zhiguo Niu References: <1730685372-2995-1-git-send-email-zhiguo.niu@unisoc.com> <22873055-370b-4240-83ff-96bcfa91413a@kernel.org> <9199e9fc-7b5b-4069-b79b-65ba5ae1b0f6@kernel.org> Content-Language: en-US In-Reply-To: X-Headers-End: 1t8Vy8-0002M8-QB Subject: Re: [f2fs-dev] [PATCH V2] f2fs: fix to adjust appropriate length for fiemap X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Chao Yu via Linux-f2fs-devel Reply-To: Chao Yu Cc: ke.wang@unisoc.com, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Zhiguo Niu , jaegeuk@kernel.org, Hao_hao.Wang@unisoc.com Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net T24gMjAyNC8xMS82IDEwOjI2LCBaaGlndW8gTml1IHdyb3RlOgo+IENoYW8gWXUgPGNoYW9Aa2Vy bmVsLm9yZz4g5LqOMjAyNOW5tDEx5pyINuaXpeWRqOS4iSAxMDoxNuWGmemBk++8mgo+Pgo+PiBP biAyMDI0LzExLzUgMTk6MDIsIFpoaWd1byBOaXUgd3JvdGU6Cj4+PiBDaGFvIFl1IDxjaGFvQGtl cm5lbC5vcmc+IOS6jjIwMjTlubQxMeaciDXml6XlkajkuowgMTg6MznlhpnpgZPvvJoKPj4+Pgo+ Pj4+IE9uIDIwMjQvMTEvNSAxNToyOCwgWmhpZ3VvIE5pdSB3cm90ZToKPj4+Pj4gQ2hhbyBZdSA8 Y2hhb0BrZXJuZWwub3JnPiDkuo4yMDI05bm0MTHmnIg15pel5ZGo5LqMIDE1OjA05YaZ6YGT77ya Cj4+Pj4+Pgo+Pj4+Pj4gT24gMjAyNC8xMS80IDk6NTYsIFpoaWd1byBOaXUgd3JvdGU6Cj4+Pj4+ Pj4gSWYgdXNlciBnaXZlIGEgZmlsZSBzaXplIGFzICJsZW5ndGgiIHBhcmFtZXRlciBmb3IgZmll bWFwCj4+Pj4+Pj4gb3BlcmF0aW9ucywgYnV0IGlmIHRoaXMgc2l6ZSBpcyBub24tYmxvY2sgc2l6 ZSBhbGlnbmVkLAo+Pj4+Pj4+IGl0IHdpbGwgc2hvdyAyIHNlZ21lbnRzIGZpZW1hcCByZXN1bHRz IGV2ZW4gdGhpcyB3aG9sZSBmaWxlCj4+Pj4+Pj4gaXMgY29udGlndW91cyBvbiBkaXNrLCBzdWNo IGFzIHRoZSBmb2xsb3dpbmcgcmVzdWx0czoKPj4+Pj4+Pgo+Pj4+Pj4+ICAgICAgLi9mMmZzX2lv IGZpZW1hcCAwIDE5MDM0IHlsb2cvYW5hbHl6ZXIucHkKPj4+Pj4+PiBGaWVtYXA6IG9mZnNldCA9 IDAgbGVuID0gMTkwMzQKPj4+Pj4+PiAgICAgICAgICAgICBsb2dpY2FsIGFkZHIuICAgIHBoeXNp Y2FsIGFkZHIuICAgbGVuZ3RoICAgICAgICAgICBmbGFncwo+Pj4+Pj4+IDAgICAgICAgMDAwMDAw MDAwMDAwMDAwMCAwMDAwMDAwMDIwYmFhMDAwIDAwMDAwMDAwMDAwMDQwMDAgMDAwMDEwMDAKPj4+ Pj4+PiAxICAgICAgIDAwMDAwMDAwMDAwMDQwMDAgMDAwMDAwMDAyMGJhZTAwMCAwMDAwMDAwMDAw MDAxMDAwIDAwMDAxMDAxCj4+Pj4+Pj4KPj4+Pj4+PiBhZnRlciB0aGlzIHBhdGNoOgo+Pj4+Pj4+ IC4vZjJmc19pbyBmaWVtYXAgMCAxOTAzNCB5bG9nL2FuYWx5emVyLnB5Cj4+Pj4+Pj4gRmllbWFw OiBvZmZzZXQgPSAwIGxlbiA9IDE5MDM0Cj4+Pj4+Pj4gICAgICAgICBsb2dpY2FsIGFkZHIuICAg IHBoeXNpY2FsIGFkZHIuICAgbGVuZ3RoICAgICAgICAgICBmbGFncwo+Pj4+Pj4+IDAgICAgMDAw MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDMxNWYzMDAwIDAwMDAwMDAwMDAwMDUwMDAgMDAwMDEwMDEK Pj4+Pj4+Pgo+Pj4+Pj4+IFNpZ25lZC1vZmYtYnk6IFpoaWd1byBOaXUgPHpoaWd1by5uaXVAdW5p c29jLmNvbT4KPj4+Pj4+PiAtLS0KPj4+Pj4+PiBWMjogY29ycmVjdCBjb21taXQgbXNnIGFjY29y ZGluZyB0byBDaGFvJ3MgcXVlc3Rpb25zCj4+Pj4+Pj4gZjJmc19pbyBoYXMgYmVlbiBtb2RpZmll ZCBmb3IgdGVzdGluZywgdGhlIGxlbmd0aCBmb3IgZmllbWFwIGlzCj4+Pj4+Pj4gcmVhbCBmaWxl IHNpemUsIG5vdCBibG9jayBudW1iZXIKPj4+Pj4+PiAtLS0KPj4+Pj4+PiAgICAgIGZzL2YyZnMv ZGF0YS5jIHwgNCArKy0tCj4+Pj4+Pj4gICAgICAxIGZpbGUgY2hhbmdlZCwgMiBpbnNlcnRpb25z KCspLCAyIGRlbGV0aW9ucygtKQo+Pj4+Pj4+Cj4+Pj4+Pj4gZGlmZiAtLWdpdCBhL2ZzL2YyZnMv ZGF0YS5jIGIvZnMvZjJmcy9kYXRhLmMKPj4+Pj4+PiBpbmRleCAzMDZiODZiMC4uOWZjMjI5ZCAx MDA2NDQKPj4+Pj4+PiAtLS0gYS9mcy9mMmZzL2RhdGEuYwo+Pj4+Pj4+ICsrKyBiL2ZzL2YyZnMv ZGF0YS5jCj4+Pj4+Pj4gQEAgLTE5NjYsOCArMTk2Niw4IEBAIGludCBmMmZzX2ZpZW1hcChzdHJ1 Y3QgaW5vZGUgKmlub2RlLCBzdHJ1Y3QgZmllbWFwX2V4dGVudF9pbmZvICpmaWVpbmZvLAo+Pj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBnb3RvIG91dDsKPj4+Pj4+PiAgICAgICAgICB9 Cj4+Pj4+Pj4KPj4+Pj4+PiAtICAgICBpZiAoYnl0ZXNfdG9fYmxrcyhpbm9kZSwgbGVuKSA9PSAw KQo+Pj4+Pj4+IC0gICAgICAgICAgICAgbGVuID0gYmxrc190b19ieXRlcyhpbm9kZSwgMSk7Cj4+ Pj4+Pj4gKyAgICAgaWYgKGxlbiAmIChibGtzX3RvX2J5dGVzKGlub2RlLCAxKSAtIDEpKQo+Pj4+ Pj4+ICsgICAgICAgICAgICAgbGVuID0gcm91bmRfdXAobGVuLCBibGtzX3RvX2J5dGVzKGlub2Rl LCAxKSk7Cj4+Pj4+Pgo+Pj4+Pj4gSG93IGRvIHlvdSB0aGluayBvZiBnZXR0aW5nIHJpZCBvZiBh Ym92ZSBhbGlnbm1lbnQgZm9yIGxlbj8KPj4+Pj4+Cj4+Pj4+Pj4KPj4+Pj4+PiAgICAgICAgICBz dGFydF9ibGsgPSBieXRlc190b19ibGtzKGlub2RlLCBzdGFydCk7Cj4+Pj4+Pj4gICAgICAgICAg bGFzdF9ibGsgPSBieXRlc190b19ibGtzKGlub2RlLCBzdGFydCArIGxlbiAtIDEpOwo+Pj4+Pj4K Pj4+Pj4+IEFuZCByb3VuZCB1cCBlbmQgcG9zaXRpb24gdy86Cj4+Pj4+Pgo+Pj4+Pj4gbGFzdF9i bGsgPSBieXRlc190b19ibGtzKGlub2RlLCByb3VuZF91cChzdGFydCArIGxlbiAtIDEsIEYyRlNf QkxLU0laRSkpOwo+Pj4+PiBIaSBDaGFvLAo+Pj4+PiBJIHRoaW5rIHRoaXMgd2lsbCBjaGFuZ2Ug dGhlIGN1cnJlbnQgY29kZSBsb2dpYwo+Pj4+PiAtLS0tLS0tLS0tLS0tCj4+Pj4+IGlmIChzdGFy dF9ibGsgPiBsYXN0X2JsaykKPj4+Pj4gICAgICAgIGdvdG8gb3V0Owo+Pj4+PiAtLS0tLS0tLS0t LS0tCj4+Pj4+IGZvciBleGFtcGxlLCBhIGZpbGUgd2l0aCBzaXplIDE5MDA2LCBidXQgdGhlIGxl bmd0aCBmcm9tIHRoZSB1c2VyIGlzIDE2Mzg0Lgo+Pj4+PiBiZWZvcmUgdGhpcyBtb2RpZmljYXRp b24sICBsYXN0X2JsayA9ICBieXRlc190b19ibGtzKGlub2RlLCBzdGFydCArCj4+Pj4+IGxlbiAt IDEpID0gKGlub2RlLCAxNjM4MykgPSAzCj4+Pj4+IGFmdGVyIHRoZSBmaXJzdCBmMmZzX21hcF9i bG9ja3MoKS4gc3RhcnRfYmxrIGNoYW5nZSB0byBiZSA0LAo+Pj4+PiBhZnRlciB0aGUgc2Vjb25k IGYyZnNfbWFwX2Jsb2NrcygpLCBmaWVtYXBfZmlsbF9uZXhfZXh0ZW4gd2lsbCBiZQo+Pj4+PiBj YWxsZWQgdG8gZmlsbCB1c2VyIHBhcmFtZXRlciBhbmQgdGhlbgo+Pj4+PiB3aWxsIGdvdG8gb3V0 IGJlY2F1c2Ugc3RhcnRfYmxrID4gbGFzdF9ibGssIHRoZW4gZmllbWFwIGZsb3cgZmluaXNoZXMu Cj4+Pj4+IGJ1dCBhZnRlciB0aGlzIG1vZGlmaWNhdGlvbiwgbGFzdF9ibGsgd2lsbCBiZSA0Cj4+ Pj4+IHdpbGwgZG8gZjJmc19tYXBfYmxvY2tzKCkgdW50aWwgcmVhY2ggdGhlIG1heF9maWxlX2Js b2Nrcyhpbm9kZSkKPj4+Pgo+Pj4+IFllcywgeW91J3JlIHJpZ2h0LCBob3dldmVyLCB3LyB0aGlz IHBhdGNoLCBpdCBtYXkgY2hhbmdlIGxhc3RfYmxrLCBlLmcuCj4+Pj4KPj4+PiB4ZnNfaW8gZmls ZSAtYyAiZmllbWFwIC12IDAgMTkwMDYiIHZzIHhmc19pbyBmaWxlIC1jICJmaWVtYXAgLXYgMiAx OTAwNiIKPj4+PiBzdGFydF9ibGsgYW5kIGxhc3RfYmxrIHdpbGwgYmU6IDAsIDQgYW5kIDAsIDUu Cj4+PiBIaSBDaGFvLAo+Pj4geWVzLCBidXQgdy9vIHRoaXMgcGF0Y2ggLCB0aGUgb3JpZ2luYWwg Y29kZSBzdGlsbCBoYXMgdGhlIHNhbWUgc2l0dWF0aW9uPz8KPj4+IGZvciBleGFtcGxlCj4+PiB4 ZnNfaW8gZmlsZSAtYyAiZmllbWFwIC12IDAgMTYzODQiIHZzIHhmc19pbyBmaWxlIC1jICJmaWVt YXAgLXYgMiAxNjM4NCIKPj4+IHN0YXJ0X2JsayBhbmQgbGFzdF9ibGsgd2lsbCBiZTogMCwgMyBh bmQgMCwgNC4KPj4KPj4gRm9yIHRoZSBjYXNlICJmaWVtYXAgLXYgMiAxOTAwNiIsIG9mZnNldCBp cyAyLCBhbmQgbGVuZ3RoIGlzIDE5MDA2LCBzbyBsYXN0X29mZnNldAo+PiBpcyAxOTAwOCwgYW5k IGxhc3RfYmxrIHNob3VsZCBiZSA0IHJhdGhlciB0aGFuIDUsIHJpZ2h0Pwo+IGhpIENoYW8sCj4g aXQgaXMgcmlnaHQgdy9vIG15IHBhdGNoLgo+Pgo+PiBBbmQgZm9yIHlvdSBjYXNlLCBpdCBjYWxj dWxhdGVzIGxhc3RfYmxrIGNvcnJlY3RseS4KPiBTbyB5b3Ugc3VnZ2VzdCB0aGF0ICJTaG91bGQg d2Ugcm91bmRfdXAgbGVuIGFmdGVyIHN0YXJ0X2JsayAmIGxhc3RfYmxrCj4gY2FsY3VsYXRpb24/ IgoKWmhpZ3VvLAoKWWVzLCBJIHRoaW5rIGFsaWdubWVudCBvZiBsZW4gc2hvdWxkIG5vdCBhZmZl Y3QgY2FsY3VsYXRpb24gb2YgbGFzdF9ibGsuCgpJIG1lYW4gdGhpcywKCi0tLQogIGZzL2YyZnMv ZGF0YS5jICAgICAgICAgIHwgNiArKystLS0KICBpbmNsdWRlL2xpbnV4L2YyZnNfZnMuaCB8IDMg KystCiAgMiBmaWxlcyBjaGFuZ2VkLCA1IGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25zKC0pCgpk aWZmIC0tZ2l0IGEvZnMvZjJmcy9kYXRhLmMgYi9mcy9mMmZzL2RhdGEuYwppbmRleCA3ZDFiYjk1 MThhNDAuLmNiYmI5NTZmNDIwZCAxMDA2NDQKLS0tIGEvZnMvZjJmcy9kYXRhLmMKKysrIGIvZnMv ZjJmcy9kYXRhLmMKQEAgLTE5NjcsMTIgKzE5NjcsMTIgQEAgaW50IGYyZnNfZmllbWFwKHN0cnVj dCBpbm9kZSAqaW5vZGUsIHN0cnVjdCBmaWVtYXBfZXh0ZW50X2luZm8gKmZpZWluZm8sCiAgCQkJ Z290byBvdXQ7CiAgCX0KCi0JaWYgKGJ5dGVzX3RvX2Jsa3MoaW5vZGUsIGxlbikgPT0gMCkKLQkJ bGVuID0gYmxrc190b19ieXRlcyhpbm9kZSwgMSk7Ci0KICAJc3RhcnRfYmxrID0gYnl0ZXNfdG9f Ymxrcyhpbm9kZSwgc3RhcnQpOwogIAlsYXN0X2JsayA9IGJ5dGVzX3RvX2Jsa3MoaW5vZGUsIHN0 YXJ0ICsgbGVuIC0gMSk7CgorCWlmIChsZW4gJiBGMkZTX0JMS1NJWkVfTUFTSykKKwkJbGVuID0g cm91bmRfdXAobGVuLCBGMkZTX0JMS1NJWkUpOworCiAgbmV4dDoKICAJbWVtc2V0KCZtYXAsIDAs IHNpemVvZihtYXApKTsKICAJbWFwLm1fbGJsayA9IHN0YXJ0X2JsazsKZGlmZiAtLWdpdCBhL2lu Y2x1ZGUvbGludXgvZjJmc19mcy5oIGIvaW5jbHVkZS9saW51eC9mMmZzX2ZzLmgKaW5kZXggYjBi ODIxZWRmZDk3Li45NTRlOGU4MzQ0YjcgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUvbGludXgvZjJmc19m cy5oCisrKyBiL2luY2x1ZGUvbGludXgvZjJmc19mcy5oCkBAIC0yNCwxMCArMjQsMTEgQEAKICAj ZGVmaW5lIE5FV19BRERSCQkoKGJsb2NrX3QpLTEpCS8qIHVzZWQgYXMgYmxvY2tfdCBhZGRyZXNz ZXMgKi8KICAjZGVmaW5lIENPTVBSRVNTX0FERFIJCSgoYmxvY2tfdCktMikJLyogdXNlZCBhcyBj b21wcmVzc2VkIGRhdGEgZmxhZyAqLwoKKyNkZWZpbmUgRjJGU19CTEtTSVpFX01BU0sJCShGMkZT X0JMS1NJWkUgLSAxKQogICNkZWZpbmUgRjJGU19CWVRFU19UT19CTEsoYnl0ZXMpCSgoYnl0ZXMp ID4+IEYyRlNfQkxLU0laRV9CSVRTKQogICNkZWZpbmUgRjJGU19CTEtfVE9fQllURVMoYmxrKQkJ KChibGspIDw8IEYyRlNfQkxLU0laRV9CSVRTKQogICNkZWZpbmUgRjJGU19CTEtfRU5EX0JZVEVT KGJsaykJCShGMkZTX0JMS19UT19CWVRFUyhibGsgKyAxKSAtIDEpCi0jZGVmaW5lIEYyRlNfQkxL X0FMSUdOKHgpCQkJKEYyRlNfQllURVNfVE9fQkxLKCh4KSArIEYyRlNfQkxLU0laRSAtIDEpKQor I2RlZmluZSBGMkZTX0JMS19BTElHTih4KQkJKEYyRlNfQllURVNfVE9fQkxLKCh4KSArIEYyRlNf QkxLU0laRSAtIDEpKQoKICAvKiAwLCAxKG5vZGUgbmlkKSwgMihtZXRhIG5pZCkgYXJlIHJlc2Vy dmVkIG5vZGUgaWQgKi8KICAjZGVmaW5lIEYyRlNfUkVTRVJWRURfTk9ERV9OVU0JCTMKLS0gCjIu NDAuMQoKCgo+IFRoYW5rcwo+Pgo+PiBUaGFua3MsCj4+Cj4+PiBidXQgb3ZlcmFsbCBsYXN0X2Js ayB3aWxsIGNoYW5nZSBsb29wIGNvdW50cyBidXQgaGFzIG5vdCBhZmZlY3Qgb24gdGhlIHJlc3Vs dHMuCj4+Pj4KPj4+PiBTaG91bGQgd2Ugcm91bmRfdXAgbGVuIGFmdGVyIHN0YXJ0X2JsayAmIGxh c3RfYmxrIGNhbGN1bGF0aW9uPwo+Pj4gSSB0aGlua3MgaXQgaXMgb2sgLGJ1dCBqdXN0IGEgbGl0 dGxlIGJpdCByZWR1bmRhbnQgd2l0aCB0aGUgZm9sbG93aW5nCj4+PiBoYW5kbGluZyBhYm91dCBs ZW4uCj4+Pgo+Pj4gaWYgKGJ5dGVzX3RvX2Jsa3MoaW5vZGUsIGxlbikgPT0gMCkKPj4+ICAgICAg bGVuID0gYmxrc190b19ieXRlcyhpbm9kZSwgMSk7Cj4+Pgo+Pj4gQmFzZWQgb24gdGhlIGFib3Zl IHNpdHVhdGlvbiwKPj4+IGRvIHlvdSBoYXZlIGFueSBvdGhlciBnb29kIHN1Z2dlc3Rpb25zPyBe Xgo+Pj4gdGhhbmtzIQo+Pj4KPj4+Pgo+Pj4+IFRoYW5rcywKPj4+Pgo+Pj4+PiB0aGFua3PvvIEK Pj4+Pj4+Cj4+Pj4+PiBUaGFua3MsCj4+Pj4+Pgo+Pj4+Cj4+CgoKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkxpbnV4LWYyZnMtZGV2ZWwgbWFpbGluZyBs aXN0CkxpbnV4LWYyZnMtZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0Cmh0dHBzOi8vbGlzdHMu c291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2xpbnV4LWYyZnMtZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E0B3418DF64 for ; Wed, 6 Nov 2024 02:40:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730860823; cv=none; b=GVRMl9GTP9ngIf66os2+XYRasLNgrfwqLlhEYnzvlUUapXrojfZyhY7WZTuOyLVib3G/0PeJ+Oq3AHYiljk2UevaKF4yfwxmOfel1oqDzhQ87vK8PVe8DgjNha92mrdOzZL7FKU4fdfuYQUIzUSgIxIiII0bHcep8uTlotarf04= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730860823; c=relaxed/simple; bh=8skSwEKa2BJdI+HdH5Bnq08Ua01XRXyPvb6CEc1N0+o=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=r8+CZRlrFtax9dZ9WC5THhE8yASqA0LaKWXw93ixuMb+CTXsEWCyVGSRr4F8eYKSVcM4oiGnY2ys+DHm3xbsbv3ddnYU8Gw4U8ulgk6hxKE4qx437dLMI3VJ5lhItzEqQMhVpu8wiFhhxECuPmTK/tii7THUhXF51ZExovlSKOw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WWXLSvRT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WWXLSvRT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8AB95C4CECF; Wed, 6 Nov 2024 02:40:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730860822; bh=8skSwEKa2BJdI+HdH5Bnq08Ua01XRXyPvb6CEc1N0+o=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=WWXLSvRTbUiPWWKtMytVIOms90KKpuZmDWJjG5XKjv3F4uI0pAzyM1IYTigynUanc EqvLbwa86M5kudGz8nuZbG+NlUIw+TGFetghuLiPIbmCcImZIIJWIHX4oDo8zG85OF ZZYVaAMIDQDEk5EtfhRfpkGr60JvP8PoDFZnU8SJcfzM4kOgZZ0JAC/8YnhdhonLdB ylzR5W2Os02g4AWb3yH2dg3vQAMX4r+Wh7GjnKZITsn9y+jOgCsrMSYnwWATTfFCJN KVimjE8sw7F8EbIdmsRHD5z+uTdR9Fxg2AoouH2PPRFem5z7+5yePqOCbv131hqZMs lg3KzOj4JVdaQ== Message-ID: Date: Wed, 6 Nov 2024 10:40:17 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: Chao Yu , Zhiguo Niu , jaegeuk@kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, ke.wang@unisoc.com, Hao_hao.Wang@unisoc.com Subject: Re: [PATCH V2] f2fs: fix to adjust appropriate length for fiemap To: Zhiguo Niu References: <1730685372-2995-1-git-send-email-zhiguo.niu@unisoc.com> <22873055-370b-4240-83ff-96bcfa91413a@kernel.org> <9199e9fc-7b5b-4069-b79b-65ba5ae1b0f6@kernel.org> Content-Language: en-US From: Chao Yu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2024/11/6 10:26, Zhiguo Niu wrote: > Chao Yu 于2024年11月6日周三 10:16写道： >> >> On 2024/11/5 19:02, Zhiguo Niu wrote: >>> Chao Yu 于2024年11月5日周二 18:39写道： >>>> >>>> On 2024/11/5 15:28, Zhiguo Niu wrote: >>>>> Chao Yu 于2024年11月5日周二 15:04写道： >>>>>> >>>>>> On 2024/11/4 9:56, Zhiguo Niu wrote: >>>>>>> If user give a file size as "length" parameter for fiemap >>>>>>> operations, but if this size is non-block size aligned, >>>>>>> it will show 2 segments fiemap results even this whole file >>>>>>> is contiguous on disk, such as the following results: >>>>>>> >>>>>>> ./f2fs_io fiemap 0 19034 ylog/analyzer.py >>>>>>> Fiemap: offset = 0 len = 19034 >>>>>>> logical addr. physical addr. length flags >>>>>>> 0 0000000000000000 0000000020baa000 0000000000004000 00001000 >>>>>>> 1 0000000000004000 0000000020bae000 0000000000001000 00001001 >>>>>>> >>>>>>> after this patch: >>>>>>> ./f2fs_io fiemap 0 19034 ylog/analyzer.py >>>>>>> Fiemap: offset = 0 len = 19034 >>>>>>> logical addr. physical addr. length flags >>>>>>> 0 0000000000000000 00000000315f3000 0000000000005000 00001001 >>>>>>> >>>>>>> Signed-off-by: Zhiguo Niu >>>>>>> --- >>>>>>> V2: correct commit msg according to Chao's questions >>>>>>> f2fs_io has been modified for testing, the length for fiemap is >>>>>>> real file size, not block number >>>>>>> --- >>>>>>> fs/f2fs/data.c | 4 ++-- >>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>>>> >>>>>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c >>>>>>> index 306b86b0..9fc229d 100644 >>>>>>> --- a/fs/f2fs/data.c >>>>>>> +++ b/fs/f2fs/data.c >>>>>>> @@ -1966,8 +1966,8 @@ int f2fs_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo, >>>>>>> goto out; >>>>>>> } >>>>>>> >>>>>>> - if (bytes_to_blks(inode, len) == 0) >>>>>>> - len = blks_to_bytes(inode, 1); >>>>>>> + if (len & (blks_to_bytes(inode, 1) - 1)) >>>>>>> + len = round_up(len, blks_to_bytes(inode, 1)); >>>>>> >>>>>> How do you think of getting rid of above alignment for len? >>>>>> >>>>>>> >>>>>>> start_blk = bytes_to_blks(inode, start); >>>>>>> last_blk = bytes_to_blks(inode, start + len - 1); >>>>>> >>>>>> And round up end position w/: >>>>>> >>>>>> last_blk = bytes_to_blks(inode, round_up(start + len - 1, F2FS_BLKSIZE)); >>>>> Hi Chao, >>>>> I think this will change the current code logic >>>>> ------------- >>>>> if (start_blk > last_blk) >>>>> goto out; >>>>> ------------- >>>>> for example, a file with size 19006, but the length from the user is 16384. >>>>> before this modification, last_blk = bytes_to_blks(inode, start + >>>>> len - 1) = (inode, 16383) = 3 >>>>> after the first f2fs_map_blocks(). start_blk change to be 4, >>>>> after the second f2fs_map_blocks(), fiemap_fill_nex_exten will be >>>>> called to fill user parameter and then >>>>> will goto out because start_blk > last_blk, then fiemap flow finishes. >>>>> but after this modification, last_blk will be 4 >>>>> will do f2fs_map_blocks() until reach the max_file_blocks(inode) >>>> >>>> Yes, you're right, however, w/ this patch, it may change last_blk, e.g. >>>> >>>> xfs_io file -c "fiemap -v 0 19006" vs xfs_io file -c "fiemap -v 2 19006" >>>> start_blk and last_blk will be: 0, 4 and 0, 5. >>> Hi Chao, >>> yes, but w/o this patch , the original code still has the same situation?? >>> for example >>> xfs_io file -c "fiemap -v 0 16384" vs xfs_io file -c "fiemap -v 2 16384" >>> start_blk and last_blk will be: 0, 3 and 0, 4. >> >> For the case "fiemap -v 2 19006", offset is 2, and length is 19006, so last_offset >> is 19008, and last_blk should be 4 rather than 5, right? > hi Chao, > it is right w/o my patch. >> >> And for you case, it calculates last_blk correctly. > So you suggest that "Should we round_up len after start_blk & last_blk > calculation?" Zhiguo, Yes, I think alignment of len should not affect calculation of last_blk. I mean this, --- fs/f2fs/data.c | 6 +++--- include/linux/f2fs_fs.h | 3 ++- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index 7d1bb9518a40..cbbb956f420d 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -1967,12 +1967,12 @@ int f2fs_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo, goto out; } - if (bytes_to_blks(inode, len) == 0) - len = blks_to_bytes(inode, 1); - start_blk = bytes_to_blks(inode, start); last_blk = bytes_to_blks(inode, start + len - 1); + if (len & F2FS_BLKSIZE_MASK) + len = round_up(len, F2FS_BLKSIZE); + next: memset(&map, 0, sizeof(map)); map.m_lblk = start_blk; diff --git a/include/linux/f2fs_fs.h b/include/linux/f2fs_fs.h index b0b821edfd97..954e8e8344b7 100644 --- a/include/linux/f2fs_fs.h +++ b/include/linux/f2fs_fs.h @@ -24,10 +24,11 @@ #define NEW_ADDR ((block_t)-1) /* used as block_t addresses */ #define COMPRESS_ADDR ((block_t)-2) /* used as compressed data flag */ +#define F2FS_BLKSIZE_MASK (F2FS_BLKSIZE - 1) #define F2FS_BYTES_TO_BLK(bytes) ((bytes) >> F2FS_BLKSIZE_BITS) #define F2FS_BLK_TO_BYTES(blk) ((blk) << F2FS_BLKSIZE_BITS) #define F2FS_BLK_END_BYTES(blk) (F2FS_BLK_TO_BYTES(blk + 1) - 1) -#define F2FS_BLK_ALIGN(x) (F2FS_BYTES_TO_BLK((x) + F2FS_BLKSIZE - 1)) +#define F2FS_BLK_ALIGN(x) (F2FS_BYTES_TO_BLK((x) + F2FS_BLKSIZE - 1)) /* 0, 1(node nid), 2(meta nid) are reserved node id */ #define F2FS_RESERVED_NODE_NUM 3 -- 2.40.1 > Thanks >> >> Thanks, >> >>> but overall last_blk will change loop counts but has not affect on the results. >>>> >>>> Should we round_up len after start_blk & last_blk calculation? >>> I thinks it is ok ,but just a little bit redundant with the following >>> handling about len. >>> >>> if (bytes_to_blks(inode, len) == 0) >>> len = blks_to_bytes(inode, 1); >>> >>> Based on the above situation, >>> do you have any other good suggestions? ^^ >>> thanks! >>> >>>> >>>> Thanks, >>>> >>>>> thanks！ >>>>>> >>>>>> Thanks, >>>>>> >>>> >>