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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 CD17FC2BA19 for ; Wed, 22 Apr 2020 01:01:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 923B2206B9 for ; Wed, 22 Apr 2020 01:01:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 923B2206B9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 282C18E0005; Tue, 21 Apr 2020 21:01:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 20B358E0003; Tue, 21 Apr 2020 21:01:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0AC748E0005; Tue, 21 Apr 2020 21:01:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0160.hostedemail.com [216.40.44.160]) by kanga.kvack.org (Postfix) with ESMTP id E12C08E0003 for ; Tue, 21 Apr 2020 21:01:47 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B379952D6 for ; Wed, 22 Apr 2020 01:01:47 +0000 (UTC) X-FDA: 76733688654.30.anger67_2c8d3d0018213 X-HE-Tag: anger67_2c8d3d0018213 X-Filterd-Recvd-Size: 4054 Received: from huawei.com (szxga06-in.huawei.com [45.249.212.32]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Apr 2020 01:01:46 +0000 (UTC) Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 925279D643D0F84A97D4; Wed, 22 Apr 2020 09:01:42 +0800 (CST) Received: from [10.173.228.124] (10.173.228.124) by smtp.huawei.com (10.3.19.206) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 22 Apr 2020 09:01:40 +0800 Subject: Re: [PATCH v5] mm/hugetlb: fix a addressing exception caused by huge_pte_offset To: Sasha Levin , , CC: Mike Kravetz , Andrew Morton , Jason Gunthorpe , Matthew Wilcox , Sean Christopherson , References: <20200413010342.771-1-longpeng2@huawei.com> <20200421195617.6104D20747@mail.kernel.org> From: "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)" Message-ID: Date: Wed, 22 Apr 2020 09:01:39 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20200421195617.6104D20747@mail.kernel.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.173.228.124] X-CFilter-Loop: Reflected 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: This bug was introduced by commit 9b19df292c666b57c407fed2496827c6aba05be2 ("mm/hugetlb.c: make huge_pte_offset() consistent and document behaviour"), but v4.4.219 and v4.9.219 haven't included it, so we needn't to apply my patch to these two stable trees. On 2020/4/22 3:56, Sasha Levin wrote: > Hi > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v5.6.5, v5.5.18, v5.4.33, v4.19.116, v4.14.176, v4.9.219, v4.4.219. > > v5.6.5: Build OK! > v5.5.18: Build OK! > v5.4.33: Build OK! > v4.19.116: Build OK! > v4.14.176: Build OK! > v4.9.219: Failed to apply! Possible dependencies: > 166f61b9435a ("mm: codgin-style fixes") > 505a60e22560 ("asm-generic: introduce 5level-fixup.h") > 82b0f8c39a38 ("mm: join struct fault_env and vm_fault") > 953c66c2b22a ("mm: THP page cache support for ppc64") > c2febafc6773 ("mm: convert generic code to 5-level paging") > fd60775aea80 ("mm, thp: avoid unlikely branches for split_huge_pmd") > > v4.4.219: Failed to apply! Possible dependencies: > 01c8f1c44b83 ("mm, dax, gpu: convert vm_insert_mixed to pfn_t") > 0e749e54244e ("dax: increase granularity of dax_clear_blocks() operations") > 166f61b9435a ("mm: codgin-style fixes") > 34c0fd540e79 ("mm, dax, pmem: introduce pfn_t") > 505a60e22560 ("asm-generic: introduce 5level-fixup.h") > 52db400fcd50 ("pmem, dax: clean up clear_pmem()") > 5c6a84a3f455 ("mm/kasan: Switch to using __pa_symbol and lm_alias") > 82b0f8c39a38 ("mm: join struct fault_env and vm_fault") > 9973c98ecfda ("dax: add support for fsync/sync") > aac453635549 ("mm, oom: introduce oom reaper") > ac401cc78242 ("dax: New fault locking") > b2e0d1625e19 ("dax: fix lifetime of in-kernel dax mappings with dax_map_atomic()") > bae473a423f6 ("mm: introduce fault_env") > bc2466e42573 ("dax: Use radix tree entry lock to protect cow faults") > c2febafc6773 ("mm: convert generic code to 5-level paging") > e4b274915863 ("DAX: move RADIX_DAX_ definitions to dax.c") > f9fe48bece3a ("dax: support dirty DAX entries in radix tree") > > > NOTE: The patch will not be queued to stable trees until it is upstream. > > How should we proceed with this patch? > -- --- Regards, Longpeng(Mike)