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.2 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,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 5B09FC433E0 for ; Mon, 1 Feb 2021 19:10:57 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 215C564DD8 for ; Mon, 1 Feb 2021 19:10:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 215C564DD8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=TzaTOAeLa4wmpnd1D6PgjrX6UJSbCNdSJaLYbVSjMbw=; b=qYRuEGE0ZPCgTdpd0dDCJw+c8 w2aa1ER/8vUHtd2hZsWTnGcCmBouXISllF3v5fVmUQM1XD8vN2tlfc+P+TNMufwN/dJHxc4CS3ufV Ei+OWobolROBL6vVi8DPXl0Rc4W7TByUHEP5amEkqgQR8LPMw8qHvGoYroooBvUNiu7BK36gDhd4e 1nSKAIv5ZO0th+DSajjZ5WAg0BcDvDuQ8mEDTIhpOdYeOd2WPDQFU6mYEpPqP4ZRjeVRk2vOzZFuN b4Pos0DSMtN5U7thK0n522UA/bbV8hhIqNoAkuAq8oHiW29L+EpzsGOvd9zGK3cqb8OVb+Esg0x/j DCbbq/N+Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6ea5-00063B-6M; Mon, 01 Feb 2021 19:09:49 +0000 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6ea1-00061b-Vq for linux-arm-kernel@lists.infradead.org; Mon, 01 Feb 2021 19:09:47 +0000 Received: by mail-wr1-x42b.google.com with SMTP id s7so14848500wru.5 for ; Mon, 01 Feb 2021 11:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=KZi22gvuBwqLPDw7duQoMyJfkf0Ns5lGGvKYgIcT0M0=; b=UK1+re8uelEE9t/0L7EegL7C3kNRfJ3JoCcg1MGv29LRpwMTRTZKHCBfKCiCmGpt2D M12l60IfJOBrblKbEqLqzCcMIK3cpef/UlZf5Ye8o5wbedwZWxL21MzE8+9JJph28oVh jZKg5Y7La97pY/SN8AZOvGBqMkj2sCRRWfQYE0H8N78mzmN/RbBWgvqHeYSUbp2V+gjO CXVFOJEsqFEYY5rGO23x1EKcQ9q7Qzs1x8RbGeZi0a1EWIrgD/eo3JkttplJiE2W2CRn NfRJfcgYm2vnsRuErNLic8lywWAGFc+CzWgsEwxgXjuVOnuUeC25o+HZM9CqXgaptgKy N3Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=KZi22gvuBwqLPDw7duQoMyJfkf0Ns5lGGvKYgIcT0M0=; b=tkEY28b2KuLV+HKrSgcLq2bktGiyPGT4/rn6LS1rBk7TNDH0ScmiiZId0FTSJ6iKW3 ZaQsJcN8vpWRPpY7pDEG0J4cIPvGstTQcaPOd0hRdu+GgHP03vUUpgpvDw+aLuo/dFET /27G1aZep9x5LZ3yNlQKgqjDIiWVRPcxZOvKKI9l/Le3woQHnIcMxoHu+LQ2h2b+enps NBdjmbTygYFKIekM5zWinEhSeDRobG4pfF3ULdm6Hd9IQZJQF3kPVY9ohdfxG/UseALK AXSbdJ6Z/VFvZohhm19KxgvMpeFiXd4BF0F3dAGoy5v5m69XjZY2ag7DphJyo5tJcoe6 dG9Q== X-Gm-Message-State: AOAM53210RCOwz+6KT6CIjlugYbFk1alRGBtl5nTt+Y/FOVpN2r3bKpb JUOyZ2vNK4FvsC+C4L6ssD0= X-Google-Smtp-Source: ABdhPJzq2/635daITjmdfnXEoXNbSSImmLPo+eE0Q03DvygR8UEIHnqVAcVix/o8GrWPEpFyanhGgQ== X-Received: by 2002:a5d:6b45:: with SMTP id x5mr19183573wrw.415.1612206584578; Mon, 01 Feb 2021 11:09:44 -0800 (PST) Received: from p4 (net-93-70-85-165.cust.vodafonedsl.it. [93.70.85.165]) by smtp.gmail.com with ESMTPSA id s24sm220864wmh.22.2021.02.01.11.09.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Feb 2021 11:09:44 -0800 (PST) Date: Mon, 1 Feb 2021 19:09:41 +0000 From: Giancarlo Ferrari To: Mark Rutland Subject: Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated Message-ID: <20210201190938.GB15399@p4> References: <1612140296-12546-1-git-send-email-giancarlo.ferrari89@gmail.com> <20210201124720.GA66060@C02TD0UTHF1T.local> <20210201143943.GA15399@p4> <20210201153012.GC66060@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210201153012.GC66060@C02TD0UTHF1T.local> User-Agent: Mutt/1.5.24 (2015-08-30) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210201_140946_070480_51E08BC2 X-CRM114-Status: GOOD ( 36.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux@armlinux.org.uk, linux-kernel@vger.kernel.org, penberg@kernel.org, geert@linux-m68k.org, linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, rppt@kernel.org, giancarlo.ferrari@nokia.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Mon, Feb 01, 2021 at 03:30:12PM +0000, Mark Rutland wrote: > Hi, > > On Mon, Feb 01, 2021 at 02:39:46PM +0000, Giancarlo Ferrari wrote: > > On Mon, Feb 01, 2021 at 12:47:20PM +0000, Mark Rutland wrote: > > > On Mon, Feb 01, 2021 at 12:44:56AM +0000, Giancarlo Ferrari wrote: > > > > machine_kexec() need to set rw permission in text and rodata sections > > > > to assign some variables (e.g. kexec_start_address). To do that at > > > > the end (after flushing pdm in memory, etc.) it needs to invalidate > > > > TLB [section] entries. > > > > > > It'd be worth noting explicitly that set_kernel_text_rw() alters > > > current->active_mm... > > > > > > > If during the TLB invalidation an interrupt occours, which might cause > > > > a context switch, there is the risk to inject invalid TLBs, with ro > > > > permissions. > > > > > > ... which is why if there's a context switch things can go wrong, since > > > active_mm isn't stable, and so it's possible that set_kernel_text_rw() > > > updates multiple tables, none of which might be the active table at the > > > point we try to make an access. > > > > Maybe the behaviour causing issue is not completely clear to me, and I do > > apologize for that (moreover I haven't eougth debug capabilities). > > I think we're in rough agreement that the issue is likely related to the > context switch, but our understanding of the specifics differs (and I > think we're missing a detail here). > > > However, current-active_mm is switched among context switches. Correct ? > > In some cases current->active_mm is not switched, and can be inherited > over a context switch. When switching to a user task, we always switch > to its mm (which becomes the active_mm), but when switching to a kthread > we retain the previous task's mm as the active_mm as part of the lazy > context switch. > > So while a kthread is preemptible, its active_mm (and active ASID) can > change under its feet. That could happen anywhere while the task is > preemptible, e.g. in the middle of set_kernel_text_rw(), or > mid-modification to the kexec variables. > Yes. In my understanding, even in the case of user process, when current->active_mm is switched, we can run into trouble. For instance: - Process A issue kexec (PageTables entry of A has 0x8000_0000-0x8010_0000 with ro permission and section is global, no NG bit set). - A context switch happens in the middle of set_kernel_text_rw(), right after the section 0x8000_0000-0x8010_0000 has been invalidated. - Process B, in its execution, re-inject its own PageTable entry with ro permission, which is not shared with Process A (and is not touched by the previous invalidation) in the MMU cache. - When Process A, is rescheduled, it carries on with the invalidation, but unfortunately I have "wrong" entries in the MMU. > > So, in principle, the invalidation, if stopped, is carried on where it > > left. > > That's true so long as all the processes we switch between share the > same leaf tables for the region we're altering. If not, then the lazy > context switch means that those tables can change under our feet. > > I believe the tables mapping the kernel text are shared by all threads, > and if so this _should_ be true. Russell might be able to confirm that > or correct me if I have that wrong. > I am not ready to put my hand on the fire, but I seen the behaviour described above. > > I thought the issue was that the PageTable entry for the section 0x8010_0000 > > is global, thus not indexed by ASID (Address Space ID). By the fact that each > > process has its own version of that entry, is the cause of the issue, as the > > schedule process might bringing a spurious entry (with ro permission) in the > > MMU cache. > > The TLB invalidation performed under set_kernel_text_rw() affects all > ASIDs on the current CPU, so there shouldn't be any stale RO TLB entries > to hit unless the kthread is migrated to another CPU. > > > If the entry is not global holds the ASID, and the issue cannot happen. > > I don't think that's true, since switching to a different active_mm > would also change ASID, and we'd have no additional guarantee. > I agree, my fault. > Thanks, > Mark. Thanks, GF _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel