All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: 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.