From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Ruidong Tian <tianruidong@linux.alibaba.com>, <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>
Cc: <linux-kernel@vger.kernel.org>, <oliver.yang@linux.alibaba.com>
Subject: Re: [PATCH] sched: move stack_canary to the start of the randomizable region
Date: Fri, 8 May 2026 22:08:04 +0530 [thread overview]
Message-ID: <bf0feb68-987a-4f9d-9e26-1561c9c05cf7@amd.com> (raw)
In-Reply-To: <20260508061558.2976364-1-tianruidong@linux.alibaba.com>
Hello Ruidong,
On 5/8/2026 11:45 AM, Ruidong Tian wrote:
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 368c7b4d7cb5..d9ee2381c3a3 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -836,6 +836,11 @@ struct task_struct {
> */
> randomized_struct_fields_start
>
> +#ifdef CONFIG_STACKPROTECTOR
> + /* Canary value for the -fstack-protector GCC feature: */
> + unsigned long stack_canary;
> +#endif
So I'm looking at pahole and I see the following on mainline
(v7.1-rc2):
struct task_struct {
struct thread_info thread_info; /* 0 24 */
unsigned int __state; /* 24 4 */
unsigned int saved_state; /* 28 4 */
void * stack; /* 32 8 */
refcount_t usage; /* 40 4 */
unsigned int flags; /* 44 4 */
unsigned int ptrace; /* 48 4 */
int on_cpu; /* 52 4 */
struct __call_single_node wake_entry; /* 56 16 */
/* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */
unsigned int wakee_flips; /* 72 4 */
/* XXX 4 bytes hole, try to pack */
long unsigned int wakee_flip_decay_ts; /* 80 8 */
struct task_struct * last_wakee; /* 88 8 */
int recent_used_cpu; /* 96 4 */
int wake_cpu; /* 100 4 */
int on_rq; /* 104 4 */
int prio; /* 108 4 */
int static_prio; /* 112 4 */
int normal_prio; /* 116 4 */
unsigned int rt_priority; /* 120 4 */
/* XXX 4 bytes hole, try to pack */
/* --- cacheline 2 boundary (128 bytes) --- */
...
};
Except for alloc_tag, nothing in here is config dependent, and if we
move "wakee_flips" to after "last_wakee", we open up 8 bytes in this
cache line and "stack_canary" should be able to fit in there without
needing any additional space wrt to where we are at.
It'll look like:
struct task_struct {
...
int on_cpu; /* 52 4 */
struct __call_single_node wake_entry; /* 56 16 */
/* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */
unsigned long stack_canary; /* 72 8 */
long unsigned int wakee_flip_decay_ts; /* 80 8 */
struct task_struct * last_wakee; /* 88 8 */
unsigned int wakee_flips; /* 96 4 */
...
}
An offset of 72 bytes should be fine right? I doubt we'll ever add 2KB
worth of data in this area to worry about this again.
> +
> void *stack;
> refcount_t usage;
> /* Per task flags (PF_*), defined further below: */
--
Thanks and Regards,
Prateek
next prev parent reply other threads:[~2026-05-08 16:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-08 6:15 [PATCH] sched: move stack_canary to the start of the randomizable region Ruidong Tian
2026-05-08 16:38 ` K Prateek Nayak [this message]
2026-05-09 3:49 ` Ruidong Tian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bf0feb68-987a-4f9d-9e26-1561c9c05cf7@amd.com \
--to=kprateek.nayak@amd.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=oliver.yang@linux.alibaba.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tianruidong@linux.alibaba.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox