linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] nodemask: Consider MAX_NUMNODES inside node_isset
@ 2017-01-03  8:27 Anshuman Khandual
  2017-01-03  8:44 ` Michal Hocko
  0 siblings, 1 reply; 5+ messages in thread
From: Anshuman Khandual @ 2017-01-03  8:27 UTC (permalink / raw)
  To: linux-kernel, linux-mm; +Cc: mhocko, vbabka, akpm

node_isset can give incorrect result if the node number is beyond the
bitmask size (MAX_NUMNODES in this case) which is not checked inside
test_bit. Hence check for the bit limits (MAX_NUMNODES) inside the
node_isset function before calling test_bit.

Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
 include/linux/nodemask.h | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/linux/nodemask.h b/include/linux/nodemask.h
index 6e66cfd..0aee588b 100644
--- a/include/linux/nodemask.h
+++ b/include/linux/nodemask.h
@@ -139,7 +139,13 @@ static inline void __nodes_clear(nodemask_t *dstp, unsigned int nbits)
 }
 
 /* No static inline type checking - see Subtlety (1) above. */
-#define node_isset(node, nodemask) test_bit((node), (nodemask).bits)
+#define node_isset(node, nodemask) node_test_bit(node, nodemask, MAX_NUMNODES)
+static inline int node_test_bit(int node, nodemask_t nodemask, int maxnodes)
+{
+	if (node >= maxnodes)
+		return 0;
+	return test_bit((node), (nodemask).bits);
+}
 
 #define node_test_and_set(node, nodemask) \
 			__node_test_and_set((node), &(nodemask))
-- 
1.8.3.1

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [RFC] nodemask: Consider MAX_NUMNODES inside node_isset
  2017-01-03  8:27 [RFC] nodemask: Consider MAX_NUMNODES inside node_isset Anshuman Khandual
@ 2017-01-03  8:44 ` Michal Hocko
  2017-01-03  9:07   ` Anshuman Khandual
  0 siblings, 1 reply; 5+ messages in thread
From: Michal Hocko @ 2017-01-03  8:44 UTC (permalink / raw)
  To: Anshuman Khandual; +Cc: linux-kernel, linux-mm, vbabka, akpm

On Tue 03-01-17 13:57:53, Anshuman Khandual wrote:
> node_isset can give incorrect result if the node number is beyond the
> bitmask size (MAX_NUMNODES in this case) which is not checked inside
> test_bit. Hence check for the bit limits (MAX_NUMNODES) inside the
> node_isset function before calling test_bit.

Could you be more specific when such a thing might happen? Have you seen
any in-kernel user who would give such a bogus node?

> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> ---
>  include/linux/nodemask.h | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/nodemask.h b/include/linux/nodemask.h
> index 6e66cfd..0aee588b 100644
> --- a/include/linux/nodemask.h
> +++ b/include/linux/nodemask.h
> @@ -139,7 +139,13 @@ static inline void __nodes_clear(nodemask_t *dstp, unsigned int nbits)
>  }
>  
>  /* No static inline type checking - see Subtlety (1) above. */
> -#define node_isset(node, nodemask) test_bit((node), (nodemask).bits)
> +#define node_isset(node, nodemask) node_test_bit(node, nodemask, MAX_NUMNODES)
> +static inline int node_test_bit(int node, nodemask_t nodemask, int maxnodes)
> +{
> +	if (node >= maxnodes)
> +		return 0;
> +	return test_bit((node), (nodemask).bits);
> +}
>  
>  #define node_test_and_set(node, nodemask) \
>  			__node_test_and_set((node), &(nodemask))
> -- 
> 1.8.3.1
> 

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC] nodemask: Consider MAX_NUMNODES inside node_isset
  2017-01-03  8:44 ` Michal Hocko
@ 2017-01-03  9:07   ` Anshuman Khandual
  2017-01-03  9:17     ` Michal Hocko
  0 siblings, 1 reply; 5+ messages in thread
From: Anshuman Khandual @ 2017-01-03  9:07 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual; +Cc: linux-kernel, linux-mm, vbabka, akpm

