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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 47517D111A8 for ; Fri, 28 Nov 2025 01:17:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Y+3KZoa4eB0lXlCRXWilBy94mb50xgSMYtNVrzXSsD8=; b=dUAN0KgAosfsoFpX9gyvVfGbNP DarP/PuE//AXxLuK8gVdmNkeUlP5/J1D/4CFZ5mdaIrL3nf+KmGjSyFIBgZG+q9RNPqT7022BEdJa 3IfdSicD2bMd7y94lzzagMIKR3GNPH/CEd5MDXnjIS8N0B67Nq+KU13o8BmtgIna3aTNxyfBdair8 kFCdqMA1/oNBCMPffQGxcEp+y0JMtVdkHN8OfWARpa/6uzJtBUsS4ueveMIGqeCzs8Wu1SWRDD2i6 54qghu0vTHStaxXWcg3gVEtc1Kj9duEh5JaAGyKrg1+fD7PzrMyi5cGIaOIA68kKhaKf983oFRNNs pLi50Ozw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vOn76-0000000HNsp-2ZSP; Fri, 28 Nov 2025 01:17:32 +0000 Received: from dggsgout11.his.huawei.com ([45.249.212.51]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vOn71-0000000HNrr-12m6 for linux-arm-kernel@lists.infradead.org; Fri, 28 Nov 2025 01:17:30 +0000 Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4dHb3S0NGtzYQtfr for ; Fri, 28 Nov 2025 09:16:20 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 7D6AB1A018D for ; Fri, 28 Nov 2025 09:17:14 +0800 (CST) Received: from [10.174.176.88] (unknown [10.174.176.88]) by APP2 (Coremail) with SMTP id Syh0CgBHpXsY+ChphOEICQ--.36213S3; Fri, 28 Nov 2025 09:17:14 +0800 (CST) Message-ID: <9ff0d134-2c64-4204-bbac-9fdf0867ac46@huaweicloud.com> Date: Fri, 28 Nov 2025 09:17:11 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Bug report] hash_name() may cross page boundary and trigger sleep in RCU context To: Will Deacon , Zizhi Wo Cc: jack@suse.com, brauner@kernel.org, hch@lst.de, akpm@linux-foundation.org, linux@armlinux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, yangerkun@huawei.com, wangkefeng.wang@huawei.com, pangliyuan1@huawei.com, xieyuanbin1@huawei.com References: <20251126090505.3057219-1-wozizhi@huaweicloud.com> From: Zizhi Wo In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: Syh0CgBHpXsY+ChphOEICQ--.36213S3 X-Coremail-Antispam: 1UD129KBjvJXoW3WryrWw45uw1fKw17tw4rAFb_yoW7Zr18pr Wjk3W2krZIgrWak3yIqanxWFyrJa4Iqr4UGr9rGr1kuw47Xryjga1kK39Yk347Xw1kW3yF vr4Fvr1Uuw1DC3JanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvE14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4U JVWxJr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gc CE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E 2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJV W8JwACjcxG0xvEwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lFIxGxcIEc7CjxVA2Y2ka 0xkIwI1lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7 v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF 1VAY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIx AIcVC0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI 42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWI evJa73UjIFyTuYvjfUonmRUUUUU X-CM-SenderInfo: pzr2x6tkl6x35dzhxuhorxvhhfrp/ X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20251127_171727_666956_A6FA7C84 X-CRM114-Status: GOOD ( 23.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 在 2025/11/27 20:59, Will Deacon 写道: > On Wed, Nov 26, 2025 at 05:05:05PM +0800, Zizhi Wo wrote: >> We're running into the following issue on an ARM32 platform with the linux >> 5.10 kernel: >> >> [] (__dabt_svc) from [] (link_path_walk.part.7+0x108/0x45c) >> [] (link_path_walk.part.7) from [] (path_openat+0xc4/0x10ec) >> [] (path_openat) from [] (do_filp_open+0x9c/0x114) >> [] (do_filp_open) from [] (do_sys_openat2+0x418/0x528) >> [] (do_sys_openat2) from [] (do_sys_open+0x88/0xe4) >> [] (do_sys_open) from [] (ret_fast_syscall+0x0/0x58) >> ... >> [] (unwind_backtrace) from [] (show_stack+0x20/0x24) >> [] (show_stack) from [] (dump_stack+0xd8/0xf8) >> [] (dump_stack) from [] (___might_sleep+0x19c/0x1e4) >> [] (___might_sleep) from [] (do_page_fault+0x2f8/0x51c) >> [] (do_page_fault) from [] (do_DataAbort+0x90/0x118) >> [] (do_DataAbort) from [] (__dabt_svc+0x58/0x80) >> ... >> >> During the execution of hash_name()->load_unaligned_zeropad(), a potential >> memory access beyond the PAGE boundary may occur. For example, when the >> filename length is near the PAGE_SIZE boundary. This triggers a page fault, >> which leads to a call to do_page_fault()->mmap_read_trylock(). If we can't >> acquire the lock, we have to fall back to the mmap_read_lock() path, which >> calls might_sleep(). This breaks RCU semantics because path lookup occurs >> under an RCU read-side critical section. In linux-mainline, arm/arm64 >> do_page_fault() still has this problem: >> >> lock_mm_and_find_vma->get_mmap_lock_carefully->mmap_read_lock_killable. >> >> And before commit bfcfaa77bdf0 ("vfs: use 'unsigned long' accesses for >> dcache name comparison and hashing"), hash_name accessed the name byte by >> byte. >> >> To prevent load_unaligned_zeropad() from accessing beyond the valid memory >> region, we would need to intercept such cases beforehand? But doing so >> would require replicating the internal logic of load_unaligned_zeropad(), >> including handling endianness and constructing the correct value manually. >> Given that load_unaligned_zeropad() is used in many places across the >> kernel, we currently haven't found a good solution to address this cleanly. >> >> What would be the recommended way to handle this situation? Would >> appreciate any feedback and guidance from the community. Thanks! > > Does it help if you bodge the translation fault handler along the lines > of the untested diff below? Thank you for the solution you provided. However, I seem to have encountered a bit of a problem. > > Will > > --->8 > > diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c > index bf1577216ffa..b3c81e448798 100644 > --- a/arch/arm/mm/fault.c > +++ b/arch/arm/mm/fault.c > @@ -407,7 +407,7 @@ do_translation_fault(unsigned long addr, unsigned int fsr, > if (addr < TASK_SIZE) > return do_page_fault(addr, fsr, regs); > > - if (user_mode(regs)) > + if (user_mode(regs) || fsr_fs(fsr) == FSR_FS_INVALID_PAGE) > goto bad_area; I'm getting an "FSR_FS_INVALID_PAGE undeclared" error during compilation... In which kernel or FSR version was this macro or constant defined? > > index = pgd_index(addr); > diff --git a/arch/arm/mm/fault.h b/arch/arm/mm/fault.h > index 9ecc2097a87a..8fb26f85e361 100644 > --- a/arch/arm/mm/fault.h > +++ b/arch/arm/mm/fault.h > @@ -12,6 +12,8 @@ > #define FSR_FS3_0 (15) > #define FSR_FS5_0 (0x3f) > > +#define FSR_FS_INVALID_PAGE 7 > + > #ifdef CONFIG_ARM_LPAE > #define FSR_FS_AEA 17 > > diff --git a/arch/arm/mm/fsr-2level.c b/arch/arm/mm/fsr-2level.c > index f2be95197265..c7060da345df 100644 > --- a/arch/arm/mm/fsr-2level.c > +++ b/arch/arm/mm/fsr-2level.c > @@ -11,7 +11,7 @@ static struct fsr_info fsr_info[] = { > { do_bad, SIGBUS, 0, "external abort on linefetch" }, > { do_translation_fault, SIGSEGV, SEGV_MAPERR, "section translation fault" }, > { do_bad, SIGBUS, 0, "external abort on linefetch" }, > - { do_page_fault, SIGSEGV, SEGV_MAPERR, "page translation fault" }, > + { do_translation_fault, SIGSEGV, SEGV_MAPERR, "page translation fault" }, > { do_bad, SIGBUS, 0, "external abort on non-linefetch" }, > { do_bad, SIGSEGV, SEGV_ACCERR, "section domain fault" }, > { do_bad, SIGBUS, 0, "external abort on non-linefetch" }, > diff --git a/arch/arm/mm/fsr-3level.c b/arch/arm/mm/fsr-3level.c > index d0ae2963656a..19df4af828bd 100644 > --- a/arch/arm/mm/fsr-3level.c > +++ b/arch/arm/mm/fsr-3level.c > @@ -7,7 +7,7 @@ static struct fsr_info fsr_info[] = { > { do_bad, SIGBUS, 0, "reserved translation fault" }, > { do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 1 translation fault" }, > { do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 2 translation fault" }, > - { do_page_fault, SIGSEGV, SEGV_MAPERR, "level 3 translation fault" }, > + { do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 3 translation fault" }, > { do_bad, SIGBUS, 0, "reserved access flag fault" }, > { do_bad, SIGSEGV, SEGV_ACCERR, "level 1 access flag fault" }, > { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 access flag fault" }, > > By the way, I tried Al's solution, and this problem didn't reproduce. Thanks, Zizhi Wo