All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zefan Li <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Tetsuo Handa
	<penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>
Cc: tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
	mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	miaox-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org
Subject: Re: [PATCH v2 3/3] cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should beatomic flags
Date: Wed, 24 Sep 2014 11:01:04 +0800	[thread overview]
Message-ID: <542233F0.1080402@huawei.com> (raw)
In-Reply-To: <201409231955.FDB73406.FOOJLOVQMHFSFt-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>

On 2014/9/23 18:55, Tetsuo Handa wrote:
> Zefan Li wrote:
>> Tetsuo reported a hard-to-reproduce kernel crash on RHEL6, which happend
> 
> s/happend/happened/
> 
>> @@ -1972,6 +1973,14 @@ static inline void memalloc_noio_restore(unsigned int flags)
>>  TASK_PFA_TEST(NO_NEW_PRIVS, no_new_privs)
>>  TASK_PFA_SET(NO_NEW_PRIVS, no_new_privs)
>>  
>> +TASK_PFA_TEST(SPREAD_PAGE, spread_page)
>> +TASK_PFA_SET(SPREAD_PAGE, spread_page)
>> +TASK_PFA_CLEAR(SPREAD_PAGE, spread_page)
>> +
>> +TASK_PFA_TEST(SPREAD_SLAB, spread_slab)
>> +TASK_PFA_SET(SPREAD_SLAB, spread_slab)
>> +TASK_PFA_CLEAR(SPREAD_SLAB, spread_slab)
>> +
> 
> I wonder how adding 3 macro lines differs from 3 inlined functions.
> Personally, from LXR (source code browser) point of view, inlined functions
> are more friendly than macros. Also, I wonder about the cost of extracting
> macros in a file which is likely included by every file but referenced
> by few files. Speak of SPREAD_PAGE and SPREAD_SLAB, they should be defined
> as inlined functions in include/linux/cpuset.h rather than as macros in
> include/linux/sched.h ?
> .

Though tsk->atomic_flags were newly introduced in 3.17 merge window, we
already have 3 flags, and we may see more flags added.

Those macros make the code easier to read, and emacs and cscope can also
understand them.

I'd vote for this:

TASK_PFA_TEST(NO_NEW_PRIVS, no_new_privs)
TASK_PFA_SET(NO_NEW_PRIVS, no_new_privs)

TASK_PFA_TEST(SPREAD_PAGE, spread_page)
TASK_PFA_SET(SPREAD_PAGE, spread_page)
TASK_PFA_CLEAR(SPREAD_PAGE, spread_page)

TASK_PFA_TEST(SPREAD_SLAB, spread_slab)
TASK_PFA_SET(SPREAD_SLAB, spread_slab)
TASK_PFA_CLEAR(SPREAD_SLAB, spread_slab)

over this:

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_new_privs(struct task_struct *p)
{
	set_bit(PFA_NO_NEW_PRIVS, &p->atomic_flags);
}

static inline bool task_spread_page(struct task_struct *p)
{
	return test_bit(PFA_SPREAD_PAGE, &p->atomic_flags);
}
static inline void task_set_spread_page(struct task_struct *p)
{
	set_bit(PFA_SPREAD_PAGE, &p->atomic_flags);
}
static inline void task_clear_spread_page(struct task_struct *p)
{
	clear_bit(PFA_SPREAD_PAGE, &p->atomic_flags);
}

static inline bool task_spread_slab(struct task_struct *p)
{
	return test_bit(PFA_SPREAD_SLAB, &p->atomic_flags);
}
static inline void task_set_spread_slab(struct task_struct *p)
{
	set_bit(PFA_SPREAD_SLAB, &p->atomic_flags);
}
static inline void task_clear_spread_slab(struct task_struct *p)
{
	clear_bit(PFA_SPREAD_SLAB, &p->atomic_flags);
}


WARNING: multiple messages have this Message-ID (diff)
From: Zefan Li <lizefan@huawei.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: <tj@kernel.org>, <peterz@infradead.org>, <mingo@kernel.org>,
	<miaox@cn.fujitsu.com>, <linux-kernel@vger.kernel.org>,
	<cgroups@vger.kernel.org>, <keescook@chromium.org>
