Re: [PATCH] pci: hotplug: This patch removes unnecessary return statement using spatch tool

[Joe Perches]

On Sat, 2016-12-24 at 13:03 +0530, Rahul Krishnan wrote:
> This patch removes unnecessary return statement using spatch tool
[]
> diff --git a/drivers/pci/hotplug/rpadlpar_core.c 
> b/drivers/pci/hotplug/rpadlpar_core.c
[]
> @@ -463,8 +463,7 @@ int __init rpadlpar_io_init(void)
>   return -EPERM;
>   }
>  
> - rc = dlpar_sysfs_init();
> - return rc;
> + return dlpar_sysfs_init();
>  }
>  
>  void rpadlpar_io_exit(void)

If you are going to submit these types
of patches, please make sure you compile
test them before sending so that you can
look at new warnings.

Now rc is unused and its declaration
should be removed.

Re: [PATCH] pci: hotplug: This patch removes unnecessary return statement using spatch tool

[Joe Perches]

On Sat, 2016-12-24 at 13:03 +0530, Rahul Krishnan wrote:
> This patch removes unnecessary return statement using spatch tool
[]
> diff --git a/drivers/pci/hotplug/rpadlpar_core.c 
> b/drivers/pci/hotplug/rpadlpar_core.c
[]
> @@ -463,8 +463,7 @@ int __init rpadlpar_io_init(void)
>   return -EPERM;
>   }
>  
> - rc = dlpar_sysfs_init();
> - return rc;
> + return dlpar_sysfs_init();
>  }
>  
>  void rpadlpar_io_exit(void)

If you are going to submit these types
of patches, please make sure you compile
test them before sending so that you can
look at new warnings.

Now rc is unused and its declaration
should be removed.

Re: [PATCH] ACPI: Remove misplaced acpi_dma_deconfigure() call in acpi_bind_one()

[Hanjun Guo]

On 2016/12/16 22:43, Lorenzo Pieralisi wrote:
> The acpi_bind_one() error return path can be hit either on physical node
> allocation failure or if the device being configured is already
> associated with an ACPI node and its ACPI companion does not match the
> one acpi_bind_one() is setting it up with. In both cases the error
> return path is executed before DMA is configured for a device therefore
> there is no need to call acpi_dma_deconfigure() on the function error
> return path.
>
> Furthermore, if acpi_bind_one() does configure DMA for a device (ie it
> successfully executes acpi_dma_configure()) acpi_bind_one() always
> completes execution successfully hence there is no need to add an exit
> path to deconfigure the DMA set-up (ie by calling acpi_dma_deconfigure()).
>
> Remove the misplaced acpi_dma_deconfigure() in acpi_bind_one() to
> reinstate its correct error return path behaviour.
>
> Fixes: d760a1baf20e ("ACPI: Implement acpi_dma_configure")
> Signed-off-by: Lorenzo Pieralisi 
> Cc: Hanjun Guo 
> Cc: Sudeep Holla 
> Cc: "Rafael J. Wysocki" 
> ---
>  drivers/acpi/glue.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> index f8d6564..eb709e7 100644
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -250,7 +250,6 @@ int acpi_bind_one(struct device *dev, struct acpi_device 
> *acpi_dev)
>   return 0;
>  
>   err:
> - acpi_dma_deconfigure(dev);
>   ACPI_COMPANION_SET(dev, NULL);
>   put_device(dev);
>   put_device(_dev->dev);

Reviewed-by: Hanjun Guo 

Thanks
Hanjun

Re: [PATCH] ACPI: Remove misplaced acpi_dma_deconfigure() call in acpi_bind_one()

[Hanjun Guo]

On 2016/12/16 22:43, Lorenzo Pieralisi wrote:
> The acpi_bind_one() error return path can be hit either on physical node
> allocation failure or if the device being configured is already
> associated with an ACPI node and its ACPI companion does not match the
> one acpi_bind_one() is setting it up with. In both cases the error
> return path is executed before DMA is configured for a device therefore
> there is no need to call acpi_dma_deconfigure() on the function error
> return path.
>
> Furthermore, if acpi_bind_one() does configure DMA for a device (ie it
> successfully executes acpi_dma_configure()) acpi_bind_one() always
> completes execution successfully hence there is no need to add an exit
> path to deconfigure the DMA set-up (ie by calling acpi_dma_deconfigure()).
>
> Remove the misplaced acpi_dma_deconfigure() in acpi_bind_one() to
> reinstate its correct error return path behaviour.
>
> Fixes: d760a1baf20e ("ACPI: Implement acpi_dma_configure")
> Signed-off-by: Lorenzo Pieralisi 
> Cc: Hanjun Guo 
> Cc: Sudeep Holla 
> Cc: "Rafael J. Wysocki" 
> ---
>  drivers/acpi/glue.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> index f8d6564..eb709e7 100644
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -250,7 +250,6 @@ int acpi_bind_one(struct device *dev, struct acpi_device 
> *acpi_dev)
>   return 0;
>  
>   err:
> - acpi_dma_deconfigure(dev);
>   ACPI_COMPANION_SET(dev, NULL);
>   put_device(dev);
>   put_device(_dev->dev);

Reviewed-by: Hanjun Guo 

Thanks
Hanjun

Re: [PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device

[Hanjun Guo]

Hi Rafael,

Thank you for your comments, when I was demoing your suggestion,
I got a little bit confusions, please see my comments below.

On 2016/12/22 20:57, Rafael J. Wysocki wrote:
> On Thu, Dec 22, 2016 at 6:35 AM, Hanjun Guo  wrote:
>> From: Hanjun Guo 
>>
>> With the platform msi domain created, we can set up the msi domain
>> for a platform device when it's probed.
>>
>> In order to do that, we need to get the domain that the platform
>> device connecting to, so the iort_get_platform_device_domain() is
>> introduced to retrieve the domain from iort.
>>
>> After the domain is retrieved, we need a proper way to set the
>> domain to paltform device, as some platform devices such as an
>> irqchip needs the msi irqdomain to be the interrupt parent domain,
>> we need to get irqdomain before platform device is probed but after
>> the platform device is allocated, so introduce a callback (pre_add_cb)
>> in pdevinfo to prepare firmware related information which is needed
>> for device probe, then set the msi domain in that callback.
>>
>> Signed-off-by: Hanjun Guo 
>> Cc: Marc Zyngier 
>> Cc: Rafael J. Wysocki 
>> Cc: Greg KH 
>> Cc: Lorenzo Pieralisi 
>> Cc: Thomas Gleixner 
>> ---
>>  drivers/acpi/acpi_platform.c| 11 +++
>>  drivers/acpi/arm64/iort.c   | 43 
>> +
>>  drivers/base/platform.c |  3 +++
>>  include/linux/acpi_iort.h   |  3 +++
>>  include/linux/platform_device.h |  3 +++
>>  5 files changed, 63 insertions(+)
>>
>> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
>> index b4c1a6a..5d8d61b4 100644
>> --- a/drivers/acpi/acpi_platform.c
>> +++ b/drivers/acpi/acpi_platform.c
>> @@ -12,6 +12,7 @@
>>   */
>>
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -48,6 +49,15 @@ static void acpi_platform_fill_resource(struct 
>> acpi_device *adev,
>>  }
>>
>>  /**
>> + * acpi_platform_pre_add_cb - callback before platform device is added, to
>> + * prepare firmware related information which is needed for device probe
>> + */
>> +static void acpi_platform_pre_add_cb(struct device *dev)
>> +{
>> +   acpi_configure_pmsi_domain(dev);
>> +}
>> +
>> +/**
>>   * acpi_create_platform_device - Create platform device for ACPI device node
>>   * @adev: ACPI device node to create a platform device for.
>>   * @properties: Optional collection of build-in properties.
>> @@ -109,6 +119,7 @@ struct platform_device 
>> *acpi_create_platform_device(struct acpi_device *adev,
>> pdevinfo.num_res = count;
>> pdevinfo.fwnode = acpi_fwnode_handle(adev);
>> pdevinfo.properties = properties;
>> +   pdevinfo.pre_add_cb = acpi_platform_pre_add_cb;
> Why don't you point that directly to acpi_configure_pmsi_domain()?  It
> doesn't look like the wrapper is necessary at all.

I was thinking that we can add something more in the future
if we need to extend the function of the callback, I can just
use acpi_configure_pmsi_domain() here.

>
> And I'm not sure why the new callback is necessary ->

I was demoing your suggestion but...

>
>> if (acpi_dma_supported(adev))
>> pdevinfo.dma_mask = DMA_BIT_MASK(32);
>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>> index bc68d93..6b72fcb 100644
>> --- a/drivers/acpi/arm64/iort.c
>> +++ b/drivers/acpi/arm64/iort.c
>> @@ -527,6 +527,49 @@ struct irq_domain *iort_get_device_domain(struct device 
>> *dev, u32 req_id)
>> return irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);
>>  }
>>
>> +/**
>> + * iort_get_platform_device_domain() - Find MSI domain related to a
>> + * platform device
>> + * @dev: the dev pointer associated with the platform device
>> + *
>> + * Returns: the MSI domain for this device, NULL otherwise
>> + */
>> +static struct irq_domain *iort_get_platform_device_domain(struct device 
>> *dev)
>> +{
>> +   struct acpi_iort_node *node, *msi_parent;
>> +   struct fwnode_handle *iort_fwnode;
>> +   struct acpi_iort_its_group *its;
>> +
>> +   /* find its associated iort node */
>> +   node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
>> + iort_match_node_callback, dev);
>> +   if (!node)
>> +   return NULL;
>> +
>> +   /* then find its msi parent node */
>> +   msi_parent = iort_node_get_id(node, NULL, IORT_MSI_TYPE, 0);
>> +   if (!msi_parent)
>> +   return NULL;
>> +
>> +   /* Move to ITS specific data */
>> +   its = (struct acpi_iort_its_group *)msi_parent->node_data;
>> +
>> +   iort_fwnode = iort_find_domain_token(its->identifiers[0]);
>> +   if (!iort_fwnode)
>> +   return NULL;
>> +
>> +   return irq_find_matching_fwnode(iort_fwnode, 
>> DOMAIN_BUS_PLATFORM_MSI);
>> +}

Re: [PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device

[Hanjun Guo]

Hi Rafael,

Thank you for your comments, when I was demoing your suggestion,
I got a little bit confusions, please see my comments below.

On 2016/12/22 20:57, Rafael J. Wysocki wrote:
> On Thu, Dec 22, 2016 at 6:35 AM, Hanjun Guo  wrote:
>> From: Hanjun Guo 
>>
>> With the platform msi domain created, we can set up the msi domain
>> for a platform device when it's probed.
>>
>> In order to do that, we need to get the domain that the platform
>> device connecting to, so the iort_get_platform_device_domain() is
>> introduced to retrieve the domain from iort.
>>
>> After the domain is retrieved, we need a proper way to set the
>> domain to paltform device, as some platform devices such as an
>> irqchip needs the msi irqdomain to be the interrupt parent domain,
>> we need to get irqdomain before platform device is probed but after
>> the platform device is allocated, so introduce a callback (pre_add_cb)
>> in pdevinfo to prepare firmware related information which is needed
>> for device probe, then set the msi domain in that callback.
>>
>> Signed-off-by: Hanjun Guo 
>> Cc: Marc Zyngier 
>> Cc: Rafael J. Wysocki 
>> Cc: Greg KH 
>> Cc: Lorenzo Pieralisi 
>> Cc: Thomas Gleixner 
>> ---
>>  drivers/acpi/acpi_platform.c| 11 +++
>>  drivers/acpi/arm64/iort.c   | 43 
>> +
>>  drivers/base/platform.c |  3 +++
>>  include/linux/acpi_iort.h   |  3 +++
>>  include/linux/platform_device.h |  3 +++
>>  5 files changed, 63 insertions(+)
>>
>> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
>> index b4c1a6a..5d8d61b4 100644
>> --- a/drivers/acpi/acpi_platform.c
>> +++ b/drivers/acpi/acpi_platform.c
>> @@ -12,6 +12,7 @@
>>   */
>>
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -48,6 +49,15 @@ static void acpi_platform_fill_resource(struct 
>> acpi_device *adev,
>>  }
>>
>>  /**
>> + * acpi_platform_pre_add_cb - callback before platform device is added, to
>> + * prepare firmware related information which is needed for device probe
>> + */
>> +static void acpi_platform_pre_add_cb(struct device *dev)
>> +{
>> +   acpi_configure_pmsi_domain(dev);
>> +}
>> +
>> +/**
>>   * acpi_create_platform_device - Create platform device for ACPI device node
>>   * @adev: ACPI device node to create a platform device for.
>>   * @properties: Optional collection of build-in properties.
>> @@ -109,6 +119,7 @@ struct platform_device 
>> *acpi_create_platform_device(struct acpi_device *adev,
>> pdevinfo.num_res = count;
>> pdevinfo.fwnode = acpi_fwnode_handle(adev);
>> pdevinfo.properties = properties;
>> +   pdevinfo.pre_add_cb = acpi_platform_pre_add_cb;
> Why don't you point that directly to acpi_configure_pmsi_domain()?  It
> doesn't look like the wrapper is necessary at all.

I was thinking that we can add something more in the future
if we need to extend the function of the callback, I can just
use acpi_configure_pmsi_domain() here.

>
> And I'm not sure why the new callback is necessary ->

I was demoing your suggestion but...

>
>> if (acpi_dma_supported(adev))
>> pdevinfo.dma_mask = DMA_BIT_MASK(32);
>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>> index bc68d93..6b72fcb 100644
>> --- a/drivers/acpi/arm64/iort.c
>> +++ b/drivers/acpi/arm64/iort.c
>> @@ -527,6 +527,49 @@ struct irq_domain *iort_get_device_domain(struct device 
>> *dev, u32 req_id)
>> return irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);
>>  }
>>
>> +/**
>> + * iort_get_platform_device_domain() - Find MSI domain related to a
>> + * platform device
>> + * @dev: the dev pointer associated with the platform device
>> + *
>> + * Returns: the MSI domain for this device, NULL otherwise
>> + */
>> +static struct irq_domain *iort_get_platform_device_domain(struct device 
>> *dev)
>> +{
>> +   struct acpi_iort_node *node, *msi_parent;
>> +   struct fwnode_handle *iort_fwnode;
>> +   struct acpi_iort_its_group *its;
>> +
>> +   /* find its associated iort node */
>> +   node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
>> + iort_match_node_callback, dev);
>> +   if (!node)
>> +   return NULL;
>> +
>> +   /* then find its msi parent node */
>> +   msi_parent = iort_node_get_id(node, NULL, IORT_MSI_TYPE, 0);
>> +   if (!msi_parent)
>> +   return NULL;
>> +
>> +   /* Move to ITS specific data */
>> +   its = (struct acpi_iort_its_group *)msi_parent->node_data;
>> +
>> +   iort_fwnode = iort_find_domain_token(its->identifiers[0]);
>> +   if (!iort_fwnode)
>> +   return NULL;
>> +
>> +   return irq_find_matching_fwnode(iort_fwnode, 
>> DOMAIN_BUS_PLATFORM_MSI);
>> +}
>> +
>> +void acpi_configure_pmsi_domain(struct device *dev)
>> +{
>> +   struct irq_domain *msi_domain;
>> +
>> +   msi_domain = iort_get_platform_device_domain(dev);
>> +   

[PATCH] pci: hotplug: This patch removes unnecessary return statement using spatch tool

[Rahul Krishnan]

This patch removes unnecessary return statement using spatch tool

Signed-off-by: Rahul Krishnan 
---
 drivers/pci/hotplug/rpadlpar_core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/pci/hotplug/rpadlpar_core.c 
b/drivers/pci/hotplug/rpadlpar_core.c
index dc67f39..9d0e2e1 100644
--- a/drivers/pci/hotplug/rpadlpar_core.c
+++ b/drivers/pci/hotplug/rpadlpar_core.c
@@ -463,8 +463,7 @@ int __init rpadlpar_io_init(void)
return -EPERM;
}
 
-   rc = dlpar_sysfs_init();
-   return rc;
+   return dlpar_sysfs_init();
 }
 
 void rpadlpar_io_exit(void)
-- 
2.7.4

[PATCH] pci: hotplug: This patch removes unnecessary return statement using spatch tool

[Rahul Krishnan]

This patch removes unnecessary return statement using spatch tool

Signed-off-by: Rahul Krishnan 
---
 drivers/pci/hotplug/rpadlpar_core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/pci/hotplug/rpadlpar_core.c 
b/drivers/pci/hotplug/rpadlpar_core.c
index dc67f39..9d0e2e1 100644
--- a/drivers/pci/hotplug/rpadlpar_core.c
+++ b/drivers/pci/hotplug/rpadlpar_core.c
@@ -463,8 +463,7 @@ int __init rpadlpar_io_init(void)
return -EPERM;
}
 
-   rc = dlpar_sysfs_init();
-   return rc;
+   return dlpar_sysfs_init();
 }
 
 void rpadlpar_io_exit(void)
-- 
2.7.4

Re: [PATCH] serial: 8250: use initializer instead of memset to clear local struct

[Masahiro Yamada]

Hi Greg,


2016-12-23 16:20 GMT+09:00 Greg Kroah-Hartman :
> On Fri, Dec 23, 2016 at 12:21:48PM +0900, Masahiro Yamada wrote:
>> Leave the way of zero-out to the compiler's decision; the compiler
>> may know a more optimized way than calling memset().
>
> But no, it doesn't, it will leave "blank" areas in the structure with
> bad data in it, which is why we do memset.  See the tree-wide fixups we
> made about a year ago for this very issue.  Are you sure none of these
> structures get copied to userspace?

I have to admit no security consideration was in my mind.

If we talk about the particular case of struct uart_8250_port,
this structure is allocated in the stack temporarily,
then serial8250_register_8250_port() copies its members to another
structure one by one.  So no "blank" area is exposed to the user-space,
I think.

Having said that, we have no good reason to take a risk for this.

So, please feel free to discard this patch.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] serial: 8250: use initializer instead of memset to clear local struct

[Masahiro Yamada]

Hi Greg,


2016-12-23 16:20 GMT+09:00 Greg Kroah-Hartman :
> On Fri, Dec 23, 2016 at 12:21:48PM +0900, Masahiro Yamada wrote:
>> Leave the way of zero-out to the compiler's decision; the compiler
>> may know a more optimized way than calling memset().
>
> But no, it doesn't, it will leave "blank" areas in the structure with
> bad data in it, which is why we do memset.  See the tree-wide fixups we
> made about a year ago for this very issue.  Are you sure none of these
> structures get copied to userspace?

I have to admit no security consideration was in my mind.

If we talk about the particular case of struct uart_8250_port,
this structure is allocated in the stack temporarily,
then serial8250_register_8250_port() copies its members to another
structure one by one.  So no "blank" area is exposed to the user-space,
I think.

Having said that, we have no good reason to take a risk for this.

So, please feel free to discard this patch.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] find_bit: Micro-optimise find_next_*_bit

[Yury Norov]

Hi Mattew,

On Fri, Dec 23, 2016 at 09:20:03AM -0800, Matthew Wilcox wrote:
> From: Matthew Wilcox 
> 
> This saves 20 bytes on my x86-64 build, mostly due to alignment
> considerations ... I think it actually saves about five bytes of
> instructions.  There's really two parts to this commit.  First, the
> first half of the test: (!nbits || start >= nbits) is trivially a subset
> of the second half, since nbits and start are both unsigned.

Yes... It's obvious... when you point it out.

ARM64 GCC compiler didn't notice it as well as me:

37 0070 :
38   70:   eb1f003fcmp x1, xzr
39   74:   fa421020ccmpx1, x2, #0x0, ne
40   78:   5488b.hi88 
41   7c:   aa0103e0mov x0, x1
42   80:   d65f03c0ret
43   84:   d503201fnop
44   88:   a9bf7bfdstp x29, x30, [sp,#-16]!
45   8c:   910003fdmov x29, sp
46   90:   d283mov x3, #0x0 // #0
47   94:   97dbbl  0 <_find_next_bit.part.0>
48   98:   a8c17bfdldp x29, x30, [sp],#16
49   9c:   d65f03c0ret

> Second,
> while looking at the disassembly, I noticed that GCC was predicting the
> branch taken.  Since this is a failure case, it's clearly the less likely
> of the two branches, so add an unlikely() to override GCC's heuristics.
> 
> Signed-off-by: Matthew Wilcox 
> ---
>  lib/find_bit.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/find_bit.c b/lib/find_bit.c
> index 18072ea9c20e..7d4a681d625f 100644
> --- a/lib/find_bit.c
> +++ b/lib/find_bit.c
> @@ -33,7 +33,7 @@ static unsigned long _find_next_bit(const unsigned long 
> *addr,
>  {
>   unsigned long tmp;
>  
> - if (!nbits || start >= nbits)
> + if (unlikely(start >= nbits))
>   return nbits;
>  
>   tmp = addr[start / BITS_PER_LONG] ^ invert;
> -- 
> 2.11.0


There's also _find_next_bit_le() with same code. I think it should be
also patched.

Acked-by: Yury Norov 

Re: [PATCH] find_bit: Micro-optimise find_next_*_bit

[Yury Norov]

Hi Mattew,

On Fri, Dec 23, 2016 at 09:20:03AM -0800, Matthew Wilcox wrote:
> From: Matthew Wilcox 
> 
> This saves 20 bytes on my x86-64 build, mostly due to alignment
> considerations ... I think it actually saves about five bytes of
> instructions.  There's really two parts to this commit.  First, the
> first half of the test: (!nbits || start >= nbits) is trivially a subset
> of the second half, since nbits and start are both unsigned.

Yes... It's obvious... when you point it out.

ARM64 GCC compiler didn't notice it as well as me:

37 0070 :
38   70:   eb1f003fcmp x1, xzr
39   74:   fa421020ccmpx1, x2, #0x0, ne
40   78:   5488b.hi88 
41   7c:   aa0103e0mov x0, x1
42   80:   d65f03c0ret
43   84:   d503201fnop
44   88:   a9bf7bfdstp x29, x30, [sp,#-16]!
45   8c:   910003fdmov x29, sp
46   90:   d283mov x3, #0x0 // #0
47   94:   97dbbl  0 <_find_next_bit.part.0>
48   98:   a8c17bfdldp x29, x30, [sp],#16
49   9c:   d65f03c0ret

> Second,
> while looking at the disassembly, I noticed that GCC was predicting the
> branch taken.  Since this is a failure case, it's clearly the less likely
> of the two branches, so add an unlikely() to override GCC's heuristics.
> 
> Signed-off-by: Matthew Wilcox 
> ---
>  lib/find_bit.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/find_bit.c b/lib/find_bit.c
> index 18072ea9c20e..7d4a681d625f 100644
> --- a/lib/find_bit.c
> +++ b/lib/find_bit.c
> @@ -33,7 +33,7 @@ static unsigned long _find_next_bit(const unsigned long 
> *addr,
>  {
>   unsigned long tmp;
>  
> - if (!nbits || start >= nbits)
> + if (unlikely(start >= nbits))
>   return nbits;
>  
>   tmp = addr[start / BITS_PER_LONG] ^ invert;
> -- 
> 2.11.0


There's also _find_next_bit_le() with same code. I think it should be
also patched.

Acked-by: Yury Norov 

Re: [PATCH] tools build: replace $(CC) -E with $(CPP) for pre-processing

[Masahiro Yamada]

Hi Jiri,


2016-12-23 19:59 GMT+09:00 Jiri Olsa :
> On Fri, Dec 23, 2016 at 01:46:42PM +0900, Masahiro Yamada wrote:
>> The top-level Makefile defines:
>>
>>   CPP = $(CC) -E
>
> hum, so that'd work for running from top level, but I guess
> it fails for compiling from other places..? like tools/perf


I thought users are supposed to build tools from the top-level, but
seems it is not necessarily true
according to your statement.

I am not quite sure how CC, AS, etc. are set-up, then.
Perhaps, relying on Make-builtin variables?

$ make --print-data-base | grep CPP

showed me the default of CPP is

CPP = $(CC) -E

I guess you are more familiar to the tools-build area,
so I follow your decision.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] tools build: replace $(CC) -E with $(CPP) for pre-processing

[Masahiro Yamada]

Hi Jiri,


2016-12-23 19:59 GMT+09:00 Jiri Olsa :
> On Fri, Dec 23, 2016 at 01:46:42PM +0900, Masahiro Yamada wrote:
>> The top-level Makefile defines:
>>
>>   CPP = $(CC) -E
>
> hum, so that'd work for running from top level, but I guess
> it fails for compiling from other places..? like tools/perf


I thought users are supposed to build tools from the top-level, but
seems it is not necessarily true
according to your statement.

I am not quite sure how CC, AS, etc. are set-up, then.
Perhaps, relying on Make-builtin variables?

$ make --print-data-base | grep CPP

showed me the default of CPP is

CPP = $(CC) -E

I guess you are more familiar to the tools-build area,
so I follow your decision.


-- 
Best Regards
Masahiro Yamada

Re: Converting DEVICE_ATTR to DEVICE_ATTR_{RO,RW,WO} and changing function names at the same time

[Julia Lawall]

On Fri, 23 Dec 2016, Guenter Roeck wrote:

> Hi Julia,
>
> On Fri, Dec 23, 2016 at 04:54:41PM +0100, Julia Lawall wrote:
> [ ... ]
> >
> > // -
> > @ro@
> > declarer name SENSOR_DEVICE_ATTR, SENSOR_DEVICE_ATTR_2;
> > identifier x,show;
> > @@
> >
> > \(SENSOR_DEVICE_ATTR\|SENSOR_DEVICE_ATTR_2\)
> > (x, \(0444\|S_IRUGO\), show, NULL, ...);
> >
>
> my version of spatch (?) does not like this construct.
>
> $ spatch --version
> spatch version 1.0.6-00036-gb62df17 compiled with OCaml version 4.02.3
> Flags passed to the configure script: --prefix=/usr
> Python scripting support: yes
> Syntax of regular expresssions: PCRE
>
> Is this something new, or am I doing something wrong ?

Something new, sorry.  I think it should be available in the github
version.  If not, the solution is just to split each case like this up
into two rules.

> I played with it myself, and came up with the (less elegant) version
> below. It isn't perfect (it does not handle the function-in-macro case
> well), but it should give us a good comparison. Also, I might just get
> rid of at least some of those macros; they just obfuscate the code anyway.
>
> Thanks,
> Guenter
>
> ---
> @initialize:python@
> @@
>
> import re
>
> // -
> // Easy case
>
> @d@
> declarer name SENSOR_DEVICE_ATTR,SENSOR_DEVICE_ATTR_2;
> identifier x,show,store;
> expression p;
> @@
>
> (
>   SENSOR_DEVICE_ATTR(x,p,show,store,...);
> |
>   SENSOR_DEVICE_ATTR_2(x,p,show,store,...);
> )
>
> @script:python expected@
> show << d.show;
> store << d.store;
> x_show;
> x_store;
> func;
> @@
> coccinelle.func = re.sub('show_|get_|_show|_get|_read', '', show)
> coccinelle.x_show = re.sub('show_|get_|_show|_get|_read', '', show) + "_show"
> coccinelle.x_store = re.sub('show_|get_|_get|_show|_read', '', show) +
"_store"
>
> if show == "NULL":
> coccinelle.x_store = re.sub('store_|set_|_set|_store|_write|_reset', '', 
> store) + "_store"
> coccinelle.func = re.sub('store_|set_|_store|_set|_write|_reset', '', 
> store)

OK, so you solve the incompatability between show and store by jut taking
the show version.  There could be some danger that another call will only
have the same store function and will rename it in a different way.  That
is:

SENSOR_DEVICE_ATTR(x, opt, get_one, set_two, 0)

will rename set_two to one_store, and

SENSOR_DEVICE_ATTR(x, opt, NULL, set_two, 0)

will rename set_two to two_store.

Otherwise, it seems fine.  It is better than my version in that it chooses
the new names all at once.  My version chose the new names for eg the WO
and RW cases after the RO case, so it had to protect against rechanging
names that it had already changed.  I also protect against renaming a name
being used in a DEVICE_ATTR call.  I don't know if that can happen.

You don't actually havce to repeat the declarer name declaration in every
rule.  Once you have specified that once, it is valid forever.  New
versions of Coccinelle allow the redeclaration, butold versions will
break.

julia


> @@
> declarer name SENSOR_DEVICE_ATTR_RO;
> identifier d.x,expected.x_show,expected.func;
> expression e;
> @@
>
> - SENSOR_DEVICE_ATTR(x, \(0444\|S_IRUGO\), x_show, NULL, e);
> + SENSOR_DEVICE_ATTR_RO(x, func, e);
>
> @@
> declarer name SENSOR_DEVICE_ATTR_WO;
> identifier d.x,expected.x_store,expected.func;
> expression e;
> @@
>
> - SENSOR_DEVICE_ATTR(x, \(0200\|S_IWUSR\), NULL, x_store, e);
> + SENSOR_DEVICE_ATTR_WO(x, func, e);
>
> @@
> declarer name SENSOR_DEVICE_ATTR_RW;
> identifier d.x,expected.x_show,expected.x_store,expected.func;
> expression e;
> @@
>
> - SENSOR_DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\|S_IWUSR|S_IRUGO\), x_show, 
> x_store, e);
> + SENSOR_DEVICE_ATTR_RW(x, func, e);
>
> @@
> declarer name SENSOR_DEVICE_ATTR_2_RO;
> identifier d.x,expected.x_show,expected.func;
> expression e1,e2;
> @@
>
> - SENSOR_DEVICE_ATTR_2(x, \(0444\|S_IRUGO\), x_show, NULL, e1, e2);
> + SENSOR_DEVICE_ATTR_2_RO(x, func, e1, e2);
>
> @@
> declarer name SENSOR_DEVICE_ATTR_2_WO;
> identifier d.x,expected.x_store,expected.func;
> expression e1,e2;
> @@
>
> - SENSOR_DEVICE_ATTR_2(x, \(0200\|S_IWUSR\), NULL, x_store, e1, e2);
> + SENSOR_DEVICE_ATTR_2_WO(x, func, e1, e2);
>
> @@
> declarer name SENSOR_DEVICE_ATTR_2_RW;
> identifier d.x,expected.x_show,expected.x_store,expected.func;
> expression e1, e2;
> @@
>
> - SENSOR_DEVICE_ATTR_2(x, \(0644\|S_IRUGO|S_IWUSR\|S_IWUSR|S_IRUGO\), x_show, 
> x_store, e1, e2);
> + SENSOR_DEVICE_ATTR_2_RW(x, func, e1, e2);
>
> // -
> // Other calls
>
> @o@
> declarer name SENSOR_DEVICE_ATTR,SENSOR_DEVICE_ATTR_2;
> identifier d.x,show,store;
> expression list es;
> @@
>
> (
> SENSOR_DEVICE_ATTR(x,\(0444\|S_IRUGO\|0200\|S_IWUSR\|0644\|S_IRUGO|S_IWUSR\|S_IWUSR|S_IRUGO\),show,store,es);
> |
> 

Re: Converting DEVICE_ATTR to DEVICE_ATTR_{RO,RW,WO} and changing function names at the same time

[Julia Lawall]

On Fri, 23 Dec 2016, Guenter Roeck wrote:

> Hi Julia,
>
> On Fri, Dec 23, 2016 at 04:54:41PM +0100, Julia Lawall wrote:
> [ ... ]
> >
> > // -
> > @ro@
> > declarer name SENSOR_DEVICE_ATTR, SENSOR_DEVICE_ATTR_2;
> > identifier x,show;
> > @@
> >
> > \(SENSOR_DEVICE_ATTR\|SENSOR_DEVICE_ATTR_2\)
> > (x, \(0444\|S_IRUGO\), show, NULL, ...);
> >
>
> my version of spatch (?) does not like this construct.
>
> $ spatch --version
> spatch version 1.0.6-00036-gb62df17 compiled with OCaml version 4.02.3
> Flags passed to the configure script: --prefix=/usr
> Python scripting support: yes
> Syntax of regular expresssions: PCRE
>
> Is this something new, or am I doing something wrong ?

Something new, sorry.  I think it should be available in the github
version.  If not, the solution is just to split each case like this up
into two rules.

> I played with it myself, and came up with the (less elegant) version
> below. It isn't perfect (it does not handle the function-in-macro case
> well), but it should give us a good comparison. Also, I might just get
> rid of at least some of those macros; they just obfuscate the code anyway.
>
> Thanks,
> Guenter
>
> ---
> @initialize:python@
> @@
>
> import re
>
> // -
> // Easy case
>
> @d@
> declarer name SENSOR_DEVICE_ATTR,SENSOR_DEVICE_ATTR_2;
> identifier x,show,store;
> expression p;
> @@
>
> (
>   SENSOR_DEVICE_ATTR(x,p,show,store,...);
> |
>   SENSOR_DEVICE_ATTR_2(x,p,show,store,...);
> )
>
> @script:python expected@
> show << d.show;
> store << d.store;
> x_show;
> x_store;
> func;
> @@
> coccinelle.func = re.sub('show_|get_|_show|_get|_read', '', show)
> coccinelle.x_show = re.sub('show_|get_|_show|_get|_read', '', show) + "_show"
> coccinelle.x_store = re.sub('show_|get_|_get|_show|_read', '', show) +
"_store"
>
> if show == "NULL":
> coccinelle.x_store = re.sub('store_|set_|_set|_store|_write|_reset', '', 
> store) + "_store"
> coccinelle.func = re.sub('store_|set_|_store|_set|_write|_reset', '', 
> store)

OK, so you solve the incompatability between show and store by jut taking
the show version.  There could be some danger that another call will only
have the same store function and will rename it in a different way.  That
is:

SENSOR_DEVICE_ATTR(x, opt, get_one, set_two, 0)

will rename set_two to one_store, and

SENSOR_DEVICE_ATTR(x, opt, NULL, set_two, 0)

will rename set_two to two_store.

Otherwise, it seems fine.  It is better than my version in that it chooses
the new names all at once.  My version chose the new names for eg the WO
and RW cases after the RO case, so it had to protect against rechanging
names that it had already changed.  I also protect against renaming a name
being used in a DEVICE_ATTR call.  I don't know if that can happen.

You don't actually havce to repeat the declarer name declaration in every
rule.  Once you have specified that once, it is valid forever.  New
versions of Coccinelle allow the redeclaration, butold versions will
break.

julia


> @@
> declarer name SENSOR_DEVICE_ATTR_RO;
> identifier d.x,expected.x_show,expected.func;
> expression e;
> @@
>
> - SENSOR_DEVICE_ATTR(x, \(0444\|S_IRUGO\), x_show, NULL, e);
> + SENSOR_DEVICE_ATTR_RO(x, func, e);
>
> @@
> declarer name SENSOR_DEVICE_ATTR_WO;
> identifier d.x,expected.x_store,expected.func;
> expression e;
> @@
>
> - SENSOR_DEVICE_ATTR(x, \(0200\|S_IWUSR\), NULL, x_store, e);
> + SENSOR_DEVICE_ATTR_WO(x, func, e);
>
> @@
> declarer name SENSOR_DEVICE_ATTR_RW;
> identifier d.x,expected.x_show,expected.x_store,expected.func;
> expression e;
> @@
>
> - SENSOR_DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\|S_IWUSR|S_IRUGO\), x_show, 
> x_store, e);
> + SENSOR_DEVICE_ATTR_RW(x, func, e);
>
> @@
> declarer name SENSOR_DEVICE_ATTR_2_RO;
> identifier d.x,expected.x_show,expected.func;
> expression e1,e2;
> @@
>
> - SENSOR_DEVICE_ATTR_2(x, \(0444\|S_IRUGO\), x_show, NULL, e1, e2);
> + SENSOR_DEVICE_ATTR_2_RO(x, func, e1, e2);
>
> @@
> declarer name SENSOR_DEVICE_ATTR_2_WO;
> identifier d.x,expected.x_store,expected.func;
> expression e1,e2;
> @@
>
> - SENSOR_DEVICE_ATTR_2(x, \(0200\|S_IWUSR\), NULL, x_store, e1, e2);
> + SENSOR_DEVICE_ATTR_2_WO(x, func, e1, e2);
>
> @@
> declarer name SENSOR_DEVICE_ATTR_2_RW;
> identifier d.x,expected.x_show,expected.x_store,expected.func;
> expression e1, e2;
> @@
>
> - SENSOR_DEVICE_ATTR_2(x, \(0644\|S_IRUGO|S_IWUSR\|S_IWUSR|S_IRUGO\), x_show, 
> x_store, e1, e2);
> + SENSOR_DEVICE_ATTR_2_RW(x, func, e1, e2);
>
> // -
> // Other calls
>
> @o@
> declarer name SENSOR_DEVICE_ATTR,SENSOR_DEVICE_ATTR_2;
> identifier d.x,show,store;
> expression list es;
> @@
>
> (
> SENSOR_DEVICE_ATTR(x,\(0444\|S_IRUGO\|0200\|S_IWUSR\|0644\|S_IRUGO|S_IWUSR\|S_IWUSR|S_IRUGO\),show,store,es);
> |
> 

Re: [PATCH v3 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel

[Mark Greer]

On Wed, Dec 21, 2016 at 11:18:34PM -0500, Geoff Lansberry wrote:
> From: Jaret Cantu 
> 
> Repeated polling attempts cause a NULL dereference error to occur.
> This is because the state of the trf7970a is currently reading but
> another request has been made to send a command before it has finished.
> 
> The solution is to properly kill the waiting reading (workqueue)
> before failing on the send.
> 
> Signed-off-by: Geoff Lansberry 
> ---

You've still provided virtually no information on the actual problem(s)
nor justified why you think this is the best solution.  You're adding
code to a section of code that should _never_ be executed so the only
reasonable things I can infer is that there are, at least, two problems:

1) There is a bug causing execution to get into this block of code.

2) Once in this block of code, there is another bug.

You seem to be attempting to fix 2) and completely ignoring 1).
1) is the first bug that needs to be root-caused and fixed.

