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 7AFF3D2127C for ; Thu, 17 Oct 2024 11:01:09 +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:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=r1G5gzVrFGvV5XZ+wXIqLJm0Yh1c2RZ6cLawElfg/Vw=; b=Ik7d/BDuFKSg+iPBIydhmU9ac9 C7TX20q067tHWrlX7hIFjrcZDm1scvdbmX0tXe9UXwbgMrmiaLjnAFeV5Xs0ATfFi4IK+EUhv/GeG +kc0TLnBybJ1dG54R5Ud/8sR7sv2XwtKRCjYbNKZ6TV+iNzHn3WYN98yF8IaqkyHn6Qt1NyJorCgd +7KiwKHpAW9980DNT7BcHXmnn6xGyiKkbH4ASY9o5DM1F6xhRlR+L0jTB7NFghRZB3qvsmCF9Xx5i eXCydJOkGrbSIYsKsvnh+sOCruGdYsY8dPAN70iPLcFKkDSXJ5MeKuDoE+Yfo9iBULYKspymS0Wdq nx2lI/8A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t1OFE-0000000EZ05-0AHf; Thu, 17 Oct 2024 11:00:40 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t1NSS-0000000ETfy-2qON for linux-arm-kernel@lists.infradead.org; Thu, 17 Oct 2024 10:10:18 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 775E9FEC; Thu, 17 Oct 2024 03:10:45 -0700 (PDT) Received: from J2N7QTR9R3 (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C0D5D3F71E; Thu, 17 Oct 2024 03:10:13 -0700 (PDT) Date: Thu, 17 Oct 2024 11:09:59 +0100 From: Mark Rutland To: Linus Walleij , Ard Biesheuvel Cc: Clement LE GOFFIC , Russell King , "Russell King (Oracle)" , Kees Cook , AngeloGioacchino Del Regno , Mark Brown , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, Antonio Borneo Subject: Re: Crash on armv7-a using KASAN Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241017_031016_824367_8BCFE04E X-CRM114-Status: GOOD ( 22.91 ) 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 On Wed, Oct 16, 2024 at 09:00:22PM +0200, Linus Walleij wrote: > On Wed, Oct 16, 2024 at 10:55 AM Mark Rutland wrote: > > > I believe that's necessary for the lazy TLB switch, at least for SMP: > > > > // CPU 0 // CPU 1 > > > > << switches to task X's mm >> > > > > << creates kthread task Y >> > > << maps task Y's new stack >> > > << maps task Y's new shadow >> > > > > // Y switched out > > context_switch(..., Y, ..., ...); > > > > // Switch from X to Y > > context_switch(..., X, Y, ...) { > > // prev = X > > // next = Y > > > > if (!next->mm) { > > // Y has no mm > > // No switch_mm() here > > // ... so no check_vmalloc_seq() > > } else { > > // not taken > > } > > > > ... > > > > // X's mm still lacks Y's stack + shadow here > > > > switch_to(prev, next, prev); > > } > > > > ... so probably worth a comment that we're faulting in the new > > stack+shadow for for lazy tlb when switching to a task with no mm? > > Switching to a task with no mm == switching to a kernel daemon. A common misconception, but not always true: * A kernel thread can have an mm: see kthread_use_mm() and kthread_unuse_mm(). * A user thread can lose its mm while exiting: see how do_exit() calls exit_mm(), and how hte task remains preemptible for a while thereafter. ... so we really do just mean "a task with no mm". > And those only use the kernel memory and relies on that always > being mapped in any previous mm context, right. A task with no mm only uses kernel memory. Anything it uses must be mapped in init_mm, but *might* not have been copied into every other mm, and hence might not be in the previous mm context as per the example above. > But where do we put that comment? In kernel/sched/core.c > context_switch()? I was trying to suggest we update the existing comment in switch_to() to be more explicit. e.g. expand the existing comment: @ @ Do a dummy read from the new stack while running from the old one so @ that we can rely on do_translation_fault() to fix up any stale PMD @ entries covering the vmalloc region. @ ... with: @ @ For a non-lazy mm switch, check_vmalloc_seq() has ensured that @ that the active mm's page tables have mappings for the prev @ task's stack and the next task's stack. @ @ For a lazy mm switch the active mm's page tables have mappings @ for the prev task's stack but might not have mappings for the @ new taks stack. Do a dummy read from the new stack while @ running from the old stack so that we can rely on @ do_translation_fault() to fix up any stale PMD entries @ covering the vmalloc region. @ Ard, does that sound good to you? Mark.