Re: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs

2017-10-06 Thread Stafford Horne
Hello,

Nice read, see some comments below

On Fri, Oct 06, 2017 at 11:34:30AM -0400, Steven Rostedt wrote:
> On Fri, 6 Oct 2017 13:49:59 +0900
> Masami Hiramatsu  wrote:
> 
> > Steve, could you write a documentation how to use ftrace callback?
> > I think I should update the Documentation/kprobes.txt so that jprobe
> > user can easily migrate on that.
> 
> I decided to do this now. Here's a first draft. What do you think?
> 
> -- Steve
> 
>   Using ftrace to hook to functions
>   =
> 
> Copyright 2017 VMware Inc.
>Author:   Steven Rostedt 
>   License:   The GNU Free Documentation License, Version 1.2
>(dual licensed under the GPL v2)
> 
> Written for: 4.14
> 
> Introduction
> 
> 
> The ftrace infrastructure was originially created to attach hooks to the
> beginning of functions in order to record and trace the flow of the kernel.
> But hooks to the start of a function can have other use cases. Either
> for live kernel patching, or for security monitoring. This document describes
> how to use ftrace to implement your own function hooks.
> 
> 
> The ftrace context
> ==
> 
> WARNING: The ability to add a callback to almost any function within the
> kernel comes with risks. A callback can be called from any context
> (normal, softirq, irq, and NMI). Callbacks can also be called just before
> going to idle, during CPU bring up and takedown, or going to user space.
> This requires extra care to what can be done inside a callback. A callback
> can be called outside the protective scope of RCU.
> 
> The ftrace infrastructure has some protections agains recursions and RCU
> but one must still be very careful how they use the callbacks.
> 
> 
> The ftrace_ops structure
> 
> 
> To register a function callback, a ftrace_ops is required. This structure
> is used to tell ftrace what function should be called as the callback
> as well as what protections the callback will perform and not require
> ftrace to handle.
> 
> There are only two fields that are needed to be set when registering
> an ftrace_ops with ftrace. The rest should be NULL.
> 
> struct ftrace_ops ops = {
>.func  = my_callback_func,
>.flags = MY_FTRACE_FLAGS
>.private   = any_private_data_structure,
> };
> 
> Both .flags and .private are optional. Only .func is required.
> 
> To enable tracing call:
> 
>   register_ftrace_function();

Maybe it would help to have a small section on 'The register function'
below to answer?

Is it possible to make changes to the filter after calling
register_ftrace_function()?  Or do you need to call
register_ftrace_function() again?

> To disable tracing call:
> 
>   unregister_ftrace_function(@ops);
> 
> 
> The callback function
> =
> 
> The prototype of the callback function is as follows (as of v4.14):
> 
>  void callback_func(unsigned long ip, unsigned long parent_ip,
>   struct ftrace_ops *op, struct pt_regs *regs);
> 
> @ip - This is the instruction pointer of the function that is being traced.
>   (where the fentry or mcount is within the function)
> 
> @parent_ip - This is the instruction pointer of the function that called the
>   the function being traced (where the call of the function occurred).
> 
> @op - This is a pointer to ftrace_ops that was used to register the callback.
>   This can be used to pass data to the callback via the private pointer.
> 
> @regs - If the FTRACE_OPS_FL_SAVE_REGS or FTRACE_OPS_FL_SAVE_REGS_IF_SUPPORTED
>   flags are set in the ftrace_ops structure, then this will be pointing
>   to the pt_regs structure like it would be if an breakpoint was placed
>   at the start of the function where ftrace was tracing. Otherwise it
>   either contains garbage, or NULL.
> 
> 
> The ftrace FLAGS
> 
> 
> The ftrace_ops flags are all defined and documented in include/linux/ftrace.h.
> Some of the flags are used for internal infrastructure of ftrace, but the
> ones that users should be aware of are the following:
> 
> (All of these are prefixed with FTRACE_OPS_FL_)
> 
> PER_CPU - When set, the callback can be enabled or disabled per cpu with the
>   following functions:
> 
>   void ftrace_function_local_enable(struct ftrace_ops *ops);
>   void ftrace_function_local_disable(struct ftrace_ops *ops);
> 
>   These two functions must be called with preemption disabled.
> 
> SAVE_REGS - If the callback requires reading or modifying the pt_regs
>   passed to the callback, then it must set this flag. Registering
>   a ftrace_ops with this flag set on an architecture that does not
>   support passing of pt_regs to the callback, will fail.
> 
> SAVE_REGS_IF_SUPPORTED - Similar to SAVE_REGS but the registering of a
>   ftrace_ops on an architecture that 

Re: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs

2017-10-06 Thread Stafford Horne
Hello,

Nice read, see some comments below

On Fri, Oct 06, 2017 at 11:34:30AM -0400, Steven Rostedt wrote:
> On Fri, 6 Oct 2017 13:49:59 +0900
> Masami Hiramatsu  wrote:
> 
> > Steve, could you write a documentation how to use ftrace callback?
> > I think I should update the Documentation/kprobes.txt so that jprobe
> > user can easily migrate on that.
> 
> I decided to do this now. Here's a first draft. What do you think?
> 
> -- Steve
> 
>   Using ftrace to hook to functions
>   =
> 
> Copyright 2017 VMware Inc.
>Author:   Steven Rostedt 
>   License:   The GNU Free Documentation License, Version 1.2
>(dual licensed under the GPL v2)
> 
> Written for: 4.14
> 
> Introduction
> 
> 
> The ftrace infrastructure was originially created to attach hooks to the
> beginning of functions in order to record and trace the flow of the kernel.
> But hooks to the start of a function can have other use cases. Either
> for live kernel patching, or for security monitoring. This document describes
> how to use ftrace to implement your own function hooks.
> 
> 
> The ftrace context
> ==
> 
> WARNING: The ability to add a callback to almost any function within the
> kernel comes with risks. A callback can be called from any context
> (normal, softirq, irq, and NMI). Callbacks can also be called just before
> going to idle, during CPU bring up and takedown, or going to user space.
> This requires extra care to what can be done inside a callback. A callback
> can be called outside the protective scope of RCU.
> 
> The ftrace infrastructure has some protections agains recursions and RCU
> but one must still be very careful how they use the callbacks.
> 
> 
> The ftrace_ops structure
> 
> 
> To register a function callback, a ftrace_ops is required. This structure
> is used to tell ftrace what function should be called as the callback
> as well as what protections the callback will perform and not require
> ftrace to handle.
> 
> There are only two fields that are needed to be set when registering
> an ftrace_ops with ftrace. The rest should be NULL.
> 
> struct ftrace_ops ops = {
>.func  = my_callback_func,
>.flags = MY_FTRACE_FLAGS
>.private   = any_private_data_structure,
> };
> 
> Both .flags and .private are optional. Only .func is required.
> 
> To enable tracing call:
> 
>   register_ftrace_function();

Maybe it would help to have a small section on 'The register function'
below to answer?

Is it possible to make changes to the filter after calling
register_ftrace_function()?  Or do you need to call
register_ftrace_function() again?

> To disable tracing call:
> 
>   unregister_ftrace_function(@ops);
> 
> 
> The callback function
> =
> 
> The prototype of the callback function is as follows (as of v4.14):
> 
>  void callback_func(unsigned long ip, unsigned long parent_ip,
>   struct ftrace_ops *op, struct pt_regs *regs);
> 
> @ip - This is the instruction pointer of the function that is being traced.
>   (where the fentry or mcount is within the function)
> 
> @parent_ip - This is the instruction pointer of the function that called the
>   the function being traced (where the call of the function occurred).
> 
> @op - This is a pointer to ftrace_ops that was used to register the callback.
>   This can be used to pass data to the callback via the private pointer.
> 
> @regs - If the FTRACE_OPS_FL_SAVE_REGS or FTRACE_OPS_FL_SAVE_REGS_IF_SUPPORTED
>   flags are set in the ftrace_ops structure, then this will be pointing
>   to the pt_regs structure like it would be if an breakpoint was placed
>   at the start of the function where ftrace was tracing. Otherwise it
>   either contains garbage, or NULL.
> 
> 
> The ftrace FLAGS
> 
> 
> The ftrace_ops flags are all defined and documented in include/linux/ftrace.h.
> Some of the flags are used for internal infrastructure of ftrace, but the
> ones that users should be aware of are the following:
> 
> (All of these are prefixed with FTRACE_OPS_FL_)
> 
> PER_CPU - When set, the callback can be enabled or disabled per cpu with the
>   following functions:
> 
>   void ftrace_function_local_enable(struct ftrace_ops *ops);
>   void ftrace_function_local_disable(struct ftrace_ops *ops);
> 
>   These two functions must be called with preemption disabled.
> 
> SAVE_REGS - If the callback requires reading or modifying the pt_regs
>   passed to the callback, then it must set this flag. Registering
>   a ftrace_ops with this flag set on an architecture that does not
>   support passing of pt_regs to the callback, will fail.
> 
> SAVE_REGS_IF_SUPPORTED - Similar to SAVE_REGS but the registering of a
>   ftrace_ops on an architecture that does not support passing of regs
>   will 

Re: [PATCH] mwifiex: Use put_unaligned_le32

2017-10-06 Thread kbuild test robot
Hi Himanshu,

[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.14-rc3 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Himanshu-Jha/mwifiex-Use-put_unaligned_le32/20171007-095017
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: openrisc-allyesconfig (attached as .config)
compiler: or1k-linux-gcc (GCC) 5.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   In file included from arch/openrisc/include/asm/unaligned.h:42:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_memmove.h:6:19: error: redefinition of 
>> 'get_unaligned_be16'
static inline u16 get_unaligned_be16(const void *p)
  ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:22:28: note: previous definition of 
'get_unaligned_be16' was here
static __always_inline u16 get_unaligned_be16(const void *p)
   ^
   In file included from arch/openrisc/include/asm/unaligned.h:42:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_memmove.h:11:19: error: redefinition of 
>> 'get_unaligned_be32'
static inline u32 get_unaligned_be32(const void *p)
  ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:27:28: note: previous definition of 
'get_unaligned_be32' was here
static __always_inline u32 get_unaligned_be32(const void *p)
   ^
   In file included from arch/openrisc/include/asm/unaligned.h:42:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_memmove.h:16:19: error: redefinition of 
>> 'get_unaligned_be64'
static inline u64 get_unaligned_be64(const void *p)
  ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:32:28: note: previous definition of 
'get_unaligned_be64' was here
static __always_inline u64 get_unaligned_be64(const void *p)
   ^
   In file included from arch/openrisc/include/asm/unaligned.h:42:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_memmove.h:21:20: error: redefinition of 
>> 'put_unaligned_be16'
static inline void put_unaligned_be16(u16 val, void *p)
   ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:52:29: note: previous definition of 
'put_unaligned_be16' was here
static __always_inline void put_unaligned_be16(u16 val, void *p)
^
   In file included from arch/openrisc/include/asm/unaligned.h:42:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_memmove.h:26:20: error: redefinition of 
>> 'put_unaligned_be32'
static inline void put_unaligned_be32(u32 val, void *p)
   ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:57:29: note: previous definition of 
'put_unaligned_be32' was here
static __always_inline void put_unaligned_be32(u32 val, void *p)
^
   In file included from arch/openrisc/include/asm/unaligned.h:42:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from 

Re: [PATCH] mwifiex: Use put_unaligned_le32

2017-10-06 Thread kbuild test robot
Hi Himanshu,

[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.14-rc3 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Himanshu-Jha/mwifiex-Use-put_unaligned_le32/20171007-095017
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: openrisc-allyesconfig (attached as .config)
compiler: or1k-linux-gcc (GCC) 5.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   In file included from arch/openrisc/include/asm/unaligned.h:42:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_memmove.h:6:19: error: redefinition of 
>> 'get_unaligned_be16'
static inline u16 get_unaligned_be16(const void *p)
  ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:22:28: note: previous definition of 
'get_unaligned_be16' was here
static __always_inline u16 get_unaligned_be16(const void *p)
   ^
   In file included from arch/openrisc/include/asm/unaligned.h:42:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_memmove.h:11:19: error: redefinition of 
>> 'get_unaligned_be32'
static inline u32 get_unaligned_be32(const void *p)
  ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:27:28: note: previous definition of 
'get_unaligned_be32' was here
static __always_inline u32 get_unaligned_be32(const void *p)
   ^
   In file included from arch/openrisc/include/asm/unaligned.h:42:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_memmove.h:16:19: error: redefinition of 
>> 'get_unaligned_be64'
static inline u64 get_unaligned_be64(const void *p)
  ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:32:28: note: previous definition of 
'get_unaligned_be64' was here
static __always_inline u64 get_unaligned_be64(const void *p)
   ^
   In file included from arch/openrisc/include/asm/unaligned.h:42:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_memmove.h:21:20: error: redefinition of 
>> 'put_unaligned_be16'
static inline void put_unaligned_be16(u16 val, void *p)
   ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:52:29: note: previous definition of 
'put_unaligned_be16' was here
static __always_inline void put_unaligned_be16(u16 val, void *p)
^
   In file included from arch/openrisc/include/asm/unaligned.h:42:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_memmove.h:26:20: error: redefinition of 
>> 'put_unaligned_be32'
static inline void put_unaligned_be32(u32 val, void *p)
   ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:57:29: note: previous definition of 
'put_unaligned_be32' was here
static __always_inline void put_unaligned_be32(u32 val, void *p)
^
   In file included from arch/openrisc/include/asm/unaligned.h:42:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from 

Re: [PATCH] MAINTAINERS: Update the UV architecture to current addresses

2017-10-06 Thread Joe Perches
On Fri, 2017-10-06 at 15:36 -0500, Nathan Zimmer wrote:
> After the buyout/merger our @sgi.com address are slowing being less useful.
> So make sure we are can be contacted properly.

This seems more like a new entry so the commit
message seems wrong.

> Signed-off-by: Nathan Zimmer 
> Signed-off-by: Mike Travis 
> ---
>  MAINTAINERS | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cc42c83..8581e18 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14161,6 +14161,16 @@ F:   include/linux/uuid.h
>  F:   include/uapi/linux/uuid.h
>  S:   Maintained
>  
> +UV PLATFORM
> +M: Mike Travis 
> +M: Nathan Zimmer 
> +M: uv_ker...@groups.ext.hpe.com
> +S: Supported
> +F: arch/x86/kernel/apic/x2apic_uv_x.c
> +F: arch/x86/platform/uv/*
> +F: arch/x86/include/asm/uv/*

And Most likmely, these 2 should not have the *

> +F: drivers/char/uv_mmtimer.c
> +
>  UVESAFB DRIVER
>  M:   Michal Januszewski 
>  L:   linux-fb...@vger.kernel.org


Re: [PATCH] MAINTAINERS: Update the UV architecture to current addresses

2017-10-06 Thread Joe Perches
On Fri, 2017-10-06 at 15:36 -0500, Nathan Zimmer wrote:
> After the buyout/merger our @sgi.com address are slowing being less useful.
> So make sure we are can be contacted properly.

This seems more like a new entry so the commit
message seems wrong.

> Signed-off-by: Nathan Zimmer 
> Signed-off-by: Mike Travis 
> ---
>  MAINTAINERS | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cc42c83..8581e18 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14161,6 +14161,16 @@ F:   include/linux/uuid.h
>  F:   include/uapi/linux/uuid.h
>  S:   Maintained
>  
> +UV PLATFORM
> +M: Mike Travis 
> +M: Nathan Zimmer 
> +M: uv_ker...@groups.ext.hpe.com
> +S: Supported
> +F: arch/x86/kernel/apic/x2apic_uv_x.c
> +F: arch/x86/platform/uv/*
> +F: arch/x86/include/asm/uv/*

And Most likmely, these 2 should not have the *

> +F: drivers/char/uv_mmtimer.c
> +
>  UVESAFB DRIVER
>  M:   Michal Januszewski 
>  L:   linux-fb...@vger.kernel.org


[PATCH] irqchip/gicv3-its: Add missing changes to support 52bit physical address

2017-10-06 Thread Shanker Donthineni
The current ITS driver works fine as long as normal memory and GICR
regions are located within the lower 48bit (>=0 && <2^48) physical
address space. Some of the registers GICR_PEND/PROP, GICR_VPEND/VPROP
and GITS_CBASER are handled properly but not all when configuring
the hardware with 52bit physical address.

This patch does the following changes to support 52bit PA.
  -Handle 52bit PA in GITS_BASERn.
  -Fix ITT_addr width to 52bits, bits[51:8].
  -Fix RDbase width to 52bits, bits[51:16].
  -Fix VPT_addr width to 52bits, bits[51:16].

Definition of the GITS_BASERn register when ITS PageSize is 64KB:
 -Bits[47:16] of the register provide bits[47:16] of the table PA.
 -Bits[15:12] of the register provide bits[51:48] of the table PA.
 -Bits[15:00] of the base physical address are 0.

Signed-off-by: Shanker Donthineni 
---
 drivers/irqchip/irq-gic-v3-its.c   | 24 +++-
 include/linux/irqchip/arm-gic-v3.h |  3 +++
 2 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index e8d8934..e52c0da 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -308,7 +308,7 @@ static void its_encode_size(struct its_cmd_block *cmd, u8 
size)
 
 static void its_encode_itt(struct its_cmd_block *cmd, u64 itt_addr)
 {
-   its_mask_encode(>raw_cmd[2], itt_addr >> 8, 50, 8);
+   its_mask_encode(>raw_cmd[2], itt_addr >> 8, 51, 8);
 }
 
 static void its_encode_valid(struct its_cmd_block *cmd, int valid)
@@ -318,7 +318,7 @@ static void its_encode_valid(struct its_cmd_block *cmd, int 
valid)
 
 static void its_encode_target(struct its_cmd_block *cmd, u64 target_addr)
 {
-   its_mask_encode(>raw_cmd[2], target_addr >> 16, 50, 16);
+   its_mask_encode(>raw_cmd[2], target_addr >> 16, 51, 16);
 }
 
 static void its_encode_collection(struct its_cmd_block *cmd, u16 col)
@@ -358,7 +358,7 @@ static void its_encode_its_list(struct its_cmd_block *cmd, 
u16 its_list)
 
 static void its_encode_vpt_addr(struct its_cmd_block *cmd, u64 vpt_pa)
 {
-   its_mask_encode(>raw_cmd[3], vpt_pa >> 16, 50, 16);
+   its_mask_encode(>raw_cmd[3], vpt_pa >> 16, 51, 16);
 }
 
 static void its_encode_vpt_size(struct its_cmd_block *cmd, u8 vpt_size)
@@ -1478,9 +1478,9 @@ static int its_setup_baser(struct its_node *its, struct 
its_baser *baser,
u64 val = its_read_baser(its, baser);
u64 esz = GITS_BASER_ENTRY_SIZE(val);
u64 type = GITS_BASER_TYPE(val);
+   u64 baser_phys, tmp;
u32 alloc_pages;
void *base;
-   u64 tmp;
 
 retry_alloc_baser:
alloc_pages = (PAGE_ORDER_TO_SIZE(order) / psz);
@@ -1496,8 +1496,22 @@ static int its_setup_baser(struct its_node *its, struct 
its_baser *baser,
if (!base)
return -ENOMEM;
 
+   baser_phys = virt_to_phys(base);
+
+   /* Check if the physical address of the memory is above 48bits */
+   if (baser_phys & (~GITS_BASER_PHYS_MASK)) {
+   /* 52bit PA is supported only when PageSize=64K */
+   if (psz != SZ_64K) {
+   free_pages((unsigned long)base, order);
+   return -EFAULT;
+   }
+
+   /* Convert 52bit PA to 48bit field */
+   baser_phys = GITS_BASER_64K_PHYS(baser_phys);
+   }
+
 retry_baser:
-   val = (virt_to_phys(base)|
+   val = (baser_phys|
(type << GITS_BASER_TYPE_SHIFT)  |
((esz - 1) << GITS_BASER_ENTRY_SIZE_SHIFT)   |
((alloc_pages - 1) << GITS_BASER_PAGES_SHIFT)|
diff --git a/include/linux/irqchip/arm-gic-v3.h 
b/include/linux/irqchip/arm-gic-v3.h
index b8b5998..4e82f73 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -373,6 +373,9 @@
 #define GITS_BASER_ENTRY_SIZE_SHIFT(48)
 #define GITS_BASER_ENTRY_SIZE(r)   r) >> GITS_BASER_ENTRY_SIZE_SHIFT) 
& 0x1f) + 1)
 #define GITS_BASER_ENTRY_SIZE_MASK GENMASK_ULL(52, 48)
+#define GITS_BASER_PHYS_MASK   GENMASK_ULL(47, 12)
+#define GITS_BASER_64K_PHYS(phys)  \
+   (((phys) | phys) >> 48) & 0xF) << 12)) & GITS_BASER_PHYS_MASK)
 #define GITS_BASER_SHAREABILITY_SHIFT  (10)
 #define GITS_BASER_InnerShareable  \
GIC_BASER_SHAREABILITY(GITS_BASER, InnerShareable)
-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.



[PATCH] irqchip/gicv3-its: Add missing changes to support 52bit physical address

2017-10-06 Thread Shanker Donthineni
The current ITS driver works fine as long as normal memory and GICR
regions are located within the lower 48bit (>=0 && <2^48) physical
address space. Some of the registers GICR_PEND/PROP, GICR_VPEND/VPROP
and GITS_CBASER are handled properly but not all when configuring
the hardware with 52bit physical address.

This patch does the following changes to support 52bit PA.
  -Handle 52bit PA in GITS_BASERn.
  -Fix ITT_addr width to 52bits, bits[51:8].
  -Fix RDbase width to 52bits, bits[51:16].
  -Fix VPT_addr width to 52bits, bits[51:16].

Definition of the GITS_BASERn register when ITS PageSize is 64KB:
 -Bits[47:16] of the register provide bits[47:16] of the table PA.
 -Bits[15:12] of the register provide bits[51:48] of the table PA.
 -Bits[15:00] of the base physical address are 0.

Signed-off-by: Shanker Donthineni 
---
 drivers/irqchip/irq-gic-v3-its.c   | 24 +++-
 include/linux/irqchip/arm-gic-v3.h |  3 +++
 2 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index e8d8934..e52c0da 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -308,7 +308,7 @@ static void its_encode_size(struct its_cmd_block *cmd, u8 
size)
 
 static void its_encode_itt(struct its_cmd_block *cmd, u64 itt_addr)
 {
-   its_mask_encode(>raw_cmd[2], itt_addr >> 8, 50, 8);
+   its_mask_encode(>raw_cmd[2], itt_addr >> 8, 51, 8);
 }
 
 static void its_encode_valid(struct its_cmd_block *cmd, int valid)
@@ -318,7 +318,7 @@ static void its_encode_valid(struct its_cmd_block *cmd, int 
valid)
 
 static void its_encode_target(struct its_cmd_block *cmd, u64 target_addr)
 {
-   its_mask_encode(>raw_cmd[2], target_addr >> 16, 50, 16);
+   its_mask_encode(>raw_cmd[2], target_addr >> 16, 51, 16);
 }
 
 static void its_encode_collection(struct its_cmd_block *cmd, u16 col)
@@ -358,7 +358,7 @@ static void its_encode_its_list(struct its_cmd_block *cmd, 
u16 its_list)
 
 static void its_encode_vpt_addr(struct its_cmd_block *cmd, u64 vpt_pa)
 {
-   its_mask_encode(>raw_cmd[3], vpt_pa >> 16, 50, 16);
+   its_mask_encode(>raw_cmd[3], vpt_pa >> 16, 51, 16);
 }
 
 static void its_encode_vpt_size(struct its_cmd_block *cmd, u8 vpt_size)
@@ -1478,9 +1478,9 @@ static int its_setup_baser(struct its_node *its, struct 
its_baser *baser,
u64 val = its_read_baser(its, baser);
u64 esz = GITS_BASER_ENTRY_SIZE(val);
u64 type = GITS_BASER_TYPE(val);
+   u64 baser_phys, tmp;
u32 alloc_pages;
void *base;
-   u64 tmp;
 
 retry_alloc_baser:
alloc_pages = (PAGE_ORDER_TO_SIZE(order) / psz);
@@ -1496,8 +1496,22 @@ static int its_setup_baser(struct its_node *its, struct 
its_baser *baser,
if (!base)
return -ENOMEM;
 
+   baser_phys = virt_to_phys(base);
+
+   /* Check if the physical address of the memory is above 48bits */
+   if (baser_phys & (~GITS_BASER_PHYS_MASK)) {
+   /* 52bit PA is supported only when PageSize=64K */
+   if (psz != SZ_64K) {
+   free_pages((unsigned long)base, order);
+   return -EFAULT;
+   }
+
+   /* Convert 52bit PA to 48bit field */
+   baser_phys = GITS_BASER_64K_PHYS(baser_phys);
+   }
+
 retry_baser:
-   val = (virt_to_phys(base)|
+   val = (baser_phys|
(type << GITS_BASER_TYPE_SHIFT)  |
((esz - 1) << GITS_BASER_ENTRY_SIZE_SHIFT)   |
((alloc_pages - 1) << GITS_BASER_PAGES_SHIFT)|
diff --git a/include/linux/irqchip/arm-gic-v3.h 
b/include/linux/irqchip/arm-gic-v3.h
index b8b5998..4e82f73 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -373,6 +373,9 @@
 #define GITS_BASER_ENTRY_SIZE_SHIFT(48)
 #define GITS_BASER_ENTRY_SIZE(r)   r) >> GITS_BASER_ENTRY_SIZE_SHIFT) 
& 0x1f) + 1)
 #define GITS_BASER_ENTRY_SIZE_MASK GENMASK_ULL(52, 48)
+#define GITS_BASER_PHYS_MASK   GENMASK_ULL(47, 12)
+#define GITS_BASER_64K_PHYS(phys)  \
+   (((phys) | phys) >> 48) & 0xF) << 12)) & GITS_BASER_PHYS_MASK)
 #define GITS_BASER_SHAREABILITY_SHIFT  (10)
 #define GITS_BASER_InnerShareable  \
GIC_BASER_SHAREABILITY(GITS_BASER, InnerShareable)
-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.



Re: [Patch v6 6/7] regmap: add SLIMBUS support

2017-10-06 Thread Jonathan Neuschäfer
Hi,

On Fri, Oct 06, 2017 at 05:51:35PM +0200, srinivas.kandaga...@linaro.org wrote:
> From: Srinivas Kandagatla 
> 
> This patch adds support to read/write slimbus value elements.
> Currently it only supports byte read/write. Adding this support in
> regmap would give codec drivers more flexibility when there are more
> than 2 control interfaces like slimbus, i2c.
> 
> Without this patch each codec driver has to directly call slimbus value
> element apis, and this could would get messy once we want to add i2c
> interface to it.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
[...]
> +static int regmap_slimbus_byte_reg_read(void *context, unsigned int reg,
> + unsigned int *val)
> +{
> + struct slim_device *slim = context;
> + struct slim_val_inf msg = {0,};
> +
> + msg.start_offset = reg;
> + msg.num_bytes = 1;
> + msg.rbuf = (void *)val;
> +
> + return slim_request_val_element(slim, );
> +}

This looks like it won't work on big-endian systems. I know big endian
is pretty uncommon in devices that will likely have SLIMBus, but it's
better to be endian-independent.

> +static int regmap_slimbus_byte_reg_write(void *context, unsigned int reg,
> +  unsigned int val)
> +{
> + struct slim_device *slim = context;
> + struct slim_val_inf msg = {0,};
> +
> + msg.start_offset = reg;
> + msg.num_bytes = 1;
> + msg.wbuf = (void *)
> +
> + return slim_change_val_element(slim, );
> +}

dito

> +static struct regmap_bus regmap_slimbus_bus = {
> + .reg_write = regmap_slimbus_byte_reg_write,
> + .reg_read = regmap_slimbus_byte_reg_read,
> +};


Thanks,
Jonathan Neuschäfer


signature.asc
Description: PGP signature


Re: [Patch v6 6/7] regmap: add SLIMBUS support

2017-10-06 Thread Jonathan Neuschäfer
Hi,

On Fri, Oct 06, 2017 at 05:51:35PM +0200, srinivas.kandaga...@linaro.org wrote:
> From: Srinivas Kandagatla 
> 
> This patch adds support to read/write slimbus value elements.
> Currently it only supports byte read/write. Adding this support in
> regmap would give codec drivers more flexibility when there are more
> than 2 control interfaces like slimbus, i2c.
> 
> Without this patch each codec driver has to directly call slimbus value
> element apis, and this could would get messy once we want to add i2c
> interface to it.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
[...]
> +static int regmap_slimbus_byte_reg_read(void *context, unsigned int reg,
> + unsigned int *val)
> +{
> + struct slim_device *slim = context;
> + struct slim_val_inf msg = {0,};
> +
> + msg.start_offset = reg;
> + msg.num_bytes = 1;
> + msg.rbuf = (void *)val;
> +
> + return slim_request_val_element(slim, );
> +}

This looks like it won't work on big-endian systems. I know big endian
is pretty uncommon in devices that will likely have SLIMBus, but it's
better to be endian-independent.

> +static int regmap_slimbus_byte_reg_write(void *context, unsigned int reg,
> +  unsigned int val)
> +{
> + struct slim_device *slim = context;
> + struct slim_val_inf msg = {0,};
> +
> + msg.start_offset = reg;
> + msg.num_bytes = 1;
> + msg.wbuf = (void *)
> +
> + return slim_change_val_element(slim, );
> +}

dito

> +static struct regmap_bus regmap_slimbus_bus = {
> + .reg_write = regmap_slimbus_byte_reg_write,
> + .reg_read = regmap_slimbus_byte_reg_read,
> +};


Thanks,
Jonathan Neuschäfer


signature.asc
Description: PGP signature


[PATCH v5 02/14] platform/x86: dell-wmi: increase severity of some failures

2017-10-06 Thread Mario Limonciello
There is a lot of error checking in place for the format of the WMI
descriptor buffer, but some of the potentially raised issues should
be considered critical failures.

If the buffer size or header don't match, this is a good indication
that the buffer format changed in a way that the rest of the data
should not be relied upon.

For the remaining data set vectors, continue to notate a warning
in undefined results, but as those are fields that the descriptor
intended to refer to other applications, don't fail if they're new
values.

Signed-off-by: Mario Limonciello 
---
 drivers/platform/x86/dell-wmi.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 1fbef560ca67..2cfaaa8faf0a 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -657,17 +657,18 @@ static int dell_wmi_check_descriptor_buffer(struct 
wmi_device *wdev)
dev_err(>dev,
"Dell descriptor buffer has invalid length (%d)\n",
obj->buffer.length);
-   if (obj->buffer.length < 16) {
-   ret = -EINVAL;
-   goto out;
-   }
+   ret = -EINVAL;
+   goto out;
}
 
buffer = (u32 *)obj->buffer.pointer;
 
