All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zefan Li <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Tetsuo Handa
	<penguin-kernel-1yMVhJb1mP/7nzcFbJAaVXf5DAMn2ifp@public.gmane.org>,
	Miao Xie <miaox-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v2 2/3] sched: add a macro to define bitops for task atomic flags
Date: Tue, 23 Sep 2014 14:52:50 +0800	[thread overview]
Message-ID: <542118C2.6030302@huawei.com> (raw)
In-Reply-To: <CAGXu5jJKNJ=PsTtkPaoMyCNf2fK07szP-hv4NdaiDVx4tHacQw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

>> -static inline bool task_no_new_privs(struct task_struct *p)
>> -{
>> -       return test_bit(PFA_NO_NEW_PRIVS, &p->atomic_flags);
>> -}
>> -
>> -static inline void task_set_no_new_privs(struct task_struct *p)
>> -{
>> -       set_bit(PFA_NO_NEW_PRIVS, &p->atomic_flags);
>> -}
>> +#define TASK_PFA_BITOPS(name, func)                            \
>> +static inline bool task_##func(struct task_struct *p)          \
>> +{ return test_bit(PFA_##name, &p->atomic_flags); }             \
>> +                                                               \
>> +static inline void task_set_##func(struct task_struct *p)      \
>> +{ set_bit(PFA_##name, &p->atomic_flags); }                     \
>> +                                                               \
>> +static inline void task_clear_##func(struct task_struct *p)    \
>> +{ clear_bit(PFA_##name, &p->atomic_flags); }
>> +
>> +TASK_PFA_BITOPS(NO_NEW_PRIVS, no_new_privs)
> 
> One thing I don't like about this is that task_clear_no_new_privs()
> ends up getting defined, and it should absolutely never be used. NNP
> should never be cleared or there could be security issues. I realize
> this isn't a very useful nit-pick, but I'd rather the function wasn't
> even available for someone to accidentally use. Maybe break up the
> macro with some kind of "write only" version like:
> 
> #define TASK_PFA_BITOPS_WO(name, func)                            \
> static inline bool task_##func(struct task_struct *p)          \
> { return test_bit(PFA_##name, &p->atomic_flags); }             \
> static inline void task_set_##func(struct task_struct *p)      \
> { set_bit(PFA_##name, &p->atomic_flags); }
> 
> #define TASK_PFA_BITOPS(name, func)                            \
> TASK_PFA_BITOPS_WO(name, func);          \
> static inline void task_clear_##func(struct task_struct *p)    \
> { clear_bit(PFA_##name, &p->atomic_flags); }
> 
> TASK_PFA_BITOPS_WO(NO_NEW_PRIVS, no_new_privs)
> 
> And then all the new users can use TASK_PFA_BITOPS() normally since
> they expect to use "clear"?
> 

Now I'm inclined to do this:

+#define TASK_PFA_TEST(name, func)					\
+	static inline bool task_##func(struct task_struct *p)		\
+	{ return test_bit(PFA_##name, &p->atomic_flags); }
+#define TASK_PFA_SET(name, func)					\
+	static inline void task_set_##func(struct task_struct *p)	\
+	{ set_bit(PFA_##name, &p->atomic_flags); }
+#define TASK_PFA_CLEAR(name, func)					\
+	static inline void task_clear_##func(struct task_struct *p)	\
+	{ clear_bit(PFA_##name, &p->atomic_flags); }
+
+TASK_PFA_TEST(NO_NEW_PRIVS, no_new_privs)
+TASK_PFA_SET(NO_NEW_PRIVS, no_new_privs)

WARNING: multiple messages have this Message-ID (diff)
From: Zefan Li <lizefan@huawei.com>
To: Kees Cook <keescook@chromium.org>
Cc: Tejun Heo <tj@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
	"Ingo Molnar" <mingo@kernel.org>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Miao Xie <miaox@cn.fujitsu.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Cgroups <cgroups@vger.kernel.org>
Subject: Re: [PATCH v2 2/3] sched: add a macro to define bitops for task atomic flags
Date: Tue, 23 Sep 2014 14:52:50 +0800	[thread overview]
Message-ID: <542118C2.6030302@huawei.com> (raw)
In-Reply-To: <CAGXu5jJKNJ=PsTtkPaoMyCNf2fK07szP-hv4NdaiDVx4tHacQw@mail.gmail.com>

>> -static inline bool task_no_new_privs(struct task_struct *p)
>> -{
>> -       return test_bit(PFA_NO_NEW_PRIVS, &p->atomic_flags);
>> -}
>> -
>> -static inline void task_set_no_new_privs(struct task_struct *p)
>> -{
>> -       set_bit(PFA_NO_NEW_PRIVS, &p->atomic_flags);
>> -}
>> +#define TASK_PFA_BITOPS(name, func)                            \
>> +static inline bool task_##func(struct task_struct *p)          \
>> +{ return test_bit(PFA_##name, &p->atomic_flags); }             \
>> +                                                               \
>> +static inline void task_set_##func(struct task_struct *p)      \
>> +{ set_bit(PFA_##name, &p->atomic_flags); }                     \
>> +                                                               \
>> +static inline void task_clear_##func(struct task_struct *p)    \
>> +{ clear_bit(PFA_##name, &p->atomic_flags); }
>> +
>> +TASK_PFA_BITOPS(NO_NEW_PRIVS, no_new_privs)
> 
> One thing I don't like about this is that task_clear_no_new_privs()
> ends up getting defined, and it should absolutely never be used. NNP
> should never be cleared or there could be security issues. I realize
> this isn't a very useful nit-pick, but I'd rather the function wasn't
> even available for someone to accidentally use. Maybe break up the
> macro with some kind of "write only" version like:
> 
> #define TASK_PFA_BITOPS_WO(name, func)                            \
> static inline bool task_##func(struct task_struct *p)          \
> { return test_bit(PFA_##name, &p->atomic_flags); }             \
> static inline void task_set_##func(struct task_struct *p)      \
> { set_bit(PFA_##name, &p->atomic_flags); }
> 
> #define TASK_PFA_BITOPS(name, func)                            \
> TASK_PFA_BITOPS_WO(name, func);          \
> static inline void task_clear_##func(struct task_struct *p)    \
> { clear_bit(PFA_##name, &p->atomic_flags); }
> 
> TASK_PFA_BITOPS_WO(NO_NEW_PRIVS, no_new_privs)
> 
> And then all the new users can use TASK_PFA_BITOPS() normally since
> they expect to use "clear"?
> 

Now I'm inclined to do this:

+#define TASK_PFA_TEST(name, func)					\
+	static inline bool task_##func(struct task_struct *p)		\
+	{ return test_bit(PFA_##name, &p->atomic_flags); }
+#define TASK_PFA_SET(name, func)					\
+	static inline void task_set_##func(struct task_struct *p)	\
+	{ set_bit(PFA_##name, &p->atomic_flags); }
+#define TASK_PFA_CLEAR(name, func)					\
+	static inline void task_clear_##func(struct task_struct *p)	\
+	{ clear_bit(PFA_##name, &p->atomic_flags); }
+
+TASK_PFA_TEST(NO_NEW_PRIVS, no_new_privs)
+TASK_PFA_SET(NO_NEW_PRIVS, no_new_privs)


  parent reply	other threads:[~2014-09-23  6:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-23  6:03 [PATCH v2 1/3] sched: fix confusing PFA_NO_NEW_PRIVS constant Zefan Li
     [not found] ` <54210D3F.2090409-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2014-09-23  6:04   ` [PATCH v2 2/3] sched: add a macro to define bitops for task atomic flags Zefan Li
2014-09-23  6:04     ` Zefan Li
     [not found]     ` <54210D7B.8030103-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2014-09-23  6:37       ` Kees Cook
2014-09-23  6:37         ` Kees Cook
     [not found]         ` <CAGXu5jJKNJ=PsTtkPaoMyCNf2fK07szP-hv4NdaiDVx4tHacQw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-23  6:52           ` Zefan Li [this message]
2014-09-23  6:52             ` Zefan Li
2014-09-23  6:05 ` [PATCH v2 3/3] cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should be " Zefan Li
2014-09-23 10:55   ` [PATCH v2 3/3] cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should beatomic flags Tetsuo Handa
     [not found]     ` <201409231955.FDB73406.FOOJLOVQMHFSFt-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>
2014-09-23 13:13       ` Tejun Heo
2014-09-23 13:13         ` Tejun Heo
2014-09-24  3:01       ` Zefan Li
2014-09-24  3:01         ` Zefan Li
2014-09-24 11:44         ` [PATCH v2 3/3] cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should be atomic flags Tetsuo Handa
     [not found]           ` <201409242044.GFJ81269.FJFVQOLSHtFMOO-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>
2014-09-24 13:06             ` Tejun Heo
2014-09-24 13:06               ` Tejun Heo

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=542118C2.6030302@huawei.com \
    --to=lizefan-hv44wf8li93qt0dzr+alfa@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=miaox-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org \
    --cc=mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=penguin-kernel-1yMVhJb1mP/7nzcFbJAaVXf5DAMn2ifp@public.gmane.org \
    --cc=peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.