Subject: Re: [PATCH v2 3/3] cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should beatomic flags
Date: Wed, 24 Sep 2014 11:01:04 +0800	[thread overview]
Message-ID: <542233F0.1080402@huawei.com> (raw)
In-Reply-To: <201409231955.FDB73406.FOOJLOVQMHFSFt@I-love.SAKURA.ne.jp>

On 2014/9/23 18:55, Tetsuo Handa wrote:
> Zefan Li wrote:
>> Tetsuo reported a hard-to-reproduce kernel crash on RHEL6, which happend
> 
> s/happend/happened/
> 
>> @@ -1972,6 +1973,14 @@ static inline void memalloc_noio_restore(unsigned int flags)
>>  TASK_PFA_TEST(NO_NEW_PRIVS, no_new_privs)
>>  TASK_PFA_SET(NO_NEW_PRIVS, no_new_privs)
>>  
>> +TASK_PFA_TEST(SPREAD_PAGE, spread_page)
>> +TASK_PFA_SET(SPREAD_PAGE, spread_page)
>> +TASK_PFA_CLEAR(SPREAD_PAGE, spread_page)
>> +
>> +TASK_PFA_TEST(SPREAD_SLAB, spread_slab)
>> +TASK_PFA_SET(SPREAD_SLAB, spread_slab)
>> +TASK_PFA_CLEAR(SPREAD_SLAB, spread_slab)
>> +
> 
> I wonder how adding 3 macro lines differs from 3 inlined functions.
> Personally, from LXR (source code browser) point of view, inlined functions
> are more friendly than macros. Also, I wonder about the cost of extracting
> macros in a file which is likely included by every file but referenced
> by few files. Speak of SPREAD_PAGE and SPREAD_SLAB, they should be defined
> as inlined functions in include/linux/cpuset.h rather than as macros in
> include/linux/sched.h ?
> .

Though tsk->atomic_flags were newly introduced in 3.17 merge window, we
already have 3 flags, and we may see more flags added.

Those macros make the code easier to read, and emacs and cscope can also
understand them.

I'd vote for this:

TASK_PFA_TEST(NO_NEW_PRIVS, no_new_privs)
TASK_PFA_SET(NO_NEW_PRIVS, no_new_privs)

TASK_PFA_TEST(SPREAD_PAGE, spread_page)
TASK_PFA_SET(SPREAD_PAGE, spread_page)
TASK_PFA_CLEAR(SPREAD_PAGE, spread_page)

TASK_PFA_TEST(SPREAD_SLAB, spread_slab)
TASK_PFA_SET(SPREAD_SLAB, spread_slab)
TASK_PFA_CLEAR(SPREAD_SLAB, spread_slab)

over this:

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_new_privs(struct task_struct *p)
{
	set_bit(PFA_NO_NEW_PRIVS, &p->atomic_flags);
}

static inline bool task_spread_page(struct task_struct *p)
{
	return test_bit(PFA_SPREAD_PAGE, &p->atomic_flags);
}
static inline void task_set_spread_page(struct task_struct *p)
{
	set_bit(PFA_SPREAD_PAGE, &p->atomic_flags);
}
static inline void task_clear_spread_page(struct task_struct *p)
{
	clear_bit(PFA_SPREAD_PAGE, &p->atomic_flags);
}

static inline bool task_spread_slab(struct task_struct *p)
{
	return test_bit(PFA_SPREAD_SLAB, &p->atomic_flags);
}
static inline void task_set_spread_slab(struct task_struct *p)
{
	set_bit(PFA_SPREAD_SLAB, &p->atomic_flags);
}
static inline void task_clear_spread_slab(struct task_struct *p)
{
	clear_bit(PFA_SPREAD_SLAB, &p->atomic_flags);
}



  parent reply	other threads:[~2014-09-24  3:01 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
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 [this message]
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=542233F0.1080402@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-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@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.