-   if (buffer[0] != 0x4C4C4544 && buffer[1] != 0x494D5720)
-   dev_warn(>dev, "Dell descriptor buffer has invalid 
signature (%*ph)\n",
+   if (buffer[0] != 0x4C4C4544 && buffer[1] != 0x494D5720) {
+   dev_err(>dev, "Dell descriptor buffer has invalid 
signature (%*ph)\n",
8, buffer);
+   ret = -EINVAL;
+   goto out;
+   }
 
if (buffer[2] != 0 && buffer[2] != 1)
dev_warn(>dev, "Dell descriptor buffer has unknown 
version (%d)\n",
-- 
2.14.1



[PATCH v5 02/14] platform/x86: dell-wmi: increase severity of some failures

2017-10-06 Thread Mario Limonciello
There is a lot of error checking in place for the format of the WMI
descriptor buffer, but some of the potentially raised issues should
be considered critical failures.

If the buffer size or header don't match, this is a good indication
that the buffer format changed in a way that the rest of the data
should not be relied upon.

For the remaining data set vectors, continue to notate a warning
in undefined results, but as those are fields that the descriptor
intended to refer to other applications, don't fail if they're new
values.

Signed-off-by: Mario Limonciello 
---
 drivers/platform/x86/dell-wmi.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 1fbef560ca67..2cfaaa8faf0a 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -657,17 +657,18 @@ static int dell_wmi_check_descriptor_buffer(struct 
wmi_device *wdev)
dev_err(>dev,
"Dell descriptor buffer has invalid length (%d)\n",
obj->buffer.length);
-   if (obj->buffer.length < 16) {
-   ret = -EINVAL;
-   goto out;
-   }
+   ret = -EINVAL;
+   goto out;
}
 
buffer = (u32 *)obj->buffer.pointer;
 
-   if (buffer[0] != 0x4C4C4544 && buffer[1] != 0x494D5720)
-   dev_warn(>dev, "Dell descriptor buffer has invalid 
signature (%*ph)\n",
+   if (buffer[0] != 0x4C4C4544 && buffer[1] != 0x494D5720) {
+   dev_err(>dev, "Dell descriptor buffer has invalid 
signature (%*ph)\n",
8, buffer);
+   ret = -EINVAL;
+   goto out;
+   }
 
if (buffer[2] != 0 && buffer[2] != 1)
dev_warn(>dev, "Dell descriptor buffer has unknown 
version (%d)\n",
-- 
2.14.1



[PATCH v5 01/14] platform/x86: wmi: Add new method wmidev_evaluate_method

2017-10-06 Thread Mario Limonciello
Drivers properly using the wmibus can pass their wmi_device
pointer rather than the GUID back to the WMI bus to evaluate
the proper methods.

Any "new" drivers added that use the WMI bus should use this
rather than the old wmi_evaluate_method that would take the
GUID.

Signed-off-by: Mario Limonciello 
---
 drivers/platform/x86/wmi.c | 28 
 include/linux/wmi.h|  6 ++
 2 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index 7a05843aff19..4d73a87c2ddf 100644
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -200,6 +200,28 @@ static acpi_status wmi_method_enable(struct wmi_block 
*wblock, int enable)
  */
 acpi_status wmi_evaluate_method(const char *guid_string, u8 instance,
 u32 method_id, const struct acpi_buffer *in, struct acpi_buffer *out)
+{
+   struct wmi_block *wblock = NULL;
+
+   if (!find_guid(guid_string, ))
+   return AE_ERROR;
+   return wmidev_evaluate_method(>dev, instance, method_id,
+ in, out);
+}
+EXPORT_SYMBOL_GPL(wmi_evaluate_method);
+
+/**
+ * wmidev_evaluate_method - Evaluate a WMI method
+ * @wdev: A wmi bus device from a driver
+ * @instance: Instance index
+ * @method_id: Method ID to call
+ * : Buffer containing input for the method call
+ * : Empty buffer to return the method results
+ *
+ * Call an ACPI-WMI method
+ */
+acpi_status wmidev_evaluate_method(struct wmi_device *wdev, u8 instance,
+   u32 method_id, const struct acpi_buffer *in, struct acpi_buffer *out)
 {
struct guid_block *block = NULL;
struct wmi_block *wblock = NULL;
@@ -209,9 +231,7 @@ u32 method_id, const struct acpi_buffer *in, struct 
acpi_buffer *out)
union acpi_object params[3];
char method[5] = "WM";
 
-   if (!find_guid(guid_string, ))
-   return AE_ERROR;
-
+   wblock = container_of(wdev, struct wmi_block, dev);
block = >gblock;
handle = wblock->acpi_device->handle;
 
@@ -246,7 +266,7 @@ u32 method_id, const struct acpi_buffer *in, struct 
acpi_buffer *out)
 
return status;
 }
-EXPORT_SYMBOL_GPL(wmi_evaluate_method);
+EXPORT_SYMBOL_GPL(wmidev_evaluate_method);
 
 static acpi_status __query_block(struct wmi_block *wblock, u8 instance,
 struct acpi_buffer *out)
diff --git a/include/linux/wmi.h b/include/linux/wmi.h
index cd0d7734dc49..2cd10c3b89e9 100644
--- a/include/linux/wmi.h
+++ b/include/linux/wmi.h
@@ -26,6 +26,12 @@ struct wmi_device {
bool setable;
 };
 
+/* evaluate the ACPI method associated with this device */
+extern acpi_status wmidev_evaluate_method(struct wmi_device *wdev,
+ u8 instance, u32 method_id,
+ const struct acpi_buffer *in,
+ struct acpi_buffer *out);
+
 /* Caller must kfree the result. */
 extern union acpi_object *wmidev_block_query(struct wmi_device *wdev,
 u8 instance);
-- 
2.14.1



[PATCH v5 01/14] platform/x86: wmi: Add new method wmidev_evaluate_method

2017-10-06 Thread Mario Limonciello
Drivers properly using the wmibus can pass their wmi_device
pointer rather than the GUID back to the WMI bus to evaluate
the proper methods.

Any "new" drivers added that use the WMI bus should use this
rather than the old wmi_evaluate_method that would take the
GUID.

Signed-off-by: Mario Limonciello 
---
 drivers/platform/x86/wmi.c | 28 
 include/linux/wmi.h|  6 ++
 2 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index 7a05843aff19..4d73a87c2ddf 100644
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -200,6 +200,28 @@ static acpi_status wmi_method_enable(struct wmi_block 
*wblock, int enable)
  */
 acpi_status wmi_evaluate_method(const char *guid_string, u8 instance,
 u32 method_id, const struct acpi_buffer *in, struct acpi_buffer *out)
+{
+   struct wmi_block *wblock = NULL;
+
+   if (!find_guid(guid_string, ))
+   return AE_ERROR;
+   return wmidev_evaluate_method(>dev, instance, method_id,
+ in, out);
+}
+EXPORT_SYMBOL_GPL(wmi_evaluate_method);
+
+/**
+ * wmidev_evaluate_method - Evaluate a WMI method
+ * @wdev: A wmi bus device from a driver
+ * @instance: Instance index
+ * @method_id: Method ID to call
+ * : Buffer containing input for the method call
+ * : Empty buffer to return the method results
+ *
+ * Call an ACPI-WMI method
+ */
+acpi_status wmidev_evaluate_method(struct wmi_device *wdev, u8 instance,
+   u32 method_id, const struct acpi_buffer *in, struct acpi_buffer *out)
 {
struct guid_block *block = NULL;
struct wmi_block *wblock = NULL;
@@ -209,9 +231,7 @@ u32 method_id, const struct acpi_buffer *in, struct 
acpi_buffer *out)
union acpi_object params[3];
char method[5] = "WM";
 
-   if (!find_guid(guid_string, ))
-   return AE_ERROR;
-
+   wblock = container_of(wdev, struct wmi_block, dev);
block = >gblock;
handle = wblock->acpi_device->handle;
 
@@ -246,7 +266,7 @@ u32 method_id, const struct acpi_buffer *in, struct 
acpi_buffer *out)
 
return status;
 }
-EXPORT_SYMBOL_GPL(wmi_evaluate_method);
+EXPORT_SYMBOL_GPL(wmidev_evaluate_method);
 
 static acpi_status __query_block(struct wmi_block *wblock, u8 instance,
 struct acpi_buffer *out)
diff --git a/include/linux/wmi.h b/include/linux/wmi.h
index cd0d7734dc49..2cd10c3b89e9 100644
--- a/include/linux/wmi.h
+++ b/include/linux/wmi.h
@@ -26,6 +26,12 @@ struct wmi_device {
bool setable;
 };
 
+/* evaluate the ACPI method associated with this device */
+extern acpi_status wmidev_evaluate_method(struct wmi_device *wdev,
+ u8 instance, u32 method_id,
+ const struct acpi_buffer *in,
+ struct acpi_buffer *out);
+
 /* Caller must kfree the result. */
 extern union acpi_object *wmidev_block_query(struct wmi_device *wdev,
 u8 instance);
-- 
2.14.1



[PATCH v5 03/14] platform/x86: dell-wmi: clean up wmi descriptor check

2017-10-06 Thread Mario Limonciello
Some cases the wrong type was used for errors and checks can be
done more cleanly.

Signed-off-by: Mario Limonciello 
Reviewed-by: Edward O'Callaghan 
Suggested-by: Andy Shevchenko 
---
 drivers/platform/x86/dell-wmi.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 2cfaaa8faf0a..ece2fe341f01 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -663,19 +663,19 @@ static int dell_wmi_check_descriptor_buffer(struct 
wmi_device *wdev)
 
buffer = (u32 *)obj->buffer.pointer;
 
