Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp363163pxb; Thu, 30 Sep 2021 07:41:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJybyOybidVGyVvdnoLsAj1EoqZZeoo6bEr3T1XHS6jEjsv1s9yie8FPAvW6je5zP0zzRuYQ X-Received: by 2002:a17:906:52d1:: with SMTP id w17mr7242276ejn.507.1633012876569; Thu, 30 Sep 2021 07:41:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633012876; cv=none; d=google.com; s=arc-20160816; b=cmBEoNeprZtNwsyT1CS7Tld18eAHGAl+cDMJqQgiCY39xZNiKs7CkcwNK3kwS6p72I bCwtj+os13zPSDaEk1BC0UJUajTz9hu7+3Wx4gVuNqijXrsmzE8wqYMUkjdJP9EEDgs6 Apiqp55NzxCEYau3dhK18z348+aP79ZHCcQzx+PcEd4LMMUysQYkbLO7TSYRIdX9hf5f c/3lLLFtnCSfJR6lMUQq3L5cDUZ/sMLS1OUjpFsjHULS17HunqhqOWKeyxBG857Odcup EbxEGi8ziDS5oNq/e2gzsUbpcnn8LfcGvTEV+kqKz95XKyHhNjWGagyZCK02AJIrfaLH Gq8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=FFlVU/wO8dbiyTrqe74R/y9sqaVCPM2Mp8oM6ke993c=; b=R37KRpAW9AhjhGnPjrWlDwjQnHDPGyoijVgVehIFKbk3f0W+RxMZNDq5QBRtET7eO4 /MYgOfs3kqscVbU3em1BvPjzisGV/6IV1BGJ7V7mltxKMDMx5UjCn7+/6ai0C5QRVIQN jBgRP9/JqRQY2rCfASDpfQgCWMhk+YR7SMGP8Yx68ni1ppPXECTG8kACULAyraGCFEVF TQ6NBkgb2kV13VNhr/gpH7hvWBnutfutrloQwIgZKEsfq3maHU53n4m0oFFn26YrND2U HVMKKe57Wk7a23CJNzwM5ir5JlZrDQW2lhgUAuMB+yC/OjmAYUKXLcMMFOU5FOvJOJbo inow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NTPAmls2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ds17si6427527ejc.757.2021.09.30.07.40.52; Thu, 30 Sep 2021 07:41:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NTPAmls2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350990AbhI3NWi (ORCPT + 99 others); Thu, 30 Sep 2021 09:22:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:40206 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350955AbhI3NWg (ORCPT ); Thu, 30 Sep 2021 09:22:36 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id E063C6187A for ; Thu, 30 Sep 2021 13:20:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1633008053; bh=/+EC8L1UcUE2bi7NaYazSzOjmyEsgKAWrMxnFdVdCPQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NTPAmls2GL2KfPIOOOLIv84iDTCtVJLUjEzIZUke3I11cGXeqADFtRsFkYkQRujy0 kOVl3MgQ4bsRgFaOWtC4wAMYf0OEguMi+Ma2VhAGx5LtTw25WUXUQ4cyjjajkINLBf W5x6F9UKxeXLsiQFVHBupEzK9cOUoEEcUsLYvVG3xDLtVBsPuKBfZV0O8xLtzqQ3lB ZmIh507VWJBdFfSje0kTIDEbGaTo3pb25rQ46WL9k3oGqcw9XH2ZP5qXzBdiICCyzt Umq+oYg+aM5gBn2CBjkJY4Cs0KxPM6NZjD2Iu18ycL0gF01o4tVeKwdYpRgheS9tWW LP8uph3PzQoGg== Received: by mail-ot1-f47.google.com with SMTP id c26-20020a056830349a00b0054d96d25c1eso7196485otu.9 for ; Thu, 30 Sep 2021 06:20:53 -0700 (PDT) X-Gm-Message-State: AOAM5337OHoxHLZgdyiV92a5JKWbEsYCiYokoU7OBIKT5kBC4Ip6mrm0 qAlQ3ez5i3PtXHetdbosWlWJRODU6va+3tJyt3A= X-Received: by 2002:a9d:63c7:: with SMTP id e7mr5289543otl.30.1633008052198; Thu, 30 Sep 2021 06:20:52 -0700 (PDT) MIME-Version: 1.0 References: <20210930125813.197418-1-ardb@kernel.org> <20210930125813.197418-2-ardb@kernel.org> <6b003f58-48df-7ac4-4dbf-81b2c5bca5d9@csgroup.eu> In-Reply-To: From: Ard Biesheuvel Date: Thu, 30 Sep 2021 15:20:41 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 1/7] arm64: add CPU field to struct thread_info To: Christophe Leroy Cc: Linux Kernel Mailing List , Keith Packard , Russell King , Catalin Marinas , Will Deacon , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Paul Walmsley , Palmer Dabbelt , Albert Ou , Heiko Carstens , Mark Rutland Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 30 Sept 2021 at 15:15, Christophe Leroy wrote: > > > > Le 30/09/2021 =C3=A0 15:07, Ard Biesheuvel a =C3=A9crit : > > On Thu, 30 Sept 2021 at 15:06, Christophe Leroy > > wrote: > >> > >> > >> > >> Le 30/09/2021 =C3=A0 14:58, Ard Biesheuvel a =C3=A9crit : > >>> The CPU field will be moved back into thread_info even when > >>> THREAD_INFO_IN_TASK is enabled, so add it back to arm64's definition = of > >>> struct thread_info. > >>> > >>> Note that arm64 always has CONFIG_SMP=3Dy so there is no point in gua= rding > >>> the CPU field with an #ifdef. > >>> > >>> Signed-off-by: Ard Biesheuvel > >>> Acked-by: Catalin Marinas > >>> Acked-by: Mark Rutland > >>> --- > >>> arch/arm64/include/asm/thread_info.h | 1 + > >>> arch/arm64/kernel/asm-offsets.c | 1 + > >>> 2 files changed, 2 insertions(+) > >>> > >>> diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/includ= e/asm/thread_info.h > >>> index 6623c99f0984..c02bc8c183c3 100644 > >>> --- a/arch/arm64/include/asm/thread_info.h > >>> +++ b/arch/arm64/include/asm/thread_info.h > >>> @@ -42,6 +42,7 @@ struct thread_info { > >>> void *scs_base; > >>> void *scs_sp; > >>> #endif > >>> + u32 cpu; > >>> }; > >>> > >>> #define thread_saved_pc(tsk) \ > >>> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-= offsets.c > >>> index 551427ae8cc5..cee9f3e9f906 100644 > >>> --- a/arch/arm64/kernel/asm-offsets.c > >>> +++ b/arch/arm64/kernel/asm-offsets.c > >>> @@ -29,6 +29,7 @@ int main(void) > >>> DEFINE(TSK_ACTIVE_MM, offsetof(struct task_struct, a= ctive_mm)); > >>> DEFINE(TSK_CPU, offsetof(struct task_struct, cpu)); > >>> BLANK(); > >>> + DEFINE(TSK_TI_CPU, offsetof(struct task_struct, thread_inf= o.cpu)); > >> > >> Why adding that now ? For powerpc you do the switch in 5. > >> > > > > > > Why not? > > Maybe to remain consistent between archs ? > Does it matter? > > > > > >>> DEFINE(TSK_TI_FLAGS, offsetof(struct task_struct, t= hread_info.flags)); > >>> DEFINE(TSK_TI_PREEMPT, offsetof(struct task_struct, thread_in= fo.preempt_count)); > >>> #ifdef CONFIG_ARM64_SW_TTBR0_PAN > >>>