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 X-Spam-Level: X-Spam-Status: No, score=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 827A8C64E7C for ; Wed, 2 Dec 2020 09:55:34 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B1E5622203 for ; Wed, 2 Dec 2020 09:55:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B1E5622203 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=dm-devel-bounces@redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-581-0JEI9pkkP06dfnTXQ8I0oQ-1; Wed, 02 Dec 2020 04:55:30 -0500 X-MC-Unique: 0JEI9pkkP06dfnTXQ8I0oQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BD05D192D791; Wed, 2 Dec 2020 09:55:25 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A1B195D9C6; Wed, 2 Dec 2020 09:55:25 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 707ED4EDB6; Wed, 2 Dec 2020 09:55:25 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 0B26Sq6s018061 for ; Wed, 2 Dec 2020 01:28:53 -0500 Received: by smtp.corp.redhat.com (Postfix) id 6FF882166B29; Wed, 2 Dec 2020 06:28:52 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast06.extmail.prod.ext.rdu2.redhat.com [10.11.55.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6ABEE2166B27 for ; Wed, 2 Dec 2020 06:28:49 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A82A9186E121 for ; Wed, 2 Dec 2020 06:28:49 +0000 (UTC) Received: from out30-56.freemail.mail.aliyun.com (out30-56.freemail.mail.aliyun.com [115.124.30.56]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-68-su9JIJy-OPa1qVjYyhhsYA-1; Wed, 02 Dec 2020 01:28:42 -0500 X-MC-Unique: su9JIJy-OPa1qVjYyhhsYA-1 X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R441e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01e04394; MF=jefflexu@linux.alibaba.com; NM=1; PH=DS; RN=4; SR=0; TI=SMTPD_---0UHIaoW8_1606890515 Received: from admindeMacBook-Pro-2.local(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0UHIaoW8_1606890515) by smtp.aliyun-inc.com(127.0.0.1); Wed, 02 Dec 2020 14:28:36 +0800 To: Mike Snitzer References: <20201201160709.31748-1-snitzer@redhat.com> <20201202033855.60882-1-jefflexu@linux.alibaba.com> <20201202033855.60882-2-jefflexu@linux.alibaba.com> <20201202050343.GA20535@redhat.com> From: JeffleXu Message-ID: <265e6542-cecf-0b62-4c03-2b053cafcee9@linux.alibaba.com> Date: Wed, 2 Dec 2020 14:28:35 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201202050343.GA20535@redhat.com> X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-loop: dm-devel@redhat.com X-Mailman-Approved-At: Wed, 02 Dec 2020 04:55:04 -0500 Cc: linux-block@vger.kernel.org, joseph.qi@linux.alibaba.com, dm-devel@redhat.com Subject: Re: [dm-devel] dm: use gcd() to fix chunk_sectors limit stacking X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dm-devel-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 CgpPbiAxMi8yLzIwIDE6MDMgUE0sIE1pa2UgU25pdHplciB3cm90ZToKPiBXaGF0IHlvdSd2ZSBk b25lIGhlcmUgaXMgZmFpcmx5IGNoYW90aWMvZGlzcnVwdGl2ZToKPiAxKSB5b3UgZW1haWxlZCBh IHBhdGNoIG91dCB0aGF0IGlzbid0IG5lZWRlZCBvciBpZGVhbCwgSSBkZWFsdCBhbHJlYWR5Cj4g ICAgc3RhZ2VkIGEgRE0gZml4IGluIGxpbnV4LW5leHQgZm9yIDUuMTAtcmNYLCBzZWU6Cj4gICAg aHR0cHM6Ly9naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQvZGV2aWNlLW1h cHBlci9saW51eC1kbS5naXQvY29tbWl0Lz9oPWRtLTUuMTAtcmNYJmlkPWYyOGRlMjYyZGRmMDli NjM1MDk1YmRlYWYwZTA3ZmY1MDdiM2M0MWIKCkZpbmUuIEkgaW5kZWVkIGRpZG4ndCBmb2xsb3cg bGludXgtZG0uZ2l0LiBTb3JyeSBpdCdzIG15IGZhdWx0LgoKPiAyKSB5b3UgcmVwbGllZCB0byB5 b3VyIHBhdGNoIGFuZCBzdGFydGVkIHJlZmVyZW5jaW5nIHNuaXBwZXRzIG9mIHRoaXMKPiAgICBv dGhlciBwYXRjaCdzIGhlYWRlciAobm93IHN0YWdlZCBmb3IgNS4xMC1yY1ggdmlhIEplbnMnIGJs b2NrIHRyZWUpOgo+ICAgIGh0dHBzOi8vZ2l0Lmtlcm5lbC5kay9jZ2l0L2xpbnV4LWJsb2NrL2Nv bW1pdC8/aD1ibG9jay01LjEwJmlkPTdlNzk4NmY5ZDNiYTY5YTczNzVhNDEwODBhMWY4YzgwMTJj YjA5MjMKPiAgICAtIHdoeSBub3QgcmVwbHkgdG8gX3RoYXRfIHBhdGNoIGluIHJlc3BvbnNlIHNv bWV0aGluZyBzdGF0ZWQgaW4gaXQ/CgpJIGp1c3Qgd2FudCB0byBzZW5kIGluIG9uZSBlbWFpbCwg d2hpY2ggc2VlbXMgb2J2aW91c2x5IGltcHJvcGVyLgoKPiAzKSB5b3Ugc3RhcnRlZCB0ZWxsaW5n IG1lLCBhbmQgb3RoZXJzIG9uIHRoZXNlIGxpc3RzLCB3aHkgeW91IHRoaW5rIEkKPiAgICB1c2Vk IGxjbV9ub3RfemVybygpLgo+ICAgIC0gcmVhbGl0eSBpcyBJIHdhbnRlZCBnY2QoKSBiZWhhdmlv ciwgSSBqdXN0IGRpZG4ndCByZWFzb24gdGhyb3VnaAo+ICAgICAgdGhlIG1hdGggdG8ga25vdyBp dC4uIGl0IHdhcyBhIHN0dXBpZCBvdmVyc2lnaHQgb24gbXkgcGFydC4gIE5vdAo+ICAgICAgZGVz aWduZWQgd2l0aCBwcmVjaXNpb24uCj4gNCkgV2h5IG5vdCBjaGVjayB3aXRoIG1lIGJlZm9yZSB5 b3UgY3JhZnQgYSBwYXRjaCBsaWtlIG90aGVycyByZXBvcnRlZAo+ICAgIHRoZSBwcm9ibGVtIHRv IHlvdT8gSSBrbm93IGl0IGxvZ2ljYWwgdG8gZm9sbG93IHRoZSBjaGFpbiBvZgo+ICAgIGltcGxp Y2F0aW9ucyBiYXNlZCBvbiBvbmUgY29tbWl0IGFuZCBzZWUgd2hlcmUgZWxzZSB0aGVyZSBtaWdo dCBiZQo+ICAgIGdhcHMgYnV0Li4uIGl0IGlzIHN0cmFuZ2UgdG8ganVzdCBwaWNrdXAgc29tZW9u ZSBlbHNlJ3Mgd29yayBsaWtlCj4gICAgdGhhdC4KPiAKPiBBbGwganVzdCBfc2VlbXNfIHdlaXJk IGFuZCBvdmVyZG9uZS4gVGhpcyBpc24ndCB0aGUga2luZCBvZiBoZWxwIEkKPiBuZWVkLiBUaGF0 IHNhaWQsIEkgX2RvXyBhcHByZWNpYXRlIHlvdSBsb29raW5nIGF0IG1ha2luZyBibGsgSU8gcG9s bGluZwo+IHdvcmsgd2l0aCBiaW8tYmFzZWQgKGFuZCBETSdzIGJpbyBzcGxpdHRpbmcgaW4gcGFy dGljdWxhciksIGJ1dCB0aGUKPiBsYWNrIG9mIGltcG9ydGFuY2UgeW91IHB1dCBvbiBETSdzIHNw bGl0dGluZyBiZWxvdyBtYWtlcyBtZSBjb25jZXJuZWQuCj4gClRob3VnaCBJIGhhdmUgbm90aWNl ZCB0aGlzIHNlcmllcyBkaXNjdXNzaW9uIHllc3RlcmRheSwgSSBkaWRuJ3QgcmVhZCBpdAp0aG9y b3VnaGx5IHVudGlsIHRvZGF5LiBXaGVuIEkgbm90aWNlZCB0aGVyZSBtYXkgYmUgb25lIHJlbWFp bmVkIGlzc3VlCihJIGtub3cgaXQgaXMgbm90IG5vdyksIHRoZSBwYXRjaCwgdGhhdCBpcyBjb21t aXQgMjJhZGE4MDJlZGU4IGhhcyBiZWVuCmFkb3B0IGJ5IEplbnMsIHNvIEkgc2VuZCBvdXQgYSBw YXRjaC4gSWYgdGhlcmUncyBubyBKZW5zJyByZXBseSwgSSB3aWxsCmp1c3QgcmVwbHkgdW5kZXIg eW91ciBtYWlsLiBUaGF0J3MgaXQuIEkgaGF2ZSB0byBhZG1pdCB0aGF0IEkgZ2V0CmV4Y2l0ZWQg d2hlbiBJIHJlYWxpemVkIHRoYXQgSSBjb3VsZCBzZW5kIGEgcGF0Y2guIEJ1dCBpdCBzZWVtcyBp bXByb3BlcgphbmQgbW9yZSBsaWtlbHkgYSBtaXN1bmRlcnN0YW5kaW5nLiBJIGFwb2xvZ2l6ZSBp ZiBJIGRpZCB3cm9uZy4KCgo+IE9uIFR1ZSwgRGVjIDAxIDIwMjAgYXQgMTA6NTdwbSAtMDUwMCwK PiBKZWZmbGVYdSA8amVmZmxleHVAbGludXguYWxpYmFiYS5jb20+IHdyb3RlOgo+IAo+PiBBY3R1 YWxseSBpbiB0ZXJtcyBvZiB0aGlzIGlzc3VlLCBJIHRoaW5rIHRoZSBkaWxlbW1hIGhlcmUgaXMg dGhhdCwKPj4gQGNodW5rX3NlY3RvcnMgb2YgZG0gZGV2aWNlIGlzIG1haW5seSBmcm9tIHR3byBz b3VyY2UuCj4+Cj4+IE9uZSBpcyB0aGF0IGZyb20gdGhlIHVuZGVybHlpbmcgZGV2aWNlcywgd2hp Y2ggaXMgY2FsY3VsYXRlZCBpbnRvIG9uZQo+PiBjb21wb3NlZCBvbmUgaW4gYmxrX3N0YWNrX2xp bWl0cygpLgo+Pgo+Pj4gY29tbWl0IDIyYWRhODAyZWRlOCAoImJsb2NrOiB1c2UgbGNtX25vdF96 ZXJvKCkgd2hlbiBzdGFja2luZwo+Pj4gY2h1bmtfc2VjdG9ycyIpIGJyb2tlIGNodW5rX3NlY3Rv cnMgbGltaXQgc3RhY2tpbmcuIGNodW5rX3NlY3RvcnMgbXVzdAo+Pj4gcmVmbGVjdCB0aGUgbW9z dCBsaW1pdGVkIG9mIGFsbCBkZXZpY2VzIGluIHRoZSBJTyBzdGFjay4KPj4+Cj4+PiBPdGhlcndp c2UgbWFsZm9ybWVkIElPIG1heSByZXN1bHQuIEUuZy46IHByaW9yIHRvIHRoaXMgZml4LAo+Pj4g LT5jaHVua19zZWN0b3JzID0gbGNtX25vdF96ZXJvKDgsIDEyOCkgd291bGQgcmVzdWx0IGluCj4+ PiBibGtfbWF4X3NpemVfb2Zmc2V0KCkgc3BsaXR0aW5nIElPIGF0IDEyOCBzZWN0b3JzIHJhdGhl ciB0aGFuIHRoZQo+Pj4gcmVxdWlyZWQgbW9yZSByZXN0cmljdGl2ZSA4IHNlY3RvcnMuCj4+Cj4+ IEZvciB0aGlzIHBhcnQsIHRlY2huaWNhbGx5IEkgY2FuJ3QgYWdyZWUgdGhhdCAnY2h1bmtfc2Vj dG9ycyBtdXN0Cj4+IHJlZmxlY3QgdGhlIG1vc3QgbGltaXRlZCBvZiBhbGwgZGV2aWNlcyBpbiB0 aGUgSU8gc3RhY2snLiBFdmVuIGlmIHRoZSBkbQo+PiBkZXZpY2UgYWR2ZXJ0aXNlcyBjaHVua19z ZWN0b3JzIG9mIDEyOEsgd2hlbiB0aGUgbGltaXRzIG9mIHR3bwo+PiB1bmRlcmx5aW5nIGRldmlj ZXMgYXJlIDhLIGFuZCAxMjhLLCBhbmQgdGh1cyBzcGxpdHRpbmcgaXMgbm90IGRvbmUgaW4gZG0K Pj4gZGV2aWNlIHBoYXNlLCB0aGUgdW5kZXJseWluZyBkZXZpY2VzIHdpbGwgc3BsaXQgYnkgdGhl bXNlbHZlcy4KPiAKPiBETSB0YXJnZXRzIHRoZW1zZWx2ZXMgX2RvXyByZXF1aXJlIHRoZWlyIG93 biBzcGxpdHRpbmcuICBZb3UgY2Fubm90IGp1c3QKPiBhc3N1bWUgYWxsIElPIHRoYXQgcGFzc2Vz IHRocm91Z2ggRE0gdGFyZ2V0cyBkb2Vzbid0IG5lZWQgdG8gYmUgcHJvcGVybHkKPiBzaXplZCBv biBlbnRyeS4gIFN1cmUgdW5kZXJseWluZyBkZXZpY2VzIHdpbGwgZG8gdGhlaXIgb3duIHNwbGl0 dGluZywKPiBidXQgdGhvc2Ugc3BsaXRzIGFyZSBiYXNlZCBvbiB0aGVpciByZXF1aXJlbWVudHMu ICBETSB0YXJnZXRzIGhhdmUgdGhlaXIKPiBvd24gSU8gc2l6ZSBsaW1pdHMgdG9vLiAgRWFjaCBs YXllciBuZWVkcyB0byBlbmZvcmNlIGFuZCByZXNwZWN0IHRoZQo+IGNvbnN0cmFpbnRzIG9mIGl0 cyBsYXllciB3aGlsZSBhbHNvIGZhY3RvcmluZyBpbiB0aG9zZSBvZiB0aGUgdW5kZXJseWluZwo+ IGRldmljZXMuCj4gCkdvdCBpdC4gVGhhbmtzLgoKCj4+PiBAQCAtNTQ3LDcgKzU0NywxMCBAQCBp bnQgYmxrX3N0YWNrX2xpbWl0cyhzdHJ1Y3QgcXVldWVfbGltaXRzICp0LCBzdHJ1Y3QgcXVldWVf bGltaXRzICpiLAo+Pj4gIAo+Pj4gIAl0LT5pb19taW4gPSBtYXgodC0+aW9fbWluLCBiLT5pb19t aW4pOwo+Pj4gIAl0LT5pb19vcHQgPSBsY21fbm90X3plcm8odC0+aW9fb3B0LCBiLT5pb19vcHQp Owo+Pj4gLQl0LT5jaHVua19zZWN0b3JzID0gbGNtX25vdF96ZXJvKHQtPmNodW5rX3NlY3RvcnMs IGItPmNodW5rX3NlY3RvcnMpOwo+Pj4gKwo+Pj4gKwkvKiBTZXQgbm9uLXBvd2VyLW9mLTIgY29t cGF0aWJsZSBjaHVua19zZWN0b3JzIGJvdW5kYXJ5ICovCj4+PiArCWlmIChiLT5jaHVua19zZWN0 b3JzKQo+Pj4gKwkJdC0+Y2h1bmtfc2VjdG9ycyA9IGdjZCh0LT5jaHVua19zZWN0b3JzLCBiLT5j aHVua19zZWN0b3JzKTsKPj4KPj4gVGhpcyBtYXkgaW50cm9kdWNlcyBhIHJlZ3Jlc3Npb24uCj4g Cj4gUmVncmVzc2lvbiByZWxhdGl2ZSB0byB3aGF0PyAgNS4xMCB3YXMgdGhlIHJlZ3Jlc3Npb24g cG9pbnQuICBUaGUgY29tbWl0Cj4gaGVhZGVyIHlvdSBwYXN0ZWQgaW50byB5b3VyIHJlcGx5IGNs ZWFybHkgY29udmV5cyB0aGF0IGNvbW1pdAo+IDIyYWRhODAyZWRlOCBjYXVzZWQgdGhlIHJlZ3Jl c3Npb24uICBJdCBtYWtlcyBubyBzZW5zZSB0byB0cnkgdG8gY3JlYXRlCj4gc29tZSBvdGhlciBy ZWdyZXNzaW9uIHBvaW50LiAgWW91IGNhbm5vdCBoYXZlIGJvdGggZnJvbSBhIHNpbmdsZSBjb21t aXQKPiBpbiB0aGUgbW9zdCByZWNlbnQgTGludXggNS4xMCByZWxlYXNlLgo+IAo+IEFuZCBzbyBJ IGhhdmUgbm8gaWRlYSB3aHkgeW91IHRoaW5rIHRoYXQgcmVzdG9yaW5nIERNJ3MgX3JlcXVpcmVk Xwo+IHNwbGl0dGluZyBjb25zdHJhaW50cyBpcyBzb21laG93IGEgcmVncmVzc2lvbi4KCkkgbWlz dGFrZW5seSBtaXNzZWQgdGhhdCBhbGwgdGhlc2UgY2hhbmdlcyBhcmUgaW50cm9kdWNlZCBpbiB2 NS4xMC4KU29ycnkgZm9yIHRoYXQuCgo+IAo+PiBTdXBwb3NlIHRoZSBAY2h1bmtfc2VjdG9ycyBs aW1pdHMgb2YKPj4gdHdvIHVuZGVybHlpbmcgZGV2aWNlcyBhcmUgOEsgYW5kIDEyOEssIHRoZW4g QGNodW5rX3NlY3RvcnMgb2YgZG0gZGV2aWNlCj4+IGlzIDhLIGFmdGVyIHRoZSBmaXguIFNvIGV2 ZW4gd2hlbiBhIDEyOEsgc2l6ZWQgYmlvIGlzIGFjdHVhbGx5Cj4+IHJlZGlyZWN0aW5nIHRvIHRo ZSB1bmRlcmx5aW5nIGRldmljZSB3aXRoIDEyOEsgQGNodW5rX3NlY3RvcnMgbGltaXQsCj4+IHRo aXMgMTI4SyBzaXplZCBiaW8gd2lsbCBhY3R1YWxseSBzcGxpdCBpbnRvIDE2IHNwbGl0IGJpb3Ms IGVhY2ggOEsKPj4gc2l6ZWTjgIJPYnZpb3VzbHkgaXQgaXMgZXhjZXNzaXZlIHNwbGl0LiBBbmQg SSB0aGluayB0aGlzIGlzIGFjdHVhbGx5IHdoeQo+PiBsY21fbm90X3plcm8oYSwgYikgaXMgdXNl ZCBvcmlnaW5hbGx5Lgo+IAo+IE5vLiAgTm90IGV4Y2Vzc2l2ZSBzcGxpdHRpbmcsIHJlcXVpcmVk IHNwbGl0dGluZy4gIEFuZCBhcyBJIGV4cGxhaW5lZCBpbgo+IHBvaW50IDIpIGFib3ZlLCBhdm9p ZGluZyAiZXhjZXNzaXZlIHNwbGl0cyIgaXNuJ3Qgd2h5IGxjbV9ub3RfemVybygpIHdhcwo+IGlt cHJvcGVybHkgdXNlZCB0byBzdGFjayBjaHVua19zZWN0b3JzLgoKVGhpcyBpcyBpbmRlZWQgYSBk aWZmZXJlbmNlIGJldHdlZW4gNS45IGFuZCA1LjEwLiBJbiA1LjEwIHRoZXJlIG1heSBiZQptb3Jl IHNtYWxsIHNwbGl0IGJpb3MsIHNpbmNlIGEgc21hbGxlciBjaHVua19zZWN0b3JzIGlzIGFwcGxp ZWQgZm9yIHRoZQp1bmRlcmx5aW5nIGRldmljZSB3aXRoIGxhcmdlciBjaHVua19zZWN0b3JzICh0 aGF0IGlzLCB0aGUgdW5kZXJseWluZwpkZXZpY2Ugd2l0aCAxMjhLIGNodW5rX3NlY3RvcnMpLiBJ IGNhbiBub3Qgc2F5IHRoYXQgbW9yZSBzbWFsbCBzcGxpdApiaW9zIHdpbGwgY2F1c2Ugd29yc2Ug cGVyZm9ybWFuY2Ugc2luY2UgSSBoYXZlIG5vdCB0ZXN0ZWQgaXQuCgoKPiAKPiBTb21lIERNIHRh cmdldHMgcmVhbGx5IGRvIHJlcXVpcmUgdGhlIElPIGJlIHNwbGl0IG9uIHNwZWNpZmljIGJvdW5k YXJpZXMKPiAtLSBob3dldmVyIGluY29udmVuaWVudCBmb3IgdGhlIHVuZGVybHlpbmcgbGF5ZXJz IHRoYXQgRE0gc3BsaXR0aW5nCj4gbWlnaHQgYmUuCj4gCgoKPj4gVGhlIG90aGVyIG9uZSBzb3Vy Y2UgaXMgZG0gZGV2aWNlIGl0c2VsZi4gRE0gZGV2aWNlIGNhbiBzZXQgQG1heF9pb19sZW4KPj4g dGhyb3VnaCAtPmlvX2hpbnQoKSwgYW5kIHRoZW4gc2V0IEBjaHVua19zZWN0b3JzIGZyb20gQG1h eF9pb19sZW4uCj4gCj4gdGktPm1heF9pb19sZW4gc2hvdWxkIGFsd2F5cyBiZSBzZXQgaW4gdGhl IERNIHRhcmdldCdzIC5jdHIKPiAKWWVzIEkgbWlzcmVtZW1iZXIgaXQuCgo+IERNIGNvcmUgdGFr ZXMgY2FyZSBvZiBhcHBseWluZyBtYXhfaW9fbGVuIHRvIGNodW5rX3NlY3RvcnMgc2luY2UgNS4x MCwKPiB5b3Ugc2hvdWxkIGtub3cgdGhhdCBnaXZlbiB5b3VyIHBhdGNoIGlzIG1lYW50IHRvIGZp eCBjb21taXQKPiA4ODJlYzRlNjA5YzEKPiAKPiBBbmQgZm9yIDUuMTEgSSd2ZSBzdGFnZWQgYSBj aGFuZ2UgdG8gaGF2ZSBpdCBpbXBvc2UgbWF4X2lvX2xlbiBpbiB0ZXJtcwo+IG9mIC0+bWF4X3Nl Y3RvcnMgdG9vLCBzZWU6Cj4gaHR0cHM6Ly9naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tl cm5lbC9naXQvZGV2aWNlLW1hcHBlci9saW51eC1kbS5naXQvY29tbWl0Lz9oPWRtLTUuMTEmaWQ9 NDFkY2I4ZjIxYTg2ZWRiZTQwOWIyYmVmOWJiMWRmNGNiOWQ2Njg1OAo+IApUaGFua3MuCgo+IE9u ZSB0aGluZyBJIGNsZWFybHkgbmVlZCB0byBkbyBtb3ZpbmcgZm9yd2FyZCBpczogYWx3YXlzIHBv c3QgbXkgY2hhbmdlcwo+IHRvIGRtLWRldmVsOyBqdXN0IHNvIHNvbWVvbmUgbGlrZSB5b3Vyc2Vs ZiBjYW4gZm9sbG93IGFsb25nIHZpYSBlbWFpbAo+IGNsaWVudC4gIEkganVzdCBhc3N1bWVkIG90 aGVycyB3aG8gY2FyZSBhYm91dCBETSBjaGFuZ2VzIGFsc28gdHJhY2sgdGhlCj4gbGludXgtZG0u Z2l0IHRyZWUncyBicmFuY2hlcy4gIENsZWFybHkgbm90IHRoZSBiZXN0IGFzc3VtcHRpb24gb3IK PiBwcmFjdGljZSBvbiBteSBwYXJ0LgoKSSB1c2VkIExpbnVzJyB0cmVlIGFzIG15IGNvZGUgYmFz ZSwgd2hpY2ggc2VlbXMgaW1wcm9wZXIuLi4KCj4gCj4+IFRoaXMgcGFydCBpcyBhY3R1YWxseSB3 aGVyZSAnY2h1bmtfc2VjdG9ycyBtdXN0IHJlZmxlY3QgdGhlIG1vc3QgbGltaXRlZAo+PiBvZiBh bGwgZGV2aWNlcyBpbiB0aGUgSU8gc3RhY2snIGlzIHRydWUsIGFuZCB3ZSBoYXZlIHRvIGFwcGx5 IHRoZSBtb3N0Cj4+IHN0cmljdCBsaW1pdGF0aW9uIGhlcmUuIFRoaXMgaXMgYWN0dWFsbHkgd2hh dCB0aGUgZm9sbG93aW5nIHBhdGNoIGRvZXMuCj4gCj4gVGhlcmUgaXMgYSB2ZXJ5IGNvbnNpc3Rl bnQgYW5kIGRlbGliZXJhdGUgd2F5IHRoYXQgZGV2aWNlIGxpbWl0cyBtdXN0IGJlCj4gaGFuZGxl ZCwgc29tZXRpbWVzIEkgdG9vIGhhdmUgbWlzc3RlcHMgYnV0IHRoYXQgZG9lc24ndCBjaGFuZ2Ug dGhlIGZhY3QKPiB0aGF0IHRoZXJlIGlzIGEgZGVsaWJlcmF0ZSBldmVubmVzcyB0byBob3cgbGlt aXRzIGFyZSBzdGFja2VkLgo+IGJsa19zdGFja19saW1pdHMoKSBuZWVkcyB0byBiZSB0aGUgYXV0 aG9yaXR5IG9uIGhvdyB0aGVzZSBsaW1pdHMgc3RhY2sKPiB1cC4gIFNvIGFsbCBETSdzIGxpbWl0 cyBzdGFja2luZyB3cmFwcyBjYWxscyB0byBpdC4gIE15IGZpeCwgc2hhcmVkIGluCj4gcG9pbnQg MSkgYWJvdmUsIHJlc3RvcmVzIHRoYXQgZGVzaWduIHBhdHRlcm4gYnkgX25vdF8gaGF2aW5nIERN Cj4gZHVwbGljYXRlIGEgc3Vic2V0IG9mIGhvdyBibGtfc3RhY2tfbGltaXRzKCkgZG9lcyBpdHMg c3RhY2tpbmcuCj4gCj4gTWlrZQoKCi0tIApUaGFua3MsCkplZmZsZQoKLS0KZG0tZGV2ZWwgbWFp bGluZyBsaXN0CmRtLWRldmVsQHJlZGhhdC5jb20KaHR0cHM6Ly93d3cucmVkaGF0LmNvbS9tYWls bWFuL2xpc3RpbmZvL2RtLWRldmVs 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 X-Spam-Level: X-Spam-Status: No, score=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45236C64E8A for ; Wed, 2 Dec 2020 06:29:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CB8C622203 for ; Wed, 2 Dec 2020 06:29:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728668AbgLBG3k (ORCPT ); Wed, 2 Dec 2020 01:29:40 -0500 Received: from out30-132.freemail.mail.aliyun.com ([115.124.30.132]:41816 "EHLO out30-132.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725885AbgLBG3j (ORCPT ); Wed, 2 Dec 2020 01:29:39 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R441e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04394;MF=jefflexu@linux.alibaba.com;NM=1;PH=DS;RN=4;SR=0;TI=SMTPD_---0UHIaoW8_1606890515; Received: from admindeMacBook-Pro-2.local(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0UHIaoW8_1606890515) by smtp.aliyun-inc.com(127.0.0.1); Wed, 02 Dec 2020 14:28:36 +0800 Subject: Re: dm: use gcd() to fix chunk_sectors limit stacking To: Mike Snitzer Cc: dm-devel@redhat.com, joseph.qi@linux.alibaba.com, linux-block@vger.kernel.org References: <20201201160709.31748-1-snitzer@redhat.com> <20201202033855.60882-1-jefflexu@linux.alibaba.com> <20201202033855.60882-2-jefflexu@linux.alibaba.com> <20201202050343.GA20535@redhat.com> From: JeffleXu Message-ID: <265e6542-cecf-0b62-4c03-2b053cafcee9@linux.alibaba.com> Date: Wed, 2 Dec 2020 14:28:35 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201202050343.GA20535@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On 12/2/20 1:03 PM, Mike Snitzer wrote: > What you've done here is fairly chaotic/disruptive: > 1) you emailed a patch out that isn't needed or ideal, I dealt already > staged a DM fix in linux-next for 5.10-rcX, see: > https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-5.10-rcX&id=f28de262ddf09b635095bdeaf0e07ff507b3c41b Fine. I indeed didn't follow linux-dm.git. Sorry it's my fault. > 2) you replied to your patch and started referencing snippets of this > other patch's header (now staged for 5.10-rcX via Jens' block tree): > https://git.kernel.dk/cgit/linux-block/commit/?h=block-5.10&id=7e7986f9d3ba69a7375a41080a1f8c8012cb0923 > - why not reply to _that_ patch in response something stated in it? I just want to send in one email, which seems obviously improper. > 3) you started telling me, and others on these lists, why you think I > used lcm_not_zero(). > - reality is I wanted gcd() behavior, I just didn't reason through > the math to know it.. it was a stupid oversight on my part. Not > designed with precision. > 4) Why not check with me before you craft a patch like others reported > the problem to you? I know it logical to follow the chain of > implications based on one commit and see where else there might be > gaps but... it is strange to just pickup someone else's work like > that. > > All just _seems_ weird and overdone. This isn't the kind of help I > need. That said, I _do_ appreciate you looking at making blk IO polling > work with bio-based (and DM's bio splitting in particular), but the > lack of importance you put on DM's splitting below makes me concerned. > Though I have noticed this series discussion yesterday, I didn't read it thoroughly until today. When I noticed there may be one remained issue (I know it is not now), the patch, that is commit 22ada802ede8 has been adopt by Jens, so I send out a patch. If there's no Jens' reply, I will just reply under your mail. That's it. I have to admit that I get excited when I realized that I could send a patch. But it seems improper and more likely a misunderstanding. I apologize if I did wrong. > On Tue, Dec 01 2020 at 10:57pm -0500, > JeffleXu wrote: > >> Actually in terms of this issue, I think the dilemma here is that, >> @chunk_sectors of dm device is mainly from two source. >> >> One is that from the underlying devices, which is calculated into one >> composed one in blk_stack_limits(). >> >>> commit 22ada802ede8 ("block: use lcm_not_zero() when stacking >>> chunk_sectors") broke chunk_sectors limit stacking. chunk_sectors must >>> reflect the most limited of all devices in the IO stack. >>> >>> Otherwise malformed IO may result. E.g.: prior to this fix, >>> ->chunk_sectors = lcm_not_zero(8, 128) would result in >>> blk_max_size_offset() splitting IO at 128 sectors rather than the >>> required more restrictive 8 sectors. >> >> For this part, technically I can't agree that 'chunk_sectors must >> reflect the most limited of all devices in the IO stack'. Even if the dm >> device advertises chunk_sectors of 128K when the limits of two >> underlying devices are 8K and 128K, and thus splitting is not done in dm >> device phase, the underlying devices will split by themselves. > > DM targets themselves _do_ require their own splitting. You cannot just > assume all IO that passes through DM targets doesn't need to be properly > sized on entry. Sure underlying devices will do their own splitting, > but those splits are based on their requirements. DM targets have their > own IO size limits too. Each layer needs to enforce and respect the > constraints of its layer while also factoring in those of the underlying > devices. > Got it. Thanks. >>> @@ -547,7 +547,10 @@ int blk_stack_limits(struct queue_limits *t, struct queue_limits *b, >>> >>> t->io_min = max(t->io_min, b->io_min); >>> t->io_opt = lcm_not_zero(t->io_opt, b->io_opt); >>> - t->chunk_sectors = lcm_not_zero(t->chunk_sectors, b->chunk_sectors); >>> + >>> + /* Set non-power-of-2 compatible chunk_sectors boundary */ >>> + if (b->chunk_sectors) >>> + t->chunk_sectors = gcd(t->chunk_sectors, b->chunk_sectors); >> >> This may introduces a regression. > > Regression relative to what? 5.10 was the regression point. The commit > header you pasted into your reply clearly conveys that commit > 22ada802ede8 caused the regression. It makes no sense to try to create > some other regression point. You cannot have both from a single commit > in the most recent Linux 5.10 release. > > And so I have no idea why you think that restoring DM's _required_ > splitting constraints is somehow a regression. I mistakenly missed that all these changes are introduced in v5.10. Sorry for that. > >> Suppose the @chunk_sectors limits of >> two underlying devices are 8K and 128K, then @chunk_sectors of dm device >> is 8K after the fix. So even when a 128K sized bio is actually >> redirecting to the underlying device with 128K @chunk_sectors limit, >> this 128K sized bio will actually split into 16 split bios, each 8K >> sized。Obviously it is excessive split. And I think this is actually why >> lcm_not_zero(a, b) is used originally. > > No. Not excessive splitting, required splitting. And as I explained in > point 2) above, avoiding "excessive splits" isn't why lcm_not_zero() was > improperly used to stack chunk_sectors. This is indeed a difference between 5.9 and 5.10. In 5.10 there may be more small split bios, since a smaller chunk_sectors is applied for the underlying device with larger chunk_sectors (that is, the underlying device with 128K chunk_sectors). I can not say that more small split bios will cause worse performance since I have not tested it. > > Some DM targets really do require the IO be split on specific boundaries > -- however inconvenient for the underlying layers that DM splitting > might be. > >> The other one source is dm device itself. DM device can set @max_io_len >> through ->io_hint(), and then set @chunk_sectors from @max_io_len. > > ti->max_io_len should always be set in the DM target's .ctr > Yes I misremember it. > DM core takes care of applying max_io_len to chunk_sectors since 5.10, > you should know that given your patch is meant to fix commit > 882ec4e609c1 > > And for 5.11 I've staged a change to have it impose max_io_len in terms > of ->max_sectors too, see: > https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-5.11&id=41dcb8f21a86edbe409b2bef9bb1df4cb9d66858 > Thanks. > One thing I clearly need to do moving forward is: always post my changes > to dm-devel; just so someone like yourself can follow along via email > client. I just assumed others who care about DM changes also track the > linux-dm.git tree's branches. Clearly not the best assumption or > practice on my part. I used Linus' tree as my code base, which seems improper... > >> This part is actually where 'chunk_sectors must reflect the most limited >> of all devices in the IO stack' is true, and we have to apply the most >> strict limitation here. This is actually what the following patch does. > > There is a very consistent and deliberate way that device limits must be > handled, sometimes I too have missteps but that doesn't change the fact > that there is a deliberate evenness to how limits are stacked. > blk_stack_limits() needs to be the authority on how these limits stack > up. So all DM's limits stacking wraps calls to it. My fix, shared in > point 1) above, restores that design pattern by _not_ having DM > duplicate a subset of how blk_stack_limits() does its stacking. > > Mike -- Thanks, Jeffle