-   if (buffer[0] != 0x4C4C4544 && buffer[1] != 0x494D5720) {
-   dev_err(>dev, "Dell descriptor buffer has invalid 
signature (%*ph)\n",
-   8, buffer);
+   if (strncmp(obj->string.pointer, "DELL WMI", 8) != 0) {
+   dev_err(>dev, "Dell descriptor buffer has invalid 
signature (%8ph)\n",
+   buffer);
ret = -EINVAL;
goto out;
}
 
if (buffer[2] != 0 && buffer[2] != 1)
-   dev_warn(>dev, "Dell descriptor buffer has unknown 
version (%d)\n",
+   dev_warn(>dev, "Dell descriptor buffer has unknown 
version (%u)\n",
buffer[2]);
 
if (buffer[3] != 4096)
-   dev_warn(>dev, "Dell descriptor buffer has invalid buffer 
length (%d)\n",
+   dev_warn(>dev, "Dell descriptor buffer has invalid buffer 
length (%u)\n",
buffer[3]);
 
priv->interface_version = buffer[2];
-- 
2.14.1



[PATCH v5 07/14] platform/x86: dell-smbios: only run if proper oem string is detected

2017-10-06 Thread Mario Limonciello
The proper way to indicate that a system is a 'supported' Dell System
is by the presence of this string in OEM strings.

Allowing the driver to load on non-Dell systems will have undefined
results.

Signed-off-by: Mario Limonciello 
---
 drivers/platform/x86/dell-smbios.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/platform/x86/dell-smbios.c 
b/drivers/platform/x86/dell-smbios.c
index e9b1ca07c872..873d1c3f7641 100644
--- a/drivers/platform/x86/dell-smbios.c
+++ b/drivers/platform/x86/dell-smbios.c
@@ -172,8 +172,15 @@ static void __init find_tokens(const struct dmi_header 
*dm, void *dummy)
 
 static int __init dell_smbios_init(void)
 {
+   const struct dmi_device *valid;
int ret;
 
+   valid = dmi_find_device(DMI_DEV_TYPE_OEM_STRING, "Dell System", NULL);
+   if (!valid) {
+   pr_info("Unable to run on non-Dell system\n");
+   return -ENODEV;
+   }
+
dmi_walk(find_tokens, NULL);
 
if (!da_tokens)  {
-- 
2.14.1



[PATCH v5 03/14] platform/x86: dell-wmi: clean up wmi descriptor check

2017-10-06 Thread Mario Limonciello
Some cases the wrong type was used for errors and checks can be
done more cleanly.

Signed-off-by: Mario Limonciello 
Reviewed-by: Edward O'Callaghan 
Suggested-by: Andy Shevchenko 
---
 drivers/platform/x86/dell-wmi.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 2cfaaa8faf0a..ece2fe341f01 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -663,19 +663,19 @@ static int dell_wmi_check_descriptor_buffer(struct 
wmi_device *wdev)
 
buffer = (u32 *)obj->buffer.pointer;
 
-   if (buffer[0] != 0x4C4C4544 && buffer[1] != 0x494D5720) {
-   dev_err(>dev, "Dell descriptor buffer has invalid 
signature (%*ph)\n",
-   8, buffer);
+   if (strncmp(obj->string.pointer, "DELL WMI", 8) != 0) {
+   dev_err(>dev, "Dell descriptor buffer has invalid 
signature (%8ph)\n",
+   buffer);
ret = -EINVAL;
goto out;
}
 
if (buffer[2] != 0 && buffer[2] != 1)
-   dev_warn(>dev, "Dell descriptor buffer has unknown 
version (%d)\n",
+   dev_warn(>dev, "Dell descriptor buffer has unknown 
version (%u)\n",
buffer[2]);
 
if (buffer[3] != 4096)
-   dev_warn(>dev, "Dell descriptor buffer has invalid buffer 
length (%d)\n",
+   dev_warn(>dev, "Dell descriptor buffer has invalid buffer 
length (%u)\n",
buffer[3]);
 
priv->interface_version = buffer[2];
-- 
2.14.1



[PATCH v5 07/14] platform/x86: dell-smbios: only run if proper oem string is detected

2017-10-06 Thread Mario Limonciello
The proper way to indicate that a system is a 'supported' Dell System
is by the presence of this string in OEM strings.

Allowing the driver to load on non-Dell systems will have undefined
results.

Signed-off-by: Mario Limonciello 
---
 drivers/platform/x86/dell-smbios.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/platform/x86/dell-smbios.c 
b/drivers/platform/x86/dell-smbios.c
index e9b1ca07c872..873d1c3f7641 100644
--- a/drivers/platform/x86/dell-smbios.c
+++ b/drivers/platform/x86/dell-smbios.c
@@ -172,8 +172,15 @@ static void __init find_tokens(const struct dmi_header 
*dm, void *dummy)
 
 static int __init dell_smbios_init(void)
 {
+   const struct dmi_device *valid;
int ret;
 
+   valid = dmi_find_device(DMI_DEV_TYPE_OEM_STRING, "Dell System", NULL);
+   if (!valid) {
+   pr_info("Unable to run on non-Dell system\n");
+   return -ENODEV;
+   }
+
dmi_walk(find_tokens, NULL);
 
if (!da_tokens)  {
-- 
2.14.1



[PATCH v5 08/14] platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens

2017-10-06 Thread Mario Limonciello
Currently userspace tools can access system tokens via the dcdbas
kernel module and a SMI call that will cause the platform to execute
SMM code.

With a goal in mind of deprecating the dcdbas kernel module a different
method for accessing these tokens from userspace needs to be created.

This is intentionally marked to only be readable as root as it can
contain sensitive information about the platform's configuration.

MAINTAINERS was missing for this driver.  Add myself and Pali to
maintainers list for it.

Signed-off-by: Mario Limonciello 
---
 .../ABI/testing/sysfs-platform-dell-smbios | 16 ++
 MAINTAINERS|  7 +++
 drivers/platform/x86/dell-smbios.c | 64 ++
 3 files changed, 87 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-smbios

diff --git a/Documentation/ABI/testing/sysfs-platform-dell-smbios 
b/Documentation/ABI/testing/sysfs-platform-dell-smbios
new file mode 100644
index ..d97f4bd5bd91
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-dell-smbios
@@ -0,0 +1,16 @@
+What:  /sys/devices/platform//tokens
+Date:  November 2017
+KernelVersion: 4.15
+Contact:   "Mario Limonciello" 
+Description:
+   A read-only description of Dell platform tokens
+   available on the machine.
+
+   The tokens will be displayed in the following
+   machine readable format with each token on a
+   new line:
+
+   ID  Locationvalue
+
+   For example token:
+   5   5   3
diff --git a/MAINTAINERS b/MAINTAINERS
index 659dbeec4191..2e3f2aea0370 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3967,6 +3967,13 @@ M:   "Maciej W. Rozycki" 
 S: Maintained
 F: drivers/net/fddi/defxx.*
 
+DELL SMBIOS DRIVER
+M: Pali Rohár 
+M: Mario Limonciello 
+L: platform-driver-...@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/dell-smbios.*
+
 DELL LAPTOP DRIVER
 M: Matthew Garrett 
 M: Pali Rohár 
diff --git a/drivers/platform/x86/dell-smbios.c 
b/drivers/platform/x86/dell-smbios.c
index 873d1c3f7641..7275d1d48190 100644
--- a/drivers/platform/x86/dell-smbios.c
+++ b/drivers/platform/x86/dell-smbios.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include "../../firmware/dcdbas.h"
+#include 
 #include "dell-smbios.h"
 
 struct calling_interface_structure {
@@ -39,6 +40,7 @@ static DEFINE_MUTEX(buffer_mutex);
 static int da_command_address;
 static int da_command_code;
 static int da_num_tokens;
+static struct platform_device *platform_device;
 static struct calling_interface_token *da_tokens;
 
 int dell_smbios_error(int value)
@@ -170,6 +172,40 @@ static void __init find_tokens(const struct dmi_header 
*dm, void *dummy)
}
 }
 
+static ssize_t tokens_show(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   size_t off = 0;
+   int to_print;
+   int i;
+
+   to_print = min(da_num_tokens, (int)(PAGE_SIZE - 1) / 15);
+   for (i = 0; i < to_print; i++) {
+   off += scnprintf(buf+off, PAGE_SIZE-off, "%04x\t%04x\t%04x\n",
+   da_tokens[i].tokenID, da_tokens[i].location,
+   da_tokens[i].value);
+   }
+
+   return off;
+}
+
+DEVICE_ATTR(tokens, 0400, tokens_show, NULL);
+
+static struct attribute *smbios_attrs[] = {
+   _attr_tokens.attr,
+   NULL
+};
+
+static const struct attribute_group smbios_attribute_group = {
+   .attrs = smbios_attrs,
+};
+
+static struct platform_driver platform_driver = {
+   .driver = {
+   .name = "dell-smbios",
+   },
+};
+
 static int __init dell_smbios_init(void)
 {
const struct dmi_device *valid;
@@ -197,9 +233,37 @@ static int __init dell_smbios_init(void)
ret = -ENOMEM;
goto fail_buffer;
}
+   ret = platform_driver_register(_driver);
+   if (ret)
+   goto fail_platform_driver;
+
+   platform_device = platform_device_alloc("dell-smbios", 0);
+   if (!platform_device) {
+   ret = -ENOMEM;
+   goto fail_platform_device_alloc;
+   }
+   ret = platform_device_add(platform_device);
+   if (ret)
+   goto fail_platform_device_add;
+   ret = sysfs_create_group(_device->dev.kobj,
+_attribute_group);
+   if (ret)
+   goto fail_create_group;
 
return 0;
 
+fail_create_group:
+   platform_device_del(platform_device);
+
+fail_platform_device_add:
+   platform_device_put(platform_device);
+
+fail_platform_device_alloc:
+   platform_driver_unregister(_driver);
+
+fail_platform_driver:
+   

[PATCH v5 04/14] platform/x86: dell-wmi: allow 32k return size in the descriptor

2017-10-06 Thread Mario Limonciello
Some platforms this year will be adopting 32k WMI buffer, so don't
complain when encountering those.

Signed-off-by: Mario Limonciello 
---
 drivers/platform/x86/dell-wmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index ece2fe341f01..c8c7f4f9326c 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -624,7 +624,7 @@ static void dell_wmi_input_destroy(struct wmi_device *wdev)
  * Vendor Signature  0   4"DELL"
  * Object Signature  4   4" WMI"
  * WMI Interface Version 8   4
- * WMI buffer length12   44096
+ * WMI buffer length12   44096 or 32768
  */
 static int dell_wmi_check_descriptor_buffer(struct wmi_device *wdev)
 {
@@ -674,7 +674,7 @@ static int dell_wmi_check_descriptor_buffer(struct 
wmi_device *wdev)
dev_warn(>dev, "Dell descriptor buffer has unknown 
version (%u)\n",
buffer[2]);
 
-   if (buffer[3] != 4096)
+   if (desc_buffer[3] != 4096 && desc_buffer[3] != 32768)
dev_warn(>dev, "Dell descriptor buffer has invalid buffer 
length (%u)\n",
buffer[3]);
 
-- 
2.14.1



[PATCH v5 08/14] platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens

2017-10-06 Thread Mario Limonciello
Currently userspace tools can access system tokens via the dcdbas
kernel module and a SMI call that will cause the platform to execute
SMM code.

With a goal in mind of deprecating the dcdbas kernel module a different
method for accessing these tokens from userspace needs to be created.

This is intentionally marked to only be readable as root as it can
contain sensitive information about the platform's configuration.

MAINTAINERS was missing for this driver.  Add myself and Pali to
maintainers list for it.

Signed-off-by: Mario Limonciello 
---
 .../ABI/testing/sysfs-platform-dell-smbios | 16 ++
 MAINTAINERS|  7 +++
 drivers/platform/x86/dell-smbios.c | 64 ++
 3 files changed, 87 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-smbios

diff --git a/Documentation/ABI/testing/sysfs-platform-dell-smbios 
b/Documentation/ABI/testing/sysfs-platform-dell-smbios
new file mode 100644
index ..d97f4bd5bd91
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-dell-smbios
@@ -0,0 +1,16 @@
+What:  /sys/devices/platform//tokens
+Date:  November 2017
+KernelVersion: 4.15
+Contact:   "Mario Limonciello" 
+Description:
+   A read-only description of Dell platform tokens
+   available on the machine.
+
+   The tokens will be displayed in the following
+   machine readable format with each token on a
+   new line:
+
+   ID  Locationvalue
+
+   For example token:
+   5   5   3
diff --git a/MAINTAINERS b/MAINTAINERS
index 659dbeec4191..2e3f2aea0370 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3967,6 +3967,13 @@ M:   "Maciej W. Rozycki" 
 S: Maintained
 F: drivers/net/fddi/defxx.*
 
+DELL SMBIOS DRIVER
+M: Pali Rohár 
+M: Mario Limonciello 
+L: platform-driver-...@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/dell-smbios.*
+
 DELL LAPTOP DRIVER
 M: Matthew Garrett 
 M: Pali Rohár 
diff --git a/drivers/platform/x86/dell-smbios.c 
b/drivers/platform/x86/dell-smbios.c
index 873d1c3f7641..7275d1d48190 100644
--- a/drivers/platform/x86/dell-smbios.c
+++ b/drivers/platform/x86/dell-smbios.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include "../../firmware/dcdbas.h"
+#include 
 #include "dell-smbios.h"
 
 struct calling_interface_structure {
@@ -39,6 +40,7 @@ static DEFINE_MUTEX(buffer_mutex);
 static int da_command_address;
 static int da_command_code;
 static int da_num_tokens;
+static struct platform_device *platform_device;
 static struct calling_interface_token *da_tokens;
 
 int dell_smbios_error(int value)
@@ -170,6 +172,40 @@ static void __init find_tokens(const struct dmi_header 
*dm, void *dummy)
}
 }
 
+static ssize_t tokens_show(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   size_t off = 0;
+   int to_print;
+   int i;
+
+   to_print = min(da_num_tokens, (int)(PAGE_SIZE - 1) / 15);
+   for (i = 0; i < to_print; i++) {
+   off += scnprintf(buf+off, PAGE_SIZE-off, "%04x\t%04x\t%04x\n",
+   da_tokens[i].tokenID, da_tokens[i].location,
+   da_tokens[i].value);
+   }
+
+   return off;
+}
+
+DEVICE_ATTR(tokens, 0400, tokens_show, NULL);
+
+static struct attribute *smbios_attrs[] = {
+   _attr_tokens.attr,
+   NULL
+};
+
+static const struct attribute_group smbios_attribute_group = {
+   .attrs = smbios_attrs,
+};
+
+static struct platform_driver platform_driver = {
+   .driver = {
+   .name = "dell-smbios",
+   },
+};
+
 static int __init dell_smbios_init(void)
 {
const struct dmi_device *valid;
@@ -197,9 +233,37 @@ static int __init dell_smbios_init(void)
ret = -ENOMEM;
goto fail_buffer;
}
+   ret = platform_driver_register(_driver);
+   if (ret)
+   goto fail_platform_driver;
+
+   platform_device = platform_device_alloc("dell-smbios", 0);
+   if (!platform_device) {
+   ret = -ENOMEM;
+   goto fail_platform_device_alloc;
+   }
+   ret = platform_device_add(platform_device);
+   if (ret)
+   goto fail_platform_device_add;
+   ret = sysfs_create_group(_device->dev.kobj,
+_attribute_group);
+   if (ret)
+   goto fail_create_group;
 
return 0;
 
+fail_create_group:
+   platform_device_del(platform_device);
+
+fail_platform_device_add:
+   platform_device_put(platform_device);
+
+fail_platform_device_alloc:
+   platform_driver_unregister(_driver);
+
+fail_platform_driver:
+   free_page((unsigned long)buffer);
+
 fail_buffer:
kfree(da_tokens);
return ret;
-- 
2.14.1



[PATCH v5 04/14] platform/x86: dell-wmi: allow 32k return size in the descriptor

2017-10-06 Thread Mario Limonciello
Some platforms this year will be adopting 32k WMI buffer, so don't
complain when encountering those.

Signed-off-by: Mario Limonciello 
---
 drivers/platform/x86/dell-wmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index ece2fe341f01..c8c7f4f9326c 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -624,7 +624,7 @@ static void dell_wmi_input_destroy(struct wmi_device *wdev)
  * Vendor Signature  0   4"DELL"
  * Object Signature  4   4" WMI"
  * WMI Interface Version 8   4
- * WMI buffer length12   44096
+ * WMI buffer length12   44096 or 32768
  */
 static int dell_wmi_check_descriptor_buffer(struct wmi_device *wdev)
 {
@@ -674,7 +674,7 @@ static int dell_wmi_check_descriptor_buffer(struct 
wmi_device *wdev)
dev_warn(>dev, "Dell descriptor buffer has unknown 
version (%u)\n",
buffer[2]);
 
-   if (buffer[3] != 4096)
+   if (desc_buffer[3] != 4096 && desc_buffer[3] != 32768)
dev_warn(>dev, "Dell descriptor buffer has invalid buffer 
length (%u)\n",
buffer[3]);
 
-- 
2.14.1



[PATCH v5 09/14] platform/x86: dell-smbios: Introduce dispatcher for SMM calls

2017-10-06 Thread Mario Limonciello
This splits up the dell-smbios driver into two drivers:
* dell-smbios
* dell-smbios-smm

dell-smbios can operate with multiple different dispatcher drivers to
perform SMBIOS operations.

Also modify the interface that dell-laptop and dell-wmi use align to this
model more closely.  Rather than a single global buffer being allocated
for all drivers, each driver will allocate and be responsible for it's own
buffer. The pointer will be passed to the calling function and each
dispatcher driver will then internally copy it to the proper location to
perform it's call.

Signed-off-by: Mario Limonciello 
---
 MAINTAINERS|   6 +
 drivers/platform/x86/Kconfig   |  16 ++-
 drivers/platform/x86/Makefile  |   1 +
 drivers/platform/x86/dell-laptop.c | 255 -
 drivers/platform/x86/dell-smbios-smm.c | 136 ++
 drivers/platform/x86/dell-smbios.c | 123 ++--
 drivers/platform/x86/dell-smbios.h |  13 +-
 drivers/platform/x86/dell-wmi.c|  11 +-
 8 files changed, 338 insertions(+), 223 deletions(-)
 create mode 100644 drivers/platform/x86/dell-smbios-smm.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 2e3f2aea0370..8faf08ebcfee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3974,6 +3974,12 @@ L:   platform-driver-...@vger.kernel.org
 S: Maintained
 F: drivers/platform/x86/dell-smbios.*
 
+DELL SMBIOS SMM DRIVER
+M: Mario Limonciello 
+L: platform-driver-...@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/dell-smbios-smm.c
+
 DELL LAPTOP DRIVER
 M: Matthew Garrett 
 M: Pali Rohár 
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 7722923c968c..7cc91519bec8 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -93,12 +93,20 @@ config ASUS_LAPTOP
 
 config DELL_SMBIOS
tristate
-   select DCDBAS
+   depends on DELL_SMBIOS_SMM
+
+config DELL_SMBIOS_SMM
+   tristate "Dell SMBIOS calling interface (SMM implementation)"
+   depends on DCDBAS
+   default DCDBAS
+   select DELL_SMBIOS
---help---
-   This module provides common functions for kernel modules using
-   Dell SMBIOS.
+   This provides an implementation for the Dell SMBIOS calling interface
+   communicated over SMI/SMM.
 
-   If you have a Dell laptop, say Y or M here.
+   If you have a Dell computer from <=2017 you should say Y or M here.
+   If you aren't sure and this module doesn't work for your computer
+   it just won't load.
 
 config DELL_LAPTOP
tristate "Dell Laptop Extras"
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 8636f5d3424f..e743615241f8 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_MSI_LAPTOP)  += msi-laptop.o
 obj-$(CONFIG_ACPI_CMPC)+= classmate-laptop.o
 obj-$(CONFIG_COMPAL_LAPTOP)+= compal-laptop.o
 obj-$(CONFIG_DELL_SMBIOS)  += dell-smbios.o
+obj-$(CONFIG_DELL_SMBIOS_SMM)  += dell-smbios-smm.o
 obj-$(CONFIG_DELL_LAPTOP)  += dell-laptop.o
 obj-$(CONFIG_DELL_WMI) += dell-wmi.o
 obj-$(CONFIG_DELL_WMI_DESCRIPTOR)  += dell-wmi-descriptor.o
diff --git a/drivers/platform/x86/dell-laptop.c 
b/drivers/platform/x86/dell-laptop.c
index f42159fd2031..2f65f5c15d53 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -85,6 +85,7 @@ static struct platform_driver platform_driver = {
}
 };
 
+static struct calling_interface_buffer *buffer;
 static struct platform_device *platform_device;
 static struct backlight_device *dell_backlight_device;
 static struct rfkill *wifi_rfkill;
@@ -283,6 +284,23 @@ static const struct dmi_system_id dell_quirks[] 
__initconst = {
{ }
 };
 
+int dell_send_request(u16 class, u16 select, u32 arg0, u32 arg1, u32 arg2,
+  u32 arg3)
+{
+   int ret;
+
+   buffer->class = class;
+   buffer->select = select;
+   buffer->input[0] = arg0;
+   buffer->input[1] = arg1;
+   buffer->input[2] = arg2;
+   buffer->input[3] = arg3;
+   ret = dell_smbios_call(buffer);
+   if (ret != 0)
+   return ret;
+   return dell_smbios_error(buffer->output[0]);
+}
+
 /*
  * Derived from information in smbios-wireless-ctl:
  *
@@ -405,7 +423,6 @@ static const struct dmi_system_id dell_quirks[] __initconst 
= {
 
 static int dell_rfkill_set(void *data, bool blocked)
 {
-   struct calling_interface_buffer *buffer;
int disable = blocked ? 1 : 0;
unsigned long radio = (unsigned long)data;
int hwswitch_bit = (unsigned long)data - 1;
@@ -413,20 +430,14 @@ static int dell_rfkill_set(void *data, bool blocked)
int status;
int ret;
 
-   buffer = dell_smbios_get_buffer();
-
-   

[PATCH v5 05/14] platform/x86: dell-wmi-descriptor: split WMI descriptor into it's own driver

2017-10-06 Thread Mario Limonciello
All communication on individual GUIDs should occur in separate drivers.
Allowing a driver to communicate with the bus to another GUID is just
a hack that discourages drivers to adopt the bus model.

The information found from the WMI descriptor driver is now exported
for use by other drivers.

Signed-off-by: Mario Limonciello 
---
 MAINTAINERS|   5 +
 drivers/platform/x86/Kconfig   |   5 +
 drivers/platform/x86/Makefile  |   1 +
 drivers/platform/x86/dell-wmi-descriptor.c | 162 +
 drivers/platform/x86/dell-wmi-descriptor.h |  18 
 drivers/platform/x86/dell-wmi.c|  89 ++--
 6 files changed, 198 insertions(+), 82 deletions(-)
 create mode 100644 drivers/platform/x86/dell-wmi-descriptor.c
 create mode 100644 drivers/platform/x86/dell-wmi-descriptor.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 08b96f77f618..659dbeec4191 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4002,6 +4002,11 @@ M:   Pali Rohár 
 S: Maintained
 F: drivers/platform/x86/dell-wmi.c
 
+DELL WMI DESCRIPTOR DRIVER
+M: Mario Limonciello 
+S: Maintained
+F: drivers/platform/x86/dell-wmi-descriptor.c
+
 DELTA ST MEDIA DRIVER
 M: Hugues Fruchet 
 L: linux-me...@vger.kernel.org
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 1f7959ff055c..7722923c968c 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -121,6 +121,7 @@ config DELL_WMI
depends on DMI
depends on INPUT
depends on ACPI_VIDEO || ACPI_VIDEO = n
+   select DELL_WMI_DESCRIPTOR
select DELL_SMBIOS
select INPUT_SPARSEKMAP
---help---
@@ -129,6 +130,10 @@ config DELL_WMI
  To compile this driver as a module, choose M here: the module will
  be called dell-wmi.
 
+config DELL_WMI_DESCRIPTOR
+   tristate
+   depends on ACPI_WMI
+
 config DELL_WMI_AIO
tristate "WMI Hotkeys for Dell All-In-One series"
depends on ACPI_WMI
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 2b315d0df3b7..8636f5d3424f 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_COMPAL_LAPTOP)   += compal-laptop.o
 obj-$(CONFIG_DELL_SMBIOS)  += dell-smbios.o
 obj-$(CONFIG_DELL_LAPTOP)  += dell-laptop.o
 obj-$(CONFIG_DELL_WMI) += dell-wmi.o
+obj-$(CONFIG_DELL_WMI_DESCRIPTOR)  += dell-wmi-descriptor.o
 obj-$(CONFIG_DELL_WMI_AIO) += dell-wmi-aio.o
 obj-$(CONFIG_DELL_WMI_LED) += dell-wmi-led.o
 obj-$(CONFIG_DELL_SMO8800) += dell-smo8800.o
diff --git a/drivers/platform/x86/dell-wmi-descriptor.c 
b/drivers/platform/x86/dell-wmi-descriptor.c
new file mode 100644
index ..72e317cf0365
--- /dev/null
+++ b/drivers/platform/x86/dell-wmi-descriptor.c
@@ -0,0 +1,162 @@
+/*
+ * Dell WMI descriptor driver
+ *
+ * Copyright (C) 2017 Dell Inc. All Rights Reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License version 2 as published
+ *  by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include "dell-wmi-descriptor.h"
+
+#define DELL_WMI_DESCRIPTOR_GUID "8D9DDCBC-A997-11DA-B012-B622A1EF5492"
+
+struct descriptor_priv {
+   struct list_head list;
+   u32 interface_version;
+   u32 size;
+};
+static LIST_HEAD(wmi_list);
+
+bool dell_wmi_get_interface_version(u32 *version)
+{
+   struct descriptor_priv *priv;
+
+   priv = list_first_entry_or_null(_list,
+   struct descriptor_priv,
+   list);
+   if (!priv)
+   return false;
+   *version = priv->interface_version;
+   return true;
+}
+EXPORT_SYMBOL_GPL(dell_wmi_get_interface_version);
+
+bool dell_wmi_get_size(u32 *size)
+{
+   struct descriptor_priv *priv;
+
+   priv = list_first_entry_or_null(_list,
+   struct descriptor_priv,
+   list);
+   if (!priv)
+   return false;
+   *size = priv->size;
+   return true;
+}
+EXPORT_SYMBOL_GPL(dell_wmi_get_size);
+
+/*
+ * Descriptor buffer is 128 byte long and contains:
+ *
+ *   Name Offset  Length  Value
+ * Vendor Signature  0   4"DELL"
+ * Object Signature  4   4" WMI"
+ * WMI Interface Version 8   4
+ * WMI buffer length12   

[PATCH v5 00/14] Introduce support for Dell SMBIOS over WMI

2017-10-06 Thread Mario Limonciello
The existing way that the dell-smbios helper module and associated
other drivers (dell-laptop, dell-wmi) communicate with the platform
really isn't secure.  It requires creating a buffer in physical
DMA32 memory space and passing that to the platform via SMM.

Since the platform got a physical memory pointer, you've just got
to trust that the platform has only modified (and accessed) memory
within that buffer.

Dell Platform designers recognize this security risk and offer a
safer way to communicate with the platform over ACPI.  This is
in turn exposed via a WMI interface to the OS.

When communicating over WMI-ACPI the communication doesn't occur
with physical memory pointers.  When the ASL is invoked, the fixed
length ACPI buffer is copied to a small operating region.  The ASL
will invoke the SMI, and SMM will only have access to this operating
region.  When the ASL returns the buffer is copied back for the OS
to process.

This method of communication should also deprecate the usage of the
dcdbas kernel module and software dependent upon it's interface.
Instead offer a character device interface for communicating with this
ASL method to allow userspace to use instead.

To faciliate that this patch series introduces a generic way for WMI
drivers to be able to create discoverable character devices with
a predictable IOCTL interface through the WMI bus when desired.
Requiring WMI drivers to explicitly ask for this functionality will
act as an effective vendor whitelist to character device creation.

Some of this work is the basis for what will be a proper interpreter
of MOF in the kernel and controls for what drivers will be able to
do with that MOF.

NOTE: This patch series is intended to go on top of platform-drivers-x86
linux-next.

For convenience the entire series including those is also available here:
https://github.com/superm1/linux/tree/wmi-smbios
changes between v4 and v5:
 * Remove Andy's S suggested by in sysfs tokens patch
 * Make some output in dell-wmi-descriptor debug only
 * Adjust various Kconfig dependencies as recommended by Darren
 * Drop patch to set dell-smbios to default on ACPI_WMI,
   it's not needed after the Kconfig dependencies rework
 * Move WSMT check patch to after WMI driver is introduced.
 * Make common smbios call return value int as there could be
   errors now with drivers not being loaded.
 * Make SMBIOS call methods for all drivers return status
 * Reorder patches 2 and 4.
 * Don't export symbols for calling functions on dispatchers
 * wmi patch:
   - use sprintf instead of strcpy
   - remove needless bool for tracking found
   - adjust logic to look for instance_count - 1, it's zero
 based not 1 based.
   - Pass a callback to unlocked_ioctl instead of full file
 operations object
   - ioctl: Don't fail on no bound WMI driver
   - Add missing header for uapi
   - Make helper macros include data types
   - add compat ioctl
 * dell-smbios:
   - Add filtering functionality for SMBIOS calling interface
   - Use dev_dbg rather than pr_debug where possible
 * dell-smbios-wmi:
   - test for handle on b1 table
   - correct misc flags comment
   - drop access checks
   - use dev_dbg instead of pr_* calls
   - use filtering functionality
   - add mutexes around list add/remove
   - switch from get_first_device to get_first_priv and inline
   - add mutex locking to prevent unloading mid-call.
   - update to new ioctl passing
   - fix userspace uapi to use __u32 instead of u32
   - Don't use a header file for internal only use
   - make sure it works with compat ioctl
 * dell-laptop: make dell_smbios_send_request local function
   for boilerplate calls.
 * ioctl patch
   - Change API to have a simpler structure to pass back and
 forth
   - Rename header file
   - Export to sysfs properly
   - Add the size of the length variable into the requested
 buffersize to sysfs, do math in the driver when copying
 data around.
changes between v3 and v4:
 * Make Dell WMI notifications driver fail notifications fail
   when WMI descriptor driver is unavailable.
 * Add a patch to check for Dell OEM string to stop dell-smbios 
   module from being loaded in unsupported systems manually.
 * Split Dell WMI descriptor into it's own driver for others to
   query.
 * Test the misc BIOS flags table to decide whether to run in WMI
   or SMI mode.
 * s/dell-wmi-smbios/dell-smbios/ in a few patch titles
 * Add missing Suggested-by to a patch from v2 (Sorry Andy S!)
 * Adjust cleanup order of wmi character device.
 * Fix a remaining reference to /dev/wmi-$driver
 * Use get_order to get size for pages
 * Split up dell-smbios into 3 drivers:
   dell-smbios
   -> dell-smbios-smm
   -> dell-smbios-wmi
   If either of the two dispatcher drivers is unloaded but
   the other still works, gracefully fall back to that driver
 * Remove unneded open and release on file operations in WMI
   driver
 * Switch to misc character device in WMI bus.
 * Query the size of the calling interface buffer 

[PATCH v5 09/14] platform/x86: dell-smbios: Introduce dispatcher for SMM calls

2017-10-06 Thread Mario Limonciello
This splits up the dell-smbios driver into two drivers:
* dell-smbios
* dell-smbios-smm

dell-smbios can operate with multiple different dispatcher drivers to
perform SMBIOS operations.

Also modify the interface that dell-laptop and dell-wmi use align to this
model more closely.  Rather than a single global buffer being allocated
for all drivers, each driver will allocate and be responsible for it's own
buffer. The pointer will be passed to the calling function and each
dispatcher driver will then internally copy it to the proper location to
perform it's call.

Signed-off-by: Mario Limonciello 
---
 MAINTAINERS|   6 +
 drivers/platform/x86/Kconfig   |  16 ++-
 drivers/platform/x86/Makefile  |   1 +
 drivers/platform/x86/dell-laptop.c | 255 -
 drivers/platform/x86/dell-smbios-smm.c | 136 ++
 drivers/platform/x86/dell-smbios.c | 123 ++--
 drivers/platform/x86/dell-smbios.h |  13 +-
 drivers/platform/x86/dell-wmi.c|  11 +-
 8 files changed, 338 insertions(+), 223 deletions(-)
 create mode 100644 drivers/platform/x86/dell-smbios-smm.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 2e3f2aea0370..8faf08ebcfee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3974,6 +3974,12 @@ L:   platform-driver-...@vger.kernel.org
 S: Maintained
 F: drivers/platform/x86/dell-smbios.*
 
+DELL SMBIOS SMM DRIVER
+M: Mario Limonciello 
+L: platform-driver-...@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/dell-smbios-smm.c
+
 DELL LAPTOP DRIVER
 M: Matthew Garrett 
 M: Pali Rohár 
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 7722923c968c..7cc91519bec8 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -93,12 +93,20 @@ config ASUS_LAPTOP
 
 config DELL_SMBIOS
tristate
-   select DCDBAS
+   depends on DELL_SMBIOS_SMM
+
+config DELL_SMBIOS_SMM
+   tristate "Dell SMBIOS calling interface (SMM implementation)"
+   depends on DCDBAS
+   default DCDBAS
+   select DELL_SMBIOS
---help---
-   This module provides common functions for kernel modules using
-   Dell SMBIOS.
+   This provides an implementation for the Dell SMBIOS calling interface
+   communicated over SMI/SMM.
 
-   If you have a Dell laptop, say Y or M here.
+   If you have a Dell computer from <=2017 you should say Y or M here.
+   If you aren't sure and this module doesn't work for your computer
+   it just won't load.
 
 config DELL_LAPTOP
tristate "Dell Laptop Extras"
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 8636f5d3424f..e743615241f8 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_MSI_LAPTOP)  += msi-laptop.o
 obj-$(CONFIG_ACPI_CMPC)+= classmate-laptop.o
 obj-$(CONFIG_COMPAL_LAPTOP)+= compal-laptop.o
 obj-$(CONFIG_DELL_SMBIOS)  += dell-smbios.o
+obj-$(CONFIG_DELL_SMBIOS_SMM)  += dell-smbios-smm.o
 obj-$(CONFIG_DELL_LAPTOP)  += dell-laptop.o
 obj-$(CONFIG_DELL_WMI) += dell-wmi.o
 obj-$(CONFIG_DELL_WMI_DESCRIPTOR)  += dell-wmi-descriptor.o
diff --git a/drivers/platform/x86/dell-laptop.c 
b/drivers/platform/x86/dell-laptop.c
index f42159fd2031..2f65f5c15d53 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -85,6 +85,7 @@ static struct platform_driver platform_driver = {
}
 };
 
+static struct calling_interface_buffer *buffer;
 static struct platform_device *platform_device;
 static struct backlight_device *dell_backlight_device;
 static struct rfkill *wifi_rfkill;
@@ -283,6 +284,23 @@ static const struct dmi_system_id dell_quirks[] 
__initconst = {
{ }
 };
 
+int dell_send_request(u16 class, u16 select, u32 arg0, u32 arg1, u32 arg2,
+  u32 arg3)
+{
+   int ret;
+
+   buffer->class = class;
+   buffer->select = select;
+   buffer->input[0] = arg0;
+   buffer->input[1] = arg1;
+   buffer->input[2] = arg2;
+   buffer->input[3] = arg3;
+   ret = dell_smbios_call(buffer);
+   if (ret != 0)
+   return ret;
+   return dell_smbios_error(buffer->output[0]);
+}
+
 /*
  * Derived from information in smbios-wireless-ctl:
  *
@@ -405,7 +423,6 @@ static const struct dmi_system_id dell_quirks[] __initconst 
= {
 
 static int dell_rfkill_set(void *data, bool blocked)
 {
-   struct calling_interface_buffer *buffer;
int disable = blocked ? 1 : 0;
unsigned long radio = (unsigned long)data;
int hwswitch_bit = (unsigned long)data - 1;
@@ -413,20 +430,14 @@ static int dell_rfkill_set(void *data, bool blocked)
int status;
int ret;
 
-   buffer = dell_smbios_get_buffer();
-
-   dell_smbios_send_request(17, 11);
-   ret = buffer->output[0];
+   ret = 

[PATCH v5 05/14] platform/x86: dell-wmi-descriptor: split WMI descriptor into it's own driver

2017-10-06 Thread Mario Limonciello
All communication on individual GUIDs should occur in separate drivers.
Allowing a driver to communicate with the bus to another GUID is just
a hack that discourages drivers to adopt the bus model.

The information found from the WMI descriptor driver is now exported
for use by other drivers.

Signed-off-by: Mario Limonciello 
---
 MAINTAINERS|   5 +
 drivers/platform/x86/Kconfig   |   5 +
 drivers/platform/x86/Makefile  |   1 +
 drivers/platform/x86/dell-wmi-descriptor.c | 162 +
 drivers/platform/x86/dell-wmi-descriptor.h |  18 
 drivers/platform/x86/dell-wmi.c|  89 ++--
 6 files changed, 198 insertions(+), 82 deletions(-)
 create mode 100644 drivers/platform/x86/dell-wmi-descriptor.c
 create mode 100644 drivers/platform/x86/dell-wmi-descriptor.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 08b96f77f618..659dbeec4191 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4002,6 +4002,11 @@ M:   Pali Rohár 
 S: Maintained
 F: drivers/platform/x86/dell-wmi.c
 
+DELL WMI DESCRIPTOR DRIVER
+M: Mario Limonciello 
+S: Maintained
+F: drivers/platform/x86/dell-wmi-descriptor.c
+
 DELTA ST MEDIA DRIVER
 M: Hugues Fruchet 
 L: linux-me...@vger.kernel.org
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 1f7959ff055c..7722923c968c 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -121,6 +121,7 @@ config DELL_WMI
depends on DMI
depends on INPUT
depends on ACPI_VIDEO || ACPI_VIDEO = n
+   select DELL_WMI_DESCRIPTOR
select DELL_SMBIOS
select INPUT_SPARSEKMAP
---help---
@@ -129,6 +130,10 @@ config DELL_WMI
  To compile this driver as a module, choose M here: the module will
  be called dell-wmi.
 
+config DELL_WMI_DESCRIPTOR
+   tristate
+   depends on ACPI_WMI
+
 config DELL_WMI_AIO
tristate "WMI Hotkeys for Dell All-In-One series"
depends on ACPI_WMI
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 2b315d0df3b7..8636f5d3424f 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_COMPAL_LAPTOP)   += compal-laptop.o
 obj-$(CONFIG_DELL_SMBIOS)  += dell-smbios.o
 obj-$(CONFIG_DELL_LAPTOP)  += dell-laptop.o
 obj-$(CONFIG_DELL_WMI) += dell-wmi.o
+obj-$(CONFIG_DELL_WMI_DESCRIPTOR)  += dell-wmi-descriptor.o
 obj-$(CONFIG_DELL_WMI_AIO) += dell-wmi-aio.o
 obj-$(CONFIG_DELL_WMI_LED) += dell-wmi-led.o
 obj-$(CONFIG_DELL_SMO8800) += dell-smo8800.o
diff --git a/drivers/platform/x86/dell-wmi-descriptor.c 
b/drivers/platform/x86/dell-wmi-descriptor.c
new file mode 100644
index ..72e317cf0365
--- /dev/null
+++ b/drivers/platform/x86/dell-wmi-descriptor.c
@@ -0,0 +1,162 @@
+/*
+ * Dell WMI descriptor driver
+ *
+ * Copyright (C) 2017 Dell Inc. All Rights Reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License version 2 as published
+ *  by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include "dell-wmi-descriptor.h"
+
+#define DELL_WMI_DESCRIPTOR_GUID "8D9DDCBC-A997-11DA-B012-B622A1EF5492"
+
+struct descriptor_priv {
+   struct list_head list;
+   u32 interface_version;
+   u32 size;
+};
+static LIST_HEAD(wmi_list);
+
+bool dell_wmi_get_interface_version(u32 *version)
+{
+   struct descriptor_priv *priv;
+
+   priv = list_first_entry_or_null(_list,
+   struct descriptor_priv,
+   list);
+   if (!priv)
+   return false;
+   *version = priv->interface_version;
+   return true;
+}
+EXPORT_SYMBOL_GPL(dell_wmi_get_interface_version);
+
+bool dell_wmi_get_size(u32 *size)
+{
+   struct descriptor_priv *priv;
+
+   priv = list_first_entry_or_null(_list,
+   struct descriptor_priv,
+   list);
+   if (!priv)
+   return false;
+   *size = priv->size;
+   return true;
+}
+EXPORT_SYMBOL_GPL(dell_wmi_get_size);
+
+/*
+ * Descriptor buffer is 128 byte long and contains:
+ *
+ *   Name Offset  Length  Value
+ * Vendor Signature  0   4"DELL"
+ * Object Signature  4   4" WMI"
+ * WMI Interface Version 8   4
+ * WMI buffer length12   44096 or 32768
+ */
+static int dell_wmi_descriptor_probe(struct wmi_device *wdev)
+{
+   

[PATCH v5 00/14] Introduce support for Dell SMBIOS over WMI

2017-10-06 Thread Mario Limonciello
The existing way that the dell-smbios helper module and associated
other drivers (dell-laptop, dell-wmi) communicate with the platform
really isn't secure.  It requires creating a buffer in physical
DMA32 memory space and passing that to the platform via SMM.

Since the platform got a physical memory pointer, you've just got
to trust that the platform has only modified (and accessed) memory
within that buffer.

Dell Platform designers recognize this security risk and offer a
safer way to communicate with the platform over ACPI.  This is
in turn exposed via a WMI interface to the OS.

When communicating over WMI-ACPI the communication doesn't occur
with physical memory pointers.  When the ASL is invoked, the fixed
length ACPI buffer is copied to a small operating region.  The ASL
will invoke the SMI, and SMM will only have access to this operating
region.  When the ASL returns the buffer is copied back for the OS
to process.

This method of communication should also deprecate the usage of the
dcdbas kernel module and software dependent upon it's interface.
Instead offer a character device interface for communicating with this
ASL method to allow userspace to use instead.

To faciliate that this patch series introduces a generic way for WMI
drivers to be able to create discoverable character devices with
a predictable IOCTL interface through the WMI bus when desired.
Requiring WMI drivers to explicitly ask for this functionality will
act as an effective vendor whitelist to character device creation.

Some of this work is the basis for what will be a proper interpreter
of MOF in the kernel and controls for what drivers will be able to
do with that MOF.

NOTE: This patch series is intended to go on top of platform-drivers-x86
linux-next.

For convenience the entire series including those is also available here:
https://github.com/superm1/linux/tree/wmi-smbios
changes between v4 and v5:
 * Remove Andy's S suggested by in sysfs tokens patch
 * Make some output in dell-wmi-descriptor debug only
 * Adjust various Kconfig dependencies as recommended by Darren
 * Drop patch to set dell-smbios to default on ACPI_WMI,
   it's not needed after the Kconfig dependencies rework
 * Move WSMT check patch to after WMI driver is introduced.
 * Make common smbios call return value int as there could be
   errors now with drivers not being loaded.
 * Make SMBIOS call methods for all drivers return status
 * Reorder patches 2 and 4.
 * Don't export symbols for calling functions on dispatchers
 * wmi patch:
   - use sprintf instead of strcpy
   - remove needless bool for tracking found
   - adjust logic to look for instance_count - 1, it's zero
 based not 1 based.
   - Pass a callback to unlocked_ioctl instead of full file
 operations object
   - ioctl: Don't fail on no bound WMI driver
   - Add missing header for uapi
   - Make helper macros include data types
   - add compat ioctl
 * dell-smbios:
   - Add filtering functionality for SMBIOS calling interface
   - Use dev_dbg rather than pr_debug where possible
 * dell-smbios-wmi:
   - test for handle on b1 table
   - correct misc flags comment
   - drop access checks
   - use dev_dbg instead of pr_* calls
   - use filtering functionality
   - add mutexes around list add/remove
   - switch from get_first_device to get_first_priv and inline
   - add mutex locking to prevent unloading mid-call.
   - update to new ioctl passing
   - fix userspace uapi to use __u32 instead of u32
   - Don't use a header file for internal only use
   - make sure it works with compat ioctl
 * dell-laptop: make dell_smbios_send_request local function
   for boilerplate calls.
 * ioctl patch
   - Change API to have a simpler structure to pass back and
 forth
   - Rename header file
   - Export to sysfs properly
   - Add the size of the length variable into the requested
 buffersize to sysfs, do math in the driver when copying
 data around.
changes between v3 and v4:
 * Make Dell WMI notifications driver fail notifications fail
   when WMI descriptor driver is unavailable.
 * Add a patch to check for Dell OEM string to stop dell-smbios 
   module from being loaded in unsupported systems manually.
 * Split Dell WMI descriptor into it's own driver for others to
   query.
 * Test the misc BIOS flags table to decide whether to run in WMI
   or SMI mode.
 * s/dell-wmi-smbios/dell-smbios/ in a few patch titles
 * Add missing Suggested-by to a patch from v2 (Sorry Andy S!)
 * Adjust cleanup order of wmi character device.
 * Fix a remaining reference to /dev/wmi-$driver
 * Use get_order to get size for pages
 * Split up dell-smbios into 3 drivers:
   dell-smbios
   -> dell-smbios-smm
   -> dell-smbios-wmi
   If either of the two dispatcher drivers is unloaded but
   the other still works, gracefully fall back to that driver
 * Remove unneded open and release on file operations in WMI
   driver
 * Switch to misc character device in WMI bus.
 * Query the size of the calling interface buffer 

[PATCH v5 11/14] platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver

2017-10-06 Thread Mario Limonciello
The dell-smbios stack only currently uses an SMI interface which grants
direct access to physical memory to the firmware SMM methods via a pointer.

This dispatcher driver adds a WMI-ACPI interface that is detected by WMI
probe and preferred over the SMI interface in dell-smbios.

Changing this to operate over WMI-ACPI will use an ACPI OperationRegion
for a buffer of data storage when SMM calls are performed.

This is a safer approach to use in kernel drivers as the SMM will
only have access to that OperationRegion.

Signed-off-by: Mario Limonciello 
---
 MAINTAINERS|   6 +
 drivers/platform/x86/Kconfig   |  16 ++-
 drivers/platform/x86/Makefile  |   1 +
 drivers/platform/x86/dell-smbios-wmi.c | 229 +
 4 files changed, 251 insertions(+), 1 deletion(-)
 create mode 100644 drivers/platform/x86/dell-smbios-wmi.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 8faf08ebcfee..e7514b616e13 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3980,6 +3980,12 @@ L:   platform-driver-...@vger.kernel.org
 S: Maintained
 F: drivers/platform/x86/dell-smbios-smm.c
 
+DELL SMBIOS WMI DRIVER
+M: Mario Limonciello 
+L: platform-driver-...@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/dell-smbios-wmi.c
+
 DELL LAPTOP DRIVER
 M: Matthew Garrett 
 M: Pali Rohár 
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 7cc91519bec8..7b0b8379 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -93,7 +93,21 @@ config ASUS_LAPTOP
 
 config DELL_SMBIOS
tristate
-   depends on DELL_SMBIOS_SMM
+   depends on DELL_SMBIOS_WMI || DELL_SMBIOS_SMM
+
+config DELL_SMBIOS_WMI
+   tristate "Dell SMBIOS calling interface (WMI implementation)"
+   depends on ACPI_WMI
+   select DELL_WMI_DESCRIPTOR
+   default ACPI_WMI
+   select DELL_SMBIOS
+   ---help---
+   This provides an implementation for the Dell SMBIOS calling interface
+   communicated over ACPI-WMI.
+
+   If you have a Dell computer from >2007 you should say Y or M here.
+   If you aren't sure and this module doesn't work for your computer
+   it just won't load.
 
 config DELL_SMBIOS_SMM
tristate "Dell SMBIOS calling interface (SMM implementation)"
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index e743615241f8..1c4234861de0 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_MSI_LAPTOP)  += msi-laptop.o
 obj-$(CONFIG_ACPI_CMPC)+= classmate-laptop.o
 obj-$(CONFIG_COMPAL_LAPTOP)+= compal-laptop.o
 obj-$(CONFIG_DELL_SMBIOS)  += dell-smbios.o
+obj-$(CONFIG_DELL_SMBIOS_WMI)  += dell-smbios-wmi.o
 obj-$(CONFIG_DELL_SMBIOS_SMM)  += dell-smbios-smm.o
 obj-$(CONFIG_DELL_LAPTOP)  += dell-laptop.o
 obj-$(CONFIG_DELL_WMI) += dell-wmi.o
diff --git a/drivers/platform/x86/dell-smbios-wmi.c 
b/drivers/platform/x86/dell-smbios-wmi.c
new file mode 100644
index ..3de8abea38f8
--- /dev/null
+++ b/drivers/platform/x86/dell-smbios-wmi.c
@@ -0,0 +1,229 @@
+/*
+ *  WMI methods for use with dell-smbios
+ *
+ *  Copyright (c) 2017 Dell Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "dell-smbios.h"
+#include "dell-wmi-descriptor.h"
+static DEFINE_MUTEX(call_mutex);
+static DEFINE_MUTEX(list_mutex);
+static int wmi_supported;
+
+struct misc_bios_flags_structure {
+   struct dmi_header header;
+   u16 flags0;
+} __packed;
+#define FLAG_HAS_ACPI_WMI 0x02
+
+#define DELL_WMI_SMBIOS_GUID "A80593CE-A997-11DA-B012-B622A1EF5492"
+
+struct wmi_extensions {
+   __u32 argattrib;
+   __u32 blength;
+   __u8 data[];
+} __packed;
+
+struct wmi_smbios_buffer {
+   struct calling_interface_buffer std;
+   struct wmi_extensions ext;
+} __packed;
+
+struct wmi_smbios_priv {
+   struct wmi_smbios_buffer *buf;
+   struct list_head list;
+   struct wmi_device *wdev;
+   struct device *child;
+   u32 buffer_size;
+};
+static LIST_HEAD(wmi_list);
+
+static inline struct wmi_smbios_priv *get_first_smbios_priv(void)
+{
+   return list_first_entry_or_null(_list,
+   struct wmi_smbios_priv,
+   list);
+}
+
+static int run_smbios_call(struct wmi_device *wdev)
+{
+   struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+   struct wmi_smbios_priv *priv;
+   struct acpi_buffer input;
+   union acpi_object *obj;
+   acpi_status status;
+
+   

[PATCH v5 11/14] platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver

2017-10-06 Thread Mario Limonciello
The dell-smbios stack only currently uses an SMI interface which grants
direct access to physical memory to the firmware SMM methods via a pointer.

This dispatcher driver adds a WMI-ACPI interface that is detected by WMI
probe and preferred over the SMI interface in dell-smbios.

Changing this to operate over WMI-ACPI will use an ACPI OperationRegion
for a buffer of data storage when SMM calls are performed.

This is a safer approach to use in kernel drivers as the SMM will
only have access to that OperationRegion.

Signed-off-by: Mario Limonciello 
---
 MAINTAINERS|   6 +
 drivers/platform/x86/Kconfig   |  16 ++-
 drivers/platform/x86/Makefile  |   1 +
 drivers/platform/x86/dell-smbios-wmi.c | 229 +
 4 files changed, 251 insertions(+), 1 deletion(-)
 create mode 100644 drivers/platform/x86/dell-smbios-wmi.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 8faf08ebcfee..e7514b616e13 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3980,6 +3980,12 @@ L:   platform-driver-...@vger.kernel.org
 S: Maintained
 F: drivers/platform/x86/dell-smbios-smm.c
 
+DELL SMBIOS WMI DRIVER
+M: Mario Limonciello 
+L: platform-driver-...@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/dell-smbios-wmi.c
+
 DELL LAPTOP DRIVER
 M: Matthew Garrett 
 M: Pali Rohár 
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 7cc91519bec8..7b0b8379 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -93,7 +93,21 @@ config ASUS_LAPTOP
 
 config DELL_SMBIOS
tristate
-   depends on DELL_SMBIOS_SMM
+   depends on DELL_SMBIOS_WMI || DELL_SMBIOS_SMM
+
+config DELL_SMBIOS_WMI
+   tristate "Dell SMBIOS calling interface (WMI implementation)"
+   depends on ACPI_WMI
+   select DELL_WMI_DESCRIPTOR
+   default ACPI_WMI
+   select DELL_SMBIOS
+   ---help---
+   This provides an implementation for the Dell SMBIOS calling interface
+   communicated over ACPI-WMI.
+
+   If you have a Dell computer from >2007 you should say Y or M here.
+   If you aren't sure and this module doesn't work for your computer
+   it just won't load.
 
 config DELL_SMBIOS_SMM
tristate "Dell SMBIOS calling interface (SMM implementation)"
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index e743615241f8..1c4234861de0 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_MSI_LAPTOP)  += msi-laptop.o
 obj-$(CONFIG_ACPI_CMPC)+= classmate-laptop.o
 obj-$(CONFIG_COMPAL_LAPTOP)+= compal-laptop.o
 obj-$(CONFIG_DELL_SMBIOS)  += dell-smbios.o
+obj-$(CONFIG_DELL_SMBIOS_WMI)  += dell-smbios-wmi.o
 obj-$(CONFIG_DELL_SMBIOS_SMM)  += dell-smbios-smm.o
 obj-$(CONFIG_DELL_LAPTOP)  += dell-laptop.o
 obj-$(CONFIG_DELL_WMI) += dell-wmi.o
diff --git a/drivers/platform/x86/dell-smbios-wmi.c 
b/drivers/platform/x86/dell-smbios-wmi.c
new file mode 100644
index ..3de8abea38f8
--- /dev/null
+++ b/drivers/platform/x86/dell-smbios-wmi.c
@@ -0,0 +1,229 @@
+/*
+ *  WMI methods for use with dell-smbios
+ *
+ *  Copyright (c) 2017 Dell Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "dell-smbios.h"
+#include "dell-wmi-descriptor.h"
+static DEFINE_MUTEX(call_mutex);
+static DEFINE_MUTEX(list_mutex);
+static int wmi_supported;
+
+struct misc_bios_flags_structure {
+   struct dmi_header header;
+   u16 flags0;
+} __packed;
+#define FLAG_HAS_ACPI_WMI 0x02
+
+#define DELL_WMI_SMBIOS_GUID "A80593CE-A997-11DA-B012-B622A1EF5492"
+
+struct wmi_extensions {
+   __u32 argattrib;
+   __u32 blength;
+   __u8 data[];
+} __packed;
+
+struct wmi_smbios_buffer {
+   struct calling_interface_buffer std;
+   struct wmi_extensions ext;
+} __packed;
+
+struct wmi_smbios_priv {
+   struct wmi_smbios_buffer *buf;
+   struct list_head list;
+   struct wmi_device *wdev;
+   struct device *child;
+   u32 buffer_size;
+};
+static LIST_HEAD(wmi_list);
+
+static inline struct wmi_smbios_priv *get_first_smbios_priv(void)
+{
+   return list_first_entry_or_null(_list,
+   struct wmi_smbios_priv,
+   list);
+}
+
+static int run_smbios_call(struct wmi_device *wdev)
+{
+   struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+   struct wmi_smbios_priv *priv;
+   struct acpi_buffer input;
+   union acpi_object *obj;
+   acpi_status status;
+
+   priv = dev_get_drvdata(>dev);
+   input.length = priv->buffer_size;
+   input.pointer = 

[PATCH v5 10/14] platform/x86: dell-smbios: add filtering capability for requests

2017-10-06 Thread Mario Limonciello
There are some categories of tokens and SMBIOS calls that it makes
sense to protect userspace from accessing.  These are calls that
may write to one time use fields or activate hardware debugging
capabilities.  They are not intended for general purpose use.

This same functionality may be be later extended to also intercept
calls that may cause kernel functionality to get out of sync if
the same functions are used by other drivers.

Signed-off-by: Mario Limonciello 
---
 drivers/platform/x86/dell-smbios.c | 76 ++
 drivers/platform/x86/dell-smbios.h |  2 +
 2 files changed, 78 insertions(+)

diff --git a/drivers/platform/x86/dell-smbios.c 
b/drivers/platform/x86/dell-smbios.c
index 2f90ba5346bc..d1908f159be3 100644
--- a/drivers/platform/x86/dell-smbios.c
+++ b/drivers/platform/x86/dell-smbios.c
@@ -32,6 +32,7 @@ struct calling_interface_structure {
struct calling_interface_token tokens[];
 } __packed;
 
+static u32 da_supported_commands;
 static int da_command_address;
 static int da_command_code;
 static int da_num_tokens;
@@ -45,6 +46,14 @@ struct smbios_device {
int (*call_fn)(struct calling_interface_buffer *);
 };
 
+static u32 token_black[] = {
+   0x0175, 0x0176, 0x0195, 0x0196, 0x0197, 0x01DC, 0x01DD, 0x027D, 0x027E,
+   0x027F, 0x0280, 0x0281, 0x0282, 0x0283, 0x0284, 0x02E3, 0x02FF, 0x0300,
+   0x0301, 0x0302, 0x0325, 0x0326, 0x0332, 0x0333, 0x0334, 0x0335, 0x0350,
+   0x0363, 0x0368, 0x03F6, 0x03F7, 0x049E, 0x049F, 0x04A0, 0x04A1, 0x04A2,
+   0x04A3, 0x04E6, 0x04E7, 0x9000, 0x9001
+};
+
 static LIST_HEAD(smbios_device_list);
 
 void dell_smbios_get_smm_address(int *address, int *code)
@@ -104,6 +113,65 @@ void dell_smbios_unregister_device(struct device *d)
 }
 EXPORT_SYMBOL_GPL(dell_smbios_unregister_device);
 
+int dell_smbios_call_filter(struct device *d,
+   struct calling_interface_buffer *buffer)
+{
+   int i;
+   int j;
+   u32 t;
+
+   /* can't make calls over 30 */
+   if (buffer->class > 30) {
+   dev_dbg(d, "buffer->class too big: %d\n", buffer->class);
+   return -EINVAL;
+   }
+
+   /* supported calls on the particular system */
+   if (!(da_supported_commands & (1 << buffer->class))) {
+   dev_dbg(d, "invalid command, supported commands: 0x%8x\n",
+   da_supported_commands);
+   return -EINVAL;
+   }
+
+   /* diagonstics, debugging information or write once  */
+   if ((buffer->class == 01 && buffer->select == 07) ||
+   (buffer->class == 06 && buffer->select == 05) ||
+   (buffer->class == 11 && buffer->select == 03) ||
+   (buffer->class == 11 && buffer->select == 07) ||
+   (buffer->class == 11 && buffer->select == 11) ||
+buffer->class == 19) {
+   dev_dbg(d, "blacklisted command: %d/%d\n",
+   buffer->class, buffer->select);
+   return -EINVAL;
+   }
+
+   /* reading/writing tokens*/
+   if ((buffer->class == 0 && buffer->select < 3) ||
+   (buffer->class == 1 && buffer->select < 3)) {
+   for (i = 0; i < da_num_tokens; i++) {
+   if (da_tokens[i].location != buffer->input[0])
+   continue;
+   /*blacklist reading and writing these */
+   t = da_tokens[i].tokenID;
+   if ((t >= 0x4000 && t <= 0x7FFF) ||
+   (t >= 0xA000 && t <= 0xBFFF) ||
+   (t >= 0xEFF0 && t <= 0xEFFF))
+   return -EINVAL;
+   for (j = 0; j < ARRAY_SIZE(token_black); j++)
+   if (t == token_black[j])
+   return -EINVAL;
+   /* token exists and is OK */
+   return 0;
+   }
+   /* token didn't exist */
+   dev_dbg(d, "token at location %u doesn't exist\n",
+   buffer->input[0]);
+   return -EINVAL;
+   }
+   return 0;
+}
+EXPORT_SYMBOL_GPL(dell_smbios_call_filter);
+
 int dell_smbios_call(struct calling_interface_buffer *buffer)
 {
int (*call_fn)(struct calling_interface_buffer *) = NULL;
@@ -127,6 +195,13 @@ int dell_smbios_call(struct calling_interface_buffer 
*buffer)
goto out_smbios_call;
}
 
+   if (dell_smbios_call_filter(selected_dev, buffer)) {
+   ret = -EINVAL;
+   dev_err(selected_dev, "Invalid call %d/%d:%8x\n",
+   buffer->class, buffer->select, buffer->input[0]);
+   goto out_smbios_call;
+   }
+
ret = call_fn(buffer);
 
 out_smbios_call:
@@ -184,6 +259,7 @@ static void __init parse_da_table(const struct dmi_header 
*dm)
 
da_command_address = 

[PATCH v5 10/14] platform/x86: dell-smbios: add filtering capability for requests

2017-10-06 Thread Mario Limonciello
There are some categories of tokens and SMBIOS calls that it makes
sense to protect userspace from accessing.  These are calls that
may write to one time use fields or activate hardware debugging
capabilities.  They are not intended for general purpose use.

This same functionality may be be later extended to also intercept
calls that may cause kernel functionality to get out of sync if
the same functions are used by other drivers.

Signed-off-by: Mario Limonciello 
---
 drivers/platform/x86/dell-smbios.c | 76 ++
 drivers/platform/x86/dell-smbios.h |  2 +
 2 files changed, 78 insertions(+)

diff --git a/drivers/platform/x86/dell-smbios.c 
b/drivers/platform/x86/dell-smbios.c
index 2f90ba5346bc..d1908f159be3 100644
--- a/drivers/platform/x86/dell-smbios.c
+++ b/drivers/platform/x86/dell-smbios.c
@@ -32,6 +32,7 @@ struct calling_interface_structure {
struct calling_interface_token tokens[];
 } __packed;
 
+static u32 da_supported_commands;
 static int da_command_address;
 static int da_command_code;
 static int da_num_tokens;
@@ -45,6 +46,14 @@ struct smbios_device {
int (*call_fn)(struct calling_interface_buffer *);
 };
 
+static u32 token_black[] = {
+   0x0175, 0x0176, 0x0195, 0x0196, 0x0197, 0x01DC, 0x01DD, 0x027D, 0x027E,
+   0x027F, 0x0280, 0x0281, 0x0282, 0x0283, 0x0284, 0x02E3, 0x02FF, 0x0300,
+   0x0301, 0x0302, 0x0325, 0x0326, 0x0332, 0x0333, 0x0334, 0x0335, 0x0350,
+   0x0363, 0x0368, 0x03F6, 0x03F7, 0x049E, 0x049F, 0x04A0, 0x04A1, 0x04A2,
+   0x04A3, 0x04E6, 0x04E7, 0x9000, 0x9001
+};
+
 static LIST_HEAD(smbios_device_list);
 
 void dell_smbios_get_smm_address(int *address, int *code)
@@ -104,6 +113,65 @@ void dell_smbios_unregister_device(struct device *d)
 }
 EXPORT_SYMBOL_GPL(dell_smbios_unregister_device);
 
+int dell_smbios_call_filter(struct device *d,
+   struct calling_interface_buffer *buffer)
+{
+   int i;
+   int j;
+   u32 t;
+
+   /* can't make calls over 30 */
+   if (buffer->class > 30) {
+   dev_dbg(d, "buffer->class too big: %d\n", buffer->class);
+   return -EINVAL;
+   }
+
+   /* supported calls on the particular system */
+   if (!(da_supported_commands & (1 << buffer->class))) {
+   dev_dbg(d, "invalid command, supported commands: 0x%8x\n",
+   da_supported_commands);
+   return -EINVAL;
+   }
+
+   /* diagonstics, debugging information or write once  */
+   if ((buffer->class == 01 && buffer->select == 07) ||
+   (buffer->class == 06 && buffer->select == 05) ||
+   (buffer->class == 11 && buffer->select == 03) ||
+   (buffer->class == 11 && buffer->select == 07) ||
+   (buffer->class == 11 && buffer->select == 11) ||
+buffer->class == 19) {
+   dev_dbg(d, "blacklisted command: %d/%d\n",
+   buffer->class, buffer->select);
+   return -EINVAL;
+   }
+
+   /* reading/writing tokens*/
+   if ((buffer->class == 0 && buffer->select < 3) ||
+   (buffer->class == 1 && buffer->select < 3)) {
+   for (i = 0; i < da_num_tokens; i++) {
+   if (da_tokens[i].location != buffer->input[0])
+   continue;
+   /*blacklist reading and writing these */
+   t = da_tokens[i].tokenID;
+   if ((t >= 0x4000 && t <= 0x7FFF) ||
+   (t >= 0xA000 && t <= 0xBFFF) ||
+   (t >= 0xEFF0 && t <= 0xEFFF))
+   return -EINVAL;
+   for (j = 0; j < ARRAY_SIZE(token_black); j++)
+   if (t == token_black[j])
+   return -EINVAL;
+   /* token exists and is OK */
+   return 0;
+   }
+   /* token didn't exist */
+   dev_dbg(d, "token at location %u doesn't exist\n",
+   buffer->input[0]);
+   return -EINVAL;
+   }
+   return 0;
+}
+EXPORT_SYMBOL_GPL(dell_smbios_call_filter);
+
 int dell_smbios_call(struct calling_interface_buffer *buffer)
 {
int (*call_fn)(struct calling_interface_buffer *) = NULL;
@@ -127,6 +195,13 @@ int dell_smbios_call(struct calling_interface_buffer 
*buffer)
goto out_smbios_call;
}
 
+   if (dell_smbios_call_filter(selected_dev, buffer)) {
+   ret = -EINVAL;
+   dev_err(selected_dev, "Invalid call %d/%d:%8x\n",
+   buffer->class, buffer->select, buffer->input[0]);
+   goto out_smbios_call;
+   }
+
ret = call_fn(buffer);
 
 out_smbios_call:
@@ -184,6 +259,7 @@ static void __init parse_da_table(const struct dmi_header 
*dm)
 
da_command_address = table->cmdIOAddress;
da_command_code 

[PATCH v5 13/14] platform/x86: wmi: create character devices when requested by drivers

2017-10-06 Thread Mario Limonciello
For WMI operations that are only Set or Query read or write sysfs
attributes created by WMI vendor drivers make sense.

For other WMI operations that are run on Method, there needs to be a
way to guarantee to userspace that the results from the method call
belong to the data request to the method call.  Sysfs attributes don't
work well in this scenario because two userspace processes may be
competing at reading/writing an attribute and step on each other's
data.

When a WMI vendor driver declares an ioctl callback in the wmi_driver
the WMI bus driver will create a character device that maps to that
function.

That character device will correspond to this path:
/dev/wmi/$driver

The WMI bus driver will interpret the IOCTL calls, test them for
a valid instance and pass them on to the vendor driver to run.

This creates an implicit policy that only driver per character
device.  If a module matches multiple GUID's, the wmi_devices
will need to be all handled by the same wmi_driver if the same
character device is used.

The WMI vendor drivers will be responsible for managing access to
this character device and proper locking on it.

When a WMI vendor driver is unloaded the WMI bus driver will clean
up the character device.

Signed-off-by: Mario Limonciello 
---
 MAINTAINERS|  1 +
 drivers/platform/x86/wmi.c | 85 ++
 include/linux/wmi.h|  5 +++
 include/uapi/linux/wmi.h   | 19 +++
 4 files changed, 110 insertions(+)
 create mode 100644 include/uapi/linux/wmi.h

diff --git a/MAINTAINERS b/MAINTAINERS
index e7514b616e13..2a99ee9fd883 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -372,6 +372,7 @@ ACPI WMI DRIVER
 L: platform-driver-...@vger.kernel.org
 S: Orphan
 F: drivers/platform/x86/wmi.c
+F: include/uapi/linux/wmi.h
 
 AD1889 ALSA SOUND DRIVER
 M: Thibaut Varene 
diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index bcb41c1c7f52..114d28aafa16 100644
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -69,6 +70,7 @@ struct wmi_block {
struct wmi_device dev;
struct list_head list;
struct guid_block gblock;
+   struct miscdevice misc_dev;
struct acpi_device *acpi_device;
wmi_notify_handler handler;
void *handler_data;
@@ -765,12 +767,90 @@ static int wmi_dev_match(struct device *dev, struct 
device_driver *driver)
return 0;
 }
 
+static int match_ioctl(struct file *filp, unsigned int cmd, unsigned long arg,
+  int compat)
+{
+   struct wmi_driver *wdriver = NULL;
+   struct wmi_block *wblock = NULL;
+   const char *driver_name;
+   struct list_head *p;
+
+   if (_IOC_TYPE(cmd) != WMI_IOC)
+   return -ENOTTY;
+
+   driver_name = filp->f_path.dentry->d_iname;
+
+   list_for_each(p, _block_list) {
+   wblock = list_entry(p, struct wmi_block, list);
+   wdriver = container_of(wblock->dev.dev.driver,
+   struct wmi_driver, driver);
+   if (!wdriver)
+   continue;
+   if (strcmp(driver_name, wdriver->driver.name) == 0)
+   break;
+   }
+
+   if (!wdriver)
+   return -ENODEV;
+
+   /* make sure we're not calling a higher instance than exists*/
+   if (_IOC_NR(cmd) > wblock->gblock.instance_count - 1)
+   return -EINVAL;
+
+   if (!compat)
+   return wdriver->unlocked_ioctl(>dev, cmd, arg);
+
+   /* not all vendor drivers may specify this */
+   if (!wdriver->compat_ioctl)
+   return -ENODEV;
+
+   return wdriver->compat_ioctl(>dev, cmd, arg);
+}
+
+static long wmi_unlocked_ioctl(struct file *filp, unsigned int cmd,
+  unsigned long arg)
+{
+   return match_ioctl(filp, cmd, arg, 0);
+}
+
+static long wmi_compat_ioctl(struct file *filp, unsigned int cmd,
+unsigned long arg)
+{
+   return match_ioctl(filp, cmd, arg, 1);
+}
+
+static const struct file_operations wmi_fops = {
+   .owner  = THIS_MODULE,
+   .unlocked_ioctl = wmi_unlocked_ioctl,
+#ifdef CONFIG_COMPAT
+   .compat_ioctl = wmi_compat_ioctl,
+#endif
+};
+
 static int wmi_dev_probe(struct device *dev)
 {
struct wmi_block *wblock = dev_to_wblock(dev);
struct wmi_driver *wdriver =
container_of(dev->driver, struct wmi_driver, driver);
int ret = 0;
+   char *buf;
+
+   /* driver wants a character device made */
+   if (wdriver->unlocked_ioctl) {
+   buf = kmalloc(strlen(wdriver->driver.name) + 4, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+   sprintf(buf, "wmi/%s", 

[PATCH v5 13/14] platform/x86: wmi: create character devices when requested by drivers

2017-10-06 Thread Mario Limonciello
For WMI operations that are only Set or Query read or write sysfs
attributes created by WMI vendor drivers make sense.

For other WMI operations that are run on Method, there needs to be a
way to guarantee to userspace that the results from the method call
belong to the data request to the method call.  Sysfs attributes don't
work well in this scenario because two userspace processes may be
competing at reading/writing an attribute and step on each other's
data.

When a WMI vendor driver declares an ioctl callback in the wmi_driver
the WMI bus driver will create a character device that maps to that
function.

That character device will correspond to this path:
/dev/wmi/$driver

The WMI bus driver will interpret the IOCTL calls, test them for
a valid instance and pass them on to the vendor driver to run.

This creates an implicit policy that only driver per character
device.  If a module matches multiple GUID's, the wmi_devices
will need to be all handled by the same wmi_driver if the same
character device is used.

The WMI vendor drivers will be responsible for managing access to
this character device and proper locking on it.

When a WMI vendor driver is unloaded the WMI bus driver will clean
up the character device.

Signed-off-by: Mario Limonciello 
---
 MAINTAINERS|  1 +
 drivers/platform/x86/wmi.c | 85 ++
 include/linux/wmi.h|  5 +++
 include/uapi/linux/wmi.h   | 19 +++
 4 files changed, 110 insertions(+)
 create mode 100644 include/uapi/linux/wmi.h

diff --git a/MAINTAINERS b/MAINTAINERS
index e7514b616e13..2a99ee9fd883 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -372,6 +372,7 @@ ACPI WMI DRIVER
 L: platform-driver-...@vger.kernel.org
 S: Orphan
 F: drivers/platform/x86/wmi.c
+F: include/uapi/linux/wmi.h
 
 AD1889 ALSA SOUND DRIVER
 M: Thibaut Varene 
diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index bcb41c1c7f52..114d28aafa16 100644
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -69,6 +70,7 @@ struct wmi_block {
struct wmi_device dev;
struct list_head list;
struct guid_block gblock;
+   struct miscdevice misc_dev;
struct acpi_device *acpi_device;
wmi_notify_handler handler;
void *handler_data;
@@ -765,12 +767,90 @@ static int wmi_dev_match(struct device *dev, struct 
device_driver *driver)
return 0;
 }
 
+static int match_ioctl(struct file *filp, unsigned int cmd, unsigned long arg,
+  int compat)
+{
+   struct wmi_driver *wdriver = NULL;
+   struct wmi_block *wblock = NULL;
+   const char *driver_name;
+   struct list_head *p;
+
+   if (_IOC_TYPE(cmd) != WMI_IOC)
+   return -ENOTTY;
+
+   driver_name = filp->f_path.dentry->d_iname;
+
+   list_for_each(p, _block_list) {
+   wblock = list_entry(p, struct wmi_block, list);
+   wdriver = container_of(wblock->dev.dev.driver,
+   struct wmi_driver, driver);
+   if (!wdriver)
+   continue;
+   if (strcmp(driver_name, wdriver->driver.name) == 0)
+   break;
+   }
+
+   if (!wdriver)
+   return -ENODEV;
+
+   /* make sure we're not calling a higher instance than exists*/
+   if (_IOC_NR(cmd) > wblock->gblock.instance_count - 1)
+   return -EINVAL;
+
+   if (!compat)
+   return wdriver->unlocked_ioctl(>dev, cmd, arg);
+
+   /* not all vendor drivers may specify this */
+   if (!wdriver->compat_ioctl)
+   return -ENODEV;
+
+   return wdriver->compat_ioctl(>dev, cmd, arg);
+}
+
+static long wmi_unlocked_ioctl(struct file *filp, unsigned int cmd,
+  unsigned long arg)
+{
+   return match_ioctl(filp, cmd, arg, 0);
+}
+
+static long wmi_compat_ioctl(struct file *filp, unsigned int cmd,
+unsigned long arg)
+{
+   return match_ioctl(filp, cmd, arg, 1);
+}
+
+static const struct file_operations wmi_fops = {
+   .owner  = THIS_MODULE,
+   .unlocked_ioctl = wmi_unlocked_ioctl,
+#ifdef CONFIG_COMPAT
+   .compat_ioctl = wmi_compat_ioctl,
+#endif
+};
+
 static int wmi_dev_probe(struct device *dev)
 {
struct wmi_block *wblock = dev_to_wblock(dev);
struct wmi_driver *wdriver =
container_of(dev->driver, struct wmi_driver, driver);
int ret = 0;
+   char *buf;
+
+   /* driver wants a character device made */
+   if (wdriver->unlocked_ioctl) {
+   buf = kmalloc(strlen(wdriver->driver.name) + 4, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+   sprintf(buf, "wmi/%s", wdriver->driver.name);
+   wblock->misc_dev.minor = 

[PATCH v5 14/14] platform/x86: dell-smbios-wmi: introduce userspace interface

2017-10-06 Thread Mario Limonciello
It's important for the driver to provide a R/W ioctl to ensure that
two competing userspace processes don't race to provide or read each
others data.

This userspace character device will be used to perform SMBIOS calls
from any applications.

It provides an ioctl that will allow passing the WMI calling
interface buffer between userspace and kernel space.

This character device is intended to deprecate the dcdbas kernel module
and the interface that it provides to userspace.

To use the character device the buffer needed for the machine will
also be needed.  This information is exported to a sysfs attribute.

The API for interacting with this interface is defined in documentation
as well as a uapi header provides the format of the structures.

Signed-off-by: Mario Limonciello 
---
 Documentation/ABI/testing/dell-smbios-wmi  |  41 
 .../ABI/testing/sysfs-platform-dell-smbios-wmi |  10 ++
 MAINTAINERS|   1 +
 drivers/platform/x86/dell-smbios-wmi.c | 104 ++---
 drivers/platform/x86/dell-smbios.h |  11 +--
 include/uapi/linux/dell-smbios.h   |  42 +
 6 files changed, 188 insertions(+), 21 deletions(-)
 create mode 100644 Documentation/ABI/testing/dell-smbios-wmi
 create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-smbios-wmi
 create mode 100644 include/uapi/linux/dell-smbios.h

diff --git a/Documentation/ABI/testing/dell-smbios-wmi 
b/Documentation/ABI/testing/dell-smbios-wmi
new file mode 100644
index ..e067e955fcc9
--- /dev/null
+++ b/Documentation/ABI/testing/dell-smbios-wmi
@@ -0,0 +1,41 @@
+What:  /dev/wmi/dell-smbios
+Date:  November 2017
+KernelVersion: 4.15
+Contact:   "Mario Limonciello" 
+Description:
+   Perform SMBIOS calls on supported Dell machines.
+   through the Dell ACPI-WMI interface.
+
+   IOCTL's and buffer formats are defined in:
+   
+
+   1) To perform a call from userspace, you'll need to first
+   determine the minimum size of the calling interface buffer
+   for your machine.
+   Platforms that contain larger buffers can return larger
+   objects from the system firmware.
+   Commonly this size is either 4k or 32k.
+
+   To determine the size of the buffer, refer to:
+   sysfs-platform-dell-smbios-wmi
+
+   2) After you've determined the minimum size of the calling
+   interface buffer, you can allocate a structure that represents
+   the structure documented above.
+
+   3) In the 'length' object store the size of the buffer you
+   determined above and allocated.
+
+   4) In this buffer object, prepare as necessary for the SMBIOS
+   call you're interested in.  Typically SMBIOS buffers have
+   "class", "select", and "input" defined to values that coincide
+   with the data you are interested in.
+   Documenting class/select/input values is outside of the scope
+   of this documentation. Check with the libsmbios project for
+   further documentation on these values.
+
+   6) Run the call by using ioctl() as described in the header.
+
+   7) The output will be returned in the buffer object.
+
+   8) Be sure to free up your allocated object.
diff --git a/Documentation/ABI/testing/sysfs-platform-dell-smbios-wmi 
b/Documentation/ABI/testing/sysfs-platform-dell-smbios-wmi
new file mode 100644
index ..6a0513703a3c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-dell-smbios-wmi
@@ -0,0 +1,10 @@
+What:  /sys/devices/platform//buffer_size
+Date:  November 2017
+KernelVersion: 4.15
+Contact:   "Mario Limonciello" 
+Description:
+   A read-only description of the size of a calling
+   interface buffer that can be passed to Dell
+   firmware.
+
+   Commonly this size is either 4k or 32k.
diff --git a/MAINTAINERS b/MAINTAINERS
index 2a99ee9fd883..4940f3c7481b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3986,6 +3986,7 @@ M:Mario Limonciello 
 L: platform-driver-...@vger.kernel.org
 S: Maintained
 F: drivers/platform/x86/dell-smbios-wmi.c
+F: include/uapi/linux/dell-smbios.h
 
 DELL LAPTOP DRIVER
 M: Matthew Garrett 
diff --git a/drivers/platform/x86/dell-smbios-wmi.c 
b/drivers/platform/x86/dell-smbios-wmi.c
index 3de8abea38f8..2b78aba68755 100644
--- a/drivers/platform/x86/dell-smbios-wmi.c
+++ b/drivers/platform/x86/dell-smbios-wmi.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "dell-smbios.h"
 #include "dell-wmi-descriptor.h"

[PATCH v5 06/14] platform/x86: wmi: Don't allow drivers to get each other's GUIDs

2017-10-06 Thread Mario Limonciello
The only driver using this was dell-wmi, and it really was a hack.
The driver was getting a data attribute from another driver and this
type of action should not be encouraged.

Rather drivers that need to interact with one another should pass
data back and forth via exported functions.

Signed-off-by: Mario Limonciello 
---
 drivers/platform/x86/wmi.c | 17 -
 include/linux/wmi.h|  4 
 2 files changed, 21 deletions(-)

diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index 4d73a87c2ddf..bcb41c1c7f52 100644
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -368,23 +368,6 @@ union acpi_object *wmidev_block_query(struct wmi_device 
*wdev, u8 instance)
 }
 EXPORT_SYMBOL_GPL(wmidev_block_query);
 
-struct wmi_device *wmidev_get_other_guid(struct wmi_device *wdev,
-const char *guid_string)
-{
-   struct wmi_block *this_wb = container_of(wdev, struct wmi_block, dev);
-   struct wmi_block *other_wb;
-
-   if (!find_guid(guid_string, _wb))
-   return NULL;
-
-   if (other_wb->acpi_device != this_wb->acpi_device)
-   return NULL;
-
-   get_device(_wb->dev.dev);
-   return _wb->dev;
-}
-EXPORT_SYMBOL_GPL(wmidev_get_other_guid);
-
 /**
  * wmi_set_block - Write to a WMI block
  * @guid_string: 36 char string of the form 
fa50ff2b-f2e8-45de-83fa-65417f2f49ba
diff --git a/include/linux/wmi.h b/include/linux/wmi.h
index 2cd10c3b89e9..ddee427e0721 100644
--- a/include/linux/wmi.h
+++ b/include/linux/wmi.h
@@ -36,10 +36,6 @@ extern acpi_status wmidev_evaluate_method(struct wmi_device 
*wdev,
 extern union acpi_object *wmidev_block_query(struct wmi_device *wdev,
 u8 instance);
 
-/* Gets another device on the same bus.  Caller must put_device the result. */
-extern struct wmi_device *wmidev_get_other_guid(struct wmi_device *wdev,
-   const char *guid_string);
-
 struct wmi_device_id {
const char *guid_string;
 };
-- 
2.14.1



[PATCH v5 14/14] platform/x86: dell-smbios-wmi: introduce userspace interface

2017-10-06 Thread Mario Limonciello
It's important for the driver to provide a R/W ioctl to ensure that
two competing userspace processes don't race to provide or read each
others data.

This userspace character device will be used to perform SMBIOS calls
from any applications.

It provides an ioctl that will allow passing the WMI calling
interface buffer between userspace and kernel space.

This character device is intended to deprecate the dcdbas kernel module
and the interface that it provides to userspace.

To use the character device the buffer needed for the machine will
also be needed.  This information is exported to a sysfs attribute.

The API for interacting with this interface is defined in documentation
as well as a uapi header provides the format of the structures.

Signed-off-by: Mario Limonciello 
---
 Documentation/ABI/testing/dell-smbios-wmi  |  41 
 .../ABI/testing/sysfs-platform-dell-smbios-wmi |  10 ++
 MAINTAINERS|   1 +
 drivers/platform/x86/dell-smbios-wmi.c | 104 ++---
 drivers/platform/x86/dell-smbios.h |  11 +--
 include/uapi/linux/dell-smbios.h   |  42 +
 6 files changed, 188 insertions(+), 21 deletions(-)
 create mode 100644 Documentation/ABI/testing/dell-smbios-wmi
 create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-smbios-wmi
 create mode 100644 include/uapi/linux/dell-smbios.h

diff --git a/Documentation/ABI/testing/dell-smbios-wmi 
b/Documentation/ABI/testing/dell-smbios-wmi
new file mode 100644
index ..e067e955fcc9
--- /dev/null
+++ b/Documentation/ABI/testing/dell-smbios-wmi
@@ -0,0 +1,41 @@
+What:  /dev/wmi/dell-smbios
+Date:  November 2017
+KernelVersion: 4.15
+Contact:   "Mario Limonciello" 
+Description:
+   Perform SMBIOS calls on supported Dell machines.
+   through the Dell ACPI-WMI interface.
+
+   IOCTL's and buffer formats are defined in:
+   
+
+   1) To perform a call from userspace, you'll need to first
+   determine the minimum size of the calling interface buffer
+   for your machine.
+   Platforms that contain larger buffers can return larger
+   objects from the system firmware.
+   Commonly this size is either 4k or 32k.
+
+   To determine the size of the buffer, refer to:
+   sysfs-platform-dell-smbios-wmi
+
+   2) After you've determined the minimum size of the calling
+   interface buffer, you can allocate a structure that represents
+   the structure documented above.
+
+   3) In the 'length' object store the size of the buffer you
+   determined above and allocated.
+
+   4) In this buffer object, prepare as necessary for the SMBIOS
+   call you're interested in.  Typically SMBIOS buffers have
+   "class", "select", and "input" defined to values that coincide
+   with the data you are interested in.
+   Documenting class/select/input values is outside of the scope
+   of this documentation. Check with the libsmbios project for
+   further documentation on these values.
+
+   6) Run the call by using ioctl() as described in the header.
+
+   7) The output will be returned in the buffer object.
+
+   8) Be sure to free up your allocated object.
diff --git a/Documentation/ABI/testing/sysfs-platform-dell-smbios-wmi 
b/Documentation/ABI/testing/sysfs-platform-dell-smbios-wmi
new file mode 100644
index ..6a0513703a3c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-dell-smbios-wmi
@@ -0,0 +1,10 @@
+What:  /sys/devices/platform//buffer_size
+Date:  November 2017
+KernelVersion: 4.15
+Contact:   "Mario Limonciello" 
+Description:
+   A read-only description of the size of a calling
+   interface buffer that can be passed to Dell
+   firmware.
+
+   Commonly this size is either 4k or 32k.
diff --git a/MAINTAINERS b/MAINTAINERS
index 2a99ee9fd883..4940f3c7481b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3986,6 +3986,7 @@ M:Mario Limonciello 
 L: platform-driver-...@vger.kernel.org
 S: Maintained
 F: drivers/platform/x86/dell-smbios-wmi.c
