From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: Tom Rini <trini@ti.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
Jianpeng Ma <majianpeng@gmail.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
Wen Congyang <wency@cn.fujitsu.com>,
Jiang Liu <jiang.liu@huawei.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Minchan Kim <minchan.kim@gmail.com>, Mel Gorman <mgorman@suse.de>,
David Rientjes <rientjes@google.com>,
Yinghai Lu <yinghai@kernel.org>, Greg KH <greg@kroah.com>,
kosaki.motohiro@gmail.com
Subject: Re: [PATCH v2] numa: Mark __node_set as __always_inline
Date: Thu, 25 Jul 2013 15:16:07 -0400 [thread overview]
Message-ID: <51F17977.9050606@gmail.com> (raw)
In-Reply-To: <1374776770-32361-1-git-send-email-trini@ti.com>
> +/*
> + * The inline keyword gives the compiler room to decide to inline, or
> + * not inline a function as it sees best. However, as these functions
> + * are called in both __init and non-__init functions, if they are not
> + * inlined we will end up with a section mis-match error (of the type of
> + * freeable items not being freed). So we must use __always_inline here
> + * to fix the problem. If other functions in the future also end up in
> + * this situation they will also need to be annotated as __always_inline
> + */
> #define node_set(node, dst) __node_set((node), &(dst))
> -static inline void __node_set(int node, volatile nodemask_t *dstp)
> +static __always_inline void __node_set(int node, volatile nodemask_t *dstp)
> {
> set_bit(node, dstp->bits);
> }
>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
next prev parent reply other threads:[~2013-07-25 19:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-25 18:26 [PATCH v2] numa: Mark __node_set as __always_inline Tom Rini
2013-07-25 19:16 ` KOSAKI Motohiro [this message]
2013-07-26 20:04 ` [tip:sched/core] numa: Mark __node_set() " tip-bot for Tom Rini
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=51F17977.9050606@gmail.com \
--to=kosaki.motohiro@gmail.com \
--cc=greg@kroah.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=jiang.liu@huawei.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=majianpeng@gmail.com \
--cc=mgorman@suse.de \
--cc=minchan.kim@gmail.com \
--cc=rientjes@google.com \
--cc=rusty@rustcorp.com.au \
--cc=trini@ti.com \
--cc=wency@cn.fujitsu.com \
--cc=x86@kernel.org \
--cc=yinghai@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox