Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1260999ybl; Mon, 2 Dec 2019 00:17:41 -0800 (PST) X-Google-Smtp-Source: APXvYqwTl1FMtW8x2088W+JGYWDOj287uQ9/v8mwMC9oslMHgMsvJ3TlFSl3KfWXjQhRXkwFmAmV X-Received: by 2002:a05:6402:518:: with SMTP id m24mr32750537edv.35.1575274660856; Mon, 02 Dec 2019 00:17:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575274660; cv=none; d=google.com; s=arc-20160816; b=HL5Ixlf8KQi8lxSZdWHOMEQjYApw5iBw9XHucTQYXF1iSheSeyUnJjS26yAMKeJ7Wa Locsnl61mB62LIodiuAWAvSKlhucA32SdSLbJaMlcfuazqXHhQPss2FQnm59cYFT7yas OAwAp6y9mmC+eNMq33g/QOuFp6abMfj42hdacgQY9pp89+QDXrF6gB1xbmvvjJFJDp+3 +CS7lYSeXdpUGQ5RCIeqwWSddLbMrSWF2s57wT+5Kru92C9NZ9JHNx/uVZEgnjONt9VG v/ARqmsHG/7LB5hJ4U51SCTF5FJVpw+xXEtf4ONWczUkvo/O7FVxr+Abv6i4mv9VNtbz 8QWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from; bh=7Bpeh/wKhNQxWOq2vvAD66wPN/026m6ExwLvAFCXI6c=; b=SJliMf8BuP1+tQmuat7YyY07u544hKXUt8v6siZLpggmDObnGadXg8tFsF4OOa0OZj pGRH3iMutxAbzvun7rQFUn511j48IsVz7k3xOropnDpUOC7zkzsZZ+bCRnXMAIy02RyG dgaspbJ5DtFt66Bq8S/VDPDUbXuBpzXsPBCTxfIE+ziO6LnG7t0t5VqIZbyxzdtRza+9 ukagHhO7M9Pjfgo0E4xcN+t1r2jaSTEns9ZekSsof/QVAKPbNVsP6IH34BG6PyHd4lAf +dPlcWTH9g+j6fLYgFbcAWDBZSt9CWuHPJPvjlHC+R1Nd5aChzx8YM8YfuYDk5T2VoSQ Yngw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w11si345791edr.139.2019.12.02.00.17.17; Mon, 02 Dec 2019 00:17:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727460AbfLBIOu (ORCPT + 99 others); Mon, 2 Dec 2019 03:14:50 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:37320 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726254AbfLBIOX (ORCPT ); Mon, 2 Dec 2019 03:14:23 -0500 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 90F8DFAE075D8D407738; Mon, 2 Dec 2019 16:14:17 +0800 (CST) Received: from huawei.com (10.175.124.28) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.439.0; Mon, 2 Dec 2019 16:14:10 +0800 From: "zhangyi (F)" To: CC: , , , , , , , , , , , Subject: [PATCH 4.4 3/7] sched/core, x86: Make struct thread_info arch specific again Date: Mon, 2 Dec 2019 16:35:15 +0800 Message-ID: <20191202083519.23138-4-yi.zhang@huawei.com> X-Mailer: git-send-email 2.17.2 In-Reply-To: <20191202083519.23138-1-yi.zhang@huawei.com> References: <20191202083519.23138-1-yi.zhang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.175.124.28] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Heiko Carstens commit c8061485a0d7569a865a3cc3c63347b0f42b3765 upstream. The following commit: c65eacbe290b ("sched/core: Allow putting thread_info into task_struct") ... made 'struct thread_info' a generic struct with only a single ::flags member, if CONFIG_THREAD_INFO_IN_TASK_STRUCT=y is selected. This change however seems to be quite x86 centric, since at least the generic preemption code (asm-generic/preempt.h) assumes that struct thread_info also has a preempt_count member, which apparently was not true for x86. We could add a bit more #ifdefs to solve this problem too, but it seems to be much simpler to make struct thread_info arch specific again. This also makes the conversion to THREAD_INFO_IN_TASK_STRUCT a bit easier for architectures that have a couple of arch specific stuff in their thread_info definition. The arch specific stuff _could_ be moved to thread_struct. However keeping them in thread_info makes it easier: accessing thread_info members is simple, since it is at the beginning of the task_struct, while the thread_struct is at the end. At least on s390 the offsets needed to access members of the thread_struct (with task_struct as base) are too large for various asm instructions. This is not a problem when keeping these members within thread_info. Signed-off-by: Heiko Carstens Signed-off-by: Mark Rutland Acked-by: Thomas Gleixner Cc: Andrew Morton Cc: Andy Lutomirski Cc: Linus Torvalds Cc: Peter Zijlstra Cc: keescook@chromium.org Cc: linux-arch@vger.kernel.org Link: http://lkml.kernel.org/r/1476901693-8492-2-git-send-email-mark.rutland@arm.com Signed-off-by: Ingo Molnar [ zhangyi: skip defination of INIT_THREAD_INFO and struct thread_info ] Signed-off-by: zhangyi (F) --- include/linux/thread_info.h | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h index 2813de75a96e..897e835379d8 100644 --- a/include/linux/thread_info.h +++ b/include/linux/thread_info.h @@ -13,17 +13,6 @@ struct timespec; struct compat_timespec; -#ifdef CONFIG_THREAD_INFO_IN_TASK -struct thread_info { - u32 flags; /* low level flags */ -}; - -#define INIT_THREAD_INFO(tsk) \ -{ \ - .flags = 0, \ -} -#endif - #ifdef CONFIG_THREAD_INFO_IN_TASK #define current_thread_info() ((struct thread_info *)current) #endif -- 2.17.2