From: Peter Xu <peterx@redhat.com> To: Andrew Morton <akpm@linux-foundation.org> Cc: kernel test robot <lkp@intel.com>, kbuild-all@lists.01.org, Linux Memory Management List <linux-mm@kvack.org> Subject: Re: [linux-next:master 5135/5346] include/linux/hugetlb.h:411:25: error: unknown type name 'zap_flags_t'; did you mean 'vm_flags_t'? Date: Thu, 21 Apr 2022 16:29:37 -0400 [thread overview] Message-ID: <YmG+sY9D5ErbFt5B@xz-m1.local> (raw) In-Reply-To: <20220421130225.01b06f5c9b1a4f681df7acd0@linux-foundation.org> On Thu, Apr 21, 2022 at 01:02:25PM -0700, Andrew Morton wrote: > On Thu, 21 Apr 2022 15:51:03 -0400 Peter Xu <peterx@redhat.com> wrote: > > > > - * file-backed memory. This should only be specified when we will completely > > > - * drop the page in the mm, either by truncation or unmapping of the vma. By > > > - * default, the flag is not set. > > > - */ > > > -#define ZAP_FLAG_DROP_MARKER ((__force zap_flags_t) BIT(0)) > > > - > > > #endif /* _LINUX_MM_H */ > > > _ > > > > > > > Andrew, > > > > It may work, but I have worry that zap_flags_t should still be a common > > struct for mm not hugetlb specific, let's say it's still legal some .c file > > wants to reference it without hugetlb knowledge? > > > > >From that POV, could we perhaps move these chunk into mm_types.h (which > > hugetlb.h includes anyway)? > > > > Sure. ZAP_FLAG_DROP_MARKER isn't a type so how about we leave that in > mm.h? Sounds good, thanks! > > > --- a/include/linux/mm.h~mm-hugetlb-only-drop-uffd-wp-special-pte-if-required-fix-fix > +++ a/include/linux/mm.h > @@ -3431,8 +3431,6 @@ madvise_set_anon_name(struct mm_struct * > } > #endif > > -typedef unsigned int __bitwise zap_flags_t; > - > /* > * Whether to drop the pte markers, for example, the uffd-wp information for > * file-backed memory. This should only be specified when we will completely > --- a/include/linux/mm_types.h~mm-hugetlb-only-drop-uffd-wp-special-pte-if-required-fix-fix > +++ a/include/linux/mm_types.h > @@ -850,4 +850,6 @@ enum fault_flag { > FAULT_FLAG_ORIG_PTE_VALID = 1 << 11, > }; > > +typedef unsigned int __bitwise zap_flags_t; > + > #endif /* _LINUX_MM_TYPES_H */ > _ > -- Peter Xu
WARNING: multiple messages have this Message-ID (diff)
From: Peter Xu <peterx@redhat.com> To: kbuild-all@lists.01.org Subject: Re: [linux-next:master 5135/5346] include/linux/hugetlb.h:411:25: error: unknown type name 'zap_flags_t'; did you mean 'vm_flags_t'? Date: Thu, 21 Apr 2022 16:29:37 -0400 [thread overview] Message-ID: <YmG+sY9D5ErbFt5B@xz-m1.local> (raw) In-Reply-To: <20220421130225.01b06f5c9b1a4f681df7acd0@linux-foundation.org> [-- Attachment #1: Type: text/plain, Size: 1749 bytes --] On Thu, Apr 21, 2022 at 01:02:25PM -0700, Andrew Morton wrote: > On Thu, 21 Apr 2022 15:51:03 -0400 Peter Xu <peterx@redhat.com> wrote: > > > > - * file-backed memory. This should only be specified when we will completely > > > - * drop the page in the mm, either by truncation or unmapping of the vma. By > > > - * default, the flag is not set. > > > - */ > > > -#define ZAP_FLAG_DROP_MARKER ((__force zap_flags_t) BIT(0)) > > > - > > > #endif /* _LINUX_MM_H */ > > > _ > > > > > > > Andrew, > > > > It may work, but I have worry that zap_flags_t should still be a common > > struct for mm not hugetlb specific, let's say it's still legal some .c file > > wants to reference it without hugetlb knowledge? > > > > >From that POV, could we perhaps move these chunk into mm_types.h (which > > hugetlb.h includes anyway)? > > > > Sure. ZAP_FLAG_DROP_MARKER isn't a type so how about we leave that in > mm.h? Sounds good, thanks! > > > --- a/include/linux/mm.h~mm-hugetlb-only-drop-uffd-wp-special-pte-if-required-fix-fix > +++ a/include/linux/mm.h > @@ -3431,8 +3431,6 @@ madvise_set_anon_name(struct mm_struct * > } > #endif > > -typedef unsigned int __bitwise zap_flags_t; > - > /* > * Whether to drop the pte markers, for example, the uffd-wp information for > * file-backed memory. This should only be specified when we will completely > --- a/include/linux/mm_types.h~mm-hugetlb-only-drop-uffd-wp-special-pte-if-required-fix-fix > +++ a/include/linux/mm_types.h > @@ -850,4 +850,6 @@ enum fault_flag { > FAULT_FLAG_ORIG_PTE_VALID = 1 << 11, > }; > > +typedef unsigned int __bitwise zap_flags_t; > + > #endif /* _LINUX_MM_TYPES_H */ > _ > -- Peter Xu
next prev parent reply other threads:[~2022-04-21 20:29 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-21 10:34 [linux-next:master 5135/5346] include/linux/hugetlb.h:411:25: error: unknown type name 'zap_flags_t'; did you mean 'vm_flags_t'? kernel test robot 2022-04-21 19:38 ` Andrew Morton 2022-04-21 19:38 ` Andrew Morton 2022-04-21 19:51 ` Peter Xu 2022-04-21 19:51 ` Peter Xu 2022-04-21 20:02 ` Andrew Morton 2022-04-21 20:02 ` Andrew Morton 2022-04-21 20:29 ` Peter Xu [this message] 2022-04-21 20:29 ` Peter Xu
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=YmG+sY9D5ErbFt5B@xz-m1.local \ --to=peterx@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=kbuild-all@lists.01.org \ --cc=linux-mm@kvack.org \ --cc=lkp@intel.com \ /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: linkBe 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.