* Re: [PATCH RFC] mm: Properly document tail pages for compound pages
2023-08-10 20:49 [PATCH RFC] mm: Properly document tail pages for compound pages Peter Xu
@ 2023-08-10 21:43 ` Matthew Wilcox
2023-08-14 18:01 ` Peter Xu
2023-08-10 22:51 ` kernel test robot
2023-08-10 23:32 ` kernel test robot
2 siblings, 1 reply; 5+ messages in thread
From: Matthew Wilcox @ 2023-08-10 21:43 UTC (permalink / raw)
To: Peter Xu
Cc: linux-mm, linux-kernel, Yu Zhao, Mike Kravetz, Yang Shi,
Andrew Morton, Kirill A . Shutemov, Hugh Dickins,
David Hildenbrand, Ryan Roberts
On Thu, Aug 10, 2023 at 04:49:44PM -0400, Peter Xu wrote:
> Tail page struct reuse is over-comlicated. Not only because we have
> implicit uses of tail page fields (mapcounts, or private for thp swap
> support, etc., that we _may_ still use in the page structs, but not obvious
> the relationship between that and the folio definitions), but also because
> we have 32/64 bits layouts for struct page so it's unclear what we can use
> and what we cannot when trying to find a new spot in folio struct.
I do not like this patch.
> We also have tricks like page->mapping, where we can reuse only the tail
> page 1/2 but nothing more than tail page 2. It is all mostly hidden, until
> someone starts to read into a VM_BUG_ON_PAGE() of __split_huge_page_tail().
We can change those BUG_ON if we want to reuse mapping in more tail pages.
Ask!
> Let's document it clearly on what we can use and what we can't, with 100%
> explanations on each of them. Hopefully this will make:
The explanations are still very page centric. I do not like the style
of them, nor how you explain them.
> One pitfall is I'll need to split part of the tail page 1 definition into
> 32/64 bits differently, that introduced some duplications on the fields.
> But hopefully that's worthwhile as it makes everything crystal clear. Not
> to mention that "pitfall" also brings a benefit that we can actually define
> fields in different order for 32/64 bits when we want.
No. This is going to ruin kernel-doc.
> + /*
> + * Some of the tail page fields (out of 8 WORDs for either 32/64
There's your first mistake; struct page is not necessarily 8 WORDs.
You've got 7 words for sure, then on 32-bit you have 8 because atomic_t
is word-sized. memcg_data might be the 9th word, virtual could be
the tenth, two awful kmsan intrusions could bring it to twelve, and
last_cpupid could bring it to thirteen.
Sure, it's 8 words on x86-64 with CONFIG_MEMCG enabled. But that's
just your system.
> + * bits archs) may not be reused by the folio object because
> + * they're already been used by the page struct:
> + *
> + * |-------+---------------|
> + * | Index | Field |
> + * |-------+---------------|
> + * | 0 | flag |
> + * | 1 | compound_head |
> + * | 2 | N/A [0] |
> + * | 3 | mapping [1] |
> + * | 4 | N/A [0] |
> + * | 5 | private [2] |
> + * | 6 | mapcount |
> + * | 7 | N/A [0] |
This is wrong. You mustn't reuse refcount. refcount must remain 0 on
all tail pages. And you can't use anything after refcount, because it's
all optional on various configurations.
> + * |-------+---------------|
> + *
> + * [0] "N/A" marks fields that are available to leverage for the
> + * large folio.
N/A is a bad way to say this. "Free" or "Available" would be better.
> + * [1] "mapping" field is only used for sanity check, see
> + * TAIL_MAPPING. Still valid to use for tail pages 1/2.
> + * (for that, see __split_huge_page_tail()).
No, definitely wrong to document this.
> + * [2] "private" field is used when THP_SWAP is on (disabled on 32
> + * bits, or on hugetlb folios) .
Ugh, this needs to be fixed, not documented. If you really must
document it, at least say that this needs to be fixed.
> + */
> union {
> struct {
> + /* WORD 0-1: not valid to reuse */
... so now you're repeating all the information you provided above?
> unsigned long _flags_1;
> unsigned long _head_1;
> - /* public: */
... did you check kernel-doc after removing this?
> + /* WORD 2 */
> unsigned char _folio_dtor;
> unsigned char _folio_order;
> + unsigned char _holes_1[2];
No. If you need to search for holes, use pahole.
> +#ifdef CONFIG_64BIT
> atomic_t _entire_mapcount;
> + /* WORD 3 */
> atomic_t _nr_pages_mapped;
> atomic_t _pincount;
> -#ifdef CONFIG_64BIT
> + /* WORD 4 */
> unsigned int _folio_nr_pages;
> + unsigned int _reserved_1_1;
> + /* WORD 5-6: not valid to reuse */
> + unsigned long _used_1_2[2];
> + /* WORD 7 */
> + unsigned long _reserved_1_2;
> +#else
> + /* WORD 3 */
> + atomic_t _entire_mapcount;
> + /* WORD 4 */
> + atomic_t _nr_pages_mapped;
> + /* WORD 5: only valid for 32bits */
> + atomic_t _pincount;
> + /* WORD 6: not valid to reuse */
> + unsigned long _used_1_2;
> + /* WORD 7 */
> + unsigned long _reserved_1;
> #endif
> - /* private: the union with struct page is transitional */
> };
> + /* private: the union with struct page is transitional */
You don't understand why I did it like this. Again, you have to build
the kernel-doc and you'll see why the private: and public: markers are
where they are.
There was even a thread on it, a year or two ago, where I outlined the
various tradeoffs between complexity of the output and the complexity
of the input.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH RFC] mm: Properly document tail pages for compound pages
2023-08-10 21:43 ` Matthew Wilcox
@ 2023-08-14 18:01 ` Peter Xu
0 siblings, 0 replies; 5+ messages in thread
From: Peter Xu @ 2023-08-14 18:01 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-mm, linux-kernel, Yu Zhao, Mike Kravetz, Yang Shi,
Andrew Morton, Kirill A . Shutemov, Hugh Dickins,
David Hildenbrand, Ryan Roberts
On Thu, Aug 10, 2023 at 10:43:44PM +0100, Matthew Wilcox wrote:
> On Thu, Aug 10, 2023 at 04:49:44PM -0400, Peter Xu wrote:
> > Tail page struct reuse is over-comlicated. Not only because we have
> > implicit uses of tail page fields (mapcounts, or private for thp swap
> > support, etc., that we _may_ still use in the page structs, but not obvious
> > the relationship between that and the folio definitions), but also because
> > we have 32/64 bits layouts for struct page so it's unclear what we can use
> > and what we cannot when trying to find a new spot in folio struct.
>
> I do not like this patch.
>
> > We also have tricks like page->mapping, where we can reuse only the tail
> > page 1/2 but nothing more than tail page 2. It is all mostly hidden, until
> > someone starts to read into a VM_BUG_ON_PAGE() of __split_huge_page_tail().
>
> We can change those BUG_ON if we want to reuse mapping in more tail pages.
> Ask!
>
> > Let's document it clearly on what we can use and what we can't, with 100%
> > explanations on each of them. Hopefully this will make:
>
> The explanations are still very page centric. I do not like the style
> of them, nor how you explain them.
>
> > One pitfall is I'll need to split part of the tail page 1 definition into
> > 32/64 bits differently, that introduced some duplications on the fields.
> > But hopefully that's worthwhile as it makes everything crystal clear. Not
> > to mention that "pitfall" also brings a benefit that we can actually define
> > fields in different order for 32/64 bits when we want.
>
> No. This is going to ruin kernel-doc.
My fault. I'll make sure kernel-doc will keep looking sane.
It'll mean that my below trick on separating for 32/64 bits with duplicated
fields will stop working, but I found some other way to represent this.
>
> > + /*
> > + * Some of the tail page fields (out of 8 WORDs for either 32/64
>
> There's your first mistake; struct page is not necessarily 8 WORDs.
> You've got 7 words for sure, then on 32-bit you have 8 because atomic_t
> is word-sized. memcg_data might be the 9th word, virtual could be
> the tenth, two awful kmsan intrusions could bring it to twelve, and
> last_cpupid could bring it to thirteen.
>
> Sure, it's 8 words on x86-64 with CONFIG_MEMCG enabled. But that's
> just your system.
True. I messed up the mapcount/refcount position on 64 bits, sorry.
I hope atomic_t can always be assumed as 4 bytes though, and should hardly
change trivially, so I can still rely upon.
>
> > + * bits archs) may not be reused by the folio object because
> > + * they're already been used by the page struct:
> > + *
> > + * |-------+---------------|
> > + * | Index | Field |
> > + * |-------+---------------|
> > + * | 0 | flag |
> > + * | 1 | compound_head |
> > + * | 2 | N/A [0] |
> > + * | 3 | mapping [1] |
> > + * | 4 | N/A [0] |
> > + * | 5 | private [2] |
> > + * | 6 | mapcount |
> > + * | 7 | N/A [0] |
>
> This is wrong. You mustn't reuse refcount. refcount must remain 0 on
> all tail pages. And you can't use anything after refcount, because it's
> all optional on various configurations.
I got the answer in the other thread. I still don't know a full list of
things that we may require that, the only two things I got now are: (1)
fast-gup over any-sized folio on speculative boosts of refs, and (2) pfn
walkers like has_unmovable_pages().
I'll make an example here describing this, but if anyone can have a full
list of why it must keep zero here I think it'll be great to document all
of them, and this seems to be one of the best places to do it.
>
> > + * |-------+---------------|
> > + *
> > + * [0] "N/A" marks fields that are available to leverage for the
> > + * large folio.
>
> N/A is a bad way to say this. "Free" or "Available" would be better.
Indeed. I'll choose FREE.
>
> > + * [1] "mapping" field is only used for sanity check, see
> > + * TAIL_MAPPING. Still valid to use for tail pages 1/2.
> > + * (for that, see __split_huge_page_tail()).
>
> No, definitely wrong to document this.
I can document it in a "less detailed" way. I tend to introduce one macro
TAIL_MAPPING_REUSED_MAX=2 and use it in __split_huge_page_tail().
>
> > + * [2] "private" field is used when THP_SWAP is on (disabled on 32
> > + * bits, or on hugetlb folios) .
>
> Ugh, this needs to be fixed, not documented. If you really must
> document it, at least say that this needs to be fixed.
Sure. Any further description on the problem and "a proper fix"? I will
document that as "may need fixing" for now, but I'd try to reference more
on it if I can understand better on the problem.
>
> > + */
> > union {
> > struct {
> > + /* WORD 0-1: not valid to reuse */
>
> ... so now you're repeating all the information you provided above?
I'll try to remove many of them, but keep some so we read the fields
easier, knowing the offset of the WORD. I'm still open to remove all of
them if you think that's preferred.
>
> > unsigned long _flags_1;
> > unsigned long _head_1;
> > - /* public: */
>
> ... did you check kernel-doc after removing this?
>
> > + /* WORD 2 */
> > unsigned char _folio_dtor;
> > unsigned char _folio_order;
> > + unsigned char _holes_1[2];
>
> No. If you need to search for holes, use pahole.
Actually using _holes_* is definitely not right, because holes are
literally free spaces that can be reused. Here IMHO I should describe it
as two free bytes just like below, and that's one major goal of such a
patch, to be clear on what can be still reused in tail pages.
>
> > +#ifdef CONFIG_64BIT
> > atomic_t _entire_mapcount;
> > + /* WORD 3 */
> > atomic_t _nr_pages_mapped;
> > atomic_t _pincount;
> > -#ifdef CONFIG_64BIT
> > + /* WORD 4 */
> > unsigned int _folio_nr_pages;
> > + unsigned int _reserved_1_1;
> > + /* WORD 5-6: not valid to reuse */
> > + unsigned long _used_1_2[2];
(These "_used*" things will go away; I took another trick to represent only
"free" slots not "used", side effect of making kernel-doc happy)
> > + /* WORD 7 */
> > + unsigned long _reserved_1_2;
> > +#else
> > + /* WORD 3 */
> > + atomic_t _entire_mapcount;
> > + /* WORD 4 */
> > + atomic_t _nr_pages_mapped;
> > + /* WORD 5: only valid for 32bits */
> > + atomic_t _pincount;
> > + /* WORD 6: not valid to reuse */
> > + unsigned long _used_1_2;
> > + /* WORD 7 */
> > + unsigned long _reserved_1;
> > #endif
> > - /* private: the union with struct page is transitional */
> > };
> > + /* private: the union with struct page is transitional */
>
> You don't understand why I did it like this. Again, you have to build
> the kernel-doc and you'll see why the private: and public: markers are
> where they are.
>
> There was even a thread on it, a year or two ago, where I outlined the
> various tradeoffs between complexity of the output and the complexity
> of the input.
Links would be appreciated, at the meantime I'll send a rfcv2. I hope that
addresses most of the issues above while still provide most of what I
wanted to provide; not sure about this last one though before I get more
information. Let me know if the whole idea just won't work, then I can
always stop.
--
Peter Xu
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH RFC] mm: Properly document tail pages for compound pages
2023-08-10 20:49 [PATCH RFC] mm: Properly document tail pages for compound pages Peter Xu
2023-08-10 21:43 ` Matthew Wilcox
@ 2023-08-10 22:51 ` kernel test robot
2023-08-10 23:32 ` kernel test robot
2 siblings, 0 replies; 5+ messages in thread
From: kernel test robot @ 2023-08-10 22:51 UTC (permalink / raw)
To: Peter Xu; +Cc: oe-kbuild-all
Hi Peter,
[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:
[auto build test ERROR on akpm-mm/mm-everything]
url: https://github.com/intel-lab-lkp/linux/commits/Peter-Xu/mm-Properly-document-tail-pages-for-compound-pages/20230811-045015
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link: https://lore.kernel.org/r/20230810204944.53471-1-peterx%40redhat.com
patch subject: [PATCH RFC] mm: Properly document tail pages for compound pages
config: mips-randconfig-r035-20230811 (https://download.01.org/0day-ci/archive/20230811/202308110642.t5ECWu7x-lkp@intel.com/config)
compiler: mips64el-linux-gcc (GCC) 12.3.0
reproduce: (https://download.01.org/0day-ci/archive/20230811/202308110642.t5ECWu7x-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202308110642.t5ECWu7x-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from include/linux/bits.h:21,
from arch/mips/include/asm/cpu.h:12,
from arch/mips/include/asm/timex.h:16,
from include/linux/timex.h:67,
from include/linux/time32.h:13,
from include/linux/time.h:60,
from include/linux/compat.h:10,
from arch/mips/kernel/asm-offsets.c:12:
>> include/linux/build_bug.h:78:41: error: static assertion failed: "offsetof(struct folio, _flags_2) == offsetof(struct page, flags) + 2 * sizeof(struct page)"
78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
| ^~~~~~~~~~~~~~
include/linux/build_bug.h:77:34: note: in expansion of macro '__static_assert'
77 | #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
| ^~~~~~~~~~~~~~~
include/linux/mm_types.h:434:9: note: in expansion of macro 'static_assert'
434 | static_assert(offsetof(struct folio, fl) == \
| ^~~~~~~~~~~~~
include/linux/mm_types.h:436:1: note: in expansion of macro 'FOLIO_MATCH'
436 | FOLIO_MATCH(flags, _flags_2);
| ^~~~~~~~~~~
>> include/linux/build_bug.h:78:41: error: static assertion failed: "offsetof(struct folio, _head_2) == offsetof(struct page, compound_head) + 2 * sizeof(struct page)"
78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
| ^~~~~~~~~~~~~~
include/linux/build_bug.h:77:34: note: in expansion of macro '__static_assert'
77 | #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
| ^~~~~~~~~~~~~~~
include/linux/mm_types.h:434:9: note: in expansion of macro 'static_assert'
434 | static_assert(offsetof(struct folio, fl) == \
| ^~~~~~~~~~~~~
include/linux/mm_types.h:437:1: note: in expansion of macro 'FOLIO_MATCH'
437 | FOLIO_MATCH(compound_head, _head_2);
| ^~~~~~~~~~~
make[3]: *** [scripts/Makefile.build:116: arch/mips/kernel/asm-offsets.s] Error 1 shuffle=3596142661
make[3]: Target 'missing-syscalls' not remade because of errors.
make[2]: *** [arch/mips/Makefile:434: archprepare] Error 2 shuffle=3596142661
make[2]: Target 'prepare' not remade because of errors.
make[1]: *** [Makefile:234: __sub-make] Error 2 shuffle=3596142661
make[1]: Target 'prepare' not remade because of errors.
make: *** [Makefile:234: __sub-make] Error 2 shuffle=3596142661
make: Target 'prepare' not remade because of errors.
vim +78 include/linux/build_bug.h
bc6245e5efd70c Ian Abbott 2017-07-10 60
6bab69c65013be Rasmus Villemoes 2019-03-07 61 /**
6bab69c65013be Rasmus Villemoes 2019-03-07 62 * static_assert - check integer constant expression at build time
6bab69c65013be Rasmus Villemoes 2019-03-07 63 *
6bab69c65013be Rasmus Villemoes 2019-03-07 64 * static_assert() is a wrapper for the C11 _Static_assert, with a
6bab69c65013be Rasmus Villemoes 2019-03-07 65 * little macro magic to make the message optional (defaulting to the
6bab69c65013be Rasmus Villemoes 2019-03-07 66 * stringification of the tested expression).
6bab69c65013be Rasmus Villemoes 2019-03-07 67 *
6bab69c65013be Rasmus Villemoes 2019-03-07 68 * Contrary to BUILD_BUG_ON(), static_assert() can be used at global
6bab69c65013be Rasmus Villemoes 2019-03-07 69 * scope, but requires the expression to be an integer constant
6bab69c65013be Rasmus Villemoes 2019-03-07 70 * expression (i.e., it is not enough that __builtin_constant_p() is
6bab69c65013be Rasmus Villemoes 2019-03-07 71 * true for expr).
6bab69c65013be Rasmus Villemoes 2019-03-07 72 *
6bab69c65013be Rasmus Villemoes 2019-03-07 73 * Also note that BUILD_BUG_ON() fails the build if the condition is
6bab69c65013be Rasmus Villemoes 2019-03-07 74 * true, while static_assert() fails the build if the expression is
6bab69c65013be Rasmus Villemoes 2019-03-07 75 * false.
6bab69c65013be Rasmus Villemoes 2019-03-07 76 */
6bab69c65013be Rasmus Villemoes 2019-03-07 77 #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
6bab69c65013be Rasmus Villemoes 2019-03-07 @78 #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
6bab69c65013be Rasmus Villemoes 2019-03-07 79
07a368b3f55a79 Maxim Levitsky 2022-10-25 80
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH RFC] mm: Properly document tail pages for compound pages
2023-08-10 20:49 [PATCH RFC] mm: Properly document tail pages for compound pages Peter Xu
2023-08-10 21:43 ` Matthew Wilcox
2023-08-10 22:51 ` kernel test robot
@ 2023-08-10 23:32 ` kernel test robot
2 siblings, 0 replies; 5+ messages in thread
From: kernel test robot @ 2023-08-10 23:32 UTC (permalink / raw)
To: Peter Xu; +Cc: llvm, oe-kbuild-all
Hi Peter,
[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:
[auto build test ERROR on akpm-mm/mm-everything]
url: https://github.com/intel-lab-lkp/linux/commits/Peter-Xu/mm-Properly-document-tail-pages-for-compound-pages/20230811-045015
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link: https://lore.kernel.org/r/20230810204944.53471-1-peterx%40redhat.com
patch subject: [PATCH RFC] mm: Properly document tail pages for compound pages
config: s390-randconfig-r033-20230811 (https://download.01.org/0day-ci/archive/20230811/202308110731.UFaTZGhn-lkp@intel.com/config)
compiler: clang version 15.0.7 (https://github.com/llvm/llvm-project.git 8dfdcc7b7bf66834a761bd8de445840ef68e4d1a)
reproduce: (https://download.01.org/0day-ci/archive/20230811/202308110731.UFaTZGhn-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202308110731.UFaTZGhn-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from arch/s390/kernel/asm-offsets.c:11:
In file included from include/linux/kvm_host.h:16:
In file included from include/linux/mm.h:7:
In file included from include/linux/gfp.h:7:
In file included from include/linux/mmzone.h:22:
>> include/linux/mm_types.h:436:1: error: static assertion failed due to requirement '__builtin_offsetof(struct folio, _flags_2) == __builtin_offsetof(struct page, flags) + 2 * sizeof(struct page)': offsetof(struct folio, _flags_2) == offsetof(struct page, flags) + 2 * sizeof(struct page)
FOLIO_MATCH(flags, _flags_2);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/mm_types.h:434:2: note: expanded from macro 'FOLIO_MATCH'
static_assert(offsetof(struct folio, fl) == \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:77:34: note: expanded from macro 'static_assert'
#define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:78:41: note: expanded from macro '__static_assert'
#define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
^ ~~~~
In file included from arch/s390/kernel/asm-offsets.c:11:
In file included from include/linux/kvm_host.h:16:
In file included from include/linux/mm.h:7:
In file included from include/linux/gfp.h:7:
In file included from include/linux/mmzone.h:22:
>> include/linux/mm_types.h:437:1: error: static assertion failed due to requirement '__builtin_offsetof(struct folio, _head_2) == __builtin_offsetof(struct page, compound_head) + 2 * sizeof(struct page)': offsetof(struct folio, _head_2) == offsetof(struct page, compound_head) + 2 * sizeof(struct page)
FOLIO_MATCH(compound_head, _head_2);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/mm_types.h:434:2: note: expanded from macro 'FOLIO_MATCH'
static_assert(offsetof(struct folio, fl) == \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:77:34: note: expanded from macro 'static_assert'
#define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:78:41: note: expanded from macro '__static_assert'
#define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
^ ~~~~
In file included from arch/s390/kernel/asm-offsets.c:11:
In file included from include/linux/kvm_host.h:19:
In file included from include/linux/msi.h:27:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/s390/include/asm/io.h:78:
include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __raw_readb(PCI_IOBASE + addr);
~~~~~~~~~~ ^
include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr));
~~~~~~~~~~ ^
include/uapi/linux/byteorder/big_endian.h:37:59: note: expanded from macro '__le16_to_cpu'
#define __le16_to_cpu(x) __swab16((__force __u16)(__le16)(x))
^
include/uapi/linux/swab.h:102:54: note: expanded from macro '__swab16'
#define __swab16(x) (__u16)__builtin_bswap16((__u16)(x))
^
In file included from arch/s390/kernel/asm-offsets.c:11:
In file included from include/linux/kvm_host.h:19:
In file included from include/linux/msi.h:27:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/s390/include/asm/io.h:78:
include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
~~~~~~~~~~ ^
include/uapi/linux/byteorder/big_endian.h:35:59: note: expanded from macro '__le32_to_cpu'
#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
^
include/uapi/linux/swab.h:115:54: note: expanded from macro '__swab32'
#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
^
In file included from arch/s390/kernel/asm-offsets.c:11:
In file included from include/linux/kvm_host.h:19:
In file included from include/linux/msi.h:27:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/s390/include/asm/io.h:78:
include/asm-generic/io.h:584:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
__raw_writeb(value, PCI_IOBASE + addr);
~~~~~~~~~~ ^
include/asm-generic/io.h:594:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
__raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr);
~~~~~~~~~~ ^
include/asm-generic/io.h:604:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
__raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr);
~~~~~~~~~~ ^
include/asm-generic/io.h:692:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
readsb(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
include/asm-generic/io.h:700:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
readsw(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
include/asm-generic/io.h:708:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
readsl(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
include/asm-generic/io.h:717:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
writesb(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
include/asm-generic/io.h:726:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
writesw(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
include/asm-generic/io.h:735:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
writesl(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
In file included from arch/s390/kernel/asm-offsets.c:11:
In file included from include/linux/kvm_host.h:19:
In file included from include/linux/msi.h:27:
In file included from include/linux/irq.h:609:
In file included from arch/s390/include/asm/hw_irq.h:6:
In file included from include/linux/pci.h:37:
In file included from include/linux/device.h:32:
In file included from include/linux/device/driver.h:21:
In file included from include/linux/module.h:19:
In file included from include/linux/elf.h:6:
In file included from arch/s390/include/asm/elf.h:160:
include/linux/compat.h:454:22: warning: array index 3 is past the end of the array (which contains 1 element) [-Warray-bounds]
case 4: v.sig[7] = (set->sig[3] >> 32); v.sig[6] = set->sig[3];
^ ~
arch/s390/include/asm/signal.h:22:9: note: array 'sig' declared here
unsigned long sig[_NSIG_WORDS];
^
In file included from arch/s390/kernel/asm-offsets.c:11:
In file included from include/linux/kvm_host.h:19:
In file included from include/linux/msi.h:27:
In file included from include/linux/irq.h:609:
In file included from arch/s390/include/asm/hw_irq.h:6:
In file included from include/linux/pci.h:37:
vim +436 include/linux/mm_types.h
7b230db3b8d373 Matthew Wilcox (Oracle 2020-12-06 412)
7b230db3b8d373 Matthew Wilcox (Oracle 2020-12-06 413) #define FOLIO_MATCH(pg, fl) \
7b230db3b8d373 Matthew Wilcox (Oracle 2020-12-06 414) static_assert(offsetof(struct page, pg) == offsetof(struct folio, fl))
7b230db3b8d373 Matthew Wilcox (Oracle 2020-12-06 415) FOLIO_MATCH(flags, flags);
7b230db3b8d373 Matthew Wilcox (Oracle 2020-12-06 416) FOLIO_MATCH(lru, lru);
536f4217ced62b Wei Yang 2022-01-29 417 FOLIO_MATCH(mapping, mapping);
7b230db3b8d373 Matthew Wilcox (Oracle 2020-12-06 418) FOLIO_MATCH(compound_head, lru);
7b230db3b8d373 Matthew Wilcox (Oracle 2020-12-06 419) FOLIO_MATCH(index, index);
7b230db3b8d373 Matthew Wilcox (Oracle 2020-12-06 420) FOLIO_MATCH(private, private);
7b230db3b8d373 Matthew Wilcox (Oracle 2020-12-06 421) FOLIO_MATCH(_mapcount, _mapcount);
7b230db3b8d373 Matthew Wilcox (Oracle 2020-12-06 422) FOLIO_MATCH(_refcount, _refcount);
7b230db3b8d373 Matthew Wilcox (Oracle 2020-12-06 423) #ifdef CONFIG_MEMCG
7b230db3b8d373 Matthew Wilcox (Oracle 2020-12-06 424) FOLIO_MATCH(memcg_data, memcg_data);
7b230db3b8d373 Matthew Wilcox (Oracle 2020-12-06 425) #endif
7b230db3b8d373 Matthew Wilcox (Oracle 2020-12-06 426) #undef FOLIO_MATCH
379708ffde1b04 Matthew Wilcox (Oracle 2022-09-02 427) #define FOLIO_MATCH(pg, fl) \
379708ffde1b04 Matthew Wilcox (Oracle 2022-09-02 428) static_assert(offsetof(struct folio, fl) == \
379708ffde1b04 Matthew Wilcox (Oracle 2022-09-02 429) offsetof(struct page, pg) + sizeof(struct page))
379708ffde1b04 Matthew Wilcox (Oracle 2022-09-02 430) FOLIO_MATCH(flags, _flags_1);
dad6a5eb555648 Hugh Dickins 2022-11-02 431 FOLIO_MATCH(compound_head, _head_1);
379708ffde1b04 Matthew Wilcox (Oracle 2022-09-02 432) #undef FOLIO_MATCH
dad6a5eb555648 Hugh Dickins 2022-11-02 433 #define FOLIO_MATCH(pg, fl) \
dad6a5eb555648 Hugh Dickins 2022-11-02 434 static_assert(offsetof(struct folio, fl) == \
dad6a5eb555648 Hugh Dickins 2022-11-02 435 offsetof(struct page, pg) + 2 * sizeof(struct page))
dad6a5eb555648 Hugh Dickins 2022-11-02 @436 FOLIO_MATCH(flags, _flags_2);
dad6a5eb555648 Hugh Dickins 2022-11-02 @437 FOLIO_MATCH(compound_head, _head_2);
dad6a5eb555648 Hugh Dickins 2022-11-02 438 #undef FOLIO_MATCH
7b230db3b8d373 Matthew Wilcox (Oracle 2020-12-06 439)
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 5+ messages in thread