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 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.