+F: include/uapi/linux/dell-smbios.h
 
 DELL LAPTOP DRIVER
 M: Matthew Garrett 
diff --git a/drivers/platform/x86/dell-smbios-wmi.c 
b/drivers/platform/x86/dell-smbios-wmi.c
index 3de8abea38f8..2b78aba68755 100644
--- a/drivers/platform/x86/dell-smbios-wmi.c
+++ b/drivers/platform/x86/dell-smbios-wmi.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "dell-smbios.h"
 #include "dell-wmi-descriptor.h"
 static DEFINE_MUTEX(call_mutex);
@@ -29,19 +30,9 @@ struct misc_bios_flags_structure {
 
 #define DELL_WMI_SMBIOS_GUID 

[PATCH v5 06/14] platform/x86: wmi: Don't allow drivers to get each other's GUIDs

2017-10-06 Thread Mario Limonciello
The only driver using this was dell-wmi, and it really was a hack.
The driver was getting a data attribute from another driver and this
type of action should not be encouraged.

Rather drivers that need to interact with one another should pass
data back and forth via exported functions.

Signed-off-by: Mario Limonciello 
---
 drivers/platform/x86/wmi.c | 17 -
 include/linux/wmi.h|  4 
 2 files changed, 21 deletions(-)

diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index 4d73a87c2ddf..bcb41c1c7f52 100644
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -368,23 +368,6 @@ union acpi_object *wmidev_block_query(struct wmi_device 
*wdev, u8 instance)
 }
 EXPORT_SYMBOL_GPL(wmidev_block_query);
 
-struct wmi_device *wmidev_get_other_guid(struct wmi_device *wdev,
-const char *guid_string)
-{
-   struct wmi_block *this_wb = container_of(wdev, struct wmi_block, dev);
-   struct wmi_block *other_wb;
-
-   if (!find_guid(guid_string, _wb))
-   return NULL;
-
-   if (other_wb->acpi_device != this_wb->acpi_device)
-   return NULL;
-
-   get_device(_wb->dev.dev);
-   return _wb->dev;
-}
-EXPORT_SYMBOL_GPL(wmidev_get_other_guid);
-
 /**
  * wmi_set_block - Write to a WMI block
  * @guid_string: 36 char string of the form 
fa50ff2b-f2e8-45de-83fa-65417f2f49ba
diff --git a/include/linux/wmi.h b/include/linux/wmi.h
index 2cd10c3b89e9..ddee427e0721 100644
--- a/include/linux/wmi.h
+++ b/include/linux/wmi.h
@@ -36,10 +36,6 @@ extern acpi_status wmidev_evaluate_method(struct wmi_device 
*wdev,
 extern union acpi_object *wmidev_block_query(struct wmi_device *wdev,
 u8 instance);
 
-/* Gets another device on the same bus.  Caller must put_device the result. */
-extern struct wmi_device *wmidev_get_other_guid(struct wmi_device *wdev,
-   const char *guid_string);
-
 struct wmi_device_id {
const char *guid_string;
 };