Also, what exactly is the "NULL dereference error" you mention?
Is this the neard crash you talked about in another thread or is
this a kernel crash?  If it is the kernel crash, please post the
relevant information.  If this is the neard crash - which seems
unlikely - then how can changing a section of kernel code that
shouldn't be executed in the first place fix that?

Mark
--

Re: [PATCH v3 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel

[Mark Greer]

On Wed, Dec 21, 2016 at 11:18:34PM -0500, Geoff Lansberry wrote:
> From: Jaret Cantu 
> 
> Repeated polling attempts cause a NULL dereference error to occur.
> This is because the state of the trf7970a is currently reading but
> another request has been made to send a command before it has finished.
> 
> The solution is to properly kill the waiting reading (workqueue)
> before failing on the send.
> 
> Signed-off-by: Geoff Lansberry 
> ---

You've still provided virtually no information on the actual problem(s)
nor justified why you think this is the best solution.  You're adding
code to a section of code that should _never_ be executed so the only
reasonable things I can infer is that there are, at least, two problems:

1) There is a bug causing execution to get into this block of code.

2) Once in this block of code, there is another bug.

You seem to be attempting to fix 2) and completely ignoring 1).
1) is the first bug that needs to be root-caused and fixed.

Also, what exactly is the "NULL dereference error" you mention?
Is this the neard crash you talked about in another thread or is
this a kernel crash?  If it is the kernel crash, please post the
relevant information.  If this is the neard crash - which seems
unlikely - then how can changing a section of kernel code that
shouldn't be executed in the first place fix that?

Mark
--

[PATCH v2] scsi: bfa: Increase requested firmware version to 3.2.5.1

[Benjamin Poirier]

bna & bfa firmware version 3.2.5.1 was submitted to linux-firmware on
Feb 17 19:10:20 2015 -0500 in 0ab54ff1dc ("linux-firmware: Add QLogic BR
Series Adapter Firmware").

bna was updated to use the newer firmware on Feb 19 16:02:32 2015 -0500 in
3f307c3d70 ("bna: Update the Driver and Firmware Version")

bfa was not updated. I presume this was an oversight but it broke support
for bfa+bna cards such as the following
04:00.0 Fibre Channel [0c04]: Brocade Communications Systems, Inc.
1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
04:00.1 Fibre Channel [0c04]: Brocade Communications Systems, Inc.
1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
04:00.2 Ethernet controller [0200]: Brocade Communications Systems,
Inc. 1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
04:00.3 Ethernet controller [0200]: Brocade Communications Systems,
Inc. 1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)

Currently, if the bfa module is loaded first, bna fails to probe the
respective devices with
[  215.026787] bna: QLogic BR-series 10G Ethernet driver - version: 3.2.25.1
[  215.043707] bna :04:00.2: bar0 mapped to c90001fc, len 262144
[  215.060656] bna :04:00.2: initialization failed err=1
[  215.073893] bna :04:00.3: bar0 mapped to c9000204, len 262144
[  215.090644] bna :04:00.3: initialization failed err=1

Whereas if bna is loaded first, bfa fails with
[  249.592109] QLogic BR-series BFA FC/FCOE SCSI driver - version: 3.2.25.0
[  249.610738] bfa :04:00.0: Running firmware version is incompatible with 
the driver version
[  249.833513] bfa :04:00.0: bfa init failed
[  249.833919] scsi host6: QLogic BR-series FC/FCOE Adapter, hwpath: 
:04:00.0 driver: 3.2.25.0
[  249.841446] bfa :04:00.1: Running firmware version is incompatible with 
the driver version
[  250.045449] bfa :04:00.1: bfa init failed
[  250.045962] scsi host7: QLogic BR-series FC/FCOE Adapter, hwpath: 
:04:00.1 driver: 3.2.25.0

Increase bfa's requested firmware version. Also increase the driver
version.
I only tested that all of the devices probe without error.

Reported-by: Tim Ehlers 
Signed-off-by: Benjamin Poirier 
Acked-by: Rasesh Mody 
---
 drivers/scsi/bfa/bfad.c | 6 +++---
 drivers/scsi/bfa/bfad_drv.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

Changes v1-v2:
Also increase the driver version

diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c
index 9d253cb..e70410b 100644
--- a/drivers/scsi/bfa/bfad.c
+++ b/drivers/scsi/bfa/bfad.c
@@ -64,9 +64,9 @@ int   max_rport_logins = BFA_FCS_MAX_RPORT_LOGINS;
 u32bfi_image_cb_size, bfi_image_ct_size, bfi_image_ct2_size;
 u32*bfi_image_cb, *bfi_image_ct, *bfi_image_ct2;
 
-#define BFAD_FW_FILE_CB"cbfw-3.2.3.0.bin"
-#define BFAD_FW_FILE_CT"ctfw-3.2.3.0.bin"
-#define BFAD_FW_FILE_CT2   "ct2fw-3.2.3.0.bin"
+#define BFAD_FW_FILE_CB"cbfw-3.2.5.1.bin"
+#define BFAD_FW_FILE_CT"ctfw-3.2.5.1.bin"
+#define BFAD_FW_FILE_CT2   "ct2fw-3.2.5.1.bin"
 
 static u32 *bfad_load_fwimg(struct pci_dev *pdev);
 static void bfad_free_fwimg(void);
diff --git a/drivers/scsi/bfa/bfad_drv.h b/drivers/scsi/bfa/bfad_drv.h
index f9e8620..cfcfff4 100644
--- a/drivers/scsi/bfa/bfad_drv.h
+++ b/drivers/scsi/bfa/bfad_drv.h
@@ -58,7 +58,7 @@
 #ifdef BFA_DRIVER_VERSION
 #define BFAD_DRIVER_VERSIONBFA_DRIVER_VERSION
 #else
-#define BFAD_DRIVER_VERSION"3.2.25.0"
+#define BFAD_DRIVER_VERSION"3.2.25.1"
 #endif
 
 #define BFAD_PROTO_NAME FCPI_NAME
-- 
2.10.2

[PATCH v2] scsi: bfa: Increase requested firmware version to 3.2.5.1

[Benjamin Poirier]

bna & bfa firmware version 3.2.5.1 was submitted to linux-firmware on
Feb 17 19:10:20 2015 -0500 in 0ab54ff1dc ("linux-firmware: Add QLogic BR
Series Adapter Firmware").

bna was updated to use the newer firmware on Feb 19 16:02:32 2015 -0500 in
3f307c3d70 ("bna: Update the Driver and Firmware Version")

bfa was not updated. I presume this was an oversight but it broke support
for bfa+bna cards such as the following
04:00.0 Fibre Channel [0c04]: Brocade Communications Systems, Inc.
1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
04:00.1 Fibre Channel [0c04]: Brocade Communications Systems, Inc.
1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
04:00.2 Ethernet controller [0200]: Brocade Communications Systems,
Inc. 1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
04:00.3 Ethernet controller [0200]: Brocade Communications Systems,
Inc. 1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)

Currently, if the bfa module is loaded first, bna fails to probe the
respective devices with
[  215.026787] bna: QLogic BR-series 10G Ethernet driver - version: 3.2.25.1
[  215.043707] bna :04:00.2: bar0 mapped to c90001fc, len 262144
[  215.060656] bna :04:00.2: initialization failed err=1
[  215.073893] bna :04:00.3: bar0 mapped to c9000204, len 262144
[  215.090644] bna :04:00.3: initialization failed err=1

Whereas if bna is loaded first, bfa fails with
[  249.592109] QLogic BR-series BFA FC/FCOE SCSI driver - version: 3.2.25.0
[  249.610738] bfa :04:00.0: Running firmware version is incompatible with 
the driver version
[  249.833513] bfa :04:00.0: bfa init failed
[  249.833919] scsi host6: QLogic BR-series FC/FCOE Adapter, hwpath: 
:04:00.0 driver: 3.2.25.0
[  249.841446] bfa :04:00.1: Running firmware version is incompatible with 
the driver version
[  250.045449] bfa :04:00.1: bfa init failed
[  250.045962] scsi host7: QLogic BR-series FC/FCOE Adapter, hwpath: 
:04:00.1 driver: 3.2.25.0

Increase bfa's requested firmware version. Also increase the driver
version.
I only tested that all of the devices probe without error.

Reported-by: Tim Ehlers 
Signed-off-by: Benjamin Poirier 
Acked-by: Rasesh Mody 
---
 drivers/scsi/bfa/bfad.c | 6 +++---
 drivers/scsi/bfa/bfad_drv.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

Changes v1-v2:
Also increase the driver version

diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c
index 9d253cb..e70410b 100644
--- a/drivers/scsi/bfa/bfad.c
+++ b/drivers/scsi/bfa/bfad.c
@@ -64,9 +64,9 @@ int   max_rport_logins = BFA_FCS_MAX_RPORT_LOGINS;
 u32bfi_image_cb_size, bfi_image_ct_size, bfi_image_ct2_size;
 u32*bfi_image_cb, *bfi_image_ct, *bfi_image_ct2;
 
-#define BFAD_FW_FILE_CB"cbfw-3.2.3.0.bin"
-#define BFAD_FW_FILE_CT"ctfw-3.2.3.0.bin"
-#define BFAD_FW_FILE_CT2   "ct2fw-3.2.3.0.bin"
+#define BFAD_FW_FILE_CB"cbfw-3.2.5.1.bin"
+#define BFAD_FW_FILE_CT"ctfw-3.2.5.1.bin"
+#define BFAD_FW_FILE_CT2   "ct2fw-3.2.5.1.bin"
 
 static u32 *bfad_load_fwimg(struct pci_dev *pdev);
 static void bfad_free_fwimg(void);
diff --git a/drivers/scsi/bfa/bfad_drv.h b/drivers/scsi/bfa/bfad_drv.h
index f9e8620..cfcfff4 100644
--- a/drivers/scsi/bfa/bfad_drv.h
+++ b/drivers/scsi/bfa/bfad_drv.h
@@ -58,7 +58,7 @@
 #ifdef BFA_DRIVER_VERSION
 #define BFAD_DRIVER_VERSIONBFA_DRIVER_VERSION
 #else
-#define BFAD_DRIVER_VERSION"3.2.25.0"
+#define BFAD_DRIVER_VERSION"3.2.25.1"
 #endif
 
 #define BFAD_PROTO_NAME FCPI_NAME
-- 
2.10.2

FOSSASIA'17 Kernel Track: Call for Speakers

[Daniel J Blueman]

Dear Linux Kernel developers,

The FOSSASIA 2017 Kernel Track would like to welcome all interested
speakers to submit abstracts for presentations. You'll have the
opportunity to share your knowledge and discuss with like-minded
individuals, representing a broad range of industries and
technologies.

The topics include, but are not limited to:
- new kernel developments, ideas and limitations
- development process and community
- bringup experience on new platforms or SoCs
- debugging, profiling, tuning tips and experience
- security and vulnerabilities
- new and exciting architectures, features and platforms

There are over 3000 attendees each year and a broad range of other
tracks including the Hardware and Maker track, the Artificial
Intelligence track, the Startup and Business Development track and the
DevOps track.

The deadline for submission has been extended until Jan 20th; for more
details see:
http://blog.fossasia.org/fossasia-summit-2017-singapore-call-for-speakers/

We are looking forward to seeing you at the summit!

Daniel
-- 
Daniel J Blueman

FOSSASIA'17 Kernel Track: Call for Speakers

[Daniel J Blueman]

Dear Linux Kernel developers,

The FOSSASIA 2017 Kernel Track would like to welcome all interested
speakers to submit abstracts for presentations. You'll have the
opportunity to share your knowledge and discuss with like-minded
individuals, representing a broad range of industries and
technologies.

The topics include, but are not limited to:
- new kernel developments, ideas and limitations
- development process and community
- bringup experience on new platforms or SoCs
- debugging, profiling, tuning tips and experience
- security and vulnerabilities
- new and exciting architectures, features and platforms

There are over 3000 attendees each year and a broad range of other
tracks including the Hardware and Maker track, the Artificial
Intelligence track, the Startup and Business Development track and the
DevOps track.

The deadline for submission has been extended until Jan 20th; for more
details see:
http://blog.fossasia.org/fossasia-summit-2017-singapore-call-for-speakers/

We are looking forward to seeing you at the summit!

Daniel
-- 
Daniel J Blueman

Re: [v2 6/7] x86/traps: Fixup general protection faults caused by UMIP

[kbuild test robot]

Hi Ricardo,