On 01/03/2017 02:14 PM, Michal Hocko wrote:
> On Tue 03-01-17 13:57:53, Anshuman Khandual wrote:
>> node_isset can give incorrect result if the node number is beyond the
>> bitmask size (MAX_NUMNODES in this case) which is not checked inside
>> test_bit. Hence check for the bit limits (MAX_NUMNODES) inside the
>> node_isset function before calling test_bit.
> Could you be more specific when such a thing might happen? Have you seen
> any in-kernel user who would give such a bogus node?

Have not seen this through any in-kernel use case. While rebasing the CDM
zonelist rebuilding series, I came across this through an error path when
a bogus node value of 256 (MAX_NUMNODES on POWER) is received when we call
first_node() on an empty nodemask (which itself seems weird as well).

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC] nodemask: Consider MAX_NUMNODES inside node_isset
  2017-01-03  9:07   ` Anshuman Khandual
@ 2017-01-03  9:17     ` Michal Hocko
  2017-01-03  9:47       ` Anshuman Khandual
  0 siblings, 1 reply; 5+ messages in thread
From: Michal Hocko @ 2017-01-03  9:17 UTC (permalink / raw)
  To: Anshuman Khandual; +Cc: linux-kernel, linux-mm, vbabka, akpm

On Tue 03-01-17 14:37:09, Anshuman Khandual wrote:
> On 01/03/2017 02:14 PM, Michal Hocko wrote:
> > On Tue 03-01-17 13:57:53, Anshuman Khandual wrote:
> >> node_isset can give incorrect result if the node number is beyond the
> >> bitmask size (MAX_NUMNODES in this case) which is not checked inside
> >> test_bit. Hence check for the bit limits (MAX_NUMNODES) inside the
> >> node_isset function before calling test_bit.
> > Could you be more specific when such a thing might happen? Have you seen
> > any in-kernel user who would give such a bogus node?
> 
> Have not seen this through any in-kernel use case. While rebasing the CDM
> zonelist rebuilding series,

Then fix this particular code path...

> I came across this through an error path when
> a bogus node value of 256 (MAX_NUMNODES on POWER) is received when we call
> first_node() on an empty nodemask (which itself seems weird as well).

Does calling first_node on an empty nodemask make any sense? If there is
a risk then I would expect nodes_empty() check before doing any mask
related operations.

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC] nodemask: Consider MAX_NUMNODES inside node_isset
  2017-01-03  9:17     ` Michal Hocko
@ 2017-01-03  9:47       ` Anshuman Khandual
  0 siblings, 0 replies; 5+ messages in thread
From: Anshuman Khandual @ 2017-01-03  9:47 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual; +Cc: linux-kernel, linux-mm, vbabka, akpm

On 01/03/2017 02:47 PM, Michal Hocko wrote:
> On Tue 03-01-17 14:37:09, Anshuman Khandual wrote:
>> On 01/03/2017 02:14 PM, Michal Hocko wrote:
>>> On Tue 03-01-17 13:57:53, Anshuman Khandual wrote:
>>>> node_isset can give incorrect result if the node number is beyond the
>>>> bitmask size (MAX_NUMNODES in this case) which is not checked inside
>>>> test_bit. Hence check for the bit limits (MAX_NUMNODES) inside the
>>>> node_isset function before calling test_bit.
>>> Could you be more specific when such a thing might happen? Have you seen
>>> any in-kernel user who would give such a bogus node?
>>
>> Have not seen this through any in-kernel use case. While rebasing the CDM
>> zonelist rebuilding series,
> 
> Then fix this particular code path...

Yeah I did.

> 
>> I came across this through an error path when
>> a bogus node value of 256 (MAX_NUMNODES on POWER) is received when we call
>> first_node() on an empty nodemask (which itself seems weird as well).
> 
> Does calling first_node on an empty nodemask make any sense? If there is
> a risk then I would expect nodes_empty() check before doing any mask
> related operations.

Hmm, you are right. All these checks should be done by the caller not
these nodemask helper functions.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2017-01-03  9:48 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-03  8:27 [RFC] nodemask: Consider MAX_NUMNODES inside node_isset Anshuman Khandual
2017-01-03  8:44 ` Michal Hocko
2017-01-03  9:07   ` Anshuman Khandual
2017-01-03  9:17     ` Michal Hocko
2017-01-03  9:47       ` Anshuman Khandual

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).