arch/x86/kernel/cpu/sgx/encl.c | 2 +- arch/x86/kernel/cpu/sgx/encl.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
The vm_flags_t type is the dedicated type for virtual memory flags.
Architecture and driver code should use this type instead of assuming
vm_flags is an unsigned long, as the underlying type may change in the
future.
This follows the cleanup in commit d75fa3c94750 ("mm: update
architecture and driver code to use vm_flags_t") by converting the
remaining vm_prot_bits usage in SGX code. Also, update the vm_max_prot_bits
type in struct sgx_encl_page to vm_flags_t for consistency.
No functional change intended.
Signed-off-by: Wentong Tian <tianwentong2000@gmail.com>
---
v2:
- Also convert the type of vm_max_prot_bits in struct sgx_encl_page
to vm_flags_t, as suggested.
arch/x86/kernel/cpu/sgx/encl.c | 2 +-
arch/x86/kernel/cpu/sgx/encl.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
index cf149b9f4916..814edcde225d 100644
--- a/arch/x86/kernel/cpu/sgx/encl.c
+++ b/arch/x86/kernel/cpu/sgx/encl.c
@@ -281,7 +281,7 @@ static struct sgx_encl_page *sgx_encl_load_page_in_vma(struct sgx_encl *encl,
unsigned long addr,
vm_flags_t vm_flags)
{
- unsigned long vm_prot_bits = vm_flags & VM_ACCESS_FLAGS;
+ vm_flags_t vm_prot_bits = vm_flags & VM_ACCESS_FLAGS;
struct sgx_encl_page *entry;
entry = xa_load(&encl->page_array, PFN_DOWN(addr));
diff --git a/arch/x86/kernel/cpu/sgx/encl.h b/arch/x86/kernel/cpu/sgx/encl.h
index 8ff47f6652b9..0e0b97e91905 100644
--- a/arch/x86/kernel/cpu/sgx/encl.h
+++ b/arch/x86/kernel/cpu/sgx/encl.h
@@ -27,7 +27,7 @@
struct sgx_encl_page {
unsigned long desc;
- unsigned long vm_max_prot_bits:8;
+ vm_flags_t vm_max_prot_bits:8;
enum sgx_page_type type:16;
struct sgx_epc_page *epc_page;
struct sgx_encl *encl;
--
2.34.1
On Thu, Jan 22, 2026 at 09:36:33PM +0800, Wentong Tian wrote:
> The vm_flags_t type is the dedicated type for virtual memory flags.
> Architecture and driver code should use this type instead of assuming
> vm_flags is an unsigned long, as the underlying type may change in the
> future.
>
> This follows the cleanup in commit d75fa3c94750 ("mm: update
> architecture and driver code to use vm_flags_t") by converting the
> remaining vm_prot_bits usage in SGX code. Also, update the vm_max_prot_bits
> type in struct sgx_encl_page to vm_flags_t for consistency.
>
> No functional change intended.
>
> Signed-off-by: Wentong Tian <tianwentong2000@gmail.com>
> ---
> v2:
> - Also convert the type of vm_max_prot_bits in struct sgx_encl_page
> to vm_flags_t, as suggested.
>
> arch/x86/kernel/cpu/sgx/encl.c | 2 +-
> arch/x86/kernel/cpu/sgx/encl.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
> index cf149b9f4916..814edcde225d 100644
> --- a/arch/x86/kernel/cpu/sgx/encl.c
> +++ b/arch/x86/kernel/cpu/sgx/encl.c
> @@ -281,7 +281,7 @@ static struct sgx_encl_page *sgx_encl_load_page_in_vma(struct sgx_encl *encl,
> unsigned long addr,
> vm_flags_t vm_flags)
> {
> - unsigned long vm_prot_bits = vm_flags & VM_ACCESS_FLAGS;
> + vm_flags_t vm_prot_bits = vm_flags & VM_ACCESS_FLAGS;
> struct sgx_encl_page *entry;
>
> entry = xa_load(&encl->page_array, PFN_DOWN(addr));
> diff --git a/arch/x86/kernel/cpu/sgx/encl.h b/arch/x86/kernel/cpu/sgx/encl.h
> index 8ff47f6652b9..0e0b97e91905 100644
> --- a/arch/x86/kernel/cpu/sgx/encl.h
> +++ b/arch/x86/kernel/cpu/sgx/encl.h
> @@ -27,7 +27,7 @@
>
> struct sgx_encl_page {
> unsigned long desc;
> - unsigned long vm_max_prot_bits:8;
> + vm_flags_t vm_max_prot_bits:8;
> enum sgx_page_type type:16;
> struct sgx_epc_page *epc_page;
> struct sgx_encl *encl;
OK, I missed the remark from Kai, but it is acceptable.
> --
> 2.34.1
>
So again:
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
On Thu, 2026-01-22 at 21:36 +0800, Wentong Tian wrote:
> The vm_flags_t type is the dedicated type for virtual memory flags.
> Architecture and driver code should use this type instead of assuming
> vm_flags is an unsigned long, as the underlying type may change in the
> future.
>
> This follows the cleanup in commit d75fa3c94750 ("mm: update
> architecture and driver code to use vm_flags_t") by converting the
> remaining vm_prot_bits usage in SGX code. Also, update the vm_max_prot_bits
> type in struct sgx_encl_page to vm_flags_t for consistency.
>
> No functional change intended.
>
> Signed-off-by: Wentong Tian <tianwentong2000@gmail.com>
> ---
> v2:
> - Also convert the type of vm_max_prot_bits in struct sgx_encl_page
> to vm_flags_t, as suggested.
Hmm I was actually just pointing out, but not suggesting, since I am not
sure (honestly).
Back to technical:
Gcc doc says:
A structure field declaration with an integer type can specify the
number of bits the field should occupy. We call that a bit field.
With vm_flags_t I think "theoretically" it could stop being integer type
someday. But I guess the advantage is when someone does that that can
trigger build error here (so that we can be aware) which perhaps isn't a
bad thing?
Sorry about that, I'll make sure to reply to the list. On Thu, Jan 23, 2026 at 4:57 AM Huang, Kai <kai.huang@intel.com> wrote: > Hmm I was actually just pointing out, but not suggesting, since I am not > sure (honestly). Sorry for the misunderstanding. > With vm_flags_t I think "theoretically" it could stop being integer type > someday. But I guess the advantage is when someone does that that can > trigger build error here (so that we can be aware) which perhaps isn't a > bad thing? You're right, the build error would be a useful early warning if vm_flags_t ever becomes incompatible. I'm fine either way, let me know if you'd prefer keeping unsigned long and I'll send a v3.
> > With vm_flags_t I think "theoretically" it could stop being integer type > > someday. But I guess the advantage is when someone does that that can > > trigger build error here (so that we can be aware) which perhaps isn't a > > bad thing? > You're right, the build error would be a useful early warning if > vm_flags_t ever becomes incompatible. > Agreed. It's what type safety means IMHO. > I'm fine either way, let me know > if you'd prefer keeping > unsigned long and I'll send a v3. It's up to maintainer(s), but v2 makes sense to me, so: Acked-by: Kai Huang <kai.huang@intel.com>
© 2016 - 2026 Red Hat, Inc.