[auto build test ERROR on tip/auto-latest]
[also build test ERROR on next-20161223]
[cannot apply to tip/x86/core v4.9]
[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/Ricardo-Neri/x86-enable-User-Mode-Instruction-Prevention/20161224-094338
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from arch/x86/tools/test_get_len.c:27:0:
>> arch/x86/include/asm/insn.h:26:23: fatal error: linux/bug.h: No such file or 
>> directory
#include 
  ^
   compilation terminated.
--
   In file included from tools/include/linux/compiler.h:55:0,
from arch/x86/include/asm/insn.h:25,
from arch/x86/tools/insn_sanity.c:34:
>> tools/include/linux/types.h:28:18: error: conflicting types for 'u64'
typedef uint64_t u64;
 ^~~
   In file included from /usr/include/asm-generic/types.h:6:0,
from /usr/include/x86_64-linux-gnu/asm/types.h:4,
from tools/include/linux/types.h:9,
from tools/include/linux/compiler.h:55,
from arch/x86/include/asm/insn.h:25,
from arch/x86/tools/insn_sanity.c:34:
   include/asm-generic/int-ll64.h:25:28: note: previous declaration of 'u64' 
was here
typedef unsigned long long u64;
   ^~~
   In file included from tools/include/linux/compiler.h:55:0,
from arch/x86/include/asm/insn.h:25,
from arch/x86/tools/insn_sanity.c:34:
>> tools/include/linux/types.h:29:17: error: conflicting types for 's64'
typedef int64_t s64;
^~~
   In file included from /usr/include/asm-generic/types.h:6:0,
from /usr/include/x86_64-linux-gnu/asm/types.h:4,
from tools/include/linux/types.h:9,
from tools/include/linux/compiler.h:55,
from arch/x86/include/asm/insn.h:25,
from arch/x86/tools/insn_sanity.c:34:
   include/asm-generic/int-ll64.h:24:26: note: previous declaration of 's64' 
was here
typedef signed long long s64;
 ^~~
   In file included from tools/include/linux/types.h:4:0,
from tools/include/linux/compiler.h:55,
from arch/x86/include/asm/insn.h:25,
from arch/x86/tools/insn_sanity.c:34:
>> include/linux/stddef.h:10:2: error: expected identifier before numeric 
>> constant
 false = 0,
 ^
   In file included from arch/x86/include/asm/ptrace.h:5:0,
from arch/x86/include/asm/insn.h:28,
from arch/x86/tools/insn_sanity.c:34:
>> arch/x86/include/asm/page_types.h:61:15: error: unknown type name 
>> 'phys_addr_t'
static inline phys_addr_t get_max_mapped(void)
  ^~~
   arch/x86/include/asm/page_types.h: In function 'get_max_mapped':
>> arch/x86/include/asm/page_types.h:63:10: error: 'phys_addr_t' undeclared 
>> (first use in this function)
 return (phys_addr_t)max_pfn_mapped << PAGE_SHIFT;
 ^~~
   arch/x86/include/asm/page_types.h:63:10: note: each undeclared identifier is 
reported only once for each function it appears in
>> arch/x86/include/asm/page_types.h:63:22: error: expected ';' before 
>> 'max_pfn_mapped'
 return (phys_addr_t)max_pfn_mapped << PAGE_SHIFT;
 ^~
   In file included from arch/x86/include/asm/insn.h:28:0,
from arch/x86/tools/insn_sanity.c:34:
   arch/x86/include/asm/ptrace.h: At top level:
>> arch/x86/include/asm/ptrace.h:33:8: error: redefinition of 'struct pt_regs'
struct pt_regs {
   ^~~
   In file included from arch/x86/include/asm/insn.h:26:0,
from arch/x86/tools/insn_sanity.c:34:
   include/linux/bug.h:13:8: note: originally defined here
struct pt_regs;
   ^~~

vim +33 arch/x86/include/asm/ptrace.h

92bc2056 include/asm-x86/ptrace.h  Harvey Harrison 2008-02-08  27   
unsigned long sp;
92bc2056 include/asm-x86/ptrace.h  Harvey Harrison 2008-02-08  28   
unsigned long ss;
65ea5b03 include/asm-x86/ptrace.h  H. Peter Anvin  2008-01-30  29  };
8fc37f2c include/asm-x86/ptrace.h  Thomas Gleixner 2007-10-23  30  
8fc37f2c include/asm-x86/ptrace.h  Thomas Gleixner 2007-10-23  31  #else /* 
__i386__ */
8fc37f2c include/asm-x86/ptrace.h  Thomas Gleixner 2007-10-23  32  
65ea5b03 include/asm-x86/ptrace.h  H. Peter Anvin  2008-01-30 @33  struct 
pt_regs {
e90e147c arch/x86/include/asm/ptrace.h Denys Vlasenko  2015-02-

Re: [v2 6/7] x86/traps: Fixup general protection faults caused by UMIP

[kbuild test robot]

Hi Ricardo,

[auto build test ERROR on tip/auto-latest]
[also build test ERROR on next-20161223]
[cannot apply to tip/x86/core v4.9]
[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/Ricardo-Neri/x86-enable-User-Mode-Instruction-Prevention/20161224-094338
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from arch/x86/tools/test_get_len.c:27:0:
>> arch/x86/include/asm/insn.h:26:23: fatal error: linux/bug.h: No such file or 
>> directory
#include 
  ^
   compilation terminated.
--
   In file included from tools/include/linux/compiler.h:55:0,
from arch/x86/include/asm/insn.h:25,
from arch/x86/tools/insn_sanity.c:34:
>> tools/include/linux/types.h:28:18: error: conflicting types for 'u64'
typedef uint64_t u64;
 ^~~
   In file included from /usr/include/asm-generic/types.h:6:0,
from /usr/include/x86_64-linux-gnu/asm/types.h:4,
from tools/include/linux/types.h:9,
from tools/include/linux/compiler.h:55,
from arch/x86/include/asm/insn.h:25,
from arch/x86/tools/insn_sanity.c:34:
   include/asm-generic/int-ll64.h:25:28: note: previous declaration of 'u64' 
was here
typedef unsigned long long u64;
   ^~~
   In file included from tools/include/linux/compiler.h:55:0,
from arch/x86/include/asm/insn.h:25,
from arch/x86/tools/insn_sanity.c:34:
>> tools/include/linux/types.h:29:17: error: conflicting types for 's64'
typedef int64_t s64;
^~~
   In file included from /usr/include/asm-generic/types.h:6:0,
from /usr/include/x86_64-linux-gnu/asm/types.h:4,
from tools/include/linux/types.h:9,
from tools/include/linux/compiler.h:55,
from arch/x86/include/asm/insn.h:25,
from arch/x86/tools/insn_sanity.c:34:
   include/asm-generic/int-ll64.h:24:26: note: previous declaration of 's64' 
was here
typedef signed long long s64;
 ^~~
   In file included from tools/include/linux/types.h:4:0,
from tools/include/linux/compiler.h:55,
from arch/x86/include/asm/insn.h:25,
from arch/x86/tools/insn_sanity.c:34:
>> include/linux/stddef.h:10:2: error: expected identifier before numeric 
>> constant
 false = 0,
 ^
   In file included from arch/x86/include/asm/ptrace.h:5:0,
from arch/x86/include/asm/insn.h:28,
from arch/x86/tools/insn_sanity.c:34:
>> arch/x86/include/asm/page_types.h:61:15: error: unknown type name 
>> 'phys_addr_t'
static inline phys_addr_t get_max_mapped(void)
  ^~~
   arch/x86/include/asm/page_types.h: In function 'get_max_mapped':
>> arch/x86/include/asm/page_types.h:63:10: error: 'phys_addr_t' undeclared 
>> (first use in this function)
 return (phys_addr_t)max_pfn_mapped << PAGE_SHIFT;
 ^~~
   arch/x86/include/asm/page_types.h:63:10: note: each undeclared identifier is 
reported only once for each function it appears in
>> arch/x86/include/asm/page_types.h:63:22: error: expected ';' before 
>> 'max_pfn_mapped'
 return (phys_addr_t)max_pfn_mapped << PAGE_SHIFT;
 ^~
   In file included from arch/x86/include/asm/insn.h:28:0,
from arch/x86/tools/insn_sanity.c:34:
   arch/x86/include/asm/ptrace.h: At top level:
>> arch/x86/include/asm/ptrace.h:33:8: error: redefinition of 'struct pt_regs'
struct pt_regs {
   ^~~
   In file included from arch/x86/include/asm/insn.h:26:0,
from arch/x86/tools/insn_sanity.c:34:
   include/linux/bug.h:13:8: note: originally defined here
struct pt_regs;
   ^~~

vim +33 arch/x86/include/asm/ptrace.h

92bc2056 include/asm-x86/ptrace.h  Harvey Harrison 2008-02-08  27   
unsigned long sp;
92bc2056 include/asm-x86/ptrace.h  Harvey Harrison 2008-02-08  28   
unsigned long ss;
65ea5b03 include/asm-x86/ptrace.h  H. Peter Anvin  2008-01-30  29  };
8fc37f2c include/asm-x86/ptrace.h  Thomas Gleixner 2007-10-23  30  
8fc37f2c include/asm-x86/ptrace.h  Thomas Gleixner 2007-10-23  31  #else /* 
__i386__ */
8fc37f2c include/asm-x86/ptrace.h  Thomas Gleixner 2007-10-23  32  
65ea5b03 include/asm-x86/ptrace.h  H. Peter Anvin  2008-01-30 @33  struct 
pt_regs {
e90e147c arch/x86/include/asm/ptrace.h Denys Vlasenko  2015-02-

linux-next: Tree for Dec 24

[Stephen Rothwell]

Hi all,

Please do not add any material for v4.11 to your linux-next included
branches until after v4.10-rc1 has been released.

There will be no linux-next releases from me between Dec 25 and Jan 2
inclusive (unless I get really bored with my new toys :-)).

Changes since 20161223:

Non-merge commits (relative to Linus' tree): 729
 1201 files changed, 17538 insertions(+), 10332 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(with KALLSYMS_EXTRA_PASS=1) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 246 trees (counting Linus' and 35 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (50b17cfb1917 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (152b695d7437 builddeb: fix cross-building to 
arm64 producing host-arch debs)
Merging arc-current/for-curr (08fe007968b2 ARC: mm: arc700: Don't assume 2 
colours for aliasing VIPT dcache)
Merging arm-current/fixes (8478132a8784 Revert "arm: move exports to 
definitions")
Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (69973b830859 Linux 4.9)
Merging sparc/master (ba6d973f78eb Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (1636098c46ac sctp: fix recovering from 0 win with small 
data chunks)
Merging ipsec/master (bc3913a5378c Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging netfilter/master (6c5d5cfbe3c5 netfilter: ipt_CLUSTERIP: check 
duplicate config when initializing)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (22b68b93ae25 rtlwifi: Fix kernel oops 
introduced with commit e49656147359)
Merging mac80211/master (a17d93ff3a95 mac80211: fix legacy and invalid rx-rate 
report)
Merging sound-current/for-linus (995c6a7fd9b9 ALSA: hiface: Fix M2Tech hiFace 
driver sampling rate change)
Merging pci-current/for-linus (e42010d8207f PCI: Set Read Completion Boundary 
to 128 iff Root Port supports it (_HPX))
Merging driver-core.current/driver-core-linus (cdb98c2698b4 Revert "nvme: add 
support for the Write Zeroes command")
Merging tty.current/tty-linus (cdb98c2698b4 Revert "nvme: add support for the 
Write Zeroes command")
Merging usb.current/usb-linus (cdb98c2698b4 Revert "nvme: add support for the 
Write Zeroes command")
Merging usb-gadget-fixes/fixes (05e78c6933d6 usb: gadget: f_fs: fix wrong 
parenthesis in ffs_func_req_match())
Merging usb-serial-fixes/usb-linus (46490c347df4 USB: serial: option: add dlink 
dwm-158)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking 
unknown bit of pmu)
Merging staging.current/staging-linus (cdb98c2698b4 Revert "nvme: add support 
for the Write Zeroes command")
Merging char-misc.current/char-misc-linus (cdb98c2698b4 Revert "nvme: add 
support for the Write Zeroes command")
Merging input-current/for-linus (67626c932302 Input: synaptics_i2c - change 
msleep to 

linux-next: Tree for Dec 24

[Stephen Rothwell]

Hi all,

Please do not add any material for v4.11 to your linux-next included
branches until after v4.10-rc1 has been released.

There will be no linux-next releases from me between Dec 25 and Jan 2
inclusive (unless I get really bored with my new toys :-)).

Changes since 20161223:

Non-merge commits (relative to Linus' tree): 729
 1201 files changed, 17538 insertions(+), 10332 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(with KALLSYMS_EXTRA_PASS=1) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 246 trees (counting Linus' and 35 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (50b17cfb1917 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (152b695d7437 builddeb: fix cross-building to 
arm64 producing host-arch debs)
Merging arc-current/for-curr (08fe007968b2 ARC: mm: arc700: Don't assume 2 
colours for aliasing VIPT dcache)
Merging arm-current/fixes (8478132a8784 Revert "arm: move exports to 
definitions")
Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (69973b830859 Linux 4.9)
Merging sparc/master (ba6d973f78eb Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (1636098c46ac sctp: fix recovering from 0 win with small 
data chunks)
Merging ipsec/master (bc3913a5378c Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging netfilter/master (6c5d5cfbe3c5 netfilter: ipt_CLUSTERIP: check 
duplicate config when initializing)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (22b68b93ae25 rtlwifi: Fix kernel oops 
introduced with commit e49656147359)
Merging mac80211/master (a17d93ff3a95 mac80211: fix legacy and invalid rx-rate 
report)
Merging sound-current/for-linus (995c6a7fd9b9 ALSA: hiface: Fix M2Tech hiFace 
driver sampling rate change)
Merging pci-current/for-linus (e42010d8207f PCI: Set Read Completion Boundary 
to 128 iff Root Port supports it (_HPX))
Merging driver-core.current/driver-core-linus (cdb98c2698b4 Revert "nvme: add 
support for the Write Zeroes command")
Merging tty.current/tty-linus (cdb98c2698b4 Revert "nvme: add support for the 
Write Zeroes command")
Merging usb.current/usb-linus (cdb98c2698b4 Revert "nvme: add support for the 
Write Zeroes command")
Merging usb-gadget-fixes/fixes (05e78c6933d6 usb: gadget: f_fs: fix wrong 
parenthesis in ffs_func_req_match())
Merging usb-serial-fixes/usb-linus (46490c347df4 USB: serial: option: add dlink 
dwm-158)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking 
unknown bit of pmu)
Merging staging.current/staging-linus (cdb98c2698b4 Revert "nvme: add support 
for the Write Zeroes command")
Merging char-misc.current/char-misc-linus (cdb98c2698b4 Revert "nvme: add 
support for the Write Zeroes command")
Merging input-current/for-linus (67626c932302 Input: synaptics_i2c - change 
msleep to 

Re: [PATCH v7 00/12] Fix kdump faults on system with amd iommu

[Baoquan He]

Hi Joerg,

Ping!

Could you help review this version? Not sure this could catch up to
v4.10 merging.

Thanks
Baoqaun

On 11/25/16 at 01:13pm, Baoquan He wrote:
> This is v7 post.
> 
> The principle of the fix is similar to intel iommu. Just defer the assignment
> of device to domain to device driver init. In this version of post, a new
> call-back is_attach_deferred is added to iommu-ops, it's used to check whether
> we need defer the domain attach/detach in iommu-core code.
> 
> v5:
> bnx2 NIC can't reset itself during driver init. Post patch to reset
> it during driver init. IO_PAGE_FAULT can't be seen anymore.
> 
> Below is link of v5 post.
> 
> https://lists.linuxfoundation.org/pipermail/iommu/2016-September/018527.html
> 
> v5->v6:
> According to Joerg's comments made several below main changes:
> - Add sanity check when copy old dev tables.
> 
> - If a device is set up with guest translations (DTE.GV=1), then don't
>   copy that information but move the device over to an empty guest-cr3
>   table and handle the faults in the PPR log (which just answer them
>   with INVALID).
> 
> v6->v7:
> Two main changes are made according to Joerg's suggestion:
> - Add is_attach_deferred call-back to iommu-ops. With this domain
>   can be deferred to device driver init cleanly.
> 
> - Allocate memory below 4G for dev table if translation pre-enabled.
>   AMD engineer pointed out that it's unsafe to update the device-table
>   while iommu is enabled. device-table pointer update is split up into
>   two 32bit writes in the IOMMU hardware. So updating it while the IOMMU
>   is enabled could have some nasty side effects.
> 
> Baoquan He (12):
>   iommu/amd: Detect pre enabled translation
>   iommu/amd: add several helper function
>   iommu/amd: Define bit fields for DTE particularly
>   iommu/amd: Add function copy_dev_tables
>   iommu/amd: copy old trans table from old kernel
>   iommu: Add is_attach_deferred call-back to iommu-ops
>   iommu/amd: Use is_attach_deferred call-back
>   iommu/amd: Add sanity check of irq remap information of old dev table
> entry
>   iommu/amd: Don't copy GCR3 table root pointer
>   iommu/amd: Clear out the GV flag when handle deferred domain attach
>   iommu: Assign the direct mapped domain to group->domain
>   iommu/amd: Allocate memory below 4G for dev table if translation
> pre-enabled
> 
>  drivers/iommu/amd_iommu.c   |  78 +---
>  drivers/iommu/amd_iommu_init.c  | 201 
> +---
>  drivers/iommu/amd_iommu_proto.h |   2 +
>  drivers/iommu/amd_iommu_types.h |  53 ++-
>  drivers/iommu/amd_iommu_v2.c|  18 +++-
>  drivers/iommu/iommu.c   |   9 ++
>  include/linux/iommu.h   |   1 +
>  7 files changed, 313 insertions(+), 49 deletions(-)
> 
> -- 
> 2.5.5
> 

Re: [PATCH v7 00/12] Fix kdump faults on system with amd iommu

[Baoquan He]

Hi Joerg,

Ping!

Could you help review this version? Not sure this could catch up to
v4.10 merging.

Thanks
Baoqaun

On 11/25/16 at 01:13pm, Baoquan He wrote:
> This is v7 post.
> 
> The principle of the fix is similar to intel iommu. Just defer the assignment
> of device to domain to device driver init. In this version of post, a new
> call-back is_attach_deferred is added to iommu-ops, it's used to check whether
> we need defer the domain attach/detach in iommu-core code.
> 
> v5:
> bnx2 NIC can't reset itself during driver init. Post patch to reset
> it during driver init. IO_PAGE_FAULT can't be seen anymore.
> 
> Below is link of v5 post.
> 
> https://lists.linuxfoundation.org/pipermail/iommu/2016-September/018527.html
> 
> v5->v6:
> According to Joerg's comments made several below main changes:
> - Add sanity check when copy old dev tables.
> 
> - If a device is set up with guest translations (DTE.GV=1), then don't
>   copy that information but move the device over to an empty guest-cr3
>   table and handle the faults in the PPR log (which just answer them
>   with INVALID).
> 
> v6->v7:
> Two main changes are made according to Joerg's suggestion:
> - Add is_attach_deferred call-back to iommu-ops. With this domain
>   can be deferred to device driver init cleanly.
> 
> - Allocate memory below 4G for dev table if translation pre-enabled.
>   AMD engineer pointed out that it's unsafe to update the device-table
>   while iommu is enabled. device-table pointer update is split up into
>   two 32bit writes in the IOMMU hardware. So updating it while the IOMMU
>   is enabled could have some nasty side effects.
> 
> Baoquan He (12):
>   iommu/amd: Detect pre enabled translation
>   iommu/amd: add several helper function
>   iommu/amd: Define bit fields for DTE particularly
>   iommu/amd: Add function copy_dev_tables
>   iommu/amd: copy old trans table from old kernel
>   iommu: Add is_attach_deferred call-back to iommu-ops
>   iommu/amd: Use is_attach_deferred call-back
>   iommu/amd: Add sanity check of irq remap information of old dev table
> entry
>   iommu/amd: Don't copy GCR3 table root pointer
>   iommu/amd: Clear out the GV flag when handle deferred domain attach
>   iommu: Assign the direct mapped domain to group->domain
>   iommu/amd: Allocate memory below 4G for dev table if translation
> pre-enabled
> 
>  drivers/iommu/amd_iommu.c   |  78 +---
>  drivers/iommu/amd_iommu_init.c  | 201 
> +---
>  drivers/iommu/amd_iommu_proto.h |   2 +
>  drivers/iommu/amd_iommu_types.h |  53 ++-
>  drivers/iommu/amd_iommu_v2.c|  18 +++-
>  drivers/iommu/iommu.c   |   9 ++
>  include/linux/iommu.h   |   1 +
>  7 files changed, 313 insertions(+), 49 deletions(-)
> 
> -- 
> 2.5.5
> 

Re: [v2 7/7] x86: Enable User-Mode Instruction Prevention

[kbuild test robot]

Hi Ricardo,

[auto build test WARNING on tip/auto-latest]
[also build test WARNING on next-20161223]
[cannot apply to tip/x86/core v4.9]
[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/Ricardo-Neri/x86-enable-User-Mode-Instruction-Prevention/20161224-094338
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   arch/x86/kernel/umip.c: In function '__identify_insn':
>> arch/x86/kernel/umip.c:65:1: warning: control reaches end of non-void 
>> function [-Wreturn-type]
}
^

vim +65 arch/x86/kernel/umip.c

78301541 Ricardo Neri 2016-12-23  49return UMIP_SGDT;
78301541 Ricardo Neri 2016-12-23  50case 1:
78301541 Ricardo Neri 2016-12-23  51return UMIP_SIDT;
78301541 Ricardo Neri 2016-12-23  52case 4:
78301541 Ricardo Neri 2016-12-23  53return UMIP_SMSW;
78301541 Ricardo Neri 2016-12-23  54default:
78301541 Ricardo Neri 2016-12-23  55return -EINVAL;
78301541 Ricardo Neri 2016-12-23  56}
78301541 Ricardo Neri 2016-12-23  57} else if (insn->opcode.bytes[1] == 
0x0) {
78301541 Ricardo Neri 2016-12-23  58if 
(X86_MODRM_REG(insn->modrm.value) == 0)
78301541 Ricardo Neri 2016-12-23  59return UMIP_SLDT;
78301541 Ricardo Neri 2016-12-23  60else if 
(X86_MODRM_REG(insn->modrm.value) == 1)
78301541 Ricardo Neri 2016-12-23  61return UMIP_STR;
78301541 Ricardo Neri 2016-12-23  62else
78301541 Ricardo Neri 2016-12-23  63return -EINVAL;
78301541 Ricardo Neri 2016-12-23  64}
78301541 Ricardo Neri 2016-12-23 @65  }
78301541 Ricardo Neri 2016-12-23  66  
78301541 Ricardo Neri 2016-12-23  67  static int __emulate_umip_insn(struct 
insn *insn, enum umip_insn umip_inst,
78301541 Ricardo Neri 2016-12-23  68   unsigned char 
*data, int *data_size)
78301541 Ricardo Neri 2016-12-23  69  {
78301541 Ricardo Neri 2016-12-23  70unsigned long const *dummy_base_addr;
78301541 Ricardo Neri 2016-12-23  71unsigned short dummy_limit = 0;
78301541 Ricardo Neri 2016-12-23  72unsigned short dummy_value = 0;
78301541 Ricardo Neri 2016-12-23  73  

:: The code at line 65 was first introduced by commit
:: 7830154191c35fde49ef59c2b9328f6b32203be4 x86: Add emulation code for 
UMIP instructions

:: TO: Ricardo Neri <ricardo.neri-calde...@linux.intel.com>
:: CC: 0day robot <fengguang...@intel.com>

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


.config.gz
Description: application/gzip

Re: [v2 7/7] x86: Enable User-Mode Instruction Prevention

[kbuild test robot]

Hi Ricardo,

[auto build test WARNING on tip/auto-latest]
[also build test WARNING on next-20161223]
[cannot apply to tip/x86/core v4.9]
[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/Ricardo-Neri/x86-enable-User-Mode-Instruction-Prevention/20161224-094338
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   arch/x86/kernel/umip.c: In function '__identify_insn':
>> arch/x86/kernel/umip.c:65:1: warning: control reaches end of non-void 
>> function [-Wreturn-type]
}
^

vim +65 arch/x86/kernel/umip.c

78301541 Ricardo Neri 2016-12-23  49return UMIP_SGDT;
78301541 Ricardo Neri 2016-12-23  50case 1:
78301541 Ricardo Neri 2016-12-23  51return UMIP_SIDT;
78301541 Ricardo Neri 2016-12-23  52case 4:
78301541 Ricardo Neri 2016-12-23  53return UMIP_SMSW;
78301541 Ricardo Neri 2016-12-23  54default:
78301541 Ricardo Neri 2016-12-23  55return -EINVAL;
78301541 Ricardo Neri 2016-12-23  56}
78301541 Ricardo Neri 2016-12-23  57} else if (insn->opcode.bytes[1] == 
0x0) {
78301541 Ricardo Neri 2016-12-23  58if 
(X86_MODRM_REG(insn->modrm.value) == 0)
78301541 Ricardo Neri 2016-12-23  59return UMIP_SLDT;
78301541 Ricardo Neri 2016-12-23  60else if 
(X86_MODRM_REG(insn->modrm.value) == 1)
78301541 Ricardo Neri 2016-12-23  61return UMIP_STR;
78301541 Ricardo Neri 2016-12-23  62else
78301541 Ricardo Neri 2016-12-23  63return -EINVAL;
78301541 Ricardo Neri 2016-12-23  64}
78301541 Ricardo Neri 2016-12-23 @65  }
78301541 Ricardo Neri 2016-12-23  66  
78301541 Ricardo Neri 2016-12-23  67  static int __emulate_umip_insn(struct 
insn *insn, enum umip_insn umip_inst,
78301541 Ricardo Neri 2016-12-23  68   unsigned char 
*data, int *data_size)
78301541 Ricardo Neri 2016-12-23  69  {
78301541 Ricardo Neri 2016-12-23  70unsigned long const *dummy_base_addr;
78301541 Ricardo Neri 2016-12-23  71unsigned short dummy_limit = 0;
78301541 Ricardo Neri 2016-12-23  72unsigned short dummy_value = 0;
78301541 Ricardo Neri 2016-12-23  73  

:: The code at line 65 was first introduced by commit
:: 7830154191c35fde49ef59c2b9328f6b32203be4 x86: Add emulation code for 
UMIP instructions

:: TO: Ricardo Neri 
:: CC: 0day robot 

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


.config.gz
Description: application/gzip

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

[Jens Axboe]

On 12/23/2016 12:42 PM, Linus Torvalds wrote:
> On Fri, Dec 23, 2016 at 2:00 AM, Christoph Hellwig  wrote:
>>
>> From: Christoph Hellwig 
>> Date: Fri, 23 Dec 2016 10:57:06 +0100
>> Subject: virtio_blk: avoid DMA to stack for the sense buffer
>>
>> Most users of BLOCK_PC requests allocate the sense buffer on the stack,
>> so to avoid DMA to the stack copy them to a field in the heap allocated
>> virtblk_req structure.  Without that any attempt at SCSI passthrough I/O,
>> including the SG_IO ioctl from userspace will crash the kernel.  Note that
>> this includes running tools like hdparm even when the host does not have
>> SCSI passthrough enabled.
> 
> Ugh. This patch is nasty.
> 
> I think we should just fix blk_execute_rq() instead.
> 
> But from a quick look, we also have at least sg_scsi_ioctl() and
> sg_io() doing the same thing.
> 
> And the SG_IO thing in bsg_ioctl(). And spi_execute() in scsi_transport_spi.c
> 
> And resp_requests() in scsi_debug.c.

It's not that it's technically hard to fix up, it's more that it's a
pain in the ass to have to do it. For instance, for blk_execute_rq(), we
either should enforce that the caller allocates it dynamically and then
free it, or we need nasty hack where the caller needs to know he has to
free it. Pretty obvious what I would prefer there.

And yes, there would be a good chunk of other places where this would
nede to be fixed up...

> So I guess ugly it may need to be, and the rule is that the sense
> buffer really can be on the stack and you can't DMA to/from it.
> Comments from others?

I'm just wondering why this is being hit now, we have a 4.9 release with
this issue and nobody reported it (that I saw)... Which is pretty sad.

If no one beats me to it, I'll try and get a patch done on Sunday. We're
in the midst of the holidays here.

-- 
Jens Axboe

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

[Jens Axboe]

On 12/23/2016 12:42 PM, Linus Torvalds wrote:
> On Fri, Dec 23, 2016 at 2:00 AM, Christoph Hellwig  wrote:
>>
>> From: Christoph Hellwig 
>> Date: Fri, 23 Dec 2016 10:57:06 +0100
>> Subject: virtio_blk: avoid DMA to stack for the sense buffer
>>
>> Most users of BLOCK_PC requests allocate the sense buffer on the stack,
>> so to avoid DMA to the stack copy them to a field in the heap allocated
>> virtblk_req structure.  Without that any attempt at SCSI passthrough I/O,
>> including the SG_IO ioctl from userspace will crash the kernel.  Note that
>> this includes running tools like hdparm even when the host does not have
>> SCSI passthrough enabled.
> 
> Ugh. This patch is nasty.
> 
> I think we should just fix blk_execute_rq() instead.
> 
> But from a quick look, we also have at least sg_scsi_ioctl() and
> sg_io() doing the same thing.
> 
> And the SG_IO thing in bsg_ioctl(). And spi_execute() in scsi_transport_spi.c
> 
> And resp_requests() in scsi_debug.c.

It's not that it's technically hard to fix up, it's more that it's a
pain in the ass to have to do it. For instance, for blk_execute_rq(), we
either should enforce that the caller allocates it dynamically and then
free it, or we need nasty hack where the caller needs to know he has to
free it. Pretty obvious what I would prefer there.

And yes, there would be a good chunk of other places where this would
nede to be fixed up...

> So I guess ugly it may need to be, and the rule is that the sense
> buffer really can be on the stack and you can't DMA to/from it.
> Comments from others?

I'm just wondering why this is being hit now, we have a 4.9 release with
this issue and nobody reported it (that I saw)... Which is pretty sad.

If no one beats me to it, I'll try and get a patch done on Sunday. We're
in the midst of the holidays here.

-- 
Jens Axboe

Re: [v2 3/7] x86/mpx, x86/insn: Relocate insn util functions to a new insn-utils

[kbuild test robot]

Hi Ricardo,

[auto build test WARNING on tip/auto-latest]
[also build test WARNING on v4.9 next-20161223]
[cannot apply to tip/x86/core]
[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/Ricardo-Neri/x86-enable-User-Mode-Instruction-Prevention/20161224-094338
config: x86_64-randconfig-x008-201651 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> warning: objtool: x86 instruction decoder differs from kernel

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


.config.gz
Description: application/gzip

Re: [v2 3/7] x86/mpx, x86/insn: Relocate insn util functions to a new insn-utils

[kbuild test robot]

Hi Ricardo,

[auto build test WARNING on tip/auto-latest]
[also build test WARNING on v4.9 next-20161223]
[cannot apply to tip/x86/core]
[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/Ricardo-Neri/x86-enable-User-Mode-Instruction-Prevention/20161224-094338
config: x86_64-randconfig-x008-201651 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> warning: objtool: x86 instruction decoder differs from kernel

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


.config.gz
Description: application/gzip

Re: [PATCH] adc: add adc driver for Hisilicon BVT SOCs

[Jiancheng Xue]

On 2016/12/24 9:54, Allen Liu wrote:
> Add ADC driver for the ADC controller found on HiSilicon BVT SOCs, like 
> Hi3516CV300, etc.
> The ADC controller is primarily in charge of detecting voltage.
> 
> Reviewed-by: Jiancheng Xue 
Hi

Sorry. I haven't reviewed this patch. Please remove this line. Thank you!

Regards,
Jiancheng

> Signed-off-by: Allen Liu 
> ---
>  .../devicetree/bindings/iio/adc/hibvt-lsadc.txt|  26 ++
>  drivers/iio/adc/Kconfig|  10 +
>  drivers/iio/adc/Makefile   |   1 +
>  drivers/iio/adc/hibvt_lsadc.c  | 344 
> +
>  4 files changed, 381 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt
>  create mode 100644 drivers/iio/adc/hibvt_lsadc.c
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt 
> b/Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt
> new file mode 100644
> index 000..63de46e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt
> @@ -0,0 +1,26 @@
> +Hisilicon BVT Low Speed (LS) A/D Converter bindings
> +
> +Required properties:
> +- compatible: should be "hisilicon,-lsadc"
> +   - "hisilicon,hibvt-lsadc": for hi3516cv300
> +
> +- reg: physical base address of the controller and length of memory mapped
> +   region.
> +- interrupts: The interrupt number to the cpu. The interrupt specifier format
> +  depends on the interrupt controller.
> +- #io-channel-cells: Should be 1, see ../iio-bindings.txt
> +
> +Optional properties:
> +- resets: Must contain an entry for each entry in reset-names if need support
> +   this option. See ../reset/reset.txt for details.
> +- reset-names: Must include the name "saradc-apb".
> +
> +Example:
> + lsadc: hibvt-lsadc@120e {
> + compatible = "hisilicon,hibvt-lsadc";
> + reg = <0x120e 0x1000>;
> + interrupts = <19>;
> + resets = < 0x7c 3>;
> + reset-names = "lsadc-crg";
> + status = "disabled";
> + };
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 99c0514..0443f51 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -225,6 +225,16 @@ config HI8435
> This driver can also be built as a module. If so, the module will be
> called hi8435.
>  
> +config HIBVT_LSADC
> + tristate "HIBVT LSADC driver"
> + depends on ARCH_HISI || COMPILE_TEST
> + help
> +   Say yes here to build support for the LSADC found in SoCs from
> +   hisilicon BVT chip.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called hibvt_lsadc.
> +
>  config INA2XX_ADC
>   tristate "Texas Instruments INA2xx Power Monitors IIO driver"
>   depends on I2C && !SENSORS_INA2XX
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 7a40c04..6554d92 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
>  obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
>  obj-$(CONFIG_HI8435) += hi8435.o
> +obj-$(CONFIG_HIBVT_LSADC) += hibvt_lsadc.o
>  obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
>  obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
>  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> diff --git a/drivers/iio/adc/hibvt_lsadc.c b/drivers/iio/adc/hibvt_lsadc.c
> new file mode 100644
> index 000..a20afe8
> --- /dev/null
> +++ b/drivers/iio/adc/hibvt_lsadc.c
> @@ -0,0 +1,344 @@
> +/*
> + * Hisilicon BVT Low Speed (LS) A/D Converter
> + * Copyright (C) 2016 HiSilicon Technologies Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* hisilicon bvt adc registers definitions */
> +#define LSADC_CONFIG 0x00
> +#define CONFIG_DEGLITCH  BIT(17)
> +#define CONFIG_RESET BIT(15)
> +#define CONFIG_POWERDOWN BIT(14)
> +#define CONFIG_MODE  BIT(13)
> +#define CONFIG_CHC_VALID BIT(10)
> +#define CONFIG_CHB_VALID BIT(9)
> +#define CONFIG_CHA_VALID BIT(8)
> +
> +#define LSADC_TIMESCAN   0x08
> +#define LSADC_INTEN  

Re: [PATCH] adc: add adc driver for Hisilicon BVT SOCs

[Jiancheng Xue]

On 2016/12/24 9:54, Allen Liu wrote:
> Add ADC driver for the ADC controller found on HiSilicon BVT SOCs, like 
> Hi3516CV300, etc.
> The ADC controller is primarily in charge of detecting voltage.
> 
> Reviewed-by: Jiancheng Xue 
Hi

Sorry. I haven't reviewed this patch. Please remove this line. Thank you!

Regards,
Jiancheng

> Signed-off-by: Allen Liu 
> ---
>  .../devicetree/bindings/iio/adc/hibvt-lsadc.txt|  26 ++
>  drivers/iio/adc/Kconfig|  10 +
>  drivers/iio/adc/Makefile   |   1 +
>  drivers/iio/adc/hibvt_lsadc.c  | 344 
> +
>  4 files changed, 381 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt
>  create mode 100644 drivers/iio/adc/hibvt_lsadc.c
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt 
> b/Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt
> new file mode 100644
> index 000..63de46e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt
> @@ -0,0 +1,26 @@
> +Hisilicon BVT Low Speed (LS) A/D Converter bindings
> +
> +Required properties:
> +- compatible: should be "hisilicon,-lsadc"
> +   - "hisilicon,hibvt-lsadc": for hi3516cv300
> +
> +- reg: physical base address of the controller and length of memory mapped
> +   region.
> +- interrupts: The interrupt number to the cpu. The interrupt specifier format
> +  depends on the interrupt controller.
> +- #io-channel-cells: Should be 1, see ../iio-bindings.txt
> +
> +Optional properties:
> +- resets: Must contain an entry for each entry in reset-names if need support
> +   this option. See ../reset/reset.txt for details.
> +- reset-names: Must include the name "saradc-apb".
> +
> +Example:
> + lsadc: hibvt-lsadc@120e {
> + compatible = "hisilicon,hibvt-lsadc";
> + reg = <0x120e 0x1000>;
> + interrupts = <19>;
> + resets = < 0x7c 3>;
> + reset-names = "lsadc-crg";
> + status = "disabled";
> + };
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 99c0514..0443f51 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -225,6 +225,16 @@ config HI8435
> This driver can also be built as a module. If so, the module will be
> called hi8435.
>  
> +config HIBVT_LSADC
> + tristate "HIBVT LSADC driver"
> + depends on ARCH_HISI || COMPILE_TEST
> + help
> +   Say yes here to build support for the LSADC found in SoCs from
> +   hisilicon BVT chip.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called hibvt_lsadc.
> +
>  config INA2XX_ADC
>   tristate "Texas Instruments INA2xx Power Monitors IIO driver"
>   depends on I2C && !SENSORS_INA2XX
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 7a40c04..6554d92 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
>  obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
>  obj-$(CONFIG_HI8435) += hi8435.o
> +obj-$(CONFIG_HIBVT_LSADC) += hibvt_lsadc.o
>  obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
>  obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
>  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> diff --git a/drivers/iio/adc/hibvt_lsadc.c b/drivers/iio/adc/hibvt_lsadc.c
> new file mode 100644
> index 000..a20afe8
> --- /dev/null
> +++ b/drivers/iio/adc/hibvt_lsadc.c
> @@ -0,0 +1,344 @@
> +/*
> + * Hisilicon BVT Low Speed (LS) A/D Converter
> + * Copyright (C) 2016 HiSilicon Technologies Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* hisilicon bvt adc registers definitions */
> +#define LSADC_CONFIG 0x00
> +#define CONFIG_DEGLITCH  BIT(17)
> +#define CONFIG_RESET BIT(15)
> +#define CONFIG_POWERDOWN BIT(14)
> +#define CONFIG_MODE  BIT(13)
> +#define CONFIG_CHC_VALID BIT(10)
> +#define CONFIG_CHB_VALID BIT(9)
> +#define CONFIG_CHA_VALID BIT(8)
> +
> +#define LSADC_TIMESCAN   0x08
> +#define LSADC_INTEN  0x10
> +#define LSADC_INTSTATUS  

Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

[Andy Lutomirski]

On Fri, Dec 23, 2016 at 6:22 PM, Andy Lutomirski  wrote:
> There are some pieecs of kernel code that want to compute SHA256
> directly without going through the crypto core.  Adjust the exported
> API to decouple it from the crypto core.
>
> I suspect this will very slightly speed up the SHA256 shash operations
> as well by reducing the amount of indirection involved.
>

I should also mention: there's a nice potential cleanup that's
possible on top of this.  Currently, most of the accelerated SHA256
implementations just swap out the block function.  Another approach to
enabling this would be to restructure sha256_update along the lines
of:

sha256_block_fn_t fn = arch_sha256_block_fn(len);
sha256_base_do_update(sctx, data, len, arch_sha256_block_fn(len));

The idea being that arch code can decide whether to use an accelerated
block function based on context (x86, for example, can't always use
xmm regs) and length (on x86, using the accelerated versions for short
digests is very slow due to the state save/restore that happens) and
then the core code can just use it.

This would allow a lot of the boilerplate that this patch was forced
to modify to be deleted outright.

--Andy

Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

[Andy Lutomirski]

On Fri, Dec 23, 2016 at 6:22 PM, Andy Lutomirski  wrote:
> There are some pieecs of kernel code that want to compute SHA256
> directly without going through the crypto core.  Adjust the exported
> API to decouple it from the crypto core.
>
> I suspect this will very slightly speed up the SHA256 shash operations
> as well by reducing the amount of indirection involved.
>

I should also mention: there's a nice potential cleanup that's
possible on top of this.  Currently, most of the accelerated SHA256
implementations just swap out the block function.  Another approach to
enabling this would be to restructure sha256_update along the lines
of:

sha256_block_fn_t fn = arch_sha256_block_fn(len);
sha256_base_do_update(sctx, data, len, arch_sha256_block_fn(len));

The idea being that arch code can decide whether to use an accelerated
block function based on context (x86, for example, can't always use
xmm regs) and length (on x86, using the accelerated versions for short
digests is very slow due to the state save/restore that happens) and
then the core code can just use it.

This would allow a lot of the boilerplate that this patch was forced
to modify to be deleted outright.

--Andy

[RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

[Andy Lutomirski]

There are some pieecs of kernel code that want to compute SHA256
directly without going through the crypto core.  Adjust the exported
API to decouple it from the crypto core.

I suspect this will very slightly speed up the SHA256 shash operations
as well by reducing the amount of indirection involved.

Cc: Ard Biesheuvel 
Cc: Herbert Xu 
Signed-off-by: Andy Lutomirski 
---
 arch/arm/crypto/sha2-ce-glue.c  | 10 ---
 arch/arm/crypto/sha256_glue.c   | 23 ++-
 arch/arm/crypto/sha256_neon_glue.c  | 34 +++--
 arch/arm64/crypto/sha2-ce-glue.c| 13 
 arch/arm64/crypto/sha256-glue.c | 59 +
 arch/x86/crypto/sha256_ssse3_glue.c | 46 +
 arch/x86/purgatory/purgatory.c  |  2 +-
 arch/x86/purgatory/sha256.c | 25 ++--
 arch/x86/purgatory/sha256.h | 22 --
 crypto/sha256_generic.c | 50 +++
 include/crypto/sha.h| 29 ++
 include/crypto/sha256_base.h| 40 -
 12 files changed, 184 insertions(+), 169 deletions(-)
 delete mode 100644 arch/x86/purgatory/sha256.h

diff --git a/arch/arm/crypto/sha2-ce-glue.c b/arch/arm/crypto/sha2-ce-glue.c
index 0755b2d657f3..8832c2f85591 100644
--- a/arch/arm/crypto/sha2-ce-glue.c
+++ b/arch/arm/crypto/sha2-ce-glue.c
@@ -38,7 +38,7 @@ static int sha2_ce_update(struct shash_desc *desc, const u8 
*data,
return crypto_sha256_arm_update(desc, data, len);
 
kernel_neon_begin();
-   sha256_base_do_update(desc, data, len,
+   sha256_base_do_update(sctx, data, len,
  (sha256_block_fn *)sha2_ce_transform);
kernel_neon_end();
 
@@ -48,17 +48,19 @@ static int sha2_ce_update(struct shash_desc *desc, const u8 
*data,
 static int sha2_ce_finup(struct shash_desc *desc, const u8 *data,
 unsigned int len, u8 *out)
 {
+   struct sha256_state *sctx = shash_desc_ctx(desc);
+
if (!may_use_simd())
return crypto_sha256_arm_finup(desc, data, len, out);
 
kernel_neon_begin();
if (len)
-   sha256_base_do_update(desc, data, len,
+   sha256_base_do_update(sctx, data, len,
  (sha256_block_fn *)sha2_ce_transform);
-   sha256_base_do_finalize(desc, (sha256_block_fn *)sha2_ce_transform);
+   sha256_base_do_finalize(sctx, (sha256_block_fn *)sha2_ce_transform);
kernel_neon_end();
 
-   return sha256_base_finish(desc, out);
+   return crypto_sha2_final(desc, out);
 }
 
 static int sha2_ce_final(struct shash_desc *desc, u8 *out)
diff --git a/arch/arm/crypto/sha256_glue.c b/arch/arm/crypto/sha256_glue.c
index a84e869ef900..405a29a9a9d3 100644
--- a/arch/arm/crypto/sha256_glue.c
+++ b/arch/arm/crypto/sha256_glue.c
@@ -36,27 +36,34 @@ asmlinkage void sha256_block_data_order(u32 *digest, const 
void *data,
 int crypto_sha256_arm_update(struct shash_desc *desc, const u8 *data,
 unsigned int len)
 {
+   struct sha256_state *sctx = shash_desc_ctx(desc);
+
/* make sure casting to sha256_block_fn() is safe */
BUILD_BUG_ON(offsetof(struct sha256_state, state) != 0);
 
-   return sha256_base_do_update(desc, data, len,
+   sha256_base_do_update(sctx, data, len,
(sha256_block_fn *)sha256_block_data_order);
+   return 0;
 }
 EXPORT_SYMBOL(crypto_sha256_arm_update);
 
-static int sha256_final(struct shash_desc *desc, u8 *out)
+static int sha256_arm_final(struct shash_desc *desc, u8 *out)
 {
-   sha256_base_do_finalize(desc,
+   struct sha256_state *sctx = shash_desc_ctx(desc);
+
+   sha256_base_do_finalize(sctx,
(sha256_block_fn *)sha256_block_data_order);
-   return sha256_base_finish(desc, out);
+   return crypto_sha2_final(desc, out);
 }
 
 int crypto_sha256_arm_finup(struct shash_desc *desc, const u8 *data,
unsigned int len, u8 *out)
 {
-   sha256_base_do_update(desc, data, len,
+   struct sha256_state *sctx = shash_desc_ctx(desc);
+
+   sha256_base_do_update(sctx, data, len,
  (sha256_block_fn *)sha256_block_data_order);
-   return sha256_final(desc, out);
+   return crypto_sha2_final(desc, out);
 }
 EXPORT_SYMBOL(crypto_sha256_arm_finup);
 
@@ -64,7 +71,7 @@ static struct shash_alg algs[] = { {
.digestsize =   SHA256_DIGEST_SIZE,
.init   =   sha256_base_init,
.update =   crypto_sha256_arm_update,
-   .final  =   sha256_final,
+   .final  =   sha256_arm_final,
.finup  =   crypto_sha256_arm_finup,
.descsize   =   sizeof(struct sha256_state),
.base   

[RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

[Andy Lutomirski]

There are some pieecs of kernel code that want to compute SHA256
directly without going through the crypto core.  Adjust the exported
API to decouple it from the crypto core.

I suspect this will very slightly speed up the SHA256 shash operations
as well by reducing the amount of indirection involved.

Cc: Ard Biesheuvel 
Cc: Herbert Xu 
Signed-off-by: Andy Lutomirski 
---
 arch/arm/crypto/sha2-ce-glue.c  | 10 ---
 arch/arm/crypto/sha256_glue.c   | 23 ++-
 arch/arm/crypto/sha256_neon_glue.c  | 34 +++--
 arch/arm64/crypto/sha2-ce-glue.c| 13 
 arch/arm64/crypto/sha256-glue.c | 59 +
 arch/x86/crypto/sha256_ssse3_glue.c | 46 +
 arch/x86/purgatory/purgatory.c  |  2 +-
 arch/x86/purgatory/sha256.c | 25 ++--
 arch/x86/purgatory/sha256.h | 22 --
 crypto/sha256_generic.c | 50 +++
 include/crypto/sha.h| 29 ++
 include/crypto/sha256_base.h| 40 -
 12 files changed, 184 insertions(+), 169 deletions(-)
 delete mode 100644 arch/x86/purgatory/sha256.h

diff --git a/arch/arm/crypto/sha2-ce-glue.c b/arch/arm/crypto/sha2-ce-glue.c
index 0755b2d657f3..8832c2f85591 100644
--- a/arch/arm/crypto/sha2-ce-glue.c
+++ b/arch/arm/crypto/sha2-ce-glue.c
@@ -38,7 +38,7 @@ static int sha2_ce_update(struct shash_desc *desc, const u8 
*data,
return crypto_sha256_arm_update(desc, data, len);
 
kernel_neon_begin();
-   sha256_base_do_update(desc, data, len,
+   sha256_base_do_update(sctx, data, len,
  (sha256_block_fn *)sha2_ce_transform);
kernel_neon_end();
 
@@ -48,17 +48,19 @@ static int sha2_ce_update(struct shash_desc *desc, const u8 
*data,
 static int sha2_ce_finup(struct shash_desc *desc, const u8 *data,
 unsigned int len, u8 *out)
 {
+   struct sha256_state *sctx = shash_desc_ctx(desc);
+
if (!may_use_simd())
return crypto_sha256_arm_finup(desc, data, len, out);
 
kernel_neon_begin();
if (len)
-   sha256_base_do_update(desc, data, len,
+   sha256_base_do_update(sctx, data, len,
  (sha256_block_fn *)sha2_ce_transform);
-   sha256_base_do_finalize(desc, (sha256_block_fn *)sha2_ce_transform);
+   sha256_base_do_finalize(sctx, (sha256_block_fn *)sha2_ce_transform);
kernel_neon_end();
 
-   return sha256_base_finish(desc, out);
+   return crypto_sha2_final(desc, out);
 }
 
 static int sha2_ce_final(struct shash_desc *desc, u8 *out)
diff --git a/arch/arm/crypto/sha256_glue.c b/arch/arm/crypto/sha256_glue.c
index a84e869ef900..405a29a9a9d3 100644
--- a/arch/arm/crypto/sha256_glue.c
+++ b/arch/arm/crypto/sha256_glue.c
@@ -36,27 +36,34 @@ asmlinkage void sha256_block_data_order(u32 *digest, const 
void *data,
 int crypto_sha256_arm_update(struct shash_desc *desc, const u8 *data,
 unsigned int len)
 {
+   struct sha256_state *sctx = shash_desc_ctx(desc);
+
/* make sure casting to sha256_block_fn() is safe */
BUILD_BUG_ON(offsetof(struct sha256_state, state) != 0);
 
-   return sha256_base_do_update(desc, data, len,
+   sha256_base_do_update(sctx, data, len,
(sha256_block_fn *)sha256_block_data_order);
+   return 0;
 }
 EXPORT_SYMBOL(crypto_sha256_arm_update);
 
-static int sha256_final(struct shash_desc *desc, u8 *out)
+static int sha256_arm_final(struct shash_desc *desc, u8 *out)
 {
-   sha256_base_do_finalize(desc,
+   struct sha256_state *sctx = shash_desc_ctx(desc);
+
+   sha256_base_do_finalize(sctx,
(sha256_block_fn *)sha256_block_data_order);
-   return sha256_base_finish(desc, out);
+   return crypto_sha2_final(desc, out);
 }
 
 int crypto_sha256_arm_finup(struct shash_desc *desc, const u8 *data,
unsigned int len, u8 *out)
 {
-   sha256_base_do_update(desc, data, len,
+   struct sha256_state *sctx = shash_desc_ctx(desc);
+
+   sha256_base_do_update(sctx, data, len,
  (sha256_block_fn *)sha256_block_data_order);
-   return sha256_final(desc, out);
+   return crypto_sha2_final(desc, out);
 }
 EXPORT_SYMBOL(crypto_sha256_arm_finup);
 
@@ -64,7 +71,7 @@ static struct shash_alg algs[] = { {
.digestsize =   SHA256_DIGEST_SIZE,
.init   =   sha256_base_init,
.update =   crypto_sha256_arm_update,
-   .final  =   sha256_final,
+   .final  =   sha256_arm_final,
.finup  =   crypto_sha256_arm_finup,
.descsize   =   sizeof(struct sha256_state),
.base   =   {
@@ -79,7 +86,7 @@ static struct shash_alg algs[] = { {

[RFC PATCH 4.10 3/6] bpf: Use SHA256 instead of SHA1 for bpf digests

[Andy Lutomirski]

BPF digests are intended to be used to avoid reloading programs that
are already loaded.  For use cases (CRIU?) where untrusted programs
are involved, intentional hash collisions could cause the wrong BPF
program to execute.  Additionally, if BPF digests are ever used
in-kernel to skip verification, a hash collision could give privilege
escalation directly.

SHA1 is no longer considered adequately collision-resistant (see, for
example, all the major browsers dropping support for SHA1
certificates).  Use SHA256 instead.

I moved the digest field to keep all of the bpf program metadata in
the same cache line.

Cc: Daniel Borkmann 
Cc: Alexei Starovoitov 
Signed-off-by: Andy Lutomirski 
---
 include/linux/filter.h | 11 +++
 init/Kconfig   |  1 +
 kernel/bpf/core.c  | 41 +++--
 3 files changed, 11 insertions(+), 42 deletions(-)

diff --git a/include/linux/filter.h b/include/linux/filter.h
index 702314253797..23df2574e30c 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -14,7 +14,8 @@
 #include 
 #include 
 #include 
-#include 
+
+#include 
 
 #include 
 
@@ -408,11 +409,11 @@ struct bpf_prog {
kmemcheck_bitfield_end(meta);
enum bpf_prog_type  type;   /* Type of BPF program */
u32 len;/* Number of filter blocks */
-   u32 digest[SHA_DIGEST_WORDS]; /* Program digest */
struct bpf_prog_aux *aux;   /* Auxiliary fields */
struct sock_fprog_kern  *orig_prog; /* Original BPF program */
unsigned int(*bpf_func)(const void *ctx,
const struct bpf_insn *insn);
+   u8  digest[SHA256_DIGEST_SIZE]; /* Program digest */
/* Instructions for interpreter */
union {
struct sock_filter  insns[0];
@@ -519,12 +520,6 @@ static inline u32 bpf_prog_insn_size(const struct bpf_prog 
*prog)
return prog->len * sizeof(struct bpf_insn);
 }
 
-static inline u32 bpf_prog_digest_scratch_size(const struct bpf_prog *prog)
-{
-   return round_up(bpf_prog_insn_size(prog) +
-   sizeof(__be64) + 1, SHA_MESSAGE_BYTES);
-}
-
 static inline unsigned int bpf_prog_size(unsigned int proglen)
 {
return max(sizeof(struct bpf_prog),
diff --git a/init/Kconfig b/init/Kconfig
index 223b734abccd..5a4e2d99cc38 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1634,6 +1634,7 @@ config BPF_SYSCALL
bool "Enable bpf() system call"
select ANON_INODES
select BPF
+   select CRYPTO_SHA256_LIB
default n
help
  Enable the bpf() system call that allows to manipulate eBPF
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 1eb4f1303756..911993863799 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -148,22 +148,18 @@ void __bpf_prog_free(struct bpf_prog *fp)
 
 int bpf_prog_calc_digest(struct bpf_prog *fp)
 {
-   const u32 bits_offset = SHA_MESSAGE_BYTES - sizeof(__be64);
-   u32 raw_size = bpf_prog_digest_scratch_size(fp);
-   u32 ws[SHA_WORKSPACE_WORDS];
-   u32 i, bsize, psize, blocks;
+   struct sha256_state sha;
+   u32 i, psize;
struct bpf_insn *dst;
bool was_ld_map;
-   u8 *raw, *todo;
-   __be32 *result;
-   __be64 *bits;
+   u8 *raw;
 
-   raw = vmalloc(raw_size);
+   psize = bpf_prog_insn_size(fp);
+   raw = vmalloc(psize);
if (!raw)
return -ENOMEM;
 
-   sha_init(fp->digest);
-   memset(ws, 0, sizeof(ws));
+   sha256_init();
 
/* We need to take out the map fd for the digest calculation
 * since they are unstable from user space side.
@@ -188,30 +184,7 @@ int bpf_prog_calc_digest(struct bpf_prog *fp)
}
}
 
-   psize = bpf_prog_insn_size(fp);
-   memset([psize], 0, raw_size - psize);
-   raw[psize++] = 0x80;
-
-   bsize  = round_up(psize, SHA_MESSAGE_BYTES);
-   blocks = bsize / SHA_MESSAGE_BYTES;
-   todo   = raw;
-   if (bsize - psize >= sizeof(__be64)) {
-   bits = (__be64 *)(todo + bsize - sizeof(__be64));
-   } else {
-   bits = (__be64 *)(todo + bsize + bits_offset);
-   blocks++;
-   }
-   *bits = cpu_to_be64((psize - 1) << 3);
-
-   while (blocks--) {
-   sha_transform(fp->digest, todo, ws);
-   todo += SHA_MESSAGE_BYTES;
-   }
-
-   result = (__force __be32 *)fp->digest;
-   for (i = 0; i < SHA_DIGEST_WORDS; i++)
-   result[i] = cpu_to_be32(fp->digest[i]);
-
+   sha256_finup(, raw, psize, fp->digest);
vfree(raw);
return 0;
 }
-- 
2.9.3

[RFC PATCH 4.10 3/6] bpf: Use SHA256 instead of SHA1 for bpf digests

[Andy Lutomirski]

BPF digests are intended to be used to avoid reloading programs that
are already loaded.  For use cases (CRIU?) where untrusted programs
are involved, intentional hash collisions could cause the wrong BPF
program to execute.  Additionally, if BPF digests are ever used
in-kernel to skip verification, a hash collision could give privilege
escalation directly.

SHA1 is no longer considered adequately collision-resistant (see, for
example, all the major browsers dropping support for SHA1
certificates).  Use SHA256 instead.

I moved the digest field to keep all of the bpf program metadata in
the same cache line.

Cc: Daniel Borkmann 
Cc: Alexei Starovoitov 
Signed-off-by: Andy Lutomirski 
---
 include/linux/filter.h | 11 +++
 init/Kconfig   |  1 +
 kernel/bpf/core.c  | 41 +++--
 3 files changed, 11 insertions(+), 42 deletions(-)

diff --git a/include/linux/filter.h b/include/linux/filter.h
index 702314253797..23df2574e30c 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -14,7 +14,8 @@
 #include 
 #include 
 #include 
-#include 
+
+#include 
 
 #include 
 
@@ -408,11 +409,11 @@ struct bpf_prog {
kmemcheck_bitfield_end(meta);
enum bpf_prog_type  type;   /* Type of BPF program */
u32 len;/* Number of filter blocks */
-   u32 digest[SHA_DIGEST_WORDS]; /* Program digest */
struct bpf_prog_aux *aux;   /* Auxiliary fields */
struct sock_fprog_kern  *orig_prog; /* Original BPF program */
unsigned int(*bpf_func)(const void *ctx,
const struct bpf_insn *insn);
+   u8  digest[SHA256_DIGEST_SIZE]; /* Program digest */
/* Instructions for interpreter */
union {
struct sock_filter  insns[0];
@@ -519,12 +520,6 @@ static inline u32 bpf_prog_insn_size(const struct bpf_prog 
*prog)
return prog->len * sizeof(struct bpf_insn);
 }
 
-static inline u32 bpf_prog_digest_scratch_size(const struct bpf_prog *prog)
-{
-   return round_up(bpf_prog_insn_size(prog) +
-   sizeof(__be64) + 1, SHA_MESSAGE_BYTES);
-}
-
 static inline unsigned int bpf_prog_size(unsigned int proglen)
 {
return max(sizeof(struct bpf_prog),
diff --git a/init/Kconfig b/init/Kconfig
index 223b734abccd..5a4e2d99cc38 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1634,6 +1634,7 @@ config BPF_SYSCALL
bool "Enable bpf() system call"
select ANON_INODES
select BPF
+   select CRYPTO_SHA256_LIB
default n
help
  Enable the bpf() system call that allows to manipulate eBPF
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 1eb4f1303756..911993863799 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -148,22 +148,18 @@ void __bpf_prog_free(struct bpf_prog *fp)
 
 int bpf_prog_calc_digest(struct bpf_prog *fp)
 {
-   const u32 bits_offset = SHA_MESSAGE_BYTES - sizeof(__be64);
-   u32 raw_size = bpf_prog_digest_scratch_size(fp);
-   u32 ws[SHA_WORKSPACE_WORDS];
-   u32 i, bsize, psize, blocks;
+   struct sha256_state sha;
+   u32 i, psize;
struct bpf_insn *dst;
bool was_ld_map;
-   u8 *raw, *todo;
-   __be32 *result;
-   __be64 *bits;
+   u8 *raw;
 
-   raw = vmalloc(raw_size);
+   psize = bpf_prog_insn_size(fp);
+   raw = vmalloc(psize);
if (!raw)
return -ENOMEM;
 
-   sha_init(fp->digest);
-   memset(ws, 0, sizeof(ws));
+   sha256_init();
 
/* We need to take out the map fd for the digest calculation
 * since they are unstable from user space side.
@@ -188,30 +184,7 @@ int bpf_prog_calc_digest(struct bpf_prog *fp)
}
}
 
-   psize = bpf_prog_insn_size(fp);
-   memset([psize], 0, raw_size - psize);
-   raw[psize++] = 0x80;
-
-   bsize  = round_up(psize, SHA_MESSAGE_BYTES);
-   blocks = bsize / SHA_MESSAGE_BYTES;
-   todo   = raw;
-   if (bsize - psize >= sizeof(__be64)) {
-   bits = (__be64 *)(todo + bsize - sizeof(__be64));
-   } else {
-   bits = (__be64 *)(todo + bsize + bits_offset);
-   blocks++;
-   }
-   *bits = cpu_to_be64((psize - 1) << 3);
-
-   while (blocks--) {
-   sha_transform(fp->digest, todo, ws);
-   todo += SHA_MESSAGE_BYTES;
-   }
-
-   result = (__force __be32 *)fp->digest;
-   for (i = 0; i < SHA_DIGEST_WORDS; i++)
-   result[i] = cpu_to_be32(fp->digest[i]);
-
+   sha256_finup(, raw, psize, fp->digest);
vfree(raw);
return 0;
 }
-- 
2.9.3

[RFC PATCH 4.10 2/6] crypto/sha256: Make the sha256 library functions selectable

[Andy Lutomirski]

This will let other kernel code call into sha256_init(), etc. without
pulling in the core crypto code.

Signed-off-by: Andy Lutomirski 
---
 crypto/Kconfig  | 8 
 crypto/Makefile | 2 +-
 crypto/sha256_generic.c | 4 
 include/crypto/sha.h| 4 
 4 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 160f08e721cc..85a2b3440c2b 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -10,6 +10,13 @@ config XOR_BLOCKS
 source "crypto/async_tx/Kconfig"
 
 #
+# Cryptographic algorithms that are usable without the Crypto API.
+# None of these should have visible config options.
+#
+config CRYPTO_SHA256_LIB
+   bool
+
+#
 # Cryptographic API Configuration
 #
 menuconfig CRYPTO
@@ -763,6 +770,7 @@ config CRYPTO_SHA512_MB
 
 config CRYPTO_SHA256
tristate "SHA224 and SHA256 digest algorithm"
+   select CRYPTO_SHA256_LIB
select CRYPTO_HASH
help
  SHA256 secure hash standard (DFIPS 180-2).
diff --git a/crypto/Makefile b/crypto/Makefile
index b8f0e3eb0791..d147d4c911f5 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -71,7 +71,7 @@ obj-$(CONFIG_CRYPTO_RMD160) += rmd160.o
 obj-$(CONFIG_CRYPTO_RMD256) += rmd256.o
 obj-$(CONFIG_CRYPTO_RMD320) += rmd320.o
 obj-$(CONFIG_CRYPTO_SHA1) += sha1_generic.o
-obj-$(CONFIG_CRYPTO_SHA256) += sha256_generic.o
+obj-$(CONFIG_CRYPTO_SHA256_LIB) += sha256_generic.o
 obj-$(CONFIG_CRYPTO_SHA512) += sha512_generic.o
 obj-$(CONFIG_CRYPTO_SHA3) += sha3_generic.o
 obj-$(CONFIG_CRYPTO_WP512) += wp512.o
diff --git a/crypto/sha256_generic.c b/crypto/sha256_generic.c
index f2747893402c..9df71ac66dc4 100644
--- a/crypto/sha256_generic.c
+++ b/crypto/sha256_generic.c
@@ -261,6 +261,8 @@ void sha256_final(struct sha256_state *sctx, u8 *out)
 }
 EXPORT_SYMBOL(sha256_final);
 
+#ifdef CONFIG_CRYPTO_HASH
+
 static int crypto_sha256_update(struct shash_desc *desc, const u8 *data,
unsigned int len)
 {
@@ -328,6 +330,8 @@ static void __exit sha256_generic_mod_fini(void)
 module_init(sha256_generic_mod_init);
 module_exit(sha256_generic_mod_fini);
 
+#endif /* CONFIG_CRYPTO_HASH */
+
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("SHA-224 and SHA-256 Secure Hash Algorithm");
 
diff --git a/include/crypto/sha.h b/include/crypto/sha.h
index 2b6978471605..381ba7fa5e3f 100644
--- a/include/crypto/sha.h
+++ b/include/crypto/sha.h
@@ -96,6 +96,8 @@ extern int crypto_sha1_update(struct shash_desc *desc, const 
u8 *data,
 extern int crypto_sha1_finup(struct shash_desc *desc, const u8 *data,
 unsigned int len, u8 *hash);
 
+#ifdef CONFIG_CRYPTO_SHA256_LIB
+
 static inline void sha256_init(struct sha256_state *sctx)
 {
sctx->state[0] = SHA256_H0;
@@ -121,6 +123,8 @@ static inline void sha256_finup(struct sha256_state *sctx, 
const u8 *data,
sha256_final(sctx, hash);
 }
 
+#endif /* CONFIG_CRYPTO_SHA256_LIB */
+
 extern int crypto_sha512_update(struct shash_desc *desc, const u8 *data,
  unsigned int len);
 
-- 
2.9.3

[RFC PATCH 4.10 4/6] bpf: Avoid copying the entire BPF program when hashing it

[Andy Lutomirski]

The sha256 helpers can consume a message incrementally, so there's no need
to allocate a buffer to store the whole blob to be hashed.

This may be a slight slowdown for very long messages because gcc can't
inline the sha256_update() calls.  For reasonably-sized programs,
however, this should be a considerable speedup as vmalloc() is quite
slow.

Cc: Daniel Borkmann 
Cc: Alexei Starovoitov 
Signed-off-by: Andy Lutomirski 
---
 kernel/bpf/core.c | 34 ++
 1 file changed, 14 insertions(+), 20 deletions(-)

diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 911993863799..1c2931f505af 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -149,43 +149,37 @@ void __bpf_prog_free(struct bpf_prog *fp)
 int bpf_prog_calc_digest(struct bpf_prog *fp)
 {
struct sha256_state sha;
-   u32 i, psize;
-   struct bpf_insn *dst;
+   u32 i;
bool was_ld_map;
-   u8 *raw;
-
-   psize = bpf_prog_insn_size(fp);
-   raw = vmalloc(psize);
-   if (!raw)
-   return -ENOMEM;
 
sha256_init();
 
/* We need to take out the map fd for the digest calculation
 * since they are unstable from user space side.
 */
-   dst = (void *)raw;
for (i = 0, was_ld_map = false; i < fp->len; i++) {
-   dst[i] = fp->insnsi[i];
+   struct bpf_insn insn = fp->insnsi[i];
+
if (!was_ld_map &&
-   dst[i].code == (BPF_LD | BPF_IMM | BPF_DW) &&
-   dst[i].src_reg == BPF_PSEUDO_MAP_FD) {
+   insn.code == (BPF_LD | BPF_IMM | BPF_DW) &&
+   insn.src_reg == BPF_PSEUDO_MAP_FD) {
was_ld_map = true;
-   dst[i].imm = 0;
+   insn.imm = 0;
} else if (was_ld_map &&
-  dst[i].code == 0 &&
-  dst[i].dst_reg == 0 &&
-  dst[i].src_reg == 0 &&
-  dst[i].off == 0) {
+  insn.code == 0 &&
+  insn.dst_reg == 0 &&
+  insn.src_reg == 0 &&
+  insn.off == 0) {
was_ld_map = false;
-   dst[i].imm = 0;
+   insn.imm = 0;
} else {
was_ld_map = false;
}
+
+   sha256_update(, (const u8 *), sizeof(insn));
}
 
-   sha256_finup(, raw, psize, fp->digest);
-   vfree(raw);
+   sha256_final(, fp->digest);
return 0;
 }
 
-- 
2.9.3

[RFC PATCH 4.10 6/6] net: Rename TCA*BPF_DIGEST to ..._SHA256

[Andy Lutomirski]

This makes it easier to add another digest algorithm down the road if
needed.  It also serves to force any programs that might have been
written against a kernel that had the old field name to notice the
change and make any necessary changes.

This shouldn't violate any stable API policies, as no released kernel
has ever had TCA*BPF_DIGEST.

Cc: Daniel Borkmann 
Cc: Alexei Starovoitov 
Signed-off-by: Andy Lutomirski 
---
 include/uapi/linux/pkt_cls.h   | 2 +-
 include/uapi/linux/tc_act/tc_bpf.h | 2 +-
 net/sched/act_bpf.c| 2 +-
 net/sched/cls_bpf.c| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index cb4bcdc58543..ac6b300c1550 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -397,7 +397,7 @@ enum {
TCA_BPF_NAME,
TCA_BPF_FLAGS,
TCA_BPF_FLAGS_GEN,
-   TCA_BPF_DIGEST,
+   TCA_BPF_SHA256,
__TCA_BPF_MAX,
 };
 
diff --git a/include/uapi/linux/tc_act/tc_bpf.h 
b/include/uapi/linux/tc_act/tc_bpf.h
index a6b88a6f7f71..eae18a7430eb 100644
--- a/include/uapi/linux/tc_act/tc_bpf.h
+++ b/include/uapi/linux/tc_act/tc_bpf.h
@@ -27,7 +27,7 @@ enum {
TCA_ACT_BPF_FD,
TCA_ACT_BPF_NAME,
TCA_ACT_BPF_PAD,
-   TCA_ACT_BPF_DIGEST,
+   TCA_ACT_BPF_SHA256,
__TCA_ACT_BPF_MAX,
 };
 #define TCA_ACT_BPF_MAX (__TCA_ACT_BPF_MAX - 1)
diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
index 1c60317f0121..3868a66d0b24 100644
--- a/net/sched/act_bpf.c
+++ b/net/sched/act_bpf.c
@@ -123,7 +123,7 @@ static int tcf_bpf_dump_ebpf_info(const struct tcf_bpf 
*prog,
nla_put_string(skb, TCA_ACT_BPF_NAME, prog->bpf_name))
return -EMSGSIZE;
 
-   nla = nla_reserve(skb, TCA_ACT_BPF_DIGEST,
+   nla = nla_reserve(skb, TCA_ACT_BPF_SHA256,
  sizeof(prog->filter->digest));
if (nla == NULL)
return -EMSGSIZE;
diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c
index adc776048d1a..6fc110321621 100644
--- a/net/sched/cls_bpf.c
+++ b/net/sched/cls_bpf.c
@@ -555,7 +555,7 @@ static int cls_bpf_dump_ebpf_info(const struct cls_bpf_prog 
*prog,
nla_put_string(skb, TCA_BPF_NAME, prog->bpf_name))
return -EMSGSIZE;
 
-   nla = nla_reserve(skb, TCA_BPF_DIGEST, sizeof(prog->filter->digest));
+   nla = nla_reserve(skb, TCA_BPF_SHA256, sizeof(prog->filter->digest));
if (nla == NULL)
return -EMSGSIZE;
 
-- 
2.9.3

[RFC PATCH 4.10 2/6] crypto/sha256: Make the sha256 library functions selectable

[Andy Lutomirski]

This will let other kernel code call into sha256_init(), etc. without
pulling in the core crypto code.

Signed-off-by: Andy Lutomirski 
---
 crypto/Kconfig  | 8 
 crypto/Makefile | 2 +-
 crypto/sha256_generic.c | 4 
 include/crypto/sha.h| 4 
 4 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 160f08e721cc..85a2b3440c2b 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -10,6 +10,13 @@ config XOR_BLOCKS
 source "crypto/async_tx/Kconfig"
 
 #
+# Cryptographic algorithms that are usable without the Crypto API.
+# None of these should have visible config options.
+#
+config CRYPTO_SHA256_LIB
+   bool
+
+#
 # Cryptographic API Configuration
 #
 menuconfig CRYPTO
@@ -763,6 +770,7 @@ config CRYPTO_SHA512_MB
 
 config CRYPTO_SHA256
tristate "SHA224 and SHA256 digest algorithm"
+   select CRYPTO_SHA256_LIB
select CRYPTO_HASH
help
  SHA256 secure hash standard (DFIPS 180-2).
diff --git a/crypto/Makefile b/crypto/Makefile
index b8f0e3eb0791..d147d4c911f5 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -71,7 +71,7 @@ obj-$(CONFIG_CRYPTO_RMD160) += rmd160.o
 obj-$(CONFIG_CRYPTO_RMD256) += rmd256.o
 obj-$(CONFIG_CRYPTO_RMD320) += rmd320.o
 obj-$(CONFIG_CRYPTO_SHA1) += sha1_generic.o
-obj-$(CONFIG_CRYPTO_SHA256) += sha256_generic.o
+obj-$(CONFIG_CRYPTO_SHA256_LIB) += sha256_generic.o
 obj-$(CONFIG_CRYPTO_SHA512) += sha512_generic.o
 obj-$(CONFIG_CRYPTO_SHA3) += sha3_generic.o
 obj-$(CONFIG_CRYPTO_WP512) += wp512.o
diff --git a/crypto/sha256_generic.c b/crypto/sha256_generic.c
index f2747893402c..9df71ac66dc4 100644
--- a/crypto/sha256_generic.c
+++ b/crypto/sha256_generic.c
@@ -261,6 +261,8 @@ void sha256_final(struct sha256_state *sctx, u8 *out)
 }
 EXPORT_SYMBOL(sha256_final);
 
+#ifdef CONFIG_CRYPTO_HASH
+
 static int crypto_sha256_update(struct shash_desc *desc, const u8 *data,
unsigned int len)
 {
@@ -328,6 +330,8 @@ static void __exit sha256_generic_mod_fini(void)
 module_init(sha256_generic_mod_init);
 module_exit(sha256_generic_mod_fini);
 
+#endif /* CONFIG_CRYPTO_HASH */
+
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("SHA-224 and SHA-256 Secure Hash Algorithm");
 
diff --git a/include/crypto/sha.h b/include/crypto/sha.h
index 2b6978471605..381ba7fa5e3f 100644
--- a/include/crypto/sha.h
+++ b/include/crypto/sha.h
@@ -96,6 +96,8 @@ extern int crypto_sha1_update(struct shash_desc *desc, const 
u8 *data,
 extern int crypto_sha1_finup(struct shash_desc *desc, const u8 *data,
 unsigned int len, u8 *hash);
 
+#ifdef CONFIG_CRYPTO_SHA256_LIB
+
 static inline void sha256_init(struct sha256_state *sctx)
 {
sctx->state[0] = SHA256_H0;
@@ -121,6 +123,8 @@ static inline void sha256_finup(struct sha256_state *sctx, 
const u8 *data,
sha256_final(sctx, hash);
 }
 
+#endif /* CONFIG_CRYPTO_SHA256_LIB */
+
 extern int crypto_sha512_update(struct shash_desc *desc, const u8 *data,
  unsigned int len);
 
-- 
2.9.3

[RFC PATCH 4.10 4/6] bpf: Avoid copying the entire BPF program when hashing it

[Andy Lutomirski]

The sha256 helpers can consume a message incrementally, so there's no need
to allocate a buffer to store the whole blob to be hashed.

This may be a slight slowdown for very long messages because gcc can't
inline the sha256_update() calls.  For reasonably-sized programs,
however, this should be a considerable speedup as vmalloc() is quite
slow.

Cc: Daniel Borkmann 
Cc: Alexei Starovoitov 
Signed-off-by: Andy Lutomirski 
---
 kernel/bpf/core.c | 34 ++
 1 file changed, 14 insertions(+), 20 deletions(-)

diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 911993863799..1c2931f505af 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -149,43 +149,37 @@ void __bpf_prog_free(struct bpf_prog *fp)
 int bpf_prog_calc_digest(struct bpf_prog *fp)
 {
struct sha256_state sha;
-   u32 i, psize;
-   struct bpf_insn *dst;
+   u32 i;
bool was_ld_map;
-   u8 *raw;
-
-   psize = bpf_prog_insn_size(fp);
-   raw = vmalloc(psize);
-   if (!raw)
-   return -ENOMEM;
 
sha256_init();
 
/* We need to take out the map fd for the digest calculation
 * since they are unstable from user space side.
 */
-   dst = (void *)raw;
for (i = 0, was_ld_map = false; i < fp->len; i++) {
-   dst[i] = fp->insnsi[i];
+   struct bpf_insn insn = fp->insnsi[i];
+
if (!was_ld_map &&
-   dst[i].code == (BPF_LD | BPF_IMM | BPF_DW) &&
-   dst[i].src_reg == BPF_PSEUDO_MAP_FD) {
+   insn.code == (BPF_LD | BPF_IMM | BPF_DW) &&
+   insn.src_reg == BPF_PSEUDO_MAP_FD) {
was_ld_map = true;
-   dst[i].imm = 0;
+   insn.imm = 0;
} else if (was_ld_map &&
-  dst[i].code == 0 &&
-  dst[i].dst_reg == 0 &&
-  dst[i].src_reg == 0 &&
-  dst[i].off == 0) {
+  insn.code == 0 &&
+  insn.dst_reg == 0 &&
+  insn.src_reg == 0 &&
+  insn.off == 0) {
was_ld_map = false;
-   dst[i].imm = 0;
+   insn.imm = 0;
} else {
was_ld_map = false;
}
+
+   sha256_update(, (const u8 *), sizeof(insn));
}
 
-   sha256_finup(, raw, psize, fp->digest);
-   vfree(raw);
+   sha256_final(, fp->digest);
return 0;
 }
 
-- 
2.9.3

[RFC PATCH 4.10 6/6] net: Rename TCA*BPF_DIGEST to ..._SHA256

[Andy Lutomirski]

This makes it easier to add another digest algorithm down the road if
needed.  It also serves to force any programs that might have been
written against a kernel that had the old field name to notice the
change and make any necessary changes.

This shouldn't violate any stable API policies, as no released kernel
has ever had TCA*BPF_DIGEST.

Cc: Daniel Borkmann 
Cc: Alexei Starovoitov 
Signed-off-by: Andy Lutomirski 
---
 include/uapi/linux/pkt_cls.h   | 2 +-
 include/uapi/linux/tc_act/tc_bpf.h | 2 +-
 net/sched/act_bpf.c| 2 +-
 net/sched/cls_bpf.c| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index cb4bcdc58543..ac6b300c1550 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -397,7 +397,7 @@ enum {
TCA_BPF_NAME,
TCA_BPF_FLAGS,
TCA_BPF_FLAGS_GEN,
-   TCA_BPF_DIGEST,
+   TCA_BPF_SHA256,
__TCA_BPF_MAX,
 };
 
diff --git a/include/uapi/linux/tc_act/tc_bpf.h 
b/include/uapi/linux/tc_act/tc_bpf.h
index a6b88a6f7f71..eae18a7430eb 100644
--- a/include/uapi/linux/tc_act/tc_bpf.h
+++ b/include/uapi/linux/tc_act/tc_bpf.h
@@ -27,7 +27,7 @@ enum {
TCA_ACT_BPF_FD,
TCA_ACT_BPF_NAME,
TCA_ACT_BPF_PAD,
-   TCA_ACT_BPF_DIGEST,
+   TCA_ACT_BPF_SHA256,
__TCA_ACT_BPF_MAX,
 };
 #define TCA_ACT_BPF_MAX (__TCA_ACT_BPF_MAX - 1)
diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
index 1c60317f0121..3868a66d0b24 100644
--- a/net/sched/act_bpf.c
+++ b/net/sched/act_bpf.c
@@ -123,7 +123,7 @@ static int tcf_bpf_dump_ebpf_info(const struct tcf_bpf 
*prog,
nla_put_string(skb, TCA_ACT_BPF_NAME, prog->bpf_name))
return -EMSGSIZE;
 
-   nla = nla_reserve(skb, TCA_ACT_BPF_DIGEST,
+   nla = nla_reserve(skb, TCA_ACT_BPF_SHA256,
  sizeof(prog->filter->digest));
if (nla == NULL)
return -EMSGSIZE;
diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c
index adc776048d1a..6fc110321621 100644
--- a/net/sched/cls_bpf.c
+++ b/net/sched/cls_bpf.c
@@ -555,7 +555,7 @@ static int cls_bpf_dump_ebpf_info(const struct cls_bpf_prog 
*prog,
nla_put_string(skb, TCA_BPF_NAME, prog->bpf_name))
return -EMSGSIZE;
 
-   nla = nla_reserve(skb, TCA_BPF_DIGEST, sizeof(prog->filter->digest));
+   nla = nla_reserve(skb, TCA_BPF_SHA256, sizeof(prog->filter->digest));
if (nla == NULL)
return -EMSGSIZE;
 
-- 
2.9.3

[RFC PATCH 4.10 5/6] bpf: Rename fdinfo's prog_digest to prog_sha256

[Andy Lutomirski]

This makes it easier to add another digest algorithm down the road
if needed.  It also serves to force any programs that might have
been written against a kernel that had 'prog_digest' to be updated.

This shouldn't violate any stable API policies, as no released
kernel has ever had 'prog_digest'.

Cc: Daniel Borkmann 
Cc: Alexei Starovoitov 
Signed-off-by: Andy Lutomirski 
---
 kernel/bpf/syscall.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index e89acea22ecf..956370b80296 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -694,7 +694,7 @@ static void bpf_prog_show_fdinfo(struct seq_file *m, struct 
file *filp)
seq_printf(m,
   "prog_type:\t%u\n"
   "prog_jited:\t%u\n"
-  "prog_digest:\t%s\n"
+  "prog_sha256:\t%s\n"
   "memlock:\t%llu\n",
   prog->type,
   prog->jited,
-- 
2.9.3

[RFC PATCH 4.10 5/6] bpf: Rename fdinfo's prog_digest to prog_sha256

[Andy Lutomirski]

This makes it easier to add another digest algorithm down the road
if needed.  It also serves to force any programs that might have
been written against a kernel that had 'prog_digest' to be updated.

This shouldn't violate any stable API policies, as no released
kernel has ever had 'prog_digest'.

Cc: Daniel Borkmann 
Cc: Alexei Starovoitov 
Signed-off-by: Andy Lutomirski 
---
 kernel/bpf/syscall.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index e89acea22ecf..956370b80296 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -694,7 +694,7 @@ static void bpf_prog_show_fdinfo(struct seq_file *m, struct 
file *filp)
seq_printf(m,
   "prog_type:\t%u\n"
   "prog_jited:\t%u\n"
-  "prog_digest:\t%s\n"
+  "prog_sha256:\t%s\n"
   "memlock:\t%llu\n",
   prog->type,
   prog->jited,
-- 
2.9.3

[RFC PATCH 4.10 0/6] Switch BPF's digest to SHA256

[Andy Lutomirski]

Since there are plenty of uses for the new-in-4.10 BPF digest feature
that would be problematic if malicious users could produce collisions,
the BPF digest should be collision-resistant.  SHA-1 is no longer
considered collision-resistant, so switch it to SHA-256.

The actual switchover is trivial.  Most of this series consists of
cleanups to the SHA256 code to make it usable as a standalone library
(since BPF should not depend on crypto).

The cleaned up library is much more user-friendly than the SHA-1 code,
so this also significantly tidies up the BPF digest code.

This is intended for 4.10.  If this series misses 4.10 and nothing
takes its place, then we'll have an unpleasant ABI stability
situation.

Andy Lutomirski (6):
  crypto/sha256: Refactor the API so it can be used without shash
  crypto/sha256: Make the sha256 library functions selectable
  bpf: Use SHA256 instead of SHA1 for bpf digests
  bpf: Avoid copying the entire BPF program when hashing it
  bpf: Rename fdinfo's prog_digest to prog_sha256
  net: Rename TCA*BPF_DIGEST to ..._SHA256

 arch/arm/crypto/sha2-ce-glue.c  | 10 +++---
 arch/arm/crypto/sha256_glue.c   | 23 +-
 arch/arm/crypto/sha256_neon_glue.c  | 34 ++--
 arch/arm64/crypto/sha2-ce-glue.c| 13 
 arch/arm64/crypto/sha256-glue.c | 59 +++---
 arch/x86/crypto/sha256_ssse3_glue.c | 46 ---
 arch/x86/purgatory/purgatory.c  |  2 +-
 arch/x86/purgatory/sha256.c | 25 ++-
 arch/x86/purgatory/sha256.h | 22 -
 crypto/Kconfig  |  8 +
 crypto/Makefile |  2 +-
 crypto/sha256_generic.c | 54 +++
 include/crypto/sha.h| 33 ---
 include/crypto/sha256_base.h| 40 +++
 include/linux/filter.h  | 11 ++-
 include/uapi/linux/pkt_cls.h|  2 +-
 include/uapi/linux/tc_act/tc_bpf.h  |  2 +-
 init/Kconfig|  1 +
 kernel/bpf/core.c   | 63 +
 kernel/bpf/syscall.c|  2 +-
 net/sched/act_bpf.c |  2 +-
 net/sched/cls_bpf.c |  2 +-
 22 files changed, 225 insertions(+), 231 deletions(-)
 delete mode 100644 arch/x86/purgatory/sha256.h

-- 
2.9.3

[RFC PATCH 4.10 0/6] Switch BPF's digest to SHA256

[Andy Lutomirski]

Since there are plenty of uses for the new-in-4.10 BPF digest feature
that would be problematic if malicious users could produce collisions,
the BPF digest should be collision-resistant.  SHA-1 is no longer
considered collision-resistant, so switch it to SHA-256.

The actual switchover is trivial.  Most of this series consists of
cleanups to the SHA256 code to make it usable as a standalone library
(since BPF should not depend on crypto).

The cleaned up library is much more user-friendly than the SHA-1 code,
so this also significantly tidies up the BPF digest code.

This is intended for 4.10.  If this series misses 4.10 and nothing
takes its place, then we'll have an unpleasant ABI stability
situation.

Andy Lutomirski (6):
  crypto/sha256: Refactor the API so it can be used without shash
  crypto/sha256: Make the sha256 library functions selectable
  bpf: Use SHA256 instead of SHA1 for bpf digests
  bpf: Avoid copying the entire BPF program when hashing it
  bpf: Rename fdinfo's prog_digest to prog_sha256
  net: Rename TCA*BPF_DIGEST to ..._SHA256

 arch/arm/crypto/sha2-ce-glue.c  | 10 +++---
 arch/arm/crypto/sha256_glue.c   | 23 +-
 arch/arm/crypto/sha256_neon_glue.c  | 34 ++--
 arch/arm64/crypto/sha2-ce-glue.c| 13 
 arch/arm64/crypto/sha256-glue.c | 59 +++---
 arch/x86/crypto/sha256_ssse3_glue.c | 46 ---
 arch/x86/purgatory/purgatory.c  |  2 +-
 arch/x86/purgatory/sha256.c | 25 ++-
 arch/x86/purgatory/sha256.h | 22 -
 crypto/Kconfig  |  8 +
 crypto/Makefile |  2 +-
 crypto/sha256_generic.c | 54 +++
 include/crypto/sha.h| 33 ---
 include/crypto/sha256_base.h| 40 +++
 include/linux/filter.h  | 11 ++-
 include/uapi/linux/pkt_cls.h|  2 +-
 include/uapi/linux/tc_act/tc_bpf.h  |  2 +-
 init/Kconfig|  1 +
 kernel/bpf/core.c   | 63 +
 kernel/bpf/syscall.c|  2 +-
 net/sched/act_bpf.c |  2 +-
 net/sched/cls_bpf.c |  2 +-
 22 files changed, 225 insertions(+), 231 deletions(-)
 delete mode 100644 arch/x86/purgatory/sha256.h

-- 
2.9.3

Re: [PATCH v2 4/4] clk: rockchip: add new pll-type for rk3328

[Heiko Stuebner]

Hi Elaine,

Am Montag, 19. Dezember 2016, 09:56:13 CET schrieb Elaine Zhang:
> The rk3328's pll and clock are similar with rk3036's,
> it different with pll_mode_mask,there are different
> control registers bit,
> so these should be independent and separate from
> the series of rk3328s.

not sure I understand this description. In the patch (and TRM excerpt) I see
that the number of parents is down to only xin24m but the general handling is
similar to the rk3036 and thus reuses its operations.

The description makes it sound like there are operational differences (the
"different control register bit" part), so could you clarify this a bit
please?

Also, please move the pll addition before the addition of the clock-controller
in the series and move the pll-type addition also here from the controller
patch.

Some more below:

> 
> Signed-off-by: Elaine Zhang 
> ---
>  drivers/clk/rockchip/clk-pll.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
> index 6ed605776abd..9650c75f61d1 100644
> --- a/drivers/clk/rockchip/clk-pll.c
> +++ b/drivers/clk/rockchip/clk-pll.c
> @@ -29,6 +29,7 @@
>  #define PLL_MODE_SLOW0x0
>  #define PLL_MODE_NORM0x1
>  #define PLL_MODE_DEEP0x2
> +#define PLL_RK3328_MODE_MASK 0x1
> 
>  struct rockchip_clk_pll {
>   struct clk_hw   hw;
> @@ -865,13 +866,17 @@ struct clk *rockchip_clk_register_pll(struct
> rockchip_clk_provider *ctx, pll_mux = >pll_mux;
>   pll_mux->reg = ctx->reg_base + mode_offset;
>   pll_mux->shift = mode_shift;
> - pll_mux->mask = PLL_MODE_MASK;
> + if (pll_type == pll_rk3328)
> + pll_mux->mask = PLL_RK3328_MODE_MASK;
> + else
> + pll_mux->mask = PLL_MODE_MASK;

you're missing the other parts handling parents, like num_parents check
and the init.num_parents parameter.

The pll really has only one parent, xin24m, so we should handle this
correctly in the code, instead of having 2 times xin24m in the parent
array coming from the clock controller.

>   pll_mux->flags = 0;
>   pll_mux->lock = >lock;
>   pll_mux->hw.init = 
> 
>   if (pll_type == pll_rk3036 ||
>   pll_type == pll_rk3066 ||
> + pll_type == pll_rk3328 ||
>   pll_type == pll_rk3399)
>   pll_mux->flags |= CLK_MUX_HIWORD_MASK;
> 
> @@ -929,6 +934,12 @@ struct clk *rockchip_clk_register_pll(struct
> rockchip_clk_provider *ctx, else
>   init.ops = _rk3066_pll_clk_ops;
>   break;
> + case pll_rk3328:
> + if (!pll->rate_table || IS_ERR(ctx->grf))
> + init.ops = _rk3036_pll_clk_norate_ops;
> + else
> + init.ops = _rk3036_pll_clk_ops;
> + break;

please don't duplicate the rk3036-ops assignment, when adding the
pll_rk3328 option to the rk3036 part suffices.

I'd think the pll-patch should look something like the
following (untested, so please test):
--- 8< -
Subject: [PATCH] clk: rockchip: add new pll-type for rk3328

The rk3328's pll and clock are similar with rk3036's,
it different with pll_mode_mask,there are different
control registers bit,
so these should be independent and separate from
the series of rk3328s.

Signed-off-by: Elaine Zhang 
Signed-off-by: Heiko Stuebner 
---
 drivers/clk/rockchip/clk-pll.c | 18 ++
 drivers/clk/rockchip/clk.h |  1 +
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 6ed6057..99ce483 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -29,6 +29,7 @@
 #define PLL_MODE_SLOW  0x0
 #define PLL_MODE_NORM  0x1
 #define PLL_MODE_DEEP  0x2
+#define PLL_RK3328_MODE_MASK   0x1
 
 struct rockchip_clk_pll {
struct clk_hw   hw;
@@ -848,8 +849,9 @@ struct clk *rockchip_clk_register_pll(struct 
rockchip_clk_provider *ctx,
struct clk *pll_clk, *mux_clk;
char pll_name[20];
 
-   if (num_parents != 2) {
-   pr_err("%s: needs two parent clocks\n", __func__);
+   if ((pll_type != pll_rk3328 && num_parents != 2) ||
+   (pll_type == pll_rk3328 && num_parents != 1)) {
+   pr_err("%s: missing parent clocks\n", __func__);
return ERR_PTR(-EINVAL);
}
 
@@ -865,13 +867,17 @@ struct clk *rockchip_clk_register_pll(struct 
rockchip_clk_provider *ctx,
pll_mux = >pll_mux;
pll_mux->reg = ctx->reg_base + mode_offset;
pll_mux->shift = mode_shift;
-   pll_mux->mask = PLL_MODE_MASK;
+   if (pll_type == pll_rk3328)
+   pll_mux->mask = PLL_RK3328_MODE_MASK;
+   else
+   pll_mux->mask = PLL_MODE_MASK;
pll_mux->flags = 0;
pll_mux->lock = 

Re: [PATCH v2 4/4] clk: rockchip: add new pll-type for rk3328

[Heiko Stuebner]

Hi Elaine,

Am Montag, 19. Dezember 2016, 09:56:13 CET schrieb Elaine Zhang:
> The rk3328's pll and clock are similar with rk3036's,
> it different with pll_mode_mask,there are different
> control registers bit,
> so these should be independent and separate from
> the series of rk3328s.

not sure I understand this description. In the patch (and TRM excerpt) I see
that the number of parents is down to only xin24m but the general handling is
similar to the rk3036 and thus reuses its operations.

The description makes it sound like there are operational differences (the
"different control register bit" part), so could you clarify this a bit
please?

Also, please move the pll addition before the addition of the clock-controller
in the series and move the pll-type addition also here from the controller
patch.

Some more below:

> 
> Signed-off-by: Elaine Zhang 
> ---
>  drivers/clk/rockchip/clk-pll.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
> index 6ed605776abd..9650c75f61d1 100644
> --- a/drivers/clk/rockchip/clk-pll.c
> +++ b/drivers/clk/rockchip/clk-pll.c
> @@ -29,6 +29,7 @@
>  #define PLL_MODE_SLOW0x0
>  #define PLL_MODE_NORM0x1
>  #define PLL_MODE_DEEP0x2
> +#define PLL_RK3328_MODE_MASK 0x1
> 
>  struct rockchip_clk_pll {
>   struct clk_hw   hw;
> @@ -865,13 +866,17 @@ struct clk *rockchip_clk_register_pll(struct
> rockchip_clk_provider *ctx, pll_mux = >pll_mux;
>   pll_mux->reg = ctx->reg_base + mode_offset;
>   pll_mux->shift = mode_shift;
> - pll_mux->mask = PLL_MODE_MASK;
> + if (pll_type == pll_rk3328)
> + pll_mux->mask = PLL_RK3328_MODE_MASK;
> + else
> + pll_mux->mask = PLL_MODE_MASK;

you're missing the other parts handling parents, like num_parents check
and the init.num_parents parameter.

The pll really has only one parent, xin24m, so we should handle this
correctly in the code, instead of having 2 times xin24m in the parent
array coming from the clock controller.

>   pll_mux->flags = 0;
>   pll_mux->lock = >lock;
>   pll_mux->hw.init = 
> 
>   if (pll_type == pll_rk3036 ||
>   pll_type == pll_rk3066 ||
> + pll_type == pll_rk3328 ||
>   pll_type == pll_rk3399)
>   pll_mux->flags |= CLK_MUX_HIWORD_MASK;
> 
> @@ -929,6 +934,12 @@ struct clk *rockchip_clk_register_pll(struct
> rockchip_clk_provider *ctx, else
>   init.ops = _rk3066_pll_clk_ops;
>   break;
> + case pll_rk3328:
> + if (!pll->rate_table || IS_ERR(ctx->grf))
> + init.ops = _rk3036_pll_clk_norate_ops;
> + else
> + init.ops = _rk3036_pll_clk_ops;
> + break;

please don't duplicate the rk3036-ops assignment, when adding the
pll_rk3328 option to the rk3036 part suffices.

I'd think the pll-patch should look something like the
following (untested, so please test):
--- 8< -
Subject: [PATCH] clk: rockchip: add new pll-type for rk3328

The rk3328's pll and clock are similar with rk3036's,
it different with pll_mode_mask,there are different
control registers bit,
so these should be independent and separate from
the series of rk3328s.

Signed-off-by: Elaine Zhang 
Signed-off-by: Heiko Stuebner 
---
 drivers/clk/rockchip/clk-pll.c | 18 ++
 drivers/clk/rockchip/clk.h |  1 +
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 6ed6057..99ce483 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -29,6 +29,7 @@
 #define PLL_MODE_SLOW  0x0
 #define PLL_MODE_NORM  0x1
 #define PLL_MODE_DEEP  0x2
+#define PLL_RK3328_MODE_MASK   0x1
 
 struct rockchip_clk_pll {
struct clk_hw   hw;
@@ -848,8 +849,9 @@ struct clk *rockchip_clk_register_pll(struct 
rockchip_clk_provider *ctx,
struct clk *pll_clk, *mux_clk;
char pll_name[20];
 
-   if (num_parents != 2) {
-   pr_err("%s: needs two parent clocks\n", __func__);
+   if ((pll_type != pll_rk3328 && num_parents != 2) ||
+   (pll_type == pll_rk3328 && num_parents != 1)) {
+   pr_err("%s: missing parent clocks\n", __func__);
return ERR_PTR(-EINVAL);
}
 
@@ -865,13 +867,17 @@ struct clk *rockchip_clk_register_pll(struct 
rockchip_clk_provider *ctx,
pll_mux = >pll_mux;
pll_mux->reg = ctx->reg_base + mode_offset;
pll_mux->shift = mode_shift;
-   pll_mux->mask = PLL_MODE_MASK;
+   if (pll_type == pll_rk3328)
+   pll_mux->mask = PLL_RK3328_MODE_MASK;
+   else
+   pll_mux->mask = PLL_MODE_MASK;
pll_mux->flags = 0;
pll_mux->lock = >lock;
pll_mux->hw.init = 
 
if (pll_type == 

Re: [v2 6/7] x86/traps: Fixup general protection faults caused by UMIP

[Andy Lutomirski]

On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri
 wrote:
> If the User-Mode Instruction Prevention CPU feature is available and
> enabled, a general protection fault will be issued if the instructions
> sgdt, sldt, sidt, str or smsw are executed from user-mode context
> (CPL > 0). If the fault was caused by any of the instructions protected
> by UMIP, fixup_umip_exceptino will emulate dummy results for these
> instructions.
>
> Cc: Andy Lutomirski 
> Cc: Andrew Morton 
> Cc: H. Peter Anvin 
> Cc: Borislav Petkov 
> Cc: Brian Gerst 
> Cc: Chen Yucong 
> Cc: Chris Metcalf 
> Cc: Dave Hansen 
> Cc: Fenghua Yu 
> Cc: Huang Rui 
> Cc: Jiri Slaby 
> Cc: Jonathan Corbet 
> Cc: Michael S. Tsirkin 
> Cc: Paul Gortmaker 
> Cc: Peter Zijlstra 
> Cc: Ravi V. Shankar 
> Cc: Shuah Khan 
> Cc: Vlastimil Babka 
> Cc: Tony Luck 
> Cc: Paolo Bonzini 
> Cc: Liang Z. Li 
> Cc: Alexandre Julliard 
> Cc: Stas Sergeev 
> Cc: x...@kernel.org
> Cc: linux-ms...@vger.kernel.org
> Signed-off-by: Ricardo Neri 
> ---
>  arch/x86/kernel/traps.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index bf0c6d0..5044fb3 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -64,6 +64,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #ifdef CONFIG_X86_64
>  #include 
> @@ -491,6 +492,9 @@ do_general_protection(struct pt_regs *regs, long 
> error_code)
> RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
> cond_local_irq_enable(regs);
>
> +   if (user_mode(regs) && !fixup_umip_exception(regs))
> +   return;
> +

I would do fixup_umip_exception(regs) == 0 to make it more obvious
what's going on.

Also, since you're allowing this in v8086 mode, I think this should
have an explicit test in
tools/testing/selftests/x86/entry_from_vm86.c.  I *think* it will work
fine, but the pt_regs handling in vm86 mode is quite scary and has
been rewritten recently.

Re: [v2 5/7] x86: Add emulation code for UMIP instructions

[Andy Lutomirski]

On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri
 wrote:
> The feature User-Mode Instruction Prevention present in recent Intel
> processor prevents a group of instructions from being executed with
> CPL > 0. Otherwise, a general protection fault is issued.
>
> Rather than relaying this fault to the user space (in the form of a SIGSEGV
> signal), the instructions protected by UMIP can be emulated to provide
> dummy results. This allows to conserve the current kernel behavior and not
> reveal the system resources that UMIP intends to protect (the global
> descriptor and interrupt descriptor tables, the segment selectors of the
> local descriptor table and the task state and the machine status word).
>
> This emulation is needed because certain applications (e.g., WineHQ) rely
> on this subset of instructions to function.
>
> The instructions protected by UMIP can be split in two groups. Those who
> return a kernel memory address (sgdt and sidt) and those who return a
> value (sldt, str and smsw).
>
> For the instructions that return a kernel memory address, the result is
> emulated as the location of a dummy variable in the kernel memory space.
> This is needed as applications such as WineHQ rely on the result being
> located in the kernel memory space function. The limit for the GDT and the
> IDT are set to zero.

Nak.  This is a trivial KASLR bypass.  Just give them hardcoded
values.  For x86_64, I would suggest 0xfffe and
0x.

>
> The instructions sldt and str return a segment selector relative to the
> base address of the global descriptor table. Since the actual address of
> such table is not revealed, it makes sense to emulate the result as zero.

Hmm, now I wonder if anything uses SLDT to see if there is an LDT.  If
so, we could emulate it better, but I doubt this matters.

>
> The instruction smsw is emulated to return zero.

If you're going to emulate it, please return something plausible.  The
protected mode bit should be on, for example.  0x33 is probably
reasonable.

> +static int __emulate_umip_insn(struct insn *insn, enum umip_insn umip_inst,
> +  unsigned char *data, int *data_size)
> +{
> +   unsigned long const *dummy_base_addr;
> +   unsigned short dummy_limit = 0;
> +   unsigned short dummy_value = 0;
> +
> +   switch (umip_inst) {
> +   /*
> +* These two instructions return the base address and limit of the
> +* global and interrupt descriptor table. The base address can be
> +* 32-bit or 64-bit. Limit is always 16-bit.
> +*/
> +   case UMIP_SGDT:
> +   case UMIP_SIDT:
> +   if (umip_inst == UMIP_SGDT)
> +   dummy_base_addr = _dummy_gdt_base;
> +   else
> +   dummy_base_addr = _dummy_idt_base;
> +   if (X86_MODRM_MOD(insn->modrm.value) == 3) {
> +   WARN_ONCE(1, "SGDT cannot take register as 
> argument!\n");

No warnings please.

> +int fixup_umip_exception(struct pt_regs *regs)
> +{
> +   struct insn insn;
> +   unsigned char buf[MAX_INSN_SIZE];
> +   /* 10 bytes is the maximum size of the result of UMIP instructions */
> +   unsigned char dummy_data[10] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
> +   int x86_64 = !test_thread_flag(TIF_IA32);

user_64bit_mode(regs)

> +   int not_copied, nr_copied, reg_offset, dummy_data_size;
> +   void __user *uaddr;
> +   unsigned long *reg_addr;
> +   enum umip_insn umip_inst;
> +
> +   not_copied = copy_from_user(buf, (void __user *)regs->ip, 
> sizeof(buf));

This is slightly wrong due to PKRU.  I doubt we care.

> +   nr_copied = sizeof(buf) - not_copied;
> +   /*
> +* The decoder _should_ fail nicely if we pass it a short buffer.
> +* But, let's not depend on that implementation detail.  If we
> +* did not get anything, just error out now.
> +*/
> +   if (!nr_copied)
> +   return -EFAULT;

If the caller cares about EINVAL vs EFAULT, it cares because it is
considering changing the signal to a fake page fault.  If so, then
this should be EINVAL -- failure to read the text should just prevent
emulation.

> +   insn_init(, buf, nr_copied, x86_64);
> +   insn_get_length();
> +   if (nr_copied < insn.length)
> +   return -EFAULT;

Ditto.

> +
> +   umip_inst = __identify_insn();
> +   /* Check if we found an instruction protected by UMIP */
> +   if (umip_inst < 0)
> +   return -EINVAL;
> +
> +   if (__emulate_umip_insn(, umip_inst, dummy_data, 
> _data_size))
> +   return -EINVAL;
> +
> +   /* If operand is a register, write directly to it */
> +   if (X86_MODRM_MOD(insn.modrm.value) == 3) {
> +   reg_offset = get_reg_offset_rm(, regs);
> +   reg_addr = (unsigned long *)((unsigned long)regs + 
> reg_offset);
> +  

Re: [v2 6/7] x86/traps: Fixup general protection faults caused by UMIP

[Andy Lutomirski]

On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri
 wrote:
> If the User-Mode Instruction Prevention CPU feature is available and
> enabled, a general protection fault will be issued if the instructions
> sgdt, sldt, sidt, str or smsw are executed from user-mode context
> (CPL > 0). If the fault was caused by any of the instructions protected
> by UMIP, fixup_umip_exceptino will emulate dummy results for these
> instructions.
>
> Cc: Andy Lutomirski 
> Cc: Andrew Morton 
> Cc: H. Peter Anvin 
> Cc: Borislav Petkov 
> Cc: Brian Gerst 
> Cc: Chen Yucong 
> Cc: Chris Metcalf 
> Cc: Dave Hansen 
> Cc: Fenghua Yu 
> Cc: Huang Rui 
> Cc: Jiri Slaby 
> Cc: Jonathan Corbet 
> Cc: Michael S. Tsirkin 
> Cc: Paul Gortmaker 
> Cc: Peter Zijlstra 
> Cc: Ravi V. Shankar 
> Cc: Shuah Khan 
> Cc: Vlastimil Babka 
> Cc: Tony Luck 
> Cc: Paolo Bonzini 
> Cc: Liang Z. Li 
> Cc: Alexandre Julliard 
> Cc: Stas Sergeev 
> Cc: x...@kernel.org
> Cc: linux-ms...@vger.kernel.org
> Signed-off-by: Ricardo Neri 
> ---
>  arch/x86/kernel/traps.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index bf0c6d0..5044fb3 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -64,6 +64,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #ifdef CONFIG_X86_64
>  #include 
> @@ -491,6 +492,9 @@ do_general_protection(struct pt_regs *regs, long 
> error_code)
> RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
> cond_local_irq_enable(regs);
>
> +   if (user_mode(regs) && !fixup_umip_exception(regs))
> +   return;
> +

I would do fixup_umip_exception(regs) == 0 to make it more obvious
what's going on.

Also, since you're allowing this in v8086 mode, I think this should
have an explicit test in
tools/testing/selftests/x86/entry_from_vm86.c.  I *think* it will work
fine, but the pt_regs handling in vm86 mode is quite scary and has
been rewritten recently.

Re: [v2 5/7] x86: Add emulation code for UMIP instructions

[Andy Lutomirski]

On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri
 wrote:
> The feature User-Mode Instruction Prevention present in recent Intel
> processor prevents a group of instructions from being executed with
> CPL > 0. Otherwise, a general protection fault is issued.
>
> Rather than relaying this fault to the user space (in the form of a SIGSEGV
> signal), the instructions protected by UMIP can be emulated to provide
> dummy results. This allows to conserve the current kernel behavior and not
> reveal the system resources that UMIP intends to protect (the global
> descriptor and interrupt descriptor tables, the segment selectors of the
> local descriptor table and the task state and the machine status word).
>
> This emulation is needed because certain applications (e.g., WineHQ) rely
> on this subset of instructions to function.
>
> The instructions protected by UMIP can be split in two groups. Those who
> return a kernel memory address (sgdt and sidt) and those who return a
> value (sldt, str and smsw).
>
> For the instructions that return a kernel memory address, the result is
> emulated as the location of a dummy variable in the kernel memory space.
> This is needed as applications such as WineHQ rely on the result being
> located in the kernel memory space function. The limit for the GDT and the
> IDT are set to zero.

Nak.  This is a trivial KASLR bypass.  Just give them hardcoded
values.  For x86_64, I would suggest 0xfffe and
0x.

>
> The instructions sldt and str return a segment selector relative to the
> base address of the global descriptor table. Since the actual address of
> such table is not revealed, it makes sense to emulate the result as zero.

Hmm, now I wonder if anything uses SLDT to see if there is an LDT.  If
so, we could emulate it better, but I doubt this matters.

>
> The instruction smsw is emulated to return zero.

If you're going to emulate it, please return something plausible.  The
protected mode bit should be on, for example.  0x33 is probably
reasonable.

> +static int __emulate_umip_insn(struct insn *insn, enum umip_insn umip_inst,
> +  unsigned char *data, int *data_size)
> +{
> +   unsigned long const *dummy_base_addr;
> +   unsigned short dummy_limit = 0;
> +   unsigned short dummy_value = 0;
> +
> +   switch (umip_inst) {
> +   /*
> +* These two instructions return the base address and limit of the
> +* global and interrupt descriptor table. The base address can be
> +* 32-bit or 64-bit. Limit is always 16-bit.
> +*/
> +   case UMIP_SGDT:
> +   case UMIP_SIDT:
> +   if (umip_inst == UMIP_SGDT)
> +   dummy_base_addr = _dummy_gdt_base;
> +   else
> +   dummy_base_addr = _dummy_idt_base;
> +   if (X86_MODRM_MOD(insn->modrm.value) == 3) {
> +   WARN_ONCE(1, "SGDT cannot take register as 
> argument!\n");

No warnings please.

> +int fixup_umip_exception(struct pt_regs *regs)
> +{
> +   struct insn insn;
> +   unsigned char buf[MAX_INSN_SIZE];
> +   /* 10 bytes is the maximum size of the result of UMIP instructions */
> +   unsigned char dummy_data[10] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
> +   int x86_64 = !test_thread_flag(TIF_IA32);

user_64bit_mode(regs)

> +   int not_copied, nr_copied, reg_offset, dummy_data_size;
> +   void __user *uaddr;
> +   unsigned long *reg_addr;
> +   enum umip_insn umip_inst;
> +
> +   not_copied = copy_from_user(buf, (void __user *)regs->ip, 
> sizeof(buf));

This is slightly wrong due to PKRU.  I doubt we care.

> +   nr_copied = sizeof(buf) - not_copied;
> +   /*
> +* The decoder _should_ fail nicely if we pass it a short buffer.
> +* But, let's not depend on that implementation detail.  If we
> +* did not get anything, just error out now.
> +*/
> +   if (!nr_copied)
> +   return -EFAULT;

If the caller cares about EINVAL vs EFAULT, it cares because it is
considering changing the signal to a fake page fault.  If so, then
this should be EINVAL -- failure to read the text should just prevent
emulation.

> +   insn_init(, buf, nr_copied, x86_64);
> +   insn_get_length();
> +   if (nr_copied < insn.length)
> +   return -EFAULT;

Ditto.

> +
> +   umip_inst = __identify_insn();
> +   /* Check if we found an instruction protected by UMIP */
> +   if (umip_inst < 0)
> +   return -EINVAL;
> +
> +   if (__emulate_umip_insn(, umip_inst, dummy_data, 
> _data_size))
> +   return -EINVAL;
> +
> +   /* If operand is a register, write directly to it */
> +   if (X86_MODRM_MOD(insn.modrm.value) == 3) {
> +   reg_offset = get_reg_offset_rm(, regs);
> +   reg_addr = (unsigned long *)((unsigned long)regs + 
> reg_offset);
> +   memcpy(reg_addr, dummy_data, 

Re: [v2 1/7] x86/mpx: Do not use SIB index if index points to R/ESP

[Andy Lutomirski]

On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri
 wrote:
> Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
> Developer's Manual volume 2A states that when memory addressing is used
> (i.e., mod part of ModR/M is not 3), a SIB byte is used and the index of
> the SIB byte points to the R/ESP (i.e.,index = 4), the index should not be
> used in the computation of the memory address.
>
> An example of such instruction could be
>
> insn -0x80(%rsp)
>
> This is represented as:
>
>  [opcode] 4c 24 80
>
>   ModR/M: mod: 1, reg: 1: r/m: 4 (R/ESP)
>   SIB 24: sc: 0, index: 100 (R/ESP), base(R/ESP): 100
>   Displacement -0x80
>
> The correct address is (base) + displacement; no index is used.
>
> Care is taken to allow R12 to be used as index, which is a valid scenario.

Since I have no idea what this patch has to do with the rest of the
series, I'll ask a question:

Why isn't this code in the standard x86 instruction decoder?  Is the
decoder similarly buggy?

Re: [v2 1/7] x86/mpx: Do not use SIB index if index points to R/ESP

[Andy Lutomirski]

On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri
 wrote:
> Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
> Developer's Manual volume 2A states that when memory addressing is used
> (i.e., mod part of ModR/M is not 3), a SIB byte is used and the index of
> the SIB byte points to the R/ESP (i.e.,index = 4), the index should not be
> used in the computation of the memory address.
>
> An example of such instruction could be
>
> insn -0x80(%rsp)
>
> This is represented as:
>
>  [opcode] 4c 24 80
>
>   ModR/M: mod: 1, reg: 1: r/m: 4 (R/ESP)
>   SIB 24: sc: 0, index: 100 (R/ESP), base(R/ESP): 100
>   Displacement -0x80
>
> The correct address is (base) + displacement; no index is used.
>
> Care is taken to allow R12 to be used as index, which is a valid scenario.

Since I have no idea what this patch has to do with the rest of the
series, I'll ask a question:

Why isn't this code in the standard x86 instruction decoder?  Is the
decoder similarly buggy?

Re: [v2 2/7] x86/mpx: Fail when implicit zero-displacement is used along with R/EBP

[Andy Lutomirski]

On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri
 wrote:
> Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
> Developer's Manual volume 2A states that when memory addressing with no
> explicit displacement (i.e, mod part of ModR/M is 0), a SIB byte is used
> and the base of the SIB byte points to (R/EBP) (i.e., base = 5), an
> explicit displacement of 0 must be used.
>
> Make the address decoder to return -EINVAL in such a case.
>
> Cc: Dave Hansen 
> Cc: Adam Buchbinder 
> Cc: Colin Ian King 
> Cc: Lorenzo Stoakes 
> Cc: Qiaowei Ren 
> Cc: Ravi V. Shankar 
> Cc: x...@kernel.org
> Signed-off-by: Ricardo Neri 
> ---
>  arch/x86/mm/mpx.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
> index 6a75a75..71681d0 100644
> --- a/arch/x86/mm/mpx.c
> +++ b/arch/x86/mm/mpx.c
> @@ -120,6 +120,13 @@ static int get_reg_offset(struct insn *insn, struct 
> pt_regs *regs,
>
> case REG_TYPE_BASE:
> regno = X86_SIB_BASE(insn->sib.value);
> +   if (regno == 5 && X86_MODRM_RM(insn->modrm.value) == 0) {
> +   WARN_ONCE(1, "An explicit displacement is required 
> when %sBP used as SIB base.",
> + (IS_ENABLED(CONFIG_X86_64) && insn->x86_64) 
> ?
> + "R13 or R" : "E");
> +   return -EINVAL;
> +   }
> +

Now that I've read the cover letter, I see what's going on.  This
should not warn -- user code can easily trigger this deliberately.

Re: [v2 2/7] x86/mpx: Fail when implicit zero-displacement is used along with R/EBP

[Andy Lutomirski]

On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri
 wrote:
> Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
> Developer's Manual volume 2A states that when memory addressing with no
> explicit displacement (i.e, mod part of ModR/M is 0), a SIB byte is used
> and the base of the SIB byte points to (R/EBP) (i.e., base = 5), an
> explicit displacement of 0 must be used.
>
> Make the address decoder to return -EINVAL in such a case.
>
> Cc: Dave Hansen 
> Cc: Adam Buchbinder 
> Cc: Colin Ian King 
> Cc: Lorenzo Stoakes 
> Cc: Qiaowei Ren 
> Cc: Ravi V. Shankar 
> Cc: x...@kernel.org
> Signed-off-by: Ricardo Neri 
> ---
>  arch/x86/mm/mpx.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
> index 6a75a75..71681d0 100644
> --- a/arch/x86/mm/mpx.c
> +++ b/arch/x86/mm/mpx.c
> @@ -120,6 +120,13 @@ static int get_reg_offset(struct insn *insn, struct 
> pt_regs *regs,
>
> case REG_TYPE_BASE:
> regno = X86_SIB_BASE(insn->sib.value);
> +   if (regno == 5 && X86_MODRM_RM(insn->modrm.value) == 0) {
> +   WARN_ONCE(1, "An explicit displacement is required 
> when %sBP used as SIB base.",
> + (IS_ENABLED(CONFIG_X86_64) && insn->x86_64) 
> ?
> + "R13 or R" : "E");
> +   return -EINVAL;
> +   }
> +

Now that I've read the cover letter, I see what's going on.  This
should not warn -- user code can easily trigger this deliberately.

[PATCH] adc: add adc driver for Hisilicon BVT SOCs

[Allen Liu]

Add ADC driver for the ADC controller found on HiSilicon BVT SOCs, like 
Hi3516CV300, etc.
The ADC controller is primarily in charge of detecting voltage.

Reviewed-by: Jiancheng Xue 
Signed-off-by: Allen Liu 
---
 .../devicetree/bindings/iio/adc/hibvt-lsadc.txt|  26 ++
 drivers/iio/adc/Kconfig|  10 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/hibvt_lsadc.c  | 344 +
 4 files changed, 381 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt
 create mode 100644 drivers/iio/adc/hibvt_lsadc.c

diff --git a/Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt 
b/Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt
new file mode 100644
index 000..63de46e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt
@@ -0,0 +1,26 @@
+Hisilicon BVT Low Speed (LS) A/D Converter bindings
+
+Required properties:
+- compatible: should be "hisilicon,-lsadc"
+   - "hisilicon,hibvt-lsadc": for hi3516cv300
+
+- reg: physical base address of the controller and length of memory mapped
+   region.
+- interrupts: The interrupt number to the cpu. The interrupt specifier format
+  depends on the interrupt controller.
+- #io-channel-cells: Should be 1, see ../iio-bindings.txt
+
+Optional properties:
+- resets: Must contain an entry for each entry in reset-names if need support
+ this option. See ../reset/reset.txt for details.
+- reset-names: Must include the name "saradc-apb".
+
+Example:
+   lsadc: hibvt-lsadc@120e {
+   compatible = "hisilicon,hibvt-lsadc";
+   reg = <0x120e 0x1000>;
+   interrupts = <19>;
+   resets = < 0x7c 3>;
+   reset-names = "lsadc-crg";
+   status = "disabled";
+   };
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 99c0514..0443f51 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -225,6 +225,16 @@ config HI8435
  This driver can also be built as a module. If so, the module will be
  called hi8435.
 
+config HIBVT_LSADC
+   tristate "HIBVT LSADC driver"
+   depends on ARCH_HISI || COMPILE_TEST
+   help
+ Say yes here to build support for the LSADC found in SoCs from
+ hisilicon BVT chip.
+
+ To compile this driver as a module, choose M here: the
+ module will be called hibvt_lsadc.
+
 config INA2XX_ADC
tristate "Texas Instruments INA2xx Power Monitors IIO driver"
depends on I2C && !SENSORS_INA2XX
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 7a40c04..6554d92 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
 obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
 obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
 obj-$(CONFIG_HI8435) += hi8435.o
+obj-$(CONFIG_HIBVT_LSADC) += hibvt_lsadc.o
 obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
 obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
 obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
diff --git a/drivers/iio/adc/hibvt_lsadc.c b/drivers/iio/adc/hibvt_lsadc.c
new file mode 100644
index 000..a20afe8
--- /dev/null
+++ b/drivers/iio/adc/hibvt_lsadc.c
@@ -0,0 +1,344 @@
+/*
+ * Hisilicon BVT Low Speed (LS) A/D Converter
+ * Copyright (C) 2016 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* hisilicon bvt adc registers definitions */
+#define LSADC_CONFIG   0x00
+#define CONFIG_DEGLITCHBIT(17)
+#define CONFIG_RESET   BIT(15)
+#define CONFIG_POWERDOWN   BIT(14)
+#define CONFIG_MODEBIT(13)
+#define CONFIG_CHC_VALID   BIT(10)
+#define CONFIG_CHB_VALID   BIT(9)
+#define CONFIG_CHA_VALID   BIT(8)
+
+#define LSADC_TIMESCAN 0x08
+#define LSADC_INTEN0x10
+#define LSADC_INTSTATUS0x14
+#define LSADC_INTCLR   0x18
+#define LSADC_START0x1C
+#define LSADC_STOP 0x20
+#define LSADC_ACTBIT   0x24
+#define LSADC_CHNDATA  0x2C
+
+#define ADC_CON_EN (1u << 0)
+#define ADC_CON_DEN

[PATCH] adc: add adc driver for Hisilicon BVT SOCs

[Allen Liu]

Add ADC driver for the ADC controller found on HiSilicon BVT SOCs, like 
Hi3516CV300, etc.
The ADC controller is primarily in charge of detecting voltage.

Reviewed-by: Jiancheng Xue 
Signed-off-by: Allen Liu 
---
 .../devicetree/bindings/iio/adc/hibvt-lsadc.txt|  26 ++
 drivers/iio/adc/Kconfig|  10 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/hibvt_lsadc.c  | 344 +
 4 files changed, 381 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt
 create mode 100644 drivers/iio/adc/hibvt_lsadc.c

diff --git a/Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt 
b/Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt
new file mode 100644
index 000..63de46e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/hibvt-lsadc.txt
@@ -0,0 +1,26 @@
+Hisilicon BVT Low Speed (LS) A/D Converter bindings
+
+Required properties:
+- compatible: should be "hisilicon,-lsadc"
+   - "hisilicon,hibvt-lsadc": for hi3516cv300
+
+- reg: physical base address of the controller and length of memory mapped
+   region.
+- interrupts: The interrupt number to the cpu. The interrupt specifier format
+  depends on the interrupt controller.
+- #io-channel-cells: Should be 1, see ../iio-bindings.txt
+
+Optional properties:
+- resets: Must contain an entry for each entry in reset-names if need support
+ this option. See ../reset/reset.txt for details.
+- reset-names: Must include the name "saradc-apb".
+
+Example:
+   lsadc: hibvt-lsadc@120e {
+   compatible = "hisilicon,hibvt-lsadc";
+   reg = <0x120e 0x1000>;
+   interrupts = <19>;
+   resets = < 0x7c 3>;
+   reset-names = "lsadc-crg";
+   status = "disabled";
+   };
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 99c0514..0443f51 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -225,6 +225,16 @@ config HI8435
  This driver can also be built as a module. If so, the module will be
  called hi8435.
 
+config HIBVT_LSADC
+   tristate "HIBVT LSADC driver"
+   depends on ARCH_HISI || COMPILE_TEST
+   help
+ Say yes here to build support for the LSADC found in SoCs from
+ hisilicon BVT chip.
+
+ To compile this driver as a module, choose M here: the
+ module will be called hibvt_lsadc.
+
 config INA2XX_ADC
tristate "Texas Instruments INA2xx Power Monitors IIO driver"
depends on I2C && !SENSORS_INA2XX
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 7a40c04..6554d92 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
 obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
 obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
 obj-$(CONFIG_HI8435) += hi8435.o
+obj-$(CONFIG_HIBVT_LSADC) += hibvt_lsadc.o
 obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
 obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
 obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
diff --git a/drivers/iio/adc/hibvt_lsadc.c b/drivers/iio/adc/hibvt_lsadc.c
new file mode 100644
index 000..a20afe8
--- /dev/null
+++ b/drivers/iio/adc/hibvt_lsadc.c
@@ -0,0 +1,344 @@
+/*
+ * Hisilicon BVT Low Speed (LS) A/D Converter
+ * Copyright (C) 2016 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* hisilicon bvt adc registers definitions */
+#define LSADC_CONFIG   0x00
+#define CONFIG_DEGLITCHBIT(17)
+#define CONFIG_RESET   BIT(15)
+#define CONFIG_POWERDOWN   BIT(14)
+#define CONFIG_MODEBIT(13)
+#define CONFIG_CHC_VALID   BIT(10)
+#define CONFIG_CHB_VALID   BIT(9)
+#define CONFIG_CHA_VALID   BIT(8)
+
+#define LSADC_TIMESCAN 0x08
+#define LSADC_INTEN0x10
+#define LSADC_INTSTATUS0x14
+#define LSADC_INTCLR   0x18
+#define LSADC_START0x1C
+#define LSADC_STOP 0x20
+#define LSADC_ACTBIT   0x24
+#define LSADC_CHNDATA  0x2C
+
+#define ADC_CON_EN (1u << 0)
+#define ADC_CON_DEN(0u << 0)
+
+#define ADC_NUM_BITS   10

[v2 2/7] x86/mpx: Fail when implicit zero-displacement is used along with R/EBP

[Ricardo Neri]

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
Developer's Manual volume 2A states that when memory addressing with no
explicit displacement (i.e, mod part of ModR/M is 0), a SIB byte is used
and the base of the SIB byte points to (R/EBP) (i.e., base = 5), an
explicit displacement of 0 must be used.

Make the address decoder to return -EINVAL in such a case.

Cc: Dave Hansen 
Cc: Adam Buchbinder 
Cc: Colin Ian King 
Cc: Lorenzo Stoakes 
Cc: Qiaowei Ren 
Cc: Ravi V. Shankar 
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri 
---
 arch/x86/mm/mpx.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
index 6a75a75..71681d0 100644
--- a/arch/x86/mm/mpx.c
+++ b/arch/x86/mm/mpx.c
@@ -120,6 +120,13 @@ static int get_reg_offset(struct insn *insn, struct 
pt_regs *regs,
 
case REG_TYPE_BASE:
regno = X86_SIB_BASE(insn->sib.value);
+   if (regno == 5 && X86_MODRM_RM(insn->modrm.value) == 0) {
+   WARN_ONCE(1, "An explicit displacement is required when 
%sBP used as SIB base.",
+ (IS_ENABLED(CONFIG_X86_64) && insn->x86_64) ?
+ "R13 or R" : "E");
+   return -EINVAL;
+   }
+
if (X86_REX_B(insn->rex_prefix.value))
regno += 8;
break;
-- 
2.9.3

[v2 1/7] x86/mpx: Do not use SIB index if index points to R/ESP

[Ricardo Neri]

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
Developer's Manual volume 2A states that when memory addressing is used
(i.e., mod part of ModR/M is not 3), a SIB byte is used and the index of
the SIB byte points to the R/ESP (i.e.,index = 4), the index should not be
used in the computation of the memory address.

An example of such instruction could be

insn -0x80(%rsp)

This is represented as:

 [opcode] 4c 24 80

  ModR/M: mod: 1, reg: 1: r/m: 4 (R/ESP)
  SIB 24: sc: 0, index: 100 (R/ESP), base(R/ESP): 100
  Displacement -0x80

The correct address is (base) + displacement; no index is used.

Care is taken to allow R12 to be used as index, which is a valid scenario.

Cc: Dave Hansen 
Cc: Adam Buchbinder 
Cc: Colin Ian King 
Cc: Lorenzo Stoakes 
Cc: Qiaowei Ren 
Cc: Ravi V. Shankar 
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri 
---
 arch/x86/mm/mpx.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
index 324e571..6a75a75 100644
--- a/arch/x86/mm/mpx.c
+++ b/arch/x86/mm/mpx.c
@@ -109,6 +109,13 @@ static int get_reg_offset(struct insn *insn, struct 
pt_regs *regs,
regno = X86_SIB_INDEX(insn->sib.value);
if (X86_REX_X(insn->rex_prefix.value))
regno += 8;
+   /*
+* If mod !=3, SP is not used as index. Check is done after
+* looking at REX.X This is because R12 can be used as an
+* index.
+*/
+   if (regno == 4 && X86_MODRM_RM(insn->modrm.value) != 3)
+   return 0;
break;
 
case REG_TYPE_BASE:
@@ -161,7 +168,10 @@ static void __user *mpx_get_addr_ref(struct insn *insn, 
struct pt_regs *regs)
goto out_err;
 
base = regs_get_register(regs, base_offset);
-   indx = regs_get_register(regs, indx_offset);
+   if (indx_offset)
+   indx = regs_get_register(regs, indx_offset);
+   else
+   indx = 0;
addr = base + indx * (1 << X86_SIB_SCALE(sib));
} else {
addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM);
-- 
2.9.3

[v2 2/7] x86/mpx: Fail when implicit zero-displacement is used along with R/EBP

[Ricardo Neri]

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
Developer's Manual volume 2A states that when memory addressing with no
explicit displacement (i.e, mod part of ModR/M is 0), a SIB byte is used
and the base of the SIB byte points to (R/EBP) (i.e., base = 5), an
explicit displacement of 0 must be used.

Make the address decoder to return -EINVAL in such a case.

Cc: Dave Hansen 
Cc: Adam Buchbinder 
Cc: Colin Ian King 
Cc: Lorenzo Stoakes 
Cc: Qiaowei Ren 
Cc: Ravi V. Shankar 
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri 
---
 arch/x86/mm/mpx.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
index 6a75a75..71681d0 100644
--- a/arch/x86/mm/mpx.c
+++ b/arch/x86/mm/mpx.c
@@ -120,6 +120,13 @@ static int get_reg_offset(struct insn *insn, struct 
pt_regs *regs,
 
case REG_TYPE_BASE:
regno = X86_SIB_BASE(insn->sib.value);
+   if (regno == 5 && X86_MODRM_RM(insn->modrm.value) == 0) {
+   WARN_ONCE(1, "An explicit displacement is required when 
%sBP used as SIB base.",
+ (IS_ENABLED(CONFIG_X86_64) && insn->x86_64) ?
+ "R13 or R" : "E");
+   return -EINVAL;
+   }
+
if (X86_REX_B(insn->rex_prefix.value))
regno += 8;
break;
-- 
2.9.3

[v2 1/7] x86/mpx: Do not use SIB index if index points to R/ESP

[Ricardo Neri]

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
Developer's Manual volume 2A states that when memory addressing is used
(i.e., mod part of ModR/M is not 3), a SIB byte is used and the index of
the SIB byte points to the R/ESP (i.e.,index = 4), the index should not be
used in the computation of the memory address.

An example of such instruction could be

insn -0x80(%rsp)

This is represented as:

 [opcode] 4c 24 80

  ModR/M: mod: 1, reg: 1: r/m: 4 (R/ESP)
  SIB 24: sc: 0, index: 100 (R/ESP), base(R/ESP): 100
  Displacement -0x80

The correct address is (base) + displacement; no index is used.

Care is taken to allow R12 to be used as index, which is a valid scenario.

Cc: Dave Hansen 
Cc: Adam Buchbinder 
Cc: Colin Ian King 
Cc: Lorenzo Stoakes 
Cc: Qiaowei Ren 
Cc: Ravi V. Shankar 
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri 
---
 arch/x86/mm/mpx.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
index 324e571..6a75a75 100644
--- a/arch/x86/mm/mpx.c
+++ b/arch/x86/mm/mpx.c
@@ -109,6 +109,13 @@ static int get_reg_offset(struct insn *insn, struct 
pt_regs *regs,
regno = X86_SIB_INDEX(insn->sib.value);
if (X86_REX_X(insn->rex_prefix.value))
regno += 8;
+   /*
+* If mod !=3, SP is not used as index. Check is done after
+* looking at REX.X This is because R12 can be used as an
+* index.
+*/
+   if (regno == 4 && X86_MODRM_RM(insn->modrm.value) != 3)
+   return 0;
break;
 
case REG_TYPE_BASE:
@@ -161,7 +168,10 @@ static void __user *mpx_get_addr_ref(struct insn *insn, 
struct pt_regs *regs)
goto out_err;
 
base = regs_get_register(regs, base_offset);
-   indx = regs_get_register(regs, indx_offset);
+   if (indx_offset)
+   indx = regs_get_register(regs, indx_offset);
+   else
+   indx = 0;
addr = base + indx * (1 << X86_SIB_SCALE(sib));
} else {
addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM);
-- 
2.9.3

[v2 5/7] x86: Add emulation code for UMIP instructions

[Ricardo Neri]

The feature User-Mode Instruction Prevention present in recent Intel
processor prevents a group of instructions from being executed with
CPL > 0. Otherwise, a general protection fault is issued.

Rather than relaying this fault to the user space (in the form of a SIGSEGV
signal), the instructions protected by UMIP can be emulated to provide
dummy results. This allows to conserve the current kernel behavior and not
reveal the system resources that UMIP intends to protect (the global
descriptor and interrupt descriptor tables, the segment selectors of the
local descriptor table and the task state and the machine status word).

This emulation is needed because certain applications (e.g., WineHQ) rely
on this subset of instructions to function.

The instructions protected by UMIP can be split in two groups. Those who
return a kernel memory address (sgdt and sidt) and those who return a
value (sldt, str and smsw).

For the instructions that return a kernel memory address, the result is
emulated as the location of a dummy variable in the kernel memory space.
This is needed as applications such as WineHQ rely on the result being
located in the kernel memory space function. The limit for the GDT and the
IDT are set to zero.

The instructions sldt and str return a segment selector relative to the
base address of the global descriptor table. Since the actual address of
such table is not revealed, it makes sense to emulate the result as zero.

The instruction smsw is emulated to return zero.

Cc: Andy Lutomirski 
Cc: Andrew Morton 
Cc: H. Peter Anvin 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Chen Yucong 
Cc: Chris Metcalf 
Cc: Dave Hansen 
Cc: Fenghua Yu 
Cc: Huang Rui 
Cc: Jiri Slaby 
Cc: Jonathan Corbet 
Cc: Michael S. Tsirkin 
Cc: Paul Gortmaker 
Cc: Peter Zijlstra 
Cc: Ravi V. Shankar 
Cc: Shuah Khan 
Cc: Vlastimil Babka 
Cc: Tony Luck 
Cc: Paolo Bonzini 
Cc: Liang Z. Li 
Cc: Alexandre Julliard 
Cc: Stas Sergeev 
Cc: x...@kernel.org
Cc: linux-ms...@vger.kernel.org
Signed-off-by: Ricardo Neri 
---
 arch/x86/include/asm/umip.h |  16 +
 arch/x86/kernel/Makefile|   1 +
 arch/x86/kernel/umip.c  | 170 
 3 files changed, 187 insertions(+)
 create mode 100644 arch/x86/include/asm/umip.h
 create mode 100644 arch/x86/kernel/umip.c

diff --git a/arch/x86/include/asm/umip.h b/arch/x86/include/asm/umip.h
new file mode 100644
index 000..7bcaca6
--- /dev/null
+++ b/arch/x86/include/asm/umip.h
@@ -0,0 +1,16 @@
+#ifndef _ASM_X86_UMIP_H
+#define _ASM_X86_UMIP_H
+
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_X86_INTEL_UMIP
+int fixup_umip_exception(struct pt_regs *regs);
+#else
+static inline int fixup_umip_exception(struct pt_regs *regs)
+{
+   return -EINVAL;
+}
+#endif  /* CONFIG_X86_INTEL_UMIP */
+#endif  /* _ASM_X86_UMIP_H */
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 581386c..c4aec02 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -124,6 +124,7 @@ obj-$(CONFIG_EFI)   += sysfb_efi.o
 obj-$(CONFIG_PERF_EVENTS)  += perf_regs.o
 obj-$(CONFIG_TRACING)  += tracepoint.o
 obj-$(CONFIG_SCHED_MC_PRIO)+= itmt.o
+obj-$(CONFIG_X86_INTEL_UMIP)   += umip.o
 
 ifdef CONFIG_FRAME_POINTER
 obj-y  += unwind_frame.o
diff --git a/arch/x86/kernel/umip.c b/arch/x86/kernel/umip.c
new file mode 100644
index 000..a104aea
--- /dev/null
+++ b/arch/x86/kernel/umip.c
@@ -0,0 +1,170 @@
+/*
+ * umip.c Emulation for instruction protected by the Intel User-Mode
+ * Instruction Prevention. The instructions are:
+ *sgdt
+ *sldt
+ *sidt
+ *str
+ *smsw
+ *
+ * Copyright (c) 2016, Intel Corporation.
+ * Ricardo Neri 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The address of this dummy values need to be readable by
+ * the user space
+ */
+
+static const long umip_dummy_gdt_base;
+static const long umip_dummy_idt_base;
+
+enum umip_insn {
+   UMIP_SGDT = 0,  /* opcode 0f 01 ModR/M reg 0 */
+   UMIP_SIDT,  /* opcode 0f 01 ModR/M reg 1 */
+   UMIP_SLDT,  /* opcode 0f 00 ModR/M reg 0 */
+   UMIP_SMSW,  /* opcode 0f 01 ModR/M reg 4 */
+   UMIP_STR,   /* opcode 0f 00 ModR/M reg 1 */
+};
+
+static int __identify_insn(struct insn *insn)
+{
+   /* by getting modrm we also get the opcode */
+   

[v2 7/7] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

User_mode Instruction Prevention (UMIP) is enabled by setting/clearing a
bit in %cr4.

It makes sense to enable UMIP at some point while booting, before user
spaces come up. Like SMAP and SMEP, is not critical to have it enabled
very early during boot. This is because UMIP is relevant only when there is
a userspace to be protected from. Given the similarities in relevance, it
makes sense to enable UMIP along with SMAP and SMEP.

UMIP is enabled by default. It can be disabled by adding clearcpuid=514
to the kernel parameters.

Cc: Andy Lutomirski 
Cc: Andrew Morton 
Cc: H. Peter Anvin 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Chen Yucong 
Cc: Chris Metcalf 
Cc: Dave Hansen 
Cc: Fenghua Yu 
Cc: Huang Rui 
Cc: Jiri Slaby 
Cc: Jonathan Corbet 
Cc: Michael S. Tsirkin 
Cc: Paul Gortmaker 
Cc: Peter Zijlstra 
Cc: Ravi V. Shankar 
Cc: Shuah Khan 
Cc: Vlastimil Babka 
Cc: Tony Luck 
Cc: Paolo Bonzini 
Cc: Liang Z. Li 
Cc: Alexandre Julliard 
Cc: Stas Sergeev 
Cc: x...@kernel.org
Cc: linux-ms...@vger.kernel.org
Signed-off-by: Ricardo Neri 
---
 arch/x86/Kconfig | 10 ++
 arch/x86/kernel/cpu/common.c | 16 +++-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e487493..bae1a8f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1733,6 +1733,16 @@ config X86_SMAP
 
  If unsure, say Y.
 
+config X86_INTEL_UMIP
+   def_bool y
+   depends on CPU_SUP_INTEL
+   prompt "User Mode Instruction Prevention" if EXPERT
+   ---help---
+ The User Mode Instruction Prevention (UMIP) is a security
+ feature in newer Intel processors. If enabled, a general
+ protection fault is issued if the instructions SGDT, SLDT,
+ SIDT, SMSW and STR are executed in user mode.
+
 config X86_INTEL_MPX
prompt "Intel MPX (Memory Protection Extensions)"
def_bool n
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index dc1697c..b38a639 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -306,6 +306,19 @@ static __always_inline void setup_smap(struct cpuinfo_x86 
*c)
}
 }
 
+static __always_inline void setup_umip(struct cpuinfo_x86 *c)
+{
+   if (cpu_feature_enabled(X86_FEATURE_UMIP) &&
+   cpu_has(c, X86_FEATURE_UMIP))
+   cr4_set_bits(X86_CR4_UMIP);
+   else
+   /*
+* Make sure UMIP is disabled in case it was enabled in a
+* previous boot (e.g., via kexec).
+*/
+   cr4_clear_bits(X86_CR4_UMIP);
+}
+
 /*
  * Protection Keys are not available in 32-bit mode.
  */
@@ -1059,9 +1072,10 @@ static void identify_cpu(struct cpuinfo_x86 *c)
/* Disable the PN if appropriate */
squash_the_stupid_serial_number(c);
 
-   /* Set up SMEP/SMAP */
+   /* Set up SMEP/SMAP/UMIP */
setup_smep(c);
setup_smap(c);
+   setup_umip(c);
 
/*
 * The vendor-specific functions might have changed features.
-- 
2.9.3

[v2 6/7] x86/traps: Fixup general protection faults caused by UMIP

[Ricardo Neri]

If the User-Mode Instruction Prevention CPU feature is available and
enabled, a general protection fault will be issued if the instructions
sgdt, sldt, sidt, str or smsw are executed from user-mode context
(CPL > 0). If the fault was caused by any of the instructions protected
by UMIP, fixup_umip_exceptino will emulate dummy results for these
instructions.

Cc: Andy Lutomirski 
Cc: Andrew Morton 
Cc: H. Peter Anvin 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Chen Yucong 
Cc: Chris Metcalf 
Cc: Dave Hansen 
Cc: Fenghua Yu 
Cc: Huang Rui 
Cc: Jiri Slaby 
Cc: Jonathan Corbet 
Cc: Michael S. Tsirkin 
Cc: Paul Gortmaker 
Cc: Peter Zijlstra 
Cc: Ravi V. Shankar 
Cc: Shuah Khan 
Cc: Vlastimil Babka 
Cc: Tony Luck 
Cc: Paolo Bonzini 
Cc: Liang Z. Li 
Cc: Alexandre Julliard 
Cc: Stas Sergeev 
Cc: x...@kernel.org
Cc: linux-ms...@vger.kernel.org
Signed-off-by: Ricardo Neri 
---
 arch/x86/kernel/traps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index bf0c6d0..5044fb3 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -64,6 +64,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_X86_64
 #include 
@@ -491,6 +492,9 @@ do_general_protection(struct pt_regs *regs, long error_code)
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
cond_local_irq_enable(regs);
 
+   if (user_mode(regs) && !fixup_umip_exception(regs))
+   return;
+
if (v8086_mode(regs)) {
local_irq_enable();
handle_vm86_fault((struct kernel_vm86_regs *) regs, error_code);
-- 
2.9.3

[v2 5/7] x86: Add emulation code for UMIP instructions

[Ricardo Neri]

The feature User-Mode Instruction Prevention present in recent Intel
processor prevents a group of instructions from being executed with
CPL > 0. Otherwise, a general protection fault is issued.

Rather than relaying this fault to the user space (in the form of a SIGSEGV
signal), the instructions protected by UMIP can be emulated to provide
dummy results. This allows to conserve the current kernel behavior and not
reveal the system resources that UMIP intends to protect (the global
descriptor and interrupt descriptor tables, the segment selectors of the
local descriptor table and the task state and the machine status word).

This emulation is needed because certain applications (e.g., WineHQ) rely
on this subset of instructions to function.

The instructions protected by UMIP can be split in two groups. Those who
return a kernel memory address (sgdt and sidt) and those who return a
value (sldt, str and smsw).

For the instructions that return a kernel memory address, the result is
emulated as the location of a dummy variable in the kernel memory space.
This is needed as applications such as WineHQ rely on the result being
located in the kernel memory space function. The limit for the GDT and the
IDT are set to zero.

The instructions sldt and str return a segment selector relative to the
base address of the global descriptor table. Since the actual address of
such table is not revealed, it makes sense to emulate the result as zero.

The instruction smsw is emulated to return zero.

Cc: Andy Lutomirski 
Cc: Andrew Morton 
Cc: H. Peter Anvin 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Chen Yucong 
Cc: Chris Metcalf 
Cc: Dave Hansen 
Cc: Fenghua Yu 
Cc: Huang Rui 
Cc: Jiri Slaby 
Cc: Jonathan Corbet 
Cc: Michael S. Tsirkin 
Cc: Paul Gortmaker 
Cc: Peter Zijlstra 
Cc: Ravi V. Shankar 
Cc: Shuah Khan 
Cc: Vlastimil Babka 
Cc: Tony Luck 
Cc: Paolo Bonzini 
Cc: Liang Z. Li 
Cc: Alexandre Julliard 
Cc: Stas Sergeev 
Cc: x...@kernel.org
Cc: linux-ms...@vger.kernel.org
Signed-off-by: Ricardo Neri 
---
 arch/x86/include/asm/umip.h |  16 +
 arch/x86/kernel/Makefile|   1 +
 arch/x86/kernel/umip.c  | 170 
 3 files changed, 187 insertions(+)
 create mode 100644 arch/x86/include/asm/umip.h
 create mode 100644 arch/x86/kernel/umip.c

diff --git a/arch/x86/include/asm/umip.h b/arch/x86/include/asm/umip.h
new file mode 100644
index 000..7bcaca6
--- /dev/null
+++ b/arch/x86/include/asm/umip.h
@@ -0,0 +1,16 @@
+#ifndef _ASM_X86_UMIP_H
+#define _ASM_X86_UMIP_H
+
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_X86_INTEL_UMIP
+int fixup_umip_exception(struct pt_regs *regs);
+#else
+static inline int fixup_umip_exception(struct pt_regs *regs)
+{
+   return -EINVAL;
+}
+#endif  /* CONFIG_X86_INTEL_UMIP */
+#endif  /* _ASM_X86_UMIP_H */
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 581386c..c4aec02 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -124,6 +124,7 @@ obj-$(CONFIG_EFI)   += sysfb_efi.o
 obj-$(CONFIG_PERF_EVENTS)  += perf_regs.o
 obj-$(CONFIG_TRACING)  += tracepoint.o
 obj-$(CONFIG_SCHED_MC_PRIO)+= itmt.o
+obj-$(CONFIG_X86_INTEL_UMIP)   += umip.o
 
 ifdef CONFIG_FRAME_POINTER
 obj-y  += unwind_frame.o
diff --git a/arch/x86/kernel/umip.c b/arch/x86/kernel/umip.c
new file mode 100644
index 000..a104aea
--- /dev/null
+++ b/arch/x86/kernel/umip.c
@@ -0,0 +1,170 @@
+/*
+ * umip.c Emulation for instruction protected by the Intel User-Mode
+ * Instruction Prevention. The instructions are:
+ *sgdt
+ *sldt
+ *sidt
+ *str
+ *smsw
+ *
+ * Copyright (c) 2016, Intel Corporation.
+ * Ricardo Neri 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The address of this dummy values need to be readable by
+ * the user space
+ */
+
+static const long umip_dummy_gdt_base;
+static const long umip_dummy_idt_base;
+
+enum umip_insn {
+   UMIP_SGDT = 0,  /* opcode 0f 01 ModR/M reg 0 */
+   UMIP_SIDT,  /* opcode 0f 01 ModR/M reg 1 */
+   UMIP_SLDT,  /* opcode 0f 00 ModR/M reg 0 */
+   UMIP_SMSW,  /* opcode 0f 01 ModR/M reg 4 */
+   UMIP_STR,   /* opcode 0f 00 ModR/M reg 1 */
+};
+
+static int __identify_insn(struct insn *insn)
+{
+   /* by getting modrm we also get the opcode */
+   insn_get_modrm(insn);
+   if (insn->opcode.bytes[0] != 0xf)
+   return -EINVAL;
+
+   if (insn->opcode.bytes[1] == 0x1) {
+   switch (X86_MODRM_REG(insn->modrm.value)) {
+   case 0:
+   return UMIP_SGDT;
+   case 1:
+   return UMIP_SIDT;
+   case 4:
+   return UMIP_SMSW;
+   default:
+   return -EINVAL;
+   }
+   } else if (insn->opcode.bytes[1] == 0x0) {
+ 

[v2 7/7] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

User_mode Instruction Prevention (UMIP) is enabled by setting/clearing a
bit in %cr4.

It makes sense to enable UMIP at some point while booting, before user
spaces come up. Like SMAP and SMEP, is not critical to have it enabled
very early during boot. This is because UMIP is relevant only when there is
a userspace to be protected from. Given the similarities in relevance, it
makes sense to enable UMIP along with SMAP and SMEP.

UMIP is enabled by default. It can be disabled by adding clearcpuid=514
to the kernel parameters.

Cc: Andy Lutomirski 
Cc: Andrew Morton 
Cc: H. Peter Anvin 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Chen Yucong 
Cc: Chris Metcalf 
Cc: Dave Hansen 
Cc: Fenghua Yu 
Cc: Huang Rui 
Cc: Jiri Slaby 
Cc: Jonathan Corbet 
Cc: Michael S. Tsirkin 
Cc: Paul Gortmaker 
Cc: Peter Zijlstra 
Cc: Ravi V. Shankar 
Cc: Shuah Khan 
Cc: Vlastimil Babka 
Cc: Tony Luck 
Cc: Paolo Bonzini 
Cc: Liang Z. Li 
Cc: Alexandre Julliard 
Cc: Stas Sergeev 
Cc: x...@kernel.org
Cc: linux-ms...@vger.kernel.org
Signed-off-by: Ricardo Neri 
---
 arch/x86/Kconfig | 10 ++
 arch/x86/kernel/cpu/common.c | 16 +++-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e487493..bae1a8f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1733,6 +1733,16 @@ config X86_SMAP
 
  If unsure, say Y.
 
+config X86_INTEL_UMIP
+   def_bool y
+   depends on CPU_SUP_INTEL
+   prompt "User Mode Instruction Prevention" if EXPERT
+   ---help---
+ The User Mode Instruction Prevention (UMIP) is a security
+ feature in newer Intel processors. If enabled, a general
+ protection fault is issued if the instructions SGDT, SLDT,
+ SIDT, SMSW and STR are executed in user mode.
+
 config X86_INTEL_MPX
prompt "Intel MPX (Memory Protection Extensions)"
def_bool n
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index dc1697c..b38a639 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -306,6 +306,19 @@ static __always_inline void setup_smap(struct cpuinfo_x86 
*c)
}
 }
 
+static __always_inline void setup_umip(struct cpuinfo_x86 *c)
+{
+   if (cpu_feature_enabled(X86_FEATURE_UMIP) &&
+   cpu_has(c, X86_FEATURE_UMIP))
+   cr4_set_bits(X86_CR4_UMIP);
+   else
+   /*
+* Make sure UMIP is disabled in case it was enabled in a
+* previous boot (e.g., via kexec).
+*/
+   cr4_clear_bits(X86_CR4_UMIP);
+}
+
 /*
  * Protection Keys are not available in 32-bit mode.
  */
@@ -1059,9 +1072,10 @@ static void identify_cpu(struct cpuinfo_x86 *c)
/* Disable the PN if appropriate */
squash_the_stupid_serial_number(c);
 
-   /* Set up SMEP/SMAP */
+   /* Set up SMEP/SMAP/UMIP */
setup_smep(c);
setup_smap(c);
+   setup_umip(c);
 
/*
 * The vendor-specific functions might have changed features.
-- 
2.9.3

[v2 6/7] x86/traps: Fixup general protection faults caused by UMIP

[Ricardo Neri]

If the User-Mode Instruction Prevention CPU feature is available and
enabled, a general protection fault will be issued if the instructions
sgdt, sldt, sidt, str or smsw are executed from user-mode context
(CPL > 0). If the fault was caused by any of the instructions protected
by UMIP, fixup_umip_exceptino will emulate dummy results for these
instructions.

Cc: Andy Lutomirski 
Cc: Andrew Morton 
Cc: H. Peter Anvin 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Chen Yucong 
Cc: Chris Metcalf 
Cc: Dave Hansen 
Cc: Fenghua Yu 
Cc: Huang Rui 
Cc: Jiri Slaby 
Cc: Jonathan Corbet 
Cc: Michael S. Tsirkin 
Cc: Paul Gortmaker 
Cc: Peter Zijlstra 
Cc: Ravi V. Shankar 
Cc: Shuah Khan 
Cc: Vlastimil Babka 
Cc: Tony Luck 
Cc: Paolo Bonzini 
Cc: Liang Z. Li 
Cc: Alexandre Julliard 
Cc: Stas Sergeev 
Cc: x...@kernel.org
Cc: linux-ms...@vger.kernel.org
Signed-off-by: Ricardo Neri 
---
 arch/x86/kernel/traps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index bf0c6d0..5044fb3 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -64,6 +64,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_X86_64
 #include 
@@ -491,6 +492,9 @@ do_general_protection(struct pt_regs *regs, long error_code)
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
cond_local_irq_enable(regs);
 
+   if (user_mode(regs) && !fixup_umip_exception(regs))
+   return;
+
if (v8086_mode(regs)) {
local_irq_enable();
handle_vm86_fault((struct kernel_vm86_regs *) regs, error_code);
-- 
2.9.3

[v2 0/7] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

This is v2 of my first submission done a while ago[1]. I apologize for the
delay.

User-Mode Instruction Prevention (UMIP) is a security feature present in
new Intel Processors. If enabled, it prevents the execution of certain
instructions if the Current Privilege Level (CPL) is greater than 0. If
these instructions were executed while in CPL > 0, user space applications
could have access to system-wide settings such as the global and local
descriptor tables, the segment selectors to the current task state and the
local descriptor table.

These are the instructions covered by UMIP:
* SGDT - Store Global Descriptor Table
* SIDT - Store Interrupt Descriptor Table
* SLDT - Store Local Descriptor Table
* SMSW - Store Machine Status Word
* STR - Store Task Register

If any of these instructions is executed with CPL > 0, a general protection
exception is issued when UMIP is enabled.

There is a caveat, however. Certain applications rely on some of these
instructions to function. An example of this are applications that use
WineHQ[2]. For instance, these applications rely on sidt returning a non-
accesible memory location[3]. During the discussions, it was proposed that
the fault could be relied to the user-space and perform the emulation in
user-mode. However, this would break existing applications until, for
instance, they update to a new WineHQ version. However, this approach
would require UMIP to be disabled by default. The concensus in this forum
is to always enable it.

This patchset initially treated tasks running in virtual-8086 mode as a
special case. However, I received clarification that DOSEMU[4] does not
support applications that use these instructions. It relies on WineHQ for
this[4]. Furthermore, the applications for which the concern was raised
run in protected mode [3].

This version keeps UMIP enabled at all times and by default. If a general
protection fault caused by the instructions protected by UMIP is
detected, such fault will be fixed-up by returning dummy values as follows:
 
 * SGDT and SIDT return a base address to a dummy location in kernel memory
   and a limit of 0.
 * STR, SLDT returns 0 as the segment selector. This seems OK since we are
   providing a dummy value as the base address of the global descriptor
   table.
 * SMSW returns 0.
 
Lastly, I found very useful the code for Intel MPX (Memory Protection
Extensions) used to parse opcodes and the memory locations contained in the
general purpose registers when used as operands. I put some of this code in
a separate file that both MPX and UMIP can access and avoid code
duplication. While here, I fixed two small bugs that I found in the MPX
implementation.

The code that I used to test the emulated instructions can be found in [6].

[1]. https://lwn.net/Articles/705877/
[2]. https://www.winehq.org/
[3]. https://www.winehq.org/pipermail/wine-devel/2016-November/115320.html
[4]. http://www.dosemu.org/
[5]. http://marc.info/?l=linux-kernel=147876798717927=2
[6]. 
https://github.com/01org/luv-yocto/tree/rneri/umip/meta-luv/recipes-core/umip/files

Thanks and BR,
Ricardo

Cc: Andy Lutomirski 
Cc: Andrew Morton 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Chen Yucong 
Cc: Chris Metcalf 
Cc: Dave Hansen 
Cc: Fenghua Yu 
Cc: Huang Rui 
Cc: Jiri Slaby 
Cc: Jonathan Corbet 
Cc: Michael S. Tsirkin 
Cc: Paul Gortmaker 
Cc: Peter Zijlstra 
Cc: Ravi V. Shankar 
Cc: Vlastimil Babka 
Cc: Shuah Khan 
Cc: Paolo Bonzini 
Cc: Liang Z Li 
Cc: x...@kernel.org
Cc: linux-ms...@vger.kernel.org

Changes since V1:
* Virtual-8086 mode tasks are not treated in a special manner. All code
  for this purpose was removed.
* Instead of attempting to disable UMIP during a context switch or when
  entering virtual-8086 mode, UMIP remains enabled all the time. General
  protection faults that occur are fixed-up by returning dummy values as
  detailed above.
* Removed umip= kernel parameter in favor of using clearcpuid=514 to
  disable UMIP.
* Removed selftests designed to detect the absence of SIGSEGV signals when
  running in virtual-8086 mode.
* Reused code from MPX to decode instructions operands. For this purpose
  code was put in a common location.
* Fixed two bugs in MPX code that decodes operands.

Ricardo Neri (7):
  x86/mpx: Do not use SIB index if index points to R/ESP
  x86/mpx: Fail when implicit zero-displacement is used along with R/EBP
  x86/mpx, x86/insn: Relocate insn util functions to a new insn-utils
  x86/cpufeature: Add User-Mode Instruction Prevention definitions
  x86: Add emulation code for UMIP instructions
  x86/traps: Fixup general protection faults caused 

[v2 4/7] x86/cpufeature: Add User-Mode Instruction Prevention definitions

[Ricardo Neri]

User-Mode Instruction Prevention is a security feature present in new
Intel processors that, when set, prevents the execution of a subset of
instructions if such instructions are executed in user mode (CPL > 0).
Attempting to execute such instructions causes a general protection
exception.

The subset of instructions comprises:

 * SGDT - Store Global Descriptor Table
 * SIDT - Store Interrupt Descriptor Table
 * SLDT - Store Local Descriptor Table
 * SMSW - Store Machine Status Word
 * STR  - Store Task Register

This feature is also added to the list of disabled-features to allow
a cleaner handling of build-time configuration.

Cc: Andy Lutomirski 
Cc: Andrew Morton 
Cc: H. Peter Anvin 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Chen Yucong 
Cc: Chris Metcalf 
Cc: Dave Hansen 
Cc: Fenghua Yu 
Cc: Huang Rui 
Cc: Jiri Slaby 
Cc: Jonathan Corbet 
Cc: Michael S. Tsirkin 
Cc: Paul Gortmaker 
Cc: Peter Zijlstra 
Cc: Ravi V. Shankar 
Cc: Shuah Khan 
Cc: Vlastimil Babka 
Cc: Tony Luck 
Cc: Paolo Bonzini 
Cc: Liang Z. Li 
Cc: Alexandre Julliard 
Cc: Stas Sergeev 
Cc: x...@kernel.org
Cc: linux-ms...@vger.kernel.org

Signed-off-by: Ricardo Neri 
---
 arch/x86/include/asm/cpufeatures.h  | 1 +
 arch/x86/include/asm/disabled-features.h| 8 +++-
 arch/x86/include/uapi/asm/processor-flags.h | 2 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index eafee31..be61bf9 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -286,6 +286,7 @@
 
 /* Intel-defined CPU features, CPUID level 0x0007:0 (ecx), word 16 */
 #define X86_FEATURE_AVX512VBMI  (16*32+ 1) /* AVX512 Vector Bit Manipulation 
instructions*/
+#define X86_FEATURE_UMIP   (16*32+ 2) /* User Mode Instruction Protection 
*/
 #define X86_FEATURE_PKU(16*32+ 3) /* Protection Keys for 
Userspace */
 #define X86_FEATURE_OSPKE  (16*32+ 4) /* OS Protection Keys Enable */
 #define X86_FEATURE_RDPID  (16*32+ 22) /* RDPID instruction */
diff --git a/arch/x86/include/asm/disabled-features.h 
b/arch/x86/include/asm/disabled-features.h
index 85599ad..4707445 100644
--- a/arch/x86/include/asm/disabled-features.h
+++ b/arch/x86/include/asm/disabled-features.h
@@ -16,6 +16,12 @@
 # define DISABLE_MPX   (1<<(X86_FEATURE_MPX & 31))
 #endif
 
+#ifdef CONFIG_X86_INTEL_UMIP
+# define DISABLE_UMIP  0
+#else
+# define DISABLE_UMIP  (1<<(X86_FEATURE_UMIP & 31))
+#endif
+
 #ifdef CONFIG_X86_64
 # define DISABLE_VME   (1<<(X86_FEATURE_VME & 31))
 # define DISABLE_K6_MTRR   (1<<(X86_FEATURE_K6_MTRR & 31))
@@ -55,7 +61,7 @@
 #define DISABLED_MASK130
 #define DISABLED_MASK140
 #define DISABLED_MASK150
-#define DISABLED_MASK16(DISABLE_PKU|DISABLE_OSPKE)
+#define DISABLED_MASK16(DISABLE_PKU|DISABLE_OSPKE|DISABLE_UMIP)
 #define DISABLED_MASK170
 #define DISABLED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 18)
 
diff --git a/arch/x86/include/uapi/asm/processor-flags.h 
b/arch/x86/include/uapi/asm/processor-flags.h
index 567de50..d2c2af8 100644
--- a/arch/x86/include/uapi/asm/processor-flags.h
+++ b/arch/x86/include/uapi/asm/processor-flags.h
@@ -104,6 +104,8 @@
 #define X86_CR4_OSFXSR _BITUL(X86_CR4_OSFXSR_BIT)
 #define X86_CR4_OSXMMEXCPT_BIT 10 /* enable unmasked SSE exceptions */
 #define X86_CR4_OSXMMEXCPT _BITUL(X86_CR4_OSXMMEXCPT_BIT)
+#define X86_CR4_UMIP_BIT   11 /* enable UMIP support */
+#define X86_CR4_UMIP   _BITUL(X86_CR4_UMIP_BIT)
 #define X86_CR4_VMXE_BIT   13 /* enable VMX virtualization */
 #define X86_CR4_VMXE   _BITUL(X86_CR4_VMXE_BIT)
 #define X86_CR4_SMXE_BIT   14 /* enable safer mode (TXT) */
-- 
2.9.3

[v2 0/7] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

This is v2 of my first submission done a while ago[1]. I apologize for the
delay.

User-Mode Instruction Prevention (UMIP) is a security feature present in
new Intel Processors. If enabled, it prevents the execution of certain
instructions if the Current Privilege Level (CPL) is greater than 0. If
these instructions were executed while in CPL > 0, user space applications
could have access to system-wide settings such as the global and local
descriptor tables, the segment selectors to the current task state and the
local descriptor table.

These are the instructions covered by UMIP:
* SGDT - Store Global Descriptor Table
* SIDT - Store Interrupt Descriptor Table
* SLDT - Store Local Descriptor Table
* SMSW - Store Machine Status Word
* STR - Store Task Register

If any of these instructions is executed with CPL > 0, a general protection
exception is issued when UMIP is enabled.

There is a caveat, however. Certain applications rely on some of these
instructions to function. An example of this are applications that use
WineHQ[2]. For instance, these applications rely on sidt returning a non-
accesible memory location[3]. During the discussions, it was proposed that
the fault could be relied to the user-space and perform the emulation in
user-mode. However, this would break existing applications until, for
instance, they update to a new WineHQ version. However, this approach
would require UMIP to be disabled by default. The concensus in this forum
is to always enable it.

This patchset initially treated tasks running in virtual-8086 mode as a
special case. However, I received clarification that DOSEMU[4] does not
support applications that use these instructions. It relies on WineHQ for
this[4]. Furthermore, the applications for which the concern was raised
run in protected mode [3].

This version keeps UMIP enabled at all times and by default. If a general
protection fault caused by the instructions protected by UMIP is
detected, such fault will be fixed-up by returning dummy values as follows:
 
 * SGDT and SIDT return a base address to a dummy location in kernel memory
   and a limit of 0.
 * STR, SLDT returns 0 as the segment selector. This seems OK since we are
   providing a dummy value as the base address of the global descriptor
   table.
 * SMSW returns 0.
 
Lastly, I found very useful the code for Intel MPX (Memory Protection
Extensions) used to parse opcodes and the memory locations contained in the
general purpose registers when used as operands. I put some of this code in
a separate file that both MPX and UMIP can access and avoid code
duplication. While here, I fixed two small bugs that I found in the MPX
implementation.

The code that I used to test the emulated instructions can be found in [6].

[1]. https://lwn.net/Articles/705877/
[2]. https://www.winehq.org/
[3]. https://www.winehq.org/pipermail/wine-devel/2016-November/115320.html
[4]. http://www.dosemu.org/
[5]. http://marc.info/?l=linux-kernel=147876798717927=2
[6]. 
https://github.com/01org/luv-yocto/tree/rneri/umip/meta-luv/recipes-core/umip/files

Thanks and BR,
Ricardo

Cc: Andy Lutomirski 
Cc: Andrew Morton 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Chen Yucong 
Cc: Chris Metcalf 
Cc: Dave Hansen 
Cc: Fenghua Yu 
Cc: Huang Rui 
Cc: Jiri Slaby 
Cc: Jonathan Corbet 
Cc: Michael S. Tsirkin 
Cc: Paul Gortmaker 
Cc: Peter Zijlstra 
Cc: Ravi V. Shankar 
Cc: Vlastimil Babka 
Cc: Shuah Khan 
Cc: Paolo Bonzini 
Cc: Liang Z Li 
Cc: x...@kernel.org
Cc: linux-ms...@vger.kernel.org

Changes since V1:
* Virtual-8086 mode tasks are not treated in a special manner. All code
  for this purpose was removed.
* Instead of attempting to disable UMIP during a context switch or when
  entering virtual-8086 mode, UMIP remains enabled all the time. General
  protection faults that occur are fixed-up by returning dummy values as
  detailed above.
* Removed umip= kernel parameter in favor of using clearcpuid=514 to
  disable UMIP.
* Removed selftests designed to detect the absence of SIGSEGV signals when
  running in virtual-8086 mode.
* Reused code from MPX to decode instructions operands. For this purpose
  code was put in a common location.
* Fixed two bugs in MPX code that decodes operands.

Ricardo Neri (7):
  x86/mpx: Do not use SIB index if index points to R/ESP
  x86/mpx: Fail when implicit zero-displacement is used along with R/EBP
  x86/mpx, x86/insn: Relocate insn util functions to a new insn-utils
  x86/cpufeature: Add User-Mode Instruction Prevention definitions
  x86: Add emulation code for UMIP instructions
  x86/traps: Fixup general protection faults caused by UMIP
  x86: Enable User-Mode Instruction Prevention

 arch/x86/Kconfig|  10 ++
 arch/x86/include/asm/cpufeatures.h  |   1 +
 arch/x86/include/asm/disabled-features.h|   8 +-
 arch/x86/include/asm/insn.h |   6 +
 arch/x86/include/asm/umip.h |  16 +++
 arch/x86/include/uapi/asm/processor-flags.h |   2 +
 

[v2 4/7] x86/cpufeature: Add User-Mode Instruction Prevention definitions

[Ricardo Neri]

User-Mode Instruction Prevention is a security feature present in new
Intel processors that, when set, prevents the execution of a subset of
instructions if such instructions are executed in user mode (CPL > 0).
Attempting to execute such instructions causes a general protection
exception.

The subset of instructions comprises:

 * SGDT - Store Global Descriptor Table
 * SIDT - Store Interrupt Descriptor Table
 * SLDT - Store Local Descriptor Table
 * SMSW - Store Machine Status Word
 * STR  - Store Task Register

This feature is also added to the list of disabled-features to allow
a cleaner handling of build-time configuration.

Cc: Andy Lutomirski 
Cc: Andrew Morton 
Cc: H. Peter Anvin 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Chen Yucong 
Cc: Chris Metcalf 
Cc: Dave Hansen 
Cc: Fenghua Yu 
Cc: Huang Rui 
Cc: Jiri Slaby 
Cc: Jonathan Corbet 
Cc: Michael S. Tsirkin 
Cc: Paul Gortmaker 
Cc: Peter Zijlstra 
Cc: Ravi V. Shankar 
Cc: Shuah Khan 
Cc: Vlastimil Babka 
Cc: Tony Luck 
Cc: Paolo Bonzini 
Cc: Liang Z. Li 
Cc: Alexandre Julliard 
Cc: Stas Sergeev 
Cc: x...@kernel.org
Cc: linux-ms...@vger.kernel.org

Signed-off-by: Ricardo Neri 
---
 arch/x86/include/asm/cpufeatures.h  | 1 +
 arch/x86/include/asm/disabled-features.h| 8 +++-
 arch/x86/include/uapi/asm/processor-flags.h | 2 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index eafee31..be61bf9 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -286,6 +286,7 @@
 
 /* Intel-defined CPU features, CPUID level 0x0007:0 (ecx), word 16 */
 #define X86_FEATURE_AVX512VBMI  (16*32+ 1) /* AVX512 Vector Bit Manipulation 
instructions*/
+#define X86_FEATURE_UMIP   (16*32+ 2) /* User Mode Instruction Protection 
*/
 #define X86_FEATURE_PKU(16*32+ 3) /* Protection Keys for 
Userspace */
 #define X86_FEATURE_OSPKE  (16*32+ 4) /* OS Protection Keys Enable */
 #define X86_FEATURE_RDPID  (16*32+ 22) /* RDPID instruction */
diff --git a/arch/x86/include/asm/disabled-features.h 
b/arch/x86/include/asm/disabled-features.h
index 85599ad..4707445 100644
--- a/arch/x86/include/asm/disabled-features.h
+++ b/arch/x86/include/asm/disabled-features.h
@@ -16,6 +16,12 @@
 # define DISABLE_MPX   (1<<(X86_FEATURE_MPX & 31))
 #endif
 
+#ifdef CONFIG_X86_INTEL_UMIP
+# define DISABLE_UMIP  0
+#else
+# define DISABLE_UMIP  (1<<(X86_FEATURE_UMIP & 31))
+#endif
+
 #ifdef CONFIG_X86_64
 # define DISABLE_VME   (1<<(X86_FEATURE_VME & 31))
 # define DISABLE_K6_MTRR   (1<<(X86_FEATURE_K6_MTRR & 31))
@@ -55,7 +61,7 @@
 #define DISABLED_MASK130
 #define DISABLED_MASK140
 #define DISABLED_MASK150
-#define DISABLED_MASK16(DISABLE_PKU|DISABLE_OSPKE)
+#define DISABLED_MASK16(DISABLE_PKU|DISABLE_OSPKE|DISABLE_UMIP)
 #define DISABLED_MASK170
 #define DISABLED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 18)
 
diff --git a/arch/x86/include/uapi/asm/processor-flags.h 
b/arch/x86/include/uapi/asm/processor-flags.h
index 567de50..d2c2af8 100644
--- a/arch/x86/include/uapi/asm/processor-flags.h
+++ b/arch/x86/include/uapi/asm/processor-flags.h
@@ -104,6 +104,8 @@
 #define X86_CR4_OSFXSR _BITUL(X86_CR4_OSFXSR_BIT)
 #define X86_CR4_OSXMMEXCPT_BIT 10 /* enable unmasked SSE exceptions */
 #define X86_CR4_OSXMMEXCPT _BITUL(X86_CR4_OSXMMEXCPT_BIT)
+#define X86_CR4_UMIP_BIT   11 /* enable UMIP support */
+#define X86_CR4_UMIP   _BITUL(X86_CR4_UMIP_BIT)
 #define X86_CR4_VMXE_BIT   13 /* enable VMX virtualization */
 #define X86_CR4_VMXE   _BITUL(X86_CR4_VMXE_BIT)
 #define X86_CR4_SMXE_BIT   14 /* enable safer mode (TXT) */
-- 
2.9.3

[v2 3/7] x86/mpx, x86/insn: Relocate insn util functions to a new insn-utils

[Ricardo Neri]

Other kernel submodules can benefit from using the utility functions
defined in mpx.c to obtain the addresses and values of operands contained
in the general purpose registers. An instance of this is the emulation code
used for instructions protected by the Intel User-Mode Instruction
Prevention feature.

Thus, these functions are relocated to a new insn-utils.c file. The reason
to not relocate these utilities for insn.c is that the latter solely
analyses instructions given by a struct insn. The file insn-utils.c intends
to be used when, for instance, determining addresses from the contents
of the general purpose registers.

To avoid creating a new insn-utils.h, insn.h is used. One caveat, however,
is that several #include's were needed by the utility functions.

Functions are simply relocated. There are not functional or indentation
changes.

Cc: Dave Hansen 
Cc: Adam Buchbinder 
Cc: Colin Ian King 
Cc: Lorenzo Stoakes 
Cc: Qiaowei Ren 
Cc: Arnaldo Carvalho de Melo 
Cc: Masami Hiramatsu 
Cc: Adrian Hunter 
Cc: Kees Cook 
Cc: Thomas Garnier 
Cc: Peter Zijlstra 
Cc: Borislav Petkov 
Cc: Dmitry Vyukov 
Cc: Ravi V. Shankar 
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri 
---
 arch/x86/include/asm/insn.h |   6 ++
 arch/x86/lib/Makefile   |   2 +-
 arch/x86/lib/insn-utils.c   | 148 
 arch/x86/mm/mpx.c   | 136 +---
 4 files changed, 156 insertions(+), 136 deletions(-)
 create mode 100644 arch/x86/lib/insn-utils.c

diff --git a/arch/x86/include/asm/insn.h b/arch/x86/include/asm/insn.h
index b3e32b0..9dc9d42 100644
--- a/arch/x86/include/asm/insn.h
+++ b/arch/x86/include/asm/insn.h
@@ -22,6 +22,10 @@
 
 /* insn_attr_t is defined in inat.h */
 #include 
+#include 
+#include 
+#include 
+#include 
 
 struct insn_field {
union {
@@ -106,6 +110,8 @@ extern void insn_get_sib(struct insn *insn);
 extern void insn_get_displacement(struct insn *insn);
 extern void insn_get_immediate(struct insn *insn);
 extern void insn_get_length(struct insn *insn);
+extern void __user *insn_get_addr_ref(struct insn *insn, struct pt_regs *regs);
+extern int get_reg_offset_rm(struct insn *insn, struct pt_regs *regs);
 
 /* Attribute will be determined after getting ModRM (for opcode groups) */
 static inline void insn_get_attribute(struct insn *insn)
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 34a7413..0d01d82 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -23,7 +23,7 @@ lib-y := delay.o misc.o cmdline.o cpu.o
 lib-y += usercopy_$(BITS).o usercopy.o getuser.o putuser.o
 lib-y += memcpy_$(BITS).o
 lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
-lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o
+lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o insn-utils.o
 lib-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
 
 obj-y += msr.o msr-reg.o msr-reg-export.o hweight.o
diff --git a/arch/x86/lib/insn-utils.c b/arch/x86/lib/insn-utils.c
new file mode 100644
index 000..598bbd6
--- /dev/null
+++ b/arch/x86/lib/insn-utils.c
@@ -0,0 +1,148 @@
+/*
+ * Utility functions for x86 operand and address decoding
+ *
+ * Copyright (C) Intel Corporation 2016
+ */
+#include 
+#include 
+#include 
+#include 
+
+enum reg_type {
+   REG_TYPE_RM = 0,
+   REG_TYPE_INDEX,
+   REG_TYPE_BASE,
+};
+
+static int get_reg_offset(struct insn *insn, struct pt_regs *regs,
+ enum reg_type type)
+{
+   int regno = 0;
+
+   static const int regoff[] = {
+   offsetof(struct pt_regs, ax),
+   offsetof(struct pt_regs, cx),
+   offsetof(struct pt_regs, dx),
+   offsetof(struct pt_regs, bx),
+   offsetof(struct pt_regs, sp),
+   offsetof(struct pt_regs, bp),
+   offsetof(struct pt_regs, si),
+   offsetof(struct pt_regs, di),
+#ifdef CONFIG_X86_64
+   offsetof(struct pt_regs, r8),
+   offsetof(struct pt_regs, r9),
+   offsetof(struct pt_regs, r10),
+   offsetof(struct pt_regs, r11),
+   offsetof(struct pt_regs, r12),
+   offsetof(struct pt_regs, r13),
+   offsetof(struct pt_regs, r14),
+   offsetof(struct pt_regs, r15),
+#endif
+   };
+   int nr_registers = ARRAY_SIZE(regoff);
+   /*
+* Don't possibly decode a 32-bit instructions as
+* reading a 64-bit-only register.
+*/
+   if (IS_ENABLED(CONFIG_X86_64) && !insn->x86_64)
+   nr_registers -= 8;
+
+   switch (type) {
+   case REG_TYPE_RM:
+   regno = 

[v2 3/7] x86/mpx, x86/insn: Relocate insn util functions to a new insn-utils

[Ricardo Neri]

Other kernel submodules can benefit from using the utility functions
defined in mpx.c to obtain the addresses and values of operands contained
in the general purpose registers. An instance of this is the emulation code
used for instructions protected by the Intel User-Mode Instruction
Prevention feature.

Thus, these functions are relocated to a new insn-utils.c file. The reason
to not relocate these utilities for insn.c is that the latter solely
analyses instructions given by a struct insn. The file insn-utils.c intends
to be used when, for instance, determining addresses from the contents
of the general purpose registers.

To avoid creating a new insn-utils.h, insn.h is used. One caveat, however,
is that several #include's were needed by the utility functions.

Functions are simply relocated. There are not functional or indentation
changes.

Cc: Dave Hansen 
Cc: Adam Buchbinder 
Cc: Colin Ian King 
Cc: Lorenzo Stoakes 
Cc: Qiaowei Ren 
Cc: Arnaldo Carvalho de Melo 
Cc: Masami Hiramatsu 
Cc: Adrian Hunter 
Cc: Kees Cook 
Cc: Thomas Garnier 
Cc: Peter Zijlstra 
Cc: Borislav Petkov 
Cc: Dmitry Vyukov 
Cc: Ravi V. Shankar 
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri 
---
 arch/x86/include/asm/insn.h |   6 ++
 arch/x86/lib/Makefile   |   2 +-
 arch/x86/lib/insn-utils.c   | 148 
 arch/x86/mm/mpx.c   | 136 +---
 4 files changed, 156 insertions(+), 136 deletions(-)
 create mode 100644 arch/x86/lib/insn-utils.c

diff --git a/arch/x86/include/asm/insn.h b/arch/x86/include/asm/insn.h
index b3e32b0..9dc9d42 100644
--- a/arch/x86/include/asm/insn.h
+++ b/arch/x86/include/asm/insn.h
@@ -22,6 +22,10 @@
 
 /* insn_attr_t is defined in inat.h */
 #include 
+#include 
+#include 
+#include 
+#include 
 
 struct insn_field {
union {
@@ -106,6 +110,8 @@ extern void insn_get_sib(struct insn *insn);
 extern void insn_get_displacement(struct insn *insn);
 extern void insn_get_immediate(struct insn *insn);
 extern void insn_get_length(struct insn *insn);
+extern void __user *insn_get_addr_ref(struct insn *insn, struct pt_regs *regs);
+extern int get_reg_offset_rm(struct insn *insn, struct pt_regs *regs);
 
 /* Attribute will be determined after getting ModRM (for opcode groups) */
 static inline void insn_get_attribute(struct insn *insn)
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 34a7413..0d01d82 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -23,7 +23,7 @@ lib-y := delay.o misc.o cmdline.o cpu.o
 lib-y += usercopy_$(BITS).o usercopy.o getuser.o putuser.o
 lib-y += memcpy_$(BITS).o
 lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
-lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o
+lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o insn-utils.o
 lib-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
 
 obj-y += msr.o msr-reg.o msr-reg-export.o hweight.o
diff --git a/arch/x86/lib/insn-utils.c b/arch/x86/lib/insn-utils.c
new file mode 100644
index 000..598bbd6
--- /dev/null
+++ b/arch/x86/lib/insn-utils.c
@@ -0,0 +1,148 @@
+/*
+ * Utility functions for x86 operand and address decoding
+ *
+ * Copyright (C) Intel Corporation 2016
+ */
+#include 
+#include 
+#include 
+#include 
+
+enum reg_type {
+   REG_TYPE_RM = 0,
+   REG_TYPE_INDEX,
+   REG_TYPE_BASE,
+};
+
+static int get_reg_offset(struct insn *insn, struct pt_regs *regs,
+ enum reg_type type)
+{
+   int regno = 0;
+
+   static const int regoff[] = {
+   offsetof(struct pt_regs, ax),
+   offsetof(struct pt_regs, cx),
+   offsetof(struct pt_regs, dx),
+   offsetof(struct pt_regs, bx),
+   offsetof(struct pt_regs, sp),
+   offsetof(struct pt_regs, bp),
+   offsetof(struct pt_regs, si),
+   offsetof(struct pt_regs, di),
+#ifdef CONFIG_X86_64
+   offsetof(struct pt_regs, r8),
+   offsetof(struct pt_regs, r9),
+   offsetof(struct pt_regs, r10),
+   offsetof(struct pt_regs, r11),
+   offsetof(struct pt_regs, r12),
+   offsetof(struct pt_regs, r13),
+   offsetof(struct pt_regs, r14),
+   offsetof(struct pt_regs, r15),
+#endif
+   };
+   int nr_registers = ARRAY_SIZE(regoff);
+   /*
+* Don't possibly decode a 32-bit instructions as
+* reading a 64-bit-only register.
+*/
+   if (IS_ENABLED(CONFIG_X86_64) && !insn->x86_64)
+   nr_registers -= 8;
+
+   switch (type) {
+   case REG_TYPE_RM:
+   regno = X86_MODRM_RM(insn->modrm.value);
+   if (X86_REX_B(insn->rex_prefix.value))
+   regno += 8;
+   break;
+
+   case REG_TYPE_INDEX:
+   regno = X86_SIB_INDEX(insn->sib.value);
+   if (X86_REX_X(insn->rex_prefix.value))
+   regno += 8;
+   /*
+

Re: [PATCH] irqchip: keystone: Fix "scheduling while atomic" on rt

[Suman Anna]

Hi Grygorii,

On 12/08/2016 05:33 PM, Grygorii Strashko wrote:
> From: "Strashko, Grygorii" 
> 
> The below call chain generates "scheduling while atomic" backtrace and
> causes system crash when Keystone 2 IRQ chip driver is used with RT-kernel:
> 
> gic_handle_irq()
>  |-__handle_domain_irq()
>   |-generic_handle_irq()
>|-keystone_irq_handler()
> |-regmap_read()
>  |-regmap_lock_spinlock()
>   |-rt_spin_lock()
> 
> The reason is that Keystone driver dispatches IRQ using chained IRQ handler
> and accesses I/O memory through syscon->regmap(mmio) which is implemented
> as fast_io regmap and uses regular spinlocks for synchronization, but
> spinlocks transformed to rt_mutexes on RT.
> 
> Hence, convert Keystone 2 IRQ driver to use generic irq handler instead of
> chained IRQ handler. This way it will be compatible with RT kernel where it
> will be forced thread IRQ handler while in non-RT kernel it still will be
> executed in HW IRQ context.
> 
> Cc: Suman Anna 
> Signed-off-by: Grygorii Strashko 
> ---
> Hi,
> 
> In general, there is an option to convert this driver to use nested threaded
> irq handlers (this should not affect our current user of these irqs from
> performance point of view), but that will affect on our current remoteproc and
> UIO based drivers (including uio core) which do not expect to use threaded
> irq and use request_irq(). These drivers and UIO core might require to be
> updated to use threaded irqs and (or) request_any_context_irq().
> 
> Suman, what do you think?

I like the current patch as is as we do not want the downstream
subsystems/interrupt users of this driver to change their design
semantics to have to use threaded irqs, and cause a cascading effect.

Tested-by: Suman Anna 

regards
Suman



> 
>  drivers/irqchip/irq-keystone.c | 28 +++-
>  1 file changed, 19 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-keystone.c b/drivers/irqchip/irq-keystone.c
> index 54a5e87..efbcf84 100644
> --- a/drivers/irqchip/irq-keystone.c
> +++ b/drivers/irqchip/irq-keystone.c
> @@ -19,9 +19,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -39,6 +39,7 @@ struct keystone_irq_device {
>   struct irq_domain   *irqd;
>   struct regmap   *devctrl_regs;
>   u32 devctrl_offset;
> + raw_spinlock_t  wa_lock;
>  };
>  
>  static inline u32 keystone_irq_readl(struct keystone_irq_device *kirq)
> @@ -83,17 +84,15 @@ static void keystone_irq_ack(struct irq_data *d)
>   /* nothing to do here */
>  }
>  
> -static void keystone_irq_handler(struct irq_desc *desc)
> +static irqreturn_t keystone_irq_handler(int irq, void *keystone_irq)
>  {
> - unsigned int irq = irq_desc_get_irq(desc);
> - struct keystone_irq_device *kirq = irq_desc_get_handler_data(desc);
> + struct keystone_irq_device *kirq = keystone_irq;
> + unsigned long wa_lock_flags;
>   unsigned long pending;
>   int src, virq;
>  
>   dev_dbg(kirq->dev, "start irq %d\n", irq);
>  
> - chained_irq_enter(irq_desc_get_chip(desc), desc);
> -
>   pending = keystone_irq_readl(kirq);
>   keystone_irq_writel(kirq, pending);
>  
> @@ -111,13 +110,15 @@ static void keystone_irq_handler(struct irq_desc *desc)
>   if (!virq)
>   dev_warn(kirq->dev, "spurious irq detected 
> hwirq %d, virq %d\n",
>src, virq);
> + raw_spin_lock_irqsave(>wa_lock, wa_lock_flags);
>   generic_handle_irq(virq);
> + raw_spin_unlock_irqrestore(>wa_lock,
> +wa_lock_flags);
>   }
>   }
>  
> - chained_irq_exit(irq_desc_get_chip(desc), desc);
> -
>   dev_dbg(kirq->dev, "end irq %d\n", irq);
> + return IRQ_HANDLED;
>  }
>  
>  static int keystone_irq_map(struct irq_domain *h, unsigned int virq,
> @@ -182,9 +183,16 @@ static int keystone_irq_probe(struct platform_device 
> *pdev)
>   return -ENODEV;
>   }
>  
> + raw_spin_lock_init(>wa_lock);
> +
>   platform_set_drvdata(pdev, kirq);
>  
> - irq_set_chained_handler_and_data(kirq->irq, keystone_irq_handler, kirq);
> + ret = request_irq(kirq->irq, keystone_irq_handler,
> +   0, dev_name(dev), kirq);
> + if (ret) {
> + irq_domain_remove(kirq->irqd);
> + return ret;
> + }
>  
>   /* clear all source bits */
>   keystone_irq_writel(kirq, ~0x0);
> @@ -199,6 +207,8 @@ static int keystone_irq_remove(struct platform_device 
> *pdev)
>   struct keystone_irq_device *kirq = platform_get_drvdata(pdev);
>   int hwirq;
>  
> + free_irq(kirq->irq, kirq);
> +
>   for (hwirq = 0; hwirq < KEYSTONE_N_IRQ; 

Re: [PATCH] irqchip: keystone: Fix "scheduling while atomic" on rt

[Suman Anna]

Hi Grygorii,

On 12/08/2016 05:33 PM, Grygorii Strashko wrote:
> From: "Strashko, Grygorii" 
> 
> The below call chain generates "scheduling while atomic" backtrace and
> causes system crash when Keystone 2 IRQ chip driver is used with RT-kernel:
> 
> gic_handle_irq()
>  |-__handle_domain_irq()
>   |-generic_handle_irq()
>|-keystone_irq_handler()
> |-regmap_read()
>  |-regmap_lock_spinlock()
>   |-rt_spin_lock()
> 
> The reason is that Keystone driver dispatches IRQ using chained IRQ handler
> and accesses I/O memory through syscon->regmap(mmio) which is implemented
> as fast_io regmap and uses regular spinlocks for synchronization, but
> spinlocks transformed to rt_mutexes on RT.
> 
> Hence, convert Keystone 2 IRQ driver to use generic irq handler instead of
> chained IRQ handler. This way it will be compatible with RT kernel where it
> will be forced thread IRQ handler while in non-RT kernel it still will be
> executed in HW IRQ context.
> 
> Cc: Suman Anna 
> Signed-off-by: Grygorii Strashko 
> ---
> Hi,
> 
> In general, there is an option to convert this driver to use nested threaded
> irq handlers (this should not affect our current user of these irqs from
> performance point of view), but that will affect on our current remoteproc and
> UIO based drivers (including uio core) which do not expect to use threaded
> irq and use request_irq(). These drivers and UIO core might require to be
> updated to use threaded irqs and (or) request_any_context_irq().
> 
> Suman, what do you think?

I like the current patch as is as we do not want the downstream
subsystems/interrupt users of this driver to change their design
semantics to have to use threaded irqs, and cause a cascading effect.

Tested-by: Suman Anna 

regards
Suman



> 
>  drivers/irqchip/irq-keystone.c | 28 +++-
>  1 file changed, 19 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-keystone.c b/drivers/irqchip/irq-keystone.c
> index 54a5e87..efbcf84 100644
> --- a/drivers/irqchip/irq-keystone.c
> +++ b/drivers/irqchip/irq-keystone.c
> @@ -19,9 +19,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -39,6 +39,7 @@ struct keystone_irq_device {
>   struct irq_domain   *irqd;
>   struct regmap   *devctrl_regs;
>   u32 devctrl_offset;
> + raw_spinlock_t  wa_lock;
>  };
>  
>  static inline u32 keystone_irq_readl(struct keystone_irq_device *kirq)
> @@ -83,17 +84,15 @@ static void keystone_irq_ack(struct irq_data *d)
>   /* nothing to do here */
>  }
>  
> -static void keystone_irq_handler(struct irq_desc *desc)
> +static irqreturn_t keystone_irq_handler(int irq, void *keystone_irq)
>  {
> - unsigned int irq = irq_desc_get_irq(desc);
> - struct keystone_irq_device *kirq = irq_desc_get_handler_data(desc);
> + struct keystone_irq_device *kirq = keystone_irq;
> + unsigned long wa_lock_flags;
>   unsigned long pending;
>   int src, virq;
>  
>   dev_dbg(kirq->dev, "start irq %d\n", irq);
>  
> - chained_irq_enter(irq_desc_get_chip(desc), desc);
> -
>   pending = keystone_irq_readl(kirq);
>   keystone_irq_writel(kirq, pending);
>  
> @@ -111,13 +110,15 @@ static void keystone_irq_handler(struct irq_desc *desc)
>   if (!virq)
>   dev_warn(kirq->dev, "spurious irq detected 
> hwirq %d, virq %d\n",
>src, virq);
> + raw_spin_lock_irqsave(>wa_lock, wa_lock_flags);
>   generic_handle_irq(virq);
> + raw_spin_unlock_irqrestore(>wa_lock,
> +wa_lock_flags);
>   }
>   }
>  
> - chained_irq_exit(irq_desc_get_chip(desc), desc);
> -
>   dev_dbg(kirq->dev, "end irq %d\n", irq);
> + return IRQ_HANDLED;
>  }
>  
>  static int keystone_irq_map(struct irq_domain *h, unsigned int virq,
> @@ -182,9 +183,16 @@ static int keystone_irq_probe(struct platform_device 
> *pdev)
>   return -ENODEV;
>   }
>  
> + raw_spin_lock_init(>wa_lock);
> +
>   platform_set_drvdata(pdev, kirq);
>  
> - irq_set_chained_handler_and_data(kirq->irq, keystone_irq_handler, kirq);
> + ret = request_irq(kirq->irq, keystone_irq_handler,
> +   0, dev_name(dev), kirq);
> + if (ret) {
> + irq_domain_remove(kirq->irqd);
> + return ret;
> + }
>  
>   /* clear all source bits */
>   keystone_irq_writel(kirq, ~0x0);
> @@ -199,6 +207,8 @@ static int keystone_irq_remove(struct platform_device 
> *pdev)
>   struct keystone_irq_device *kirq = platform_get_drvdata(pdev);
>   int hwirq;
>  
> + free_irq(kirq->irq, kirq);
> +
>   for (hwirq = 0; hwirq < KEYSTONE_N_IRQ; hwirq++)
>   irq_dispose_mapping(irq_find_mapping(kirq->irqd, hwirq));
>  

Re: [PATCH] drivers: net: ethernet: 3com: fix return value

[David Dillow]

On Sat, 2016-12-24 at 00:00 +0100, Thomas Preisner wrote:
> diff --git a/drivers/net/ethernet/3com/typhoon.c 
> b/drivers/net/ethernet/3com/typhoon.c
> index a0cacbe..9a3ab58 100644
> --- a/drivers/net/ethernet/3com/typhoon.c
> +++ b/drivers/net/ethernet/3com/typhoon.c
> @@ -2404,6 +2404,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>  
>   if(!is_valid_ether_addr(dev->dev_addr)) {
>   err_msg = "Could not obtain valid ethernet address, aborting";
> + err = -EIO;
>   goto error_out_reset;

The change above is fine, but the other two should use the return value
from the failing function call.


> @@ -2413,6 +2414,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>   INIT_COMMAND_WITH_RESPONSE(_cmd, TYPHOON_CMD_READ_VERSIONS);
>   if(typhoon_issue_command(tp, 1, _cmd, 3, xp_resp) < 0) {
>   err_msg = "Could not get Sleep Image version";
> + err = -EIO;
>   goto error_out_reset;
>   }
>  
> @@ -2455,6 +2457,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>  
>   if(register_netdev(dev) < 0) {
>   err_msg = "unable to register netdev";
> + err = -EIO;
>   goto error_out_reset;
>   }
>  

Re: [PATCH] drivers: net: ethernet: 3com: fix return value

[David Dillow]

On Sat, 2016-12-24 at 00:00 +0100, Thomas Preisner wrote:
> diff --git a/drivers/net/ethernet/3com/typhoon.c 
> b/drivers/net/ethernet/3com/typhoon.c
> index a0cacbe..9a3ab58 100644
> --- a/drivers/net/ethernet/3com/typhoon.c
> +++ b/drivers/net/ethernet/3com/typhoon.c
> @@ -2404,6 +2404,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>  
>   if(!is_valid_ether_addr(dev->dev_addr)) {
>   err_msg = "Could not obtain valid ethernet address, aborting";
> + err = -EIO;
>   goto error_out_reset;

The change above is fine, but the other two should use the return value
from the failing function call.


> @@ -2413,6 +2414,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>   INIT_COMMAND_WITH_RESPONSE(_cmd, TYPHOON_CMD_READ_VERSIONS);
>   if(typhoon_issue_command(tp, 1, _cmd, 3, xp_resp) < 0) {
>   err_msg = "Could not get Sleep Image version";
> + err = -EIO;
>   goto error_out_reset;
>   }
>  
> @@ -2455,6 +2457,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>  
>   if(register_netdev(dev) < 0) {
>   err_msg = "unable to register netdev";
> + err = -EIO;
>   goto error_out_reset;
>   }
>  

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

[George Spelvin]

Hannes Frederic Sowa wrote:
> On 24.12.2016 00:39, George Spelvin wrote:
>> We just finished discussing why 8 bytes isn't enough.  If you only
>> feed back 8 bytes, an attacker who can do 2^64 computation can find it
>> (by guessing and computing forward to verify the guess) and recover the
>> previous state.  You need to feed back at least as much output as your
>> security targete.  For /dev/urandom's ChaCha20, that's 256 bits.

> I followed the discussion but it appeared to me that this has the
> additional constraint of time until the next reseeding event happenes,
> which is 300s (under the assumption that calls to get_random_int happen
> regularly, which I expect right now). After that the existing reseeding
> mechansim will ensure enough backtracking protection. The number of
> bytes can easily be increased here, given that reseeding was shown to be
> quite fast already and we produce enough output. But I am not sure if
> this is a bit overengineered in the end?

I'm not following your description of how the time-based and call-based
mechanisms interact, but for any mix-back, you should either do enough
or none at all.  (Also called "catastrophic reseeding".)

For example, two mix-backs of 64 bits gives you 65 bit security, not 128.
(Because each mixback can be guessed and verified separately.)

> Also agreed. Given your solution below to prandom_u32, I do think it
> might also work without the seqlock now.

It's not technically a seqlock; in particular the reader doesn't
spin.  But the write side, and general logic is so similar it's
a good mental model.

Basically, assume a 64-byte buffer.  The reader has gone through
32 bytes of it, and has 32 left, and when he reads another 8 bytes,
has to distinguish three cases:

1) No update; we read the old bytes and there are now 32 - 24 bytes left.
2) Update completed while we weren't looking.  There are now new
   bytes in the buffer, and we took 8 leaving 64 - 8 = 56.
3) Update in progress at the time of the read.  We don't know if we
   are seeing old bytes or new bytes, so we have to assume the worst
   and not proceeed unless 32 >= 8, but assume at the end there are
   64 - 8 = 56 new bytes left.

> I wouldn't have added a disable irqs, but given that I really like your
> proposal, I would take it in my todo branch and submit it when net-next
> window opens.

If you want that, I have a pile of patches to prandom I really
should push upstream.  Shall I refresh them and send them to you?


commit 4cf1b3d9f4fbccc29ffc2fe4ca4ff52ea77253f1
Author: George Spelvin 
Date:   Mon Aug 31 00:05:00 2015 -0400

net: Use prandom_u32_max()

It's slightly more efficient than "prandom_u32() % range"

The net/802 code was already efficient, but prandom_u32_max() is simpler.

In net/batman-adv/bat_iv_ogm.c, batadv_iv_ogm_fwd_send_time() got changed
from picking a random number of milliseconds and converting to jiffies to
picking a random number of jiffies, since the number of milliseconds (and
thus the conversion to jiffies) is a compile-time constant.  The equivalent
code in batadv_iv_ogm_emit_send_time was not changed, because the number
of milliseconds is variable.

In net/ipv6/ip6_flowlabel.c, ip6_flowlabel had htonl(prandom_u32()),
which is silly.  Just cast to __be32 without permuting the bits.

net/sched/sch_netem.c got adjusted to only need one call to prandom_u32
instead of 2.  (Assuming skb_headlen can't exceed 512 MiB, which is
hopefully safe for some time yet.)

Signed-off-by: George Spelvin 

commit 9c8fb80e1fd2be42c35cab1af27187d600fd85e3
Author: George Spelvin 
Date:   Sat May 24 15:20:47 2014 -0400

mm/swapfile.c: Use prandom_u32_max()

It's slightly more efficient than "prandom_u32() % range"

Signed-off-by: George Spelvin 

commit 2743eb01e5c5958fd88ae78d19c5fea772d4b117
Author: George Spelvin 
Date:   Sat May 24 15:19:53 2014 -0400

lib: Use prandom_u32_max()

It's slightly more efficient than "prandom_u32() % range"

Signed-off-by: George Spelvin 

commit 6a5e91bf395060a3351bfe5efc40ac20ffba2c1b
Author: George Spelvin 
Date:   Sat May 24 15:18:50 2014 -0400

fs/xfs: Use prandom_u32_max()

It's slightly more efficient than "prandom_u32() % range".

Also changed the last argument of xfs_error_test() from "unsigned long"
to "unsigned", since the code never did support values > 2^32, and
the largest value ever passed is 100.

The code could be improved even further by passing in 2^32/rf rather
than rf, but I'll leave that to some XFS developers.

Signed-off-by: George Spelvin 

commit 6f6d485d9179ca6ec4e30caa06ade0e0c6931810
Author: George Spelvin 
Date:   Sat May 24 15:00:17 2014 -0400

fs/ubifs: Use 

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

[George Spelvin]

Hannes Frederic Sowa wrote:
> On 24.12.2016 00:39, George Spelvin wrote:
>> We just finished discussing why 8 bytes isn't enough.  If you only
>> feed back 8 bytes, an attacker who can do 2^64 computation can find it
>> (by guessing and computing forward to verify the guess) and recover the
>> previous state.  You need to feed back at least as much output as your
>> security targete.  For /dev/urandom's ChaCha20, that's 256 bits.

> I followed the discussion but it appeared to me that this has the
> additional constraint of time until the next reseeding event happenes,
> which is 300s (under the assumption that calls to get_random_int happen
> regularly, which I expect right now). After that the existing reseeding
> mechansim will ensure enough backtracking protection. The number of
> bytes can easily be increased here, given that reseeding was shown to be
> quite fast already and we produce enough output. But I am not sure if
> this is a bit overengineered in the end?

I'm not following your description of how the time-based and call-based
mechanisms interact, but for any mix-back, you should either do enough
or none at all.  (Also called "catastrophic reseeding".)

For example, two mix-backs of 64 bits gives you 65 bit security, not 128.
(Because each mixback can be guessed and verified separately.)

> Also agreed. Given your solution below to prandom_u32, I do think it
> might also work without the seqlock now.

It's not technically a seqlock; in particular the reader doesn't
spin.  But the write side, and general logic is so similar it's
a good mental model.

Basically, assume a 64-byte buffer.  The reader has gone through
32 bytes of it, and has 32 left, and when he reads another 8 bytes,
has to distinguish three cases:

1) No update; we read the old bytes and there are now 32 - 24 bytes left.
2) Update completed while we weren't looking.  There are now new
   bytes in the buffer, and we took 8 leaving 64 - 8 = 56.
3) Update in progress at the time of the read.  We don't know if we
   are seeing old bytes or new bytes, so we have to assume the worst
   and not proceeed unless 32 >= 8, but assume at the end there are
   64 - 8 = 56 new bytes left.

> I wouldn't have added a disable irqs, but given that I really like your
> proposal, I would take it in my todo branch and submit it when net-next
> window opens.

If you want that, I have a pile of patches to prandom I really
should push upstream.  Shall I refresh them and send them to you?


commit 4cf1b3d9f4fbccc29ffc2fe4ca4ff52ea77253f1
Author: George Spelvin 
Date:   Mon Aug 31 00:05:00 2015 -0400

net: Use prandom_u32_max()

It's slightly more efficient than "prandom_u32() % range"

The net/802 code was already efficient, but prandom_u32_max() is simpler.

In net/batman-adv/bat_iv_ogm.c, batadv_iv_ogm_fwd_send_time() got changed
from picking a random number of milliseconds and converting to jiffies to
picking a random number of jiffies, since the number of milliseconds (and
thus the conversion to jiffies) is a compile-time constant.  The equivalent
code in batadv_iv_ogm_emit_send_time was not changed, because the number
of milliseconds is variable.

In net/ipv6/ip6_flowlabel.c, ip6_flowlabel had htonl(prandom_u32()),
which is silly.  Just cast to __be32 without permuting the bits.

net/sched/sch_netem.c got adjusted to only need one call to prandom_u32
instead of 2.  (Assuming skb_headlen can't exceed 512 MiB, which is
hopefully safe for some time yet.)

Signed-off-by: George Spelvin 

commit 9c8fb80e1fd2be42c35cab1af27187d600fd85e3
Author: George Spelvin 
Date:   Sat May 24 15:20:47 2014 -0400

mm/swapfile.c: Use prandom_u32_max()

It's slightly more efficient than "prandom_u32() % range"

Signed-off-by: George Spelvin 

commit 2743eb01e5c5958fd88ae78d19c5fea772d4b117
Author: George Spelvin 
Date:   Sat May 24 15:19:53 2014 -0400

lib: Use prandom_u32_max()

It's slightly more efficient than "prandom_u32() % range"

Signed-off-by: George Spelvin 

commit 6a5e91bf395060a3351bfe5efc40ac20ffba2c1b
Author: George Spelvin 
Date:   Sat May 24 15:18:50 2014 -0400

fs/xfs: Use prandom_u32_max()

It's slightly more efficient than "prandom_u32() % range".

Also changed the last argument of xfs_error_test() from "unsigned long"
to "unsigned", since the code never did support values > 2^32, and
the largest value ever passed is 100.

The code could be improved even further by passing in 2^32/rf rather
than rf, but I'll leave that to some XFS developers.

Signed-off-by: George Spelvin 

commit 6f6d485d9179ca6ec4e30caa06ade0e0c6931810
Author: George Spelvin 
Date:   Sat May 24 15:00:17 2014 -0400

fs/ubifs: Use prandom_u32_max()

It's slightly more efficient than "prandom_u32() % range".

In fs/ubifs/debug.c, the chance() function got rewritten entirely
to take advantage 

RE: [PATCH] scsi: bfa: Increase requested firmware version to 3.2.5.1

[Mody, Rasesh]

> From: Benjamin Poirier [mailto:benjamin.poir...@gmail.com] On Behalf Of
> Benjamin Poirier
> Sent: Friday, December 23, 2016 2:01 PM
> 
> bna & bfa firmware version 3.2.5.1 was submitted to linux-firmware on Tue
> Feb 17 19:10:20 2015 -0500 in 0ab54ff1dc ("linux-firmware: Add QLogic BR
> Series Adapter Firmware").
> 
> bna was updated to use the newer firmware on Thu, 19 Feb 2015 16:02:32
> -0500 in 3f307c3d70 ("bna: Update the Driver and Firmware Version")
> 
> bfa was not updated. I presume this was an oversight but it broke support
> for bfa+bna cards such as the following
>   04:00.0 Fibre Channel [0c04]: Brocade Communications Systems, Inc.
>   1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
>   04:00.1 Fibre Channel [0c04]: Brocade Communications Systems, Inc.
>   1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
>   04:00.2 Ethernet controller [0200]: Brocade Communications
> Systems,
>   Inc. 1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
>   04:00.3 Ethernet controller [0200]: Brocade Communications
> Systems,
>   Inc. 1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
> 
> Currently, if the bfa module is loaded first, bna fails to probe the 
> respective
> devices with [  215.026787] bna: QLogic BR-series 10G Ethernet driver -
> version: 3.2.25.1 [  215.043707] bna :04:00.2: bar0 mapped to
> c90001fc, len 262144 [  215.060656] bna :04:00.2: initialization
> failed err=1 [  215.073893] bna :04:00.3: bar0 mapped to
> c9000204, len 262144 [  215.090644] bna :04:00.3: initialization
> failed err=1
> 
> Whereas if bna is loaded first, bfa fails with [  249.592109] QLogic BR-series
> BFA FC/FCOE SCSI driver - version: 3.2.25.0 [  249.610738] bfa :04:00.0:
> Running firmware version is incompatible with the driver version [
> 249.833513] bfa :04:00.0: bfa init failed [  249.833919] scsi host6: 
> QLogic
> BR-series FC/FCOE Adapter, hwpath: :04:00.0 driver: 3.2.25.0 [
> 249.841446] bfa :04:00.1: Running firmware version is incompatible with
> the driver version [  250.045449] bfa :04:00.1: bfa init failed [  
> 250.045962]
> scsi host7: QLogic BR-series FC/FCOE Adapter, hwpath: :04:00.1 driver:
> 3.2.25.0
> 
> Increase bfa's requested firmware version.
> I only tested that all of the devices probe without error.
> 
> Cc: Rasesh Mody 
> Reported-by: Tim Ehlers 
> Signed-off-by: Benjamin Poirier 

Acked-by: Rasesh Mody  

Thanks! We also need to bump up the BFA driver version to 3.2.25.1.

> ---
>  drivers/scsi/bfa/bfad.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c index
> 9d253cb..e70410b 100644
> --- a/drivers/scsi/bfa/bfad.c
> +++ b/drivers/scsi/bfa/bfad.c
> @@ -64,9 +64,9 @@ int max_rport_logins =
> BFA_FCS_MAX_RPORT_LOGINS;
>  u32  bfi_image_cb_size, bfi_image_ct_size, bfi_image_ct2_size;
>  u32  *bfi_image_cb, *bfi_image_ct, *bfi_image_ct2;
> 
> -#define BFAD_FW_FILE_CB  "cbfw-3.2.3.0.bin"
> -#define BFAD_FW_FILE_CT  "ctfw-3.2.3.0.bin"
> -#define BFAD_FW_FILE_CT2 "ct2fw-3.2.3.0.bin"
> +#define BFAD_FW_FILE_CB  "cbfw-3.2.5.1.bin"
> +#define BFAD_FW_FILE_CT  "ctfw-3.2.5.1.bin"
> +#define BFAD_FW_FILE_CT2 "ct2fw-3.2.5.1.bin"
> 
>  static u32 *bfad_load_fwimg(struct pci_dev *pdev);  static void
> bfad_free_fwimg(void);
> --
> 2.10.2

RE: [PATCH] scsi: bfa: Increase requested firmware version to 3.2.5.1

[Mody, Rasesh]

> From: Benjamin Poirier [mailto:benjamin.poir...@gmail.com] On Behalf Of
> Benjamin Poirier
> Sent: Friday, December 23, 2016 2:01 PM
> 
> bna & bfa firmware version 3.2.5.1 was submitted to linux-firmware on Tue
> Feb 17 19:10:20 2015 -0500 in 0ab54ff1dc ("linux-firmware: Add QLogic BR
> Series Adapter Firmware").
> 
> bna was updated to use the newer firmware on Thu, 19 Feb 2015 16:02:32
> -0500 in 3f307c3d70 ("bna: Update the Driver and Firmware Version")
> 
> bfa was not updated. I presume this was an oversight but it broke support
> for bfa+bna cards such as the following
>   04:00.0 Fibre Channel [0c04]: Brocade Communications Systems, Inc.
>   1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
>   04:00.1 Fibre Channel [0c04]: Brocade Communications Systems, Inc.
>   1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
>   04:00.2 Ethernet controller [0200]: Brocade Communications
> Systems,
>   Inc. 1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
>   04:00.3 Ethernet controller [0200]: Brocade Communications
> Systems,
>   Inc. 1010/1020/1007/1741 10Gbps CNA [1657:0014] (rev 01)
> 
> Currently, if the bfa module is loaded first, bna fails to probe the 
> respective
> devices with [  215.026787] bna: QLogic BR-series 10G Ethernet driver -
> version: 3.2.25.1 [  215.043707] bna :04:00.2: bar0 mapped to
> c90001fc, len 262144 [  215.060656] bna :04:00.2: initialization
> failed err=1 [  215.073893] bna :04:00.3: bar0 mapped to
> c9000204, len 262144 [  215.090644] bna :04:00.3: initialization
> failed err=1
> 
> Whereas if bna is loaded first, bfa fails with [  249.592109] QLogic BR-series
> BFA FC/FCOE SCSI driver - version: 3.2.25.0 [  249.610738] bfa :04:00.0:
> Running firmware version is incompatible with the driver version [
> 249.833513] bfa :04:00.0: bfa init failed [  249.833919] scsi host6: 
> QLogic
> BR-series FC/FCOE Adapter, hwpath: :04:00.0 driver: 3.2.25.0 [
> 249.841446] bfa :04:00.1: Running firmware version is incompatible with
> the driver version [  250.045449] bfa :04:00.1: bfa init failed [  
> 250.045962]
> scsi host7: QLogic BR-series FC/FCOE Adapter, hwpath: :04:00.1 driver:
> 3.2.25.0
> 
> Increase bfa's requested firmware version.
> I only tested that all of the devices probe without error.
> 
> Cc: Rasesh Mody 
> Reported-by: Tim Ehlers 
> Signed-off-by: Benjamin Poirier 

Acked-by: Rasesh Mody  

Thanks! We also need to bump up the BFA driver version to 3.2.25.1.

> ---
>  drivers/scsi/bfa/bfad.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c index
> 9d253cb..e70410b 100644
> --- a/drivers/scsi/bfa/bfad.c
> +++ b/drivers/scsi/bfa/bfad.c
> @@ -64,9 +64,9 @@ int max_rport_logins =
> BFA_FCS_MAX_RPORT_LOGINS;
>  u32  bfi_image_cb_size, bfi_image_ct_size, bfi_image_ct2_size;
>  u32  *bfi_image_cb, *bfi_image_ct, *bfi_image_ct2;
> 
> -#define BFAD_FW_FILE_CB  "cbfw-3.2.3.0.bin"
> -#define BFAD_FW_FILE_CT  "ctfw-3.2.3.0.bin"
> -#define BFAD_FW_FILE_CT2 "ct2fw-3.2.3.0.bin"
> +#define BFAD_FW_FILE_CB  "cbfw-3.2.5.1.bin"
> +#define BFAD_FW_FILE_CT  "ctfw-3.2.5.1.bin"
> +#define BFAD_FW_FILE_CT2 "ct2fw-3.2.5.1.bin"
> 
>  static u32 *bfad_load_fwimg(struct pci_dev *pdev);  static void
> bfad_free_fwimg(void);
> --
> 2.10.2

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

[Hannes Frederic Sowa]

Hi,

On 24.12.2016 00:39, George Spelvin wrote:
> Hannes Frederic Sowa wrote:
>> In general this looks good, but bitbuffer needs to be protected from
>> concurrent access, thus needing at least some atomic instruction and
>> disabling of interrupts for the locking if done outside of
>> get_random_long. Thus I liked your previous approach more where you
>> simply embed this in the already necessary get_random_long and aliased
>> get_random_long as get_random_bits(BITS_PER_LONG) accordingly, IMHO.
> 
> It's meant to be part of the same approach, and I didn't include locking
> because that's a requirement for *any* solution, and isn't specific
> to the part I was trying to illustrate.
> 
> (As for re-using the name "get_random_long", that was just so
> I didn't have to explain it.  Call it "get_random_long_internal"
> if you like.)
> 
> Possible locking implementations include:
> 1) Use the same locking as applies to get_random_long_internal(), or
> 2) Make bitbuffer a per-CPU variable (note that we currently have 128
>bits of per-CPU state in get_random_int_hash[]), and this is all a
>fast-path to bypass heavier locking in get_random_long_internal().

I understood that this is definitely a solvable problem.

>>> But, I just realized I've been overlooking something glaringly obvious...
>>> there's no reason you can't compute multple blocks in advance.
>>
>> In the current code on the cost of per cpu allocations thus memory.
> 
> Yes, but on 4-core machines it's still not much, and 4096-core
> behemoths have RAM to burn.
> 
>> In the extract_crng case, couldn't we simply use 8 bytes of the 64 byte
>> return block to feed it directly back into the state chacha? So we pass
>> on 56 bytes into the pcpu buffer, and consume 8 bytes for the next
>> state. This would make the window max shorter than the anti
>> backtracking protection right now from 300s to 14 get_random_int calls.
>> Not sure if this is worth it.
> 
> We just finished discussing why 8 bytes isn't enough.  If you only
> feed back 8 bytes, an attacker who can do 2^64 computation can find it
> (by guessing and computing forward to verify the guess) and recover the
> previous state.  You need to feed back at least as much output as your
> security targete.  For /dev/urandom's ChaCha20, that's 256 bits.

I followed the discussion but it appeared to me that this has the
additional constraint of time until the next reseeding event happenes,
which is 300s (under the assumption that calls to get_random_int happen
regularly, which I expect right now). After that the existing reseeding
mechansim will ensure enough backtracking protection. The number of
bytes can easily be increased here, given that reseeding was shown to be
quite fast already and we produce enough output. But I am not sure if
this is a bit overengineered in the end?

>>> For example, suppose we gave each CPU a small pool to minimize locking.
>>> When one runs out and calls the global refill, it could refill *all*
>>> of the CPU pools.  (You don't even need locking; there may be a race to
>>> determine *which* random numbers the reader sees, but they're equally
>>> good either way.)
> 
>> Yes, but still disabled interrupts, otherwise the same state could be
>> used twice on the same CPU. Uff, I think we have this problem in
>> prandom_u32.
> 
> There are some locking gotchas, but it is doable lock-free.
> 
> Basically, it's a seqlock.  The writer increments it once (to an odd
> number) before starting to overwrite the buffer, and a second time (to
> an even number) after.  "Before" and "after" mean smp_wmb().
> 
> The reader can use this to figure out how much of the data in the buffer
> is safely fresh.  The full sequence of checks is a bit intricate,
> but straightforward.
> 
> I didn't discuss the locking because I'm confident it's solvable,
> not because I wasn't aware it has to be solved.

Also agreed. Given your solution below to prandom_u32, I do think it
might also work without the seqlock now.

> As for prandom_u32(), what's the problem?  Are you worried that
> get_cpu_var disables preemption but not interrupts, and so an
> ISR might return the same value as process-level code?

Yes, exactly those were my thoughts.

> First of all, that's not a problem because prandom_u32() doesn't
> have security guarantees.  Occasionally returning a dupicate number
> is okay.
>
> Second, if you do care, that could be trivially fixed by throwing
> a barrier() in the middle of the code.  (Patch appended; S-o-B
> if anyone wants it.)

I wouldn't have added a disable irqs, but given that I really like your
proposal, I would take it in my todo branch and submit it when net-next
window opens.

> diff --git a/lib/random32.c b/lib/random32.c
> index c750216d..6bee4a36 100644
> --- a/lib/random32.c
> +++ b/lib/random32.c
> [...]

Thanks,
Hannes

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

[Hannes Frederic Sowa]

Hi,

On 24.12.2016 00:39, George Spelvin wrote:
> Hannes Frederic Sowa wrote:
>> In general this looks good, but bitbuffer needs to be protected from
>> concurrent access, thus needing at least some atomic instruction and
>> disabling of interrupts for the locking if done outside of
>> get_random_long. Thus I liked your previous approach more where you
>> simply embed this in the already necessary get_random_long and aliased
>> get_random_long as get_random_bits(BITS_PER_LONG) accordingly, IMHO.
> 
> It's meant to be part of the same approach, and I didn't include locking
> because that's a requirement for *any* solution, and isn't specific
> to the part I was trying to illustrate.
> 
> (As for re-using the name "get_random_long", that was just so
> I didn't have to explain it.  Call it "get_random_long_internal"
> if you like.)
> 
> Possible locking implementations include:
> 1) Use the same locking as applies to get_random_long_internal(), or
> 2) Make bitbuffer a per-CPU variable (note that we currently have 128
>bits of per-CPU state in get_random_int_hash[]), and this is all a
>fast-path to bypass heavier locking in get_random_long_internal().

I understood that this is definitely a solvable problem.

>>> But, I just realized I've been overlooking something glaringly obvious...
>>> there's no reason you can't compute multple blocks in advance.
>>
>> In the current code on the cost of per cpu allocations thus memory.
> 
> Yes, but on 4-core machines it's still not much, and 4096-core
> behemoths have RAM to burn.
> 
>> In the extract_crng case, couldn't we simply use 8 bytes of the 64 byte
>> return block to feed it directly back into the state chacha? So we pass
>> on 56 bytes into the pcpu buffer, and consume 8 bytes for the next
>> state. This would make the window max shorter than the anti
>> backtracking protection right now from 300s to 14 get_random_int calls.
>> Not sure if this is worth it.
> 
> We just finished discussing why 8 bytes isn't enough.  If you only
> feed back 8 bytes, an attacker who can do 2^64 computation can find it
> (by guessing and computing forward to verify the guess) and recover the
> previous state.  You need to feed back at least as much output as your
> security targete.  For /dev/urandom's ChaCha20, that's 256 bits.

I followed the discussion but it appeared to me that this has the
additional constraint of time until the next reseeding event happenes,
which is 300s (under the assumption that calls to get_random_int happen
regularly, which I expect right now). After that the existing reseeding
mechansim will ensure enough backtracking protection. The number of
bytes can easily be increased here, given that reseeding was shown to be
quite fast already and we produce enough output. But I am not sure if
this is a bit overengineered in the end?

>>> For example, suppose we gave each CPU a small pool to minimize locking.
>>> When one runs out and calls the global refill, it could refill *all*
>>> of the CPU pools.  (You don't even need locking; there may be a race to
>>> determine *which* random numbers the reader sees, but they're equally
>>> good either way.)
> 
>> Yes, but still disabled interrupts, otherwise the same state could be
>> used twice on the same CPU. Uff, I think we have this problem in
>> prandom_u32.
> 
> There are some locking gotchas, but it is doable lock-free.
> 
> Basically, it's a seqlock.  The writer increments it once (to an odd
> number) before starting to overwrite the buffer, and a second time (to
> an even number) after.  "Before" and "after" mean smp_wmb().
> 
> The reader can use this to figure out how much of the data in the buffer
> is safely fresh.  The full sequence of checks is a bit intricate,
> but straightforward.
> 
> I didn't discuss the locking because I'm confident it's solvable,
> not because I wasn't aware it has to be solved.

Also agreed. Given your solution below to prandom_u32, I do think it
might also work without the seqlock now.

> As for prandom_u32(), what's the problem?  Are you worried that
> get_cpu_var disables preemption but not interrupts, and so an
> ISR might return the same value as process-level code?

Yes, exactly those were my thoughts.

> First of all, that's not a problem because prandom_u32() doesn't
> have security guarantees.  Occasionally returning a dupicate number
> is okay.
>
> Second, if you do care, that could be trivially fixed by throwing
> a barrier() in the middle of the code.  (Patch appended; S-o-B
> if anyone wants it.)

I wouldn't have added a disable irqs, but given that I really like your
proposal, I would take it in my todo branch and submit it when net-next
window opens.

> diff --git a/lib/random32.c b/lib/random32.c
> index c750216d..6bee4a36 100644
> --- a/lib/random32.c
> +++ b/lib/random32.c
> [...]

Thanks,
Hannes

Re: [PATCH 1/2] soc: ti: Use remoteproc auto_boot feature

[Suman Anna]

On 12/23/2016 11:05 AM, Suman Anna wrote:
> Hi Sarang,
> 
>>>
>>> On 12/15/2016 06:03 PM, Sarangdhar Joshi wrote:
 The function wkup_m3_rproc_boot_thread waits for asynchronous
 firmware loading to complete successfully before calling
 rproc_boot(). The same can be achieved by just setting
 rproc->auto_boot flag. Change this. As a result this change
 removes wkup_m3_rproc_boot_thread and moves m3_ipc->sync_complete
 initialization to the wkup_m3_ipc_probe().

 Other than the current usage, the firmware_loading_complete is
 only used in rproc_del() where it's no longer needed.  This
 change is in preparation for removing firmware_loading_complete
 completely.
>>>
>>> Based on the comments so far, I am assuming that you are dropping this
>>> series.
>>
>> No, may not be dropping this. Will try to handle it differently in
>> rproc_del() (probably by making use of some state flag).
>>>
>>> In any case, this series did break our PM stack. We definitely don't
>>> want to auto-boot the wkup_m3_rproc device, that responsibility will
>>> need to stay with the wkup_m3_ipc driver.
>>
>> Which scenario did it break? Booting up rproc device before
>> wkup_m3_ipc_probe() causes issues?
> 
> Yes, our state machine requires the wkup_m3_ipc driver to control the
> boot of the wkup_m3 remoteproc. The wkup_m3 is not a typical remoteproc,
> it is our PM master and is responsible for putting the host processor
> into suspend and waking it up in system suspend/cpuidle paths.
> The remoteproc infrastructure is only used for load/boot, but the Linux
> PM state machine and communication is all controlled by the wkup_m3_ipc
> driver.
> 
>>
>> Nevertheless, I think Bjorn's suggestion of just dropping the call to
>> wait_for_completion() and keeping kthread looks good, also because of
>> the fact that rproc_boot() anyways calls request_firmware() and no
>> longer needed to wait on asynchronous loading of firmware.
> 
> Yeah, I will have to test this, but looking at current code, this should
> mostly be ok because of the remoteproc core changes w.r.t resource table
> parsing.

Tested with just the wait_for_completion() removed and it works fine. I
can send a patch for the same if you prefer me to send it.

regards
Suman

> 
> regards
> Suman
> --
> To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 1/2] soc: ti: Use remoteproc auto_boot feature

[Suman Anna]

On 12/23/2016 11:05 AM, Suman Anna wrote:
> Hi Sarang,
> 
>>>
>>> On 12/15/2016 06:03 PM, Sarangdhar Joshi wrote:
 The function wkup_m3_rproc_boot_thread waits for asynchronous
 firmware loading to complete successfully before calling
 rproc_boot(). The same can be achieved by just setting
 rproc->auto_boot flag. Change this. As a result this change
 removes wkup_m3_rproc_boot_thread and moves m3_ipc->sync_complete
 initialization to the wkup_m3_ipc_probe().

 Other than the current usage, the firmware_loading_complete is
 only used in rproc_del() where it's no longer needed.  This
 change is in preparation for removing firmware_loading_complete
 completely.
>>>
>>> Based on the comments so far, I am assuming that you are dropping this
>>> series.
>>
>> No, may not be dropping this. Will try to handle it differently in
>> rproc_del() (probably by making use of some state flag).
>>>
>>> In any case, this series did break our PM stack. We definitely don't
>>> want to auto-boot the wkup_m3_rproc device, that responsibility will
>>> need to stay with the wkup_m3_ipc driver.
>>
>> Which scenario did it break? Booting up rproc device before
>> wkup_m3_ipc_probe() causes issues?
> 
> Yes, our state machine requires the wkup_m3_ipc driver to control the
> boot of the wkup_m3 remoteproc. The wkup_m3 is not a typical remoteproc,
> it is our PM master and is responsible for putting the host processor
> into suspend and waking it up in system suspend/cpuidle paths.
> The remoteproc infrastructure is only used for load/boot, but the Linux
> PM state machine and communication is all controlled by the wkup_m3_ipc
> driver.
> 
>>
>> Nevertheless, I think Bjorn's suggestion of just dropping the call to
>> wait_for_completion() and keeping kthread looks good, also because of
>> the fact that rproc_boot() anyways calls request_firmware() and no
>> longer needed to wait on asynchronous loading of firmware.
> 
> Yeah, I will have to test this, but looking at current code, this should
> mostly be ok because of the remoteproc core changes w.r.t resource table
> parsing.

Tested with just the wait_for_completion() removed and it works fine. I
can send a patch for the same if you prefer me to send it.

regards
Suman

> 
> regards
> Suman
> --
> To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

[George Spelvin]

Hannes Frederic Sowa wrote:
> In general this looks good, but bitbuffer needs to be protected from
> concurrent access, thus needing at least some atomic instruction and
> disabling of interrupts for the locking if done outside of
> get_random_long. Thus I liked your previous approach more where you
> simply embed this in the already necessary get_random_long and aliased
> get_random_long as get_random_bits(BITS_PER_LONG) accordingly, IMHO.

It's meant to be part of the same approach, and I didn't include locking
because that's a requirement for *any* solution, and isn't specific
to the part I was trying to illustrate.

(As for re-using the name "get_random_long", that was just so
I didn't have to explain it.  Call it "get_random_long_internal"
if you like.)

Possible locking implementations include:
1) Use the same locking as applies to get_random_long_internal(), or
2) Make bitbuffer a per-CPU variable (note that we currently have 128
   bits of per-CPU state in get_random_int_hash[]), and this is all a
   fast-path to bypass heavier locking in get_random_long_internal().

>> But, I just realized I've been overlooking something glaringly obvious...
>> there's no reason you can't compute multple blocks in advance.
>
> In the current code on the cost of per cpu allocations thus memory.

Yes, but on 4-core machines it's still not much, and 4096-core
behemoths have RAM to burn.

> In the extract_crng case, couldn't we simply use 8 bytes of the 64 byte
> return block to feed it directly back into the state chacha? So we pass
> on 56 bytes into the pcpu buffer, and consume 8 bytes for the next
> state. This would make the window max shorter than the anti
> backtracking protection right now from 300s to 14 get_random_int calls.
> Not sure if this is worth it.

We just finished discussing why 8 bytes isn't enough.  If you only
feed back 8 bytes, an attacker who can do 2^64 computation can find it
(by guessing and computing forward to verify the guess) and recover the
previous state.  You need to feed back at least as much output as your
security targete.  For /dev/urandom's ChaCha20, that's 256 bits.

>> For example, suppose we gave each CPU a small pool to minimize locking.
>> When one runs out and calls the global refill, it could refill *all*
>> of the CPU pools.  (You don't even need locking; there may be a race to
>> determine *which* random numbers the reader sees, but they're equally
>> good either way.)

> Yes, but still disabled interrupts, otherwise the same state could be
> used twice on the same CPU. Uff, I think we have this problem in
> prandom_u32.

There are some locking gotchas, but it is doable lock-free.

Basically, it's a seqlock.  The writer increments it once (to an odd
number) before starting to overwrite the buffer, and a second time (to
an even number) after.  "Before" and "after" mean smp_wmb().

The reader can use this to figure out how much of the data in the buffer
is safely fresh.  The full sequence of checks is a bit intricate,
but straightforward.

I didn't discuss the locking because I'm confident it's solvable,
not because I wasn't aware it has to be solved.

As for prandom_u32(), what's the problem?  Are you worried that
get_cpu_var disables preemption but not interrupts, and so an
ISR might return the same value as process-level code?

First of all, that's not a problem because prandom_u32() doesn't
have security guarantees.  Occasionally returning a dupicate number
is okay.

Second, if you do care, that could be trivially fixed by throwing
a barrier() in the middle of the code.  (Patch appended; S-o-B
if anyone wants it.)


diff --git a/lib/random32.c b/lib/random32.c
index c750216d..6bee4a36 100644
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -55,16 +55,29 @@ static DEFINE_PER_CPU(struct rnd_state, net_rand_state);
  *
  * This is used for pseudo-randomness with no outside seeding.
  * For more random results, use prandom_u32().
+ *
+ * The barrier() is to allow prandom_u32() to be called from interupt
+ * context without locking.  An interrupt will run to completion,
+ * updating all four state variables.  The barrier() ensures that
+ * the interrupted code will compute a different result.  Either it
+ * will have written s1 and s2 (so the interrupt will start with
+ * the updated values), or it will use the values of s3 and s4
+ * updated by the interrupt.
+ *
+ * (The same logic applies recursively to nested interrupts, trap
+ * handlers, and NMIs.)
  */
 u32 prandom_u32_state(struct rnd_state *state)
 {
+   register u32 x;
 #define TAUSWORTHE(s, a, b, c, d) ((s & c) << d) ^ (((s << a) ^ s) >> b)
-   state->s1 = TAUSWORTHE(state->s1,  6, 13, 4294967294U, 18U);
-   state->s2 = TAUSWORTHE(state->s2,  2, 27, 4294967288U,  2U);
-   state->s3 = TAUSWORTHE(state->s3, 13, 21, 4294967280U,  7U);
-   state->s4 = TAUSWORTHE(state->s4,  3, 12, 4294967168U, 13U);
+   x  = state->s1 = TAUSWORTHE(state->s1,  6, 13,   

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

[George Spelvin]

Hannes Frederic Sowa wrote:
> In general this looks good, but bitbuffer needs to be protected from
> concurrent access, thus needing at least some atomic instruction and
> disabling of interrupts for the locking if done outside of
> get_random_long. Thus I liked your previous approach more where you
> simply embed this in the already necessary get_random_long and aliased
> get_random_long as get_random_bits(BITS_PER_LONG) accordingly, IMHO.

It's meant to be part of the same approach, and I didn't include locking
because that's a requirement for *any* solution, and isn't specific
to the part I was trying to illustrate.

(As for re-using the name "get_random_long", that was just so
I didn't have to explain it.  Call it "get_random_long_internal"
if you like.)

Possible locking implementations include:
1) Use the same locking as applies to get_random_long_internal(), or
2) Make bitbuffer a per-CPU variable (note that we currently have 128
   bits of per-CPU state in get_random_int_hash[]), and this is all a
   fast-path to bypass heavier locking in get_random_long_internal().

>> But, I just realized I've been overlooking something glaringly obvious...
>> there's no reason you can't compute multple blocks in advance.
>
> In the current code on the cost of per cpu allocations thus memory.

Yes, but on 4-core machines it's still not much, and 4096-core
behemoths have RAM to burn.

> In the extract_crng case, couldn't we simply use 8 bytes of the 64 byte
> return block to feed it directly back into the state chacha? So we pass
> on 56 bytes into the pcpu buffer, and consume 8 bytes for the next
> state. This would make the window max shorter than the anti
> backtracking protection right now from 300s to 14 get_random_int calls.
> Not sure if this is worth it.

We just finished discussing why 8 bytes isn't enough.  If you only
feed back 8 bytes, an attacker who can do 2^64 computation can find it
(by guessing and computing forward to verify the guess) and recover the
previous state.  You need to feed back at least as much output as your
security targete.  For /dev/urandom's ChaCha20, that's 256 bits.

>> For example, suppose we gave each CPU a small pool to minimize locking.
>> When one runs out and calls the global refill, it could refill *all*
>> of the CPU pools.  (You don't even need locking; there may be a race to
>> determine *which* random numbers the reader sees, but they're equally
>> good either way.)

> Yes, but still disabled interrupts, otherwise the same state could be
> used twice on the same CPU. Uff, I think we have this problem in
> prandom_u32.

There are some locking gotchas, but it is doable lock-free.

Basically, it's a seqlock.  The writer increments it once (to an odd
number) before starting to overwrite the buffer, and a second time (to
an even number) after.  "Before" and "after" mean smp_wmb().

The reader can use this to figure out how much of the data in the buffer
is safely fresh.  The full sequence of checks is a bit intricate,
but straightforward.

I didn't discuss the locking because I'm confident it's solvable,
not because I wasn't aware it has to be solved.

As for prandom_u32(), what's the problem?  Are you worried that
get_cpu_var disables preemption but not interrupts, and so an
ISR might return the same value as process-level code?

First of all, that's not a problem because prandom_u32() doesn't
have security guarantees.  Occasionally returning a dupicate number
is okay.

Second, if you do care, that could be trivially fixed by throwing
a barrier() in the middle of the code.  (Patch appended; S-o-B
if anyone wants it.)


diff --git a/lib/random32.c b/lib/random32.c
index c750216d..6bee4a36 100644
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -55,16 +55,29 @@ static DEFINE_PER_CPU(struct rnd_state, net_rand_state);
  *
  * This is used for pseudo-randomness with no outside seeding.
  * For more random results, use prandom_u32().
+ *
+ * The barrier() is to allow prandom_u32() to be called from interupt
+ * context without locking.  An interrupt will run to completion,
+ * updating all four state variables.  The barrier() ensures that
+ * the interrupted code will compute a different result.  Either it
+ * will have written s1 and s2 (so the interrupt will start with
+ * the updated values), or it will use the values of s3 and s4
+ * updated by the interrupt.
+ *
+ * (The same logic applies recursively to nested interrupts, trap
+ * handlers, and NMIs.)
  */
 u32 prandom_u32_state(struct rnd_state *state)
 {
+   register u32 x;
 #define TAUSWORTHE(s, a, b, c, d) ((s & c) << d) ^ (((s << a) ^ s) >> b)
-   state->s1 = TAUSWORTHE(state->s1,  6, 13, 4294967294U, 18U);
-   state->s2 = TAUSWORTHE(state->s2,  2, 27, 4294967288U,  2U);
-   state->s3 = TAUSWORTHE(state->s3, 13, 21, 4294967280U,  7U);
-   state->s4 = TAUSWORTHE(state->s4,  3, 12, 4294967168U, 13U);
+   x  = state->s1 = TAUSWORTHE(state->s1,  6, 13,   

[PATCH] cpufreq: intel_pstate: Do not expose PID parameters in passive mode

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

If intel_pstate works in the passive mode in which it acts as
a regular cpufreq driver and collaborates with generic cpufreq
governors, the PID parameters are not used, so do not expose
them via debugfs in that case.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpufreq/intel_pstate.c |9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -1018,10 +1018,6 @@ static void __init intel_pstate_debug_ex
struct dentry *debugfs_parent;
int i = 0;
 
-   if (hwp_active ||
-   pstate_funcs.get_target_pstate == get_target_pstate_use_cpu_load)
-   return;
-
debugfs_parent = debugfs_create_dir("pstate_snb", NULL);
if (IS_ERR_OR_NULL(debugfs_parent))
return;
@@ -2487,7 +2483,10 @@ hwp_cpu_matched:
if (rc)
goto out;
 
-   intel_pstate_debug_expose_params();
+   if (intel_pstate_driver == _pstate && !hwp_active &&
+   pstate_funcs.get_target_pstate != get_target_pstate_use_cpu_load)
+   intel_pstate_debug_expose_params();
+
intel_pstate_sysfs_expose_params();
 
if (hwp_active)

[PATCH] cpufreq: intel_pstate: Do not expose PID parameters in passive mode

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

If intel_pstate works in the passive mode in which it acts as
a regular cpufreq driver and collaborates with generic cpufreq
governors, the PID parameters are not used, so do not expose
them via debugfs in that case.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpufreq/intel_pstate.c |9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -1018,10 +1018,6 @@ static void __init intel_pstate_debug_ex
struct dentry *debugfs_parent;
int i = 0;
 
-   if (hwp_active ||
-   pstate_funcs.get_target_pstate == get_target_pstate_use_cpu_load)
-   return;
-
debugfs_parent = debugfs_create_dir("pstate_snb", NULL);
if (IS_ERR_OR_NULL(debugfs_parent))
return;
@@ -2487,7 +2483,10 @@ hwp_cpu_matched:
if (rc)
goto out;
 
-   intel_pstate_debug_expose_params();
+   if (intel_pstate_driver == _pstate && !hwp_active &&
+   pstate_funcs.get_target_pstate != get_target_pstate_use_cpu_load)
+   intel_pstate_debug_expose_params();
+
intel_pstate_sysfs_expose_params();
 
if (hwp_active)

Re: Converting DEVICE_ATTR to DEVICE_ATTR_{RO,RW,WO} and changing function names at the same time

[Guenter Roeck]

Hi Julia,

On Fri, Dec 23, 2016 at 04:54:41PM +0100, Julia Lawall wrote:
[ ... ]
> 
> // -
> @ro@
> declarer name SENSOR_DEVICE_ATTR, SENSOR_DEVICE_ATTR_2;
> identifier x,show;
> @@
> 
> \(SENSOR_DEVICE_ATTR\|SENSOR_DEVICE_ATTR_2\)
> (x, \(0444\|S_IRUGO\), show, NULL, ...);
> 

my version of spatch (?) does not like this construct.

$ spatch --version
spatch version 1.0.6-00036-gb62df17 compiled with OCaml version 4.02.3
Flags passed to the configure script: --prefix=/usr
Python scripting support: yes
Syntax of regular expresssions: PCRE

Is this something new, or am I doing something wrong ?

I played with it myself, and came up with the (less elegant) version
below. It isn't perfect (it does not handle the function-in-macro case
well), but it should give us a good comparison. Also, I might just get
rid of at least some of those macros; they just obfuscate the code anyway.

Thanks,
Guenter

---
@initialize:python@
@@

import re

// -
// Easy case

@d@
declarer name SENSOR_DEVICE_ATTR,SENSOR_DEVICE_ATTR_2;
identifier x,show,store;
expression p;
@@

(
  SENSOR_DEVICE_ATTR(x,p,show,store,...);
|
  SENSOR_DEVICE_ATTR_2(x,p,show,store,...);
)

@script:python expected@
show << d.show;
store << d.store;
x_show;
x_store;
func;
@@
coccinelle.func = re.sub('show_|get_|_show|_get|_read', '', show)
coccinelle.x_show = re.sub('show_|get_|_show|_get|_read', '', show) + "_show"
coccinelle.x_store = re.sub('show_|get_|_get|_show|_read', '', show) + "_store"

if show == "NULL":
coccinelle.x_store = re.sub('store_|set_|_set|_store|_write|_reset', '', 
store) + "_store"
coccinelle.func = re.sub('store_|set_|_store|_set|_write|_reset', '', store)

@@
declarer name SENSOR_DEVICE_ATTR_RO;
identifier d.x,expected.x_show,expected.func;
expression e;
@@

- SENSOR_DEVICE_ATTR(x, \(0444\|S_IRUGO\), x_show, NULL, e);
+ SENSOR_DEVICE_ATTR_RO(x, func, e);

@@
declarer name SENSOR_DEVICE_ATTR_WO;
identifier d.x,expected.x_store,expected.func;
expression e;
@@

- SENSOR_DEVICE_ATTR(x, \(0200\|S_IWUSR\), NULL, x_store, e);
+ SENSOR_DEVICE_ATTR_WO(x, func, e);

@@
declarer name SENSOR_DEVICE_ATTR_RW;
identifier d.x,expected.x_show,expected.x_store,expected.func;
expression e;
@@

- SENSOR_DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\|S_IWUSR|S_IRUGO\), x_show, 
x_store, e);
+ SENSOR_DEVICE_ATTR_RW(x, func, e);

@@
declarer name SENSOR_DEVICE_ATTR_2_RO;
identifier d.x,expected.x_show,expected.func;
expression e1,e2;
@@

- SENSOR_DEVICE_ATTR_2(x, \(0444\|S_IRUGO\), x_show, NULL, e1, e2);
+ SENSOR_DEVICE_ATTR_2_RO(x, func, e1, e2);

@@
declarer name SENSOR_DEVICE_ATTR_2_WO;
identifier d.x,expected.x_store,expected.func;
expression e1,e2;
@@

- SENSOR_DEVICE_ATTR_2(x, \(0200\|S_IWUSR\), NULL, x_store, e1, e2);
+ SENSOR_DEVICE_ATTR_2_WO(x, func, e1, e2);

@@
declarer name SENSOR_DEVICE_ATTR_2_RW;
identifier d.x,expected.x_show,expected.x_store,expected.func;
expression e1, e2;
@@

- SENSOR_DEVICE_ATTR_2(x, \(0644\|S_IRUGO|S_IWUSR\|S_IWUSR|S_IRUGO\), x_show, 
x_store, e1, e2);
+ SENSOR_DEVICE_ATTR_2_RW(x, func, e1, e2);

// -
// Other calls

@o@
declarer name SENSOR_DEVICE_ATTR,SENSOR_DEVICE_ATTR_2;
identifier d.x,show,store;
expression list es;
@@

(
SENSOR_DEVICE_ATTR(x,\(0444\|S_IRUGO\|0200\|S_IWUSR\|0644\|S_IRUGO|S_IWUSR\|S_IWUSR|S_IRUGO\),show,store,es);
|
SENSOR_DEVICE_ATTR_2(x,\(0444\|S_IRUGO\|0200\|S_IWUSR\|0644\|S_IRUGO|S_IWUSR\|S_IWUSR|S_IRUGO\),show,store,es);
)

// rename functions

@show1@
identifier o.show,expected.x_show;
parameter list ps;
@@

static
- show(ps)
+ x_show(ps)
  { ... }

@depends on show1@
identifier o.show,expected.x_show;
expression list es;
@@
- show(es)
+ x_show(es)

@depends on show1@
identifier o.show,expected.x_show;
@@
- show
+ x_show

@store1@
identifier o.store,expected.x_store;
parameter list ps;
@@

static
- store(ps)
+ x_store(ps)
  { ... }

@depends on store1@
identifier o.store,expected.x_store;
expression list es;
@@
- store(es)
+ x_store(es)

@depends on store1@
identifier o.store,expected.x_store;
@@
- store
+ x_store

// try again

@@
declarer name SENSOR_DEVICE_ATTR_RO;
identifier d.x,expected.x_show,expected.func;
expression e;
@@

- SENSOR_DEVICE_ATTR(x, \(0444\|S_IRUGO\), x_show, NULL, e);
+ SENSOR_DEVICE_ATTR_RO(x, func, e);

@@
declarer name SENSOR_DEVICE_ATTR_WO;
identifier d.x,expected.x_store,expected.func;
expression e;
@@

- SENSOR_DEVICE_ATTR(x, \(0200\|S_IWUSR\), NULL, x_store, e);
+ SENSOR_DEVICE_ATTR_WO(x, func, e);

@@
declarer name SENSOR_DEVICE_ATTR_RW;
identifier d.x,expected.x_show,expected.x_store,expected.func;
expression e;
@@

- SENSOR_DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\|S_IWUSR|S_IRUGO\), x_show, 
x_store, e);
+ SENSOR_DEVICE_ATTR_RW(x, func, e);

@@
declarer name SENSOR_DEVICE_ATTR_2_RO;
identifier d.x,expected.x_show,expected.func;
expression 

Re: Converting DEVICE_ATTR to DEVICE_ATTR_{RO,RW,WO} and changing function names at the same time

[Guenter Roeck]

Hi Julia,

On Fri, Dec 23, 2016 at 04:54:41PM +0100, Julia Lawall wrote:
[ ... ]
> 
> // -
> @ro@
> declarer name SENSOR_DEVICE_ATTR, SENSOR_DEVICE_ATTR_2;
> identifier x,show;
> @@
> 
> \(SENSOR_DEVICE_ATTR\|SENSOR_DEVICE_ATTR_2\)
> (x, \(0444\|S_IRUGO\), show, NULL, ...);
> 

my version of spatch (?) does not like this construct.

$ spatch --version
spatch version 1.0.6-00036-gb62df17 compiled with OCaml version 4.02.3
Flags passed to the configure script: --prefix=/usr
Python scripting support: yes
Syntax of regular expresssions: PCRE

Is this something new, or am I doing something wrong ?

I played with it myself, and came up with the (less elegant) version
below. It isn't perfect (it does not handle the function-in-macro case
well), but it should give us a good comparison. Also, I might just get
rid of at least some of those macros; they just obfuscate the code anyway.

Thanks,
Guenter

---
@initialize:python@
@@

import re

// -
// Easy case

@d@
declarer name SENSOR_DEVICE_ATTR,SENSOR_DEVICE_ATTR_2;
identifier x,show,store;
expression p;
@@

(
  SENSOR_DEVICE_ATTR(x,p,show,store,...);
|
  SENSOR_DEVICE_ATTR_2(x,p,show,store,...);
)

@script:python expected@
show << d.show;
store << d.store;
x_show;
x_store;
func;
@@
coccinelle.func = re.sub('show_|get_|_show|_get|_read', '', show)
coccinelle.x_show = re.sub('show_|get_|_show|_get|_read', '', show) + "_show"
coccinelle.x_store = re.sub('show_|get_|_get|_show|_read', '', show) + "_store"

if show == "NULL":
coccinelle.x_store = re.sub('store_|set_|_set|_store|_write|_reset', '', 
store) + "_store"
coccinelle.func = re.sub('store_|set_|_store|_set|_write|_reset', '', store)

@@
declarer name SENSOR_DEVICE_ATTR_RO;
identifier d.x,expected.x_show,expected.func;
expression e;
@@

- SENSOR_DEVICE_ATTR(x, \(0444\|S_IRUGO\), x_show, NULL, e);
+ SENSOR_DEVICE_ATTR_RO(x, func, e);

@@
declarer name SENSOR_DEVICE_ATTR_WO;
identifier d.x,expected.x_store,expected.func;
expression e;
@@

- SENSOR_DEVICE_ATTR(x, \(0200\|S_IWUSR\), NULL, x_store, e);
+ SENSOR_DEVICE_ATTR_WO(x, func, e);

@@
declarer name SENSOR_DEVICE_ATTR_RW;
identifier d.x,expected.x_show,expected.x_store,expected.func;
expression e;
@@

- SENSOR_DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\|S_IWUSR|S_IRUGO\), x_show, 
x_store, e);
+ SENSOR_DEVICE_ATTR_RW(x, func, e);

@@
declarer name SENSOR_DEVICE_ATTR_2_RO;
identifier d.x,expected.x_show,expected.func;
expression e1,e2;
@@

- SENSOR_DEVICE_ATTR_2(x, \(0444\|S_IRUGO\), x_show, NULL, e1, e2);
+ SENSOR_DEVICE_ATTR_2_RO(x, func, e1, e2);

@@
declarer name SENSOR_DEVICE_ATTR_2_WO;
identifier d.x,expected.x_store,expected.func;
expression e1,e2;
@@

- SENSOR_DEVICE_ATTR_2(x, \(0200\|S_IWUSR\), NULL, x_store, e1, e2);
+ SENSOR_DEVICE_ATTR_2_WO(x, func, e1, e2);

@@
declarer name SENSOR_DEVICE_ATTR_2_RW;
identifier d.x,expected.x_show,expected.x_store,expected.func;
expression e1, e2;
@@

- SENSOR_DEVICE_ATTR_2(x, \(0644\|S_IRUGO|S_IWUSR\|S_IWUSR|S_IRUGO\), x_show, 
x_store, e1, e2);
+ SENSOR_DEVICE_ATTR_2_RW(x, func, e1, e2);

// -
// Other calls

@o@
declarer name SENSOR_DEVICE_ATTR,SENSOR_DEVICE_ATTR_2;
identifier d.x,show,store;
expression list es;
@@

(
SENSOR_DEVICE_ATTR(x,\(0444\|S_IRUGO\|0200\|S_IWUSR\|0644\|S_IRUGO|S_IWUSR\|S_IWUSR|S_IRUGO\),show,store,es);
|
SENSOR_DEVICE_ATTR_2(x,\(0444\|S_IRUGO\|0200\|S_IWUSR\|0644\|S_IRUGO|S_IWUSR\|S_IWUSR|S_IRUGO\),show,store,es);
)

// rename functions

@show1@
identifier o.show,expected.x_show;
parameter list ps;
@@

static
- show(ps)
+ x_show(ps)
  { ... }

@depends on show1@
identifier o.show,expected.x_show;
expression list es;
@@
- show(es)
+ x_show(es)

@depends on show1@
identifier o.show,expected.x_show;
@@
- show
+ x_show

@store1@
identifier o.store,expected.x_store;
parameter list ps;
@@

static
- store(ps)
+ x_store(ps)
  { ... }

@depends on store1@
identifier o.store,expected.x_store;
expression list es;
@@
- store(es)
+ x_store(es)

@depends on store1@
identifier o.store,expected.x_store;
@@
- store
+ x_store

// try again

@@
declarer name SENSOR_DEVICE_ATTR_RO;
identifier d.x,expected.x_show,expected.func;
expression e;
@@

- SENSOR_DEVICE_ATTR(x, \(0444\|S_IRUGO\), x_show, NULL, e);
+ SENSOR_DEVICE_ATTR_RO(x, func, e);

@@
declarer name SENSOR_DEVICE_ATTR_WO;
identifier d.x,expected.x_store,expected.func;
expression e;
@@

- SENSOR_DEVICE_ATTR(x, \(0200\|S_IWUSR\), NULL, x_store, e);
+ SENSOR_DEVICE_ATTR_WO(x, func, e);

@@
declarer name SENSOR_DEVICE_ATTR_RW;
identifier d.x,expected.x_show,expected.x_store,expected.func;
expression e;
@@

- SENSOR_DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\|S_IWUSR|S_IRUGO\), x_show, 
x_store, e);
+ SENSOR_DEVICE_ATTR_RW(x, func, e);

@@
declarer name SENSOR_DEVICE_ATTR_2_RO;
identifier d.x,expected.x_show,expected.func;
expression 

[PATCH] drivers: net: ethernet: 3com: fix return value

[Thomas Preisner]

In a few cases the err-variable is not set to a negative error code if a
function call fails and thus 0 is returned instead.
It may be better to set err to the proper negative error code before
returning.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188841

Reported-by: Pan Bian 
Signed-off-by: Thomas Preisner 
Signed-off-by: Milan Stephan 
---
 drivers/net/ethernet/3com/typhoon.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/3com/typhoon.c 
b/drivers/net/ethernet/3com/typhoon.c
index a0cacbe..9a3ab58 100644
--- a/drivers/net/ethernet/3com/typhoon.c
+++ b/drivers/net/ethernet/3com/typhoon.c
@@ -2404,6 +2404,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
if(!is_valid_ether_addr(dev->dev_addr)) {
err_msg = "Could not obtain valid ethernet address, aborting";
+   err = -EIO;
goto error_out_reset;
}
 
@@ -2413,6 +2414,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
INIT_COMMAND_WITH_RESPONSE(_cmd, TYPHOON_CMD_READ_VERSIONS);
if(typhoon_issue_command(tp, 1, _cmd, 3, xp_resp) < 0) {
err_msg = "Could not get Sleep Image version";
+   err = -EIO;
goto error_out_reset;
}
 
@@ -2455,6 +2457,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
if(register_netdev(dev) < 0) {
err_msg = "unable to register netdev";
+   err = -EIO;
goto error_out_reset;
}
 
-- 
2.7.4

[PATCH] drivers: net: ethernet: 3com: fix return value

[Thomas Preisner]

In a few cases the err-variable is not set to a negative error code if a
function call fails and thus 0 is returned instead.
It may be better to set err to the proper negative error code before
returning.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188841

Reported-by: Pan Bian 
Signed-off-by: Thomas Preisner 
Signed-off-by: Milan Stephan 
---
 drivers/net/ethernet/3com/typhoon.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/3com/typhoon.c 
b/drivers/net/ethernet/3com/typhoon.c
index a0cacbe..9a3ab58 100644
--- a/drivers/net/ethernet/3com/typhoon.c
+++ b/drivers/net/ethernet/3com/typhoon.c
@@ -2404,6 +2404,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
if(!is_valid_ether_addr(dev->dev_addr)) {
err_msg = "Could not obtain valid ethernet address, aborting";
+   err = -EIO;
goto error_out_reset;
}
 
@@ -2413,6 +2414,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
INIT_COMMAND_WITH_RESPONSE(_cmd, TYPHOON_CMD_READ_VERSIONS);
if(typhoon_issue_command(tp, 1, _cmd, 3, xp_resp) < 0) {
err_msg = "Could not get Sleep Image version";
+   err = -EIO;
goto error_out_reset;
}
 
@@ -2455,6 +2457,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
if(register_netdev(dev) < 0) {
err_msg = "unable to register netdev";
+   err = -EIO;
goto error_out_reset;
}
 
-- 
2.7.4