-- 
2.14.1



[PATCH v5 12/14] platform/x86: dell-smbios-smm: test for WSMT

2017-10-06 Thread Mario Limonciello
WSMT is as an attestation to the OS that the platform won't
modify memory outside of pre-defined areas.

If a platform has WSMT enabled in BIOS setup, SMM calls through
dcdbas will fail.  The only way to access platform data in these
instances is through the WMI SMBIOS calling interface.

Signed-off-by: Mario Limonciello 
---
 drivers/platform/x86/dell-smbios-smm.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/platform/x86/dell-smbios-smm.c 
b/drivers/platform/x86/dell-smbios-smm.c
index 223531e43fea..ba315753e847 100644
--- a/drivers/platform/x86/dell-smbios-smm.c
+++ b/drivers/platform/x86/dell-smbios-smm.c
@@ -25,6 +25,8 @@ static struct calling_interface_buffer *buffer;
 struct platform_device *platform_device;
 static DEFINE_MUTEX(smm_mutex);
 
+#define WSMT_EN_TOKEN  0x04EC
+
 static const struct dmi_system_id dell_device_table[] __initconst = {
{
.ident = "Dell laptop",
@@ -76,6 +78,30 @@ int dell_smbios_smm_call(struct calling_interface_buffer 
*input)
return 0;
 }
 
+static int test_wsmt_enabled(void)
+{
+   struct calling_interface_token *token;
+
+   /* if token doesn't exist, SMM will work */
+   token = dell_smbios_find_token(WSMT_EN_TOKEN);
+   if (!token)
+   return 0;
+
+   /* if token exists, try to access over SMM */
+   buffer->class = 0;
+   buffer->select = 0;
+   memset(buffer, 0, sizeof(struct calling_interface_buffer));
+   buffer->input[0] = token->location;
+   dell_smbios_smm_call(buffer);
+
+   /* if lookup failed, we know WSMT was enabled */
+   if (buffer->output[0] != 0)
+   return 1;
+
+   /* query token status if it didn't fail */
+   return (buffer->output[1] == token->value);
+}
+
 static int __init dell_smbios_smm_init(void)
 {
int ret;
@@ -88,6 +114,13 @@ static int __init dell_smbios_smm_init(void)
return -ENOMEM;
dell_smbios_get_smm_address(_command_address, _command_code);
 
+   ret = test_wsmt_enabled();
+   pr_debug("WSMT enable test: %d\n", ret);
+   if (ret) {
+   ret = -ENODEV;
+   goto fail_wsmt;
+   }
+
platform_device = platform_device_alloc("dell-smbios", 1);
if (!platform_device) {
ret = -ENOMEM;
@@ -111,6 +144,7 @@ static int __init dell_smbios_smm_init(void)
 fail_platform_device_add:
platform_device_put(platform_device);
 
+fail_wsmt:
 fail_platform_device_alloc:
free_page((unsigned long)buffer);
return ret;
-- 
2.14.1



[PATCH v5 12/14] platform/x86: dell-smbios-smm: test for WSMT

2017-10-06 Thread Mario Limonciello
WSMT is as an attestation to the OS that the platform won't
modify memory outside of pre-defined areas.

If a platform has WSMT enabled in BIOS setup, SMM calls through
dcdbas will fail.  The only way to access platform data in these
instances is through the WMI SMBIOS calling interface.

Signed-off-by: Mario Limonciello 
---
 drivers/platform/x86/dell-smbios-smm.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/platform/x86/dell-smbios-smm.c 
b/drivers/platform/x86/dell-smbios-smm.c
index 223531e43fea..ba315753e847 100644
--- a/drivers/platform/x86/dell-smbios-smm.c
+++ b/drivers/platform/x86/dell-smbios-smm.c
@@ -25,6 +25,8 @@ static struct calling_interface_buffer *buffer;
 struct platform_device *platform_device;
 static DEFINE_MUTEX(smm_mutex);
 
+#define WSMT_EN_TOKEN  0x04EC
+
 static const struct dmi_system_id dell_device_table[] __initconst = {
{
.ident = "Dell laptop",
@@ -76,6 +78,30 @@ int dell_smbios_smm_call(struct calling_interface_buffer 
*input)
return 0;
 }
 
+static int test_wsmt_enabled(void)
+{
+   struct calling_interface_token *token;
+
+   /* if token doesn't exist, SMM will work */
+   token = dell_smbios_find_token(WSMT_EN_TOKEN);
+   if (!token)
+   return 0;
+
+   /* if token exists, try to access over SMM */
+   buffer->class = 0;
+   buffer->select = 0;
+   memset(buffer, 0, sizeof(struct calling_interface_buffer));
+   buffer->input[0] = token->location;
+   dell_smbios_smm_call(buffer);
+
+   /* if lookup failed, we know WSMT was enabled */
+   if (buffer->output[0] != 0)
+   return 1;
+
+   /* query token status if it didn't fail */
+   return (buffer->output[1] == token->value);
+}
+
 static int __init dell_smbios_smm_init(void)
 {
int ret;
@@ -88,6 +114,13 @@ static int __init dell_smbios_smm_init(void)
return -ENOMEM;
dell_smbios_get_smm_address(_command_address, _command_code);
 
+   ret = test_wsmt_enabled();
+   pr_debug("WSMT enable test: %d\n", ret);
+   if (ret) {
+   ret = -ENODEV;
+   goto fail_wsmt;
+   }
+
platform_device = platform_device_alloc("dell-smbios", 1);
if (!platform_device) {
ret = -ENOMEM;
@@ -111,6 +144,7 @@ static int __init dell_smbios_smm_init(void)
 fail_platform_device_add:
platform_device_put(platform_device);
 
+fail_wsmt:
 fail_platform_device_alloc:
free_page((unsigned long)buffer);
return ret;
-- 
2.14.1



Re: [ANNOUNCE] v4.11.12-rt13

2017-10-06 Thread Mike Galbraith
On Fri, 2017-10-06 at 19:38 +0200, Mike Galbraith wrote:
> On Fri, 2017-10-06 at 15:33 +0200, Mike Galbraith wrote:
> > 
> > I'll run full ltp again, make sure there are no new failure deltas.
> 
> Haven't done that yet, but I have checked all of the reported failures.
> 
> time-hrtimer:-Use-softirq-based-wakeups-for-non-RT-threads.patch fixes
> clock_settime_8-1.run-test, hrtimer:-Update-offset-for-soft-bases.patch 
> fixes the rest.
> 
> However...

testcases/open_posix_testsuite/conformance/interfaces/clock_settime/8-1.c:
 * Steps:
 * - get time T0
 * - in child:  set clock_nanosleep() to sleep for SLEEPSEC seconds
 * - in parent:  sleep SMALLTIME (< SLEEPSEC)
 * - in parent:  set time back to T0
 * - in child:  ensure time when clock_nanosleep() expires is within
 *   ACCEPTABLEDELTA of T0+(SLEEPSEC-SMALLTIME)
...
#define SLEEPSEC 5
#define SMALLTIME 2
#define ACCEPTABLEDELTA 1

homer:..debug/tracing # time chrt -o 0 
/usr/local/ltp/conformance/interfaces/clock_settime/clock_settime_8-1.run-test
Test PASSED

real0m5.002s
user0m0.000s
sys 0m0.001s
homer:..debug/tracing # time chrt -f 1 
/usr/local/ltp/conformance/interfaces/clock_settime/clock_settime_8-1.run-test
Ended too late.  1507351636 >> 1507351634
Test FAILED

real0m7.002s
user0m0.000s
sys 0m0.002s





Re: [ANNOUNCE] v4.11.12-rt13

2017-10-06 Thread Mike Galbraith
On Fri, 2017-10-06 at 19:38 +0200, Mike Galbraith wrote:
> On Fri, 2017-10-06 at 15:33 +0200, Mike Galbraith wrote:
> > 
> > I'll run full ltp again, make sure there are no new failure deltas.
> 
> Haven't done that yet, but I have checked all of the reported failures.
> 
> time-hrtimer:-Use-softirq-based-wakeups-for-non-RT-threads.patch fixes
> clock_settime_8-1.run-test, hrtimer:-Update-offset-for-soft-bases.patch 
> fixes the rest.
> 
> However...

testcases/open_posix_testsuite/conformance/interfaces/clock_settime/8-1.c:
 * Steps:
 * - get time T0
 * - in child:  set clock_nanosleep() to sleep for SLEEPSEC seconds
 * - in parent:  sleep SMALLTIME (< SLEEPSEC)
 * - in parent:  set time back to T0
 * - in child:  ensure time when clock_nanosleep() expires is within
 *   ACCEPTABLEDELTA of T0+(SLEEPSEC-SMALLTIME)
...
#define SLEEPSEC 5
#define SMALLTIME 2
#define ACCEPTABLEDELTA 1

homer:..debug/tracing # time chrt -o 0 
/usr/local/ltp/conformance/interfaces/clock_settime/clock_settime_8-1.run-test
Test PASSED

real0m5.002s
user0m0.000s
sys 0m0.001s
homer:..debug/tracing # time chrt -f 1 
/usr/local/ltp/conformance/interfaces/clock_settime/clock_settime_8-1.run-test
Ended too late.  1507351636 >> 1507351634
Test FAILED

real0m7.002s
user0m0.000s
sys 0m0.002s





[rcu:rcu/next 48/97] drivers/firmware/tegra/ivc.c:154:39: error: lvalue required as left operand of assignment

2017-10-06 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
rcu/next
head:   bd76953f4e7b0b1f66b3fe631106fcc4c85a380c
commit: 669f98e232aa6f77bd602e2826dd55c3694109e5 [48/97] 
drivers/firmware/tegra: Convert ACCESS_ONCE() to READ_ONCE()
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 669f98e232aa6f77bd602e2826dd55c3694109e5
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   drivers/firmware/tegra/ivc.c: In function 'tegra_ivc_advance_tx':
>> drivers/firmware/tegra/ivc.c:154:39: error: lvalue required as left operand 
>> of assignment
 READ_ONCE(ivc->tx.channel->tx.count) =
  ^
   drivers/firmware/tegra/ivc.c: In function 'tegra_ivc_advance_rx':
   drivers/firmware/tegra/ivc.c:165:39: error: lvalue required as left operand 
of assignment
 READ_ONCE(ivc->rx.channel->rx.count) =
  ^

vim +154 drivers/firmware/tegra/ivc.c

   151  
   152  static inline void tegra_ivc_advance_tx(struct tegra_ivc *ivc)
   153  {
 > 154  READ_ONCE(ivc->tx.channel->tx.count) =
   155  READ_ONCE(ivc->tx.channel->tx.count) + 1;
   156  
   157  if (ivc->tx.position == ivc->num_frames - 1)
   158  ivc->tx.position = 0;
   159  else
   160  ivc->tx.position++;
   161  }
   162  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


[rcu:rcu/next 48/97] drivers/firmware/tegra/ivc.c:154:39: error: lvalue required as left operand of assignment

2017-10-06 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
rcu/next
head:   bd76953f4e7b0b1f66b3fe631106fcc4c85a380c
commit: 669f98e232aa6f77bd602e2826dd55c3694109e5 [48/97] 
drivers/firmware/tegra: Convert ACCESS_ONCE() to READ_ONCE()
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 669f98e232aa6f77bd602e2826dd55c3694109e5
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   drivers/firmware/tegra/ivc.c: In function 'tegra_ivc_advance_tx':
>> drivers/firmware/tegra/ivc.c:154:39: error: lvalue required as left operand 
>> of assignment
 READ_ONCE(ivc->tx.channel->tx.count) =
  ^
   drivers/firmware/tegra/ivc.c: In function 'tegra_ivc_advance_rx':
   drivers/firmware/tegra/ivc.c:165:39: error: lvalue required as left operand 
of assignment
 READ_ONCE(ivc->rx.channel->rx.count) =
  ^

vim +154 drivers/firmware/tegra/ivc.c

   151  
   152  static inline void tegra_ivc_advance_tx(struct tegra_ivc *ivc)
   153  {
 > 154  READ_ONCE(ivc->tx.channel->tx.count) =
   155  READ_ONCE(ivc->tx.channel->tx.count) + 1;
   156  
   157  if (ivc->tx.position == ivc->num_frames - 1)
   158  ivc->tx.position = 0;
   159  else
   160  ivc->tx.position++;
   161  }
   162  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


Re: [PATCH] crypto: omap: use of_device_get_match_data

2017-10-06 Thread Herbert Xu
On Wed, Sep 20, 2017 at 08:42:48PM +0200, Corentin Labbe wrote:
> The usage of of_device_get_match_data reduce the code size a bit.
> Furthermore, it prevents an improbable dereference when
> of_match_device() return NULL.
> 
> Signed-off-by: Corentin Labbe 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: bcm: use of_device_get_match_data

2017-10-06 Thread Herbert Xu
On Wed, Sep 20, 2017 at 08:47:26PM +0200, Corentin Labbe wrote:
> The usage of of_device_get_match_data reduce the code size a bit.
> Furthermore, it prevents an improbable dereference when
> of_match_device() return NULL.
> 
> Signed-off-by: Corentin Labbe 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: stm32: use of_device_get_match_data

2017-10-06 Thread Herbert Xu
On Wed, Sep 20, 2017 at 08:31:40PM +0200, Corentin Labbe wrote:
> The usage of of_device_get_match_data reduce the code size a bit.
> Furthermore, it prevents an improbable dereference when
> of_match_device() return NULL.
> 
> Signed-off-by: Corentin Labbe 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: bcm: use of_device_get_match_data

2017-10-06 Thread Herbert Xu
On Wed, Sep 20, 2017 at 08:47:26PM +0200, Corentin Labbe wrote:
> The usage of of_device_get_match_data reduce the code size a bit.
> Furthermore, it prevents an improbable dereference when
> of_match_device() return NULL.
> 
> Signed-off-by: Corentin Labbe 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: stm32: use of_device_get_match_data

2017-10-06 Thread Herbert Xu
On Wed, Sep 20, 2017 at 08:31:40PM +0200, Corentin Labbe wrote:
> The usage of of_device_get_match_data reduce the code size a bit.
> Furthermore, it prevents an improbable dereference when
> of_match_device() return NULL.
> 
> Signed-off-by: Corentin Labbe 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: omap: use of_device_get_match_data

2017-10-06 Thread Herbert Xu
On Wed, Sep 20, 2017 at 08:42:48PM +0200, Corentin Labbe wrote:
> The usage of of_device_get_match_data reduce the code size a bit.
> Furthermore, it prevents an improbable dereference when
> of_match_device() return NULL.
> 
> Signed-off-by: Corentin Labbe 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: algboss: remove redundant setting of len to zero

2017-10-06 Thread Herbert Xu
On Thu, Sep 14, 2017 at 07:02:19PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> The variable len is set to zero, never read and then later updated
> to p - name, so clearly the zero'ing of len is redundant and
> can be removed.
> 
> Detected by clang scan-build:
> " warning: Value stored to 'len' is never read"
> 
> Signed-off-by: Colin Ian King 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: algboss: remove redundant setting of len to zero

2017-10-06 Thread Herbert Xu
On Thu, Sep 14, 2017 at 07:02:19PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> The variable len is set to zero, never read and then later updated
> to p - name, so clearly the zero'ing of len is redundant and
> can be removed.
> 
> Detected by clang scan-build:
> " warning: Value stored to 'len' is never read"
> 
> Signed-off-by: Colin Ian King 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH 02/10] drivers:crypto: return -ENOMEM on allocation failure.

2017-10-06 Thread Herbert Xu
Allen Pais  wrote:
> Signed-off-by: Allen Pais 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH 02/10] drivers:crypto: return -ENOMEM on allocation failure.

2017-10-06 Thread Herbert Xu
Allen Pais  wrote:
> Signed-off-by: Allen Pais 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH 1/2] crypto: stm32 - Fix uninitialized data usage

2017-10-06 Thread Herbert Xu
On Tue, Sep 12, 2017 at 11:35:38AM +0200, Arnd Bergmann wrote:
> The error handling in stm32_hash_irq_thread passes
> uninitialized data into stm32_hash_finish_req, as gcc
> points out:
> 
> drivers/crypto/stm32/stm32-hash.c: In function 'stm32_hash_irq_thread':
> drivers/crypto/stm32/stm32-hash.c:1088:2: error: 'err' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> I could not tell what data should be passed there instead,
> so this changes the code to always pass zero, making it
> well-defined, though possibly still wrong. Please check.
> 
> Signed-off-by: Arnd Bergmann 

This is already fixed in cryptodev.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH 2/2] crypto: stm32 - Try to fix hash padding

2017-10-06 Thread Herbert Xu
On Tue, Sep 12, 2017 at 11:35:39AM +0200, Arnd Bergmann wrote:
> gcc warns that the length for the extra unaligned data in the hash
> function may be used unaligned. In theory this could happen if
> we pass a zero-length sg_list, or if sg_is_last() was never true:
> 
> In file included from drivers/crypto/stm32/stm32-hash.c:23:
> drivers/crypto/stm32/stm32-hash.c: In function 'stm32_hash_one_request':
> include/uapi/linux/kernel.h:12:49: error: 'ncp' may be used uninitialized in 
> this function [-Werror=maybe-uninitialized]
>  #define __KERNEL_DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
> 
> Neither of these can happen in practice, so the warning is harmless.
> 
> However while trying to suppress the warning, I noticed multiple
> problems with that code:
> 
> - On big-endian kernels, we byte-swap the data like we do for
>   register accesses, however this is a data stream and almost
>   certainly needs to use a single writesl() instead of series
>   of writel() to give the correct hash.
> 
> - If the length is not a multiple of four bytes, we skip the
>   last word entirely, since we write the truncated length
>   using stm32_hash_set_nblw().
> 
> - If we change the code to round the length up rather than
>   down, the last bytes contain stale data, so it needs some
>   form of padding.
> 
> This tries to address all four problems, by correctly
> initializing the length to zero, using endian-safe copy
> functions, adding zero-padding and passing the padded length.
> 
> I have done no testing on this patch, so please review
> carefully and if possible test with an unaligned length
> and big-endian kernel builds.
> 
> Fixes: 8a1012d3f2ab ("crypto: stm32 - Support for STM32 HASH module")
> Signed-off-by: Arnd Bergmann 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH 1/2] crypto: stm32 - Fix uninitialized data usage

2017-10-06 Thread Herbert Xu
On Tue, Sep 12, 2017 at 11:35:38AM +0200, Arnd Bergmann wrote:
> The error handling in stm32_hash_irq_thread passes
> uninitialized data into stm32_hash_finish_req, as gcc
> points out:
> 
> drivers/crypto/stm32/stm32-hash.c: In function 'stm32_hash_irq_thread':
> drivers/crypto/stm32/stm32-hash.c:1088:2: error: 'err' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> I could not tell what data should be passed there instead,
> so this changes the code to always pass zero, making it
> well-defined, though possibly still wrong. Please check.
> 
> Signed-off-by: Arnd Bergmann 

This is already fixed in cryptodev.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH 2/2] crypto: stm32 - Try to fix hash padding

2017-10-06 Thread Herbert Xu
On Tue, Sep 12, 2017 at 11:35:39AM +0200, Arnd Bergmann wrote:
> gcc warns that the length for the extra unaligned data in the hash
> function may be used unaligned. In theory this could happen if
> we pass a zero-length sg_list, or if sg_is_last() was never true:
> 
> In file included from drivers/crypto/stm32/stm32-hash.c:23:
> drivers/crypto/stm32/stm32-hash.c: In function 'stm32_hash_one_request':
> include/uapi/linux/kernel.h:12:49: error: 'ncp' may be used uninitialized in 
> this function [-Werror=maybe-uninitialized]
>  #define __KERNEL_DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
> 
> Neither of these can happen in practice, so the warning is harmless.
> 
> However while trying to suppress the warning, I noticed multiple
> problems with that code:
> 
> - On big-endian kernels, we byte-swap the data like we do for
>   register accesses, however this is a data stream and almost
>   certainly needs to use a single writesl() instead of series
>   of writel() to give the correct hash.
> 
> - If the length is not a multiple of four bytes, we skip the
>   last word entirely, since we write the truncated length
>   using stm32_hash_set_nblw().
> 
> - If we change the code to round the length up rather than
>   down, the last bytes contain stale data, so it needs some
>   form of padding.
> 
> This tries to address all four problems, by correctly
> initializing the length to zero, using endian-safe copy
> functions, adding zero-padding and passing the padded length.
> 
> I have done no testing on this patch, so please review
> carefully and if possible test with an unaligned length
> and big-endian kernel builds.
> 
> Fixes: 8a1012d3f2ab ("crypto: stm32 - Support for STM32 HASH module")
> Signed-off-by: Arnd Bergmann 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crc32-pclmul: remove useless relative addressing

2017-10-06 Thread Herbert Xu
On Wed, Sep 06, 2017 at 10:41:21PM -0400, Mikulas Patocka wrote:
> In 32-bit mode, the x86 architecture can hold full 32-bit pointers.
> Therefore, the code that copies the current address to the %ecx register
> and uses %ecx-relative addressing is useless, we could just use absolute
> addressing.
> 
> The processors have a stack of return addresses for branch prediction. If 
> we use a call instruction and pop the return address, it desynchronizes 
> the return stack and causes branch prediction misses.
> 
> This patch also moves the data to the .rodata section.
> 
> Signed-off-by: Mikulas Patocka 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crc32-pclmul: remove useless relative addressing

2017-10-06 Thread Herbert Xu
On Wed, Sep 06, 2017 at 10:41:21PM -0400, Mikulas Patocka wrote:
> In 32-bit mode, the x86 architecture can hold full 32-bit pointers.
> Therefore, the code that copies the current address to the %ecx register
> and uses %ecx-relative addressing is useless, we could just use absolute
> addressing.
> 
> The processors have a stack of return addresses for branch prediction. If 
> we use a call instruction and pop the return address, it desynchronizes 
> the return stack and causes branch prediction misses.
> 
> This patch also moves the data to the .rodata section.
> 
> Signed-off-by: Mikulas Patocka 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: xts - Fix an error handling path in 'create()'

2017-10-06 Thread Herbert Xu
On Tue, Sep 26, 2017 at 08:17:44AM +0200, Christophe JAILLET wrote:
> All error handling paths 'goto err_drop_spawn' except this one.
> In order to avoid some resources leak, we should do it as well here.
> 
> Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher")
> Signed-off-by: Christophe JAILLET 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: xts - Fix an error handling path in 'create()'

2017-10-06 Thread Herbert Xu
On Tue, Sep 26, 2017 at 08:17:44AM +0200, Christophe JAILLET wrote:
> All error handling paths 'goto err_drop_spawn' except this one.
> In order to avoid some resources leak, we should do it as well here.
> 
> Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher")
> Signed-off-by: Christophe JAILLET 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [Patch v6 1/7] slimbus: Device management on SLIMbus

2017-10-06 Thread Jonathan Neuschäfer
Hi, I have some more or less trivial comments below.

On Fri, Oct 06, 2017 at 05:51:30PM +0200, srinivas.kandaga...@linaro.org wrote:
> From: Sagar Dharia 
> 
> SLIMbus (Serial Low Power Interchip Media Bus) is a specification
> developed by MIPI (Mobile Industry Processor Interface) alliance.
> SLIMbus is a 2-wire implementation, which is used to communicate with
> peripheral components like audio-codec.
> SLIMbus uses Time-Division-Multiplexing to accommodate multiple data
> channels, and control channel. Control channel has messages to do
> device-enumeration, messages to send/receive control-data to/from
> slimbus devices, messages for port/channel management, and messages to
> do bandwidth allocation.
> The framework supports multiple instances of the bus (1 controller per
> bus), and multiple slave devices per controller.
> 
> This patch does device enumeration, logical address assignment,
> informing device when the device reports present/absent etc.
> Reporting present may need the driver to do the needful (e.g. turning
> on voltage regulators powering the device). Additionally device is
> probed when it reports present if that device doesn't need any such
> steps mentioned above.
> 
> Signed-off-by: Sagar Dharia 
> Signed-off-by: Srinivas Kandagatla 
> ---
[...]
> +SLIMbus example for Qualcomm's slimbus manager component:
> +
> + slim@2808 {
> + compatible = "qcom,slim-msm";
> + reg = <0x2808 0x2000>,
> + interrupts = <0 33 0>;
> + clocks = < SLIMBUS_SRC>, < AUDIO_SLIMBUS_CLK>;
> + clock-names = "iface_clk", "core_clk";
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + codec: wcd9310@1{
> + compatible = "slim217,60"";
^ spurious quote?

> + reg = <1 0>;
> + };
> + };
> diff --git a/Documentation/slimbus/summary b/Documentation/slimbus/summary
> new file mode 100644
> index 000..e7f90bb
> --- /dev/null
> +++ b/Documentation/slimbus/summary

Should this file have a .rst extension, like other Restructured Text
files?

> @@ -0,0 +1,109 @@
> +Overview of Linux kernel SLIMbus support
> +
[...]
> +Device notifications to the driver:
> +---
> +Since SLIMbus devices have mechanisms for reporting their presence, the
> +framework allows drivers to bind when corresponding devices report their
> +presence on the bus.
> +However, it is possible that the driver needs to be probed
> +first so that it can enable corresponding SLIMbus devie (e.g. power it up 
> and/or

s/devie/device/ I guess

> +take it out of reset). To support that behavior, the framework allows drivers
> +to probe first as well  (e.g. using standard DeviceTree compatbility field).
> +This creates the necessity for the driver to know when the device is 
> functional
> +(i.e. reported present). device_up callback is used for that reason when the
> +device reports present and is assigned a logical address by the controller.
[...]
> +/**
> + * struct slim_addrt: slimbus address used internally by the slimbus 
> framework.
> + * @valid: If the device is present. Valid is set to false when device 
> reports
> + *   absent.
> + * @eaddr: Enumeration address
> + * @laddr: It is possible that controller will set a predefined logical 
> address
> + *   rather than the one assigned by framework. (i.e. logical address may
> + *   not be same as index into this table). This entry will store the
> + *   logical address value for this enumeration address.
> + */
> +struct slim_addrt {
> + boolvalid;
> + struct slim_eaddr   eaddr;
> + u8  laddr;
> +};

I wonder if valid should be moved after eaddr, to reduce the need for
padding. AFAICS, struct slim_eaddr is 6 bytes long and requires 2-byte
alignment, so if valid is one byte long, there would be one byte of
padding after it, slightly bloating struct slim_addrt, unnecessarily.

> +/**
> + * struct slim_controller: Controls every instance of SLIMbus
> + *   (similar to 'master' on SPI)
> + *   'Manager device' is responsible for  device management, bandwidth
> + *   allocation, channel setup, and port associations per channel.
> + *   Device management means Logical address assignment/removal based on
> + *   enumeration (report-present, report-absent) if a device.

s/if a device/of a device/ ?

> + *   Bandwidth allocation is done dynamically by the manager based on active
> + *   channels on the bus, message-bandwidth requests made by slimbus devices.
> + *   Based on current bandwidth usage, manager chooses a frequency to run
> + *   the bus at (in steps of 'clock-gear', 1 through 10, each clock gear
> + *   representing twice the frequency than the previous 

Re: [Patch v6 1/7] slimbus: Device management on SLIMbus

2017-10-06 Thread Jonathan Neuschäfer
Hi, I have some more or less trivial comments below.

On Fri, Oct 06, 2017 at 05:51:30PM +0200, srinivas.kandaga...@linaro.org wrote:
> From: Sagar Dharia 
> 
> SLIMbus (Serial Low Power Interchip Media Bus) is a specification
> developed by MIPI (Mobile Industry Processor Interface) alliance.
> SLIMbus is a 2-wire implementation, which is used to communicate with
> peripheral components like audio-codec.
> SLIMbus uses Time-Division-Multiplexing to accommodate multiple data
> channels, and control channel. Control channel has messages to do
> device-enumeration, messages to send/receive control-data to/from
> slimbus devices, messages for port/channel management, and messages to
> do bandwidth allocation.
> The framework supports multiple instances of the bus (1 controller per
> bus), and multiple slave devices per controller.
> 
> This patch does device enumeration, logical address assignment,
> informing device when the device reports present/absent etc.
> Reporting present may need the driver to do the needful (e.g. turning
> on voltage regulators powering the device). Additionally device is
> probed when it reports present if that device doesn't need any such
> steps mentioned above.
> 
> Signed-off-by: Sagar Dharia 
> Signed-off-by: Srinivas Kandagatla 
> ---
[...]
> +SLIMbus example for Qualcomm's slimbus manager component:
> +
> + slim@2808 {
> + compatible = "qcom,slim-msm";
> + reg = <0x2808 0x2000>,
> + interrupts = <0 33 0>;
> + clocks = < SLIMBUS_SRC>, < AUDIO_SLIMBUS_CLK>;
> + clock-names = "iface_clk", "core_clk";
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + codec: wcd9310@1{
> + compatible = "slim217,60"";
^ spurious quote?

> + reg = <1 0>;
> + };
> + };
> diff --git a/Documentation/slimbus/summary b/Documentation/slimbus/summary
> new file mode 100644
> index 000..e7f90bb
> --- /dev/null
> +++ b/Documentation/slimbus/summary

Should this file have a .rst extension, like other Restructured Text
files?

> @@ -0,0 +1,109 @@
> +Overview of Linux kernel SLIMbus support
> +
[...]
> +Device notifications to the driver:
> +---
> +Since SLIMbus devices have mechanisms for reporting their presence, the
> +framework allows drivers to bind when corresponding devices report their
> +presence on the bus.
> +However, it is possible that the driver needs to be probed
> +first so that it can enable corresponding SLIMbus devie (e.g. power it up 
> and/or

s/devie/device/ I guess

> +take it out of reset). To support that behavior, the framework allows drivers
> +to probe first as well  (e.g. using standard DeviceTree compatbility field).
> +This creates the necessity for the driver to know when the device is 
> functional
> +(i.e. reported present). device_up callback is used for that reason when the
> +device reports present and is assigned a logical address by the controller.
[...]
> +/**
> + * struct slim_addrt: slimbus address used internally by the slimbus 
> framework.
> + * @valid: If the device is present. Valid is set to false when device 
> reports
> + *   absent.
> + * @eaddr: Enumeration address
> + * @laddr: It is possible that controller will set a predefined logical 
> address
> + *   rather than the one assigned by framework. (i.e. logical address may
> + *   not be same as index into this table). This entry will store the
> + *   logical address value for this enumeration address.
> + */
> +struct slim_addrt {
> + boolvalid;
> + struct slim_eaddr   eaddr;
> + u8  laddr;
> +};

I wonder if valid should be moved after eaddr, to reduce the need for
padding. AFAICS, struct slim_eaddr is 6 bytes long and requires 2-byte
alignment, so if valid is one byte long, there would be one byte of
padding after it, slightly bloating struct slim_addrt, unnecessarily.

