[PATCH v4 2/7] powerpc/eeh: Export confirm_error_lock

[Gavin Shan]

This exports @confirm_error_lock so that eeh_serialize_{lock, unlock}()
can be used to freeze the affected PE in PCI surprise hot remove path.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/kernel/eeh.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 0699f15..130bcae 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -116,6 +116,7 @@ struct eeh_ops *eeh_ops = NULL;
 
 /* Lock to avoid races due to multiple reports of an error */
 DEFINE_RAW_SPINLOCK(confirm_error_lock);
+EXPORT_SYMBOL_GPL(confirm_error_lock);
 
 /* Lock to protect passed flags */
 static DEFINE_MUTEX(eeh_dev_mutex);
-- 
2.1.0

[PATCH v4 3/7] powerpc/eeh: Export eeh_pe_state_mark()

[Gavin Shan]

This exports eeh_pe_state_mark(). It will be used to mark the surprise
hot removed PE as isolated to avoid unexpected EEH error reporting in
surprise remove path.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/kernel/eeh_pe.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/eeh_pe.c b/arch/powerpc/kernel/eeh_pe.c
index f0520da..de7d091 100644
--- a/arch/powerpc/kernel/eeh_pe.c
+++ b/arch/powerpc/kernel/eeh_pe.c
@@ -581,6 +581,7 @@ void eeh_pe_state_mark(struct eeh_pe *pe, int state)
 {
eeh_pe_traverse(pe, __eeh_pe_state_mark, );
 }
