The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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


  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