All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@linux.alibaba.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
	Wei Yang <richard.weiyang@linux.alibaba.com>,
	akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/hugetlb: hide nr_nodes in the internal of for_each_node_mask_to_[alloc|free]
Date: Wed, 15 Jul 2020 11:46:00 +0800	[thread overview]
Message-ID: <20200715034600.GA88314@L-31X9LVDL-1304.local> (raw)
In-Reply-To: <694bb1ac-4f9c-a6a5-7c87-1fc0cdd948a6@oracle.com>

On Tue, Jul 14, 2020 at 02:12:03PM -0700, Mike Kravetz wrote:
>On 7/14/20 3:02 AM, Vlastimil Babka wrote:
>> On 7/14/20 11:57 AM, Wei Yang wrote:
>>> On Tue, Jul 14, 2020 at 11:22:03AM +0200, Vlastimil Babka wrote:
>>>> On 7/14/20 11:13 AM, Vlastimil Babka wrote:
>>>>> On 7/14/20 9:34 AM, Wei Yang wrote:
>>>>>> The second parameter of for_each_node_mask_to_[alloc|free] is a loop
>>>>>> variant, which is not used outside of loop iteration.
>>>>>>
>>>>>> Let's hide this.
>>>>>>
>>>>>> Signed-off-by: Wei Yang <richard.weiyang@linux.alibaba.com>
>>>>>> ---
>>>>>>  mm/hugetlb.c | 38 ++++++++++++++++++++------------------
>>>>>>  1 file changed, 20 insertions(+), 18 deletions(-)
>>>>>>
>>>>>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>>>>>> index 57ece74e3aae..9c3d15fb317e 100644
>>>>>> --- a/mm/hugetlb.c
>>>>>> +++ b/mm/hugetlb.c
>>>>>> @@ -1196,17 +1196,19 @@ static int hstate_next_node_to_free(struct hstate *h, nodemask_t *nodes_allowed)
>>>>>>  	return nid;
>>>>>>  }
>>>>>>  
>>>>>> -#define for_each_node_mask_to_alloc(hs, nr_nodes, node, mask)		\
>>>>>> -	for (nr_nodes = nodes_weight(*mask);				\
>>>>>> -		nr_nodes > 0 &&						\
>>>>>> +#define for_each_node_mask_to_alloc(hs, node, mask)			\
>>>>>> +	int __nr_nodes;							\
>>>>>> +	for (__nr_nodes = nodes_weight(*mask);				\
>>>>>
>>>>> The problem with this is that if I use the macro twice in the same block, this
>>>>> will redefine __nr_nodes and fail to compile, no?
>>>>> In that case it's better to avoid setting up this trap, IMHO.
>>>>
>>>> Ah, and it will also generate the following warning, if the use of for_each*
>>>> macro is not the first thing after variable declarations, but there's another
>>>> statement before:
>>>>
>>>> warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
>>>>
>>>> Instead we should switch to C99 and declare it as "for (int __nr_nodes" :P
>>>
>>> Hmm... I tried what you suggested, but compiler complains.
>>>
>>> 'for' loop initial declarations are only allowed in C99 or C11 mode
>> 
>> Yes, by "we should switch to C99" I meant that the kernel kbuild system would
>> need to switch. Not a trivial change...
>> Without that, I don't see how your patch is possible to do safely.
>
>Vlastimil, thanks for pointing out future potential issues with this patch.
>I likely would have missed that.
>
>Wei, thanks for taking the time to put together the patch.  However, I tend
>to agree with Vlastimil's assesment.  The cleanup is not worth the risk of
>running into issues if someone uses multiple instances of the macro.

Yep, thanks all for your feedback.

>-- 
>Mike Kravetz

-- 
Wei Yang
Help you, Help me

      reply	other threads:[~2020-07-15  3:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-14  7:34 [PATCH] mm/hugetlb: hide nr_nodes in the internal of for_each_node_mask_to_[alloc|free] Wei Yang
2020-07-14  8:37 ` Pankaj Gupta
2020-07-14  8:37   ` Pankaj Gupta
2020-07-14  9:13 ` Vlastimil Babka
2020-07-14  9:22   ` Vlastimil Babka
2020-07-14  9:50     ` Wei Yang
2020-07-14  9:57     ` Wei Yang
2020-07-14 10:02       ` Vlastimil Babka
2020-07-14 21:12         ` Mike Kravetz
2020-07-15  3:46           ` Wei Yang [this message]

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=20200715034600.GA88314@L-31X9LVDL-1304.local \
    --to=richard.weiyang@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=vbabka@suse.cz \
    /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.