All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: James Cowgill <james.cowgill@mips.com>
Cc: stable@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: Apply "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stable trees
Date: Thu, 16 Nov 2017 13:12:05 +0000	[thread overview]
Message-ID: <20171116131205.GA6447@kroah.com> (raw)
In-Reply-To: <26f91532-a424-5449-bf5f-5682e47fb1c4@mips.com>

On Thu, Nov 16, 2017 at 11:57:27AM +0000, James Cowgill wrote:
> Hi,
> 
> Is it possible to apply this commit to the stable trees before 4.12?
> 
> commit 47b2c3fff4932e6fc17ce13d51a43c6969714e20
> Author: Bilal Amarni <bilal.amarni@gmail.com>
> Date:   Thu Jun 8 14:47:26 2017 +0100
> 
>     security/keys: add CONFIG_KEYS_COMPAT to Kconfig
> 
> In commit 20f06ed9f61a ("KEYS: 64-bit MIPS needs to use
> compat_sys_keyctl for 32-bit userspace"), the keyctl syscall for 32-bit
> MIPS was "fixed" to point at compat_sys_keyctl instead of sys_keyctl.
> Unfortunately this caused the syscall to always return ENOSYS because
> CONFIG_KEYS_COMPAT was not enabled on MIPS. Instead of fixing this by
> manually by enabling KEYS_COMPAT in the MIPS Kconfig, I think applying
> the above commit is a better.

Sounds resonable, but how far back should it go?  4.9 makes sense, but
stuff older than that?  4.4?  4.1?  3.16?

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: James Cowgill <james.cowgill@mips.com>
Cc: stable@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: Apply "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stable trees
Date: Thu, 16 Nov 2017 14:12:05 +0100	[thread overview]
Message-ID: <20171116131205.GA6447@kroah.com> (raw)
In-Reply-To: <26f91532-a424-5449-bf5f-5682e47fb1c4@mips.com>

On Thu, Nov 16, 2017 at 11:57:27AM +0000, James Cowgill wrote:
> Hi,
> 
> Is it possible to apply this commit to the stable trees before 4.12?
> 
> commit 47b2c3fff4932e6fc17ce13d51a43c6969714e20
> Author: Bilal Amarni <bilal.amarni@gmail.com>
> Date:   Thu Jun 8 14:47:26 2017 +0100
> 
>     security/keys: add CONFIG_KEYS_COMPAT to Kconfig
> 
> In commit 20f06ed9f61a ("KEYS: 64-bit MIPS needs to use
> compat_sys_keyctl for 32-bit userspace"), the keyctl syscall for 32-bit
> MIPS was "fixed" to point at compat_sys_keyctl instead of sys_keyctl.
> Unfortunately this caused the syscall to always return ENOSYS because
> CONFIG_KEYS_COMPAT was not enabled on MIPS. Instead of fixing this by
> manually by enabling KEYS_COMPAT in the MIPS Kconfig, I think applying
> the above commit is a better.

Sounds resonable, but how far back should it go?  4.9 makes sense, but
stuff older than that?  4.4?  4.1?  3.16?

thanks,

greg k-h

  reply	other threads:[~2017-11-16 13:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-16 11:57 Apply "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stable trees James Cowgill
2017-11-16 11:57 ` James Cowgill
2017-11-16 13:12 ` Greg KH [this message]
2017-11-16 13:12   ` Greg KH
2017-11-16 14:10   ` James Cowgill
2017-11-16 14:10     ` James Cowgill
2017-11-16 16:33     ` Greg KH
2017-11-16 16:33       ` Greg KH

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=20171116131205.GA6447@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=james.cowgill@mips.com \
    --cc=keyrings@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /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.