Re: [PATCH] hugetlb: fix CONFIG_CGROUP_HUGETLB ifdefs

From: Randy Dunlap
Date: Sun Feb 16 2020 - 21:48:28 EST


On 2/16/20 1:03 PM, Mina Almasry wrote:
> On Sun, Feb 16, 2020 at 12:40 PM Mina Almasry <almasrymina@xxxxxxxxxx> wrote:
>>
>> On Fri, Feb 14, 2020 at 5:57 PM Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote:
>>>
>>> On 2/14/20 5:17 PM, Randy Dunlap wrote:
>>>> On 2/14/20 1:00 PM, Mina Almasry wrote:
>>>>> On Fri, Feb 14, 2020 at 12:46 PM Mina Almasry <almasrymina@xxxxxxxxxx> wrote:
>>>>>>
>>>>>> Fixes an #ifdef bug in the patch referred to below that was
>>>>>> causing a build error when CONFIG_DEBUG_VM &&
>>>>>> !CONFIG_CCGROUP_HUGETLB.
>>>>
>>>> Hi Mina,
>>>>
>>>> I don't know if this was supposed to fix the 2 build reports that I made,
>>>> but this does not apply cleanly to mmotm (and it's a reply email so it's
>>>> more difficult to apply anyway):
>>>>
>>>> Applying patch mm-hugetlb-fix-CONFIG_CGROUP_HUGETLB.patch
>>>> patching file mm/hugetlb.c
>>>> Hunk #1 succeeded at 289 with fuzz 1.
>>>> Hunk #2 succeeded at 325 with fuzz 2.
>>>> Hunk #3 FAILED at 435.
>>>> 1 out of 3 hunks FAILED -- rejects in file mm/hugetlb.c
>>>>
>>>
>>> OK, I applied this patch manually and it does fix most of the reported build problems.
>>> The only one remaining is this:
>>>
>>> CC mm/migrate.o
>>> In file included from ../mm/migrate.c:39:0:
>>> ../include/linux/hugetlb_cgroup.h:146:21: warning: âstruct file_regionâ declared inside parameter list will not be visible outside of this definition or declaration
>>> struct file_region *rg,
>>> ^~~~~~~~~~~
>>> ../include/linux/hugetlb_cgroup.h:145:63: warning: âstruct resv_mapâ declared inside parameter list will not be visible outside of this definition or declaration
>>> static inline void hugetlb_cgroup_uncharge_file_region(struct resv_map *resv,
>>> ^~~~~~~~
>>> ../include/linux/hugetlb_cgroup.h:233:59: warning: âstruct resv_mapâ declared inside parameter list will not be visible outside of this definition or declaration
>>> static inline void hugetlb_cgroup_uncharge_counter(struct resv_map *resv,
>>> ^~~~~~~~
>>>
>>
>> Hi Randy,
>>
>> Yes this was supposed to fix the build errors. I'm having trouble
>> reproducing the one you have pending above. This is my development
>> environment:
>>
>> â prodkernel2 git:(mm-build-fix) git remote show github-akpm
>> * remote github-akpm
>> Fetch URL: https://github.com/hnaz/linux-mm.git
>> Push URL: https://github.com/hnaz/linux-mm.git
>>
>> â prodkernel2 git:(mm-build-fix) git s
>> ## mm-build-fix...github-akpm/master [ahead 1]
>>
>> â prodkernel2 git:(mm-build-fix) make -j80 mm/migrate.o
>> (succeeds with no warnings).
>>
>> â prodkernel2 git:(mm-build-fix) make -j80
>> (succeeds with no warnings)
>>
>> Is my development environment wrong? Shouldn't I be able to reproduce
>> this build warning on this tree with my fix?
>> https://github.com/hnaz/linux-mm.git
>>
>> I'm using config-r9887 that you sent earlier.
>>
>> I'm probably supposed to use a different branch since you also say
>> that my patch doesn't apply cleanily, but the mmotm readme says that
>> github mirrors Andrew's tree?
>>
>
> Just looking at the build error without being able to reproduce, it
> looks like this diff would fix it?

Hi Mina,
This patch does not fix the build warnings that I reported.

The initial report is here:
https://lore.kernel.org/lkml/97879032-f159-f1c6-9cde-d4e0389b2d7f@xxxxxxxxxxxxx/
and the kernel .config file is named config-r9883 (not r9887).


> â prodkernel2 git:(mm-build-fix) â git diff
> diff --git a/include/linux/hugetlb_cgroup.h b/include/linux/hugetlb_cgroup.h
> index a09d4164ba910..5f66cdcbe9b10 100644
> --- a/include/linux/hugetlb_cgroup.h
> +++ b/include/linux/hugetlb_cgroup.h
> @@ -15,6 +15,7 @@
> #ifndef _LINUX_HUGETLB_CGROUP_H
> #define _LINUX_HUGETLB_CGROUP_H
>
> +#include <linux/hugetlb.h>
> #include <linux/mmdebug.h>
>
> struct hugetlb_cgroup;
>
> Can you let me know? Or any insight into why I can't reproduce the
> warning? Wrong tree perhaps?
>
> I suspect a forward declaration of struct resv_map and struct
> file_region in hugetlb_cgroup.h would also fix.



--
~Randy