> +/**
> + * struct slim_controller: Controls every instance of SLIMbus
> + *   (similar to 'master' on SPI)
> + *   'Manager device' is responsible for  device management, bandwidth
> + *   allocation, channel setup, and port associations per channel.
> + *   Device management means Logical address assignment/removal based on
> + *   enumeration (report-present, report-absent) if a device.

s/if a device/of a device/ ?

> + *   Bandwidth allocation is done dynamically by the manager based on active
> + *   channels on the bus, message-bandwidth requests made by slimbus devices.
> + *   Based on current bandwidth usage, manager chooses a frequency to run
> + *   the bus at (in steps of 'clock-gear', 1 through 10, each clock gear
> + *   representing twice the frequency than the previous gear).
> + *   Manager is also responsible for entering (and exiting) 

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

2017-10-06 Thread Tetsuo Handa
Johannes Weiner wrote:
> On Sat, Oct 07, 2017 at 11:21:26AM +0900, Tetsuo Handa wrote:
> > On 2017/10/05 19:36, Tetsuo Handa wrote:
> > > I don't want this patch backported. If you want to backport,
> > > "s/fatal_signal_pending/tsk_is_oom_victim/" is the safer way.
> > 
> > If you backport this patch, you will see "complete depletion of memory 
> > reserves"
> > and "extra OOM kills due to depletion of memory reserves" using below 
> > reproducer.
> > 
> > --
> > #include 
> > #include 
> > #include 
> > 
> > static char *buffer;
> > 
> > static int __init test_init(void)
> > {
> > set_current_oom_origin();
> > buffer = vmalloc((1UL << 32) - 480 * 1048576);
> 
> That's not a reproducer, that's a kernel module. It's not hard to
> crash the kernel from within the kernel.
> 

When did we agree that "reproducer" is "userspace program" ?
A "reproducer" is a program that triggers something intended.

Year by year, people are spending efforts for kernel hardening.
It is silly to say that "It's not hard to crash the kernel from
within the kernel." when we can easily mitigate.

Even with cd04ae1e2dc8, there is no point with triggering extra
OOM kills by needlessly consuming memory reserves.


Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

2017-10-06 Thread Tetsuo Handa
Johannes Weiner wrote:
> On Sat, Oct 07, 2017 at 11:21:26AM +0900, Tetsuo Handa wrote:
> > On 2017/10/05 19:36, Tetsuo Handa wrote:
> > > I don't want this patch backported. If you want to backport,
> > > "s/fatal_signal_pending/tsk_is_oom_victim/" is the safer way.
> > 
> > If you backport this patch, you will see "complete depletion of memory 
> > reserves"
> > and "extra OOM kills due to depletion of memory reserves" using below 
> > reproducer.
> > 
> > --
> > #include 
> > #include 
> > #include 
> > 
> > static char *buffer;
> > 
> > static int __init test_init(void)
> > {
> > set_current_oom_origin();
> > buffer = vmalloc((1UL << 32) - 480 * 1048576);
> 
> That's not a reproducer, that's a kernel module. It's not hard to
> crash the kernel from within the kernel.
> 

When did we agree that "reproducer" is "userspace program" ?
A "reproducer" is a program that triggers something intended.

Year by year, people are spending efforts for kernel hardening.
It is silly to say that "It's not hard to crash the kernel from
within the kernel." when we can easily mitigate.

Even with cd04ae1e2dc8, there is no point with triggering extra
OOM kills by needlessly consuming memory reserves.


Re: [PATCH] sched/rt.c: pick and check task if double_lock_balance() unlock the rq

2017-10-06 Thread zhouchengming

Hi Steven, Peter,

On 2017/9/26 11:18, Steven Rostedt wrote:

On Tue, 26 Sep 2017 09:23:20 +0800
zhouchengming  wrote:


On 2017/9/26 3:40, Steven Rostedt wrote:

On Mon, 11 Sep 2017 14:51:49 +0800
Zhou Chengming   wrote:


push_rt_task() pick the first pushable task and find an eligible
lowest_rq, then double_lock_balance(rq, lowest_rq). So if
double_lock_balance() unlock the rq (when double_lock_balance() return 1),
we have to check if this task is still on the rq.

The problem is that the check conditions are not sufficient:

if (unlikely(task_rq(task) != rq ||
 !cpumask_test_cpu(lowest_rq->cpu,>cpus_allowed) ||
 task_running(rq, task) ||
 !rt_task(task) ||
 !task_on_rq_queued(task))) {

cpu2cpu1cpu0
push_rt_task(rq1)
pick task_A on rq1
find rq0
  double_lock_balance(rq1, rq0)
unlock(rq1)
rq1 __schedule
  pick task_A run
task_A sleep (dequeued)
lock(rq0)
lock(rq1)
  do_above_check(task_A)
task_rq(task_A) == rq1
cpus_allowed unchanged
task_running == false
rt_task(task_A) == true
try_to_wake_up(task_A)
  select_cpu = cpu3
  enqueue(rq3, task_A)

How can this happen? The try_to_wake_up(task_A) needs to grab the rq
that task A is on, and we have that rq lock.

/me confused.

-- Steve

Thanks for the reply!
After the task_A sleep on cpu1, the try_to_wake_up(task_A) on cpu0 select a 
different cpu3,
so it will grab the rq3 lock, not the rq1 lock.

Ah crap. This is caused by 7608dec2ce20 ("sched: Drop the rq argument
to sched_class::select_task_rq()"). Because this code depends on
try_to_wake_up() grabbing the task's rq lock. But it no longer does
that, and it causes this race.

OK, I need to look at this deeper when I'm not so jetlagged and typing
this because I can't sleep at 5am.

Thanks for pointing this out!

It may be fixed by simply grabbing the run queue lock on migration, as
that would sync things up.


Is there any new solution? I don't think grabbing the rq lock without the 
task->pi_lock
will fix this problem. And I think my patch is correct and the changes are 
small.

Thanks!


Peter?


-- Steve



.






Re: [PATCH] sched/rt.c: pick and check task if double_lock_balance() unlock the rq

2017-10-06 Thread zhouchengming

Hi Steven, Peter,

On 2017/9/26 11:18, Steven Rostedt wrote:

On Tue, 26 Sep 2017 09:23:20 +0800
zhouchengming  wrote:


On 2017/9/26 3:40, Steven Rostedt wrote:

On Mon, 11 Sep 2017 14:51:49 +0800
Zhou Chengming   wrote:


push_rt_task() pick the first pushable task and find an eligible
lowest_rq, then double_lock_balance(rq, lowest_rq). So if
double_lock_balance() unlock the rq (when double_lock_balance() return 1),
we have to check if this task is still on the rq.

The problem is that the check conditions are not sufficient:

if (unlikely(task_rq(task) != rq ||
 !cpumask_test_cpu(lowest_rq->cpu,>cpus_allowed) ||
 task_running(rq, task) ||
 !rt_task(task) ||
 !task_on_rq_queued(task))) {

cpu2cpu1cpu0
push_rt_task(rq1)
pick task_A on rq1
find rq0
  double_lock_balance(rq1, rq0)
unlock(rq1)
rq1 __schedule
  pick task_A run
task_A sleep (dequeued)
lock(rq0)
lock(rq1)
  do_above_check(task_A)
task_rq(task_A) == rq1
cpus_allowed unchanged
task_running == false
rt_task(task_A) == true
try_to_wake_up(task_A)
  select_cpu = cpu3
  enqueue(rq3, task_A)

How can this happen? The try_to_wake_up(task_A) needs to grab the rq
that task A is on, and we have that rq lock.

/me confused.

-- Steve

Thanks for the reply!
After the task_A sleep on cpu1, the try_to_wake_up(task_A) on cpu0 select a 
different cpu3,
so it will grab the rq3 lock, not the rq1 lock.

Ah crap. This is caused by 7608dec2ce20 ("sched: Drop the rq argument
to sched_class::select_task_rq()"). Because this code depends on
try_to_wake_up() grabbing the task's rq lock. But it no longer does
that, and it causes this race.

OK, I need to look at this deeper when I'm not so jetlagged and typing
this because I can't sleep at 5am.

Thanks for pointing this out!

It may be fixed by simply grabbing the run queue lock on migration, as
that would sync things up.


Is there any new solution? I don't think grabbing the rq lock without the 
task->pi_lock
will fix this problem. And I think my patch is correct and the changes are 
small.

Thanks!


Peter?


-- Steve



.






Re: [RFC PATCH] crypto: make the seed() function optional

2017-10-06 Thread Herbert Xu
Mathieu Malaterre  wrote:
> This makes it simplier for driver author to not provide the seed() function
> in case of a pseudo RNG where the seed operation is a no-op.
> 
> Document that the seed() function pointer is optional in header.
> 
> Signed-off-by: Mathieu Malaterre 
> ---
> The PRNG as found on Ingenic JZ4780 is one such example. This is found on a
> MIPS Creator CI20 SoC.

So how does it seed itself? This also contradicts with the JZ4780
driver that's currently in the patch queue as it does contain a
seed function.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [RFC PATCH] crypto: make the seed() function optional

2017-10-06 Thread Herbert Xu
Mathieu Malaterre  wrote:
> This makes it simplier for driver author to not provide the seed() function
> in case of a pseudo RNG where the seed operation is a no-op.
> 
> Document that the seed() function pointer is optional in header.
> 
> Signed-off-by: Mathieu Malaterre 
> ---
> The PRNG as found on Ingenic JZ4780 is one such example. This is found on a
> MIPS Creator CI20 SoC.

So how does it seed itself? This also contradicts with the JZ4780
driver that's currently in the patch queue as it does contain a
seed function.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] mwifiex: Use put_unaligned_le32

2017-10-06 Thread kbuild test robot
Hi Himanshu,

[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.14-rc3 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Himanshu-Jha/mwifiex-Use-put_unaligned_le32/20171007-095017
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   In file included from arch/xtensa/include/asm/unaligned.h:22:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_struct.h:6:19: error: redefinition of 
>> 'get_unaligned_be16'
static inline u16 get_unaligned_be16(const void *p)
  ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:22:28: note: previous definition of 
'get_unaligned_be16' was here
static __always_inline u16 get_unaligned_be16(const void *p)
   ^
   In file included from arch/xtensa/include/asm/unaligned.h:22:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_struct.h:11:19: error: redefinition of 
>> 'get_unaligned_be32'
static inline u32 get_unaligned_be32(const void *p)
  ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:27:28: note: previous definition of 
'get_unaligned_be32' was here
static __always_inline u32 get_unaligned_be32(const void *p)
   ^
   In file included from arch/xtensa/include/asm/unaligned.h:22:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_struct.h:16:19: error: redefinition of 
>> 'get_unaligned_be64'
static inline u64 get_unaligned_be64(const void *p)
  ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:32:28: note: previous definition of 
'get_unaligned_be64' was here
static __always_inline u64 get_unaligned_be64(const void *p)
   ^
   In file included from arch/xtensa/include/asm/unaligned.h:22:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_struct.h:21:20: error: redefinition of 
>> 'put_unaligned_be16'
static inline void put_unaligned_be16(u16 val, void *p)
   ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:52:29: note: previous definition of 
'put_unaligned_be16' was here
static __always_inline void put_unaligned_be16(u16 val, void *p)
^
   In file included from arch/xtensa/include/asm/unaligned.h:22:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_struct.h:26:20: error: redefinition of 
>> 'put_unaligned_be32'
static inline void put_unaligned_be32(u32 val, void *p)
   ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:57:29: note: previous definition of 
'put_unaligned_be32' was here
static __always_inline void put_unaligned_be32(u32 val, void *p)
^
   In file included from arch/xtensa/include/asm/unaligned.h:22:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
   

Re: [PATCH] mwifiex: Use put_unaligned_le32

2017-10-06 Thread kbuild test robot
Hi Himanshu,

[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.14-rc3 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Himanshu-Jha/mwifiex-Use-put_unaligned_le32/20171007-095017
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   In file included from arch/xtensa/include/asm/unaligned.h:22:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_struct.h:6:19: error: redefinition of 
>> 'get_unaligned_be16'
static inline u16 get_unaligned_be16(const void *p)
  ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:22:28: note: previous definition of 
'get_unaligned_be16' was here
static __always_inline u16 get_unaligned_be16(const void *p)
   ^
   In file included from arch/xtensa/include/asm/unaligned.h:22:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_struct.h:11:19: error: redefinition of 
>> 'get_unaligned_be32'
static inline u32 get_unaligned_be32(const void *p)
  ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:27:28: note: previous definition of 
'get_unaligned_be32' was here
static __always_inline u32 get_unaligned_be32(const void *p)
   ^
   In file included from arch/xtensa/include/asm/unaligned.h:22:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_struct.h:16:19: error: redefinition of 
>> 'get_unaligned_be64'
static inline u64 get_unaligned_be64(const void *p)
  ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:32:28: note: previous definition of 
'get_unaligned_be64' was here
static __always_inline u64 get_unaligned_be64(const void *p)
   ^
   In file included from arch/xtensa/include/asm/unaligned.h:22:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_struct.h:21:20: error: redefinition of 
>> 'put_unaligned_be16'
static inline void put_unaligned_be16(u16 val, void *p)
   ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:52:29: note: previous definition of 
'put_unaligned_be16' was here
static __always_inline void put_unaligned_be16(u16 val, void *p)
^
   In file included from arch/xtensa/include/asm/unaligned.h:22:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
from drivers/net//wireless/marvell/mwifiex/cmdevt.c:21:
>> include/linux/unaligned/be_struct.h:26:20: error: redefinition of 
>> 'put_unaligned_be32'
static inline void put_unaligned_be32(u32 val, void *p)
   ^
   In file included from drivers/net//wireless/marvell/mwifiex/cmdevt.c:20:0:
   include/linux/unaligned/access_ok.h:57:29: note: previous definition of 
'put_unaligned_be32' was here
static __always_inline void put_unaligned_be32(u32 val, void *p)
^
   In file included from arch/xtensa/include/asm/unaligned.h:22:0,
from include/linux/etherdevice.h:28,
from include/linux/ieee80211.h:22,
from drivers/net//wireless/marvell/mwifiex/decl.h:28,
   

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-06 Thread Paul E. McKenney
On Fri, Oct 06, 2017 at 10:15:37PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 06, 2017 at 12:18:22PM -0700, Paul E. McKenney wrote:
> > > /me goes and install this herd thing again.. I'm sure I had it running
> > > _somewhere_.. A well.
> > > 
> > >   C C-PaulEMcKenney-W+RWC4+2017-10-05
> > > 
> > >   {
> > >   }
> > > 
> > >   P0(int *a, int *x)
> > >   {
> > >   WRITE_ONCE(*a, 1);
> > >   smp_mb(); /* Lock acquisition for rcu_node ->lock. */
> > >   WRITE_ONCE(*x, 1);
> > >   }
> > > 
> > >   P1(int *x, int *y)
> > >   {
> > >   r3 = READ_ONCE(*x);
> > >   smp_mb(); /* Lock acquisition for rcu_node ->lock. */
> > >   smp_store_release(y, 1);
> > >   }
> > > 
> > >   P2(int *y, int *b)
> > >   {
> > >   r4 = smp_load_acquire(y);
> > >   r1 = READ_ONCE(*b);
> > >   }
> > > 
> > >   P3(int *b, int *a)
> > >   {
> > >   WRITE_ONCE(*b, 1);
> > >   smp_mb();
> > >   r2 = READ_ONCE(*a);
> > >   }
> > > 
> > >   exists (1:r3=1 /\ 2:r4=1 /\ 2:r1=0 /\ 3:r2=0)
> > > 
> > > 
> > > Is what I was thinking of, I think that is the minimal ordering
> > > complete()/wait_for_completion() need to provide.
> > 
> > OK, I will bite...  What do the smp_store_release() and the
> > smp_load_acquire() correspond to?  I see just plain locking in
> > wait_for_completion() and complete().
> 
> They reflect the concept of complete() / wait_for_completion().
> Fundamentally all it needs to do is pass the message of 'completion'.
> 
> That is, if we were to go optimize our completion implementation, it
> would be impossible to be weaker than this and still correct.

OK, though the model does not provide spinlocks, and there can be
differences in behavior between spinlocks and release-acquire.
But yes, in this case, it works.

> > So I dropped that patch yesterday.  The main thing I was missing was
> > that there is no ordering-free fastpath in wait_for_completion() and
> > complete(): Each unconditionally acquires the lock.  So the smp_mb()
> > that I was trying to add doesn't need to be there.
> 
> Going by the above, it never needs to be there, even if there was a
> lock-free fast-path.

Given that wait_for_completion()/complete() both acquire the same lock,
yes, and agreed, if it were lockless but provided the release and
acquire ordering, then yes.  But if it was instead structured like
wait_event()/wake_up(), there would be ordering only if the caller
supplied it.

All that aside, paring the ordering down to the bare minimum is not
always the right approach.  Nevertheless, in this particular case,
there is plenty of ordering, so yet again, I have dropped this commit.
Like yesterday.  ;-)

Thanx, Paul



Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-06 Thread Paul E. McKenney
On Fri, Oct 06, 2017 at 10:15:37PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 06, 2017 at 12:18:22PM -0700, Paul E. McKenney wrote:
> > > /me goes and install this herd thing again.. I'm sure I had it running
> > > _somewhere_.. A well.
> > > 
> > >   C C-PaulEMcKenney-W+RWC4+2017-10-05
> > > 
> > >   {
> > >   }
> > > 
> > >   P0(int *a, int *x)
> > >   {
> > >   WRITE_ONCE(*a, 1);
> > >   smp_mb(); /* Lock acquisition for rcu_node ->lock. */
> > >   WRITE_ONCE(*x, 1);
> > >   }
> > > 
> > >   P1(int *x, int *y)
> > >   {
> > >   r3 = READ_ONCE(*x);
> > >   smp_mb(); /* Lock acquisition for rcu_node ->lock. */
> > >   smp_store_release(y, 1);
> > >   }
> > > 
> > >   P2(int *y, int *b)
> > >   {
> > >   r4 = smp_load_acquire(y);
> > >   r1 = READ_ONCE(*b);
> > >   }
> > > 
> > >   P3(int *b, int *a)
> > >   {
> > >   WRITE_ONCE(*b, 1);
> > >   smp_mb();
> > >   r2 = READ_ONCE(*a);
> > >   }
> > > 
> > >   exists (1:r3=1 /\ 2:r4=1 /\ 2:r1=0 /\ 3:r2=0)
> > > 
> > > 
> > > Is what I was thinking of, I think that is the minimal ordering
> > > complete()/wait_for_completion() need to provide.
> > 
> > OK, I will bite...  What do the smp_store_release() and the
> > smp_load_acquire() correspond to?  I see just plain locking in
> > wait_for_completion() and complete().
> 
> They reflect the concept of complete() / wait_for_completion().
> Fundamentally all it needs to do is pass the message of 'completion'.
> 
> That is, if we were to go optimize our completion implementation, it
> would be impossible to be weaker than this and still correct.

OK, though the model does not provide spinlocks, and there can be
differences in behavior between spinlocks and release-acquire.
But yes, in this case, it works.

> > So I dropped that patch yesterday.  The main thing I was missing was
> > that there is no ordering-free fastpath in wait_for_completion() and
> > complete(): Each unconditionally acquires the lock.  So the smp_mb()
> > that I was trying to add doesn't need to be there.
> 
> Going by the above, it never needs to be there, even if there was a
> lock-free fast-path.

Given that wait_for_completion()/complete() both acquire the same lock,
yes, and agreed, if it were lockless but provided the release and
acquire ordering, then yes.  But if it was instead structured like
wait_event()/wake_up(), there would be ordering only if the caller
supplied it.

All that aside, paring the ordering down to the bare minimum is not
always the right approach.  Nevertheless, in this particular case,
there is plenty of ordering, so yet again, I have dropped this commit.
Like yesterday.  ;-)

Thanx, Paul



follow this information

2017-10-06 Thread ''vinec''
hello,note that i am having problem with other e-mail.
i therefore, recommend you to register free via below link to increase your 
finance, free money no charges

click or copy link -  http://woredrzydo.win/8071093818423/

please get back to me after registration.


follow this information

2017-10-06 Thread ''vinec''
hello,note that i am having problem with other e-mail.
i therefore, recommend you to register free via below link to increase your 
finance, free money no charges

click or copy link -  http://woredrzydo.win/8071093818423/

please get back to me after registration.


Re: [BUG] GPF on reboot of box

2017-10-06 Thread Steven Rostedt
This bug still crashes my box on rc3

-- Steve


