pkeys: Remove easily triggered WARN

pkeys: Remove easily triggered WARN

[Dave Jones]

This easy-to-trigger warning shows up instantly when running
Trinity on a kernel with CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS disabled.

At most this should have been a printk, but the -EINVAL alone should be more
than adequate indicator that something isn't available.

Signed-off-by: Dave Jones <davej@codemonkey.org.uk>

diff --git a/include/linux/pkeys.h b/include/linux/pkeys.h
index e4c08c1ff0c5..a1bacf1150b2 100644
--- a/include/linux/pkeys.h
+++ b/include/linux/pkeys.h
@@ -25,7 +25,6 @@ static inline int mm_pkey_alloc(struct mm_struct *mm)
 
 static inline int mm_pkey_free(struct mm_struct *mm, int pkey)
 {
-	WARN_ONCE(1, "free of protection key when disabled");
 	return -EINVAL;
 }
 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

pkeys: Remove easily triggered WARN

[Dave Jones]

This easy-to-trigger warning shows up instantly when running
Trinity on a kernel with CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS disabled.

At most this should have been a printk, but the -EINVAL alone should be more
than adequate indicator that something isn't available.

Signed-off-by: Dave Jones <davej@codemonkey.org.uk>

diff --git a/include/linux/pkeys.h b/include/linux/pkeys.h
index e4c08c1ff0c5..a1bacf1150b2 100644
--- a/include/linux/pkeys.h
+++ b/include/linux/pkeys.h
@@ -25,7 +25,6 @@ static inline int mm_pkey_alloc(struct mm_struct *mm)
 
 static inline int mm_pkey_free(struct mm_struct *mm, int pkey)
 {
-	WARN_ONCE(1, "free of protection key when disabled");
 	return -EINVAL;
 }
 

Re: pkeys: Remove easily triggered WARN

[Dave Hansen]

On 10/14/2016 11:26 AM, Dave Jones wrote:
> This easy-to-trigger warning shows up instantly when running
> Trinity on a kernel with CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS disabled.
> 
> At most this should have been a printk, but the -EINVAL alone should be more
> than adequate indicator that something isn't available.

Urg, thanks for the patch.  It's obviously correct, of course.

Acked-by: Dave Hansen <dave.hansen@intel.com>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: pkeys: Remove easily triggered WARN

[Dave Hansen]

On 10/14/2016 11:26 AM, Dave Jones wrote:
> This easy-to-trigger warning shows up instantly when running
> Trinity on a kernel with CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS disabled.
> 
> At most this should have been a printk, but the -EINVAL alone should be more
> than adequate indicator that something isn't available.

Urg, thanks for the patch.  It's obviously correct, of course.

Acked-by: Dave Hansen <dave.hansen@intel.com>

Re: pkeys: Remove easily triggered WARN

[Heiko Carstens]

On Fri, Oct 14, 2016 at 02:26:24PM -0400, Dave Jones wrote:
> This easy-to-trigger warning shows up instantly when running
> Trinity on a kernel with CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS disabled.
> 
> At most this should have been a printk, but the -EINVAL alone should be more
> than adequate indicator that something isn't available.
> 
> Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
> 
> diff --git a/include/linux/pkeys.h b/include/linux/pkeys.h
> index e4c08c1ff0c5..a1bacf1150b2 100644
> --- a/include/linux/pkeys.h
> +++ b/include/linux/pkeys.h
> @@ -25,7 +25,6 @@ static inline int mm_pkey_alloc(struct mm_struct *mm)
>  
>  static inline int mm_pkey_free(struct mm_struct *mm, int pkey)
>  {
> -	WARN_ONCE(1, "free of protection key when disabled");
>  	return -EINVAL;
>  }

FWIW, are all architectures supposed to wire these new system calls up?

I decided to ignore these on s390 since we can't make any sane use of
them. However mips has them already wired up.

The only difference on s390 (and any other architecture without memory
protection keys with x86 like semantics) would be that pkey_alloc/pkey_free
will return -EINVAL instead of -ENOSYS and that we have a new mprotect
wrapper called pkey_mprotect, if being called with a pkey parameter of -1.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: pkeys: Remove easily triggered WARN

[Heiko Carstens]

