[PATCH v2] task_struct: stack_canary is not needed without CC_STACKPROTECTOR

[Hiroshi Shimamoto]

Andi Kleen wrote:
> Hiroshi Shimamoto <h-shimamoto@xxxxxxxxxxxxx> writes:
> 
>> From: Hiroshi Shimamoto <h-shimamoto@xxxxxxxxxxxxx>
>>
>> The field stack_canary is only used with CC_STACKPROTECTOR.
>> This patch reduces task_struct size without CC_STACKPROTECTOR.
> 
> Adding a ifdef in the middle of a widely used structure is nasty.  It
> means that if someone changes the option then the newly loaded modules
> don't work anymore (yes that's not officially supported, but works
> most of the time and is often convenient in practice)
> 
> So when you add a ifdef please move the field to the end at least.

Thanks for the comment, that's reasonable.
Here's the update.

====
From: Hiroshi Shimamoto <h-shimamoto@xxxxxxxxxxxxx>

The field stack_canary is only used with CC_STACKPROTECTOR.
This patch reduces task_struct size without CC_STACKPROTECTOR.

Signed-off-by: Hiroshi Shimamoto <h-shimamoto@xxxxxxxxxxxxx>
---
 include/linux/sched.h |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index af1e328..9a1d68d 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1247,9 +1247,6 @@ struct task_struct {
 	pid_t pid;
 	pid_t tgid;
 
-	/* Canary value for the -fstack-protector gcc feature */
-	unsigned long stack_canary;
-
 	/* 
 	 * pointers to (original) parent process, youngest child, younger sibling,
 	 * older sibling, respectively.  (p->father can be replaced with 
@@ -1494,6 +1491,10 @@ struct task_struct {
 	/* bitmask of trace recursion */
 	unsigned long trace_recursion;
 #endif /* CONFIG_TRACING */
+#ifdef CONFIG_CC_STACKPROTECTOR
+	/* Canary value for the -fstack-protector gcc feature */
+	unsigned long stack_canary;
+#endif
 };
 
 /* Future-safe accessor for struct task_struct's cpus_allowed. */
-- 
1.6.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/