On October 6, 2017 10:21:26 PM EDT, Nadav Amit  wrote:
>Steven Rostedt  wrote:
>
>> Starting with v4.14-rc1 my box crashes during a reboot. All I get is
>> the following:
>> 
>> [  250.615793] sd 0:0:0:0: [sda] Synchronizing SCSI cache
>> [  250.635639] reboot: Restarting system
>> [  250.639671] reboot: machine restart
>> [  250.643842] general protection fault:  [#1] PREEMPT SMP KASAN
>> 
>> Then nothing. No reboot, it just hangs there.
>> 
>> I bisected it down to this commit:
>> 
>> 660da7c9228f ("x86/mm: Enable CR4.PCIDE on supported systems")
>> 
>> If I comment out the setting of X86_CR4_PCIDE in that commit, it
>boots
>> fine. But...
>> 
>> I noticed that commit c7ad5ad29 ("x86/mm/64: Initialize CR4.PCIDE
>> early") moved the problem code from arch/x86/kernel/cpu/common.c to
>> arch/x86/mm/init.c
>> 
>> If I comment it out in v4.14-rc1, it crashes on boot up.
>> 
>> It appears that my box doesn't like having X86_CR4_PCIDE set. it
>causes
>> reboot to fail. But it also appears that setting that is required for
>> some other code to work.
>
>IIRC, there was a problem in rc1, which should be resolved in newer
>rcs.
>If you need to run rc1, you can try to use the kernel parameter
>“nopcid".
>
>Nadav

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Re: [BUG] GPF on reboot of box

2017-10-06 Thread Steven Rostedt
This bug still crashes my box on rc3

-- Steve


On October 6, 2017 10:21:26 PM EDT, Nadav Amit  wrote:
>Steven Rostedt  wrote:
>
>> Starting with v4.14-rc1 my box crashes during a reboot. All I get is
>> the following:
>> 
>> [  250.615793] sd 0:0:0:0: [sda] Synchronizing SCSI cache
>> [  250.635639] reboot: Restarting system
>> [  250.639671] reboot: machine restart
>> [  250.643842] general protection fault:  [#1] PREEMPT SMP KASAN
>> 
>> Then nothing. No reboot, it just hangs there.
>> 
>> I bisected it down to this commit:
>> 
>> 660da7c9228f ("x86/mm: Enable CR4.PCIDE on supported systems")
>> 
>> If I comment out the setting of X86_CR4_PCIDE in that commit, it
>boots
>> fine. But...
>> 
>> I noticed that commit c7ad5ad29 ("x86/mm/64: Initialize CR4.PCIDE
>> early") moved the problem code from arch/x86/kernel/cpu/common.c to
>> arch/x86/mm/init.c
>> 
>> If I comment it out in v4.14-rc1, it crashes on boot up.
>> 
>> It appears that my box doesn't like having X86_CR4_PCIDE set. it
>causes
>> reboot to fail. But it also appears that setting that is required for
>> some other code to work.
>
>IIRC, there was a problem in rc1, which should be resolved in newer
>rcs.
>If you need to run rc1, you can try to use the kernel parameter
>“nopcid".
>
>Nadav

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()

2017-10-06 Thread Levin, Alexander (Sasha Levin)
On Fri, Oct 06, 2017 at 07:13:22PM +0100, Mark Rutland wrote:
>Hi Greg,
>
>On Fri, Oct 06, 2017 at 10:52:04AM +0200, Greg Kroah-Hartman wrote:
>> 4.9-stable review patch.  If anyone has any objections, please let me know.
>
>I'm a little confused as to why this is being backported, given it
>wasn't Cc'd stable or marked as a fix.
>
>The lm_alias() helper was only introduced in v4.10, and I don't recall
>seeing that backported.
>
>What's going on here?

Mark,

We are experimenting with using neural network to aid with patch
selection for stable kernel trees. There are quite a few commits that
were not marked for stable, but are stable material, and we're trying
to get them into their appropriate kernel trees.

-- 

Thanks,
Sasha

Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()

2017-10-06 Thread Levin, Alexander (Sasha Levin)
On Fri, Oct 06, 2017 at 07:13:22PM +0100, Mark Rutland wrote:
>Hi Greg,
>
>On Fri, Oct 06, 2017 at 10:52:04AM +0200, Greg Kroah-Hartman wrote:
>> 4.9-stable review patch.  If anyone has any objections, please let me know.
>
>I'm a little confused as to why this is being backported, given it
>wasn't Cc'd stable or marked as a fix.
>
>The lm_alias() helper was only introduced in v4.10, and I don't recall
>seeing that backported.
>
>What's going on here?

Mark,

We are experimenting with using neural network to aid with patch
selection for stable kernel trees. There are quite a few commits that
were not marked for stable, but are stable material, and we're trying
to get them into their appropriate kernel trees.

-- 

Thanks,
Sasha

Re: [PATCH v8 01/20] crypto: change transient busy return code to -EAGAIN

2017-10-06 Thread Herbert Xu
On Tue, Sep 05, 2017 at 03:38:40PM +0300, Gilad Ben-Yossef wrote:
>
> diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
> index 5e92bd2..3b3c154 100644
> --- a/crypto/algif_hash.c
> +++ b/crypto/algif_hash.c
> @@ -39,6 +39,20 @@ struct algif_hash_tfm {
>   bool has_key;
>  };
>  
> +/* Previous versions of crypto_* ops used to return -EBUSY
> + * rather than -EAGAIN to indicate being tied up. The in
> + * kernel API changed but we don't want to break the user
> + * space API. As only the hash user interface exposed this
> + * error ever to the user, do the translation here.
> + */
> +static inline int crypto_user_err(int err)
> +{
> + if (err == -EAGAIN)
> + return -EBUSY;
> +
> + return err;

I don't see the need to carry along this baggage.  Does anyone
in user-space actually rely on EBUSY?

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH v8 01/20] crypto: change transient busy return code to -EAGAIN

2017-10-06 Thread Herbert Xu
On Tue, Sep 05, 2017 at 03:38:40PM +0300, Gilad Ben-Yossef wrote:
>
> diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
> index 5e92bd2..3b3c154 100644
> --- a/crypto/algif_hash.c
> +++ b/crypto/algif_hash.c
> @@ -39,6 +39,20 @@ struct algif_hash_tfm {
>   bool has_key;
>  };
>  
> +/* Previous versions of crypto_* ops used to return -EBUSY
> + * rather than -EAGAIN to indicate being tied up. The in
> + * kernel API changed but we don't want to break the user
> + * space API. As only the hash user interface exposed this
> + * error ever to the user, do the translation here.
> + */
> +static inline int crypto_user_err(int err)
> +{
> + if (err == -EAGAIN)
> + return -EBUSY;
> +
> + return err;

I don't see the need to carry along this baggage.  Does anyone
in user-space actually rely on EBUSY?

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


[PATCH v2 2/4] kmemcheck: stop using GFP_NOTRACK and SLAB_NOTRACK

2017-10-06 Thread Levin, Alexander (Sasha Levin)
Convert all allocations that used a NOTRACK flag to stop using it.

Signed-off-by: Sasha Levin 
---
 arch/arm/include/asm/pgalloc.h   |  2 +-
 arch/arm64/include/asm/pgalloc.h |  2 +-
 arch/powerpc/include/asm/pgalloc.h   |  2 +-
 arch/sh/kernel/dwarf.c   |  4 ++--
 arch/sh/kernel/process.c |  2 +-
 arch/sparc/mm/init_64.c  |  4 ++--
 arch/unicore32/include/asm/pgalloc.h |  2 +-
 arch/x86/kernel/espfix_64.c  |  2 +-
 arch/x86/mm/init.c   |  3 +--
 arch/x86/mm/init_64.c|  2 +-
 arch/x86/mm/pageattr.c   | 10 +-
 arch/x86/mm/pgtable.c|  2 +-
 arch/x86/platform/efi/efi_64.c   |  2 +-
 crypto/xor.c |  7 +--
 include/linux/thread_info.h  |  5 ++---
 init/do_mounts.c |  3 +--
 kernel/fork.c| 12 ++--
 kernel/signal.c  |  3 +--
 mm/kmemcheck.c   |  2 +-
 mm/slab.c|  2 +-
 mm/slab.h|  5 ++---
 mm/slab_common.c |  2 +-
 mm/slub.c|  4 +---
 23 files changed, 36 insertions(+), 48 deletions(-)

diff --git a/arch/arm/include/asm/pgalloc.h b/arch/arm/include/asm/pgalloc.h
index b2902a5cd780..2d7344f0e208 100644
--- a/arch/arm/include/asm/pgalloc.h
+++ b/arch/arm/include/asm/pgalloc.h
@@ -57,7 +57,7 @@ static inline void pud_populate(struct mm_struct *mm, pud_t 
*pud, pmd_t *pmd)
 extern pgd_t *pgd_alloc(struct mm_struct *mm);
 extern void pgd_free(struct mm_struct *mm, pgd_t *pgd);
 
-#define PGALLOC_GFP(GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO)
+#define PGALLOC_GFP(GFP_KERNEL | __GFP_ZERO)
 
 static inline void clean_pte_table(pte_t *pte)
 {
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index d25f4f137c2a..5ca6a573a701 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -26,7 +26,7 @@
 
 #define check_pgt_cache()  do { } while (0)
 
-#define PGALLOC_GFP(GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO)
+#define PGALLOC_GFP(GFP_KERNEL | __GFP_ZERO)
 #define PGD_SIZE   (PTRS_PER_PGD * sizeof(pgd_t))
 
 #if CONFIG_PGTABLE_LEVELS > 2
diff --git a/arch/powerpc/include/asm/pgalloc.h 
b/arch/powerpc/include/asm/pgalloc.h
index 45ae1212ab8a..bb01297b617a 100644
--- a/arch/powerpc/include/asm/pgalloc.h
+++ b/arch/powerpc/include/asm/pgalloc.h
@@ -17,7 +17,7 @@ static inline gfp_t pgtable_gfp_flags(struct mm_struct *mm, 
gfp_t gfp)
 }
 #endif /* MODULE */
 
-#define PGALLOC_GFP (GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO)
+#define PGALLOC_GFP (GFP_KERNEL | __GFP_ZERO)
 
 #ifdef CONFIG_PPC_BOOK3S
 #include 
diff --git a/arch/sh/kernel/dwarf.c b/arch/sh/kernel/dwarf.c
index e1d751ae2498..1a2526676a87 100644
--- a/arch/sh/kernel/dwarf.c
+++ b/arch/sh/kernel/dwarf.c
@@ -1172,11 +1172,11 @@ static int __init dwarf_unwinder_init(void)
 
dwarf_frame_cachep = kmem_cache_create("dwarf_frames",
sizeof(struct dwarf_frame), 0,
-   SLAB_PANIC | SLAB_HWCACHE_ALIGN | SLAB_NOTRACK, NULL);
+   SLAB_PANIC | SLAB_HWCACHE_ALIGN, NULL);
 
dwarf_reg_cachep = kmem_cache_create("dwarf_regs",
sizeof(struct dwarf_reg), 0,
-   SLAB_PANIC | SLAB_HWCACHE_ALIGN | SLAB_NOTRACK, NULL);
+   SLAB_PANIC | SLAB_HWCACHE_ALIGN, NULL);
 
dwarf_frame_pool = mempool_create_slab_pool(DWARF_FRAME_MIN_REQ,
dwarf_frame_cachep);
diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c
index f8a695a223dd..ded55e7461f8 100644
--- a/arch/sh/kernel/process.c
+++ b/arch/sh/kernel/process.c
@@ -58,7 +58,7 @@ void arch_task_cache_init(void)
 
task_xstate_cachep = kmem_cache_create("task_xstate", xstate_size,
   __alignof__(union thread_xstate),
-  SLAB_PANIC | SLAB_NOTRACK, NULL);
+  SLAB_PANIC, NULL);
 }
 
 #ifdef CONFIG_SH_FPU_EMU
diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index b2ba410b26f4..78f79004be2c 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -2926,7 +2926,7 @@ void __flush_tlb_all(void)
 pte_t *pte_alloc_one_kernel(struct mm_struct *mm,
unsigned long address)
 {
-   struct page *page = alloc_page(GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO);
+   struct page *page = alloc_page(GFP_KERNEL | __GFP_ZERO);
pte_t *pte = NULL;
 
if (page)
@@ -2938,7 +2938,7 @@ pte_t *pte_alloc_one_kernel(struct mm_struct *mm,
 pgtable_t pte_alloc_one(struct mm_struct *mm,
unsigned long address)
 {
-   struct page *page = alloc_page(GFP_KERNEL | __GFP_NOTRACK | 

[PATCH v2 2/4] kmemcheck: stop using GFP_NOTRACK and SLAB_NOTRACK

2017-10-06 Thread Levin, Alexander (Sasha Levin)
Convert all allocations that used a NOTRACK flag to stop using it.

Signed-off-by: Sasha Levin 
---
 arch/arm/include/asm/pgalloc.h   |  2 +-
 arch/arm64/include/asm/pgalloc.h |  2 +-
 arch/powerpc/include/asm/pgalloc.h   |  2 +-
 arch/sh/kernel/dwarf.c   |  4 ++--
 arch/sh/kernel/process.c |  2 +-
 arch/sparc/mm/init_64.c  |  4 ++--
 arch/unicore32/include/asm/pgalloc.h |  2 +-
 arch/x86/kernel/espfix_64.c  |  2 +-
 arch/x86/mm/init.c   |  3 +--
 arch/x86/mm/init_64.c|  2 +-
 arch/x86/mm/pageattr.c   | 10 +-
 arch/x86/mm/pgtable.c|  2 +-
 arch/x86/platform/efi/efi_64.c   |  2 +-
 crypto/xor.c |  7 +--
 include/linux/thread_info.h  |  5 ++---
 init/do_mounts.c |  3 +--
 kernel/fork.c| 12 ++--
 kernel/signal.c  |  3 +--
 mm/kmemcheck.c   |  2 +-
 mm/slab.c|  2 +-
 mm/slab.h|  5 ++---
 mm/slab_common.c |  2 +-
 mm/slub.c|  4 +---
 23 files changed, 36 insertions(+), 48 deletions(-)

diff --git a/arch/arm/include/asm/pgalloc.h b/arch/arm/include/asm/pgalloc.h
index b2902a5cd780..2d7344f0e208 100644
--- a/arch/arm/include/asm/pgalloc.h
+++ b/arch/arm/include/asm/pgalloc.h
@@ -57,7 +57,7 @@ static inline void pud_populate(struct mm_struct *mm, pud_t 
*pud, pmd_t *pmd)
 extern pgd_t *pgd_alloc(struct mm_struct *mm);
 extern void pgd_free(struct mm_struct *mm, pgd_t *pgd);
 
-#define PGALLOC_GFP(GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO)
+#define PGALLOC_GFP(GFP_KERNEL | __GFP_ZERO)
 
 static inline void clean_pte_table(pte_t *pte)
 {
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index d25f4f137c2a..5ca6a573a701 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -26,7 +26,7 @@
 
 #define check_pgt_cache()  do { } while (0)
 
-#define PGALLOC_GFP(GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO)
+#define PGALLOC_GFP(GFP_KERNEL | __GFP_ZERO)
 #define PGD_SIZE   (PTRS_PER_PGD * sizeof(pgd_t))
 
 #if CONFIG_PGTABLE_LEVELS > 2
diff --git a/arch/powerpc/include/asm/pgalloc.h 
b/arch/powerpc/include/asm/pgalloc.h
index 45ae1212ab8a..bb01297b617a 100644
--- a/arch/powerpc/include/asm/pgalloc.h
+++ b/arch/powerpc/include/asm/pgalloc.h
@@ -17,7 +17,7 @@ static inline gfp_t pgtable_gfp_flags(struct mm_struct *mm, 
gfp_t gfp)
 }
 #endif /* MODULE */
 
-#define PGALLOC_GFP (GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO)
+#define PGALLOC_GFP (GFP_KERNEL | __GFP_ZERO)
 
 #ifdef CONFIG_PPC_BOOK3S
 #include 
diff --git a/arch/sh/kernel/dwarf.c b/arch/sh/kernel/dwarf.c
index e1d751ae2498..1a2526676a87 100644
--- a/arch/sh/kernel/dwarf.c
+++ b/arch/sh/kernel/dwarf.c
@@ -1172,11 +1172,11 @@ static int __init dwarf_unwinder_init(void)
 
dwarf_frame_cachep = kmem_cache_create("dwarf_frames",
sizeof(struct dwarf_frame), 0,
-   SLAB_PANIC | SLAB_HWCACHE_ALIGN | SLAB_NOTRACK, NULL);
+   SLAB_PANIC | SLAB_HWCACHE_ALIGN, NULL);
 
dwarf_reg_cachep = kmem_cache_create("dwarf_regs",
sizeof(struct dwarf_reg), 0,
-   SLAB_PANIC | SLAB_HWCACHE_ALIGN | SLAB_NOTRACK, NULL);
+   SLAB_PANIC | SLAB_HWCACHE_ALIGN, NULL);
 
dwarf_frame_pool = mempool_create_slab_pool(DWARF_FRAME_MIN_REQ,
dwarf_frame_cachep);
diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c
index f8a695a223dd..ded55e7461f8 100644
--- a/arch/sh/kernel/process.c
+++ b/arch/sh/kernel/process.c
@@ -58,7 +58,7 @@ void arch_task_cache_init(void)
 
task_xstate_cachep = kmem_cache_create("task_xstate", xstate_size,
   __alignof__(union thread_xstate),
-  SLAB_PANIC | SLAB_NOTRACK, NULL);
+  SLAB_PANIC, NULL);
 }
 
 #ifdef CONFIG_SH_FPU_EMU
diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index b2ba410b26f4..78f79004be2c 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -2926,7 +2926,7 @@ void __flush_tlb_all(void)
 pte_t *pte_alloc_one_kernel(struct mm_struct *mm,
unsigned long address)
 {
-   struct page *page = alloc_page(GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO);
+   struct page *page = alloc_page(GFP_KERNEL | __GFP_ZERO);
pte_t *pte = NULL;
 
if (page)
@@ -2938,7 +2938,7 @@ pte_t *pte_alloc_one_kernel(struct mm_struct *mm,
 pgtable_t pte_alloc_one(struct mm_struct *mm,
unsigned long address)
 {
-   struct page *page = alloc_page(GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO);
+   struct page 

[PATCH v2 1/4] kmemcheck: remove annotations

2017-10-06 Thread Levin, Alexander (Sasha Levin)
Remove kmemcheck annotations, and calls to kmemcheck from the kernel.

Signed-off-by: Sasha Levin 
---
 arch/arm/include/asm/dma-iommu.h|  1 -
 arch/openrisc/include/asm/dma-mapping.h |  1 -
 arch/x86/Makefile   |  5 -
 arch/x86/include/asm/dma-mapping.h  |  1 -
 arch/x86/include/asm/xor.h  |  5 +
 arch/x86/kernel/traps.c |  5 -
 arch/x86/mm/fault.c |  6 --
 drivers/char/random.c   |  1 -
 drivers/misc/c2port/core.c  |  2 --
 fs/dcache.c |  2 --
 include/linux/c2port.h  |  4 
 include/linux/dma-mapping.h |  4 
 include/linux/filter.h  |  2 --
 include/linux/mm_types.h|  8 
 include/linux/net.h |  3 ---
 include/linux/ring_buffer.h |  3 ---
 include/linux/skbuff.h  |  3 ---
 include/net/inet_sock.h |  3 ---
 include/net/inet_timewait_sock.h|  4 
 include/net/sock.h  |  3 ---
 init/main.c |  1 -
 kernel/bpf/core.c   |  6 --
 kernel/locking/lockdep.c|  3 ---
 kernel/trace/ring_buffer.c  |  3 ---
 mm/kmemleak.c   |  9 -
 mm/page_alloc.c | 14 --
 mm/slab.c   | 14 --
 mm/slab.h   |  2 --
 mm/slub.c   | 20 
 net/core/skbuff.c   |  5 -
 net/core/sock.c |  2 --
 net/ipv4/inet_timewait_sock.c   |  3 ---
 net/ipv4/tcp_input.c|  1 -
 net/socket.c|  1 -
 34 files changed, 1 insertion(+), 149 deletions(-)

diff --git a/arch/arm/include/asm/dma-iommu.h b/arch/arm/include/asm/dma-iommu.h
index c090ec675eac..5ad676f2de22 100644
--- a/arch/arm/include/asm/dma-iommu.h
+++ b/arch/arm/include/asm/dma-iommu.h
@@ -6,7 +6,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #define ARM_MAPPING_ERROR  (~(dma_addr_t)0x0)
diff --git a/arch/openrisc/include/asm/dma-mapping.h 
b/arch/openrisc/include/asm/dma-mapping.h
index f41bd3cb76d9..e212a1f0b6d2 100644
--- a/arch/openrisc/include/asm/dma-mapping.h
+++ b/arch/openrisc/include/asm/dma-mapping.h
@@ -23,7 +23,6 @@
  */
 
 #include 
-#include 
 #include 
 
 extern const struct dma_map_ops or1k_dma_map_ops;
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 6276572259c8..559eb0a282fd 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -157,11 +157,6 @@ ifdef CONFIG_X86_X32
 endif
 export CONFIG_X86_X32_ABI
 
-# Don't unroll struct assignments with kmemcheck enabled
-ifeq ($(CONFIG_KMEMCHECK),y)
-   KBUILD_CFLAGS += $(call cc-option,-fno-builtin-memcpy)
-endif
-
 #
 # If the function graph tracer is used with mcount instead of fentry,
 # '-maccumulate-outgoing-args' is needed to prevent a GCC bug
diff --git a/arch/x86/include/asm/dma-mapping.h 
b/arch/x86/include/asm/dma-mapping.h
index 1387dafdba2d..bd974c04c9aa 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -6,7 +6,6 @@
  * Documentation/DMA-API.txt for documentation.
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/include/asm/xor.h b/arch/x86/include/asm/xor.h
index 1f5c5161ead6..45c8605467f1 100644
--- a/arch/x86/include/asm/xor.h
+++ b/arch/x86/include/asm/xor.h
@@ -1,7 +1,4 @@
-#ifdef CONFIG_KMEMCHECK
-/* kmemcheck doesn't handle MMX/SSE/SSE2 instructions */
-# include 
-#elif !defined(_ASM_X86_XOR_H)
+#ifndef _ASM_X86_XOR_H
 #define _ASM_X86_XOR_H
 
 /*
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 67db4f43309e..969bb67e06f4 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -42,7 +42,6 @@
 #include 
 #endif
 
-#include 
 #include 
 #include 
 #include 
@@ -740,10 +739,6 @@ dotraplinkage void do_debug(struct pt_regs *regs, long 
error_code)
if (!dr6 && user_mode(regs))
user_icebp = 1;
 
-   /* Catch kmemcheck conditions! */
-   if ((dr6 & DR_STEP) && kmemcheck_trap(regs))
-   goto exit;
-
/* Store the virtualized DR6 value */
tsk->thread.debugreg6 = dr6;
 
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index e2baeaa053a5..a4f96448bc7a 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -19,7 +19,6 @@
 #include /* boot_cpu_has, ...*/
 #include  /* dotraplinkage, ...   */
 #include/* pgd_*(), ... */
-#include  /* kmemcheck_*(), ...   */
 #include /* VSYSCALL_ADDR
*/
 #include   /* emulate_vsyscall */
 #include   /* struct 

[PATCH v2 3/4] kmemcheck: rip it out

2017-10-06 Thread Levin, Alexander (Sasha Levin)
Fix up makefiles, remove references, and git rm kmemcheck.

Signed-off-by: Sasha Levin 
---
 Documentation/admin-guide/kernel-parameters.txt |   7 -
 Documentation/dev-tools/index.rst   |   1 -
 Documentation/dev-tools/kmemcheck.rst   | 733 
 MAINTAINERS |  10 -
 arch/x86/Kconfig|   3 +-
 arch/x86/include/asm/kmemcheck.h|  42 --
 arch/x86/include/asm/string_32.h|   9 -
 arch/x86/include/asm/string_64.h|   8 -
 arch/x86/kernel/cpu/intel.c |  15 -
 arch/x86/mm/Makefile|   2 -
 arch/x86/mm/init.c  |   5 +-
 arch/x86/mm/kmemcheck/Makefile  |   1 -
 arch/x86/mm/kmemcheck/error.c   | 227 
 arch/x86/mm/kmemcheck/error.h   |  15 -
 arch/x86/mm/kmemcheck/kmemcheck.c   | 658 -
 arch/x86/mm/kmemcheck/opcode.c  | 106 
 arch/x86/mm/kmemcheck/opcode.h  |   9 -
 arch/x86/mm/kmemcheck/pte.c |  22 -
 arch/x86/mm/kmemcheck/pte.h |  10 -
 arch/x86/mm/kmemcheck/selftest.c|  70 ---
 arch/x86/mm/kmemcheck/selftest.h|   6 -
 arch/x86/mm/kmemcheck/shadow.c  | 173 --
 arch/x86/mm/kmemcheck/shadow.h  |  18 -
 include/linux/interrupt.h   |  15 -
 include/linux/kmemcheck.h   | 171 --
 kernel/softirq.c|  10 -
 kernel/sysctl.c |  10 -
 lib/Kconfig.debug   |   6 +-
 lib/Kconfig.kmemcheck   |  94 ---
 mm/Kconfig.debug|   1 -
 mm/Makefile |   2 -
 mm/kmemcheck.c  | 125 
 mm/slub.c   |   5 +-
 scripts/kernel-doc  |   2 -
 tools/include/linux/kmemcheck.h |   8 -
 35 files changed, 7 insertions(+), 2592 deletions(-)
 delete mode 100644 Documentation/dev-tools/kmemcheck.rst
 delete mode 100644 arch/x86/include/asm/kmemcheck.h
 delete mode 100644 arch/x86/mm/kmemcheck/Makefile
 delete mode 100644 arch/x86/mm/kmemcheck/error.c
 delete mode 100644 arch/x86/mm/kmemcheck/error.h
 delete mode 100644 arch/x86/mm/kmemcheck/kmemcheck.c
 delete mode 100644 arch/x86/mm/kmemcheck/opcode.c
 delete mode 100644 arch/x86/mm/kmemcheck/opcode.h
 delete mode 100644 arch/x86/mm/kmemcheck/pte.c
 delete mode 100644 arch/x86/mm/kmemcheck/pte.h
 delete mode 100644 arch/x86/mm/kmemcheck/selftest.c
 delete mode 100644 arch/x86/mm/kmemcheck/selftest.h
 delete mode 100644 arch/x86/mm/kmemcheck/shadow.c
 delete mode 100644 arch/x86/mm/kmemcheck/shadow.h
 delete mode 100644 include/linux/kmemcheck.h
 delete mode 100644 lib/Kconfig.kmemcheck
 delete mode 100644 mm/kmemcheck.c
 delete mode 100644 tools/include/linux/kmemcheck.h

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 05496622b4ef..5e1e0e7ebee3 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1841,13 +1841,6 @@
Built with CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y,
the default is off.
 
-   kmemcheck=  [X86] Boot-time kmemcheck enable/disable/one-shot mode
-   Valid arguments: 0, 1, 2
-   kmemcheck=0 (disabled)
-   kmemcheck=1 (enabled)
-   kmemcheck=2 (one-shot mode)
-   Default: 2 (one-shot mode)
-
kvm.ignore_msrs=[KVM] Ignore guest accesses to unhandled MSRs.
Default is 0 (don't ignore, but inject #GP)
 
diff --git a/Documentation/dev-tools/index.rst 
b/Documentation/dev-tools/index.rst
index a81787cd47d7..e313925fb0fa 100644
--- a/Documentation/dev-tools/index.rst
+++ b/Documentation/dev-tools/index.rst
@@ -21,7 +21,6 @@ whole; patches welcome!
kasan
ubsan
kmemleak
-   kmemcheck
gdb-kernel-debugging
kgdb
kselftest
diff --git a/Documentation/dev-tools/kmemcheck.rst 
b/Documentation/dev-tools/kmemcheck.rst
deleted file mode 100644
index 7f3d1985de74..
--- a/Documentation/dev-tools/kmemcheck.rst
+++ /dev/null
@@ -1,733 +0,0 @@
-Getting started with kmemcheck
-==
-
-Vegard Nossum 
-
-
-Introduction
-
-
-kmemcheck is a debugging feature for the Linux Kernel. More specifically, it
-is a dynamic checker that detects and warns about some uses of uninitialized
-memory.
-
-Userspace programmers might be familiar with Valgrind's memcheck. The main
-difference between memcheck and 

[PATCH v2 1/4] kmemcheck: remove annotations

2017-10-06 Thread Levin, Alexander (Sasha Levin)
Remove kmemcheck annotations, and calls to kmemcheck from the kernel.

Signed-off-by: Sasha Levin 
---
 arch/arm/include/asm/dma-iommu.h|  1 -
 arch/openrisc/include/asm/dma-mapping.h |  1 -
 arch/x86/Makefile   |  5 -
 arch/x86/include/asm/dma-mapping.h  |  1 -
 arch/x86/include/asm/xor.h  |  5 +
 arch/x86/kernel/traps.c |  5 -
 arch/x86/mm/fault.c |  6 --
 drivers/char/random.c   |  1 -
 drivers/misc/c2port/core.c  |  2 --
 fs/dcache.c |  2 --
 include/linux/c2port.h  |  4 
 include/linux/dma-mapping.h |  4 
 include/linux/filter.h  |  2 --
 include/linux/mm_types.h|  8 
 include/linux/net.h |  3 ---
 include/linux/ring_buffer.h |  3 ---
 include/linux/skbuff.h  |  3 ---
 include/net/inet_sock.h |  3 ---
 include/net/inet_timewait_sock.h|  4 
 include/net/sock.h  |  3 ---
 init/main.c |  1 -
 kernel/bpf/core.c   |  6 --
 kernel/locking/lockdep.c|  3 ---
 kernel/trace/ring_buffer.c  |  3 ---
 mm/kmemleak.c   |  9 -
 mm/page_alloc.c | 14 --
 mm/slab.c   | 14 --
 mm/slab.h   |  2 --
 mm/slub.c   | 20 
 net/core/skbuff.c   |  5 -
 net/core/sock.c |  2 --
 net/ipv4/inet_timewait_sock.c   |  3 ---
 net/ipv4/tcp_input.c|  1 -
 net/socket.c|  1 -
 34 files changed, 1 insertion(+), 149 deletions(-)

diff --git a/arch/arm/include/asm/dma-iommu.h b/arch/arm/include/asm/dma-iommu.h
index c090ec675eac..5ad676f2de22 100644
--- a/arch/arm/include/asm/dma-iommu.h
+++ b/arch/arm/include/asm/dma-iommu.h
@@ -6,7 +6,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #define ARM_MAPPING_ERROR  (~(dma_addr_t)0x0)
diff --git a/arch/openrisc/include/asm/dma-mapping.h 
b/arch/openrisc/include/asm/dma-mapping.h
index f41bd3cb76d9..e212a1f0b6d2 100644
--- a/arch/openrisc/include/asm/dma-mapping.h
+++ b/arch/openrisc/include/asm/dma-mapping.h
@@ -23,7 +23,6 @@
  */
 
 #include 
-#include 
 #include 
 
 extern const struct dma_map_ops or1k_dma_map_ops;
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 6276572259c8..559eb0a282fd 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -157,11 +157,6 @@ ifdef CONFIG_X86_X32
 endif
 export CONFIG_X86_X32_ABI
 
-# Don't unroll struct assignments with kmemcheck enabled
-ifeq ($(CONFIG_KMEMCHECK),y)
-   KBUILD_CFLAGS += $(call cc-option,-fno-builtin-memcpy)
-endif
-
 #
 # If the function graph tracer is used with mcount instead of fentry,
 # '-maccumulate-outgoing-args' is needed to prevent a GCC bug
diff --git a/arch/x86/include/asm/dma-mapping.h 
b/arch/x86/include/asm/dma-mapping.h
index 1387dafdba2d..bd974c04c9aa 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -6,7 +6,6 @@
  * Documentation/DMA-API.txt for documentation.
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/include/asm/xor.h b/arch/x86/include/asm/xor.h
index 1f5c5161ead6..45c8605467f1 100644
--- a/arch/x86/include/asm/xor.h
+++ b/arch/x86/include/asm/xor.h
@@ -1,7 +1,4 @@
-#ifdef CONFIG_KMEMCHECK
-/* kmemcheck doesn't handle MMX/SSE/SSE2 instructions */
-# include 
-#elif !defined(_ASM_X86_XOR_H)
+#ifndef _ASM_X86_XOR_H
 #define _ASM_X86_XOR_H
 
 /*
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 67db4f43309e..969bb67e06f4 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -42,7 +42,6 @@
 #include 
 #endif
 
-#include 
 #include 
 #include 
 #include 
@@ -740,10 +739,6 @@ dotraplinkage void do_debug(struct pt_regs *regs, long 
error_code)
if (!dr6 && user_mode(regs))
user_icebp = 1;
 
-   /* Catch kmemcheck conditions! */
-   if ((dr6 & DR_STEP) && kmemcheck_trap(regs))
-   goto exit;
-
/* Store the virtualized DR6 value */
tsk->thread.debugreg6 = dr6;
 
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index e2baeaa053a5..a4f96448bc7a 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -19,7 +19,6 @@
 #include /* boot_cpu_has, ...*/
 #include  /* dotraplinkage, ...   */
 #include/* pgd_*(), ... */
-#include  /* kmemcheck_*(), ...   */
 #include /* VSYSCALL_ADDR
*/
 #include   /* emulate_vsyscall */
 #include   /* struct vm86  */
@@ 

[PATCH v2 3/4] kmemcheck: rip it out

2017-10-06 Thread Levin, Alexander (Sasha Levin)
Fix up makefiles, remove references, and git rm kmemcheck.

Signed-off-by: Sasha Levin 
---
 Documentation/admin-guide/kernel-parameters.txt |   7 -
 Documentation/dev-tools/index.rst   |   1 -
 Documentation/dev-tools/kmemcheck.rst   | 733 
 MAINTAINERS |  10 -
 arch/x86/Kconfig|   3 +-
 arch/x86/include/asm/kmemcheck.h|  42 --
 arch/x86/include/asm/string_32.h|   9 -
 arch/x86/include/asm/string_64.h|   8 -
 arch/x86/kernel/cpu/intel.c |  15 -
 arch/x86/mm/Makefile|   2 -
 arch/x86/mm/init.c  |   5 +-
 arch/x86/mm/kmemcheck/Makefile  |   1 -
 arch/x86/mm/kmemcheck/error.c   | 227 
 arch/x86/mm/kmemcheck/error.h   |  15 -
 arch/x86/mm/kmemcheck/kmemcheck.c   | 658 -
 arch/x86/mm/kmemcheck/opcode.c  | 106 
 arch/x86/mm/kmemcheck/opcode.h  |   9 -
 arch/x86/mm/kmemcheck/pte.c |  22 -
 arch/x86/mm/kmemcheck/pte.h |  10 -
 arch/x86/mm/kmemcheck/selftest.c|  70 ---
 arch/x86/mm/kmemcheck/selftest.h|   6 -
 arch/x86/mm/kmemcheck/shadow.c  | 173 --
 arch/x86/mm/kmemcheck/shadow.h  |  18 -
 include/linux/interrupt.h   |  15 -
 include/linux/kmemcheck.h   | 171 --
 kernel/softirq.c|  10 -
 kernel/sysctl.c |  10 -
 lib/Kconfig.debug   |   6 +-
 lib/Kconfig.kmemcheck   |  94 ---
 mm/Kconfig.debug|   1 -
 mm/Makefile |   2 -
 mm/kmemcheck.c  | 125 
 mm/slub.c   |   5 +-
 scripts/kernel-doc  |   2 -
 tools/include/linux/kmemcheck.h |   8 -
 35 files changed, 7 insertions(+), 2592 deletions(-)
 delete mode 100644 Documentation/dev-tools/kmemcheck.rst
 delete mode 100644 arch/x86/include/asm/kmemcheck.h
 delete mode 100644 arch/x86/mm/kmemcheck/Makefile
 delete mode 100644 arch/x86/mm/kmemcheck/error.c
 delete mode 100644 arch/x86/mm/kmemcheck/error.h
 delete mode 100644 arch/x86/mm/kmemcheck/kmemcheck.c
 delete mode 100644 arch/x86/mm/kmemcheck/opcode.c
 delete mode 100644 arch/x86/mm/kmemcheck/opcode.h
 delete mode 100644 arch/x86/mm/kmemcheck/pte.c
 delete mode 100644 arch/x86/mm/kmemcheck/pte.h
 delete mode 100644 arch/x86/mm/kmemcheck/selftest.c
 delete mode 100644 arch/x86/mm/kmemcheck/selftest.h
 delete mode 100644 arch/x86/mm/kmemcheck/shadow.c
 delete mode 100644 arch/x86/mm/kmemcheck/shadow.h
 delete mode 100644 include/linux/kmemcheck.h
 delete mode 100644 lib/Kconfig.kmemcheck
 delete mode 100644 mm/kmemcheck.c
 delete mode 100644 tools/include/linux/kmemcheck.h

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 05496622b4ef..5e1e0e7ebee3 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1841,13 +1841,6 @@
Built with CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y,
the default is off.
 
-   kmemcheck=  [X86] Boot-time kmemcheck enable/disable/one-shot mode
-   Valid arguments: 0, 1, 2
-   kmemcheck=0 (disabled)
-   kmemcheck=1 (enabled)
-   kmemcheck=2 (one-shot mode)
-   Default: 2 (one-shot mode)
-
kvm.ignore_msrs=[KVM] Ignore guest accesses to unhandled MSRs.
Default is 0 (don't ignore, but inject #GP)
 
diff --git a/Documentation/dev-tools/index.rst 
b/Documentation/dev-tools/index.rst
index a81787cd47d7..e313925fb0fa 100644
--- a/Documentation/dev-tools/index.rst
+++ b/Documentation/dev-tools/index.rst
@@ -21,7 +21,6 @@ whole; patches welcome!
kasan
ubsan
kmemleak
-   kmemcheck
gdb-kernel-debugging
kgdb
kselftest
diff --git a/Documentation/dev-tools/kmemcheck.rst 
b/Documentation/dev-tools/kmemcheck.rst
deleted file mode 100644
index 7f3d1985de74..
--- a/Documentation/dev-tools/kmemcheck.rst
+++ /dev/null
@@ -1,733 +0,0 @@
-Getting started with kmemcheck
-==
-
-Vegard Nossum 
-
-
-Introduction
-
-
-kmemcheck is a debugging feature for the Linux Kernel. More specifically, it
-is a dynamic checker that detects and warns about some uses of uninitialized
-memory.
-
-Userspace programmers might be familiar with Valgrind's memcheck. The main
-difference between memcheck and kmemcheck is that memcheck works for userspace
-programs 

[PATCH v2 4/4] kmemcheck: remove whats left of NOTRACK flags

2017-10-06 Thread Levin, Alexander (Sasha Levin)
Now that kmemcheck is gone, we don't need the NOTRACK flags.

Signed-off-by: Sasha Levin 
---
 arch/x86/include/asm/pgtable.h   |  5 -
 arch/x86/include/asm/pgtable_types.h | 13 -
 include/linux/gfp.h  |  9 -
 include/linux/slab.h |  6 --
 include/trace/events/mmflags.h   |  1 -
 mm/slub.c|  2 --
 tools/perf/builtin-kmem.c|  1 -
 7 files changed, 37 deletions(-)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index b714934512b3..d110e38893d1 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -666,11 +666,6 @@ static inline bool pte_accessible(struct mm_struct *mm, 
pte_t a)
return false;
 }
 
-static inline int pte_hidden(pte_t pte)
-{
-   return pte_flags(pte) & _PAGE_HIDDEN;
-}
-
 static inline int pmd_present(pmd_t pmd)
 {
/*
diff --git a/arch/x86/include/asm/pgtable_types.h 
b/arch/x86/include/asm/pgtable_types.h
index f1492473f10e..27e230dec7a4 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -31,7 +31,6 @@
 
 #define _PAGE_BIT_SPECIAL  _PAGE_BIT_SOFTW1
 #define _PAGE_BIT_CPA_TEST _PAGE_BIT_SOFTW1
-#define _PAGE_BIT_HIDDEN   _PAGE_BIT_SOFTW3 /* hidden by kmemcheck */
 #define _PAGE_BIT_SOFT_DIRTY   _PAGE_BIT_SOFTW3 /* software dirty tracking */
 #define _PAGE_BIT_DEVMAP   _PAGE_BIT_SOFTW4
 
@@ -78,18 +77,6 @@
 #define _PAGE_KNL_ERRATUM_MASK 0
 #endif
 
-#ifdef CONFIG_KMEMCHECK
-#define _PAGE_HIDDEN   (_AT(pteval_t, 1) << _PAGE_BIT_HIDDEN)
-#else
-#define _PAGE_HIDDEN   (_AT(pteval_t, 0))
-#endif
-
-/*
- * The same hidden bit is used by kmemcheck, but since kmemcheck
- * works on kernel pages while soft-dirty engine on user space,
- * they do not conflict with each other.
- */
-
 #ifdef CONFIG_MEM_SOFT_DIRTY
 #define _PAGE_SOFT_DIRTY   (_AT(pteval_t, 1) << _PAGE_BIT_SOFT_DIRTY)
 #else
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index f780718b7391..3427fb8d936a 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -36,7 +36,6 @@ struct vm_area_struct;
 #define ___GFP_THISNODE0x4u
 #define ___GFP_ATOMIC  0x8u
 #define ___GFP_ACCOUNT 0x10u
-#define ___GFP_NOTRACK 0x20u
 #define ___GFP_DIRECT_RECLAIM  0x40u
 #define ___GFP_WRITE   0x80u
 #define ___GFP_KSWAPD_RECLAIM  0x100u
@@ -200,19 +199,11 @@ struct vm_area_struct;
  * __GFP_COMP address compound page metadata.
  *
  * __GFP_ZERO returns a zeroed page on success.
- *
- * __GFP_NOTRACK avoids tracking with kmemcheck.
- *
- * __GFP_NOTRACK_FALSE_POSITIVE is an alias of __GFP_NOTRACK. It's a means of
- *   distinguishing in the source between false positives and allocations that
- *   cannot be supported (e.g. page tables).
  */
 #define __GFP_COLD ((__force gfp_t)___GFP_COLD)
 #define __GFP_NOWARN   ((__force gfp_t)___GFP_NOWARN)
 #define __GFP_COMP ((__force gfp_t)___GFP_COMP)
 #define __GFP_ZERO ((__force gfp_t)___GFP_ZERO)
-#define __GFP_NOTRACK  ((__force gfp_t)___GFP_NOTRACK)
-#define __GFP_NOTRACK_FALSE_POSITIVE (__GFP_NOTRACK)
 
 /* Disable lockdep for GFP context tracking */
 #define __GFP_NOLOCKDEP ((__force gfp_t)___GFP_NOLOCKDEP)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 41473df6dfb0..f35c640687a0 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -77,12 +77,6 @@
 
 #define SLAB_NOLEAKTRACE   0x0080UL/* Avoid kmemleak tracing */
 
-/* Don't track use of uninitialized memory */
-#ifdef CONFIG_KMEMCHECK
-# define SLAB_NOTRACK  0x0100UL
-#else
-# define SLAB_NOTRACK  0xUL
-#endif
 #ifdef CONFIG_FAILSLAB
 # define SLAB_FAILSLAB 0x0200UL/* Fault injection mark */
 #else
diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h
index fec6291a6703..937d5d54d1b9 100644
--- a/include/trace/events/mmflags.h
+++ b/include/trace/events/mmflags.h
@@ -45,7 +45,6 @@
{(unsigned long)__GFP_RECLAIMABLE,  "__GFP_RECLAIMABLE"},   \
{(unsigned long)__GFP_MOVABLE,  "__GFP_MOVABLE"},   \
{(unsigned long)__GFP_ACCOUNT,  "__GFP_ACCOUNT"},   \
-   {(unsigned long)__GFP_NOTRACK,  "__GFP_NOTRACK"},   \
{(unsigned long)__GFP_WRITE,"__GFP_WRITE"}, \
{(unsigned long)__GFP_RECLAIM,  "__GFP_RECLAIM"},   \
{(unsigned long)__GFP_DIRECT_RECLAIM,   "__GFP_DIRECT_RECLAIM"},\
diff --git a/mm/slub.c b/mm/slub.c
index a3ccf106fc0b..ea182bbd52b6 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -5631,8 +5631,6 @@ static char *create_unique_id(struct kmem_cache *s)
*p++ = 'a';
if (s->flags & SLAB_CONSISTENCY_CHECKS)
*p++ = 'F';
-   if (!(s->flags & SLAB_NOTRACK))
-   *p++ = 't';
if (s->flags & SLAB_ACCOUNT)

[PATCH v2 0/4] kmemcheck: kill kmemcheck

2017-10-06 Thread Levin, Alexander (Sasha Levin)
2 Years ago I proposed to kill kmemcheck:

> As discussed on LSF/MM, kill kmemcheck.
>
> KASan is a replacement that is able to work without the limitation of
> kmemcheck (single CPU, slow). KASan is already upstream.
>
> We are also not aware of any users of kmemcheck (or users who don't consider
> KASan as a suitable replacement).

The only objection was that since KASAN wasn't supported by all GCC
versions provided by distros at that time we should hold off for 2
years, and try again.

Now that 2 years have passed, and all distros provide gcc that supports
KASAN, kill kmemcheck again for the very same reasons.


Changes for v2:
 - Break patch out.


Sasha Levin (4):
  kmemcheck: remove annotations
  kmemcheck: stop using GFP_NOTRACK and SLAB_NOTRACK
  kmemcheck: rip it out
  kmemcheck: remove whats left of NOTRACK flags

 Documentation/admin-guide/kernel-parameters.txt |   7 -
 Documentation/dev-tools/index.rst   |   1 -
 Documentation/dev-tools/kmemcheck.rst   | 733 
 MAINTAINERS |  10 -
 arch/arm/include/asm/dma-iommu.h|   1 -
 arch/arm/include/asm/pgalloc.h  |   2 +-
 arch/arm64/include/asm/pgalloc.h|   2 +-
 arch/openrisc/include/asm/dma-mapping.h |   1 -
 arch/powerpc/include/asm/pgalloc.h  |   2 +-
 arch/sh/kernel/dwarf.c  |   4 +-
 arch/sh/kernel/process.c|   2 +-
 arch/sparc/mm/init_64.c |   4 +-
 arch/unicore32/include/asm/pgalloc.h|   2 +-
 arch/x86/Kconfig|   3 +-
 arch/x86/Makefile   |   5 -
 arch/x86/include/asm/dma-mapping.h  |   1 -
 arch/x86/include/asm/kmemcheck.h|  42 --
 arch/x86/include/asm/pgtable.h  |   5 -
 arch/x86/include/asm/pgtable_types.h|  13 -
 arch/x86/include/asm/string_32.h|   9 -
 arch/x86/include/asm/string_64.h|   8 -
 arch/x86/include/asm/xor.h  |   5 +-
 arch/x86/kernel/cpu/intel.c |  15 -
 arch/x86/kernel/espfix_64.c |   2 +-
 arch/x86/kernel/traps.c |   5 -
 arch/x86/mm/Makefile|   2 -
 arch/x86/mm/fault.c |   6 -
 arch/x86/mm/init.c  |   8 +-
 arch/x86/mm/init_64.c   |   2 +-
 arch/x86/mm/kmemcheck/Makefile  |   1 -
 arch/x86/mm/kmemcheck/error.c   | 227 
 arch/x86/mm/kmemcheck/error.h   |  15 -
 arch/x86/mm/kmemcheck/kmemcheck.c   | 658 -
 arch/x86/mm/kmemcheck/opcode.c  | 106 
 arch/x86/mm/kmemcheck/opcode.h  |   9 -
 arch/x86/mm/kmemcheck/pte.c |  22 -
 arch/x86/mm/kmemcheck/pte.h |  10 -
 arch/x86/mm/kmemcheck/selftest.c|  70 ---
 arch/x86/mm/kmemcheck/selftest.h|   6 -
 arch/x86/mm/kmemcheck/shadow.c  | 173 --
 arch/x86/mm/kmemcheck/shadow.h  |  18 -
 arch/x86/mm/pageattr.c  |  10 +-
 arch/x86/mm/pgtable.c   |   2 +-
 arch/x86/platform/efi/efi_64.c  |   2 +-
 crypto/xor.c|   7 +-
 drivers/char/random.c   |   1 -
 drivers/misc/c2port/core.c  |   2 -
 fs/dcache.c |   2 -
 include/linux/c2port.h  |   4 -
 include/linux/dma-mapping.h |   4 -
 include/linux/filter.h  |   2 -
 include/linux/gfp.h |   9 -
 include/linux/interrupt.h   |  15 -
 include/linux/kmemcheck.h   | 171 --
 include/linux/mm_types.h|   8 -
 include/linux/net.h |   3 -
 include/linux/ring_buffer.h |   3 -
 include/linux/skbuff.h  |   3 -
 include/linux/slab.h|   6 -
 include/linux/thread_info.h |   5 +-
 include/net/inet_sock.h |   3 -
 include/net/inet_timewait_sock.h|   4 -
 include/net/sock.h  |   3 -
 include/trace/events/mmflags.h  |   1 -
 init/do_mounts.c|   3 +-
 init/main.c |   1 -
 kernel/bpf/core.c   |   6 -
 kernel/fork.c   |  12 +-
 kernel/locking/lockdep.c|   3 -
 kernel/signal.c |   3 +-
 kernel/softirq.c|  10 -
 kernel/sysctl.c  

[PATCH v2 4/4] kmemcheck: remove whats left of NOTRACK flags

2017-10-06 Thread Levin, Alexander (Sasha Levin)
Now that kmemcheck is gone, we don't need the NOTRACK flags.

Signed-off-by: Sasha Levin 
---
 arch/x86/include/asm/pgtable.h   |  5 -
 arch/x86/include/asm/pgtable_types.h | 13 -
 include/linux/gfp.h  |  9 -
 include/linux/slab.h |  6 --
 include/trace/events/mmflags.h   |  1 -
 mm/slub.c|  2 --
 tools/perf/builtin-kmem.c|  1 -
 7 files changed, 37 deletions(-)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index b714934512b3..d110e38893d1 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -666,11 +666,6 @@ static inline bool pte_accessible(struct mm_struct *mm, 
pte_t a)
return false;
 }
 
-static inline int pte_hidden(pte_t pte)
-{
-   return pte_flags(pte) & _PAGE_HIDDEN;
-}
-
 static inline int pmd_present(pmd_t pmd)
 {
/*
diff --git a/arch/x86/include/asm/pgtable_types.h 
b/arch/x86/include/asm/pgtable_types.h
index f1492473f10e..27e230dec7a4 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -31,7 +31,6 @@
 
 #define _PAGE_BIT_SPECIAL  _PAGE_BIT_SOFTW1
 #define _PAGE_BIT_CPA_TEST _PAGE_BIT_SOFTW1
-#define _PAGE_BIT_HIDDEN   _PAGE_BIT_SOFTW3 /* hidden by kmemcheck */
 #define _PAGE_BIT_SOFT_DIRTY   _PAGE_BIT_SOFTW3 /* software dirty tracking */
 #define _PAGE_BIT_DEVMAP   _PAGE_BIT_SOFTW4
 
@@ -78,18 +77,6 @@
 #define _PAGE_KNL_ERRATUM_MASK 0
 #endif
 
-#ifdef CONFIG_KMEMCHECK
-#define _PAGE_HIDDEN   (_AT(pteval_t, 1) << _PAGE_BIT_HIDDEN)
-#else
-#define _PAGE_HIDDEN   (_AT(pteval_t, 0))
-#endif
-
-/*
- * The same hidden bit is used by kmemcheck, but since kmemcheck
- * works on kernel pages while soft-dirty engine on user space,
- * they do not conflict with each other.
- */
-
 #ifdef CONFIG_MEM_SOFT_DIRTY
 #define _PAGE_SOFT_DIRTY   (_AT(pteval_t, 1) << _PAGE_BIT_SOFT_DIRTY)
 #else
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index f780718b7391..3427fb8d936a 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -36,7 +36,6 @@ struct vm_area_struct;
 #define ___GFP_THISNODE0x4u
 #define ___GFP_ATOMIC  0x8u
 #define ___GFP_ACCOUNT 0x10u
-#define ___GFP_NOTRACK 0x20u
 #define ___GFP_DIRECT_RECLAIM  0x40u
 #define ___GFP_WRITE   0x80u
 #define ___GFP_KSWAPD_RECLAIM  0x100u
@@ -200,19 +199,11 @@ struct vm_area_struct;
  * __GFP_COMP address compound page metadata.
  *
  * __GFP_ZERO returns a zeroed page on success.
- *
- * __GFP_NOTRACK avoids tracking with kmemcheck.
- *
- * __GFP_NOTRACK_FALSE_POSITIVE is an alias of __GFP_NOTRACK. It's a means of
- *   distinguishing in the source between false positives and allocations that
- *   cannot be supported (e.g. page tables).
  */
 #define __GFP_COLD ((__force gfp_t)___GFP_COLD)
 #define __GFP_NOWARN   ((__force gfp_t)___GFP_NOWARN)
 #define __GFP_COMP ((__force gfp_t)___GFP_COMP)
 #define __GFP_ZERO ((__force gfp_t)___GFP_ZERO)
-#define __GFP_NOTRACK  ((__force gfp_t)___GFP_NOTRACK)
-#define __GFP_NOTRACK_FALSE_POSITIVE (__GFP_NOTRACK)
 
 /* Disable lockdep for GFP context tracking */
 #define __GFP_NOLOCKDEP ((__force gfp_t)___GFP_NOLOCKDEP)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 41473df6dfb0..f35c640687a0 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -77,12 +77,6 @@
 
 #define SLAB_NOLEAKTRACE   0x0080UL/* Avoid kmemleak tracing */
 
-/* Don't track use of uninitialized memory */
-#ifdef CONFIG_KMEMCHECK
-# define SLAB_NOTRACK  0x0100UL
-#else
-# define SLAB_NOTRACK  0xUL
-#endif
 #ifdef CONFIG_FAILSLAB
 # define SLAB_FAILSLAB 0x0200UL/* Fault injection mark */
 #else
diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h
index fec6291a6703..937d5d54d1b9 100644
--- a/include/trace/events/mmflags.h
+++ b/include/trace/events/mmflags.h
@@ -45,7 +45,6 @@
{(unsigned long)__GFP_RECLAIMABLE,  "__GFP_RECLAIMABLE"},   \
{(unsigned long)__GFP_MOVABLE,  "__GFP_MOVABLE"},   \
{(unsigned long)__GFP_ACCOUNT,  "__GFP_ACCOUNT"},   \
-   {(unsigned long)__GFP_NOTRACK,  "__GFP_NOTRACK"},   \
{(unsigned long)__GFP_WRITE,"__GFP_WRITE"}, \
{(unsigned long)__GFP_RECLAIM,  "__GFP_RECLAIM"},   \
{(unsigned long)__GFP_DIRECT_RECLAIM,   "__GFP_DIRECT_RECLAIM"},\
diff --git a/mm/slub.c b/mm/slub.c
index a3ccf106fc0b..ea182bbd52b6 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -5631,8 +5631,6 @@ static char *create_unique_id(struct kmem_cache *s)
*p++ = 'a';
if (s->flags & SLAB_CONSISTENCY_CHECKS)
*p++ = 'F';
-   if (!(s->flags & SLAB_NOTRACK))
-   *p++ = 't';
if (s->flags & SLAB_ACCOUNT)
*p++ = 'A';

[PATCH v2 0/4] kmemcheck: kill kmemcheck

2017-10-06 Thread Levin, Alexander (Sasha Levin)
2 Years ago I proposed to kill kmemcheck:

> As discussed on LSF/MM, kill kmemcheck.
>
> KASan is a replacement that is able to work without the limitation of
> kmemcheck (single CPU, slow). KASan is already upstream.
>
> We are also not aware of any users of kmemcheck (or users who don't consider
> KASan as a suitable replacement).

The only objection was that since KASAN wasn't supported by all GCC
versions provided by distros at that time we should hold off for 2
years, and try again.

Now that 2 years have passed, and all distros provide gcc that supports
KASAN, kill kmemcheck again for the very same reasons.


Changes for v2:
 - Break patch out.


Sasha Levin (4):
  kmemcheck: remove annotations
  kmemcheck: stop using GFP_NOTRACK and SLAB_NOTRACK
  kmemcheck: rip it out
  kmemcheck: remove whats left of NOTRACK flags

 Documentation/admin-guide/kernel-parameters.txt |   7 -
 Documentation/dev-tools/index.rst   |   1 -
 Documentation/dev-tools/kmemcheck.rst   | 733 
 MAINTAINERS |  10 -
 arch/arm/include/asm/dma-iommu.h|   1 -
 arch/arm/include/asm/pgalloc.h  |   2 +-
 arch/arm64/include/asm/pgalloc.h|   2 +-
 arch/openrisc/include/asm/dma-mapping.h |   1 -
 arch/powerpc/include/asm/pgalloc.h  |   2 +-
 arch/sh/kernel/dwarf.c  |   4 +-
 arch/sh/kernel/process.c|   2 +-
 arch/sparc/mm/init_64.c |   4 +-
 arch/unicore32/include/asm/pgalloc.h|   2 +-
 arch/x86/Kconfig|   3 +-
 arch/x86/Makefile   |   5 -
 arch/x86/include/asm/dma-mapping.h  |   1 -
 arch/x86/include/asm/kmemcheck.h|  42 --
 arch/x86/include/asm/pgtable.h  |   5 -
 arch/x86/include/asm/pgtable_types.h|  13 -
 arch/x86/include/asm/string_32.h|   9 -
 arch/x86/include/asm/string_64.h|   8 -
 arch/x86/include/asm/xor.h  |   5 +-
 arch/x86/kernel/cpu/intel.c |  15 -
 arch/x86/kernel/espfix_64.c |   2 +-
 arch/x86/kernel/traps.c |   5 -
 arch/x86/mm/Makefile|   2 -
 arch/x86/mm/fault.c |   6 -
 arch/x86/mm/init.c  |   8 +-
 arch/x86/mm/init_64.c   |   2 +-
 arch/x86/mm/kmemcheck/Makefile  |   1 -
 arch/x86/mm/kmemcheck/error.c   | 227 
 arch/x86/mm/kmemcheck/error.h   |  15 -
 arch/x86/mm/kmemcheck/kmemcheck.c   | 658 -
 arch/x86/mm/kmemcheck/opcode.c  | 106 
 arch/x86/mm/kmemcheck/opcode.h  |   9 -
 arch/x86/mm/kmemcheck/pte.c |  22 -
 arch/x86/mm/kmemcheck/pte.h |  10 -
 arch/x86/mm/kmemcheck/selftest.c|  70 ---
 arch/x86/mm/kmemcheck/selftest.h|   6 -
 arch/x86/mm/kmemcheck/shadow.c  | 173 --
 arch/x86/mm/kmemcheck/shadow.h  |  18 -
 arch/x86/mm/pageattr.c  |  10 +-
 arch/x86/mm/pgtable.c   |   2 +-
 arch/x86/platform/efi/efi_64.c  |   2 +-
 crypto/xor.c|   7 +-
 drivers/char/random.c   |   1 -
 drivers/misc/c2port/core.c  |   2 -
 fs/dcache.c |   2 -
 include/linux/c2port.h  |   4 -
 include/linux/dma-mapping.h |   4 -
 include/linux/filter.h  |   2 -
 include/linux/gfp.h |   9 -
 include/linux/interrupt.h   |  15 -
 include/linux/kmemcheck.h   | 171 --
 include/linux/mm_types.h|   8 -
 include/linux/net.h |   3 -
 include/linux/ring_buffer.h |   3 -
 include/linux/skbuff.h  |   3 -
 include/linux/slab.h|   6 -
 include/linux/thread_info.h |   5 +-
 include/net/inet_sock.h |   3 -
 include/net/inet_timewait_sock.h|   4 -
 include/net/sock.h  |   3 -
 include/trace/events/mmflags.h  |   1 -
 init/do_mounts.c|   3 +-
 init/main.c |   1 -
 kernel/bpf/core.c   |   6 -
 kernel/fork.c   |  12 +-
 kernel/locking/lockdep.c|   3 -
 kernel/signal.c |   3 +-
 kernel/softirq.c|  10 -
 kernel/sysctl.c  

Re: [PATCH] Userfaultfd: Add description for UFFD_FEATURE_SIGBUS

2017-10-06 Thread Prakash Sangappa

cc: Andrea Arcangeli


On 10/6/17 7:52 PM, Prakash Sangappa wrote:

Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should
be available in Linux 4.14 release. This patch is for the manpage
changes documenting this API.

Documents the following commit:

commit 2d6d6f5a09a96cc1fec7ed992b825e05f64cb50e
Author: Prakash Sangappa 
Date: Wed Sep 6 16:23:39 2017 -0700

 mm: userfaultfd: add feature to request for a signal delivery

Signed-off-by: Prakash Sangappa 
---
  man2/ioctl_userfaultfd.2 |  9 +
  man2/userfaultfd.2   | 17 +
  2 files changed, 26 insertions(+)

diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2
index 60fd29b..cfc65ae 100644
--- a/man2/ioctl_userfaultfd.2
+++ b/man2/ioctl_userfaultfd.2
@@ -196,6 +196,15 @@ with the
  flag set,
  .BR memfd_create (2),
  and so on.
+.TP
+.B UFFD_FEATURE_SIGBUS
+Since Linux 4.14, If this feature bit is set, no page-fault events(
+.B UFFD_EVENT_PAGEFAULT
+) will be delivered, instead a
+.B SIGBUS
+signal will be sent to the faulting process. Applications using this
+feature will not require the use of a userfaultfd monitor for handling
+page-fault events.
  .IP
  The returned
  .I ioctls
diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2
index 1741ee3..a033742 100644
--- a/man2/userfaultfd.2
+++ b/man2/userfaultfd.2
@@ -172,6 +172,23 @@ or
  .BR ioctl (2)
  operations to resolve the page fault.
  .PP
+Starting from Linux 4.14, if application sets
+.B UFFD_FEATURE_SIGBUS
+feature bit using
+.B UFFDIO_API
+.BR ioctl (2)
+, no page fault notification will be forwarded to
+the user-space, instead a
+.B SIGBUS
+signal is delivered to the faulting process. With this feature,
+userfaultfd can be used for robustness purpose to simply catch
+any access to areas within the registered address range that do not
+have pages allocated, without having to deal with page-fault events.
+No userfaultd monitor will be required for handling page faults. For
+example, this feature can be useful for applications that want to
+prevent the kernel from automatically allocating pages and filling
+holes in sparse files when the hole is accessed thru mapped address.
+.PP
  Details of the various
  .BR ioctl (2)
  operations can be found in




Re: [PATCH] Userfaultfd: Add description for UFFD_FEATURE_SIGBUS

2017-10-06 Thread Prakash Sangappa

cc: Andrea Arcangeli


On 10/6/17 7:52 PM, Prakash Sangappa wrote:

Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should
be available in Linux 4.14 release. This patch is for the manpage
changes documenting this API.

Documents the following commit:

commit 2d6d6f5a09a96cc1fec7ed992b825e05f64cb50e
Author: Prakash Sangappa 
Date: Wed Sep 6 16:23:39 2017 -0700

 mm: userfaultfd: add feature to request for a signal delivery

Signed-off-by: Prakash Sangappa 
---
  man2/ioctl_userfaultfd.2 |  9 +
  man2/userfaultfd.2   | 17 +
  2 files changed, 26 insertions(+)

diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2
index 60fd29b..cfc65ae 100644
--- a/man2/ioctl_userfaultfd.2
+++ b/man2/ioctl_userfaultfd.2
@@ -196,6 +196,15 @@ with the
  flag set,
  .BR memfd_create (2),
  and so on.
+.TP
+.B UFFD_FEATURE_SIGBUS
+Since Linux 4.14, If this feature bit is set, no page-fault events(
+.B UFFD_EVENT_PAGEFAULT
+) will be delivered, instead a
+.B SIGBUS
+signal will be sent to the faulting process. Applications using this
+feature will not require the use of a userfaultfd monitor for handling
+page-fault events.
  .IP
  The returned
  .I ioctls
diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2
index 1741ee3..a033742 100644
--- a/man2/userfaultfd.2
+++ b/man2/userfaultfd.2
@@ -172,6 +172,23 @@ or
  .BR ioctl (2)
  operations to resolve the page fault.
  .PP
+Starting from Linux 4.14, if application sets
+.B UFFD_FEATURE_SIGBUS
+feature bit using
+.B UFFDIO_API
+.BR ioctl (2)
+, no page fault notification will be forwarded to
+the user-space, instead a
+.B SIGBUS
+signal is delivered to the faulting process. With this feature,
+userfaultfd can be used for robustness purpose to simply catch
+any access to areas within the registered address range that do not
+have pages allocated, without having to deal with page-fault events.
+No userfaultd monitor will be required for handling page faults. For
+example, this feature can be useful for applications that want to
+prevent the kernel from automatically allocating pages and filling
+holes in sparse files when the hole is accessed thru mapped address.
+.PP
  Details of the various
  .BR ioctl (2)
  operations can be found in




[PATCH] Userfaultfd: Add description for UFFD_FEATURE_SIGBUS

2017-10-06 Thread Prakash Sangappa
Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should
be available in Linux 4.14 release. This patch is for the manpage
changes documenting this API.

Documents the following commit:

commit 2d6d6f5a09a96cc1fec7ed992b825e05f64cb50e
Author: Prakash Sangappa 
Date: Wed Sep 6 16:23:39 2017 -0700

mm: userfaultfd: add feature to request for a signal delivery

Signed-off-by: Prakash Sangappa 
---
 man2/ioctl_userfaultfd.2 |  9 +
 man2/userfaultfd.2   | 17 +
 2 files changed, 26 insertions(+)

diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2
index 60fd29b..cfc65ae 100644
--- a/man2/ioctl_userfaultfd.2
+++ b/man2/ioctl_userfaultfd.2
@@ -196,6 +196,15 @@ with the
 flag set,
 .BR memfd_create (2),
 and so on.
+.TP
+.B UFFD_FEATURE_SIGBUS
+Since Linux 4.14, If this feature bit is set, no page-fault events(
+.B UFFD_EVENT_PAGEFAULT
+) will be delivered, instead a
+.B SIGBUS
+signal will be sent to the faulting process. Applications using this
+feature will not require the use of a userfaultfd monitor for handling
+page-fault events.
 .IP
 The returned
 .I ioctls
diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2
index 1741ee3..a033742 100644
--- a/man2/userfaultfd.2
+++ b/man2/userfaultfd.2
@@ -172,6 +172,23 @@ or
 .BR ioctl (2)
 operations to resolve the page fault.
 .PP
+Starting from Linux 4.14, if application sets
+.B UFFD_FEATURE_SIGBUS
+feature bit using
+.B UFFDIO_API
+.BR ioctl (2)
+, no page fault notification will be forwarded to
+the user-space, instead a
+.B SIGBUS
+signal is delivered to the faulting process. With this feature,
+userfaultfd can be used for robustness purpose to simply catch
+any access to areas within the registered address range that do not
+have pages allocated, without having to deal with page-fault events.
+No userfaultd monitor will be required for handling page faults. For
+example, this feature can be useful for applications that want to
+prevent the kernel from automatically allocating pages and filling
+holes in sparse files when the hole is accessed thru mapped address.
+.PP
 Details of the various
 .BR ioctl (2)
 operations can be found in
-- 
2.7.4



[PATCH] Userfaultfd: Add description for UFFD_FEATURE_SIGBUS

2017-10-06 Thread Prakash Sangappa
Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should
be available in Linux 4.14 release. This patch is for the manpage
changes documenting this API.

Documents the following commit:

commit 2d6d6f5a09a96cc1fec7ed992b825e05f64cb50e
Author: Prakash Sangappa 
Date: Wed Sep 6 16:23:39 2017 -0700

mm: userfaultfd: add feature to request for a signal delivery

Signed-off-by: Prakash Sangappa 
---
 man2/ioctl_userfaultfd.2 |  9 +
 man2/userfaultfd.2   | 17 +
 2 files changed, 26 insertions(+)

diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2
index 60fd29b..cfc65ae 100644
--- a/man2/ioctl_userfaultfd.2
+++ b/man2/ioctl_userfaultfd.2
@@ -196,6 +196,15 @@ with the
 flag set,
 .BR memfd_create (2),
 and so on.
+.TP
+.B UFFD_FEATURE_SIGBUS
+Since Linux 4.14, If this feature bit is set, no page-fault events(
+.B UFFD_EVENT_PAGEFAULT
+) will be delivered, instead a
+.B SIGBUS
+signal will be sent to the faulting process. Applications using this
+feature will not require the use of a userfaultfd monitor for handling
+page-fault events.
 .IP
 The returned
 .I ioctls
diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2
index 1741ee3..a033742 100644
--- a/man2/userfaultfd.2
+++ b/man2/userfaultfd.2
@@ -172,6 +172,23 @@ or
 .BR ioctl (2)
 operations to resolve the page fault.
 .PP
+Starting from Linux 4.14, if application sets
+.B UFFD_FEATURE_SIGBUS
+feature bit using
+.B UFFDIO_API
+.BR ioctl (2)
+, no page fault notification will be forwarded to
+the user-space, instead a
+.B SIGBUS
+signal is delivered to the faulting process. With this feature,
+userfaultfd can be used for robustness purpose to simply catch
+any access to areas within the registered address range that do not
+have pages allocated, without having to deal with page-fault events.
+No userfaultd monitor will be required for handling page faults. For
+example, this feature can be useful for applications that want to
+prevent the kernel from automatically allocating pages and filling
+holes in sparse files when the hole is accessed thru mapped address.
+.PP
 Details of the various
 .BR ioctl (2)
 operations can be found in
-- 
2.7.4



Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

2017-10-06 Thread Johannes Weiner
On Sat, Oct 07, 2017 at 11:21:26AM +0900, Tetsuo Handa wrote:
> On 2017/10/05 19:36, Tetsuo Handa wrote:
> > I don't want this patch backported. If you want to backport,
> > "s/fatal_signal_pending/tsk_is_oom_victim/" is the safer way.
> 
> If you backport this patch, you will see "complete depletion of memory 
> reserves"
> and "extra OOM kills due to depletion of memory reserves" using below 
> reproducer.
> 
> --
> #include 
> #include 
> #include 
> 
> static char *buffer;
> 
> static int __init test_init(void)
> {
>   set_current_oom_origin();
>   buffer = vmalloc((1UL << 32) - 480 * 1048576);

That's not a reproducer, that's a kernel module. It's not hard to
crash the kernel from within the kernel.


Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

2017-10-06 Thread Johannes Weiner
On Sat, Oct 07, 2017 at 11:21:26AM +0900, Tetsuo Handa wrote:
> On 2017/10/05 19:36, Tetsuo Handa wrote:
> > I don't want this patch backported. If you want to backport,
> > "s/fatal_signal_pending/tsk_is_oom_victim/" is the safer way.
> 
> If you backport this patch, you will see "complete depletion of memory 
> reserves"
> and "extra OOM kills due to depletion of memory reserves" using below 
> reproducer.
> 
> --
> #include 
> #include 
> #include 
> 
> static char *buffer;
> 
> static int __init test_init(void)
> {
>   set_current_oom_origin();
>   buffer = vmalloc((1UL << 32) - 480 * 1048576);

That's not a reproducer, that's a kernel module. It's not hard to
crash the kernel from within the kernel.


[RFC v4 5/8] platform/x86: intel_punit_ipc: Fix resource ioremap warning

2017-10-06 Thread sathyanarayanan . kuppuswamy
From: Kuppuswamy Sathyanarayanan 

For PUNIT device, ISPDRIVER_IPC and GTDDRIVER_IPC resources are
not mandatory. So when PMC IPC driver creates a PUNIT device, if
these resources are not available then it creates dummy resource
entries for these missing resources. But during PUNIT device probe
, doing ioremap on these dummy resources generates following warning
messages.

intel_punit_ipc intel_punit_ipc: can't request region for resource [mem
0x]
intel_punit_ipc intel_punit_ipc: can't request region for resource [mem
0x]
intel_punit_ipc intel_punit_ipc: can't request region for resource [mem
0x]
intel_punit_ipc intel_punit_ipc: can't request region for resource [mem
0x]

This patch fixes this issue by adding extra check for resource size
before performing ioremap operation.

Signed-off-by: Kuppuswamy Sathyanarayanan 

---
 drivers/platform/x86/intel_punit_ipc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/intel_punit_ipc.c 
b/drivers/platform/x86/intel_punit_ipc.c
index a47a41f..b5b8901 100644
--- a/drivers/platform/x86/intel_punit_ipc.c
+++ b/drivers/platform/x86/intel_punit_ipc.c
@@ -252,28 +252,28 @@ static int intel_punit_get_bars(struct platform_device 
*pdev)
 * - GTDRIVER_IPC BASE_IFACE
 */
res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
-   if (res) {
+   if (res && resource_size(res) > 1) {
addr = devm_ioremap_resource(>dev, res);
if (!IS_ERR(addr))
punit_ipcdev->base[ISPDRIVER_IPC][BASE_DATA] = addr;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 3);
-   if (res) {
+   if (res && resource_size(res) > 1) {
addr = devm_ioremap_resource(>dev, res);
if (!IS_ERR(addr))
punit_ipcdev->base[ISPDRIVER_IPC][BASE_IFACE] = addr;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 4);
-   if (res) {
+   if (res && resource_size(res) > 1) {
addr = devm_ioremap_resource(>dev, res);
if (!IS_ERR(addr))
punit_ipcdev->base[GTDRIVER_IPC][BASE_DATA] = addr;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 5);
-   if (res) {
+   if (res && resource_size(res) > 1) {
addr = devm_ioremap_resource(>dev, res);
if (!IS_ERR(addr))
punit_ipcdev->base[GTDRIVER_IPC][BASE_IFACE] = addr;
-- 
2.7.4



[RFC v4 5/8] platform/x86: intel_punit_ipc: Fix resource ioremap warning

2017-10-06 Thread sathyanarayanan . kuppuswamy
From: Kuppuswamy Sathyanarayanan 

For PUNIT device, ISPDRIVER_IPC and GTDDRIVER_IPC resources are
not mandatory. So when PMC IPC driver creates a PUNIT device, if
these resources are not available then it creates dummy resource
entries for these missing resources. But during PUNIT device probe
, doing ioremap on these dummy resources generates following warning
messages.

intel_punit_ipc intel_punit_ipc: can't request region for resource [mem
0x]
intel_punit_ipc intel_punit_ipc: can't request region for resource [mem
0x]
intel_punit_ipc intel_punit_ipc: can't request region for resource [mem
0x]
intel_punit_ipc intel_punit_ipc: can't request region for resource [mem
0x]

This patch fixes this issue by adding extra check for resource size
before performing ioremap operation.

Signed-off-by: Kuppuswamy Sathyanarayanan 

---
 drivers/platform/x86/intel_punit_ipc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/intel_punit_ipc.c 
b/drivers/platform/x86/intel_punit_ipc.c
index a47a41f..b5b8901 100644
--- a/drivers/platform/x86/intel_punit_ipc.c
+++ b/drivers/platform/x86/intel_punit_ipc.c
@@ -252,28 +252,28 @@ static int intel_punit_get_bars(struct platform_device 
*pdev)
 * - GTDRIVER_IPC BASE_IFACE
 */
res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
-   if (res) {
+   if (res && resource_size(res) > 1) {
addr = devm_ioremap_resource(>dev, res);
if (!IS_ERR(addr))
punit_ipcdev->base[ISPDRIVER_IPC][BASE_DATA] = addr;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 3);
-   if (res) {
+   if (res && resource_size(res) > 1) {
addr = devm_ioremap_resource(>dev, res);
if (!IS_ERR(addr))
punit_ipcdev->base[ISPDRIVER_IPC][BASE_IFACE] = addr;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 4);
-   if (res) {
+   if (res && resource_size(res) > 1) {
addr = devm_ioremap_resource(>dev, res);
if (!IS_ERR(addr))
punit_ipcdev->base[GTDRIVER_IPC][BASE_DATA] = addr;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 5);
-   if (res) {
+   if (res && resource_size(res) > 1) {
addr = devm_ioremap_resource(>dev, res);
if (!IS_ERR(addr))
punit_ipcdev->base[GTDRIVER_IPC][BASE_IFACE] = addr;
-- 
2.7.4



  1   2   3   4   5   6   7   8   9   10   >