From nobody Sat May 30 12:37:18 2026 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 74DB523D2A4 for ; Sat, 9 May 2026 03:50:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.119 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778298622; cv=none; b=VWaC3aB+U1QcxQKhc5Pc1FlyRnA1fM1JA/lGueiXkB8veQ4iM9FQasPhATGj7DrHU4u9TevT+4YarfjytEOGcSNsjkfuM8nXF+whXccylJwfI7i1Ofi7iEDN03Ca8FTa8yKCTB8tDA84JEbz/RVrOc+lfbqJFFke+rhWcv+zDgQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778298622; c=relaxed/simple; bh=4LqpbrjIzIuj6aMp8r6WZtli3urbwZ1mHiID93K3TYE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=QOguz4U23Ez0wBoBB46b4Ys/OiPT3yo7IST0t4aEEAOCRFvlSofwASBllpreAJ8LIrE5K4sSYELgHaG5uxfjlU6f9cAuF9Omt6z+CKi1N23Bcb+rOKwwqcW4mH108osUPftDY0j3azJjL0uaC92uxbXfdu/VN0YkpVUtumdB+vo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=oPqgjGUJ; arc=none smtp.client-ip=115.124.30.119 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="oPqgjGUJ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1778298618; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=RQEqFkfpYLaOOuHkWnzb0jdYNOqeNUzC1GGk2CWyZqc=; b=oPqgjGUJfrI6P+/X827k4UxZCk0E2PQWk2kfazP/5/rQxV+R99RE1SXj95kmSpdGKAiC3K+CGNMmJq0A2gGhdKkJn+DWE2XOmd/FinLe0ymvc4guxiG/vS9o51pA1Pya692Dm9R7Gn1NZQlK0RT8N628/XmiLqvOiyKnfQf20sA= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R381e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033032089153;MF=tianruidong@linux.alibaba.com;NM=1;PH=DS;RN=13;SR=0;TI=SMTPD_---0X2ZICSd_1778298615; Received: from localhost(mailfrom:tianruidong@linux.alibaba.com fp:SMTPD_---0X2ZICSd_1778298615 cluster:ay36) by smtp.aliyun-inc.com; Sat, 09 May 2026 11:50:17 +0800 From: Ruidong Tian To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, kprateek.nayak@amd.com Cc: linux-kernel@vger.kernel.org, oliver.yang@linux.alibaba.com, Ruidong Tian Subject: [PATCH v2] sched: move stack_canary to the start of the randomizable region Date: Sat, 9 May 2026 11:50:14 +0800 Message-ID: <20260509035014.2220372-1-tianruidong@linux.alibaba.com> X-Mailer: git-send-email 2.43.7 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" task_struct keeps growing over time. On architectures that compute the per-task stack canary offset from asm-offsets.h and pass it to the compiler via -mstack-protector-guard-offset=3D, this growth eventually pushes stack_canary beyond what the target ISA can encode. On RISC-V, canary loads are emitted as ld t0, TSK_STACK_CANARY(tp) where TSK_STACK_CANARY must fit into a 12-bit signed immediate, i.e. [-2048, 2047]. Once stack_canary sits past byte 2047 of task_struct, the build fails with cc1: error: '' is not a valid offset in '-mstack-protector-guard-offset=3D' * On RISC-V, CONFIG_STACKPROTECTOR_PER_TASK depends on !RANDSTRUCT, so randomized_struct_fields_start/end always expand to nothing and stack_canary lands at a small, stable offset well within the 12-bit signed immediate range. The build error goes away. * On architectures that enable RANDSTRUCT for hardening, stack_canary stays inside the randomized region and is still shuffled together with the other fields by the layout randomization, so its hardening coverage is preserved. asm-offsets-based architectures read the shuffled offset at build time, so the generated canary accesses remain correct. pahole on a typical 64-bit config shows that the area around the wakee_* fields already contains a usable hole: struct __call_single_node wake_entry; /* 56 16 */ /* --- cacheline 1 boundary (64 bytes) --- */ unsigned int wakee_flips; /* 72 4 */ /* XXX 4 bytes hole, try to pack */ unsigned long int wakee_flip_decay_ts; /* 80 8 */ struct task_struct * last_wakee; /* 88 8 */ Move wakee_flips to sit after last_wakee. That opens up a clean 8-byte slot at offset 72 into which stack_canary fits exactly: struct __call_single_node wake_entry; /* 56 16 */ /* --- cacheline 1 boundary (64 bytes) --- */ unsigned long stack_canary; /* 72 8 */ unsigned long int wakee_flip_decay_ts; /* 80 8 */ struct task_struct * last_wakee; /* 88 8 */ unsigned int wakee_flips; /* 96 4 */ Suggested-by: K Prateek Nayak Signed-off-by: Ruidong Tian Reviewed-by: Valentin Schneider --- include/linux/sched.h | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/include/linux/sched.h b/include/linux/sched.h index 368c7b4d7cb5..5064c4afd19c 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -848,9 +848,15 @@ struct task_struct { =20 int on_cpu; struct __call_single_node wake_entry; - unsigned int wakee_flips; + +#ifdef CONFIG_STACKPROTECTOR + /* Canary value for the -fstack-protector GCC feature: */ + unsigned long stack_canary; +#endif + unsigned long wakee_flip_decay_ts; struct task_struct *last_wakee; + unsigned int wakee_flips; =20 /* * recent_used_cpu is initially set as the last CPU used by a task @@ -1060,10 +1066,6 @@ struct task_struct { pid_t pid; pid_t tgid; =20 -#ifdef CONFIG_STACKPROTECTOR - /* Canary value for the -fstack-protector GCC feature: */ - unsigned long stack_canary; -#endif /* * Pointers to the (original) parent process, youngest child, younger sib= ling, * older sibling, respectively. (p->father can be replaced with --=20 2.51.2.612.gdc70283dfc