Re: [PATCH] mm: don't allow empty relative nodemask in mpol_relative_nodemask()

[David Hildenbrand (Arm)]

>>
>> Thank you for taking a shot at fixing the bug report, please let me know what
>> you think! Have a great day : -)
> 
> Hi Joshua.
> 
> Indeed, quick and dirty shot.
> 
> The problem is that nodes_fold() can't work with the sz == 0. In
> other words, folding to a 0-bit bitmap is an error. We don't check
> that on bitmaps level because it's an internal helper, and it's a
> caller's responsibility to validate the parameters.
> 
> nodes_onto(), or more specifically bitmap_onto(), is a different
> story. In case of empty relmap, the function actually clears all the
> bits in dst and returns.

It's very weird that mpol_new_nodemask() (->create() callback) disallows empty
nodemasks, but mpol_rebind_nodemask() (->rebind() callback) would allow empty
nodemasks.

I guess mpol_set_nodemask() could trigger it after doing the

	nodes_and(nsc->mask1, cpuset_current_mems_allowed,
		  node_states[N_MEMORY]);

And ending with an empty &nsc->mask1.

The later "mpol_ops[pol->mode].create(pol, &nsc->mask2);" would reject it, but
the division by zero could still happen.

> 
> I see 2 options to move this forward.
> 
> 1. Simply disallow empty relmap in mpol_relative_nodemask(). There's
> no valid cases for it, AFAIK, so the nodes_fold() limitation looks
> reasonable. We can consider it as a new policy.
> 
> We've got 2 users for mpol_relative_nodemask(). In mpol_set_nodemask()
> we can simply propagate the error; and in mpol_rebind_nodemask() we
> can throw a warning and do nothing.

Throwing a warning is really bad. We'd still end up with an empty nodemask?

-- 
Cheers,

David