From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id AF7ED1D9665 for ; Thu, 17 Oct 2024 10:10:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729159820; cv=none; b=FlqWFY5FMcUsTsZv3jymXcvsglmF2aZrouPef6CVLq/4wyDScTakKd6IUOuqWE6KW25oVb0BBhBc3NS3yl/yznOMhuTFnwpuQ2YRRz5aiVuykLe+/lF0Ij4P9Gq8xq3D7pl6rwrIMD59IW+mU9u9zQcr7Ne/h/ToXCBvfql6weU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729159820; c=relaxed/simple; bh=5MmganSkY9EwYM+hJwn2kIIvfvkeRpb5Bzkji/bpPzI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nnL9ePW6huyOq4mJ/BbXiVgmBKubVSnTaQX5lDWjQpIEGYM1WMDDWeuo2Gwqled85rXYIeadZCsBaG/8BkrmVuCDKAwFOBaai9iinOUbp5SwklW1MP6Mxsa27WJwDplMw+nG/d92EsC1iRkemvSCjVc9mnif0W/u89vG9xaoso0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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.