| Message ID | 20181205091905.27727-1-richard.weiyang@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin | expand |
On Wed, Dec 05, 2018 at 05:19:04PM +0800, Wei Yang wrote: > When SPARSEMEM is used, there is an indication that pageblock is not > allowed to exceed one mem_section. Current code doesn't have this > constrain explicitly. > > This patch adds this to make sure it won't. > > Signed-off-by: Wei Yang <richard.weiyang@gmail.com> Is this even possible? This would imply that the section size is smaller than max order which would be quite a crazy selection for a sparesemem section size. A lot of assumptions on the validity of PFNs within a max-order boundary would be broken with such a section size. I'd be surprised if such a setup could even boot, let alone run.
On Wed, Dec 05, 2018 at 11:15:13AM +0000, Mel Gorman wrote: >On Wed, Dec 05, 2018 at 05:19:04PM +0800, Wei Yang wrote: >> When SPARSEMEM is used, there is an indication that pageblock is not >> allowed to exceed one mem_section. Current code doesn't have this >> constrain explicitly. >> >> This patch adds this to make sure it won't. >> >> Signed-off-by: Wei Yang <richard.weiyang@gmail.com> > >Is this even possible? This would imply that the section size is smaller >than max order which would be quite a crazy selection for a sparesemem >section size. A lot of assumptions on the validity of PFNs within a >max-order boundary would be broken with such a section size. I'd be >surprised if such a setup could even boot, let alone run. pageblock_order has two definitions. #define pageblock_order HUGETLB_PAGE_ORDER #define pageblock_order (MAX_ORDER-1) If CONFIG_HUGETLB_PAGE is not enabled, pageblock_order is related to MAX_ORDER, which ensures it is smaller than section size. If CONFIG_HUGETLB_PAGE is enabled, pageblock_order is not related to MAX_ORDER. I don't see HUGETLB_PAGE_ORDER is ensured to be less than section size. Maybe I missed it? > >-- >Mel Gorman >SUSE Labs
On Wed, Dec 05, 2018 at 12:08:20PM +0000, Wei Yang wrote: > On Wed, Dec 05, 2018 at 11:15:13AM +0000, Mel Gorman wrote: > >On Wed, Dec 05, 2018 at 05:19:04PM +0800, Wei Yang wrote: > >> When SPARSEMEM is used, there is an indication that pageblock is not > >> allowed to exceed one mem_section. Current code doesn't have this > >> constrain explicitly. > >> > >> This patch adds this to make sure it won't. > >> > >> Signed-off-by: Wei Yang <richard.weiyang@gmail.com> > > > >Is this even possible? This would imply that the section size is smaller > >than max order which would be quite a crazy selection for a sparesemem > >section size. A lot of assumptions on the validity of PFNs within a > >max-order boundary would be broken with such a section size. I'd be > >surprised if such a setup could even boot, let alone run. > > pageblock_order has two definitions. > > #define pageblock_order HUGETLB_PAGE_ORDER > > #define pageblock_order (MAX_ORDER-1) > > If CONFIG_HUGETLB_PAGE is not enabled, pageblock_order is related to > MAX_ORDER, which ensures it is smaller than section size. > > If CONFIG_HUGETLB_PAGE is enabled, pageblock_order is not related to > MAX_ORDER. I don't see HUGETLB_PAGE_ORDER is ensured to be less than > section size. Maybe I missed it? > HUGETLB_PAGE_ORDER is less than MAX_ORDER on the basis that normal huge pages (not gigantic) pages are served from the buddy allocator which is limited by MAX_ORDER.
On Wed, Dec 05, 2018 at 03:37:33PM +0000, Mel Gorman wrote: >On Wed, Dec 05, 2018 at 12:08:20PM +0000, Wei Yang wrote: >> On Wed, Dec 05, 2018 at 11:15:13AM +0000, Mel Gorman wrote: >> >On Wed, Dec 05, 2018 at 05:19:04PM +0800, Wei Yang wrote: >> >> When SPARSEMEM is used, there is an indication that pageblock is not >> >> allowed to exceed one mem_section. Current code doesn't have this >> >> constrain explicitly. >> >> >> >> This patch adds this to make sure it won't. >> >> >> >> Signed-off-by: Wei Yang <richard.weiyang@gmail.com> >> > >> >Is this even possible? This would imply that the section size is smaller >> >than max order which would be quite a crazy selection for a sparesemem >> >section size. A lot of assumptions on the validity of PFNs within a >> >max-order boundary would be broken with such a section size. I'd be >> >surprised if such a setup could even boot, let alone run. >> >> pageblock_order has two definitions. >> >> #define pageblock_order HUGETLB_PAGE_ORDER >> >> #define pageblock_order (MAX_ORDER-1) >> >> If CONFIG_HUGETLB_PAGE is not enabled, pageblock_order is related to >> MAX_ORDER, which ensures it is smaller than section size. >> >> If CONFIG_HUGETLB_PAGE is enabled, pageblock_order is not related to >> MAX_ORDER. I don't see HUGETLB_PAGE_ORDER is ensured to be less than >> section size. Maybe I missed it? >> > >HUGETLB_PAGE_ORDER is less than MAX_ORDER on the basis that normal huge >pages (not gigantic) pages are served from the buddy allocator which is >limited by MAX_ORDER. > Maybe I am lost here, I got one possible definition on x86. #define pageblock_order HUGETLB_PAGE_ORDER #define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT) #define HPAGE_SHIFT PMD_SHIFT #define PMD_SHIFT PUD_SHIFT #define PUD_SHIFT 30 This leads to pageblock_order = (30 - 12) = 18 > MAX_ORDER ? What you mentioned sounds reasonable. A huge page should be less than MAX_ORDER, otherwise page allocator couldn't handle it. But I don't see the connection between MAX_ORDER and HUGETLB_PAGE_ORDER. Do we need to add a check on this? Or it already has similar contrain in code, but I missed it? >-- >Mel Gorman >SUSE Labs
On 05.12.18 23:31, Wei Yang wrote: > On Wed, Dec 05, 2018 at 03:37:33PM +0000, Mel Gorman wrote: >> On Wed, Dec 05, 2018 at 12:08:20PM +0000, Wei Yang wrote: >>> On Wed, Dec 05, 2018 at 11:15:13AM +0000, Mel Gorman wrote: >>>> On Wed, Dec 05, 2018 at 05:19:04PM +0800, Wei Yang wrote: >>>>> When SPARSEMEM is used, there is an indication that pageblock is not >>>>> allowed to exceed one mem_section. Current code doesn't have this >>>>> constrain explicitly. >>>>> >>>>> This patch adds this to make sure it won't. >>>>> >>>>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com> >>>> >>>> Is this even possible? This would imply that the section size is smaller >>>> than max order which would be quite a crazy selection for a sparesemem >>>> section size. A lot of assumptions on the validity of PFNs within a >>>> max-order boundary would be broken with such a section size. I'd be >>>> surprised if such a setup could even boot, let alone run. >>> >>> pageblock_order has two definitions. >>> >>> #define pageblock_order HUGETLB_PAGE_ORDER >>> >>> #define pageblock_order (MAX_ORDER-1) >>> >>> If CONFIG_HUGETLB_PAGE is not enabled, pageblock_order is related to >>> MAX_ORDER, which ensures it is smaller than section size. >>> >>> If CONFIG_HUGETLB_PAGE is enabled, pageblock_order is not related to >>> MAX_ORDER. I don't see HUGETLB_PAGE_ORDER is ensured to be less than >>> section size. Maybe I missed it? >>> >> >> HUGETLB_PAGE_ORDER is less than MAX_ORDER on the basis that normal huge >> pages (not gigantic) pages are served from the buddy allocator which is >> limited by MAX_ORDER. >> > > Maybe I am lost here, I got one possible definition on x86. > > #define pageblock_order HUGETLB_PAGE_ORDER > #define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT) > #define HPAGE_SHIFT PMD_SHIFT > #define PMD_SHIFT PUD_SHIFT PMD_SHIFT is usually 21 arch/x86/include/asm/pgtable-3level_types.h:#define PMD_SHIFT 21 arch/x86/include/asm/pgtable_64_types.h:#define PMD_SHIFT 21 Unless CONFIG_PGTABLE_LEVELS <= 2 Then include/asm-generic/pgtable-nopmd.h will be used in arch/x86/include/asm/pgtable_types.h #define PMD_SHIFT PUD_SHIFT In that case, also include/asm-generic/pgtable-nopmd.h is uses #define PUD_SHIFT P4D_SHIFT ... include/asm-generic/pgtable-nop4d.h #define P4D_SHIFT PGDIR_SHIFT And that would be arch/x86/include/asm/pgtable-2level_types.h:#define PGDIR_SHIFT 22 If I am not wrong. So we would have pageblock_order = (22 - 12) = 10 > #define PUD_SHIFT 30 > > This leads to pageblock_order = (30 - 12) = 18 > MAX_ORDER ? > > What you mentioned sounds reasonable. A huge page should be less than > MAX_ORDER, otherwise page allocator couldn't handle it. But I don't see > the connection between MAX_ORDER and HUGETLB_PAGE_ORDER. Do we need to > add a check on this? Or it already has similar contrain in code, but I > missed it? > >> -- >> Mel Gorman >> SUSE Labs >
On Thu, Dec 06, 2018 at 10:00:05AM +0100, David Hildenbrand wrote: >On 05.12.18 23:31, Wei Yang wrote: >> On Wed, Dec 05, 2018 at 03:37:33PM +0000, Mel Gorman wrote: >>> On Wed, Dec 05, 2018 at 12:08:20PM +0000, Wei Yang wrote: >>>> On Wed, Dec 05, 2018 at 11:15:13AM +0000, Mel Gorman wrote: >>>>> On Wed, Dec 05, 2018 at 05:19:04PM +0800, Wei Yang wrote: >>>>>> When SPARSEMEM is used, there is an indication that pageblock is not >>>>>> allowed to exceed one mem_section. Current code doesn't have this >>>>>> constrain explicitly. >>>>>> >>>>>> This patch adds this to make sure it won't. >>>>>> >>>>>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com> >>>>> >>>>> Is this even possible? This would imply that the section size is smaller >>>>> than max order which would be quite a crazy selection for a sparesemem >>>>> section size. A lot of assumptions on the validity of PFNs within a >>>>> max-order boundary would be broken with such a section size. I'd be >>>>> surprised if such a setup could even boot, let alone run. >>>> >>>> pageblock_order has two definitions. >>>> >>>> #define pageblock_order HUGETLB_PAGE_ORDER >>>> >>>> #define pageblock_order (MAX_ORDER-1) >>>> >>>> If CONFIG_HUGETLB_PAGE is not enabled, pageblock_order is related to >>>> MAX_ORDER, which ensures it is smaller than section size. >>>> >>>> If CONFIG_HUGETLB_PAGE is enabled, pageblock_order is not related to >>>> MAX_ORDER. I don't see HUGETLB_PAGE_ORDER is ensured to be less than >>>> section size. Maybe I missed it? >>>> >>> >>> HUGETLB_PAGE_ORDER is less than MAX_ORDER on the basis that normal huge >>> pages (not gigantic) pages are served from the buddy allocator which is >>> limited by MAX_ORDER. >>> >> >> Maybe I am lost here, I got one possible definition on x86. >> >> #define pageblock_order HUGETLB_PAGE_ORDER >> #define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT) >> #define HPAGE_SHIFT PMD_SHIFT >> #define PMD_SHIFT PUD_SHIFT > >PMD_SHIFT is usually 21 > >arch/x86/include/asm/pgtable-3level_types.h:#define PMD_SHIFT 21 >arch/x86/include/asm/pgtable_64_types.h:#define PMD_SHIFT 21 > >Unless CONFIG_PGTABLE_LEVELS <= 2 > >Then include/asm-generic/pgtable-nopmd.h will be used in >arch/x86/include/asm/pgtable_types.h > #define PMD_SHIFT PUD_SHIFT > >In that case, also include/asm-generic/pgtable-nopmd.h is uses > #define PUD_SHIFT P4D_SHIFT > >... include/asm-generic/pgtable-nop4d.h > #define P4D_SHIFT PGDIR_SHIFT > > >And that would be >arch/x86/include/asm/pgtable-2level_types.h:#define PGDIR_SHIFT 22 > >If I am not wrong. > >So we would have pageblock_order = (22 - 12) = 10 > Thank, David :-) I think current configuration is correct, while all these digits are written by programmer. My concern and suggestion is to add a compiler check to enforce this. So that we would avoid this situation if someone miss this constrain. Just as the check on MAX_ORDER and SECION_SIZE. > >> #define PUD_SHIFT 30 >> >> This leads to pageblock_order = (30 - 12) = 18 > MAX_ORDER ? >> >> What you mentioned sounds reasonable. A huge page should be less than >> MAX_ORDER, otherwise page allocator couldn't handle it. But I don't see >> the connection between MAX_ORDER and HUGETLB_PAGE_ORDER. Do we need to >> add a check on this? Or it already has similar contrain in code, but I >> missed it? >> >>> -- >>> Mel Gorman >>> SUSE Labs >> > > >-- > >Thanks, > >David / dhildenb
On 06.12.18 10:21, Wei Yang wrote: > On Thu, Dec 06, 2018 at 10:00:05AM +0100, David Hildenbrand wrote: >> On 05.12.18 23:31, Wei Yang wrote: >>> On Wed, Dec 05, 2018 at 03:37:33PM +0000, Mel Gorman wrote: >>>> On Wed, Dec 05, 2018 at 12:08:20PM +0000, Wei Yang wrote: >>>>> On Wed, Dec 05, 2018 at 11:15:13AM +0000, Mel Gorman wrote: >>>>>> On Wed, Dec 05, 2018 at 05:19:04PM +0800, Wei Yang wrote: >>>>>>> When SPARSEMEM is used, there is an indication that pageblock is not >>>>>>> allowed to exceed one mem_section. Current code doesn't have this >>>>>>> constrain explicitly. >>>>>>> >>>>>>> This patch adds this to make sure it won't. >>>>>>> >>>>>>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com> >>>>>> >>>>>> Is this even possible? This would imply that the section size is smaller >>>>>> than max order which would be quite a crazy selection for a sparesemem >>>>>> section size. A lot of assumptions on the validity of PFNs within a >>>>>> max-order boundary would be broken with such a section size. I'd be >>>>>> surprised if such a setup could even boot, let alone run. >>>>> >>>>> pageblock_order has two definitions. >>>>> >>>>> #define pageblock_order HUGETLB_PAGE_ORDER >>>>> >>>>> #define pageblock_order (MAX_ORDER-1) >>>>> >>>>> If CONFIG_HUGETLB_PAGE is not enabled, pageblock_order is related to >>>>> MAX_ORDER, which ensures it is smaller than section size. >>>>> >>>>> If CONFIG_HUGETLB_PAGE is enabled, pageblock_order is not related to >>>>> MAX_ORDER. I don't see HUGETLB_PAGE_ORDER is ensured to be less than >>>>> section size. Maybe I missed it? >>>>> >>>> >>>> HUGETLB_PAGE_ORDER is less than MAX_ORDER on the basis that normal huge >>>> pages (not gigantic) pages are served from the buddy allocator which is >>>> limited by MAX_ORDER. >>>> >>> >>> Maybe I am lost here, I got one possible definition on x86. >>> >>> #define pageblock_order HUGETLB_PAGE_ORDER >>> #define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT) >>> #define HPAGE_SHIFT PMD_SHIFT >>> #define PMD_SHIFT PUD_SHIFT >> >> PMD_SHIFT is usually 21 >> >> arch/x86/include/asm/pgtable-3level_types.h:#define PMD_SHIFT 21 >> arch/x86/include/asm/pgtable_64_types.h:#define PMD_SHIFT 21 >> >> Unless CONFIG_PGTABLE_LEVELS <= 2 >> >> Then include/asm-generic/pgtable-nopmd.h will be used in >> arch/x86/include/asm/pgtable_types.h >> #define PMD_SHIFT PUD_SHIFT >> >> In that case, also include/asm-generic/pgtable-nopmd.h is uses >> #define PUD_SHIFT P4D_SHIFT >> >> ... include/asm-generic/pgtable-nop4d.h >> #define P4D_SHIFT PGDIR_SHIFT >> >> >> And that would be >> arch/x86/include/asm/pgtable-2level_types.h:#define PGDIR_SHIFT 22 >> >> If I am not wrong. >> >> So we would have pageblock_order = (22 - 12) = 10 >> > > Thank, David :-) > > I think current configuration is correct, while all these digits are > written by programmer. > > My concern and suggestion is to add a compiler check to enforce this. So > that we would avoid this situation if someone miss this constrain. Just > as the check on MAX_ORDER and SECION_SIZE. I am not completely against this, I rather wonder if it is needed because I assume other things will break horribly in case this is violated. And at that would only be helpful for somebody developing for a new architecture/flavor. As I am a friend of documenting things that are not obvious, I would rather suggest to add a comment to the #define pageblock_order HUGETLB_PAGE_ORDER line, stating what we just learned. /* * HUGETLB_PAGE_ORDER will always be smaller than MAX_ORDER, so that * huge (not gigantic) pages can be served from the buddy allocator. */
On Thu, Dec 06, 2018 at 10:26:55AM +0100, David Hildenbrand wrote: >On 06.12.18 10:21, Wei Yang wrote: >> On Thu, Dec 06, 2018 at 10:00:05AM +0100, David Hildenbrand wrote: >>> On 05.12.18 23:31, Wei Yang wrote: >>>> On Wed, Dec 05, 2018 at 03:37:33PM +0000, Mel Gorman wrote: >>>>> On Wed, Dec 05, 2018 at 12:08:20PM +0000, Wei Yang wrote: >>>>>> On Wed, Dec 05, 2018 at 11:15:13AM +0000, Mel Gorman wrote: >>>>>>> On Wed, Dec 05, 2018 at 05:19:04PM +0800, Wei Yang wrote: >>>>>>>> When SPARSEMEM is used, there is an indication that pageblock is not >>>>>>>> allowed to exceed one mem_section. Current code doesn't have this >>>>>>>> constrain explicitly. >>>>>>>> >>>>>>>> This patch adds this to make sure it won't. >>>>>>>> >>>>>>>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com> >>>>>>> >>>>>>> Is this even possible? This would imply that the section size is smaller >>>>>>> than max order which would be quite a crazy selection for a sparesemem >>>>>>> section size. A lot of assumptions on the validity of PFNs within a >>>>>>> max-order boundary would be broken with such a section size. I'd be >>>>>>> surprised if such a setup could even boot, let alone run. >>>>>> >>>>>> pageblock_order has two definitions. >>>>>> >>>>>> #define pageblock_order HUGETLB_PAGE_ORDER >>>>>> >>>>>> #define pageblock_order (MAX_ORDER-1) >>>>>> >>>>>> If CONFIG_HUGETLB_PAGE is not enabled, pageblock_order is related to >>>>>> MAX_ORDER, which ensures it is smaller than section size. >>>>>> >>>>>> If CONFIG_HUGETLB_PAGE is enabled, pageblock_order is not related to >>>>>> MAX_ORDER. I don't see HUGETLB_PAGE_ORDER is ensured to be less than >>>>>> section size. Maybe I missed it? >>>>>> >>>>> >>>>> HUGETLB_PAGE_ORDER is less than MAX_ORDER on the basis that normal huge >>>>> pages (not gigantic) pages are served from the buddy allocator which is >>>>> limited by MAX_ORDER. >>>>> >>>> >>>> Maybe I am lost here, I got one possible definition on x86. >>>> >>>> #define pageblock_order HUGETLB_PAGE_ORDER >>>> #define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT) >>>> #define HPAGE_SHIFT PMD_SHIFT >>>> #define PMD_SHIFT PUD_SHIFT >>> >>> PMD_SHIFT is usually 21 >>> >>> arch/x86/include/asm/pgtable-3level_types.h:#define PMD_SHIFT 21 >>> arch/x86/include/asm/pgtable_64_types.h:#define PMD_SHIFT 21 >>> >>> Unless CONFIG_PGTABLE_LEVELS <= 2 >>> >>> Then include/asm-generic/pgtable-nopmd.h will be used in >>> arch/x86/include/asm/pgtable_types.h >>> #define PMD_SHIFT PUD_SHIFT >>> >>> In that case, also include/asm-generic/pgtable-nopmd.h is uses >>> #define PUD_SHIFT P4D_SHIFT >>> >>> ... include/asm-generic/pgtable-nop4d.h >>> #define P4D_SHIFT PGDIR_SHIFT >>> >>> >>> And that would be >>> arch/x86/include/asm/pgtable-2level_types.h:#define PGDIR_SHIFT 22 >>> >>> If I am not wrong. >>> >>> So we would have pageblock_order = (22 - 12) = 10 >>> >> >> Thank, David :-) >> >> I think current configuration is correct, while all these digits are >> written by programmer. >> >> My concern and suggestion is to add a compiler check to enforce this. So >> that we would avoid this situation if someone miss this constrain. Just >> as the check on MAX_ORDER and SECION_SIZE. > >I am not completely against this, I rather wonder if it is needed >because I assume other things will break horribly in case this is >violated. And at that would only be helpful for somebody developing for >a new architecture/flavor. I think you are right. > >As I am a friend of documenting things that are not obvious, I would >rather suggest to add a comment to the > #define pageblock_order HUGETLB_PAGE_ORDER >line, stating what we just learned. > >/* > * HUGETLB_PAGE_ORDER will always be smaller than MAX_ORDER, so that > * huge (not gigantic) pages can be served from the buddy allocator. > */ > This looks good to me. Let's see which one others prefer :-) > >-- > >Thanks, > >David / dhildenb
Hi Wei,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc5 next-20181207]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Wei-Yang/mm-pageblock-make-sure-pageblock-won-t-exceed-mem_sectioin/20181207-030601
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=powerpc
All warnings (new ones prefixed by >>):
In file included from include/linux/gfp.h:6:0,
from include/linux/xarray.h:14,
from include/linux/radix-tree.h:31,
from include/linux/fs.h:15,
from include/linux/compat.h:17,
from arch/powerpc/kernel/asm-offsets.c:16:
>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
#if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
^~~~~~~~~~~~~~~
--
In file included from include/linux/gfp.h:6:0,
from include/linux/mm.h:10,
from mm//swap.c:16:
>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
#if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
^~~~~~~~~~~~~~~
In file included from include/linux/gfp.h:6:0,
from include/linux/mm.h:10,
from mm//swap.c:16:
>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
#if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
^~~~~~~~~~~~~~~
vim +/pageblock_order +1088 include/linux/mmzone.h
1087
> 1088 #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
1089 #error Allocator pageblock_order exceeds SECTION_SIZE
1090 #endif
1091
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
On Sat, Dec 08, 2018 at 09:42:29AM +0800, kbuild test robot wrote: >Hi Wei, > >Thank you for the patch! Perhaps something to improve: > >[auto build test WARNING on linus/master] >[also build test WARNING on v4.20-rc5 next-20181207] >[if your patch is applied to the wrong git tree, please drop us a note to help improve the system] > >url: https://github.com/0day-ci/linux/commits/Wei-Yang/mm-pageblock-make-sure-pageblock-won-t-exceed-mem_sectioin/20181207-030601 >config: powerpc-allmodconfig (attached as .config) >compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 >reproduce: > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > GCC_VERSION=7.2.0 make.cross ARCH=powerpc > >All warnings (new ones prefixed by >>): > > In file included from include/linux/gfp.h:6:0, > from include/linux/xarray.h:14, > from include/linux/radix-tree.h:31, > from include/linux/fs.h:15, > from include/linux/compat.h:17, > from arch/powerpc/kernel/asm-offsets.c:16: >>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] > #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS > ^~~~~~~~~~~~~~~ >-- > In file included from include/linux/gfp.h:6:0, > from include/linux/mm.h:10, > from mm//swap.c:16: >>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] > #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS > ^~~~~~~~~~~~~~~ > In file included from include/linux/gfp.h:6:0, > from include/linux/mm.h:10, > from mm//swap.c:16: >>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] > #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS > ^~~~~~~~~~~~~~~ > >vim +/pageblock_order +1088 include/linux/mmzone.h > > 1087 >> 1088 #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS > 1089 #error Allocator pageblock_order exceeds SECTION_SIZE > 1090 #endif > 1091 > I took a look at the latest code, at line 1082 of the same file uses pageblock_order. And I apply this patch on top of v4.20-rc5, the build looks good to me. Confused why this introduce an compile error. >--- >0-DAY kernel test infrastructure Open Source Technology Center >https://lists.01.org/pipermail/kbuild-all Intel Corporation
Hi Wei,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc5 next-20181207]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Wei-Yang/mm-pageblock-make-sure-pageblock-won-t-exceed-mem_sectioin/20181207-030601
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
In file included from include/linux/gfp.h:6:0,
from include/linux/umh.h:4,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/misc/ocxl/main.c:3:
>> include/linux/mmzone.h:1088:6: error: "pageblock_order" is not defined, evaluates to 0 [-Werror=undef]
#if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
^~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
vim +/pageblock_order +1088 include/linux/mmzone.h
1087
> 1088 #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
1089 #error Allocator pageblock_order exceeds SECTION_SIZE
1090 #endif
1091
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
On 12/09/2018 08:03 PM, Wei Yang wrote: > On Sat, Dec 08, 2018 at 09:42:29AM +0800, kbuild test robot wrote: >> Hi Wei, >> >> Thank you for the patch! Perhaps something to improve: >> >> [auto build test WARNING on linus/master] >> [also build test WARNING on v4.20-rc5 next-20181207] >> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] >> >> url: https://github.com/0day-ci/linux/commits/Wei-Yang/mm-pageblock-make-sure-pageblock-won-t-exceed-mem_sectioin/20181207-030601 >> config: powerpc-allmodconfig (attached as .config) >> compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 >> reproduce: >> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross >> chmod +x ~/bin/make.cross >> # save the attached .config to linux build tree >> GCC_VERSION=7.2.0 make.cross ARCH=powerpc >> >> All warnings (new ones prefixed by >>): >> >> In file included from include/linux/gfp.h:6:0, >> from include/linux/xarray.h:14, >> from include/linux/radix-tree.h:31, >> from include/linux/fs.h:15, >> from include/linux/compat.h:17, >> from arch/powerpc/kernel/asm-offsets.c:16: >>>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] >> #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS >> ^~~~~~~~~~~~~~~ >> -- >> In file included from include/linux/gfp.h:6:0, >> from include/linux/mm.h:10, >> from mm//swap.c:16: >>>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] >> #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS >> ^~~~~~~~~~~~~~~ >> In file included from include/linux/gfp.h:6:0, >> from include/linux/mm.h:10, >> from mm//swap.c:16: >>>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] >> #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS >> ^~~~~~~~~~~~~~~ >> >> vim +/pageblock_order +1088 include/linux/mmzone.h >> >> 1087 >>> 1088 #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS >> 1089 #error Allocator pageblock_order exceeds SECTION_SIZE >> 1090 #endif >> 1091 >> > I took a look at the latest code, at line 1082 of the same file uses > pageblock_order. And I apply this patch on top of v4.20-rc5, the build > looks good to me. > > Confused why this introduce an compile error. Hi Wei, we could reproduce the warnings with using make.cross. Best Regards, Rong Chen > >> --- >> 0-DAY kernel test infrastructure Open Source Technology Center >> https://lists.01.org/pipermail/kbuild-all Intel Corporation > >
On Thu, Dec 13, 2018 at 10:26:41AM +0800, Rong Chen wrote: > > >On 12/09/2018 08:03 PM, Wei Yang wrote: >> On Sat, Dec 08, 2018 at 09:42:29AM +0800, kbuild test robot wrote: >> > Hi Wei, >> > >> > Thank you for the patch! Perhaps something to improve: >> > >> > [auto build test WARNING on linus/master] >> > [also build test WARNING on v4.20-rc5 next-20181207] >> > [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] >> > >> > url: https://github.com/0day-ci/linux/commits/Wei-Yang/mm-pageblock-make-sure-pageblock-won-t-exceed-mem_sectioin/20181207-030601 >> > config: powerpc-allmodconfig (attached as .config) >> > compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 >> > reproduce: >> > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross >> > chmod +x ~/bin/make.cross >> > # save the attached .config to linux build tree >> > GCC_VERSION=7.2.0 make.cross ARCH=powerpc >> > >> > All warnings (new ones prefixed by >>): >> > >> > In file included from include/linux/gfp.h:6:0, >> > from include/linux/xarray.h:14, >> > from include/linux/radix-tree.h:31, >> > from include/linux/fs.h:15, >> > from include/linux/compat.h:17, >> > from arch/powerpc/kernel/asm-offsets.c:16: >> > > > include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] >> > #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS >> > ^~~~~~~~~~~~~~~ >> > -- >> > In file included from include/linux/gfp.h:6:0, >> > from include/linux/mm.h:10, >> > from mm//swap.c:16: >> > > > include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] >> > #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS >> > ^~~~~~~~~~~~~~~ >> > In file included from include/linux/gfp.h:6:0, >> > from include/linux/mm.h:10, >> > from mm//swap.c:16: >> > > > include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] >> > #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS >> > ^~~~~~~~~~~~~~~ >> > >> > vim +/pageblock_order +1088 include/linux/mmzone.h >> > >> > 1087 >> > > 1088 #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS >> > 1089 #error Allocator pageblock_order exceeds SECTION_SIZE >> > 1090 #endif >> > 1091 >> > >> I took a look at the latest code, at line 1082 of the same file uses >> pageblock_order. And I apply this patch on top of v4.20-rc5, the build >> looks good to me. >> >> Confused why this introduce an compile error. > >Hi Wei, > >we could reproduce the warnings with using make.cross. > That's interesting. Do you see this file already use pageblock_order in line 1081? Is this one report warning? >Best Regards, >Rong Chen > >> >> > --- >> > 0-DAY kernel test infrastructure Open Source Technology Center >> > https://lists.01.org/pipermail/kbuild-all Intel Corporation >> >>
On 12/13/2018 11:08 AM, Wei Yang wrote: > On Thu, Dec 13, 2018 at 10:26:41AM +0800, Rong Chen wrote: >> >> On 12/09/2018 08:03 PM, Wei Yang wrote: >>> On Sat, Dec 08, 2018 at 09:42:29AM +0800, kbuild test robot wrote: >>>> Hi Wei, >>>> >>>> Thank you for the patch! Perhaps something to improve: >>>> >>>> [auto build test WARNING on linus/master] >>>> [also build test WARNING on v4.20-rc5 next-20181207] >>>> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] >>>> >>>> url: https://github.com/0day-ci/linux/commits/Wei-Yang/mm-pageblock-make-sure-pageblock-won-t-exceed-mem_sectioin/20181207-030601 >>>> config: powerpc-allmodconfig (attached as .config) >>>> compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 >>>> reproduce: >>>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross >>>> chmod +x ~/bin/make.cross >>>> # save the attached .config to linux build tree >>>> GCC_VERSION=7.2.0 make.cross ARCH=powerpc >>>> >>>> All warnings (new ones prefixed by >>): >>>> >>>> In file included from include/linux/gfp.h:6:0, >>>> from include/linux/xarray.h:14, >>>> from include/linux/radix-tree.h:31, >>>> from include/linux/fs.h:15, >>>> from include/linux/compat.h:17, >>>> from arch/powerpc/kernel/asm-offsets.c:16: >>>>>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] >>>> #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS >>>> ^~~~~~~~~~~~~~~ >>>> -- >>>> In file included from include/linux/gfp.h:6:0, >>>> from include/linux/mm.h:10, >>>> from mm//swap.c:16: >>>>>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] >>>> #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS >>>> ^~~~~~~~~~~~~~~ >>>> In file included from include/linux/gfp.h:6:0, >>>> from include/linux/mm.h:10, >>>> from mm//swap.c:16: >>>>>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] >>>> #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS >>>> ^~~~~~~~~~~~~~~ >>>> >>>> vim +/pageblock_order +1088 include/linux/mmzone.h >>>> >>>> 1087 >>>>> 1088 #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS >>>> 1089 #error Allocator pageblock_order exceeds SECTION_SIZE >>>> 1090 #endif >>>> 1091 >>>> >>> I took a look at the latest code, at line 1082 of the same file uses >>> pageblock_order. And I apply this patch on top of v4.20-rc5, the build >>> looks good to me. >>> >>> Confused why this introduce an compile error. >> Hi Wei, >> >> we could reproduce the warnings with using make.cross. >> > That's interesting. > > Do you see this file already use pageblock_order in line 1081? > > Is this one report warning? > both questions is yes. Best Regards, Rong Chen <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <p><br> </p> <br> <div class="moz-cite-prefix">On 12/13/2018 11:08 AM, Wei Yang wrote:<br> </div> <blockquote type="cite" cite="mid:20181213030832.whutggpzdy336u6y@master"> <pre wrap="">On Thu, Dec 13, 2018 at 10:26:41AM +0800, Rong Chen wrote: </pre> <blockquote type="cite"> <pre wrap=""> On 12/09/2018 08:03 PM, Wei Yang wrote: </pre> <blockquote type="cite"> <pre wrap="">On Sat, Dec 08, 2018 at 09:42:29AM +0800, kbuild test robot wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi Wei, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.20-rc5 next-20181207] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: <a class="moz-txt-link-freetext" href="https://github.com/0day-ci/linux/commits/Wei-Yang/mm-pageblock-make-sure-pageblock-won-t-exceed-mem_sectioin/20181207-030601">https://github.com/0day-ci/linux/commits/Wei-Yang/mm-pageblock-make-sure-pageblock-won-t-exceed-mem_sectioin/20181207-030601</a> config: powerpc-allmodconfig (attached as .config) compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget <a class="moz-txt-link-freetext" href="https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross">https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross</a> -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=powerpc All warnings (new ones prefixed by >>): In file included from include/linux/gfp.h:6:0, from include/linux/xarray.h:14, from include/linux/radix-tree.h:31, from include/linux/fs.h:15, from include/linux/compat.h:17, from arch/powerpc/kernel/asm-offsets.c:16: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] </pre> </blockquote> </blockquote> <pre wrap=""> #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS ^~~~~~~~~~~~~~~ -- In file included from include/linux/gfp.h:6:0, from include/linux/mm.h:10, from mm//swap.c:16: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] </pre> </blockquote> </blockquote> <pre wrap=""> #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS ^~~~~~~~~~~~~~~ In file included from include/linux/gfp.h:6:0, from include/linux/mm.h:10, from mm//swap.c:16: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] </pre> </blockquote> </blockquote> <pre wrap=""> #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS ^~~~~~~~~~~~~~~ vim +/pageblock_order +1088 include/linux/mmzone.h 1087 </pre> <blockquote type="cite"> <pre wrap="">1088 #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS </pre> </blockquote> <pre wrap=""> 1089 #error Allocator pageblock_order exceeds SECTION_SIZE 1090 #endif 1091 </pre> </blockquote> <pre wrap="">I took a look at the latest code, at line 1082 of the same file uses pageblock_order. And I apply this patch on top of v4.20-rc5, the build looks good to me. Confused why this introduce an compile error. </pre> </blockquote> <pre wrap=""> Hi Wei, we could reproduce the warnings with using make.cross. </pre> </blockquote> <pre wrap=""> That's interesting. Do you see this file already use pageblock_order in line 1081? Is this one report warning? </pre> </blockquote> <br> <span id="w_228" class="high-light">both </span><span id="w_229" class="">questions </span><span id="w_230" class="">is </span><span id="w_231" class="high-light">yes</span><span id="w_232" class="">.<br> <br> Best Regards,<br> Rong Chen<br> <br> </span> <blockquote type="cite" cite="mid:20181213030832.whutggpzdy336u6y@master"> <pre wrap=""> </pre> </blockquote> <br> </body> </html>
On Thu, Dec 13, 2018 at 01:02:21PM +0800, Rong Chen wrote: > > >On 12/13/2018 11:08 AM, Wei Yang wrote: >> On Thu, Dec 13, 2018 at 10:26:41AM +0800, Rong Chen wrote: >> > >> > On 12/09/2018 08:03 PM, Wei Yang wrote: >> > > On Sat, Dec 08, 2018 at 09:42:29AM +0800, kbuild test robot wrote: >> > > > Hi Wei, >> > > > >> > > > Thank you for the patch! Perhaps something to improve: >> > > > >> > > > [auto build test WARNING on linus/master] >> > > > [also build test WARNING on v4.20-rc5 next-20181207] >> > > > [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] >> > > > >> > > > url: https://github.com/0day-ci/linux/commits/Wei-Yang/mm-pageblock-make-sure-pageblock-won-t-exceed-mem_sectioin/20181207-030601 >> > > > config: powerpc-allmodconfig (attached as .config) >> > > > compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 >> > > > reproduce: >> > > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross >> > > > chmod +x ~/bin/make.cross >> > > > # save the attached .config to linux build tree >> > > > GCC_VERSION=7.2.0 make.cross ARCH=powerpc >> > > > >> > > > All warnings (new ones prefixed by >>): >> > > > >> > > > In file included from include/linux/gfp.h:6:0, >> > > > from include/linux/xarray.h:14, >> > > > from include/linux/radix-tree.h:31, >> > > > from include/linux/fs.h:15, >> > > > from include/linux/compat.h:17, >> > > > from arch/powerpc/kernel/asm-offsets.c:16: >> > > > > > include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] >> > > > #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS >> > > > ^~~~~~~~~~~~~~~ >> > > > -- >> > > > In file included from include/linux/gfp.h:6:0, >> > > > from include/linux/mm.h:10, >> > > > from mm//swap.c:16: >> > > > > > include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] >> > > > #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS >> > > > ^~~~~~~~~~~~~~~ >> > > > In file included from include/linux/gfp.h:6:0, >> > > > from include/linux/mm.h:10, >> > > > from mm//swap.c:16: >> > > > > > include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef] >> > > > #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS >> > > > ^~~~~~~~~~~~~~~ >> > > > >> > > > vim +/pageblock_order +1088 include/linux/mmzone.h >> > > > >> > > > 1087 >> > > > > 1088 #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS >> > > > 1089 #error Allocator pageblock_order exceeds SECTION_SIZE >> > > > 1090 #endif >> > > > 1091 >> > > > >> > > I took a look at the latest code, at line 1082 of the same file uses >> > > pageblock_order. And I apply this patch on top of v4.20-rc5, the build >> > > looks good to me. >> > > >> > > Confused why this introduce an compile error. >> > Hi Wei, >> > >> > we could reproduce the warnings with using make.cross. >> > >> That's interesting. >> >> Do you see this file already use pageblock_order in line 1081? >> >> Is this one report warning? >> > >both questions is yes. > Sounds interesting :-) I don't have a power machine and we may drop this patch as discussed, so I won't look into this now. Thanks for your effort. >Best Regards, >Rong Chen > >
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index be126113b499..8f3ce3a0c7d6 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -1084,6 +1084,10 @@ static inline unsigned long early_pfn_to_nid(unsigned long pfn) #error Allocator MAX_ORDER exceeds SECTION_SIZE #endif +#if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS +#error Allocator pageblock_order exceeds SECTION_SIZE +#endif + static inline unsigned long pfn_to_section_nr(unsigned long pfn) { return pfn >> PFN_SECTION_SHIFT;
When SPARSEMEM is used, there is an indication that pageblock is not allowed to exceed one mem_section. Current code doesn't have this constrain explicitly. This patch adds this to make sure it won't. Signed-off-by: Wei Yang <richard.weiyang@gmail.com> --- include/linux/mmzone.h | 4 ++++ 1 file changed, 4 insertions(+)