From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 5AA763264F7 for ; Fri, 21 Aug 2026 17:11:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787332313; cv=none; b=liSHrbdUWZ/NPPFBwPUJrimf53tBVLnjdF45yXqwyxmSgZfCm+TX/SsjsJ12H5BH8MdDY8AKY445C4ZC8rLSyBJ7vqwJ/e3iKnWb/Mcly4mzQMnvDuUJVXS/Pt6iYXNl4+RxGLj0gZRT94UJxnevE/m+czJP0b4P16jn6EBHFvU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787332313; c=relaxed/simple; bh=T+fw2U6TAwmLmPKUyY1ryWtiZOL0KqK3ebjqVETP4kI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type:Content-Disposition; b=b1YRy0c4iHa1muyHVnYbE5dTm93RRbmSCu+ZCdH7XsLE62krzl8X5n7HiJFY9VtNRm40HUHbMhMp65W+gg9DZ1J5SYbI1+uwYIaJOpsJ2bDrvrUrBgiEcYU2mJ1kgNH1/Qiq+ETNcNHMyR8dOtjHutHiEPt6dEs+Me1HAZaqxnI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=NcC1RsLA; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="NcC1RsLA" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1787332311; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Zi9iwiB91DU3G3fOh1jtokgzea+BDVppiEtnBmMzEyI=; b=NcC1RsLAdZZ9ufxFx8vRv9PCsqN9bjz0+A+aCyDhPRTvK5uu0SECMzc70KzYVX7Y7chZWe Xro5d6x12R/usCVjSnZaBaxm37GniBGf78v8KWPCgNNf4vu4ZCAQ71sOuz1rHH72bUTZ5u 3goDUHeH+kh3F8EfpRmoZKkvxu0I3do= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-678-XK9I8aNVOwKtLUhDmZKnYQ-1; Fri, 21 Aug 2026 13:11:46 -0400 X-MC-Unique: XK9I8aNVOwKtLUhDmZKnYQ-1 X-Mimecast-MFC-AGG-ID: XK9I8aNVOwKtLUhDmZKnYQ_1787332304 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8140F1801331; Fri, 21 Aug 2026 17:11:43 +0000 (UTC) Received: from cmirabil.redhat.com (unknown [10.2.16.118]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 618A318005AA; Fri, 21 Aug 2026 17:11:39 +0000 (UTC) From: Charles Mirabile To: vschneid@redhat.com Cc: bsegall@google.com, dietmar.eggemann@arm.com, juri.lelli@redhat.com, kprateek.nayak@amd.com, linux-kernel@vger.kernel.org, mgorman@suse.de, mingo@redhat.com, oliver.yang@linux.alibaba.com, peterz@infradead.org, rostedt@goodmis.org, tianruidong@linux.alibaba.com, vincent.guittot@linaro.org, pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr, linux-riscv@lists.infradead.org Subject: Re: [PATCH v2] sched: move stack_canary to the start of the randomizable region Date: Fri, 21 Aug 2026 13:11:27 -0400 Message-ID: <20260821171127.1061494-1-cmirabil@redhat.com> In-Reply-To: References: <20260509035014.2220372-1-tianruidong@linux.alibaba.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 Hi Ruidong, Valentin, (+ copying in RISC-V list/maintainers)— On Tue, May 12, 2026 at 06:16:43PM +0200, Valentin Schneider wrote: > On 09/05/26 11:50, Ruidong Tian wrote: > > 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=, 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=' Thanks for this patch. We just ran into this exact issue during a CKI build https://datawarehouse.cki-project.org/kcidb/builds/1639782 and this seems like exactly the fix we need. > > > > * 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 > Thanks for the review, is there any hope of this patch going in during the 7.3 merge window? I have also copied the RISC-V list as well, maybe if it is ok with the sched folks, the RISC-V maintainers could take it through their tree as a RISC-V specific urgent fix? Best—Charlie