+EXPORT_SYMBOL_GPL(eeh_pe_state_mark);
 
 static void *__eeh_pe_dev_mode_mark(void *data, void *flag)
 {
-- 
2.1.0

[PATCH v4 4/7] powerpc/powernv: Unfreeze PE on allocation

[Gavin Shan]

This unfreezes PE when it's initialized because the PE might be put
into frozen state in the last hot remove path. It's not harmful to
do so if the PE is already in unfrozen state.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/platforms/powernv/pci-ioda.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 38a5c65..841395e 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -133,9 +133,21 @@ static inline bool pnv_pci_is_m64_flags(unsigned long 
resource_flags)
 
 static struct pnv_ioda_pe *pnv_ioda_init_pe(struct pnv_phb *phb, int pe_no)
 {
+   s64 rc;
+
phb->ioda.pe_array[pe_no].phb = phb;
phb->ioda.pe_array[pe_no].pe_number = pe_no;
 
+   /* Clear the PE frozen state as it might be put into frozen state
+* in the last PCI remove path. It's not harmful to do so when the
+* PE is already in unfrozen state.
+*/
+   rc = opal_pci_eeh_freeze_clear(phb->opal_id, pe_no,
+  OPAL_EEH_ACTION_CLEAR_FREEZE_ALL);
+   if (rc != OPAL_SUCCESS)
+   pr_warn("%s: Error %lld unfreezing PHB#%d-PE#%d\n",
+   __func__, rc, phb->hose->global_number, pe_no);
+
return >ioda.pe_array[pe_no];
 }
 
-- 
2.1.0

[PATCH v4 1/7] powerpc/eeh: Allow to freeze PE in eeh_pe_set_option()

[Gavin Shan]

Function eeh_pe_set_option() is used to apply the requested options
(enable, disable, unfreeze) in EEH virtualization path. The semantics
of this function isn't complete until freezing is supported.

This allows to freeze the indicated PE. The new semantics is going to
be used in PCI surprise hot remove path, to freeze removed PCI devices
(PE) to avoid unexpected EEH error reporting.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/kernel/eeh.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 7429556..0699f15 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1502,6 +1502,7 @@ int eeh_pe_set_option(struct eeh_pe *pe, int option)
break;
case EEH_OPT_THAW_MMIO:
case EEH_OPT_THAW_DMA:
+   case EEH_OPT_FREEZE_PE:
if (!eeh_ops || !eeh_ops->set_option) {
ret = -ENOENT;
break;
-- 
2.1.0

[PATCH v4 7/7] drivers/pci/hotplug: Support surprise hotplug in powernv driver

[Gavin Shan]

This supports PCI surprise hotplug. The design is highlighted as
below:

   * The PCI slot's surprise hotplug capability is exposed through
 device node property "ibm,slot-surprise-pluggable", meaning
 PCI surprise hotplug will be disabled if skiboot doesn't support
 it yet.
   * The interrupt because of presence or link state change is raised
 on surprise hotplug event. One event is allocated and queued to
 the PCI slot for workqueue to pick it up and process in serialized
 fashion. The code flow for surprise hotplug is same to that for
 managed hotplug except: the affected PEs are put into frozen state
 to avoid unexpected EEH error reporting in surprise hot remove path.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/include/asm/pnv-pci.h |   2 +
 drivers/pci/hotplug/pnv_php.c  | 212 +
 2 files changed, 214 insertions(+)

diff --git a/arch/powerpc/include/asm/pnv-pci.h 
b/arch/powerpc/include/asm/pnv-pci.h
index 0cbd813..17e89dd 100644
--- a/arch/powerpc/include/asm/pnv-pci.h
+++ b/arch/powerpc/include/asm/pnv-pci.h
@@ -60,6 +60,8 @@ struct pnv_php_slot {
 #define PNV_PHP_STATE_POPULATED2
 #define PNV_PHP_STATE_OFFLINE  3
int state;
+   int irq;
+   struct workqueue_struct *wq;
struct device_node  *dn;
struct pci_dev  *pdev;
struct pci_bus  *bus;
diff --git a/drivers/pci/hotplug/pnv_php.c b/drivers/pci/hotplug/pnv_php.c
index 96ccb7f..7dba35c 100644
--- a/drivers/pci/hotplug/pnv_php.c
+++ b/drivers/pci/hotplug/pnv_php.c
@@ -22,6 +22,12 @@
 #define DRIVER_AUTHOR  "Gavin Shan, IBM Corporation"
 #define DRIVER_DESC"PowerPC PowerNV PCI Hotplug Driver"
 
+struct pnv_php_event {
+   booladded;
+   struct pnv_php_slot *php_slot;
+   struct work_struct  work;
+};
+
 static LIST_HEAD(pnv_php_slot_list);
 static DEFINE_SPINLOCK(pnv_php_lock);
 
@@ -29,12 +35,40 @@ static void pnv_php_register(struct device_node *dn);
 static void pnv_php_unregister_one(struct device_node *dn);
 static void pnv_php_unregister(struct device_node *dn);
 
+static void pnv_php_disable_irq(struct pnv_php_slot *php_slot)
+{
+   struct pci_dev *pdev = php_slot->pdev;
+   u16 ctrl;
+
+   if (php_slot->irq > 0) {
+   pcie_capability_read_word(pdev, PCI_EXP_SLTCTL, );
+   ctrl &= ~(PCI_EXP_SLTCTL_HPIE |
+ PCI_EXP_SLTCTL_PDCE |
+ PCI_EXP_SLTCTL_DLLSCE);
+   pcie_capability_write_word(pdev, PCI_EXP_SLTCTL, ctrl);
+
+   free_irq(php_slot->irq, php_slot);
+   php_slot->irq = 0;
+   }
+
+   if (php_slot->wq) {
+   destroy_workqueue(php_slot->wq);
+   php_slot->wq = NULL;
+   }
+
+   if (pdev->msix_enabled)
+   pci_disable_msix(pdev);
+   else if (pdev->msi_enabled)
+   pci_disable_msi(pdev);
+}
+
 static void pnv_php_free_slot(struct kref *kref)
 {
struct pnv_php_slot *php_slot = container_of(kref,
struct pnv_php_slot, kref);
 
WARN_ON(!list_empty(_slot->children));
+   pnv_php_disable_irq(php_slot);
kfree(php_slot->name);
kfree(php_slot);
 }
@@ -610,6 +644,179 @@ static int pnv_php_register_slot(struct pnv_php_slot 
*php_slot)
return 0;
 }
 
+static int pnv_php_enable_msix(struct pnv_php_slot *php_slot)
+{
+   struct pci_dev *pdev = php_slot->pdev;
+   struct msix_entry entry;
+   int nr_entries, ret;
+   u16 pcie_flag;
+
+   /* Get total number of MSIx entries */
+   nr_entries = pci_msix_vec_count(pdev);
+   if (nr_entries < 0)
+   return nr_entries;
+
+   /* Check hotplug MSIx entry is in range */
+   pcie_capability_read_word(pdev, PCI_EXP_FLAGS, _flag);
+   entry.entry = (pcie_flag & PCI_EXP_FLAGS_IRQ) >> 9;
+   if (entry.entry >= nr_entries)
+   return -ERANGE;
+
+   /* Enable MSIx */
+   ret = pci_enable_msix_exact(pdev, , 1);
+   if (ret) {
+   dev_warn(>dev, "Error %d enabling MSIx\n", ret);
+   return ret;
+   }
+
+   return entry.vector;
+}
+
+static void pnv_php_event_handler(struct work_struct *work)
+{
+   struct pnv_php_event *event =
+   container_of(work, struct pnv_php_event, work);
+   struct pnv_php_slot *php_slot = event->php_slot;
+
+   if (event->added)
+   pnv_php_enable_slot(_slot->slot);
+   else
+   pnv_php_disable_slot(_slot->slot);
+
+   kfree(event);
+}
+
+static irqreturn_t pnv_php_interrupt(int irq, void *data)
+{
+   struct pnv_php_slot *php_slot = data;
+   struct pci_dev *pchild, *pdev = php_slot->pdev;
+   struct eeh_dev *edev;
+   struct eeh_pe *pe;
+   

[PATCH v4 6/7] drivers/pci/hotplug: Use of_property_read_u32() in powernv driver

[Gavin Shan]

This replaces of_get_property() with of_property_read_u32() or
of_property_read_string() so that we needn't consider the endian
issue, the returned value always is in CPU-endian.

Signed-off-by: Gavin Shan 
---
 drivers/pci/hotplug/pnv_php.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/hotplug/pnv_php.c b/drivers/pci/hotplug/pnv_php.c
index 182f218..96ccb7f 100644
--- a/drivers/pci/hotplug/pnv_php.c
+++ b/drivers/pci/hotplug/pnv_php.c
@@ -513,9 +513,10 @@ static struct pnv_php_slot *pnv_php_alloc_slot(struct 
device_node *dn)
struct pci_bus *bus;
const char *label;
uint64_t id;
+   int ret;
 
-   label = of_get_property(dn, "ibm,slot-label", NULL);
-   if (!label)
+   ret = of_property_read_string(dn, "ibm,slot-label", );
+   if (ret)
return NULL;
 
if (pnv_pci_get_slot_id(dn, ))
@@ -612,16 +613,16 @@ static int pnv_php_register_slot(struct pnv_php_slot 
*php_slot)
 static int pnv_php_register_one(struct device_node *dn)
 {
struct pnv_php_slot *php_slot;
-   const __be32 *prop32;
+   u32 prop32;
int ret;
 
/* Check if it's hotpluggable slot */
-   prop32 = of_get_property(dn, "ibm,slot-pluggable", NULL);
-   if (!prop32 || !of_read_number(prop32, 1))
+   ret = of_property_read_u32(dn, "ibm,slot-pluggable", );
+   if (ret || !prop32)
return -ENXIO;
 
-   prop32 = of_get_property(dn, "ibm,reset-by-firmware", NULL);
-   if (!prop32 || !of_read_number(prop32, 1))
+   ret = of_property_read_u32(dn, "ibm,reset-by-firmware", );
+   if (ret || !prop32)
return -ENXIO;
 
php_slot = pnv_php_alloc_slot(dn);
-- 
2.1.0

[PATCH v4 0/7] powerpc/powernv: PCI Surprise Hotplug Support

[Gavin Shan]

This series of patches supports PCI surprise hotplug on PowerNV platform.
Without the corresponding skiboot patches, this feature won't be enabled
and workable.

   * The skiboot patches can be found in below link (PATCH[01/16):
 https://patchwork.ozlabs.org/project/skiboot/list/?submitter=63923
   * This newly added functionality depends on skiboot's changes. However,
 the functionality is disabled simply when skiboot doesn't support it.
 For one specific slot, property "ibm,slot-surprise-pluggable" of the
 slot's device node is set to 1 when surprise hotplug is claimed by
 skiboot.
   * The interrupts because of presence and link state change are enabled
 in order to support PCI surprise hotplug. The surprise hotplug events
 are queued to the PCI slot and they're picked up for further processing
 in serialized fashion. The surprise and managed hotplug share same code
 flow except: the affected PEs are put into frozen state to avoid unexpected
 EEH error reporting in surprise hot remove path.

PATCH[1/7] to PATCH[3/7] allow to freeze PEs to avoid unexpected EEH error
reporting in PCI surprise hot remove path. PATCH[4/7] clears PE's frozen state
on initializing it because the PE might have been put into frozen state in last
PCI surprise hot remove. PATCH[5/7] removes likely() and unlikely() in pnv_php.c
as they are not too useful. PATCH[6/7] replaces of_get_property() with 
of_property_
read_u32() and of_property_read_string(). PATCH[7/7] supports PCI surprise 
hotplug
for PowerNV PCI hotplug driver.

Changelog
=
v2:
   * Add one patch to remove likely() and unlikely() in pnv_php.c.
   * Remove likely() and unlikely() in PATCH[v1 4/4].
   * The event isn't pre-allocated. It's always allocated from slab
 in the interrupt handler. The removed PE is put into frozen state
 before the event is allocated.
v3:
   * Add one patch to export confirm_error_lock to avoid building error
 when having CONFIG_HOTPLUG_PCI_POWERNV=m
v4:
   * Add patch to replace of_get_property() with of_property_read_u32()
 and of_property_read_string(). Also, the of_get_property() in last
 patch was replaced to of_property_read_u32().

Gavin Shan (7):
  powerpc/eeh: Allow to freeze PE in eeh_pe_set_option()
  powerpc/eeh: Export confirm_error_lock
  powerpc/eeh: Export eeh_pe_state_mark()
  powerpc/powernv: Unfreeze PE on allocation
  drivers/pci/hotplug: Remove likely() and unlikely() in powernv driver
  drivers/pci/hotplug: Use of_property_read_u32() in powernv driver
  drivers/pci/hotplug: Support surprise hotplug in powernv driver

 arch/powerpc/include/asm/pnv-pci.h|   2 +
 arch/powerpc/kernel/eeh.c |   2 +
 arch/powerpc/kernel/eeh_pe.c  |   1 +
 arch/powerpc/platforms/powernv/pci-ioda.c |  12 ++
 drivers/pci/hotplug/pnv_php.c | 281 ++
 5 files changed, 264 insertions(+), 34 deletions(-)

-- 
2.1.0

Re: [PATCH v5 3/4] PCI: Add a new option for resource_alignment to reassign alignment

[Yongji Xie]

On 2016/9/29 6:42, Bjorn Helgaas wrote:


On Tue, Sep 13, 2016 at 05:00:33PM +0800, Yongji Xie wrote:

When using resource_alignment kernel parameter, the current
implement reassigns the alignment by changing resources' size
which can potentially break some drivers. For example, the driver
uses the size to locate some register whose length is related
to the size.

This patch adds a new option "noresize" for the parameter to
solve this problem.

Signed-off-by: Yongji Xie 
---
  Documentation/kernel-parameters.txt |9 ++---
  drivers/pci/pci.c   |   37 +--
  2 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index a4f4d69..d6a340d 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3023,9 +3023,10 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
window. The default value is 64 megabytes.
resource_alignment=
Format:
-   [@][:]:.[; ...]
-   [@]pci::\
-   [::][; 
...]
+   [@][noresize@][:]
+   :.[; ...]
+   [@][noresize@]pci::
+   [::][; ...]
Specifies alignment and device to reassign
aligned memory resources.
If  is not specified,
@@ -3036,6 +3037,8 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
instances of a device, the PCI vendor,
device, subvendor, and subdevice may be
specified, e.g., 4096@pci:8086:9c22:103c:198f
+   noresize: Don't change the resources' sizes when
+   reassigning alignment.
ecrc=   Enable/disable PCIe ECRC (transaction layer
end-to-end CRC checking).
bios: Use BIOS/firmware settings. This is the
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b8357d7..37f8062 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4946,11 +4946,13 @@ static DEFINE_SPINLOCK(resource_alignment_lock);
  /**
   * pci_specified_resource_alignment - get resource alignment specified by 
user.
   * @dev: the PCI device to get
+ * @resize: whether or not to change resources' size when reassigning alignment
   *
   * RETURNS: Resource alignment if it is specified.
   *  Zero if it is not specified.
   */
-static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev)
+static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev,
+   bool *resize)
  {
int seg, bus, slot, func, align_order, count;
unsigned short vendor, device, subsystem_vendor, subsystem_device;
@@ -4974,6 +4976,13 @@ static resource_size_t 
pci_specified_resource_alignment(struct pci_dev *dev)
} else {
align_order = -1;
}
+
+   if (!strncmp(p, "noresize@", 9)) {
+   *resize = false;
+   p += 9;
+   } else
+   *resize = true;
+
if (strncmp(p, "pci:", 4) == 0) {
/* PCI vendor/device (subvendor/subdevice) ids are 
specified */
p += 4;
@@ -5045,6 +5054,7 @@ void pci_reassigndev_resource_alignment(struct pci_dev 
*dev)
  {
int i;
struct resource *r;
+   bool resize = true;
resource_size_t align, size;
u16 command;
  
@@ -5058,7 +5068,7 @@ void pci_reassigndev_resource_alignment(struct pci_dev *dev)

return;
  
  	/* check if specified PCI is target device to reassign */

-   align = pci_specified_resource_alignment(dev);
+   align = pci_specified_resource_alignment(dev, );
if (!align)
return;
  
@@ -5086,15 +5096,22 @@ void pci_reassigndev_resource_alignment(struct pci_dev *dev)

}
  
  		size = resource_size(r);

-   if (size < align) {
-   size = align;
-   dev_info(>dev,
-   "Rounding up size of resource #%d to %#llx.\n",
-   i, (unsigned long long)size);
+   if (resize) {
+   if (size < align) {
+   size = align;
+   dev_info(>dev,
+   "Rounding up size of resource #%d to 
%#llx.\n",
+   i, (unsigned long long)size);
+  

Re: [PATCH v5 3/4] PCI: Add a new option for resource_alignment to reassign alignment

[Bjorn Helgaas]

On Tue, Sep 13, 2016 at 05:00:33PM +0800, Yongji Xie wrote:
> When using resource_alignment kernel parameter, the current
> implement reassigns the alignment by changing resources' size
> which can potentially break some drivers. For example, the driver
> uses the size to locate some register whose length is related
> to the size.
> 
> This patch adds a new option "noresize" for the parameter to
> solve this problem.
> 
> Signed-off-by: Yongji Xie 
> ---
>  Documentation/kernel-parameters.txt |9 ++---
>  drivers/pci/pci.c   |   37 
> +--
>  2 files changed, 33 insertions(+), 13 deletions(-)
> 
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index a4f4d69..d6a340d 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -3023,9 +3023,10 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
>   window. The default value is 64 megabytes.
>   resource_alignment=
>   Format:
> - [ align>@][:]:.[; ...]
> - [@]pci::\
> - [::][; 
> ...]
> + [@][noresize@][:]
> + :.[; ...]
> + [ align>@][noresize@]pci::
> + [::][; ...]
>   Specifies alignment and device to reassign
>   aligned memory resources.
>   If  is not specified,
> @@ -3036,6 +3037,8 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
>   instances of a device, the PCI vendor,
>   device, subvendor, and subdevice may be
>   specified, e.g., 4096@pci:8086:9c22:103c:198f
> + noresize: Don't change the resources' sizes when
> + reassigning alignment.
>   ecrc=   Enable/disable PCIe ECRC (transaction layer
>   end-to-end CRC checking).
>   bios: Use BIOS/firmware settings. This is the
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b8357d7..37f8062 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -4946,11 +4946,13 @@ static DEFINE_SPINLOCK(resource_alignment_lock);
>  /**
>   * pci_specified_resource_alignment - get resource alignment specified by 
> user.
>   * @dev: the PCI device to get
> + * @resize: whether or not to change resources' size when reassigning 
> alignment
>   *
>   * RETURNS: Resource alignment if it is specified.
>   *  Zero if it is not specified.
>   */
> -static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev)
> +static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev,
> + bool *resize)
>  {
>   int seg, bus, slot, func, align_order, count;
>   unsigned short vendor, device, subsystem_vendor, subsystem_device;
> @@ -4974,6 +4976,13 @@ static resource_size_t 
> pci_specified_resource_alignment(struct pci_dev *dev)
>   } else {
>   align_order = -1;
>   }
> +
> + if (!strncmp(p, "noresize@", 9)) {
> + *resize = false;
> + p += 9;
> + } else
> + *resize = true;
> +
>   if (strncmp(p, "pci:", 4) == 0) {
>   /* PCI vendor/device (subvendor/subdevice) ids are 
> specified */
>   p += 4;
> @@ -5045,6 +5054,7 @@ void pci_reassigndev_resource_alignment(struct pci_dev 
> *dev)
>  {
>   int i;
>   struct resource *r;
> + bool resize = true;
>   resource_size_t align, size;
>   u16 command;
>  
> @@ -5058,7 +5068,7 @@ void pci_reassigndev_resource_alignment(struct pci_dev 
> *dev)
>   return;
>  
>   /* check if specified PCI is target device to reassign */
> - align = pci_specified_resource_alignment(dev);
> + align = pci_specified_resource_alignment(dev, );
>   if (!align)
>   return;
>  
> @@ -5086,15 +5096,22 @@ void pci_reassigndev_resource_alignment(struct 
> pci_dev *dev)
>   }
>  
>   size = resource_size(r);
> - if (size < align) {
> - size = align;
> - dev_info(>dev,
> - "Rounding up size of resource #%d to %#llx.\n",
> - i, (unsigned long long)size);
> + if (resize) {
> + if (size < align) {
> + size = align;
> + dev_info(>dev,
> + "Rounding up size of resource #%d to 
> 

Re: [PATCH 0/3] Fix crypto/vmx/p8_ghash memory corruption

[Anton Blanchard]

Hi Marcelo

> This series fixes the memory corruption found by Jan Stancek in
> 4.8-rc7. The problem however also affects previous versions of the
> driver.

If it affects previous versions, please add the lines in the sign off to
get it into the stable kernels.

Anton

Re: [v3,4/5] powerpc/pm: support deep sleep feature on T104x

[Scott Wood]

On Tue, 2016-09-27 at 11:05 +, C.H. Zhao wrote:
> From: Scott Wood 
> Sent: Sunday, September 25, 2016 3:24 PM
> To: C.H. Zhao
> Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; z.chenhui@g
> mail.com; Jason Jin
> Subject: Re: [v3,4/5] powerpc/pm: support deep sleep feature on T104x
> 
> On Tue, Aug 02, 2016 at 07:59:31PM +0800, Chenhui Zhao wrote:
> > 
> > T104x has deep sleep feature, which can switch off most parts of
> > the SoC when it is in deep sleep mode. This way, it becomes more
> > energy-efficient.
> > 
> > The DDR controller will also be powered off in deep sleep. Therefore,
> > the last stage (the latter part of fsl_dp_enter_low) will run without DDR
> > access. This piece of code and related TLBs are prefetched in advance.
> > 
> > Due to the different initialization code between 32-bit and 64-bit, they
> > have separate resume entry and precedure.
> > 
> > The feature supports 32-bit and 64-bit kernel mode.
> > 
> > Signed-off-by: Chenhui Zhao 
> > ---
> >   arch/powerpc/include/asm/fsl_pm.h |  24 ++
> >   arch/powerpc/kernel/asm-offsets.c |  12 +
> >   arch/powerpc/kernel/fsl_booke_entry_mapping.S |  10 +
> >   arch/powerpc/kernel/head_64.S |   2 +-
> >   arch/powerpc/platforms/85xx/Makefile  |   1 +
> >   arch/powerpc/platforms/85xx/deepsleep.c   | 278 ++
> >   arch/powerpc/platforms/85xx/qoriq_pm.c    |  25 ++
> >   arch/powerpc/platforms/85xx/t104x_deepsleep.S | 531
> > ++
> >   arch/powerpc/sysdev/fsl_rcpm.c    |   8 +-
> >   9 files changed, 889 insertions(+), 2 deletions(-)
> >   create mode 100644 arch/powerpc/platforms/85xx/deepsleep.c
> >   create mode 100644 arch/powerpc/platforms/85xx/t104x_deepsleep.S
> > 
> > diff --git a/arch/powerpc/include/asm/fsl_pm.h
> > b/arch/powerpc/include/asm/fsl_pm.h
> > index e05049b..48c2631 100644
> > --- a/arch/powerpc/include/asm/fsl_pm.h
> > +++ b/arch/powerpc/include/asm/fsl_pm.h
> > @@ -20,6 +20,7 @@
> >   
> >   #define PLAT_PM_SLEEP    20
> >   #define PLAT_PM_LPM20    30
> > +#define PLAT_PM_LPM35    40
> >   
> >   #define FSL_PM_SLEEP (1 << 0)
> >   #define FSL_PM_DEEP_SLEEP    (1 << 1)
> > @@ -48,4 +49,27 @@ extern const struct fsl_pm_ops *qoriq_pm_ops;
> >   
> >   int __init fsl_rcpm_init(void);
> >   
> > +#ifdef CONFIG_FSL_QORIQ_PM
> > +int fsl_enter_deepsleep(void);
> > +int fsl_deepsleep_init(void);
> > +#else
> > +static inline int fsl_enter_deepsleep(void) { return -1; }
> > +static inline int fsl_deepsleep_init(void) { return -1; }
> > +#endif
> Please return proper error codes.
> 
> Where can fsl_deepsleep_init() be called without CONFIG_FSL_QORIQ_PM?
> 
> [Chenhui] I can get rid of the ifdef here. And add it
> in arch/powerpc/sysdev/fsl_rcpm.c.

No, this is the right place for the ifdef for functions that are called from
code that doesn't depend on CONFIG_FSL_QORIQ_PM.  But fsl_deepsleep_init() is
called from deepsleep.c which is only built with CONFIG_FSL_QORIQ_PM, and it's
hard to picture a scenario where it would be called from elsewhere.

> > diff --git a/arch/powerpc/kernel/fsl_booke_entry_mapping.S
> > b/arch/powerpc/kernel/fsl_booke_entry_mapping.S
> > index 83dd0f6..659b059 100644
> > --- a/arch/powerpc/kernel/fsl_booke_entry_mapping.S
> > +++ b/arch/powerpc/kernel/fsl_booke_entry_mapping.S
> > @@ -173,6 +173,10 @@ skpinv:  addi    r6,r6,1 /*
> > Increment */
> >     lis r6,MAS2_VAL(PAGE_OFFSET, BOOK3E_PAGESZ_64M, M_IF_NEEDED)@h
> >     ori r6,r6,MAS2_VAL(PAGE_OFFSET, BOOK3E_PAGESZ_64M,
> > M_IF_NEEDED)@l
> >     mtspr   SPRN_MAS2,r6
> > +#ifdef ENTRY_DEEPSLEEP_SETUP
> > + LOAD_REG_IMMEDIATE(r8, MEMORY_START)
> > + ori r8,r8,(MAS3_SX|MAS3_SW|MAS3_SR)
> > +#endif
> >     mtspr   SPRN_MAS3,r8
> >     tlbwe
> >   
> Have you tried this with a relocatable kernel?
> 
> [Chenhui] Not yet. Not sure whether it has been supported on QorIQ platform.

It is supported, and deep sleep needs to work with it.

> > +static void fsl_dp_set_resume_pointer(void)
> > +{
> > + u32 resume_addr;
> > +
> > + /* the bootloader will finally jump to this address to return kernel
> > */
> > +#ifdef CONFIG_PPC32
> > + resume_addr = (u32)(__pa(fsl_booke_deep_sleep_resume));
> > +#else
> > + resume_addr = (u32)(__pa(*(u64 *)fsl_booke_deep_sleep_resume)
> > + & 0x);
> > +#endif
> Why are you masking the physical address by 0x?  Besides the
> (u32) cast accomplishing the same thing, wouldn't it be a problem if
> (e.g. due to a relocatable kernel) the address is above 4 GiB?
> 
> [Chenhui] Here, I assumed kernel is below 4 GiB. Maybe I should add a
> comment here.

It needs a fix rather than a comment, unless you can show that the relocatable
mechanism doesn't support kernels over 4 GiB (I don't remember of the top of
my head whether it does).

Re: [PATCH v21 06/19] perf, tools: Support alias descriptions

[Arnaldo Carvalho de Melo]

Em Wed, Sep 28, 2016 at 11:29:16AM -0700, Sukadev Bhattiprolu escreveu:
> Arnaldo Carvalho de Melo [a...@kernel.org] wrote:
> > Em Tue, Sep 27, 2016 at 11:11:16AM -0700, Sukadev Bhattiprolu escreveu:
> > > Arnaldo Carvalho de Melo [a...@kernel.org] wrote:
> > > > Em Thu, Sep 15, 2016 at 03:24:43PM -0700, Sukadev Bhattiprolu escreveu:
> > > > > From: Andi Kleen 
> > > > > Add support to print alias descriptions in perf list, which
> > > > > are taken from the generated event files.
> > > > > 
> > > > > The sorting code is changed to put the events with descriptions
> > > > > at the end. The descriptions are printed as possibly multiple word
> > > > > wrapped lines.
> > > > 
> > > > So, now I'm trying to reproduce the results below, but I couldn't find a
> > > > tarball with those .json files for me to use, can you provide me with
> > > > one?
> > > 
> > > The data files are in my github, in the json-code+data-v21 branch
> > > starting with 23bb101. They are individual commits rather than a
> > > tarball though.
> > 
> > Ok, I'll pick one for powerpc and another for x86_64 so that I can test
> > it and Jiri's x-compile support.
> 
> Please pull all files if possible, specially on x86, _before_ building the
> perf binary. If you are going to pull only one, you need to make sure that
> the file you pull matches the CPU model on the system you are testing.(see
> below). For Power, you need to test on Power8.
> 
> > 
> > Refresh my mind, what is the plan on these files? Are we just going to
> > provide pointers to where to get them from vendors, ship it in the
> > kernel, auto-download them as part of the build process?
> 
> They are supposed to be committed into the linux kernel tree as shown
> in the json-code+data-v21 tree and they will be picked up _during build_
> of the perf binary. (We are just not mailing those data files as patches
> since they are large and there is very little value in reviewing them).
> 
> When building perf on on say x86, event tables for all the different
> x86 CPU models will be included in the perf binary. When perf is then
> executed on an x86 box, it will detect the CPU model of that box and
> use the set of events corresponding to that model.
> 
> If the CPU model does not match the models "known" to the perf binary,
> then the symbolic names will not work on that system, but there should
> be no other change in behavior.
> 
> Patch 15/19 tries to explain the process.

I didn't get to that one yet.
 
> > At least examples that allows to build and have a new 'perf test' entry
> > to check them automatically seems to be in order, no?
> 
> Well, the hope was that build/usage will be transparent! but we did not

the 'perf test' entry is to test the whole process of going from a json
file to a the perf binary and then asking for one such event and
checking if the resulting perf_event_attr is what we expect it to be,
see, for instance:

[root@jouet c]# perf test roundtrip
11: roundtrip evsel->name check  : Ok

tools/perf/tests/evsel-roundtrip-name.c

> test in the cross-compile environment. Will think about a test case.
> Please let me know if we can update the README in Patch 15/19 in any
> way.

I'll let you know when I get to that patch, till then I'll follow the
instructions you gave me here.

I.e. I go on testing patch by patch, trying to use the documentation
that is available up to that point, trying to reproduce the results
described in the patch, to fully validate it.

- Arnaldo
 
> > >   >   https://github.com/sukadev/linux.git
> > >   >
> > >   >   Branch  Description
> > >   >   --
> > >   >   json-code-v21   Source Code only
> > >   >   json-code+data-v21  Both code and data(for build/test/pull)
> > >   > 
> > > 
> > > Sukadev

Re: [PATCH v21 06/19] perf, tools: Support alias descriptions

[Sukadev Bhattiprolu]

Arnaldo Carvalho de Melo [a...@kernel.org] wrote:
> Em Tue, Sep 27, 2016 at 11:11:16AM -0700, Sukadev Bhattiprolu escreveu:
> > Arnaldo Carvalho de Melo [a...@kernel.org] wrote:
> > > Em Thu, Sep 15, 2016 at 03:24:43PM -0700, Sukadev Bhattiprolu escreveu:
> > > > From: Andi Kleen 
> > > > Add support to print alias descriptions in perf list, which
> > > > are taken from the generated event files.
> > > > 
> > > > The sorting code is changed to put the events with descriptions
> > > > at the end. The descriptions are printed as possibly multiple word
> > > > wrapped lines.
> > > 
> > > So, now I'm trying to reproduce the results below, but I couldn't find a
> > > tarball with those .json files for me to use, can you provide me with
> > > one?
> > 
> > The data files are in my github, in the json-code+data-v21 branch
> > starting with 23bb101. They are individual commits rather than a
> > tarball though.
> 
> Ok, I'll pick one for powerpc and another for x86_64 so that I can test
> it and Jiri's x-compile support.

Please pull all files if possible, specially on x86, _before_ building the
perf binary. If you are going to pull only one, you need to make sure that
the file you pull matches the CPU model on the system you are testing.(see
below). For Power, you need to test on Power8.

> 
> Refresh my mind, what is the plan on these files? Are we just going to
> provide pointers to where to get them from vendors, ship it in the
> kernel, auto-download them as part of the build process?

They are supposed to be committed into the linux kernel tree as shown
in the json-code+data-v21 tree and they will be picked up _during build_
of the perf binary. (We are just not mailing those data files as patches
since they are large and there is very little value in reviewing them).

When building perf on on say x86, event tables for all the different
x86 CPU models will be included in the perf binary. When perf is then
executed on an x86 box, it will detect the CPU model of that box and
use the set of events corresponding to that model.

If the CPU model does not match the models "known" to the perf binary,
then the symbolic names will not work on that system, but there should
be no other change in behavior.

Patch 15/19 tries to explain the process.

> 
> At least examples that allows to build and have a new 'perf test' entry
> to check them automatically seems to be in order, no?

Well, the hope was that build/usage will be transparent! but we did not
test in the cross-compile environment. Will think about a test case.
Please let me know if we can update the README in Patch 15/19 in any
way.

> 
> - Arnaldo
> 
> > >   https://github.com/sukadev/linux.git
> > >
> > >   Branch  Description
> > >   --
> > >   json-code-v21   Source Code only
> > >   json-code+data-v21  Both code and data(for build/test/pull)
> > > 
> > 
> > Sukadev

Re: [PATCH v5] powerpc: Do not make the entire heap executable

[Kees Cook]

On Tue, Sep 27, 2016 at 6:42 PM, Michael Ellerman  wrote:
> Denys Vlasenko  writes:
>
>> On 32-bit powerpc the ELF PLT sections of binaries (built with --bss-plt,
>> or with a toolchain which defaults to it) look like this:
>
> Or (it seems), for all programs built with -pg (profiling).
>
>>   [17] .sbss NOBITS  0002aff8 01aff8 14 00  WA  0   
>> 0  4
>>   [18] .plt  NOBITS  0002b00c 01aff8 84 00 WAX  0   
>> 0  4
>>   [19] .bss  NOBITS  0002b090 01aff8 a4 00  WA  0   
>> 0  4
>>
>> Which results in an ELF load header:
>>
>>   Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>>   LOAD   0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x1
>>
>> This is all correct, the load region containing the PLT is marked as
>> executable. Note that the PLT starts at 0002b00c but the file mapping ends at
>> 0002aff8, so the PLT falls in the 0 fill section described by the load 
>> header,
>> and after a page boundary.
>>
>> Unfortunately the generic ELF loader ignores the X bit in the load headers
>> when it creates the 0 filled non-file backed mappings. It assumes all of 
>> these
>> mappings are RW BSS sections, which is not the case for PPC.
>>
>> gcc/ld has an option (--secure-plt) to not do this, this is said to incur
>> a small performance penalty.
>>
>> Currently, to support 32-bit binaries with PLT in BSS kernel maps *entire
>> brk area* with executable rights for all binaries, even --secure-plt ones.
>>
>> Stop doing that.
>>
>> Teach the ELF loader to check the X bit in the relevant load header
>> and create 0 filled anonymous mappings that are executable
>> if the load header requests that.
> ...
>>
>> Signed-off-by: Jason Gunthorpe 
>> Signed-off-by: Denys Vlasenko 
>> Reviewed-by: Kees Cook 
>> CC: Michael Ellerman 
>
> This looks OK to me, I've tested it with --bss-plt and --secure-plt and
> also -pg.
>
> So for the powerpc part I'll give you an:
>
> Acked-by: Michael Ellerman 
>
> But this is not really a powerpc patch, and I'm not an ELF expert. So
> I'm not comfortable merging it via the powerpc tree. It doesn't look
> like we really have a maintainer for binfmt_elf.c, so I'm not sure who
> should be acking that part.

I've done a bunch of recent work in and around binfmt_elf.c, so I'd be
happy to change my "Reviewed-by" to an "Acked-by" a change that I
suggested earlier. (Details below.)

> I've added Al Viro to Cc, he maintains fs/ and might be interested.
>
> I've also added Andrew Morton who might be happy to put this in his
> tree, and see if anyone complains?
>
> Also here: https://patchwork.ozlabs.org/patch/661595/
>
> cheers
>
>> ---
>> Changes since v4:
>> * if (current->personality & READ_IMPLIES_EXEC), still use VM_EXEC
>>   for 32-bit executables.
>>
>> Changes since v3:
>> * typo fix in commit message
>> * rebased to current Linus tree
>>
>> Changes since v2:
>> * moved capability to map with VM_EXEC into vm_brk_flags()
>>
>> Changes since v1:
>> * wrapped lines to not exceed 79 chars
>> * improved comment
>> * expanded CC list
>>
>>  arch/powerpc/include/asm/page.h |  3 ++-
>>  fs/binfmt_elf.c | 30 ++
>>  include/linux/mm.h  |  1 +
>>  mm/mmap.c   | 21 -
>>  4 files changed, 41 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/page.h 
>> b/arch/powerpc/include/asm/page.h
>> index 56398e7..d188f51 100644
>> --- a/arch/powerpc/include/asm/page.h
>> +++ b/arch/powerpc/include/asm/page.h
>> @@ -230,7 +230,9 @@ extern long long virt_phys_offset;
>>   * and needs to be executable.  This means the whole heap ends
>>   * up being executable.
>>   */
>> -#define VM_DATA_DEFAULT_FLAGS32  (VM_READ | VM_WRITE | VM_EXEC | \
>> +#define VM_DATA_DEFAULT_FLAGS32 \
>> + (((current->personality & READ_IMPLIES_EXEC) ? VM_EXEC : 0) | \
>> +  VM_READ | VM_WRITE | \
>>VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
>>
>>  #define VM_DATA_DEFAULT_FLAGS64  (VM_READ | VM_WRITE | \
>> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
>> index 7f6aff3f..2b57b5a 100644
>> --- a/fs/binfmt_elf.c
>> +++ b/fs/binfmt_elf.c
>> @@ -91,12 +91,18 @@ static struct linux_binfmt elf_format = {
>>
>>  #define BAD_ADDR(x) ((unsigned long)(x) >= TASK_SIZE)
>>
>> -static int set_brk(unsigned long start, unsigned long end)
>> +static int set_brk(unsigned long start, unsigned long end, int prot)
>>  {
>>   start = ELF_PAGEALIGN(start);
>>   end = ELF_PAGEALIGN(end);
>>   if (end > start) {
>> - int error = vm_brk(start, end - start);
>> + /*
>> +  * Map the last of the bss segment.
>> +  * If the header is requesting these pages to 

[PATCH 2/3] crypto: vmx - Fix memory corruption caused by p8_ghash

[Marcelo Cerri]

This patch changes the p8_ghash driver to use ghash-generic as a fixed
fallback implementation. This allows the correct value of descsize to be
defined directly in its shash_alg structure and avoids problems with
incorrect buffer sizes when its state is exported or imported.

Reported-by: Jan Stancek 
Signed-off-by: Marcelo Cerri 
---
 drivers/crypto/vmx/ghash.c | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/drivers/crypto/vmx/ghash.c b/drivers/crypto/vmx/ghash.c
index 6c999cb0..27a94a1 100644
--- a/drivers/crypto/vmx/ghash.c
+++ b/drivers/crypto/vmx/ghash.c
@@ -26,16 +26,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
 #define IN_INTERRUPT in_interrupt()
 
-#define GHASH_BLOCK_SIZE (16)
-#define GHASH_DIGEST_SIZE (16)
-#define GHASH_KEY_LEN (16)
-
 void gcm_init_p8(u128 htable[16], const u64 Xi[2]);
 void gcm_gmult_p8(u64 Xi[2], const u128 htable[16]);
 void gcm_ghash_p8(u64 Xi[2], const u128 htable[16],
@@ -55,16 +52,11 @@ struct p8_ghash_desc_ctx {
 
 static int p8_ghash_init_tfm(struct crypto_tfm *tfm)
 {
-   const char *alg;
+   const char *alg = "ghash-generic";
struct crypto_shash *fallback;
struct crypto_shash *shash_tfm = __crypto_shash_cast(tfm);
struct p8_ghash_ctx *ctx = crypto_tfm_ctx(tfm);
 
-   if (!(alg = crypto_tfm_alg_name(tfm))) {
-   printk(KERN_ERR "Failed to get algorithm name.\n");
-   return -ENOENT;
-   }
-
fallback = crypto_alloc_shash(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
if (IS_ERR(fallback)) {
printk(KERN_ERR
@@ -78,10 +70,18 @@ static int p8_ghash_init_tfm(struct crypto_tfm *tfm)
crypto_shash_set_flags(fallback,
   crypto_shash_get_flags((struct crypto_shash
   *) tfm));
-   ctx->fallback = fallback;
 
-   shash_tfm->descsize = sizeof(struct p8_ghash_desc_ctx)
-   + crypto_shash_descsize(fallback);
+   /* Check if the descsize defined in the algorithm is still enough. */
+   if (shash_tfm->descsize < sizeof(struct p8_ghash_desc_ctx)
+   + crypto_shash_descsize(fallback)) {
+   printk(KERN_ERR
+  "Desc size of the fallback implementation (%s) does not 
match the expected value: %lu vs %u\n",
+  alg,
+  shash_tfm->descsize - sizeof(struct p8_ghash_desc_ctx),
+  crypto_shash_descsize(fallback));
+   return -EINVAL;
+   }
+   ctx->fallback = fallback;
 
return 0;
 }
@@ -113,7 +113,7 @@ static int p8_ghash_setkey(struct crypto_shash *tfm, const 
u8 *key,
 {
struct p8_ghash_ctx *ctx = crypto_tfm_ctx(crypto_shash_tfm(tfm));
 
-   if (keylen != GHASH_KEY_LEN)
+   if (keylen != GHASH_BLOCK_SIZE)
return -EINVAL;
 
preempt_disable();
@@ -211,7 +211,8 @@ struct shash_alg p8_ghash_alg = {
.update = p8_ghash_update,
.final = p8_ghash_final,
.setkey = p8_ghash_setkey,
-   .descsize = sizeof(struct p8_ghash_desc_ctx),
+   .descsize = sizeof(struct p8_ghash_desc_ctx)
+   + sizeof(struct ghash_desc_ctx),
.base = {
 .cra_name = "ghash",
 .cra_driver_name = "p8_ghash",
-- 
2.7.4

[PATCH 3/3] crypto: vmx - Ensure ghash-generic is enabled

[Marcelo Cerri]

Add CRYPTO_GHASH as a dependency for vmx_crypto since p8_ghash uses it
as the fallback implementation.

Signed-off-by: Marcelo Cerri 
---
 drivers/crypto/vmx/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/vmx/Kconfig b/drivers/crypto/vmx/Kconfig
index a83ead1..c21b09a 100644
--- a/drivers/crypto/vmx/Kconfig
+++ b/drivers/crypto/vmx/Kconfig
@@ -1,6 +1,6 @@
 config CRYPTO_DEV_VMX_ENCRYPT
tristate "Encryption acceleration support on P8 CPU"
-   depends on CRYPTO_DEV_VMX
+   depends on CRYPTO_DEV_VMX || CRYPTO_GHASH
default m
help
  Support for VMX cryptographic acceleration instructions on Power8 CPU.
-- 
2.7.4

[PATCH 1/3] crypto: ghash-generic - move common definitions to a new header file

[Marcelo Cerri]

Move common values and types used by ghash-generic to a new header file
so drivers can directly use ghash-generic as a fallback implementation.

Signed-off-by: Marcelo Cerri 
---
 crypto/ghash-generic.c | 13 +
 include/crypto/ghash.h | 23 +++
 2 files changed, 24 insertions(+), 12 deletions(-)
 create mode 100644 include/crypto/ghash.h

diff --git a/crypto/ghash-generic.c b/crypto/ghash-generic.c
index bac7099..12ad3e3 100644
--- a/crypto/ghash-generic.c
+++ b/crypto/ghash-generic.c
@@ -14,24 +14,13 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
-#define GHASH_BLOCK_SIZE   16
-#define GHASH_DIGEST_SIZE  16
-
-struct ghash_ctx {
-   struct gf128mul_4k *gf128;
-};
-
-struct ghash_desc_ctx {
-   u8 buffer[GHASH_BLOCK_SIZE];
-   u32 bytes;
-};
-
 static int ghash_init(struct shash_desc *desc)
 {
struct ghash_desc_ctx *dctx = shash_desc_ctx(desc);
diff --git a/include/crypto/ghash.h b/include/crypto/ghash.h
new file mode 100644
index 000..2a61c9b
--- /dev/null
+++ b/include/crypto/ghash.h
@@ -0,0 +1,23 @@
+/*
+ * Common values for GHASH algorithms
+ */
+
+#ifndef __CRYPTO_GHASH_H__
+#define __CRYPTO_GHASH_H__
+
+#include 
+#include 
+
+#define GHASH_BLOCK_SIZE   16
+#define GHASH_DIGEST_SIZE  16
+
+struct ghash_ctx {
+   struct gf128mul_4k *gf128;
+};
+
+struct ghash_desc_ctx {
+   u8 buffer[GHASH_BLOCK_SIZE];
+   u32 bytes;
+};
+
+#endif
-- 
2.7.4

[PATCH 0/3] Fix crypto/vmx/p8_ghash memory corruption

[Marcelo Cerri]

This series fixes the memory corruption found by Jan Stancek in 4.8-rc7. The
problem however also affects previous versions of the driver.

Marcelo Cerri (3):
  crypto: ghash-generic - move common definitions to a new header file
  crypto: vmx - Fix memory corruption caused by p8_ghash
  crypto: vmx - Ensure ghash-generic is enabled

 crypto/ghash-generic.c | 13 +
 drivers/crypto/vmx/Kconfig |  2 +-
 drivers/crypto/vmx/ghash.c | 31 ---
 include/crypto/ghash.h | 23 +++
 4 files changed, 41 insertions(+), 28 deletions(-)
 create mode 100644 include/crypto/ghash.h

-- 
2.7.4

[PATCH -next] powerpc/4xx: Fix error return code in ppc4xx_msi_probe()

[Wei Yongjun]

From: Wei Yongjun 

Fix to return a negative error code from the ppc4xx_setup_pcieh_hw()
error handling case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun 
---
 arch/powerpc/sysdev/ppc4xx_msi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
index 590dab4..b729d44 100644
--- a/arch/powerpc/sysdev/ppc4xx_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -242,7 +242,8 @@ static int ppc4xx_msi_probe(struct platform_device *dev)
if (!msi_irqs)
return -ENODEV;
 
-   if (ppc4xx_setup_pcieh_hw(dev, res, msi))
+   err = ppc4xx_setup_pcieh_hw(dev, res, msi);
+   if (err)
goto error_out;
 
err = ppc4xx_msi_init_allocator(dev, msi);

Re: [PATCH v21 06/19] perf, tools: Support alias descriptions

[Arnaldo Carvalho de Melo]

Em Tue, Sep 27, 2016 at 11:11:16AM -0700, Sukadev Bhattiprolu escreveu:
> Arnaldo Carvalho de Melo [a...@kernel.org] wrote:
> > Em Thu, Sep 15, 2016 at 03:24:43PM -0700, Sukadev Bhattiprolu escreveu:
> > > From: Andi Kleen 
> > > Add support to print alias descriptions in perf list, which
> > > are taken from the generated event files.
> > > 
> > > The sorting code is changed to put the events with descriptions
> > > at the end. The descriptions are printed as possibly multiple word
> > > wrapped lines.
> > 
> > So, now I'm trying to reproduce the results below, but I couldn't find a
> > tarball with those .json files for me to use, can you provide me with
> > one?
> 
> The data files are in my github, in the json-code+data-v21 branch
> starting with 23bb101. They are individual commits rather than a
> tarball though.

Ok, I'll pick one for powerpc and another for x86_64 so that I can test
it and Jiri's x-compile support.

Refresh my mind, what is the plan on these files? Are we just going to
provide pointers to where to get them from vendors, ship it in the
kernel, auto-download them as part of the build process?

At least examples that allows to build and have a new 'perf test' entry
to check them automatically seems to be in order, no?

- Arnaldo
 
>   >   https://github.com/sukadev/linux.git
>   >
>   >   Branch  Description
>   >   --
>   >   json-code-v21   Source Code only
>   >   json-code+data-v21  Both code and data(for build/test/pull)
>   > 
> 
> Sukadev

Re: [PATCH] crypto: sha1-powerpc: little-endian support

[Marcelo Cerri]

On Wed, Sep 28, 2016 at 09:20:15PM +0800, Herbert Xu wrote:
> On Wed, Sep 28, 2016 at 10:15:51AM -0300, Marcelo Cerri wrote:
> > Hi Herbert,
> > 
> > Any thoughts on this one?
> 
> Can this patch wait until the next merge window? On the broken
> platforms it should just fail the self-test, right?

Yes. It fails on any LE platform (including Ubuntu and RHEL 7.1).

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

-- 
Regards,
Marcelo


signature.asc
Description: PGP signature

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

[Paulo Flabiano Smorigo]

Wed, Sep 28, 2016 at 08:33:18PM +0800, Herbert Xu wrote:
> On Wed, Sep 28, 2016 at 09:28:44AM -0300, Marcelo Cerri wrote:
> >
> > The big difference between p8_ghash and padlock_sha1 is that
> > padlock_sha1 defines alg->statesize as sizeof(struct sha1_state), which
> > is the descsize value used by sha1_generic. This probably works but
> > it's also wrong because the padlock_sha1 driver does not ensures that
> > sha1_generic is always used.
> 
> It should work because all our SHA implementations use the same
> export format.  This is not necessarily the case for GHASH though.
> 
> > So, one solution is to hardcode ghash-generic as the fallback algorithm
> > and update the descsize direct in its shash_alg structure. There's only
> > one problem with that. ghash-generic desc type (struct ghash_desc_ctx)
> > is not available for vmx_crypto at compile type, the type is defined
> > directly in crypto/ghash-generic.c. That's the reason I added a function
> > to get the fallback desc size at runtime in the patch I wrote as a prove
> > of concept.
> 
> The problem with your patch is that there is no guarantee that
> you will get the same algorithm every time you allocate a fallback.
> Someone may have loaded a new module for example.
> 
> So I think the safe approach is to stick with ghash-generic and
> expose its state data structure in a header file.

Since generic is the only posible fallback for ppc, I think that's a
good solution. :)

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

-- 
Paulo Flabiano Smorigo
IBM Linux Technology Center

Re: [PATCH] crypto: sha1-powerpc: little-endian support

[Herbert Xu]

On Wed, Sep 28, 2016 at 10:15:51AM -0300, Marcelo Cerri wrote:
> Hi Herbert,
> 
> Any thoughts on this one?

Can this patch wait until the next merge window? On the broken
platforms it should just fail the self-test, right?

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

Re: [PATCH] crypto: sha1-powerpc: little-endian support

[Marcelo Cerri]

Hi Herbert,

Any thoughts on this one?

-- 
Regards,
Marcelo

On Fri, Sep 23, 2016 at 04:31:56PM -0300, Marcelo Cerri wrote:
> The driver does not handle endianness properly when loading the input
> data.
> 
> Signed-off-by: Marcelo Cerri 
> ---
>  arch/powerpc/crypto/sha1-powerpc-asm.S | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/crypto/sha1-powerpc-asm.S 
> b/arch/powerpc/crypto/sha1-powerpc-asm.S
> index 125e165..82ddc9b 100644
> --- a/arch/powerpc/crypto/sha1-powerpc-asm.S
> +++ b/arch/powerpc/crypto/sha1-powerpc-asm.S
> @@ -7,6 +7,15 @@
>  #include 
>  #include 
>  
> +#ifdef __BIG_ENDIAN__
> +#define LWZ(rt, d, ra)   \
> + lwz rt,d(ra)
> +#else
> +#define LWZ(rt, d, ra)   \
> + li  rt,d;   \
> + lwbrx   rt,rt,ra
> +#endif
> +
>  /*
>   * We roll the registers for T, A, B, C, D, E around on each
>   * iteration; T on iteration t is A on iteration t+1, and so on.
> @@ -23,7 +32,7 @@
>  #define W(t) (((t)%16)+16)
>  
>  #define LOADW(t) \
> - lwz W(t),(t)*4(r4)
> + LWZ(W(t),(t)*4,r4)
>  
>  #define STEPD0_LOAD(t)   \
>   andcr0,RD(t),RB(t); \
> @@ -33,7 +42,7 @@
>   add r0,RE(t),r15;   \
>   add RT(t),RT(t),r6; \
>   add r14,r0,W(t);\
> - lwz W((t)+4),((t)+4)*4(r4); \
> + LWZ(W((t)+4),((t)+4)*4,r4); \
>   rotlwi  RB(t),RB(t),30; \
>   add RT(t),RT(t),r14
>  
> -- 
> 2.7.4
> 


signature.asc
Description: PGP signature

Re: [PATCH v5] powerpc: Do not make the entire heap executable

[Florian Weimer]

* Jason Gunthorpe:

> Eg that 32 bit powerpc currently unconditionally injects writable,
> executable pages into a user space process.
>
> This critically undermines all the W^X security work that has been
> done in the tool chain and user space by the PPC community.

Exactly, this is how we found it.  I have pretty extensive execmod
tests, and I'm going to put them into glibc eventually.  It would be
nice to cut down the number of architectures where it will fail.
(Even if you don't believe in security hardening.)

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

[Herbert Xu]

On Wed, Sep 28, 2016 at 09:55:58AM -0300, Marcelo Cerri wrote:
> 
> Great! If we check the descsize every time a fallback tfm is allocated
> that should be enough to prevent bigger problems such as memory
> corruptions.

Yes a check wouldn't hurt.
 
> Can I move ghash_desc_ctx to a header file under include/crypto/? Or do
> you do you prefer to do that?

No you can go ahead and do the move.

> Maybe include/crypto/internal/hash.h or a new header file
> include/crypto/internal/ghash.h ?

Let's put it in include/crypto/ghash.h.

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

[RFC/PATCH 43/45] usb: gadget: udc: fsl: remove unnecessary & operation

[Felipe Balbi]

Now that usb_endpoint_maxp() only returns the lowest
11 bits from wMaxPacketSize, we can remove the &
operation from this driver.

Cc: Li Yang 
Cc: 
Signed-off-by: Felipe Balbi 
---
 drivers/usb/gadget/udc/fsl_udc_core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index 4459644b9b55..71094e479a96 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -586,7 +586,6 @@ static int fsl_ep_enable(struct usb_ep *_ep,
case USB_ENDPOINT_XFER_ISOC:
/* Calculate transactions needed for high bandwidth iso */
mult = usb_endpoint_maxp_mult(desc);
-   max = max & 0x7ff;  /* bit 0~10 */
/* 3 transactions at most */
if (mult > 3)
goto en_done;
-- 
2.10.0.440.g21f862b

[RFC/PATCH 20/45] usb: gadget: udc: fsl: make use of new usb_endpoint_maxp_mult()

[Felipe Balbi]

We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.

Cc: Li Yang 
Cc: 
Signed-off-by: Felipe Balbi 
---
 drivers/usb/gadget/udc/fsl_udc_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index aab5221d6c2e..4459644b9b55 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -585,7 +585,7 @@ static int fsl_ep_enable(struct usb_ep *_ep,
break;
case USB_ENDPOINT_XFER_ISOC:
/* Calculate transactions needed for high bandwidth iso */
-   mult = (unsigned char)(1 + ((max >> 11) & 0x03));
+   mult = usb_endpoint_maxp_mult(desc);
max = max & 0x7ff;  /* bit 0~10 */
/* 3 transactions at most */
if (mult > 3)
-- 
2.10.0.440.g21f862b

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

[Marcelo Cerri]

On Wed, Sep 28, 2016 at 08:44:52PM +0800, Herbert Xu wrote:
> On Wed, Sep 28, 2016 at 09:38:41AM -0300, Marcelo Cerri wrote:
> > 
> > The patch forces ghash-generic as the fallback. And I don't think that
> > is a big problem if we decide to go by this path.
> 
> Right it should work but could break for example if we ever decide
> to change the exported state structure for ghash and someone unloads
> the ghash-generic module and reloads a new one.
> 

Great! If we check the descsize every time a fallback tfm is allocated
that should be enough to prevent bigger problems such as memory
corruptions.

> > That would be nice because it would allow p8_ghash to keep using a
> > dynamic fallback, but I'm not that is viable. What do you think?
> 
> We did it for SHA because it was desirable to have multiple
> fallbacks, i.e., a generic C version plus an assembly-optimised
> version.
> 
> Not sure whether the same motiviation exists for GHASH.
> 
> > > Otherwise we can go back to allocating just ghash-generic and
> > > also move its data structure into an exported header file.
> > > 
> > 
> > That would make the fix much more simple and it wouldn't require to get
> > the fallback descsize at runtime.
> 
> This is the easiest fix so let's go with this now.  If we ever
> care enough to have multiple fallbacks for GHASH we can always
> revisit this.  The exported format is not exposed to user-space
> so it can always be changed.

Can I move ghash_desc_ctx to a header file under include/crypto/? Or do
you do you prefer to do that?

Maybe include/crypto/internal/hash.h or a new header file
include/crypto/internal/ghash.h ?

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


signature.asc
Description: PGP signature

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

[Herbert Xu]

On Wed, Sep 28, 2016 at 09:38:41AM -0300, Marcelo Cerri wrote:
> 
> The patch forces ghash-generic as the fallback. And I don't think that
> is a big problem if we decide to go by this path.

Right it should work but could break for example if we ever decide
to change the exported state structure for ghash and someone unloads
the ghash-generic module and reloads a new one.

> That would be nice because it would allow p8_ghash to keep using a
> dynamic fallback, but I'm not that is viable. What do you think?

We did it for SHA because it was desirable to have multiple
fallbacks, i.e., a generic C version plus an assembly-optimised
version.

Not sure whether the same motiviation exists for GHASH.

> > Otherwise we can go back to allocating just ghash-generic and
> > also move its data structure into an exported header file.
> > 
> 
> That would make the fix much more simple and it wouldn't require to get
> the fallback descsize at runtime.

This is the easiest fix so let's go with this now.  If we ever
care enough to have multiple fallbacks for GHASH we can always
revisit this.  The exported format is not exposed to user-space
so it can always be changed.

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

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

[Marcelo Cerri]

Hi Hebert,

On Wed, Sep 28, 2016 at 08:29:35PM +0800, Herbert Xu wrote:
> On Wed, Sep 28, 2016 at 03:40:51AM -0400, Jan Stancek wrote:
> > 
> > Thanks for clearing up how this works in padlock-sha, but
> > we are not exactly in same situation with p8_ghash.
> > 
> > p8_ghash_init_tfm() already updates descsize. Problem in original report
> > is that without custom export/import/statesize p8_ghash_alg.statesize
> > gets initialized by shash_prepare_alg() to alg->descsize:
> 
> Right.
> 
> > so I think we need either:
> > 1) make sure p8_ghash_alg.descsize is correct before we register shash,
> >this is what Marcelo's last patch is doing
> 
> This approach doesn't work because there is no guarantee that
> you'll get the same fallback the next time you allocate a tfm.
> So relying on the descsize being constant can only work if all
> implementations of the fallback use the same desc struct.

The patch forces ghash-generic as the fallback. And I don't think that
is a big problem if we decide to go by this path.
> 
> > 2) provide custom export/import/statesize for p8_ghash_alg
> 
> This works for padlock-sha because every implementation of SHA
> uses the same state data structure from sha.h.  If we can make
> all implementations of ghash agree on the exported state then
> we can use the same approach.

That would be nice because it would allow p8_ghash to keep using a
dynamic fallback, but I'm not that is viable. What do you think?

> 
> Otherwise we can go back to allocating just ghash-generic and
> also move its data structure into an exported header file.
> 

That would make the fix much more simple and it wouldn't require to get
the fallback descsize at runtime.

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

-- 
Regards,
Marcelo


signature.asc
Description: PGP signature

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

[Herbert Xu]

On Wed, Sep 28, 2016 at 09:28:44AM -0300, Marcelo Cerri wrote:
>
> The big difference between p8_ghash and padlock_sha1 is that
> padlock_sha1 defines alg->statesize as sizeof(struct sha1_state), which
> is the descsize value used by sha1_generic. This probably works but
> it's also wrong because the padlock_sha1 driver does not ensures that
> sha1_generic is always used.

It should work because all our SHA implementations use the same
export format.  This is not necessarily the case for GHASH though.

> So, one solution is to hardcode ghash-generic as the fallback algorithm
> and update the descsize direct in its shash_alg structure. There's only
> one problem with that. ghash-generic desc type (struct ghash_desc_ctx)
> is not available for vmx_crypto at compile type, the type is defined
> directly in crypto/ghash-generic.c. That's the reason I added a function
> to get the fallback desc size at runtime in the patch I wrote as a prove
> of concept.

The problem with your patch is that there is no guarantee that
you will get the same algorithm every time you allocate a fallback.
Someone may have loaded a new module for example.

So I think the safe approach is to stick with ghash-generic and
expose its state data structure in a header file.

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

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

[Herbert Xu]

On Wed, Sep 28, 2016 at 03:40:51AM -0400, Jan Stancek wrote:
> 
> Thanks for clearing up how this works in padlock-sha, but
> we are not exactly in same situation with p8_ghash.
> 
> p8_ghash_init_tfm() already updates descsize. Problem in original report
> is that without custom export/import/statesize p8_ghash_alg.statesize
> gets initialized by shash_prepare_alg() to alg->descsize:

Right.

> so I think we need either:
> 1) make sure p8_ghash_alg.descsize is correct before we register shash,
>this is what Marcelo's last patch is doing

This approach doesn't work because there is no guarantee that
you'll get the same fallback the next time you allocate a tfm.
So relying on the descsize being constant can only work if all
implementations of the fallback use the same desc struct.

> 2) provide custom export/import/statesize for p8_ghash_alg

This works for padlock-sha because every implementation of SHA
uses the same state data structure from sha.h.  If we can make
all implementations of ghash agree on the exported state then
we can use the same approach.

Otherwise we can go back to allocating just ghash-generic and
also move its data structure into an exported header file.

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

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

[Marcelo Cerri]

Hi Herbert,

On Wed, Sep 28, 2016 at 10:45:49AM +0800, Herbert Xu wrote:
> On Tue, Sep 27, 2016 at 04:46:44PM -0300, Marcelo Cerri wrote:
> >
> > Can you check if the problem occurs with this patch?
>
> In light of the fact that padlock-sha is the correct example
> to follow, you only need to add one line to the init_tfm fucntion
> to update the descsize based on that of the fallback.
>

Not sure if I'm missing something here but p8_ghash already does that:

 56 static int p8_ghash_init_tfm(struct crypto_tfm *tfm)
 57 {
 ...
 83 shash_tfm->descsize = sizeof(struct p8_ghash_desc_ctx)
 84 + crypto_shash_descsize(fallback);
 85
 86 return 0;
 87 }

I think the problem here is that crypto_ahash_statesize uses the
statesize value (that is initialized with the descsize value from
shash_alg) instead of using the value from the tfm that was updated.

For padlock_sha1, it uses the value from alg->statesize since it defines
import and export functions. It doesn't make much difference if it uses
the value from descsize or statesize here, what really matter is that
it uses the value defined in struct shash_alg and not from the tfm.

The big difference between p8_ghash and padlock_sha1 is that
padlock_sha1 defines alg->statesize as sizeof(struct sha1_state), which
is the descsize value used by sha1_generic. This probably works but
it's also wrong because the padlock_sha1 driver does not ensures that
sha1_generic is always used.

So, one solution is to hardcode ghash-generic as the fallback algorithm
and update the descsize direct in its shash_alg structure. There's only
one problem with that. ghash-generic desc type (struct ghash_desc_ctx)
is not available for vmx_crypto at compile type, the type is defined
directly in crypto/ghash-generic.c. That's the reason I added a function
to get the fallback desc size at runtime in the patch I wrote as a prove
of concept.

--
Regards,
Marcelo


signature.asc
Description: PGP signature

Re: [1/6] powerpc/boot: add sed script

[Michael Ellerman]

On Thu, 2016-22-09 at 06:54:29 UTC, Oliver O'Halloran wrote:
> The powerpc boot wrapper is compiled with a separate "bootcc" toolchain
> rather than the toolchain used for the rest of the kernel. The main
> problem with this is that the wrapper does not have access to the kernel
> headers (without a lot of gross hacks). To get around this the required
> headers are copied into the build directory via several sed scripts
> which rewrite problematic includes. This patch moves these fixups out of
> the makefile into a separate .sed script file to clean up makefile
> slightly.
> 
> Signed-off-by: Oliver O'Halloran 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/1a13de6df9bf998a0b6d9bfa42

cheers

Re: [v5, 01/20] selftests/powerpc: Compile selftests against headers without AT_HWCAP2

[Michael Ellerman]

On Fri, 2016-23-09 at 06:18:07 UTC, Cyril Bur wrote:
> It might be nice to compile selftests against older kernels and
> headers but which may not have HWCAP2.
> 
> Signed-off-by: Cyril Bur 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/96c447077c2f66ed4117fd832a

cheers

[PATCH] dma/fsldma : Unmap region obtained by of_iomap

[Arvind Yadav]

Free memory mapping, if probe is not successful.

Signed-off-by: Arvind Yadav 
---
 drivers/dma/fsldma.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 911b717..7ba8944 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1351,7 +1351,7 @@ static int fsldma_of_probe(struct platform_device *op)
if (!fdev->regs) {
dev_err(>dev, "unable to ioremap registers\n");
err = -ENOMEM;
-   goto out_free_fdev;
+   goto out_free;
}
 
/* map the channel IRQ if it exists, but don't hookup the handler yet */
@@ -1416,6 +1416,8 @@ static int fsldma_of_probe(struct platform_device *op)
 
 out_free_fdev:
irq_dispose_mapping(fdev->irq);
+   iounmap(fdev->regs);
+out_free:
kfree(fdev);
 out_return:
return err;
-- 
1.7.9.5

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

[Jan Stancek]

> Jan,
> 
> Can you check if the problem occurs with this patch?

No issues in over-night test with this patch.

> --- a/drivers/crypto/vmx/vmx.c
> +++ b/drivers/crypto/vmx/vmx.c
> @@ -28,6 +28,8 @@
>  #include 
>  #include 
>  
> +int p8_ghash_fallback_descsize(void);
> +
>  extern struct shash_alg p8_ghash_alg;
>  extern struct crypto_alg p8_aes_alg;
>  extern struct crypto_alg p8_aes_cbc_alg;
> @@ -45,6 +47,7 @@ int __init p8_init(void)
>  {
>   int ret = 0;
>   struct crypto_alg **alg_it;
> + int ghash_descsize;
>  
>   for (alg_it = algs; *alg_it; alg_it++) {
>   ret = crypto_register_alg(*alg_it);
> @@ -59,6 +62,12 @@ int __init p8_init(void)
>   if (ret)
>   return ret;
>  
> + ghash_descsize = p8_ghash_fallback_descsize();
> + if (ghash_descsize < 0) {
> + printk(KERN_ERR "Cannot get descsize for p8_ghash fallback\n");
> + return ghash_descsize;
> + }
> + p8_ghash_alg.descsize += ghash_descsize;
>   ret = crypto_register_shash(_ghash_alg);
>   if (ret) {
>   for (alg_it = algs; *alg_it; alg_it++)

I'd suggest to move this inside vmx/ghash.c to a new function, so all p8_ghash
related code is at single place. Then p8_init() would just call the new
function:
-ret = crypto_register_shash(_ghash_alg);
+ret = register_p8_ghash();

Regards,
Jan

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

[Jan Stancek]

- Original Message -
> From: "Herbert Xu" 
> To: "Marcelo Cerri" 
> Cc: "Jan Stancek" , "rui y wang" , 
> mhce...@linux.vnet.ibm.com,
> leosi...@linux.vnet.ibm.com, pfsmor...@linux.vnet.ibm.com, 
> linux-cry...@vger.kernel.org,
> linuxppc-dev@lists.ozlabs.org, linux-ker...@vger.kernel.org
> Sent: Wednesday, 28 September, 2016 4:45:49 AM
> Subject: Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
> 
> On Tue, Sep 27, 2016 at 04:46:44PM -0300, Marcelo Cerri wrote:
> > 
> > Can you check if the problem occurs with this patch?
> 
> In light of the fact that padlock-sha is the correct example
> to follow, you only need to add one line to the init_tfm fucntion
> to update the descsize based on that of the fallback.

Thanks for clearing up how this works in padlock-sha, but
we are not exactly in same situation with p8_ghash.

p8_ghash_init_tfm() already updates descsize. Problem in original report
is that without custom export/import/statesize p8_ghash_alg.statesize
gets initialized by shash_prepare_alg() to alg->descsize:

crash> p p8_ghash_alg.statesize
$1 = 56

testmgr allocates space for export based on crypto_shash_statesize(),
but shash_default_export() writes based on crypto_shash_descsize():
[8.297902] state: c004b873aa80, statesize: 56
[8.297932] shash_default_export memcpy c004b873aa80 c004b8607da0, 
len: 76

so I think we need either:
1) make sure p8_ghash_alg.descsize is correct before we register shash,
   this is what Marcelo's last patch is doing
2) provide custom export/import/statesize for p8_ghash_alg

Regards,
Jan

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

[PATCH v2] Fix buglet in tlbiel where we set L=1 for ISA 206/7

[Balbir Singh]

This patch fixes a bug where we set bit 10 in tlbie via our
custom .long opcode for tlbiel. These bits are reserved for
2.06/2.07. In ISA 3.0 bit 10 is a part of the register field
RS and we could end up corrupting the meaning of the register
field completely with L=1

Signed-off-by: Balbir Singh 
---
 Changelog v2->v1:
Use the compiler to generate tlbiel as suggsted by mpe
Drop the rest of the changes to macros

 arch/powerpc/mm/hash_native_64.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
index 0e4e965..0f77edf 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -123,8 +123,9 @@ static inline void __tlbiel(unsigned long vpn, int psize, 
int apsize, int ssize)
va |= ssize << 8;
sllp = get_sllp_encoding(apsize);
va |= sllp << 5;
-   asm volatile(".long 0x7c000224 | (%0 << 11) | (0 << 21)"
-: : "r"(va) : "memory");
+   asm volatile(ASM_FTR_IFCLR("tlbiel %0,0", "tlbiel %0", %1)
+: : "r" (va), "i" (CPU_FTR_ARCH_206)
+: "memory");
break;
default:
/* We need 14 to 14 + i bits of va */
@@ -141,8 +142,9 @@ static inline void __tlbiel(unsigned long vpn, int psize, 
int apsize, int ssize)
 */
va |= (vpn & 0xfe);
va |= 1; /* L */
-   asm volatile(".long 0x7c000224 | (%0 << 11) | (1 << 21)"
-: : "r"(va) : "memory");
+   asm volatile(ASM_FTR_IFCLR("tlbiel %0,1", "tlbiel %0", %1)
+: : "r" (va), "i" (CPU_FTR_ARCH_206)
+: "memory");
break;
}
 
-- 
2.5.5

Re: [PATCH] usb: Convert pr_warning to pr_warn

[Nicolas Ferre]

Le 27/09/2016 à 18:16, Joe Perches a écrit :
> Use the more common logging mechanism.
> 
> Miscellanea:
> 
> o Realign multiline statements
> o Coalesce format
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/usb/gadget/function/rndis.c |  9 -
>  drivers/usb/gadget/function/u_serial.c  |  4 ++--
>  drivers/usb/gadget/udc/at91_udc.h   |  2 +-
>  drivers/usb/gadget/udc/atmel_usba_udc.c |  4 ++--

For AT91 and Atmel parts:
Acked-by: Nicolas Ferre 

Thanks

>  drivers/usb/gadget/udc/fsl_usb2_udc.h   |  2 +-
>  drivers/usb/gadget/udc/m66592-udc.c |  4 ++--
>  drivers/usb/gadget/udc/omap_udc.h   |  2 +-
>  drivers/usb/gadget/udc/pxa25x_udc.h |  2 +-
>  drivers/usb/host/isp1362-hcd.c  | 27 ++-
>  drivers/usb/isp1760/isp1760-if.c|  2 +-
>  10 files changed, 29 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/usb/gadget/function/rndis.c 
> b/drivers/usb/gadget/function/rndis.c
> index ab6ac1b74ac0..766c328c15c0 100644
> --- a/drivers/usb/gadget/function/rndis.c
> +++ b/drivers/usb/gadget/function/rndis.c
> @@ -474,8 +474,7 @@ static int gen_ndis_query_resp(struct rndis_params 
> *params, u32 OID, u8 *buf,
>   break;
>  
>   default:
> - pr_warning("%s: query unknown OID 0x%08X\n",
> -  __func__, OID);
> + pr_warn("%s: query unknown OID 0x%08X\n", __func__, OID);
>   }
>   if (retval < 0)
>   length = 0;
> @@ -546,8 +545,8 @@ static int gen_ndis_set_resp(struct rndis_params *params, 
> u32 OID,
>   break;
>  
>   default:
> - pr_warning("%s: set unknown OID 0x%08X, size %d\n",
> -  __func__, OID, buf_len);
> + pr_warn("%s: set unknown OID 0x%08X, size %d\n",
> + __func__, OID, buf_len);
>   }
>  
>   return retval;
> @@ -854,7 +853,7 @@ int rndis_msg_parser(struct rndis_params *params, u8 *buf)
>* In one case those messages seemed to relate to the host
>* suspending itself.
>*/
> - pr_warning("%s: unknown RNDIS message 0x%08X len %d\n",
> + pr_warn("%s: unknown RNDIS message 0x%08X len %d\n",
>   __func__, MsgType, MsgLength);
>   print_hex_dump_bytes(__func__, DUMP_PREFIX_OFFSET,
>buf, MsgLength);
> diff --git a/drivers/usb/gadget/function/u_serial.c 
> b/drivers/usb/gadget/function/u_serial.c
> index e0cd1e4c8892..62ec842874aa 100644
> --- a/drivers/usb/gadget/function/u_serial.c
> +++ b/drivers/usb/gadget/function/u_serial.c
> @@ -622,8 +622,8 @@ static void gs_write_complete(struct usb_ep *ep, struct 
> usb_request *req)
>   switch (req->status) {
>   default:
>   /* presumably a transient fault */
> - pr_warning("%s: unexpected %s status %d\n",
> - __func__, ep->name, req->status);
> + pr_warn("%s: unexpected %s status %d\n",
> + __func__, ep->name, req->status);
>   /* FALL THROUGH */
>   case 0:
>   /* normal completion */
> diff --git a/drivers/usb/gadget/udc/at91_udc.h 
> b/drivers/usb/gadget/udc/at91_udc.h
> index 0a433e6b346b..9bbe72764f31 100644
> --- a/drivers/usb/gadget/udc/at91_udc.h
> +++ b/drivers/usb/gadget/udc/at91_udc.h
> @@ -175,7 +175,7 @@ struct at91_request {
>  #endif
>  
>  #define ERR(stuff...)pr_err("udc: " stuff)
> -#define WARNING(stuff...)pr_warning("udc: " stuff)
> +#define WARNING(stuff...)pr_warn("udc: " stuff)
>  #define INFO(stuff...)   pr_info("udc: " stuff)
>  #define DBG(stuff...)pr_debug("udc: " stuff)
>  
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
> b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index 45bc997d0711..1ef7a9a9d7f5 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -1464,8 +1464,8 @@ static void usba_control_irq(struct usba_udc *udc, 
> struct usba_ep *ep)
>   pkt_len = USBA_BFEXT(BYTE_COUNT, usba_ep_readl(ep, STA));
>   DBG(DBG_HW, "Packet length: %u\n", pkt_len);
>   if (pkt_len != sizeof(crq)) {
> - pr_warning("udc: Invalid packet length %u "
> - "(expected %zu)\n", pkt_len, sizeof(crq));
> + pr_warn("udc: Invalid packet length %u (expected 
> %zu)\n",
> + pkt_len, sizeof(crq));
>   set_protocol_stall(udc, ep);
>   return;
>   }
> diff --git a/drivers/usb/gadget/udc/fsl_usb2_udc.h 
> b/drivers/usb/gadget/udc/fsl_usb2_udc.h
> index 84715625b2b3..e92b8408b6f6 100644
> --- a/drivers/usb/gadget/udc/fsl_usb2_udc.h
> +++ b/drivers/usb/gadget/udc/fsl_usb2_udc.h
> @@ -554,7 +554,7 @@ static void dump_msg(const char *label, const u8