On Fri, Oct 14, 2016 at 02:26:24PM -0400, Dave Jones wrote:
> This easy-to-trigger warning shows up instantly when running
> Trinity on a kernel with CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS disabled.
> 
> At most this should have been a printk, but the -EINVAL alone should be more
> than adequate indicator that something isn't available.
> 
> Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
> 
> diff --git a/include/linux/pkeys.h b/include/linux/pkeys.h
> index e4c08c1ff0c5..a1bacf1150b2 100644
> --- a/include/linux/pkeys.h
> +++ b/include/linux/pkeys.h
> @@ -25,7 +25,6 @@ static inline int mm_pkey_alloc(struct mm_struct *mm)
>  
>  static inline int mm_pkey_free(struct mm_struct *mm, int pkey)
>  {
> -	WARN_ONCE(1, "free of protection key when disabled");
>  	return -EINVAL;
>  }

FWIW, are all architectures supposed to wire these new system calls up?

I decided to ignore these on s390 since we can't make any sane use of
them. However mips has them already wired up.

The only difference on s390 (and any other architecture without memory
protection keys with x86 like semantics) would be that pkey_alloc/pkey_free
will return -EINVAL instead of -ENOSYS and that we have a new mprotect
wrapper called pkey_mprotect, if being called with a pkey parameter of -1.

Re: pkeys: Remove easily triggered WARN

[Heiko Carstens]

On Mon, Oct 17, 2016 at 09:16:48AM +0200, Heiko Carstens wrote:
> On Fri, Oct 14, 2016 at 02:26:24PM -0400, Dave Jones wrote:
> > This easy-to-trigger warning shows up instantly when running
> > Trinity on a kernel with CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS disabled.
> > 
> > At most this should have been a printk, but the -EINVAL alone should be more
> > than adequate indicator that something isn't available.
> > 
> > Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
> > 
> > diff --git a/include/linux/pkeys.h b/include/linux/pkeys.h
> > index e4c08c1ff0c5..a1bacf1150b2 100644
> > --- a/include/linux/pkeys.h
> > +++ b/include/linux/pkeys.h
> > @@ -25,7 +25,6 @@ static inline int mm_pkey_alloc(struct mm_struct *mm)
> >  
> >  static inline int mm_pkey_free(struct mm_struct *mm, int pkey)
> >  {
> > -	WARN_ONCE(1, "free of protection key when disabled");
> >  	return -EINVAL;
> >  }
> 
> FWIW, are all architectures supposed to wire these new system calls up?
> 
> I decided to ignore these on s390 since we can't make any sane use of
> them. However mips has them already wired up.
> 
> The only difference on s390 (and any other architecture without memory
> protection keys with x86 like semantics) would be that pkey_alloc/pkey_free
> will return -EINVAL instead of -ENOSYS and that we have a new mprotect
> wrapper called pkey_mprotect, if being called with a pkey parameter of -1.

What I wrote is of course not correct... 

There can't be any -ENOSYS if the system call isn't wired up, since the
system call number hasn't been allocated at all for an architecture.

But the question remains: should these be wired up on all architectures?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: pkeys: Remove easily triggered WARN

[Heiko Carstens]

On Mon, Oct 17, 2016 at 09:16:48AM +0200, Heiko Carstens wrote:
> On Fri, Oct 14, 2016 at 02:26:24PM -0400, Dave Jones wrote:
> > This easy-to-trigger warning shows up instantly when running
> > Trinity on a kernel with CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS disabled.
> > 
> > At most this should have been a printk, but the -EINVAL alone should be more
> > than adequate indicator that something isn't available.
> > 
> > Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
> > 
> > diff --git a/include/linux/pkeys.h b/include/linux/pkeys.h
> > index e4c08c1ff0c5..a1bacf1150b2 100644
> > --- a/include/linux/pkeys.h
> > +++ b/include/linux/pkeys.h
> > @@ -25,7 +25,6 @@ static inline int mm_pkey_alloc(struct mm_struct *mm)
> >  
> >  static inline int mm_pkey_free(struct mm_struct *mm, int pkey)
> >  {
> > -	WARN_ONCE(1, "free of protection key when disabled");
> >  	return -EINVAL;
> >  }
> 
> FWIW, are all architectures supposed to wire these new system calls up?
> 
> I decided to ignore these on s390 since we can't make any sane use of
> them. However mips has them already wired up.
> 
> The only difference on s390 (and any other architecture without memory
> protection keys with x86 like semantics) would be that pkey_alloc/pkey_free
> will return -EINVAL instead of -ENOSYS and that we have a new mprotect
> wrapper called pkey_mprotect, if being called with a pkey parameter of -1.

What I wrote is of course not correct... 

There can't be any -ENOSYS if the system call isn't wired up, since the
system call number hasn't been allocated at all for an architecture.

But the question remains: should these be wired up on all architectures?