On Tue, Nov 03, 2020 at 07:14:07PM +0100, Greg KH wrote: > On Tue, Nov 03, 2020 at 09:53:36AM -0800, Ira Weiny wrote: > > On Tue, Nov 03, 2020 at 07:50:24AM +0100, Greg KH wrote: > > > On Mon, Nov 02, 2020 at 12:53:15PM -0800, [email protected] wrote: > > > > From: Fenghua Yu <[email protected]> > > > > > > > > [snip] > > > > > > diff --git a/include/linux/pkeys.h b/include/linux/pkeys.h > > > > index 2955ba976048..0959a4c0ca64 100644 > > > > --- a/include/linux/pkeys.h > > > > +++ b/include/linux/pkeys.h > > > > @@ -50,4 +50,28 @@ static inline void copy_init_pkru_to_fpregs(void) > > > > > > > > #endif /* ! CONFIG_ARCH_HAS_PKEYS */ > > > > > > > > +#define PKS_FLAG_EXCLUSIVE 0x00 > > > > + > > > > +#ifndef CONFIG_ARCH_HAS_SUPERVISOR_PKEYS > > > > +static inline int pks_key_alloc(const char * const pkey_user, int > > > > flags) > > > > +{ > > > > + return -EOPNOTSUPP; > > > > +} > > > > +static inline void pks_key_free(int pkey) > > > > +{ > > > > +} > > > > +static inline void pks_mk_noaccess(int pkey) > > > > +{ > > > > + WARN_ON_ONCE(1); > > > > > > So for panic-on-warn systems, this is ok to reboot the box? > > > > I would not expect this to reboot the box no. But it is a violation of the > > API > > contract. If pky_key_alloc() returns an error calling any of the other > > functions is an error. > > > > > > > > Are you sure, that feels odd... > > > > It does feel odd and downright wrong... But there are a lot of > > WARN_ON_ONCE's > > out there to catch this type of internal programming error. Is > > panic-on-warn > > commonly used? > > Yes it is, and we are trying to recover from that as it is something > that you should recover from. Properly handle the error and move on.
Sorry, I did not know that... Ok I'll look at the series because I probably have others I need to change. Thanks, Ira
