[PATCH 4.9 056/145] RDMA/cma: Make sure that PSN is not over max allowed

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Moni Shoua 


[ Upstream commit 23a9cd2ad90543e9da3786878d2b2729c095439d ]

This patch limits the initial value for PSN to 24 bits as
spec requires.

Signed-off-by: Moni Shoua 
Signed-off-by: Mukesh Kacker 
Signed-off-by: Daniel Jurgens 
Reviewed-by: Parav Pandit 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/infiniband/core/cma.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -744,6 +744,7 @@ struct rdma_cm_id *rdma_create_id(struct
INIT_LIST_HEAD(_priv->mc_list);
get_random_bytes(_priv->seq_num, sizeof id_priv->seq_num);
id_priv->id.route.addr.dev_addr.net = get_net(net);
+   id_priv->seq_num &= 0x00ff;
 
return _priv->id;
 }




[PATCH 4.9 056/145] RDMA/cma: Make sure that PSN is not over max allowed

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Moni Shoua 


[ Upstream commit 23a9cd2ad90543e9da3786878d2b2729c095439d ]

This patch limits the initial value for PSN to 24 bits as
spec requires.

Signed-off-by: Moni Shoua 
Signed-off-by: Mukesh Kacker 
Signed-off-by: Daniel Jurgens 
Reviewed-by: Parav Pandit 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/infiniband/core/cma.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -744,6 +744,7 @@ struct rdma_cm_id *rdma_create_id(struct
INIT_LIST_HEAD(_priv->mc_list);
get_random_bytes(_priv->seq_num, sizeof id_priv->seq_num);
id_priv->id.route.addr.dev_addr.net = get_net(net);
+   id_priv->seq_num &= 0x00ff;
 
return _priv->id;
 }




[PATCH 4.9 058/145] scripts/kernel-doc: Dont fail with status != 0 if error encountered with -none

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Will Deacon 


[ Upstream commit e814bccbafece52a24e152d2395b5d49eef55841 ]

My bisect scripts starting running into build failures when trying to
compile 4.15-rc1 with the builds failing with things like:

drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot 
parse struct or union!

The line in question is actually just a #define, but after some digging
it turns out that my scripts pass W=1 and since commit 3a025e1d1c2ea
("Add optional check for bad kernel-doc comments") that results in
kernel-doc running on each source file. The file in question has a
badly formatted comment immediately before the #define:

/**
 * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for
 * bus layer usage.
 */

which causes the regex in dump_struct to fail (lack of braces following
struct declaration) and kernel-doc returns 1, which causes the build
to fail.

Fix the issue by always returning 0 from kernel-doc when invoked with
-none. It successfully generates no documentation, and prints out any
issues.

Cc: Matthew Wilcox 
Cc: Jonathan Corbet 
Signed-off-by: Will Deacon 
Signed-off-by: Jonathan Corbet 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 scripts/kernel-doc |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -3139,4 +3139,4 @@ if ($verbose && $warnings) {
   print STDERR "$warnings warnings\n";
 }
 
-exit($errors);
+exit($output_mode eq "none" ? 0 : $errors);




[PATCH 4.9 058/145] scripts/kernel-doc: Dont fail with status != 0 if error encountered with -none

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Will Deacon 


[ Upstream commit e814bccbafece52a24e152d2395b5d49eef55841 ]

My bisect scripts starting running into build failures when trying to
compile 4.15-rc1 with the builds failing with things like:

drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot 
parse struct or union!

The line in question is actually just a #define, but after some digging
it turns out that my scripts pass W=1 and since commit 3a025e1d1c2ea
("Add optional check for bad kernel-doc comments") that results in
kernel-doc running on each source file. The file in question has a
badly formatted comment immediately before the #define:

/**
 * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for
 * bus layer usage.
 */

which causes the regex in dump_struct to fail (lack of braces following
struct declaration) and kernel-doc returns 1, which causes the build
to fail.

Fix the issue by always returning 0 from kernel-doc when invoked with
-none. It successfully generates no documentation, and prints out any
issues.

Cc: Matthew Wilcox 
Cc: Jonathan Corbet 
Signed-off-by: Will Deacon 
Signed-off-by: Jonathan Corbet 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 scripts/kernel-doc |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -3139,4 +3139,4 @@ if ($verbose && $warnings) {
   print STDERR "$warnings warnings\n";
 }
 
-exit($errors);
+exit($output_mode eq "none" ? 0 : $errors);




[PATCH 4.9 059/145] ipvlan: Add the skb->mark as flow4s member to lookup route

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Gao Feng 


[ Upstream commit a98a4ebc8c61d20f0150d6be66e0e65223a347af ]

Current codes don't use skb->mark to assign flowi4_mark, it would
make the policy route rule with fwmark doesn't work as expected.

Signed-off-by: Gao Feng 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ipvlan/ipvlan_core.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -370,6 +370,7 @@ static int ipvlan_process_v4_outbound(st
.flowi4_oif = dev->ifindex,
.flowi4_tos = RT_TOS(ip4h->tos),
.flowi4_flags = FLOWI_FLAG_ANYSRC,
+   .flowi4_mark = skb->mark,
.daddr = ip4h->daddr,
.saddr = ip4h->saddr,
};




[PATCH 4.9 059/145] ipvlan: Add the skb->mark as flow4s member to lookup route

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Gao Feng 


[ Upstream commit a98a4ebc8c61d20f0150d6be66e0e65223a347af ]

Current codes don't use skb->mark to assign flowi4_mark, it would
make the policy route rule with fwmark doesn't work as expected.

Signed-off-by: Gao Feng 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ipvlan/ipvlan_core.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -370,6 +370,7 @@ static int ipvlan_process_v4_outbound(st
.flowi4_oif = dev->ifindex,
.flowi4_tos = RT_TOS(ip4h->tos),
.flowi4_flags = FLOWI_FLAG_ANYSRC,
+   .flowi4_mark = skb->mark,
.daddr = ip4h->daddr,
.saddr = ip4h->saddr,
};




[PATCH 4.9 061/145] powerpc/perf: Fix oops when grouping different pmu events

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Ravi Bangoria 


[ Upstream commit 5aa04b3eb6fca63d2e9827be656dcadc26d54e11 ]

When user tries to group imc (In-Memory Collections) event with
normal event, (sometime) kernel crashes with following log:

Faulting instruction address: 0x
[link register   ] c010ce88 power_check_constraints+0x128/0x980
...
c010e238 power_pmu_event_init+0x268/0x6f0
c02dc60c perf_try_init_event+0xdc/0x1a0
c02dce88 perf_event_alloc+0x7b8/0xac0
c02e92e0 SyS_perf_event_open+0x530/0xda0
c000b004 system_call+0x38/0xe0

'event_base' field of 'struct hw_perf_event' is used as flags for
normal hw events and used as memory address for imc events. While
grouping these two types of events, collect_events() tries to
interpret imc 'event_base' as a flag, which causes a corruption
resulting in a crash.

Consider only those events which belongs to 'perf_hw_context' in
collect_events().

Signed-off-by: Ravi Bangoria 
Reviewed-By: Madhavan Srinivasan 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/powerpc/perf/core-book3s.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1381,7 +1381,7 @@ static int collect_events(struct perf_ev
int n = 0;
struct perf_event *event;
 
-   if (!is_software_event(group)) {
+   if (group->pmu->task_ctx_nr == perf_hw_context) {
if (n >= max_count)
return -1;
ctrs[n] = group;
@@ -1389,7 +1389,7 @@ static int collect_events(struct perf_ev
events[n++] = group->hw.config;
}
list_for_each_entry(event, >sibling_list, group_entry) {
-   if (!is_software_event(event) &&
+   if (event->pmu->task_ctx_nr == perf_hw_context &&
event->state != PERF_EVENT_STATE_OFF) {
if (n >= max_count)
return -1;




[PATCH 4.9 061/145] powerpc/perf: Fix oops when grouping different pmu events

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Ravi Bangoria 


[ Upstream commit 5aa04b3eb6fca63d2e9827be656dcadc26d54e11 ]

When user tries to group imc (In-Memory Collections) event with
normal event, (sometime) kernel crashes with following log:

Faulting instruction address: 0x
[link register   ] c010ce88 power_check_constraints+0x128/0x980
...
c010e238 power_pmu_event_init+0x268/0x6f0
c02dc60c perf_try_init_event+0xdc/0x1a0
c02dce88 perf_event_alloc+0x7b8/0xac0
c02e92e0 SyS_perf_event_open+0x530/0xda0
c000b004 system_call+0x38/0xe0

'event_base' field of 'struct hw_perf_event' is used as flags for
normal hw events and used as memory address for imc events. While
grouping these two types of events, collect_events() tries to
interpret imc 'event_base' as a flag, which causes a corruption
resulting in a crash.

Consider only those events which belongs to 'perf_hw_context' in
collect_events().

Signed-off-by: Ravi Bangoria 
Reviewed-By: Madhavan Srinivasan 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/powerpc/perf/core-book3s.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1381,7 +1381,7 @@ static int collect_events(struct perf_ev
int n = 0;
struct perf_event *event;
 
-   if (!is_software_event(group)) {
+   if (group->pmu->task_ctx_nr == perf_hw_context) {
if (n >= max_count)
return -1;
ctrs[n] = group;
@@ -1389,7 +1389,7 @@ static int collect_events(struct perf_ev
events[n++] = group->hw.config;
}
list_for_each_entry(event, >sibling_list, group_entry) {
-   if (!is_software_event(event) &&
+   if (event->pmu->task_ctx_nr == perf_hw_context &&
event->state != PERF_EVENT_STATE_OFF) {
if (n >= max_count)
return -1;




[PATCH 4.9 043/145] ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Tony Lindgren 


[ Upstream commit d09220a887f70368afa79e850c95e74890c0a32d ]

With the CMA changes from Joonsoo Kim , it
was noticed that n900 stopped booting. After investigating it turned
out that n900 save_secure_ram_context does some whacky virtual to
physical address translation for the SRAM data address.

As we now only have minimal parts of omap3 idle code copied to SRAM,
running save_secure_ram_context() in SRAM is not needed. It only gets
called on PM init. And it seems there's no need to ever call this from
SRAM idle code.

So let's just keep save_secure_ram_context() in DDR, and pass it the
physical address of the parameters. We can do everything else in
omap-secure.c like we already do for other secure code.

And since we don't have any documentation, I still have no clue what
the values for 0, 1 and 1 for the parameters might be. If somebody has
figured it out, please do send a patch to add some comments.

Debugged-by: Joonsoo Kim 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm/mach-omap2/omap-secure.c |   19 +++
 arch/arm/mach-omap2/omap-secure.h |4 
 arch/arm/mach-omap2/pm.h  |4 
 arch/arm/mach-omap2/pm34xx.c  |   13 -
 arch/arm/mach-omap2/sleep34xx.S   |   26 --
 5 files changed, 31 insertions(+), 35 deletions(-)

--- a/arch/arm/mach-omap2/omap-secure.c
+++ b/arch/arm/mach-omap2/omap-secure.c
@@ -73,6 +73,25 @@ phys_addr_t omap_secure_ram_mempool_base
return omap_secure_memblock_base;
 }
 
+u32 omap3_save_secure_ram(void __iomem *addr, int size)
+{
+   u32 ret;
+   u32 param[5];
+
+   if (size != OMAP3_SAVE_SECURE_RAM_SZ)
+   return OMAP3_SAVE_SECURE_RAM_SZ;
+
+   param[0] = 4;   /* Number of arguments */
+   param[1] = __pa(addr);  /* Physical address for saving */
+   param[2] = 0;
+   param[3] = 1;
+   param[4] = 1;
+
+   ret = save_secure_ram_context(__pa(param));
+
+   return ret;
+}
+
 /**
  * rx51_secure_dispatcher: Routine to dispatch secure PPA API calls
  * @idx: The PPA API index
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -31,6 +31,8 @@
 /* Maximum Secure memory storage size */
 #define OMAP_SECURE_RAM_STORAGE(88 * SZ_1K)
 
+#define OMAP3_SAVE_SECURE_RAM_SZ   0x803F
+
 /* Secure low power HAL API index */
 #define OMAP4_HAL_SAVESECURERAM_INDEX  0x1a
 #define OMAP4_HAL_SAVEHW_INDEX 0x1b
@@ -65,6 +67,8 @@ extern u32 omap_smc2(u32 id, u32 falg, u
 extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
 extern phys_addr_t omap_secure_ram_mempool_base(void);
 extern int omap_secure_ram_reserve_memblock(void);
+extern u32 save_secure_ram_context(u32 args_pa);
+extern u32 omap3_save_secure_ram(void __iomem *save_regs, int size);
 
 extern u32 rx51_secure_dispatcher(u32 idx, u32 process, u32 flag, u32 nargs,
  u32 arg1, u32 arg2, u32 arg3, u32 arg4);
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -81,10 +81,6 @@ extern unsigned int omap3_do_wfi_sz;
 /* ... and its pointer from SRAM after copy */
 extern void (*omap3_do_wfi_sram)(void);
 
-/* save_secure_ram_context function pointer and size, for copy to SRAM */
-extern int save_secure_ram_context(u32 *addr);
-extern unsigned int save_secure_ram_context_sz;
-
 extern void omap3_save_scratchpad_contents(void);
 
 #define PM_RTA_ERRATUM_i608(1 << 0)
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -48,6 +48,7 @@
 #include "prm3xxx.h"
 #include "pm.h"
 #include "sdrc.h"
+#include "omap-secure.h"
 #include "sram.h"
 #include "control.h"
 #include "vc.h"
@@ -66,7 +67,6 @@ struct power_state {
 
 static LIST_HEAD(pwrst_list);
 
-static int (*_omap_save_secure_sram)(u32 *addr);
 void (*omap3_do_wfi_sram)(void);
 
 static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
@@ -121,8 +121,8 @@ static void omap3_save_secure_ram_contex
 * will hang the system.
 */
pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
-   ret = _omap_save_secure_sram((u32 *)(unsigned long)
-   __pa(omap3_secure_ram_storage));
+   ret = omap3_save_secure_ram(omap3_secure_ram_storage,
+   OMAP3_SAVE_SECURE_RAM_SZ);
pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
/* Following is for error tracking, it should not happen */
if (ret) {
@@ -434,15 +434,10 @@ static int __init pwrdms_setup(struct po
  *
  * The minimum set of functions is pushed to SRAM for execution:
  * - omap3_do_wfi for erratum i581 

[PATCH 4.9 062/145] s390/dasd: prevent prefix I/O error

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Stefan Haberland 


[ Upstream commit da340f921d3454f1521671c7a5a43ad3331fbe50 ]

Prevent that a prefix flag is set based on invalid configuration data.
The validity.verify_base flag should only be set for alias devices.
Usually the unit address type is either one of base, PAV alias or
HyperPAV alias. But in cases where the unit address type is not set or
any other value the validity.verify_base flag might be set as well.
This would lead to follow on errors.
Explicitly check for alias devices and set the validity flag only for
them.

Signed-off-by: Stefan Haberland 
Reviewed-by: Jan Hoeppner 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/s390/block/dasd_eckd.c |   16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

--- a/drivers/s390/block/dasd_eckd.c
+++ b/drivers/s390/block/dasd_eckd.c
@@ -521,10 +521,12 @@ static int prefix_LRE(struct ccw1 *ccw,
pfxdata->validity.define_extent = 1;
 
/* private uid is kept up to date, conf_data may be outdated */
-   if (startpriv->uid.type != UA_BASE_DEVICE) {
+   if (startpriv->uid.type == UA_BASE_PAV_ALIAS)
pfxdata->validity.verify_base = 1;
-   if (startpriv->uid.type == UA_HYPER_PAV_ALIAS)
-   pfxdata->validity.hyper_pav = 1;
+
+   if (startpriv->uid.type == UA_HYPER_PAV_ALIAS) {
+   pfxdata->validity.verify_base = 1;
+   pfxdata->validity.hyper_pav = 1;
}
 
/* define extend data (mostly)*/
@@ -3471,10 +3473,12 @@ static int prepare_itcw(struct itcw *itc
pfxdata.validity.define_extent = 1;
 
/* private uid is kept up to date, conf_data may be outdated */
-   if (startpriv->uid.type != UA_BASE_DEVICE) {
+   if (startpriv->uid.type == UA_BASE_PAV_ALIAS)
+   pfxdata.validity.verify_base = 1;
+
+   if (startpriv->uid.type == UA_HYPER_PAV_ALIAS) {
pfxdata.validity.verify_base = 1;
-   if (startpriv->uid.type == UA_HYPER_PAV_ALIAS)
-   pfxdata.validity.hyper_pav = 1;
+   pfxdata.validity.hyper_pav = 1;
}
 
switch (cmd) {




[PATCH 4.9 043/145] ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Tony Lindgren 


[ Upstream commit d09220a887f70368afa79e850c95e74890c0a32d ]

With the CMA changes from Joonsoo Kim , it
was noticed that n900 stopped booting. After investigating it turned
out that n900 save_secure_ram_context does some whacky virtual to
physical address translation for the SRAM data address.

As we now only have minimal parts of omap3 idle code copied to SRAM,
running save_secure_ram_context() in SRAM is not needed. It only gets
called on PM init. And it seems there's no need to ever call this from
SRAM idle code.

So let's just keep save_secure_ram_context() in DDR, and pass it the
physical address of the parameters. We can do everything else in
omap-secure.c like we already do for other secure code.

And since we don't have any documentation, I still have no clue what
the values for 0, 1 and 1 for the parameters might be. If somebody has
figured it out, please do send a patch to add some comments.

Debugged-by: Joonsoo Kim 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm/mach-omap2/omap-secure.c |   19 +++
 arch/arm/mach-omap2/omap-secure.h |4 
 arch/arm/mach-omap2/pm.h  |4 
 arch/arm/mach-omap2/pm34xx.c  |   13 -
 arch/arm/mach-omap2/sleep34xx.S   |   26 --
 5 files changed, 31 insertions(+), 35 deletions(-)

--- a/arch/arm/mach-omap2/omap-secure.c
+++ b/arch/arm/mach-omap2/omap-secure.c
@@ -73,6 +73,25 @@ phys_addr_t omap_secure_ram_mempool_base
return omap_secure_memblock_base;
 }
 
+u32 omap3_save_secure_ram(void __iomem *addr, int size)
+{
+   u32 ret;
+   u32 param[5];
+
+   if (size != OMAP3_SAVE_SECURE_RAM_SZ)
+   return OMAP3_SAVE_SECURE_RAM_SZ;
+
+   param[0] = 4;   /* Number of arguments */
+   param[1] = __pa(addr);  /* Physical address for saving */
+   param[2] = 0;
+   param[3] = 1;
+   param[4] = 1;
+
+   ret = save_secure_ram_context(__pa(param));
+
+   return ret;
+}
+
 /**
  * rx51_secure_dispatcher: Routine to dispatch secure PPA API calls
  * @idx: The PPA API index
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -31,6 +31,8 @@
 /* Maximum Secure memory storage size */
 #define OMAP_SECURE_RAM_STORAGE(88 * SZ_1K)
 
+#define OMAP3_SAVE_SECURE_RAM_SZ   0x803F
+
 /* Secure low power HAL API index */
 #define OMAP4_HAL_SAVESECURERAM_INDEX  0x1a
 #define OMAP4_HAL_SAVEHW_INDEX 0x1b
@@ -65,6 +67,8 @@ extern u32 omap_smc2(u32 id, u32 falg, u
 extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
 extern phys_addr_t omap_secure_ram_mempool_base(void);
 extern int omap_secure_ram_reserve_memblock(void);
+extern u32 save_secure_ram_context(u32 args_pa);
+extern u32 omap3_save_secure_ram(void __iomem *save_regs, int size);
 
 extern u32 rx51_secure_dispatcher(u32 idx, u32 process, u32 flag, u32 nargs,
  u32 arg1, u32 arg2, u32 arg3, u32 arg4);
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -81,10 +81,6 @@ extern unsigned int omap3_do_wfi_sz;
 /* ... and its pointer from SRAM after copy */
 extern void (*omap3_do_wfi_sram)(void);
 
-/* save_secure_ram_context function pointer and size, for copy to SRAM */
-extern int save_secure_ram_context(u32 *addr);
-extern unsigned int save_secure_ram_context_sz;
-
 extern void omap3_save_scratchpad_contents(void);
 
 #define PM_RTA_ERRATUM_i608(1 << 0)
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -48,6 +48,7 @@
 #include "prm3xxx.h"
 #include "pm.h"
 #include "sdrc.h"
+#include "omap-secure.h"
 #include "sram.h"
 #include "control.h"
 #include "vc.h"
@@ -66,7 +67,6 @@ struct power_state {
 
 static LIST_HEAD(pwrst_list);
 
-static int (*_omap_save_secure_sram)(u32 *addr);
 void (*omap3_do_wfi_sram)(void);
 
 static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
@@ -121,8 +121,8 @@ static void omap3_save_secure_ram_contex
 * will hang the system.
 */
pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
-   ret = _omap_save_secure_sram((u32 *)(unsigned long)
-   __pa(omap3_secure_ram_storage));
+   ret = omap3_save_secure_ram(omap3_secure_ram_storage,
+   OMAP3_SAVE_SECURE_RAM_SZ);
pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
/* Following is for error tracking, it should not happen */
if (ret) {
@@ -434,15 +434,10 @@ static int __init pwrdms_setup(struct po
  *
  * The minimum set of functions is pushed to SRAM for execution:
  * - omap3_do_wfi for erratum i581 WA,
- * - save_secure_ram_context for security extensions.
  */
 void omap_push_sram_idle(void)
 {
omap3_do_wfi_sram = 

[PATCH 4.9 062/145] s390/dasd: prevent prefix I/O error

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Stefan Haberland 


[ Upstream commit da340f921d3454f1521671c7a5a43ad3331fbe50 ]

Prevent that a prefix flag is set based on invalid configuration data.
The validity.verify_base flag should only be set for alias devices.
Usually the unit address type is either one of base, PAV alias or
HyperPAV alias. But in cases where the unit address type is not set or
any other value the validity.verify_base flag might be set as well.
This would lead to follow on errors.
Explicitly check for alias devices and set the validity flag only for
them.

Signed-off-by: Stefan Haberland 
Reviewed-by: Jan Hoeppner 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/s390/block/dasd_eckd.c |   16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

--- a/drivers/s390/block/dasd_eckd.c
+++ b/drivers/s390/block/dasd_eckd.c
@@ -521,10 +521,12 @@ static int prefix_LRE(struct ccw1 *ccw,
pfxdata->validity.define_extent = 1;
 
/* private uid is kept up to date, conf_data may be outdated */
-   if (startpriv->uid.type != UA_BASE_DEVICE) {
+   if (startpriv->uid.type == UA_BASE_PAV_ALIAS)
pfxdata->validity.verify_base = 1;
-   if (startpriv->uid.type == UA_HYPER_PAV_ALIAS)
-   pfxdata->validity.hyper_pav = 1;
+
+   if (startpriv->uid.type == UA_HYPER_PAV_ALIAS) {
+   pfxdata->validity.verify_base = 1;
+   pfxdata->validity.hyper_pav = 1;
}
 
/* define extend data (mostly)*/
@@ -3471,10 +3473,12 @@ static int prepare_itcw(struct itcw *itc
pfxdata.validity.define_extent = 1;
 
/* private uid is kept up to date, conf_data may be outdated */
-   if (startpriv->uid.type != UA_BASE_DEVICE) {
+   if (startpriv->uid.type == UA_BASE_PAV_ALIAS)
+   pfxdata.validity.verify_base = 1;
+
+   if (startpriv->uid.type == UA_HYPER_PAV_ALIAS) {
pfxdata.validity.verify_base = 1;
-   if (startpriv->uid.type == UA_HYPER_PAV_ALIAS)
-   pfxdata.validity.hyper_pav = 1;
+   pfxdata.validity.hyper_pav = 1;
}
 
switch (cmd) {




[PATCH 4.9 065/145] net_sched: red: Avoid devision by zero

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Nogah Frankel 


[ Upstream commit 5c472203421ab4f928aa1ae9e1dbcfdd80324148 ]

Do not allow delta value to be zero since it is used as a divisor.

Fixes: 8af2a218de38 ("sch_red: Adaptative RED AQM")
Signed-off-by: Nogah Frankel 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 include/net/red.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/net/red.h
+++ b/include/net/red.h
@@ -178,7 +178,7 @@ static inline void red_set_parms(struct
p->qth_max  = qth_max << Wlog;
p->Wlog = Wlog;
p->Plog = Plog;
-   if (delta < 0)
+   if (delta <= 0)
delta = 1;
p->qth_delta= delta;
if (!max_P) {




[PATCH 4.9 065/145] net_sched: red: Avoid devision by zero

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Nogah Frankel 


[ Upstream commit 5c472203421ab4f928aa1ae9e1dbcfdd80324148 ]

Do not allow delta value to be zero since it is used as a divisor.

Fixes: 8af2a218de38 ("sch_red: Adaptative RED AQM")
Signed-off-by: Nogah Frankel 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 include/net/red.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/net/red.h
+++ b/include/net/red.h
@@ -178,7 +178,7 @@ static inline void red_set_parms(struct
p->qth_max  = qth_max << Wlog;
p->Wlog = Wlog;
p->Plog = Plog;
-   if (delta < 0)
+   if (delta <= 0)
delta = 1;
p->qth_delta= delta;
if (!max_P) {




[PATCH 4.9 064/145] gianfar: fix a flooded alignment reports because of padding issue.

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Zumeng Chen 


[ Upstream commit 58117672943734715bbe7565ac9f062effa524f0 ]

According to LS1021A RM, the value of PAL can be set so that the start of the
IP header in the receive data buffer is aligned to a 32-bit boundary. Normally,
setting PAL = 2 provides minimal padding to ensure such alignment of the IP
header.

However every incoming packet's 8-byte time stamp will be inserted into the
packet data buffer as padding alignment bytes when hardware time stamping is
enabled.

So we set the padding 8+2 here to avoid the flooded alignment faults:

root@128:~# cat /proc/cpu/alignment
User:   0
System: 17539 (inet_gro_receive+0x114/0x2c0)
Skipped:0
Half:   0
Word:   0
DWord:  0
Multi:  17539
User faults:2 (fixup)

Also shown when exception report enablement

CPU: 0 PID: 161 Comm: irq/66-eth1_g0_ Not tainted 
4.1.21-rt13-WR8.0.0.0_preempt-rt #16
Hardware name: Freescale LS1021A
[<8001b420>] (unwind_backtrace) from [<8001476c>] (show_stack+0x20/0x24)
[<8001476c>] (show_stack) from [<807cfb48>] (dump_stack+0x94/0xac)
[<807cfb48>] (dump_stack) from [<80025d70>] (do_alignment+0x720/0x958)
[<80025d70>] (do_alignment) from [<80009224>] (do_DataAbort+0x40/0xbc)
[<80009224>] (do_DataAbort) from [<80015398>] (__dabt_svc+0x38/0x60)
Exception stack(0x86ad1cc0 to 0x86ad1d08)
1cc0: f9b3e080 86b3d072 2d78d287  866816c0 86b3d05e 86e785d0 
1ce0: 0011 000e 80840ab0 86ad1d3c 86ad1d08 86ad1d08 806d7fc0 806d806c
1d00: 40070013 
[<80015398>] (__dabt_svc) from [<806d806c>] (inet_gro_receive+0x114/0x2c0)
[<806d806c>] (inet_gro_receive) from [<80660eec>] (dev_gro_receive+0x21c/0x3c0)
[<80660eec>] (dev_gro_receive) from [<8066133c>] (napi_gro_receive+0x44/0x17c)
[<8066133c>] (napi_gro_receive) from [<804f0538>] 
(gfar_clean_rx_ring+0x39c/0x7d4)
[<804f0538>] (gfar_clean_rx_ring) from [<804f0bf4>] (gfar_poll_rx_sq+0x58/0xe0)
[<804f0bf4>] (gfar_poll_rx_sq) from [<80660b10>] (net_rx_action+0x27c/0x43c)
[<80660b10>] (net_rx_action) from [<80033638>] (do_current_softirqs+0x1e0/0x3dc)
[<80033638>] (do_current_softirqs) from [<800338c4>] 
(__local_bh_enable+0x90/0xa8)
[<800338c4>] (__local_bh_enable) from [<8008025c>] 
(irq_forced_thread_fn+0x70/0x84)
[<8008025c>] (irq_forced_thread_fn) from [<800805e8>] (irq_thread+0x16c/0x244)
[<800805e8>] (irq_thread) from [<8004e490>] (kthread+0xe8/0x104)
[<8004e490>] (kthread) from [<8000fda8>] (ret_from_fork+0x14/0x2c)

Signed-off-by: Zumeng Chen 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/freescale/gianfar.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -1375,9 +1375,11 @@ static int gfar_probe(struct platform_de
 
gfar_init_addr_hash_table(priv);
 
-   /* Insert receive time stamps into padding alignment bytes */
+   /* Insert receive time stamps into padding alignment bytes, and
+* plus 2 bytes padding to ensure the cpu alignment.
+*/
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER)
-   priv->padding = 8;
+   priv->padding = 8 + DEFAULT_PADDING;
 
if (dev->features & NETIF_F_IP_CSUM ||
priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER)




[PATCH 4.9 064/145] gianfar: fix a flooded alignment reports because of padding issue.

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Zumeng Chen 


[ Upstream commit 58117672943734715bbe7565ac9f062effa524f0 ]

According to LS1021A RM, the value of PAL can be set so that the start of the
IP header in the receive data buffer is aligned to a 32-bit boundary. Normally,
setting PAL = 2 provides minimal padding to ensure such alignment of the IP
header.

However every incoming packet's 8-byte time stamp will be inserted into the
packet data buffer as padding alignment bytes when hardware time stamping is
enabled.

So we set the padding 8+2 here to avoid the flooded alignment faults:

root@128:~# cat /proc/cpu/alignment
User:   0
System: 17539 (inet_gro_receive+0x114/0x2c0)
Skipped:0
Half:   0
Word:   0
DWord:  0
Multi:  17539
User faults:2 (fixup)

Also shown when exception report enablement

CPU: 0 PID: 161 Comm: irq/66-eth1_g0_ Not tainted 
4.1.21-rt13-WR8.0.0.0_preempt-rt #16
Hardware name: Freescale LS1021A
[<8001b420>] (unwind_backtrace) from [<8001476c>] (show_stack+0x20/0x24)
[<8001476c>] (show_stack) from [<807cfb48>] (dump_stack+0x94/0xac)
[<807cfb48>] (dump_stack) from [<80025d70>] (do_alignment+0x720/0x958)
[<80025d70>] (do_alignment) from [<80009224>] (do_DataAbort+0x40/0xbc)
[<80009224>] (do_DataAbort) from [<80015398>] (__dabt_svc+0x38/0x60)
Exception stack(0x86ad1cc0 to 0x86ad1d08)
1cc0: f9b3e080 86b3d072 2d78d287  866816c0 86b3d05e 86e785d0 
1ce0: 0011 000e 80840ab0 86ad1d3c 86ad1d08 86ad1d08 806d7fc0 806d806c
1d00: 40070013 
[<80015398>] (__dabt_svc) from [<806d806c>] (inet_gro_receive+0x114/0x2c0)
[<806d806c>] (inet_gro_receive) from [<80660eec>] (dev_gro_receive+0x21c/0x3c0)
[<80660eec>] (dev_gro_receive) from [<8066133c>] (napi_gro_receive+0x44/0x17c)
[<8066133c>] (napi_gro_receive) from [<804f0538>] 
(gfar_clean_rx_ring+0x39c/0x7d4)
[<804f0538>] (gfar_clean_rx_ring) from [<804f0bf4>] (gfar_poll_rx_sq+0x58/0xe0)
[<804f0bf4>] (gfar_poll_rx_sq) from [<80660b10>] (net_rx_action+0x27c/0x43c)
[<80660b10>] (net_rx_action) from [<80033638>] (do_current_softirqs+0x1e0/0x3dc)
[<80033638>] (do_current_softirqs) from [<800338c4>] 
(__local_bh_enable+0x90/0xa8)
[<800338c4>] (__local_bh_enable) from [<8008025c>] 
(irq_forced_thread_fn+0x70/0x84)
[<8008025c>] (irq_forced_thread_fn) from [<800805e8>] (irq_thread+0x16c/0x244)
[<800805e8>] (irq_thread) from [<8004e490>] (kthread+0xe8/0x104)
[<8004e490>] (kthread) from [<8000fda8>] (ret_from_fork+0x14/0x2c)

Signed-off-by: Zumeng Chen 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/freescale/gianfar.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -1375,9 +1375,11 @@ static int gfar_probe(struct platform_de
 
gfar_init_addr_hash_table(priv);
 
-   /* Insert receive time stamps into padding alignment bytes */
+   /* Insert receive time stamps into padding alignment bytes, and
+* plus 2 bytes padding to ensure the cpu alignment.
+*/
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER)
-   priv->padding = 8;
+   priv->padding = 8 + DEFAULT_PADDING;
 
if (dev->features & NETIF_F_IP_CSUM ||
priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER)




[PATCH 4.9 068/145] brcmfmac: Avoid build error with make W=1

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Andy Shevchenko 


[ Upstream commit 51ef7925e10688c57186d438e784532e063492e4 ]

When I run make W=1 on gcc (Debian 7.2.0-16) 7.2.0 I got an error for
the first run, all next ones are okay.

  CC [M]  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot 
parse struct or union!
scripts/Makefile.build:310: recipe for target 
'drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o' failed

Seems like something happened with W=1 and wrong kernel doc format.
As a quick fix remove dubious /** in the code.

Signed-off-by: Andy Shevchenko 
Acked-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -2049,7 +2049,7 @@ static int brcmf_sdio_txpkt_hdalign(stru
return head_pad;
 }
 
-/**
+/*
  * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for
  * bus layer usage.
  */




[PATCH 4.9 068/145] brcmfmac: Avoid build error with make W=1

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Andy Shevchenko 


[ Upstream commit 51ef7925e10688c57186d438e784532e063492e4 ]

When I run make W=1 on gcc (Debian 7.2.0-16) 7.2.0 I got an error for
the first run, all next ones are okay.

  CC [M]  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot 
parse struct or union!
scripts/Makefile.build:310: recipe for target 
'drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o' failed

Seems like something happened with W=1 and wrong kernel doc format.
As a quick fix remove dubious /** in the code.

Signed-off-by: Andy Shevchenko 
Acked-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -2049,7 +2049,7 @@ static int brcmf_sdio_txpkt_hdalign(stru
return head_pad;
 }
 
-/**
+/*
  * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for
  * bus layer usage.
  */




[PATCH 4.9 067/145] btrfs: Fix possible off-by-one in btrfs_search_path_in_tree

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Nikolay Borisov 


[ Upstream commit c8bcbfbd239ed60a6562964b58034ac8a25f4c31 ]

The name char array passed to btrfs_search_path_in_tree is of size
BTRFS_INO_LOOKUP_PATH_MAX (4080). So the actual accessible char indexes
are in the range of [0, 4079]. Currently the code uses the define but this
represents an off-by-one.

Implications:

Size of btrfs_ioctl_ino_lookup_args is 4096, so the new byte will be
written to extra space, not some padding that could be provided by the
allocator.

btrfs-progs store the arguments on stack, but kernel does own copy of
the ioctl buffer and the off-by-one overwrite does not affect userspace,
but the ending 0 might be lost.

Kernel ioctl buffer is allocated dynamically so we're overwriting
somebody else's memory, and the ioctl is privileged if args.objectid is
not 256. Which is in most cases, but resolving a subvolume stored in
another directory will trigger that path.

Before this patch the buffer was one byte larger, but then the -1 was
not added.

Fixes: ac8e9819d71f907 ("Btrfs: add search and inode lookup ioctls")
Signed-off-by: Nikolay Borisov 
Reviewed-by: David Sterba 
[ added implications ]
Signed-off-by: David Sterba 

Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 fs/btrfs/ioctl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2244,7 +2244,7 @@ static noinline int btrfs_search_path_in
if (!path)
return -ENOMEM;
 
-   ptr = [BTRFS_INO_LOOKUP_PATH_MAX];
+   ptr = [BTRFS_INO_LOOKUP_PATH_MAX - 1];
 
key.objectid = tree_id;
key.type = BTRFS_ROOT_ITEM_KEY;




[PATCH 4.9 067/145] btrfs: Fix possible off-by-one in btrfs_search_path_in_tree

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Nikolay Borisov 


[ Upstream commit c8bcbfbd239ed60a6562964b58034ac8a25f4c31 ]

The name char array passed to btrfs_search_path_in_tree is of size
BTRFS_INO_LOOKUP_PATH_MAX (4080). So the actual accessible char indexes
are in the range of [0, 4079]. Currently the code uses the define but this
represents an off-by-one.

Implications:

Size of btrfs_ioctl_ino_lookup_args is 4096, so the new byte will be
written to extra space, not some padding that could be provided by the
allocator.

btrfs-progs store the arguments on stack, but kernel does own copy of
the ioctl buffer and the off-by-one overwrite does not affect userspace,
but the ending 0 might be lost.

Kernel ioctl buffer is allocated dynamically so we're overwriting
somebody else's memory, and the ioctl is privileged if args.objectid is
not 256. Which is in most cases, but resolving a subvolume stored in
another directory will trigger that path.

Before this patch the buffer was one byte larger, but then the -1 was
not added.

Fixes: ac8e9819d71f907 ("Btrfs: add search and inode lookup ioctls")
Signed-off-by: Nikolay Borisov 
Reviewed-by: David Sterba 
[ added implications ]
Signed-off-by: David Sterba 

Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 fs/btrfs/ioctl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2244,7 +2244,7 @@ static noinline int btrfs_search_path_in
if (!path)
return -ENOMEM;
 
-   ptr = [BTRFS_INO_LOOKUP_PATH_MAX];
+   ptr = [BTRFS_INO_LOOKUP_PATH_MAX - 1];
 
key.objectid = tree_id;
key.type = BTRFS_ROOT_ITEM_KEY;




[PATCH 4.9 069/145] net: ethernet: arc: fix error handling in emac_rockchip_probe

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Branislav Radocaj 


[ Upstream commit e46772a6946a7d1f3fbbc1415871851d6651f1d4 ]

If clk_set_rate() fails, we should disable clk before return.
Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Branislav Radocaj 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/arc/emac_rockchip.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/arc/emac_rockchip.c
+++ b/drivers/net/ethernet/arc/emac_rockchip.c
@@ -220,9 +220,11 @@ static int emac_rockchip_probe(struct pl
 
/* RMII TX/RX needs always a rate of 25MHz */
err = clk_set_rate(priv->macclk, 2500);
-   if (err)
+   if (err) {
dev_err(dev,
"failed to change mac clock rate (%d)\n", err);
+   goto out_clk_disable_macclk;
+   }
}
 
err = arc_emac_probe(ndev, interface);
@@ -232,7 +234,8 @@ static int emac_rockchip_probe(struct pl
}
 
return 0;
-
+out_clk_disable_macclk:
+   clk_disable_unprepare(priv->macclk);
 out_regulator_disable:
if (priv->regulator)
regulator_disable(priv->regulator);




[PATCH 4.9 044/145] ARM: AM33xx: PRM: Remove am33xx_pwrdm_read_prev_pwrst function

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Keerthy 


[ Upstream commit b6d6af7226465b6d11eac09d0be2ab78a4a9eb62 ]

Referring TRM Am335X series:
http://www.ti.com/lit/ug/spruh73p/spruh73p.pdf

The LastPowerStateEntered bitfield is present only for PM_CEFUSE
domain. This is not present in any of the other power domains. Hence
remove the generic am33xx_pwrdm_read_prev_pwrst hook which wrongly
reads the reserved bit fields for all the other power domains.

Reading the reserved bits leads to wrongly interpreting the low
power transitions for various power domains that do not have the
LastPowerStateEntered field. The pm debug counters values are wrong
currently as we are incrementing them based on the reserved bits.

Signed-off-by: Keerthy 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm/mach-omap2/prm33xx.c |   12 
 1 file changed, 12 deletions(-)

--- a/arch/arm/mach-omap2/prm33xx.c
+++ b/arch/arm/mach-omap2/prm33xx.c
@@ -176,17 +176,6 @@ static int am33xx_pwrdm_read_pwrst(struc
return v;
 }
 
-static int am33xx_pwrdm_read_prev_pwrst(struct powerdomain *pwrdm)
-{
-   u32 v;
-
-   v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstst_offs);
-   v &= AM33XX_LASTPOWERSTATEENTERED_MASK;
-   v >>= AM33XX_LASTPOWERSTATEENTERED_SHIFT;
-
-   return v;
-}
-
 static int am33xx_pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm)
 {
am33xx_prm_rmw_reg_bits(AM33XX_LOWPOWERSTATECHANGE_MASK,
@@ -357,7 +346,6 @@ struct pwrdm_ops am33xx_pwrdm_operations
.pwrdm_set_next_pwrst   = am33xx_pwrdm_set_next_pwrst,
.pwrdm_read_next_pwrst  = am33xx_pwrdm_read_next_pwrst,
.pwrdm_read_pwrst   = am33xx_pwrdm_read_pwrst,
-   .pwrdm_read_prev_pwrst  = am33xx_pwrdm_read_prev_pwrst,
.pwrdm_set_logic_retst  = am33xx_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = am33xx_pwrdm_read_logic_pwrst,
.pwrdm_read_logic_retst = am33xx_pwrdm_read_logic_retst,




[PATCH 4.9 069/145] net: ethernet: arc: fix error handling in emac_rockchip_probe

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Branislav Radocaj 


[ Upstream commit e46772a6946a7d1f3fbbc1415871851d6651f1d4 ]

If clk_set_rate() fails, we should disable clk before return.
Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Branislav Radocaj 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/arc/emac_rockchip.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/arc/emac_rockchip.c
+++ b/drivers/net/ethernet/arc/emac_rockchip.c
@@ -220,9 +220,11 @@ static int emac_rockchip_probe(struct pl
 
/* RMII TX/RX needs always a rate of 25MHz */
err = clk_set_rate(priv->macclk, 2500);
-   if (err)
+   if (err) {
dev_err(dev,
"failed to change mac clock rate (%d)\n", err);
+   goto out_clk_disable_macclk;
+   }
}
 
err = arc_emac_probe(ndev, interface);
@@ -232,7 +234,8 @@ static int emac_rockchip_probe(struct pl
}
 
return 0;
-
+out_clk_disable_macclk:
+   clk_disable_unprepare(priv->macclk);
 out_regulator_disable:
if (priv->regulator)
regulator_disable(priv->regulator);




[PATCH 4.9 044/145] ARM: AM33xx: PRM: Remove am33xx_pwrdm_read_prev_pwrst function

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Keerthy 


[ Upstream commit b6d6af7226465b6d11eac09d0be2ab78a4a9eb62 ]

Referring TRM Am335X series:
http://www.ti.com/lit/ug/spruh73p/spruh73p.pdf

The LastPowerStateEntered bitfield is present only for PM_CEFUSE
domain. This is not present in any of the other power domains. Hence
remove the generic am33xx_pwrdm_read_prev_pwrst hook which wrongly
reads the reserved bit fields for all the other power domains.

Reading the reserved bits leads to wrongly interpreting the low
power transitions for various power domains that do not have the
LastPowerStateEntered field. The pm debug counters values are wrong
currently as we are incrementing them based on the reserved bits.

Signed-off-by: Keerthy 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm/mach-omap2/prm33xx.c |   12 
 1 file changed, 12 deletions(-)

--- a/arch/arm/mach-omap2/prm33xx.c
+++ b/arch/arm/mach-omap2/prm33xx.c
@@ -176,17 +176,6 @@ static int am33xx_pwrdm_read_pwrst(struc
return v;
 }
 
-static int am33xx_pwrdm_read_prev_pwrst(struct powerdomain *pwrdm)
-{
-   u32 v;
-
-   v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstst_offs);
-   v &= AM33XX_LASTPOWERSTATEENTERED_MASK;
-   v >>= AM33XX_LASTPOWERSTATEENTERED_SHIFT;
-
-   return v;
-}
-
 static int am33xx_pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm)
 {
am33xx_prm_rmw_reg_bits(AM33XX_LOWPOWERSTATECHANGE_MASK,
@@ -357,7 +346,6 @@ struct pwrdm_ops am33xx_pwrdm_operations
.pwrdm_set_next_pwrst   = am33xx_pwrdm_set_next_pwrst,
.pwrdm_read_next_pwrst  = am33xx_pwrdm_read_next_pwrst,
.pwrdm_read_pwrst   = am33xx_pwrdm_read_pwrst,
-   .pwrdm_read_prev_pwrst  = am33xx_pwrdm_read_prev_pwrst,
.pwrdm_set_logic_retst  = am33xx_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = am33xx_pwrdm_read_logic_pwrst,
.pwrdm_read_logic_retst = am33xx_pwrdm_read_logic_retst,




[PATCH 4.9 072/145] dmaengine: ioat: Fix error handling path

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Christophe JAILLET 


[ Upstream commit 5c9afbda911ce20b3f2181d1e440a0222e1027dd ]

If the last test in 'ioat_dma_self_test()' fails, we must release all
the allocated resources and not just part of them.

Signed-off-by: Christophe JAILLET 
Acked-by: Dave Jiang 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/dma/ioat/init.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/dma/ioat/init.c
+++ b/drivers/dma/ioat/init.c
@@ -388,7 +388,7 @@ static int ioat_dma_self_test(struct ioa
if (memcmp(src, dest, IOAT_TEST_SIZE)) {
dev_err(dev, "Self-test copy failed compare, disabling\n");
err = -ENODEV;
-   goto free_resources;
+   goto unmap_dma;
}
 
 unmap_dma:




[PATCH 4.9 072/145] dmaengine: ioat: Fix error handling path

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Christophe JAILLET 


[ Upstream commit 5c9afbda911ce20b3f2181d1e440a0222e1027dd ]

If the last test in 'ioat_dma_self_test()' fails, we must release all
the allocated resources and not just part of them.

Signed-off-by: Christophe JAILLET 
Acked-by: Dave Jiang 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/dma/ioat/init.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/dma/ioat/init.c
+++ b/drivers/dma/ioat/init.c
@@ -388,7 +388,7 @@ static int ioat_dma_self_test(struct ioa
if (memcmp(src, dest, IOAT_TEST_SIZE)) {
dev_err(dev, "Self-test copy failed compare, disabling\n");
err = -ENODEV;
-   goto free_resources;
+   goto unmap_dma;
}
 
 unmap_dma:




[PATCH 4.9 075/145] ASoC: rockchip: disable clock on error

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Stefan Potyra 


[ Upstream commit c7b92172a61b91936be985cb9bc499a4ebc6489b ]

Disable the clocks in  rk_spdif_probe when an error occurs after one
of the clocks has been enabled previously.

Found by Linux Driver Verification project (linuxtesting.org).

Fixes: f874b80e1571 ASoC: rockchip: Add rockchip SPDIF transceiver driver
Signed-off-by: Stefan Potyra 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 sound/soc/rockchip/rockchip_spdif.c |   18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

--- a/sound/soc/rockchip/rockchip_spdif.c
+++ b/sound/soc/rockchip/rockchip_spdif.c
@@ -318,26 +318,30 @@ static int rk_spdif_probe(struct platfor
spdif->mclk = devm_clk_get(>dev, "mclk");
if (IS_ERR(spdif->mclk)) {
dev_err(>dev, "Can't retrieve rk_spdif master clock\n");
-   return PTR_ERR(spdif->mclk);
+   ret = PTR_ERR(spdif->mclk);
+   goto err_disable_hclk;
}
 
ret = clk_prepare_enable(spdif->mclk);
if (ret) {
dev_err(spdif->dev, "clock enable failed %d\n", ret);
-   return ret;
+   goto err_disable_clocks;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(regs))
-   return PTR_ERR(regs);
+   if (IS_ERR(regs)) {
+   ret = PTR_ERR(regs);
+   goto err_disable_clocks;
+   }
 
spdif->regmap = devm_regmap_init_mmio_clk(>dev, "hclk", regs,
  _spdif_regmap_config);
if (IS_ERR(spdif->regmap)) {
dev_err(>dev,
"Failed to initialise managed register map\n");
-   return PTR_ERR(spdif->regmap);
+   ret = PTR_ERR(spdif->regmap);
+   goto err_disable_clocks;
}
 
spdif->playback_dma_data.addr = res->start + SPDIF_SMPDR;
@@ -369,6 +373,10 @@ static int rk_spdif_probe(struct platfor
 
 err_pm_runtime:
pm_runtime_disable(>dev);
+err_disable_clocks:
+   clk_disable_unprepare(spdif->mclk);
+err_disable_hclk:
+   clk_disable_unprepare(spdif->hclk);
 
return ret;
 }




[PATCH 4.9 075/145] ASoC: rockchip: disable clock on error

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Stefan Potyra 


[ Upstream commit c7b92172a61b91936be985cb9bc499a4ebc6489b ]

Disable the clocks in  rk_spdif_probe when an error occurs after one
of the clocks has been enabled previously.

Found by Linux Driver Verification project (linuxtesting.org).

Fixes: f874b80e1571 ASoC: rockchip: Add rockchip SPDIF transceiver driver
Signed-off-by: Stefan Potyra 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 sound/soc/rockchip/rockchip_spdif.c |   18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

--- a/sound/soc/rockchip/rockchip_spdif.c
+++ b/sound/soc/rockchip/rockchip_spdif.c
@@ -318,26 +318,30 @@ static int rk_spdif_probe(struct platfor
spdif->mclk = devm_clk_get(>dev, "mclk");
if (IS_ERR(spdif->mclk)) {
dev_err(>dev, "Can't retrieve rk_spdif master clock\n");
-   return PTR_ERR(spdif->mclk);
+   ret = PTR_ERR(spdif->mclk);
+   goto err_disable_hclk;
}
 
ret = clk_prepare_enable(spdif->mclk);
if (ret) {
dev_err(spdif->dev, "clock enable failed %d\n", ret);
-   return ret;
+   goto err_disable_clocks;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(regs))
-   return PTR_ERR(regs);
+   if (IS_ERR(regs)) {
+   ret = PTR_ERR(regs);
+   goto err_disable_clocks;
+   }
 
spdif->regmap = devm_regmap_init_mmio_clk(>dev, "hclk", regs,
  _spdif_regmap_config);
if (IS_ERR(spdif->regmap)) {
dev_err(>dev,
"Failed to initialise managed register map\n");
-   return PTR_ERR(spdif->regmap);
+   ret = PTR_ERR(spdif->regmap);
+   goto err_disable_clocks;
}
 
spdif->playback_dma_data.addr = res->start + SPDIF_SMPDR;
@@ -369,6 +373,10 @@ static int rk_spdif_probe(struct platfor
 
 err_pm_runtime:
pm_runtime_disable(>dev);
+err_disable_clocks:
+   clk_disable_unprepare(spdif->mclk);
+err_disable_hclk:
+   clk_disable_unprepare(spdif->hclk);
 
return ret;
 }




[PATCH 4.9 074/145] clk: fix a panic error caused by accessing NULL pointer

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Cai Li 


[ Upstream commit 975b820b6836b6b6c42fb84cd2e772e2b41bca67 ]

In some cases the clock parent would be set NULL when doing re-parent,
it will cause a NULL pointer accessing if clk_set trace event is
enabled.

This patch sets the parent as "none" if the input parameter is NULL.

Fixes: dfc202ead312 (clk: Add tracepoints for hardware operations)
Signed-off-by: Cai Li 
Signed-off-by: Chunyan Zhang 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 include/trace/events/clk.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/include/trace/events/clk.h
+++ b/include/trace/events/clk.h
@@ -134,12 +134,12 @@ DECLARE_EVENT_CLASS(clk_parent,
 
TP_STRUCT__entry(
__string(name,   core->name)
-   __string(pname,  parent->name  )
+   __string(pname, parent ? parent->name : "none" )
),
 
TP_fast_assign(
__assign_str(name, core->name);
-   __assign_str(pname, parent->name);
+   __assign_str(pname, parent ? parent->name : "none");
),
 
TP_printk("%s %s", __get_str(name), __get_str(pname))




[PATCH 4.9 074/145] clk: fix a panic error caused by accessing NULL pointer

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Cai Li 


[ Upstream commit 975b820b6836b6b6c42fb84cd2e772e2b41bca67 ]

In some cases the clock parent would be set NULL when doing re-parent,
it will cause a NULL pointer accessing if clk_set trace event is
enabled.

This patch sets the parent as "none" if the input parameter is NULL.

Fixes: dfc202ead312 (clk: Add tracepoints for hardware operations)
Signed-off-by: Cai Li 
Signed-off-by: Chunyan Zhang 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 include/trace/events/clk.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/include/trace/events/clk.h
+++ b/include/trace/events/clk.h
@@ -134,12 +134,12 @@ DECLARE_EVENT_CLASS(clk_parent,
 
TP_STRUCT__entry(
__string(name,   core->name)
-   __string(pname,  parent->name  )
+   __string(pname, parent ? parent->name : "none" )
),
 
TP_fast_assign(
__assign_str(name, core->name);
-   __assign_str(pname, parent->name);
+   __assign_str(pname, parent ? parent->name : "none");
),
 
TP_printk("%s %s", __get_str(name), __get_str(pname))




[PATCH 4.9 076/145] spi: sun4i: disable clocks in the remove function

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Takuo Koguchi 


[ Upstream commit c810daba0ab5226084a56893a789af427a801146 ]

mclk and hclk need to be disabled. Since pm_runtime_disable does
not disable the clocks, use pm_runtime_force_suspend instead.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Takuo Koguchi 
Acked-by: Maxime Ripard 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/spi/spi-sun4i.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -466,7 +466,7 @@ err_free_master:
 
 static int sun4i_spi_remove(struct platform_device *pdev)
 {
-   pm_runtime_disable(>dev);
+   pm_runtime_force_suspend(>dev);
 
return 0;
 }




[PATCH 4.9 076/145] spi: sun4i: disable clocks in the remove function

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Takuo Koguchi 


[ Upstream commit c810daba0ab5226084a56893a789af427a801146 ]

mclk and hclk need to be disabled. Since pm_runtime_disable does
not disable the clocks, use pm_runtime_force_suspend instead.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Takuo Koguchi 
Acked-by: Maxime Ripard 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/spi/spi-sun4i.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -466,7 +466,7 @@ err_free_master:
 
 static int sun4i_spi_remove(struct platform_device *pdev)
 {
-   pm_runtime_disable(>dev);
+   pm_runtime_force_suspend(>dev);
 
return 0;
 }




[PATCH 4.9 077/145] xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies.

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Steffen Klassert 


[ Upstream commit 732706afe1cc46ef48493b3d2b69c98f36314ae4 ]

On policies with a transport mode template, we pass the addresses
from the flowi to xfrm_state_find(), assuming that the IP addresses
(and address family) don't change during transformation.

Unfortunately our policy template validation is not strict enough.
It is possible to configure policies with transport mode template
where the address family of the template does not match the selectors
address family. This lead to stack-out-of-bound reads because
we compare arddesses of the wrong family. Fix this by refusing
such a configuration, address family can not change on transport
mode.

We use the assumption that, on transport mode, the first templates
address family must match the address family of the policy selector.
Subsequent transport mode templates must mach the address family of
the previous template.

Signed-off-by: Steffen Klassert 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 net/xfrm/xfrm_user.c |9 +
 1 file changed, 9 insertions(+)

--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1380,11 +1380,14 @@ static void copy_templates(struct xfrm_p
 
 static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family)
 {
+   u16 prev_family;
int i;
 
if (nr > XFRM_MAX_DEPTH)
return -EINVAL;
 
+   prev_family = family;
+
for (i = 0; i < nr; i++) {
/* We never validated the ut->family value, so many
 * applications simply leave it at zero.  The check was
@@ -1396,6 +1399,12 @@ static int validate_tmpl(int nr, struct
if (!ut[i].family)
ut[i].family = family;
 
+   if ((ut[i].mode == XFRM_MODE_TRANSPORT) &&
+   (ut[i].family != prev_family))
+   return -EINVAL;
+
+   prev_family = ut[i].family;
+
switch (ut[i].family) {
case AF_INET:
break;




[PATCH 4.9 077/145] xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies.

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Steffen Klassert 


[ Upstream commit 732706afe1cc46ef48493b3d2b69c98f36314ae4 ]

On policies with a transport mode template, we pass the addresses
from the flowi to xfrm_state_find(), assuming that the IP addresses
(and address family) don't change during transformation.

Unfortunately our policy template validation is not strict enough.
It is possible to configure policies with transport mode template
where the address family of the template does not match the selectors
address family. This lead to stack-out-of-bound reads because
we compare arddesses of the wrong family. Fix this by refusing
such a configuration, address family can not change on transport
mode.

We use the assumption that, on transport mode, the first templates
address family must match the address family of the policy selector.
Subsequent transport mode templates must mach the address family of
the previous template.

Signed-off-by: Steffen Klassert 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 net/xfrm/xfrm_user.c |9 +
 1 file changed, 9 insertions(+)

--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1380,11 +1380,14 @@ static void copy_templates(struct xfrm_p
 
 static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family)
 {
+   u16 prev_family;
int i;
 
if (nr > XFRM_MAX_DEPTH)
return -EINVAL;
 
+   prev_family = family;
+
for (i = 0; i < nr; i++) {
/* We never validated the ut->family value, so many
 * applications simply leave it at zero.  The check was
@@ -1396,6 +1399,12 @@ static int validate_tmpl(int nr, struct
if (!ut[i].family)
ut[i].family = family;
 
+   if ((ut[i].mode == XFRM_MODE_TRANSPORT) &&
+   (ut[i].family != prev_family))
+   return -EINVAL;
+
+   prev_family = ut[i].family;
+
switch (ut[i].family) {
case AF_INET:
break;




[PATCH 4.9 045/145] ARM: dts: Fix omap4 hang with GPS connected to USB by using wakeupgen

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Tony Lindgren 


[ Upstream commit cf87634c8b24e24bf379b8c6807c8b0fb5f23567 ]

There's been a reproducable USB OHCI/EHCI cpuidle related hang on omap4
for a while that happens after about 20 - 40 minutes on an idle system
with some data feeding device being connected, like a USB GPS device or
a cellular modem.

This issue happens in cpuidle states C2 and C3 and does not happen if
cpuidle is limited to C1 state only. The symptoms are that the whole
system hangs and never wakes up from idle, and if a watchdog is
configured the system reboots after a while.

Turns out that OHCI/EHCI devices on omap4 are trying to use the GIC
interrupt controller directly as a parent instead of the WUGEN. We
need to pass the interrupts through WUGEN to GIC to provide the wakeup
events for the processor.

Let's fix the issue by removing the gic interrupt-parent and use the
default interrupt-parent wakeupgen instead. Note that omap5.dtsi had
this already fixes earlier by commit 7136d457f365 ("ARM: omap: convert
wakeupgen to stacked domains") but we somehow missed omap4 at that
point.

Fixes: 7136d457f365 ("ARM: omap: convert wakeupgen to stacked domains")
Cc: Dave Gerlach 
Cc: Nishanth Menon 
Cc: Marc Zyngier 
Cc: Sebastian Reichel 
Reviewed-by: Roger Quadros 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm/boot/dts/omap4.dtsi |2 --
 1 file changed, 2 deletions(-)

--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -859,14 +859,12 @@
usbhsohci: ohci@4a064800 {
compatible = "ti,ohci-omap3";
reg = <0x4a064800 0x400>;
-   interrupt-parent = <>;
interrupts = ;
};
 
usbhsehci: ehci@4a064c00 {
compatible = "ti,ehci-omap";
reg = <0x4a064c00 0x400>;
-   interrupt-parent = <>;
interrupts = ;
};
};




[PATCH 4.9 045/145] ARM: dts: Fix omap4 hang with GPS connected to USB by using wakeupgen

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Tony Lindgren 


[ Upstream commit cf87634c8b24e24bf379b8c6807c8b0fb5f23567 ]

There's been a reproducable USB OHCI/EHCI cpuidle related hang on omap4
for a while that happens after about 20 - 40 minutes on an idle system
with some data feeding device being connected, like a USB GPS device or
a cellular modem.

This issue happens in cpuidle states C2 and C3 and does not happen if
cpuidle is limited to C1 state only. The symptoms are that the whole
system hangs and never wakes up from idle, and if a watchdog is
configured the system reboots after a while.

Turns out that OHCI/EHCI devices on omap4 are trying to use the GIC
interrupt controller directly as a parent instead of the WUGEN. We
need to pass the interrupts through WUGEN to GIC to provide the wakeup
events for the processor.

Let's fix the issue by removing the gic interrupt-parent and use the
default interrupt-parent wakeupgen instead. Note that omap5.dtsi had
this already fixes earlier by commit 7136d457f365 ("ARM: omap: convert
wakeupgen to stacked domains") but we somehow missed omap4 at that
point.

Fixes: 7136d457f365 ("ARM: omap: convert wakeupgen to stacked domains")
Cc: Dave Gerlach 
Cc: Nishanth Menon 
Cc: Marc Zyngier 
Cc: Sebastian Reichel 
Reviewed-by: Roger Quadros 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm/boot/dts/omap4.dtsi |2 --
 1 file changed, 2 deletions(-)

--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -859,14 +859,12 @@
usbhsohci: ohci@4a064800 {
compatible = "ti,ohci-omap3";
reg = <0x4a064800 0x400>;
-   interrupt-parent = <>;
interrupts = ;
};
 
usbhsehci: ehci@4a064c00 {
compatible = "ti,ehci-omap";
reg = <0x4a064c00 0x400>;
-   interrupt-parent = <>;
interrupts = ;
};
};




[PATCH 4.9 079/145] dmaengine: jz4740: disable/unprepare clk if probe fails

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Tobias Jordan 


[ Upstream commit eb9436966fdc84cebdf222952a99898ab46d9bb0 ]

in error path of jz4740_dma_probe(), call clk_disable_unprepare() to clean
up.

Found by Linux Driver Verification project (linuxtesting.org).

Fixes: 25ce6c35fea0 MIPS: jz4740: Remove custom DMA API
Signed-off-by: Tobias Jordan 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/dma/dma-jz4740.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/dma/dma-jz4740.c
+++ b/drivers/dma/dma-jz4740.c
@@ -555,7 +555,7 @@ static int jz4740_dma_probe(struct platf
 
ret = dma_async_device_register(dd);
if (ret)
-   return ret;
+   goto err_clk;
 
irq = platform_get_irq(pdev, 0);
ret = request_irq(irq, jz4740_dma_irq, 0, dev_name(>dev), dmadev);
@@ -568,6 +568,8 @@ static int jz4740_dma_probe(struct platf
 
 err_unregister:
dma_async_device_unregister(dd);
+err_clk:
+   clk_disable_unprepare(dmadev->clk);
return ret;
 }
 




[PATCH 4.9 079/145] dmaengine: jz4740: disable/unprepare clk if probe fails

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Tobias Jordan 


[ Upstream commit eb9436966fdc84cebdf222952a99898ab46d9bb0 ]

in error path of jz4740_dma_probe(), call clk_disable_unprepare() to clean
up.

Found by Linux Driver Verification project (linuxtesting.org).

Fixes: 25ce6c35fea0 MIPS: jz4740: Remove custom DMA API
Signed-off-by: Tobias Jordan 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/dma/dma-jz4740.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/dma/dma-jz4740.c
+++ b/drivers/dma/dma-jz4740.c
@@ -555,7 +555,7 @@ static int jz4740_dma_probe(struct platf
 
ret = dma_async_device_register(dd);
if (ret)
-   return ret;
+   goto err_clk;
 
irq = platform_get_irq(pdev, 0);
ret = request_irq(irq, jz4740_dma_irq, 0, dev_name(>dev), dmadev);
@@ -568,6 +568,8 @@ static int jz4740_dma_probe(struct platf
 
 err_unregister:
dma_async_device_unregister(dd);
+err_clk:
+   clk_disable_unprepare(dmadev->clk);
return ret;
 }
 




[PATCH 4.9 046/145] ARM: dts: logicpd-som-lv: Fix gpmc addresses for NAND and enet

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Adam Ford 


[ Upstream commit 3c18bbf3d11d2005da08b57ff26f44ff1c2b12d0 ]

This patch fixes and issue where the NAND and GPMC based ethernet
controller stopped working.  This also updates the GPMC settings
to be consistent with the Logic PD Torpedo development from the
commit listed above.

Fixes: 44e4716499b8 ("ARM: dts: omap3: Fix NAND device nodes")

Signed-off-by: Adam Ford 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts |3 ++-
 arch/arm/boot/dts/logicpd-som-lv.dtsi|2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts
@@ -72,7 +72,8 @@
 };
 
  {
-   ranges = <1 0 0x0800 0x100>;/* CS1: 16MB for LAN9221 */
+   ranges = <0 0 0x3000 0x100  /* CS0: 16MB for NAND */
+ 1 0 0x2c00 0x100>;/* CS1: 16MB for LAN9221 */
 
ethernet@gpmc {
pinctrl-names = "default";
--- a/arch/arm/boot/dts/logicpd-som-lv.dtsi
+++ b/arch/arm/boot/dts/logicpd-som-lv.dtsi
@@ -37,7 +37,7 @@
 };
 
  {
-   ranges = <0 0 0x 0x100>;/* CS0: 16MB for NAND */
+   ranges = <0 0 0x3000 0x100>;/* CS0: 16MB for NAND */
 
nand@0,0 {
compatible = "ti,omap2-nand";




[PATCH 4.9 046/145] ARM: dts: logicpd-som-lv: Fix gpmc addresses for NAND and enet

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Adam Ford 


[ Upstream commit 3c18bbf3d11d2005da08b57ff26f44ff1c2b12d0 ]

This patch fixes and issue where the NAND and GPMC based ethernet
controller stopped working.  This also updates the GPMC settings
to be consistent with the Logic PD Torpedo development from the
commit listed above.

Fixes: 44e4716499b8 ("ARM: dts: omap3: Fix NAND device nodes")

Signed-off-by: Adam Ford 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts |3 ++-
 arch/arm/boot/dts/logicpd-som-lv.dtsi|2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts
@@ -72,7 +72,8 @@
 };
 
  {
-   ranges = <1 0 0x0800 0x100>;/* CS1: 16MB for LAN9221 */
+   ranges = <0 0 0x3000 0x100  /* CS0: 16MB for NAND */
+ 1 0 0x2c00 0x100>;/* CS1: 16MB for LAN9221 */
 
ethernet@gpmc {
pinctrl-names = "default";
--- a/arch/arm/boot/dts/logicpd-som-lv.dtsi
+++ b/arch/arm/boot/dts/logicpd-som-lv.dtsi
@@ -37,7 +37,7 @@
 };
 
  {
-   ranges = <0 0 0x 0x100>;/* CS0: 16MB for NAND */
+   ranges = <0 0 0x3000 0x100>;/* CS0: 16MB for NAND */
 
nand@0,0 {
compatible = "ti,omap2-nand";




[PATCH 4.9 081/145] usb: dwc3: of-simple: fix missing clk_disable_unprepare

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Andreas Platschek 


[ Upstream commit ded600ea9fb51a495d2fcd21e90351df876488e8 ]

If of_clk_get() fails, the clean-up of already initialized clocks should be
the same as when clk_prepare_enable() fails. Thus a clk_disable_unprepare()
for each clock should be called before the clk_put().

Found by Linux Driver Verification project (linuxtesting.org).

Fixes: 16adc674d0d6 ("usb: dwc3: ep0: fix setup_packet_pending initialization")

Signed-off-by: Andreas Platschek 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/dwc3/dwc3-of-simple.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -58,8 +58,10 @@ static int dwc3_of_simple_clk_init(struc
 
clk = of_clk_get(np, i);
if (IS_ERR(clk)) {
-   while (--i >= 0)
+   while (--i >= 0) {
+   clk_disable_unprepare(simple->clks[i]);
clk_put(simple->clks[i]);
+   }
return PTR_ERR(clk);
}
 




[PATCH 4.9 081/145] usb: dwc3: of-simple: fix missing clk_disable_unprepare

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Andreas Platschek 


[ Upstream commit ded600ea9fb51a495d2fcd21e90351df876488e8 ]

If of_clk_get() fails, the clean-up of already initialized clocks should be
the same as when clk_prepare_enable() fails. Thus a clk_disable_unprepare()
for each clock should be called before the clk_put().

Found by Linux Driver Verification project (linuxtesting.org).

Fixes: 16adc674d0d6 ("usb: dwc3: ep0: fix setup_packet_pending initialization")

Signed-off-by: Andreas Platschek 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/dwc3/dwc3-of-simple.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -58,8 +58,10 @@ static int dwc3_of_simple_clk_init(struc
 
clk = of_clk_get(np, i);
if (IS_ERR(clk)) {
-   while (--i >= 0)
+   while (--i >= 0) {
+   clk_disable_unprepare(simple->clks[i]);
clk_put(simple->clks[i]);
+   }
return PTR_ERR(clk);
}
 




[PATCH 4.9 049/145] ARM: dts: am437x-cm-t43: Correct the dmas property of spi0

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Peter Ujfalusi 


[ Upstream commit ca41e244517d6d3f1600c229ff7ca615049c1e9c ]

The DMA binding for eDMA needs 2 parameters, not 1.
The second, missing parameter is the tptc to be used for the channel.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm/boot/dts/am437x-cm-t43.dts |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/am437x-cm-t43.dts
+++ b/arch/arm/boot/dts/am437x-cm-t43.dts
@@ -301,8 +301,8 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-   dmas = < 16
-17>;
+   dmas = < 16 0
+17 0>;
dma-names = "tx0", "rx0";
 
flash: w25q64cvzpig@0 {




[PATCH 4.9 047/145] ARM: dts: logicpd-somlv: Fix wl127x pinmux

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Adam Ford 


[ Upstream commit cd7594ac3281722cb8f10d6f6c7e4287747c7a9d ]

The pin assignment for the wl127x interrupt was incorrect.  I am
not sure how this every worked.  This also eliminates a conflict with
the SMC911x ethernet driver and properly moves pinmuxes for the
related gpio to omap3_pmx_wkup from omap3_pmx_core.

Fixes: ab8dd3aed011 ("ARM: DTS: Add minimal Support for Logic PD
DM3730 SOM-LV")

Signed-off-by: Adam Ford 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm/boot/dts/logicpd-som-lv.dtsi |   14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

--- a/arch/arm/boot/dts/logicpd-som-lv.dtsi
+++ b/arch/arm/boot/dts/logicpd-som-lv.dtsi
@@ -121,7 +121,7 @@
 
  {
interrupts-extended = < 94 _pmx_core2 0x46>;
-   pinctrl-0 = <_pins>;
+   pinctrl-0 = <_pins _gpio>;
pinctrl-names = "default";
vmmc-supply = <_vmmc>;
non-removable;
@@ -132,8 +132,8 @@
wlcore: wlcore@2 {
compatible = "ti,wl1273";
reg = <2>;
-   interrupt-parent = <>;
-   interrupts = <24 IRQ_TYPE_LEVEL_HIGH>; /* gpio 152 */
+   interrupt-parent = <>;
+   interrupts = <2 IRQ_TYPE_LEVEL_HIGH>; /* gpio 2 */
ref-clock-frequency = <2600>;
};
 };
@@ -157,8 +157,6 @@
OMAP3_CORE1_IOPAD(0x2166, PIN_INPUT_PULLUP | MUX_MODE3) 
/* sdmmc2_dat5.sdmmc3_dat1 */
OMAP3_CORE1_IOPAD(0x2168, PIN_INPUT_PULLUP | MUX_MODE3) 
/* sdmmc2_dat6.sdmmc3_dat2 */
OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT_PULLUP | MUX_MODE3) 
/* sdmmc2_dat6.sdmmc3_dat3 */
-   OMAP3_CORE1_IOPAD(0x2184, PIN_INPUT_PULLUP | MUX_MODE4) 
/* mcbsp4_clkx.gpio_152 */
-   OMAP3_CORE1_IOPAD(0x2a0c, PIN_OUTPUT | MUX_MODE4)   
/* sys_boot1.gpio_3 */
OMAP3_CORE1_IOPAD(0x21d0, PIN_INPUT_PULLUP | MUX_MODE3) 
/* mcspi1_cs1.sdmmc3_cmd */
OMAP3_CORE1_IOPAD(0x21d2, PIN_INPUT_PULLUP | MUX_MODE3) 
/* mcspi1_cs2.sdmmc_clk */
>;
@@ -228,6 +226,12 @@
OMAP3_WKUP_IOPAD(0x2a0e, PIN_OUTPUT | MUX_MODE4)
/* sys_boot2.gpio_4 */
>;
};
+   wl127x_gpio: pinmux_wl127x_gpio_pin {
+   pinctrl-single,pins = <
+   OMAP3_WKUP_IOPAD(0x2a0c, PIN_INPUT | MUX_MODE4) 
/* sys_boot0.gpio_2 */
+   OMAP3_WKUP_IOPAD(0x2a0c, PIN_OUTPUT | MUX_MODE4)
/* sys_boot1.gpio_3 */
+   >;
+   };
 };
 
 _pmx_core2 {




[PATCH 4.9 049/145] ARM: dts: am437x-cm-t43: Correct the dmas property of spi0

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Peter Ujfalusi 


[ Upstream commit ca41e244517d6d3f1600c229ff7ca615049c1e9c ]

The DMA binding for eDMA needs 2 parameters, not 1.
The second, missing parameter is the tptc to be used for the channel.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm/boot/dts/am437x-cm-t43.dts |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/am437x-cm-t43.dts
+++ b/arch/arm/boot/dts/am437x-cm-t43.dts
@@ -301,8 +301,8 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-   dmas = < 16
-17>;
+   dmas = < 16 0
+17 0>;
dma-names = "tx0", "rx0";
 
flash: w25q64cvzpig@0 {




[PATCH 4.9 047/145] ARM: dts: logicpd-somlv: Fix wl127x pinmux

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Adam Ford 


[ Upstream commit cd7594ac3281722cb8f10d6f6c7e4287747c7a9d ]

The pin assignment for the wl127x interrupt was incorrect.  I am
not sure how this every worked.  This also eliminates a conflict with
the SMC911x ethernet driver and properly moves pinmuxes for the
related gpio to omap3_pmx_wkup from omap3_pmx_core.

Fixes: ab8dd3aed011 ("ARM: DTS: Add minimal Support for Logic PD
DM3730 SOM-LV")

Signed-off-by: Adam Ford 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm/boot/dts/logicpd-som-lv.dtsi |   14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

--- a/arch/arm/boot/dts/logicpd-som-lv.dtsi
+++ b/arch/arm/boot/dts/logicpd-som-lv.dtsi
@@ -121,7 +121,7 @@
 
  {
interrupts-extended = < 94 _pmx_core2 0x46>;
-   pinctrl-0 = <_pins>;
+   pinctrl-0 = <_pins _gpio>;
pinctrl-names = "default";
vmmc-supply = <_vmmc>;
non-removable;
@@ -132,8 +132,8 @@
wlcore: wlcore@2 {
compatible = "ti,wl1273";
reg = <2>;
-   interrupt-parent = <>;
-   interrupts = <24 IRQ_TYPE_LEVEL_HIGH>; /* gpio 152 */
+   interrupt-parent = <>;
+   interrupts = <2 IRQ_TYPE_LEVEL_HIGH>; /* gpio 2 */
ref-clock-frequency = <2600>;
};
 };
@@ -157,8 +157,6 @@
OMAP3_CORE1_IOPAD(0x2166, PIN_INPUT_PULLUP | MUX_MODE3) 
/* sdmmc2_dat5.sdmmc3_dat1 */
OMAP3_CORE1_IOPAD(0x2168, PIN_INPUT_PULLUP | MUX_MODE3) 
/* sdmmc2_dat6.sdmmc3_dat2 */
OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT_PULLUP | MUX_MODE3) 
/* sdmmc2_dat6.sdmmc3_dat3 */
-   OMAP3_CORE1_IOPAD(0x2184, PIN_INPUT_PULLUP | MUX_MODE4) 
/* mcbsp4_clkx.gpio_152 */
-   OMAP3_CORE1_IOPAD(0x2a0c, PIN_OUTPUT | MUX_MODE4)   
/* sys_boot1.gpio_3 */
OMAP3_CORE1_IOPAD(0x21d0, PIN_INPUT_PULLUP | MUX_MODE3) 
/* mcspi1_cs1.sdmmc3_cmd */
OMAP3_CORE1_IOPAD(0x21d2, PIN_INPUT_PULLUP | MUX_MODE3) 
/* mcspi1_cs2.sdmmc_clk */
>;
@@ -228,6 +226,12 @@
OMAP3_WKUP_IOPAD(0x2a0e, PIN_OUTPUT | MUX_MODE4)
/* sys_boot2.gpio_4 */
>;
};
+   wl127x_gpio: pinmux_wl127x_gpio_pin {
+   pinctrl-single,pins = <
+   OMAP3_WKUP_IOPAD(0x2a0c, PIN_INPUT | MUX_MODE4) 
/* sys_boot0.gpio_2 */
+   OMAP3_WKUP_IOPAD(0x2a0c, PIN_OUTPUT | MUX_MODE4)
/* sys_boot1.gpio_3 */
+   >;
+   };
 };
 
 _pmx_core2 {




[PATCH 4.9 093/145] clk: sunxi-ng: fix build error without CONFIG_RESET_CONTROLLER

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Tobias Regnery 

commit aa01338c018469274848a973bcbd287ef341937c upstream.

With CONFIG_RESET_CONTROLLER=n we get the following link error in the
sunxi-ng clk driver:

drivers/built-in.o: In function `sunxi_ccu_probe':
mux-core.c:(.text+0x12fe68): undefined reference to 'reset_controller_register'
mux-core.c:(.text+0x12fe68): relocation truncated to fit: R_AARCH64_CALL26 
against undefined symbol 'reset_controller_register'

Fix this by adding the appropriate select statement.

Signed-off-by: Tobias Regnery 
Signed-off-by: Maxime Ripard 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/clk/sunxi-ng/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -1,6 +1,7 @@
 config SUNXI_CCU
bool "Clock support for Allwinner SoCs"
depends on ARCH_SUNXI || COMPILE_TEST
+   select RESET_CONTROLLER
default ARCH_SUNXI
 
 if SUNXI_CCU




[PATCH 4.9 083/145] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Karol Herbst 


[ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ]

If something calls ioremap() with an address not aligned to PAGE_SIZE, the
returned address might be not aligned as well. This led to a probe
registered on exactly the returned address, but the entire page was armed
for mmiotracing.

On calling iounmap() the address passed to unregister_kmmio_probe() was
PAGE_SIZE aligned by the caller leading to a complete freeze of the
machine.

We should always page align addresses while (un)registerung mappings,
because the mmiotracer works on top of pages, not mappings. We still keep
track of the probes based on their real addresses and lengths though,
because the mmiotrace still needs to know what are mapped memory regions.

Also move the call to mmiotrace_iounmap() prior page aligning the address,
so that all probes are unregistered properly, otherwise the kernel ends up
failing memory allocations randomly after disabling the mmiotracer.

Tested-by: Lyude 
Signed-off-by: Karol Herbst 
Acked-by: Pekka Paalanen 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: nouv...@lists.freedesktop.org
Link: http://lkml.kernel.org/r/20171127075139.4928-1-kher...@redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/x86/mm/ioremap.c |4 ++--
 arch/x86/mm/kmmio.c   |   12 +++-
 2 files changed, 9 insertions(+), 7 deletions(-)

--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -347,11 +347,11 @@ void iounmap(volatile void __iomem *addr
(void __force *)addr < phys_to_virt(ISA_END_ADDRESS))
return;
 
+   mmiotrace_iounmap(addr);
+
addr = (volatile void __iomem *)
(PAGE_MASK & (unsigned long __force)addr);
 
-   mmiotrace_iounmap(addr);
-
/* Use the vm area unlocked, assuming the caller
   ensures there isn't another iounmap for the same address
   in parallel. Reuse of the virtual address is prevented by
--- a/arch/x86/mm/kmmio.c
+++ b/arch/x86/mm/kmmio.c
@@ -434,17 +434,18 @@ int register_kmmio_probe(struct kmmio_pr
unsigned long flags;
int ret = 0;
unsigned long size = 0;
+   unsigned long addr = p->addr & PAGE_MASK;
const unsigned long size_lim = p->len + (p->addr & ~PAGE_MASK);
unsigned int l;
pte_t *pte;
 
spin_lock_irqsave(_lock, flags);
-   if (get_kmmio_probe(p->addr)) {
+   if (get_kmmio_probe(addr)) {
ret = -EEXIST;
goto out;
}
 
-   pte = lookup_address(p->addr, );
+   pte = lookup_address(addr, );
if (!pte) {
ret = -EINVAL;
goto out;
@@ -453,7 +454,7 @@ int register_kmmio_probe(struct kmmio_pr
kmmio_count++;
list_add_rcu(>list, _probes);
while (size < size_lim) {
-   if (add_kmmio_fault_page(p->addr + size))
+   if (add_kmmio_fault_page(addr + size))
pr_err("Unable to set page fault.\n");
size += page_level_size(l);
}
@@ -527,19 +528,20 @@ void unregister_kmmio_probe(struct kmmio
 {
unsigned long flags;
unsigned long size = 0;
+   unsigned long addr = p->addr & PAGE_MASK;
const unsigned long size_lim = p->len + (p->addr & ~PAGE_MASK);
struct kmmio_fault_page *release_list = NULL;
struct kmmio_delayed_release *drelease;
unsigned int l;
pte_t *pte;
 
-   pte = lookup_address(p->addr, );
+   pte = lookup_address(addr, );
if (!pte)
return;
 
spin_lock_irqsave(_lock, flags);
while (size < size_lim) {
-   release_kmmio_fault_page(p->addr + size, _list);
+   release_kmmio_fault_page(addr + size, _list);
size += page_level_size(l);
}
list_del_rcu(>list);




[PATCH 4.9 093/145] clk: sunxi-ng: fix build error without CONFIG_RESET_CONTROLLER

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Tobias Regnery 

commit aa01338c018469274848a973bcbd287ef341937c upstream.

With CONFIG_RESET_CONTROLLER=n we get the following link error in the
sunxi-ng clk driver:

drivers/built-in.o: In function `sunxi_ccu_probe':
mux-core.c:(.text+0x12fe68): undefined reference to 'reset_controller_register'
mux-core.c:(.text+0x12fe68): relocation truncated to fit: R_AARCH64_CALL26 
against undefined symbol 'reset_controller_register'

Fix this by adding the appropriate select statement.

Signed-off-by: Tobias Regnery 
Signed-off-by: Maxime Ripard 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/clk/sunxi-ng/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -1,6 +1,7 @@
 config SUNXI_CCU
bool "Clock support for Allwinner SoCs"
depends on ARCH_SUNXI || COMPILE_TEST
+   select RESET_CONTROLLER
default ARCH_SUNXI
 
 if SUNXI_CCU




[PATCH 4.9 083/145] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Karol Herbst 


[ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ]

If something calls ioremap() with an address not aligned to PAGE_SIZE, the
returned address might be not aligned as well. This led to a probe
registered on exactly the returned address, but the entire page was armed
for mmiotracing.

On calling iounmap() the address passed to unregister_kmmio_probe() was
PAGE_SIZE aligned by the caller leading to a complete freeze of the
machine.

We should always page align addresses while (un)registerung mappings,
because the mmiotracer works on top of pages, not mappings. We still keep
track of the probes based on their real addresses and lengths though,
because the mmiotrace still needs to know what are mapped memory regions.

Also move the call to mmiotrace_iounmap() prior page aligning the address,
so that all probes are unregistered properly, otherwise the kernel ends up
failing memory allocations randomly after disabling the mmiotracer.

Tested-by: Lyude 
Signed-off-by: Karol Herbst 
Acked-by: Pekka Paalanen 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: nouv...@lists.freedesktop.org
Link: http://lkml.kernel.org/r/20171127075139.4928-1-kher...@redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/x86/mm/ioremap.c |4 ++--
 arch/x86/mm/kmmio.c   |   12 +++-
 2 files changed, 9 insertions(+), 7 deletions(-)

--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -347,11 +347,11 @@ void iounmap(volatile void __iomem *addr
(void __force *)addr < phys_to_virt(ISA_END_ADDRESS))
return;
 
+   mmiotrace_iounmap(addr);
+
addr = (volatile void __iomem *)
(PAGE_MASK & (unsigned long __force)addr);
 
-   mmiotrace_iounmap(addr);
-
/* Use the vm area unlocked, assuming the caller
   ensures there isn't another iounmap for the same address
   in parallel. Reuse of the virtual address is prevented by
--- a/arch/x86/mm/kmmio.c
+++ b/arch/x86/mm/kmmio.c
@@ -434,17 +434,18 @@ int register_kmmio_probe(struct kmmio_pr
unsigned long flags;
int ret = 0;
unsigned long size = 0;
+   unsigned long addr = p->addr & PAGE_MASK;
const unsigned long size_lim = p->len + (p->addr & ~PAGE_MASK);
unsigned int l;
pte_t *pte;
 
spin_lock_irqsave(_lock, flags);
-   if (get_kmmio_probe(p->addr)) {
+   if (get_kmmio_probe(addr)) {
ret = -EEXIST;
goto out;
}
 
-   pte = lookup_address(p->addr, );
+   pte = lookup_address(addr, );
if (!pte) {
ret = -EINVAL;
goto out;
@@ -453,7 +454,7 @@ int register_kmmio_probe(struct kmmio_pr
kmmio_count++;
list_add_rcu(>list, _probes);
while (size < size_lim) {
-   if (add_kmmio_fault_page(p->addr + size))
+   if (add_kmmio_fault_page(addr + size))
pr_err("Unable to set page fault.\n");
size += page_level_size(l);
}
@@ -527,19 +528,20 @@ void unregister_kmmio_probe(struct kmmio
 {
unsigned long flags;
unsigned long size = 0;
+   unsigned long addr = p->addr & PAGE_MASK;
const unsigned long size_lim = p->len + (p->addr & ~PAGE_MASK);
struct kmmio_fault_page *release_list = NULL;
struct kmmio_delayed_release *drelease;
unsigned int l;
pte_t *pte;
 
-   pte = lookup_address(p->addr, );
+   pte = lookup_address(addr, );
if (!pte)
return;
 
spin_lock_irqsave(_lock, flags);
while (size < size_lim) {
-   release_kmmio_fault_page(p->addr + size, _list);
+   release_kmmio_fault_page(addr + size, _list);
size += page_level_size(l);
}
list_del_rcu(>list);




[PATCH 4.9 050/145] perf top: Fix window dimensions change handling

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Jiri Olsa 


[ Upstream commit 89d0aeab4252adc2a7ea693637dd21c588bfa2d1 ]

The stdio perf top crashes when we change the terminal
window size. The reason is that we assumed we get the
perf_top pointer as a signal handler argument which is
not the case.

Changing the SIGWINCH handler logic to change global
resize variable, which is checked in the main thread
loop.

Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Tested-by: Ravi Bangoria 
Cc: Adrian Hunter 
Cc: Andi Kleen 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-ysuzwz77oev1ftgvdscn9...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 tools/perf/builtin-top.c |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -73,6 +73,7 @@
 #include 
 
 static volatile int done;
+static volatile int resize;
 
 #define HEADER_LINE_NR  5
 
@@ -82,10 +83,13 @@ static void perf_top__update_print_entri
 }
 
 static void perf_top__sig_winch(int sig __maybe_unused,
-   siginfo_t *info __maybe_unused, void *arg)
+   siginfo_t *info __maybe_unused, void *arg 
__maybe_unused)
 {
-   struct perf_top *top = arg;
+   resize = 1;
+}
 
+static void perf_top__resize(struct perf_top *top)
+{
get_term_dimensions(>winsize);
perf_top__update_print_entries(top);
 }
@@ -472,7 +476,7 @@ static bool perf_top__handle_keypress(st
.sa_sigaction = perf_top__sig_winch,
.sa_flags = SA_SIGINFO,
};
-   perf_top__sig_winch(SIGWINCH, NULL, top);
+   perf_top__resize(top);
sigaction(SIGWINCH, , NULL);
} else {
signal(SIGWINCH, SIG_DFL);
@@ -1003,6 +1007,11 @@ static int __cmd_top(struct perf_top *to
 
if (hits == top->samples)
ret = perf_evlist__poll(top->evlist, 100);
+
+   if (resize) {
+   perf_top__resize(top);
+   resize = 0;
+   }
}
 
ret = 0;




[PATCH 4.9 050/145] perf top: Fix window dimensions change handling

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Jiri Olsa 


[ Upstream commit 89d0aeab4252adc2a7ea693637dd21c588bfa2d1 ]

The stdio perf top crashes when we change the terminal
window size. The reason is that we assumed we get the
perf_top pointer as a signal handler argument which is
not the case.

Changing the SIGWINCH handler logic to change global
resize variable, which is checked in the main thread
loop.

Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Tested-by: Ravi Bangoria 
Cc: Adrian Hunter 
Cc: Andi Kleen 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-ysuzwz77oev1ftgvdscn9...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 tools/perf/builtin-top.c |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -73,6 +73,7 @@
 #include 
 
 static volatile int done;
+static volatile int resize;
 
 #define HEADER_LINE_NR  5
 
@@ -82,10 +83,13 @@ static void perf_top__update_print_entri
 }
 
 static void perf_top__sig_winch(int sig __maybe_unused,
-   siginfo_t *info __maybe_unused, void *arg)
+   siginfo_t *info __maybe_unused, void *arg 
__maybe_unused)
 {
-   struct perf_top *top = arg;
+   resize = 1;
+}
 
+static void perf_top__resize(struct perf_top *top)
+{
get_term_dimensions(>winsize);
perf_top__update_print_entries(top);
 }
@@ -472,7 +476,7 @@ static bool perf_top__handle_keypress(st
.sa_sigaction = perf_top__sig_winch,
.sa_flags = SA_SIGINFO,
};
-   perf_top__sig_winch(SIGWINCH, NULL, top);
+   perf_top__resize(top);
sigaction(SIGWINCH, , NULL);
} else {
signal(SIGWINCH, SIG_DFL);
@@ -1003,6 +1007,11 @@ static int __cmd_top(struct perf_top *to
 
if (hits == top->samples)
ret = perf_evlist__poll(top->evlist, 100);
+
+   if (resize) {
+   perf_top__resize(top);
+   resize = 0;
+   }
}
 
ret = 0;




[PATCH 4.9 041/145] usbip: keep usbip_device sockfd state in sync with tcp_socket

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Shuah Khan 

commit 009f41aed4b3e11e6dc1e3c07377a10c20f1a5ed upstream.

Keep usbip_device sockfd state in sync with tcp_socket. When tcp_socket
is reset to null, reset sockfd to -1 to keep it in sync.

Signed-off-by: Shuah Khan 
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/usbip/stub_dev.c |3 +++
 drivers/usb/usbip/vhci_hcd.c |2 ++
 2 files changed, 5 insertions(+)

--- a/drivers/usb/usbip/stub_dev.c
+++ b/drivers/usb/usbip/stub_dev.c
@@ -87,6 +87,7 @@ static ssize_t store_sockfd(struct devic
goto err;
 
sdev->ud.tcp_socket = socket;
+   sdev->ud.sockfd = sockfd;
 
spin_unlock_irq(>ud.lock);
 
@@ -186,6 +187,7 @@ static void stub_shutdown_connection(str
if (ud->tcp_socket) {
sockfd_put(ud->tcp_socket);
ud->tcp_socket = NULL;
+   ud->sockfd = -1;
}
 
/* 3. free used data */
@@ -280,6 +282,7 @@ static struct stub_device *stub_device_a
sdev->ud.status = SDEV_ST_AVAILABLE;
spin_lock_init(>ud.lock);
sdev->ud.tcp_socket = NULL;
+   sdev->ud.sockfd = -1;
 
INIT_LIST_HEAD(>priv_init);
INIT_LIST_HEAD(>priv_tx);
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -832,6 +832,7 @@ static void vhci_shutdown_connection(str
if (vdev->ud.tcp_socket) {
sockfd_put(vdev->ud.tcp_socket);
vdev->ud.tcp_socket = NULL;
+   vdev->ud.sockfd = -1;
}
pr_info("release socket\n");
 
@@ -879,6 +880,7 @@ static void vhci_device_reset(struct usb
if (ud->tcp_socket) {
sockfd_put(ud->tcp_socket);
ud->tcp_socket = NULL;
+   ud->sockfd = -1;
}
ud->status = VDEV_ST_NULL;
 




[PATCH 4.9 048/145] ARM: dts: am4372: Correct the interrupts_properties of McASP

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Peter Ujfalusi 


[ Upstream commit 627395a6f8091c0aa18f49dca7df59ba3ec147ef ]

Fixes the following warnings:

arch/arm/boot/dts/am437x-cm-t43.dtb: Warning (interrupts_property):
interrupts size is (8), expected multiple of 12 in
/ocp@4400/mcasp@48038000

arch/arm/boot/dts/am437x-cm-t43.dtb: Warning (interrupts_property):
interrupts size is (8), expected multiple of 12 in
/ocp@4400/mcasp@4803C000

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm/boot/dts/am4372.dtsi |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -926,7 +926,8 @@
reg = <0x48038000 0x2000>,
  <0x4600 0x40>;
reg-names = "mpu", "dat";
-   interrupts = <80>, <81>;
+   interrupts = ,
+;
interrupt-names = "tx", "rx";
status = "disabled";
dmas = < 8 2>,
@@ -940,7 +941,8 @@
reg = <0x4803C000 0x2000>,
  <0x4640 0x40>;
reg-names = "mpu", "dat";
-   interrupts = <82>, <83>;
+   interrupts = ,
+;
interrupt-names = "tx", "rx";
status = "disabled";
dmas = < 10 2>,




[PATCH 4.9 041/145] usbip: keep usbip_device sockfd state in sync with tcp_socket

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Shuah Khan 

commit 009f41aed4b3e11e6dc1e3c07377a10c20f1a5ed upstream.

Keep usbip_device sockfd state in sync with tcp_socket. When tcp_socket
is reset to null, reset sockfd to -1 to keep it in sync.

Signed-off-by: Shuah Khan 
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/usbip/stub_dev.c |3 +++
 drivers/usb/usbip/vhci_hcd.c |2 ++
 2 files changed, 5 insertions(+)

--- a/drivers/usb/usbip/stub_dev.c
+++ b/drivers/usb/usbip/stub_dev.c
@@ -87,6 +87,7 @@ static ssize_t store_sockfd(struct devic
goto err;
 
sdev->ud.tcp_socket = socket;
+   sdev->ud.sockfd = sockfd;
 
spin_unlock_irq(>ud.lock);
 
@@ -186,6 +187,7 @@ static void stub_shutdown_connection(str
if (ud->tcp_socket) {
sockfd_put(ud->tcp_socket);
ud->tcp_socket = NULL;
+   ud->sockfd = -1;
}
 
/* 3. free used data */
@@ -280,6 +282,7 @@ static struct stub_device *stub_device_a
sdev->ud.status = SDEV_ST_AVAILABLE;
spin_lock_init(>ud.lock);
sdev->ud.tcp_socket = NULL;
+   sdev->ud.sockfd = -1;
 
INIT_LIST_HEAD(>priv_init);
INIT_LIST_HEAD(>priv_tx);
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -832,6 +832,7 @@ static void vhci_shutdown_connection(str
if (vdev->ud.tcp_socket) {
sockfd_put(vdev->ud.tcp_socket);
vdev->ud.tcp_socket = NULL;
+   vdev->ud.sockfd = -1;
}
pr_info("release socket\n");
 
@@ -879,6 +880,7 @@ static void vhci_device_reset(struct usb
if (ud->tcp_socket) {
sockfd_put(ud->tcp_socket);
ud->tcp_socket = NULL;
+   ud->sockfd = -1;
}
ud->status = VDEV_ST_NULL;
 




[PATCH 4.9 048/145] ARM: dts: am4372: Correct the interrupts_properties of McASP

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Peter Ujfalusi 


[ Upstream commit 627395a6f8091c0aa18f49dca7df59ba3ec147ef ]

Fixes the following warnings:

arch/arm/boot/dts/am437x-cm-t43.dtb: Warning (interrupts_property):
interrupts size is (8), expected multiple of 12 in
/ocp@4400/mcasp@48038000

arch/arm/boot/dts/am437x-cm-t43.dtb: Warning (interrupts_property):
interrupts size is (8), expected multiple of 12 in
/ocp@4400/mcasp@4803C000

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm/boot/dts/am4372.dtsi |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -926,7 +926,8 @@
reg = <0x48038000 0x2000>,
  <0x4600 0x40>;
reg-names = "mpu", "dat";
-   interrupts = <80>, <81>;
+   interrupts = ,
+;
interrupt-names = "tx", "rx";
status = "disabled";
dmas = < 8 2>,
@@ -940,7 +941,8 @@
reg = <0x4803C000 0x2000>,
  <0x4640 0x40>;
reg-names = "mpu", "dat";
-   interrupts = <82>, <83>;
+   interrupts = ,
+;
interrupt-names = "tx", "rx";
status = "disabled";
dmas = < 10 2>,




[PATCH 4.9 106/145] arm64: define BUG() instruction without CONFIG_BUG

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit f13d52cb3fad03c237572be2ee691e1fe2d1d7bb upstream.

This mirrors commit e9c38ceba8d9 ("ARM: 8455/1: define __BUG as
asm(BUG_INSTR) without CONFIG_BUG") to make the behavior of
arm64 consistent with arm and x86, and avoids lots of warnings in
randconfig builds, such as:

kernel/seccomp.c: In function '__seccomp_filter':
kernel/seccomp.c:666:1: error: no return statement in function returning 
non-void [-Werror=return-type]

Acked-by: Will Deacon 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/include/asm/bug.h |   35 ---
 1 file changed, 20 insertions(+), 15 deletions(-)

--- a/arch/arm64/include/asm/bug.h
+++ b/arch/arm64/include/asm/bug.h
@@ -20,9 +20,6 @@
 
 #include 
 
-#ifdef CONFIG_GENERIC_BUG
-#define HAVE_ARCH_BUG
-
 #ifdef CONFIG_DEBUG_BUGVERBOSE
 #define _BUGVERBOSE_LOCATION(file, line) __BUGVERBOSE_LOCATION(file, line)
 #define __BUGVERBOSE_LOCATION(file, line)  \
@@ -36,28 +33,36 @@
 #define _BUGVERBOSE_LOCATION(file, line)
 #endif
 
-#define _BUG_FLAGS(flags) __BUG_FLAGS(flags)
+#ifdef CONFIG_GENERIC_BUG
 
-#define __BUG_FLAGS(flags) asm volatile (  \
+#define __BUG_ENTRY(flags) \
".pushsection __bug_table,\"a\"\n\t"\
".align 2\n\t"  \
"0: .long 1f - 0b\n\t"  \
 _BUGVERBOSE_LOCATION(__FILE__, __LINE__)   \
".short " #flags "\n\t" \
".popsection\n" \
-   \
-   "1: brk %[imm]" \
-   :: [imm] "i" (BUG_BRK_IMM)  \
-)
-
-#define BUG() do { \
-   _BUG_FLAGS(0);  \
-   unreachable();  \
+   "1: "
+#else
+#define __BUG_ENTRY(flags) ""
+#endif
+
+#define __BUG_FLAGS(flags) \
+   asm volatile (  \
+   __BUG_ENTRY(flags)  \
+   "brk %[imm]" :: [imm] "i" (BUG_BRK_IMM) \
+   );
+
+
+#define BUG() do { \
+   __BUG_FLAGS(0); \
+   unreachable();  \
 } while (0)
 
-#define __WARN_TAINT(taint) _BUG_FLAGS(BUGFLAG_TAINT(taint))
+#define __WARN_TAINT(taint)\
+   __BUG_FLAGS(BUGFLAG_TAINT(taint))
 
-#endif /* ! CONFIG_GENERIC_BUG */
+#define HAVE_ARCH_BUG
 
 #include 
 




[PATCH 4.9 106/145] arm64: define BUG() instruction without CONFIG_BUG

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit f13d52cb3fad03c237572be2ee691e1fe2d1d7bb upstream.

This mirrors commit e9c38ceba8d9 ("ARM: 8455/1: define __BUG as
asm(BUG_INSTR) without CONFIG_BUG") to make the behavior of
arm64 consistent with arm and x86, and avoids lots of warnings in
randconfig builds, such as:

kernel/seccomp.c: In function '__seccomp_filter':
kernel/seccomp.c:666:1: error: no return statement in function returning 
non-void [-Werror=return-type]

Acked-by: Will Deacon 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/include/asm/bug.h |   35 ---
 1 file changed, 20 insertions(+), 15 deletions(-)

--- a/arch/arm64/include/asm/bug.h
+++ b/arch/arm64/include/asm/bug.h
@@ -20,9 +20,6 @@
 
 #include 
 
-#ifdef CONFIG_GENERIC_BUG
-#define HAVE_ARCH_BUG
-
 #ifdef CONFIG_DEBUG_BUGVERBOSE
 #define _BUGVERBOSE_LOCATION(file, line) __BUGVERBOSE_LOCATION(file, line)
 #define __BUGVERBOSE_LOCATION(file, line)  \
@@ -36,28 +33,36 @@
 #define _BUGVERBOSE_LOCATION(file, line)
 #endif
 
-#define _BUG_FLAGS(flags) __BUG_FLAGS(flags)
+#ifdef CONFIG_GENERIC_BUG
 
-#define __BUG_FLAGS(flags) asm volatile (  \
+#define __BUG_ENTRY(flags) \
".pushsection __bug_table,\"a\"\n\t"\
".align 2\n\t"  \
"0: .long 1f - 0b\n\t"  \
 _BUGVERBOSE_LOCATION(__FILE__, __LINE__)   \
".short " #flags "\n\t" \
".popsection\n" \
-   \
-   "1: brk %[imm]" \
-   :: [imm] "i" (BUG_BRK_IMM)  \
-)
-
-#define BUG() do { \
-   _BUG_FLAGS(0);  \
-   unreachable();  \
+   "1: "
+#else
+#define __BUG_ENTRY(flags) ""
+#endif
+
+#define __BUG_FLAGS(flags) \
+   asm volatile (  \
+   __BUG_ENTRY(flags)  \
+   "brk %[imm]" :: [imm] "i" (BUG_BRK_IMM) \
+   );
+
+
+#define BUG() do { \
+   __BUG_FLAGS(0); \
+   unreachable();  \
 } while (0)
 
-#define __WARN_TAINT(taint) _BUG_FLAGS(BUGFLAG_TAINT(taint))
+#define __WARN_TAINT(taint)\
+   __BUG_FLAGS(BUGFLAG_TAINT(taint))
 
-#endif /* ! CONFIG_GENERIC_BUG */
+#define HAVE_ARCH_BUG
 
 #include 
 




[PATCH 4.9 103/145] scsi: advansys: fix build warning for PCI=n

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit f46e7cd36b5f2ce2bfb567e278a10ca717f85b84 upstream.

The advansys probe function tries to handle both ISA and PCI cases, each
hidden in an #ifdef when unused. This leads to a warning indicating that
when PCI is disabled we could be using uninitialized data:

drivers/scsi/advansys.c: In function  advansys_board_found :
drivers/scsi/advansys.c:11036:5: error:  ret  may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
drivers/scsi/advansys.c:10928:28: note:  ret  was declared here
drivers/scsi/advansys.c:11309:8: error:  share_irq  may be used uninitialized 
in this function [-Werror=maybe-uninitialized]
drivers/scsi/advansys.c:10928:6: note:  share_irq  was declared here

This cannot happen in practice because the hardware in question only
exists for PCI, but changing the code to just error out here is better
for consistency and avoids the warning.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/advansys.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -11030,6 +11030,9 @@ static int advansys_board_found(struct S
ASC_DBG(2, "AdvInitGetConfig()\n");
 
ret = AdvInitGetConfig(pdev, shost) ? -ENODEV : 0;
+#else
+   share_irq = 0;
+   ret = -ENODEV;
 #endif /* CONFIG_PCI */
}
 




[PATCH 4.9 100/145] PCI: Change pci_host_common_probe() visibility

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Marc Gonzalez 

commit de5bbdd01cf9ee3cd4586b5a970d3ea015c6d7e3 upstream.

pci_host_common_probe() is defined when CONFIG_PCI_HOST_COMMON=y;
therefore the function declaration should match that.

  drivers/pci/host/pcie-tango.c:300:9: error:
implicit declaration of function 'pci_host_common_probe'

Signed-off-by: Marc Gonzalez 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/pci-ecam.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/linux/pci-ecam.h
+++ b/include/linux/pci-ecam.h
@@ -59,7 +59,7 @@ void __iomem *pci_ecam_map_bus(struct pc
 /* default ECAM ops */
 extern struct pci_ecam_ops pci_generic_ecam_ops;
 
-#ifdef CONFIG_PCI_HOST_GENERIC
+#ifdef CONFIG_PCI_HOST_COMMON
 /* for DT-based PCI controllers that support ECAM */
 int pci_host_common_probe(struct platform_device *pdev,
  struct pci_ecam_ops *ops);




[PATCH 4.9 103/145] scsi: advansys: fix build warning for PCI=n

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit f46e7cd36b5f2ce2bfb567e278a10ca717f85b84 upstream.

The advansys probe function tries to handle both ISA and PCI cases, each
hidden in an #ifdef when unused. This leads to a warning indicating that
when PCI is disabled we could be using uninitialized data:

drivers/scsi/advansys.c: In function  advansys_board_found :
drivers/scsi/advansys.c:11036:5: error:  ret  may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
drivers/scsi/advansys.c:10928:28: note:  ret  was declared here
drivers/scsi/advansys.c:11309:8: error:  share_irq  may be used uninitialized 
in this function [-Werror=maybe-uninitialized]
drivers/scsi/advansys.c:10928:6: note:  share_irq  was declared here

This cannot happen in practice because the hardware in question only
exists for PCI, but changing the code to just error out here is better
for consistency and avoids the warning.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/advansys.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -11030,6 +11030,9 @@ static int advansys_board_found(struct S
ASC_DBG(2, "AdvInitGetConfig()\n");
 
ret = AdvInitGetConfig(pdev, shost) ? -ENODEV : 0;
+#else
+   share_irq = 0;
+   ret = -ENODEV;
 #endif /* CONFIG_PCI */
}
 




[PATCH 4.9 100/145] PCI: Change pci_host_common_probe() visibility

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Marc Gonzalez 

commit de5bbdd01cf9ee3cd4586b5a970d3ea015c6d7e3 upstream.

pci_host_common_probe() is defined when CONFIG_PCI_HOST_COMMON=y;
therefore the function declaration should match that.

  drivers/pci/host/pcie-tango.c:300:9: error:
implicit declaration of function 'pci_host_common_probe'

Signed-off-by: Marc Gonzalez 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/pci-ecam.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/linux/pci-ecam.h
+++ b/include/linux/pci-ecam.h
@@ -59,7 +59,7 @@ void __iomem *pci_ecam_map_bus(struct pc
 /* default ECAM ops */
 extern struct pci_ecam_ops pci_generic_ecam_ops;
 
-#ifdef CONFIG_PCI_HOST_GENERIC
+#ifdef CONFIG_PCI_HOST_COMMON
 /* for DT-based PCI controllers that support ECAM */
 int pci_host_common_probe(struct platform_device *pdev,
  struct pci_ecam_ops *ops);




[PATCH 4.9 108/145] tools build: Add tools tree support for make -s

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Josh Poimboeuf 

commit e572d0887137acfc53f18175522964ec19d88175 upstream.

When doing a kernel build with 'make -s', everything is silenced except
the objtool build.  That's because the tools tree support for silent
builds is some combination of missing and broken.

Three changes are needed to fix it:

- Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the
  tools Makefiles can see it.

- tools/scripts/Makefile.include: fix the tools Makefiles' ability to
  recognize '-s'.  The MAKE_VERSION and MAKEFLAGS checks are copied from
  the top-level Makefile.  This silences the "DESCEND objtool" message.

- tools/build/Makefile.build: add support to the tools Build files for
  recognizing '-s'.  Again the MAKE_VERSION and MAKEFLAGS checks are
  copied from the top-level Makefile.  This silences all the object
  compile/link messages.

Reported-and-Tested-by: Peter Zijlstra 
Signed-off-by: Josh Poimboeuf 
Cc: Jiri Olsa 
Cc: Michal Marek 
Link: 
http://lkml.kernel.org/r/e8967562ef640c3ae9a76da4ae0f4e47df737c34.1484799200.git.jpoim...@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman 

---
 Makefile   |6 --
 tools/build/Makefile.build |   10 ++
 tools/scripts/Makefile.include |   12 +++-
 3 files changed, 25 insertions(+), 3 deletions(-)

--- a/Makefile
+++ b/Makefile
@@ -87,10 +87,12 @@ endif
 ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4
 ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
   quiet=silent_
+  tools_silent=s
 endif
 else   # make-3.8x
 ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
   quiet=silent_
+  tools_silent=-s
 endif
 endif
 
@@ -1614,11 +1616,11 @@ image_name:
 # Clear a bunch of variables before executing the submake
 tools/: FORCE
$(Q)mkdir -p $(objtree)/tools
-   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" 
O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/
+   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% 
-j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C 
$(src)/tools/
 
 tools/%: FORCE
$(Q)mkdir -p $(objtree)/tools
-   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" 
O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/ $*
+   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% 
-j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C 
$(src)/tools/ $*
 
 # Single targets
 # ---
--- a/tools/build/Makefile.build
+++ b/tools/build/Makefile.build
@@ -19,6 +19,16 @@ else
   Q=@
 endif
 
+ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4
+ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
+  quiet=silent_
+endif
+else   # make-3.8x
+ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
+  quiet=silent_
+endif
+endif
+
 build-dir := $(srctree)/tools/build
 
 # Define $(fixdep) for dep-cmd function
--- a/tools/scripts/Makefile.include
+++ b/tools/scripts/Makefile.include
@@ -46,6 +46,16 @@ else
 NO_SUBDIR = :
 endif
 
+ifneq ($(filter 4.%,$(MAKE_VERSION)),)  # make-4
+ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
+  silent=1
+endif
+else   # make-3.8x
+ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
+  silent=1
+endif
+endif
+
 #
 # Define a callable command for descending to a new directory
 #
@@ -58,7 +68,7 @@ descend = \
 QUIET_SUBDIR0  = +$(MAKE) $(COMMAND_O) -C # space to separate -C and subdir
 QUIET_SUBDIR1  =
 
-ifneq ($(findstring $(MAKEFLAGS),s),s)
+ifneq ($(silent),1)
   ifneq ($(V),1)
QUIET_CC   = @echo '  CC   '$@;
QUIET_CC_FPIC  = @echo '  CC FPIC  '$@;




[PATCH 4.9 108/145] tools build: Add tools tree support for make -s

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Josh Poimboeuf 

commit e572d0887137acfc53f18175522964ec19d88175 upstream.

When doing a kernel build with 'make -s', everything is silenced except
the objtool build.  That's because the tools tree support for silent
builds is some combination of missing and broken.

Three changes are needed to fix it:

- Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the
  tools Makefiles can see it.

- tools/scripts/Makefile.include: fix the tools Makefiles' ability to
  recognize '-s'.  The MAKE_VERSION and MAKEFLAGS checks are copied from
  the top-level Makefile.  This silences the "DESCEND objtool" message.

- tools/build/Makefile.build: add support to the tools Build files for
  recognizing '-s'.  Again the MAKE_VERSION and MAKEFLAGS checks are
  copied from the top-level Makefile.  This silences all the object
  compile/link messages.

Reported-and-Tested-by: Peter Zijlstra 
Signed-off-by: Josh Poimboeuf 
Cc: Jiri Olsa 
Cc: Michal Marek 
Link: 
http://lkml.kernel.org/r/e8967562ef640c3ae9a76da4ae0f4e47df737c34.1484799200.git.jpoim...@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman 

---
 Makefile   |6 --
 tools/build/Makefile.build |   10 ++
 tools/scripts/Makefile.include |   12 +++-
 3 files changed, 25 insertions(+), 3 deletions(-)

--- a/Makefile
+++ b/Makefile
@@ -87,10 +87,12 @@ endif
 ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4
 ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
   quiet=silent_
+  tools_silent=s
 endif
 else   # make-3.8x
 ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
   quiet=silent_
+  tools_silent=-s
 endif
 endif
 
@@ -1614,11 +1616,11 @@ image_name:
 # Clear a bunch of variables before executing the submake
 tools/: FORCE
$(Q)mkdir -p $(objtree)/tools
-   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" 
O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/
+   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% 
-j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C 
$(src)/tools/
 
 tools/%: FORCE
$(Q)mkdir -p $(objtree)/tools
-   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" 
O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/ $*
+   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% 
-j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C 
$(src)/tools/ $*
 
 # Single targets
 # ---
--- a/tools/build/Makefile.build
+++ b/tools/build/Makefile.build
@@ -19,6 +19,16 @@ else
   Q=@
 endif
 
+ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4
+ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
+  quiet=silent_
+endif
+else   # make-3.8x
+ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
+  quiet=silent_
+endif
+endif
+
 build-dir := $(srctree)/tools/build
 
 # Define $(fixdep) for dep-cmd function
--- a/tools/scripts/Makefile.include
+++ b/tools/scripts/Makefile.include
@@ -46,6 +46,16 @@ else
 NO_SUBDIR = :
 endif
 
+ifneq ($(filter 4.%,$(MAKE_VERSION)),)  # make-4
+ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
+  silent=1
+endif
+else   # make-3.8x
+ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
+  silent=1
+endif
+endif
+
 #
 # Define a callable command for descending to a new directory
 #
@@ -58,7 +68,7 @@ descend = \
 QUIET_SUBDIR0  = +$(MAKE) $(COMMAND_O) -C # space to separate -C and subdir
 QUIET_SUBDIR1  =
 
-ifneq ($(findstring $(MAKEFLAGS),s),s)
+ifneq ($(silent),1)
   ifneq ($(V),1)
QUIET_CC   = @echo '  CC   '$@;
QUIET_CC_FPIC  = @echo '  CC FPIC  '$@;




[PATCH 4.9 109/145] x86/build: Silence the build with "make -s"

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit d460131dd50599e0e9405d5f4ae02c27d529a44a upstream.

Every kernel build on x86 will result in some output:

  Setup is 13084 bytes (padded to 13312 bytes).
  System is 4833 kB
  CRC 6d35fa35
  Kernel: arch/x86/boot/bzImage is ready  (#2)

This shuts it up, so that 'make -s' is truely silent as long as
everything works. Building without '-s' should produce unchanged
output.

Signed-off-by: Arnd Bergmann 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20170719125310.2487451-6-a...@arndb.de
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/boot/Makefile |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -73,12 +73,13 @@ UBSAN_SANITIZE := n
 $(obj)/bzImage: asflags-y  := $(SVGA_MODE)
 
 quiet_cmd_image = BUILD   $@
+silent_redirect_image = >/dev/null
 cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin \
-  $(obj)/zoffset.h $@
+  $(obj)/zoffset.h $@ $($(quiet)redirect_image)
 
 $(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin $(obj)/tools/build FORCE
$(call if_changed,image)
-   @echo 'Kernel: $@ is ready' ' (#'`cat .version`')'
+   @$(kecho) 'Kernel: $@ is ready' ' (#'`cat .version`')'
 
 OBJCOPYFLAGS_vmlinux.bin := -O binary -R .note -R .comment -S
 $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE




[PATCH 4.9 109/145] x86/build: Silence the build with "make -s"

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit d460131dd50599e0e9405d5f4ae02c27d529a44a upstream.

Every kernel build on x86 will result in some output:

  Setup is 13084 bytes (padded to 13312 bytes).
  System is 4833 kB
  CRC 6d35fa35
  Kernel: arch/x86/boot/bzImage is ready  (#2)

This shuts it up, so that 'make -s' is truely silent as long as
everything works. Building without '-s' should produce unchanged
output.

Signed-off-by: Arnd Bergmann 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20170719125310.2487451-6-a...@arndb.de
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/boot/Makefile |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -73,12 +73,13 @@ UBSAN_SANITIZE := n
 $(obj)/bzImage: asflags-y  := $(SVGA_MODE)
 
 quiet_cmd_image = BUILD   $@
+silent_redirect_image = >/dev/null
 cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin \
-  $(obj)/zoffset.h $@
+  $(obj)/zoffset.h $@ $($(quiet)redirect_image)
 
 $(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin $(obj)/tools/build FORCE
$(call if_changed,image)
-   @echo 'Kernel: $@ is ready' ' (#'`cat .version`')'
+   @$(kecho) 'Kernel: $@ is ready' ' (#'`cat .version`')'
 
 OBJCOPYFLAGS_vmlinux.bin := -O binary -R .note -R .comment -S
 $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE




[PATCH 4.9 085/145] xen: XEN_ACPI_PROCESSOR is Dom0-only

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Beulich 


[ Upstream commit c4f9d9cb2c29ff04c6b4bb09b72802d8aedfc7cb ]

Add a respective dependency.

Signed-off-by: Jan Beulich 
Reviewed-by: Juergen Gross 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/xen/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -246,7 +246,7 @@ config XEN_ACPI_HOTPLUG_CPU
 
 config XEN_ACPI_PROCESSOR
tristate "Xen ACPI processor"
-   depends on XEN && X86 && ACPI_PROCESSOR && CPU_FREQ
+   depends on XEN && XEN_DOM0 && X86 && ACPI_PROCESSOR && CPU_FREQ
default m
help
   This ACPI processor uploads Power Management information to the Xen




[PATCH 4.9 085/145] xen: XEN_ACPI_PROCESSOR is Dom0-only

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Beulich 


[ Upstream commit c4f9d9cb2c29ff04c6b4bb09b72802d8aedfc7cb ]

Add a respective dependency.

Signed-off-by: Jan Beulich 
Reviewed-by: Juergen Gross 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/xen/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -246,7 +246,7 @@ config XEN_ACPI_HOTPLUG_CPU
 
 config XEN_ACPI_PROCESSOR
tristate "Xen ACPI processor"
-   depends on XEN && X86 && ACPI_PROCESSOR && CPU_FREQ
+   depends on XEN && XEN_DOM0 && X86 && ACPI_PROCESSOR && CPU_FREQ
default m
help
   This ACPI processor uploads Power Management information to the Xen




Re: [PATCH] efivarfs: Limit the rate for non-root to read files

2018-02-23 Thread Peter Jones
On Thu, Feb 22, 2018 at 06:11:14AM +, Luck, Tony wrote:
>> On Feb 21, 2018, at 21:52, Linus Torvalds wrote:
>> 
>> Does the error return actually break real users? Not "I can do did
>> things and it acts differently" things, but actual users...
> 
> Probably not. Peter Jones said that efibootmgr might access up to 20
> files. Assuming it is sanely reading in big chunks, it won’t hit the
> rate limit that I set at 100.

Typically each read looks like:

openat(AT_FDCWD, 
"/sys/firmware/efi/efivars/Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c", 
O_RDONLY) = 3
read(3, "\7\0\0\0", 4)  = 4
read(3, "\1\0\0\0b\0t\0e\0s\0t\0\0\0\4\1*\0\1\0\0\0\0\10\0\0\0\0\0\0"..., 4096) 
= 114
read(3, "", 3982)   = 0
close(3)= 0

For each multiple of 4k, you'll see one more read() call.  (It's two
reads because libefivar's efi_get_variable() returns the attributes
separately from the data, which goes in an allocation the caller is
responsible for freeing, so doing it as one read means it would
introduce an extra copy.)  Looking at that code path, if it *does* get
tripped up by EAGAIN, it should handle it fine, though maybe I should
add a short randomized delay (or just sched_yield()) in that case.

I don't think the 3rd read there to detect EOF hits the efivarfs code,
so that's 2 reads per variable until you go over 4k, which most never
do.

That pattern is true of everything that uses libefivar to do its EFI
variable manipulation.  On my moderately typical laptop with 2 boot
variables set, it looks something like:

trillian:~$ strace -o efibootmgr.strace efibootmgr -v 
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,
Boot* Fedora
HD(1,GPT,2cf5261b-7b98-48c0-ae54-463dbd23e65b,0x800,0x64000)/File(\EFI\fedora\shimx64.efi)
Boot0001* test  
HD(1,GPT,2cf5261b-7b98-48c0-ae54-463dbd23e65b,0x800,0x64000)/File(\EFI\fedora\shimx64.efi)
trillian:~$ grep '^\(open\|read\)' efibootmgr.strace | grep -A100 sys/firmware  
| grep -c ^read
15

Which, if I'm write about VFS eating that last read, means 10 calls.
Many machines have some default boot variables; my desktop at home has 5
completely useless variables the firmware sets.  So there it winds up
being 27 calls to read(2), and thus 18 calls to count towards our limit.

Your limit at 100 looks sufficiently large to me.

-- 
  Peter


Re: [PATCH] efivarfs: Limit the rate for non-root to read files

2018-02-23 Thread Peter Jones
On Thu, Feb 22, 2018 at 06:11:14AM +, Luck, Tony wrote:
>> On Feb 21, 2018, at 21:52, Linus Torvalds wrote:
>> 
>> Does the error return actually break real users? Not "I can do did
>> things and it acts differently" things, but actual users...
> 
> Probably not. Peter Jones said that efibootmgr might access up to 20
> files. Assuming it is sanely reading in big chunks, it won’t hit the
> rate limit that I set at 100.

Typically each read looks like:

openat(AT_FDCWD, 
"/sys/firmware/efi/efivars/Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c", 
O_RDONLY) = 3
read(3, "\7\0\0\0", 4)  = 4
read(3, "\1\0\0\0b\0t\0e\0s\0t\0\0\0\4\1*\0\1\0\0\0\0\10\0\0\0\0\0\0"..., 4096) 
= 114
read(3, "", 3982)   = 0
close(3)= 0

For each multiple of 4k, you'll see one more read() call.  (It's two
reads because libefivar's efi_get_variable() returns the attributes
separately from the data, which goes in an allocation the caller is
responsible for freeing, so doing it as one read means it would
introduce an extra copy.)  Looking at that code path, if it *does* get
tripped up by EAGAIN, it should handle it fine, though maybe I should
add a short randomized delay (or just sched_yield()) in that case.

I don't think the 3rd read there to detect EOF hits the efivarfs code,
so that's 2 reads per variable until you go over 4k, which most never
do.

That pattern is true of everything that uses libefivar to do its EFI
variable manipulation.  On my moderately typical laptop with 2 boot
variables set, it looks something like:

trillian:~$ strace -o efibootmgr.strace efibootmgr -v 
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,
Boot* Fedora
HD(1,GPT,2cf5261b-7b98-48c0-ae54-463dbd23e65b,0x800,0x64000)/File(\EFI\fedora\shimx64.efi)
Boot0001* test  
HD(1,GPT,2cf5261b-7b98-48c0-ae54-463dbd23e65b,0x800,0x64000)/File(\EFI\fedora\shimx64.efi)
trillian:~$ grep '^\(open\|read\)' efibootmgr.strace | grep -A100 sys/firmware  
| grep -c ^read
15

Which, if I'm write about VFS eating that last read, means 10 calls.
Many machines have some default boot variables; my desktop at home has 5
completely useless variables the firmware sets.  So there it winds up
being 27 calls to read(2), and thus 18 calls to count towards our limit.

Your limit at 100 looks sufficiently large to me.

-- 
  Peter


[PATCH 4.9 112/145] dmaengine: zx: fix build warning

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Jun Nie 

commit 067fdeb2f391bfa071f741a2b3eb74b8ff3785cd upstream.

Fix build warning that related to PAGE_SIZE. The maximum DMA
length has nothing to do with PAGE_SIZE, just use a fix number
for the definition.

drivers/dma/zx_dma.c: In function 'zx_dma_prep_memcpy':
drivers/dma/zx_dma.c:523:8: warning: division by zero [-Wdiv-by-zero]
drivers/dma/zx_dma.c: In function 'zx_dma_prep_slave_sg':
drivers/dma/zx_dma.c:567:11: warning: division by zero [-Wdiv-by-zero]

Signed-off-by: Jun Nie 
Tested-by: Shawn Guo 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/dma/zx296702_dma.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/dma/zx296702_dma.c
+++ b/drivers/dma/zx296702_dma.c
@@ -26,7 +26,7 @@
 
 #define DRIVER_NAME"zx-dma"
 #define DMA_ALIGN  4
-#define DMA_MAX_SIZE   (0x1 - PAGE_SIZE)
+#define DMA_MAX_SIZE   (0x1 - 512)
 #define LLI_BLOCK_SIZE (4 * PAGE_SIZE)
 
 #define REG_ZX_SRC_ADDR0x00




[PATCH 4.9 112/145] dmaengine: zx: fix build warning

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Jun Nie 

commit 067fdeb2f391bfa071f741a2b3eb74b8ff3785cd upstream.

Fix build warning that related to PAGE_SIZE. The maximum DMA
length has nothing to do with PAGE_SIZE, just use a fix number
for the definition.

drivers/dma/zx_dma.c: In function 'zx_dma_prep_memcpy':
drivers/dma/zx_dma.c:523:8: warning: division by zero [-Wdiv-by-zero]
drivers/dma/zx_dma.c: In function 'zx_dma_prep_slave_sg':
drivers/dma/zx_dma.c:567:11: warning: division by zero [-Wdiv-by-zero]

Signed-off-by: Jun Nie 
Tested-by: Shawn Guo 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/dma/zx296702_dma.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/dma/zx296702_dma.c
+++ b/drivers/dma/zx296702_dma.c
@@ -26,7 +26,7 @@
 
 #define DRIVER_NAME"zx-dma"
 #define DMA_ALIGN  4
-#define DMA_MAX_SIZE   (0x1 - PAGE_SIZE)
+#define DMA_MAX_SIZE   (0x1 - 512)
 #define LLI_BLOCK_SIZE (4 * PAGE_SIZE)
 
 #define REG_ZX_SRC_ADDR0x00




[PATCH 4.9 116/145] arm64: Kconfig: select COMPAT_BINFMT_ELF only when BINFMT_ELF is set

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Kefeng Wang 

commit 2e449048a25eb75d48dff12882b93f26d130a1c6 upstream.

Fix warning:
"(COMPAT) selects COMPAT_BINFMT_ELF which has unmet direct dependencies
(COMPAT && BINFMT_ELF)"

Signed-off-by: Kefeng Wang 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1007,7 +1007,7 @@ source "fs/Kconfig.binfmt"
 config COMPAT
bool "Kernel support for 32-bit EL0"
depends on ARM64_4K_PAGES || EXPERT
-   select COMPAT_BINFMT_ELF
+   select COMPAT_BINFMT_ELF if BINFMT_ELF
select HAVE_UID16
select OLD_SIGSUSPEND3
select COMPAT_OLD_SIGACTION




[PATCH 4.9 115/145] scsi: advansys: fix uninitialized data access

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit 44a5b977128c00654392b40f4c2ce72a619b upstream.

gcc-7.0.1 now warns about a previously unnoticed access of uninitialized
struct members:

drivers/scsi/advansys.c: In function 'AscMsgOutSDTR':
drivers/scsi/advansys.c:3860:26: error: '*((void *)_buf+5)' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
 ((ushort)s_buffer[i + 1] << 8) | s_buffer[i]);
  ^
drivers/scsi/advansys.c:3860:26: error: '*((void *)_buf+7)' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
drivers/scsi/advansys.c:3860:26: error: '*((void *)_buf+5)' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
drivers/scsi/advansys.c:3860:26: error: '*((void *)_buf+7)' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]

The code has existed in this exact form at least since v2.6.12, and the
warning seems correct. This uses named initializers to ensure we
initialize all members of the structure.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/advansys.c |   21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -6291,18 +6291,17 @@ static uchar AscGetSynPeriodIndex(ASC_DV
 static uchar
 AscMsgOutSDTR(ASC_DVC_VAR *asc_dvc, uchar sdtr_period, uchar sdtr_offset)
 {
-   EXT_MSG sdtr_buf;
-   uchar sdtr_period_index;
-   PortAddr iop_base;
-
-   iop_base = asc_dvc->iop_base;
-   sdtr_buf.msg_type = EXTENDED_MESSAGE;
-   sdtr_buf.msg_len = MS_SDTR_LEN;
-   sdtr_buf.msg_req = EXTENDED_SDTR;
-   sdtr_buf.xfer_period = sdtr_period;
+   PortAddr iop_base = asc_dvc->iop_base;
+   uchar sdtr_period_index = AscGetSynPeriodIndex(asc_dvc, sdtr_period);
+   EXT_MSG sdtr_buf = {
+   .msg_type = EXTENDED_MESSAGE,
+   .msg_len = MS_SDTR_LEN,
+   .msg_req = EXTENDED_SDTR,
+   .xfer_period = sdtr_period,
+   .req_ack_offset = sdtr_offset,
+   };
sdtr_offset &= ASC_SYN_MAX_OFFSET;
-   sdtr_buf.req_ack_offset = sdtr_offset;
-   sdtr_period_index = AscGetSynPeriodIndex(asc_dvc, sdtr_period);
+
if (sdtr_period_index <= asc_dvc->max_sdtr_index) {
AscMemWordCopyPtrToLram(iop_base, ASCV_MSGOUT_BEG,
(uchar *)_buf,




[PATCH 4.9 116/145] arm64: Kconfig: select COMPAT_BINFMT_ELF only when BINFMT_ELF is set

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Kefeng Wang 

commit 2e449048a25eb75d48dff12882b93f26d130a1c6 upstream.

Fix warning:
"(COMPAT) selects COMPAT_BINFMT_ELF which has unmet direct dependencies
(COMPAT && BINFMT_ELF)"

Signed-off-by: Kefeng Wang 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1007,7 +1007,7 @@ source "fs/Kconfig.binfmt"
 config COMPAT
bool "Kernel support for 32-bit EL0"
depends on ARM64_4K_PAGES || EXPERT
-   select COMPAT_BINFMT_ELF
+   select COMPAT_BINFMT_ELF if BINFMT_ELF
select HAVE_UID16
select OLD_SIGSUSPEND3
select COMPAT_OLD_SIGACTION




[PATCH 4.9 115/145] scsi: advansys: fix uninitialized data access

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit 44a5b977128c00654392b40f4c2ce72a619b upstream.

gcc-7.0.1 now warns about a previously unnoticed access of uninitialized
struct members:

drivers/scsi/advansys.c: In function 'AscMsgOutSDTR':
drivers/scsi/advansys.c:3860:26: error: '*((void *)_buf+5)' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
 ((ushort)s_buffer[i + 1] << 8) | s_buffer[i]);
  ^
drivers/scsi/advansys.c:3860:26: error: '*((void *)_buf+7)' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
drivers/scsi/advansys.c:3860:26: error: '*((void *)_buf+5)' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
drivers/scsi/advansys.c:3860:26: error: '*((void *)_buf+7)' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]

The code has existed in this exact form at least since v2.6.12, and the
warning seems correct. This uses named initializers to ensure we
initialize all members of the structure.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/advansys.c |   21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -6291,18 +6291,17 @@ static uchar AscGetSynPeriodIndex(ASC_DV
 static uchar
 AscMsgOutSDTR(ASC_DVC_VAR *asc_dvc, uchar sdtr_period, uchar sdtr_offset)
 {
-   EXT_MSG sdtr_buf;
-   uchar sdtr_period_index;
-   PortAddr iop_base;
-
-   iop_base = asc_dvc->iop_base;
-   sdtr_buf.msg_type = EXTENDED_MESSAGE;
-   sdtr_buf.msg_len = MS_SDTR_LEN;
-   sdtr_buf.msg_req = EXTENDED_SDTR;
-   sdtr_buf.xfer_period = sdtr_period;
+   PortAddr iop_base = asc_dvc->iop_base;
+   uchar sdtr_period_index = AscGetSynPeriodIndex(asc_dvc, sdtr_period);
+   EXT_MSG sdtr_buf = {
+   .msg_type = EXTENDED_MESSAGE,
+   .msg_len = MS_SDTR_LEN,
+   .msg_req = EXTENDED_SDTR,
+   .xfer_period = sdtr_period,
+   .req_ack_offset = sdtr_offset,
+   };
sdtr_offset &= ASC_SYN_MAX_OFFSET;
-   sdtr_buf.req_ack_offset = sdtr_offset;
-   sdtr_period_index = AscGetSynPeriodIndex(asc_dvc, sdtr_period);
+
if (sdtr_period_index <= asc_dvc->max_sdtr_index) {
AscMemWordCopyPtrToLram(iop_base, ASCV_MSGOUT_BEG,
(uchar *)_buf,




[PATCH 4.9 120/145] security/keys: BIG_KEY requires CONFIG_CRYPTO

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit 3cd18d1981731d5f74b8e437009124ac99905d14 upstream.

The recent rework introduced a possible randconfig build failure
when CONFIG_CRYPTO configured to only allow modules:

security/keys/big_key.o: In function `big_key_crypt':
big_key.c:(.text+0x29f): undefined reference to `crypto_aead_setkey'
security/keys/big_key.o: In function `big_key_init':
big_key.c:(.init.text+0x1a): undefined reference to `crypto_alloc_aead'
big_key.c:(.init.text+0x45): undefined reference to `crypto_aead_setauthsize'
big_key.c:(.init.text+0x77): undefined reference to `crypto_destroy_tfm'
crypto/gcm.o: In function `gcm_hash_crypt_remain_continue':
gcm.c:(.text+0x167): undefined reference to `crypto_ahash_finup'
crypto/gcm.o: In function `crypto_gcm_exit_tfm':
gcm.c:(.text+0x847): undefined reference to `crypto_destroy_tfm'

When we 'select CRYPTO' like the other users, we always get a
configuration that builds.

Fixes: 428490e38b2e ("security/keys: rewrite all of big_key crypto")
Signed-off-by: Arnd Bergmann 
Signed-off-by: David Howells 
Signed-off-by: Greg Kroah-Hartman 

---
 security/keys/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -45,6 +45,7 @@ config BIG_KEYS
bool "Large payload keys"
depends on KEYS
depends on TMPFS
+   select CRYPTO
select CRYPTO_AES
select CRYPTO_GCM
help




[PATCH 4.9 086/145] hippi: Fix a Fix a possible sleep-in-atomic bug in rr_close

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Jia-Ju Bai 


[ Upstream commit 6e266610eb6553cfb7e7eb5d11914bd01509c406 ]

The driver may sleep under a spinlock.
The function call path is:
rr_close (acquire the spinlock)
  free_irq --> may sleep

To fix it, free_irq is moved to the place without holding the spinlock.

This bug is found by my static analysis tool(DSAC) and checked by my code 
review.

Signed-off-by: Jia-Ju Bai 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/hippi/rrunner.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/hippi/rrunner.c
+++ b/drivers/net/hippi/rrunner.c
@@ -1381,8 +1381,8 @@ static int rr_close(struct net_device *d
rrpriv->info_dma);
rrpriv->info = NULL;
 
-   free_irq(pdev->irq, dev);
spin_unlock_irqrestore(>lock, flags);
+   free_irq(pdev->irq, dev);
 
return 0;
 }




[PATCH 4.9 117/145] ALSA: hda/ca0132 - fix possible NULL pointer use

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit 46a049dae771b95e77ac6c823330f4a60f600236 upstream.

gcc-7 caught what it considers a NULL pointer dereference:

sound/pci/hda/patch_ca0132.c: In function 'dspio_scp.constprop':
sound/pci/hda/patch_ca0132.c:1487:4: error: argument 1 null where non-null 
expected [-Werror=nonnull]

This is plausible from looking at the function, as we compare 'reply'
to NULL earlier in it. I have not tried to analyze if there are constraints
that make it impossible to hit the bug, but adding another NULL check in
the end kills the warning and makes the function more robust.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/pci/hda/patch_ca0132.c |3 +++
 1 file changed, 3 insertions(+)

--- a/sound/pci/hda/patch_ca0132.c
+++ b/sound/pci/hda/patch_ca0132.c
@@ -1482,6 +1482,9 @@ static int dspio_scp(struct hda_codec *c
} else if (ret_size != reply_data_size) {
codec_dbg(codec, "RetLen and HdrLen .NE.\n");
return -EINVAL;
+   } else if (!reply) {
+   codec_dbg(codec, "NULL reply\n");
+   return -EINVAL;
} else {
*reply_len = ret_size*sizeof(unsigned int);
memcpy(reply, scp_reply.data, *reply_len);




[PATCH 4.9 120/145] security/keys: BIG_KEY requires CONFIG_CRYPTO

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit 3cd18d1981731d5f74b8e437009124ac99905d14 upstream.

The recent rework introduced a possible randconfig build failure
when CONFIG_CRYPTO configured to only allow modules:

security/keys/big_key.o: In function `big_key_crypt':
big_key.c:(.text+0x29f): undefined reference to `crypto_aead_setkey'
security/keys/big_key.o: In function `big_key_init':
big_key.c:(.init.text+0x1a): undefined reference to `crypto_alloc_aead'
big_key.c:(.init.text+0x45): undefined reference to `crypto_aead_setauthsize'
big_key.c:(.init.text+0x77): undefined reference to `crypto_destroy_tfm'
crypto/gcm.o: In function `gcm_hash_crypt_remain_continue':
gcm.c:(.text+0x167): undefined reference to `crypto_ahash_finup'
crypto/gcm.o: In function `crypto_gcm_exit_tfm':
gcm.c:(.text+0x847): undefined reference to `crypto_destroy_tfm'

When we 'select CRYPTO' like the other users, we always get a
configuration that builds.

Fixes: 428490e38b2e ("security/keys: rewrite all of big_key crypto")
Signed-off-by: Arnd Bergmann 
Signed-off-by: David Howells 
Signed-off-by: Greg Kroah-Hartman 

---
 security/keys/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -45,6 +45,7 @@ config BIG_KEYS
bool "Large payload keys"
depends on KEYS
depends on TMPFS
+   select CRYPTO
select CRYPTO_AES
select CRYPTO_GCM
help




[PATCH 4.9 086/145] hippi: Fix a Fix a possible sleep-in-atomic bug in rr_close

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Jia-Ju Bai 


[ Upstream commit 6e266610eb6553cfb7e7eb5d11914bd01509c406 ]

The driver may sleep under a spinlock.
The function call path is:
rr_close (acquire the spinlock)
  free_irq --> may sleep

To fix it, free_irq is moved to the place without holding the spinlock.

This bug is found by my static analysis tool(DSAC) and checked by my code 
review.

Signed-off-by: Jia-Ju Bai 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/hippi/rrunner.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/hippi/rrunner.c
+++ b/drivers/net/hippi/rrunner.c
@@ -1381,8 +1381,8 @@ static int rr_close(struct net_device *d
rrpriv->info_dma);
rrpriv->info = NULL;
 
-   free_irq(pdev->irq, dev);
spin_unlock_irqrestore(>lock, flags);
+   free_irq(pdev->irq, dev);
 
return 0;
 }




[PATCH 4.9 117/145] ALSA: hda/ca0132 - fix possible NULL pointer use

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit 46a049dae771b95e77ac6c823330f4a60f600236 upstream.

gcc-7 caught what it considers a NULL pointer dereference:

sound/pci/hda/patch_ca0132.c: In function 'dspio_scp.constprop':
sound/pci/hda/patch_ca0132.c:1487:4: error: argument 1 null where non-null 
expected [-Werror=nonnull]

This is plausible from looking at the function, as we compare 'reply'
to NULL earlier in it. I have not tried to analyze if there are constraints
that make it impossible to hit the bug, but adding another NULL check in
the end kills the warning and makes the function more robust.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/pci/hda/patch_ca0132.c |3 +++
 1 file changed, 3 insertions(+)

--- a/sound/pci/hda/patch_ca0132.c
+++ b/sound/pci/hda/patch_ca0132.c
@@ -1482,6 +1482,9 @@ static int dspio_scp(struct hda_codec *c
} else if (ret_size != reply_data_size) {
codec_dbg(codec, "RetLen and HdrLen .NE.\n");
return -EINVAL;
+   } else if (!reply) {
+   codec_dbg(codec, "NULL reply\n");
+   return -EINVAL;
} else {
*reply_len = ret_size*sizeof(unsigned int);
memcpy(reply, scp_reply.data, *reply_len);




[PATCH 4.9 089/145] powerpc/64s: Improve RFI L1-D cache flush fallback

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--


From: Nicholas Piggin 

commit bdcb1aefc5b3f7d0f1dc8b02673602bca2ff7a4b upstream.

The fallback RFI flush is used when firmware does not provide a way
to flush the cache. It's a "displacement flush" that evicts useful
data by displacing it with an uninteresting buffer.

The flush has to take care to work with implementation specific cache
replacment policies, so the recipe has been in flux. The initial
slow but conservative approach is to touch all lines of a congruence
class, with dependencies between each load. It has since been
determined that a linear pattern of loads without dependencies is
sufficient, and is significantly faster.

Measuring the speed of a null syscall with RFI fallback flush enabled
gives the relative improvement:

P8 - 1.83x
P9 - 1.75x

The flush also becomes simpler and more adaptable to different cache
geometries.

Signed-off-by: Nicholas Piggin 
[mpe: Backport to 4.9]
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/powerpc/include/asm/paca.h  |3 -
 arch/powerpc/kernel/asm-offsets.c|3 -
 arch/powerpc/kernel/exceptions-64s.S |   76 ---
 arch/powerpc/kernel/setup_64.c   |   13 -
 4 files changed, 39 insertions(+), 56 deletions(-)

--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -212,8 +212,7 @@ struct paca_struct {
 */
u64 exrfi[13] __aligned(0x80);
void *rfi_flush_fallback_area;
-   u64 l1d_flush_congruence;
-   u64 l1d_flush_sets;
+   u64 l1d_flush_size;
 #endif
 };
 
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -242,8 +242,7 @@ int main(void)
DEFINE(PACA_IN_MCE, offsetof(struct paca_struct, in_mce));
DEFINE(PACA_RFI_FLUSH_FALLBACK_AREA, offsetof(struct paca_struct, 
rfi_flush_fallback_area));
DEFINE(PACA_EXRFI, offsetof(struct paca_struct, exrfi));
-   DEFINE(PACA_L1D_FLUSH_CONGRUENCE, offsetof(struct paca_struct, 
l1d_flush_congruence));
-   DEFINE(PACA_L1D_FLUSH_SETS, offsetof(struct paca_struct, 
l1d_flush_sets));
+   DEFINE(PACA_L1D_FLUSH_SIZE, offsetof(struct paca_struct, 
l1d_flush_size));
 #endif
DEFINE(PACAHWCPUID, offsetof(struct paca_struct, hw_cpu_id));
DEFINE(PACAKEXECSTATE, offsetof(struct paca_struct, kexec_state));
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1602,39 +1602,37 @@ rfi_flush_fallback:
std r9,PACA_EXRFI+EX_R9(r13)
std r10,PACA_EXRFI+EX_R10(r13)
std r11,PACA_EXRFI+EX_R11(r13)
-   std r12,PACA_EXRFI+EX_R12(r13)
-   std r8,PACA_EXRFI+EX_R13(r13)
mfctr   r9
ld  r10,PACA_RFI_FLUSH_FALLBACK_AREA(r13)
-   ld  r11,PACA_L1D_FLUSH_SETS(r13)
-   ld  r12,PACA_L1D_FLUSH_CONGRUENCE(r13)
-   /*
-* The load adresses are at staggered offsets within cachelines,
-* which suits some pipelines better (on others it should not
-* hurt).
-*/
-   addir12,r12,8
+   ld  r11,PACA_L1D_FLUSH_SIZE(r13)
+   srdir11,r11,(7 + 3) /* 128 byte lines, unrolled 8x */
mtctr   r11
DCBT_STOP_ALL_STREAM_IDS(r11) /* Stop prefetch streams */
 
/* order ld/st prior to dcbt stop all streams with flushing */
sync
-1: li  r8,0
-   .rept   8 /* 8-way set associative */
-   ldx r11,r10,r8
-   add r8,r8,r12
-   xor r11,r11,r11 // Ensure r11 is 0 even if fallback area is not
-   add r8,r8,r11   // Add 0, this creates a dependency on the ldx
-   .endr
-   addir10,r10,128 /* 128 byte cache line */
+
+   /*
+* The load adresses are at staggered offsets within cachelines,
+* which suits some pipelines better (on others it should not
+* hurt).
+*/
+1:
+   ld  r11,(0x80 + 8)*0(r10)
+   ld  r11,(0x80 + 8)*1(r10)
+   ld  r11,(0x80 + 8)*2(r10)
+   ld  r11,(0x80 + 8)*3(r10)
+   ld  r11,(0x80 + 8)*4(r10)
+   ld  r11,(0x80 + 8)*5(r10)
+   ld  r11,(0x80 + 8)*6(r10)
+   ld  r11,(0x80 + 8)*7(r10)
+   addir10,r10,0x80*8
bdnz1b
 
mtctr   r9
ld  r9,PACA_EXRFI+EX_R9(r13)
ld  r10,PACA_EXRFI+EX_R10(r13)
ld  r11,PACA_EXRFI+EX_R11(r13)
-   ld  r12,PACA_EXRFI+EX_R12(r13)
-   ld  r8,PACA_EXRFI+EX_R13(r13)
GET_SCRATCH0(r13);
rfid
 
@@ -1645,39 +1643,37 @@ hrfi_flush_fallback:
std r9,PACA_EXRFI+EX_R9(r13)
std r10,PACA_EXRFI+EX_R10(r13)
std r11,PACA_EXRFI+EX_R11(r13)
-   std r12,PACA_EXRFI+EX_R12(r13)
-   std r8,PACA_EXRFI+EX_R13(r13)
mfctr   r9
ld  

Re: [PATCH] fs: proc: use down_read_killable in proc_pid_cmdline_read()

2018-02-23 Thread Alexey Dobriyan
On Fri, Feb 23, 2018 at 11:42:34AM -0800, Yang Shi wrote:
> 
> 
> On 2/23/18 11:33 AM, Alexey Dobriyan wrote:
> > On Wed, Feb 21, 2018 at 03:13:10PM -0800, Yang Shi wrote:
> >
> > 2) access_remote_vm() et al will do the same ->mmap_sem, and
>  Yes, it does. But, __access_remote_vm() is called by access_process_vm()
>  too, which is used by much more places, i.e. ptrace, so I was not sure
>  if it is preferred to convert to killable version. So, I leave it 
>  untouched.
> >>> Yeah, but ->mmap_sem is taken 3 times per /proc/*/cmdline read
> >>> and your scalability tests should trigger next backtrace right away.
> >> Yes, however, I didn't run into it if mmap_sem is acquired earlier.
> >>
> >> How about defining a killable version, like
> >> __access_remote_vm_killable() which use down_read_killable(), then the
> >> killable version can be used by proc/*/cmdline? There might be other
> >> users in the future.
> > It would be a disaster as interfaces multiply.
> 
> Might be not that bad.

Maybe.

But you need to explain why there is no backtrace several lines later:

access_remote_vm
__access_remote_vm
down_read(>mmap_sem)


[PATCH 4.9 089/145] powerpc/64s: Improve RFI L1-D cache flush fallback

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--


From: Nicholas Piggin 

commit bdcb1aefc5b3f7d0f1dc8b02673602bca2ff7a4b upstream.

The fallback RFI flush is used when firmware does not provide a way
to flush the cache. It's a "displacement flush" that evicts useful
data by displacing it with an uninteresting buffer.

The flush has to take care to work with implementation specific cache
replacment policies, so the recipe has been in flux. The initial
slow but conservative approach is to touch all lines of a congruence
class, with dependencies between each load. It has since been
determined that a linear pattern of loads without dependencies is
sufficient, and is significantly faster.

Measuring the speed of a null syscall with RFI fallback flush enabled
gives the relative improvement:

P8 - 1.83x
P9 - 1.75x

The flush also becomes simpler and more adaptable to different cache
geometries.

Signed-off-by: Nicholas Piggin 
[mpe: Backport to 4.9]
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/powerpc/include/asm/paca.h  |3 -
 arch/powerpc/kernel/asm-offsets.c|3 -
 arch/powerpc/kernel/exceptions-64s.S |   76 ---
 arch/powerpc/kernel/setup_64.c   |   13 -
 4 files changed, 39 insertions(+), 56 deletions(-)

--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -212,8 +212,7 @@ struct paca_struct {
 */
u64 exrfi[13] __aligned(0x80);
void *rfi_flush_fallback_area;
-   u64 l1d_flush_congruence;
-   u64 l1d_flush_sets;
+   u64 l1d_flush_size;
 #endif
 };
 
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -242,8 +242,7 @@ int main(void)
DEFINE(PACA_IN_MCE, offsetof(struct paca_struct, in_mce));
DEFINE(PACA_RFI_FLUSH_FALLBACK_AREA, offsetof(struct paca_struct, 
rfi_flush_fallback_area));
DEFINE(PACA_EXRFI, offsetof(struct paca_struct, exrfi));
-   DEFINE(PACA_L1D_FLUSH_CONGRUENCE, offsetof(struct paca_struct, 
l1d_flush_congruence));
-   DEFINE(PACA_L1D_FLUSH_SETS, offsetof(struct paca_struct, 
l1d_flush_sets));
+   DEFINE(PACA_L1D_FLUSH_SIZE, offsetof(struct paca_struct, 
l1d_flush_size));
 #endif
DEFINE(PACAHWCPUID, offsetof(struct paca_struct, hw_cpu_id));
DEFINE(PACAKEXECSTATE, offsetof(struct paca_struct, kexec_state));
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1602,39 +1602,37 @@ rfi_flush_fallback:
std r9,PACA_EXRFI+EX_R9(r13)
std r10,PACA_EXRFI+EX_R10(r13)
std r11,PACA_EXRFI+EX_R11(r13)
-   std r12,PACA_EXRFI+EX_R12(r13)
-   std r8,PACA_EXRFI+EX_R13(r13)
mfctr   r9
ld  r10,PACA_RFI_FLUSH_FALLBACK_AREA(r13)
-   ld  r11,PACA_L1D_FLUSH_SETS(r13)
-   ld  r12,PACA_L1D_FLUSH_CONGRUENCE(r13)
-   /*
-* The load adresses are at staggered offsets within cachelines,
-* which suits some pipelines better (on others it should not
-* hurt).
-*/
-   addir12,r12,8
+   ld  r11,PACA_L1D_FLUSH_SIZE(r13)
+   srdir11,r11,(7 + 3) /* 128 byte lines, unrolled 8x */
mtctr   r11
DCBT_STOP_ALL_STREAM_IDS(r11) /* Stop prefetch streams */
 
/* order ld/st prior to dcbt stop all streams with flushing */
sync
-1: li  r8,0
-   .rept   8 /* 8-way set associative */
-   ldx r11,r10,r8
-   add r8,r8,r12
-   xor r11,r11,r11 // Ensure r11 is 0 even if fallback area is not
-   add r8,r8,r11   // Add 0, this creates a dependency on the ldx
-   .endr
-   addir10,r10,128 /* 128 byte cache line */
+
+   /*
+* The load adresses are at staggered offsets within cachelines,
+* which suits some pipelines better (on others it should not
+* hurt).
+*/
+1:
+   ld  r11,(0x80 + 8)*0(r10)
+   ld  r11,(0x80 + 8)*1(r10)
+   ld  r11,(0x80 + 8)*2(r10)
+   ld  r11,(0x80 + 8)*3(r10)
+   ld  r11,(0x80 + 8)*4(r10)
+   ld  r11,(0x80 + 8)*5(r10)
+   ld  r11,(0x80 + 8)*6(r10)
+   ld  r11,(0x80 + 8)*7(r10)
+   addir10,r10,0x80*8
bdnz1b
 
mtctr   r9
ld  r9,PACA_EXRFI+EX_R9(r13)
ld  r10,PACA_EXRFI+EX_R10(r13)
ld  r11,PACA_EXRFI+EX_R11(r13)
-   ld  r12,PACA_EXRFI+EX_R12(r13)
-   ld  r8,PACA_EXRFI+EX_R13(r13)
GET_SCRATCH0(r13);
rfid
 
@@ -1645,39 +1643,37 @@ hrfi_flush_fallback:
std r9,PACA_EXRFI+EX_R9(r13)
std r10,PACA_EXRFI+EX_R10(r13)
std r11,PACA_EXRFI+EX_R11(r13)
-   std r12,PACA_EXRFI+EX_R12(r13)
-   std r8,PACA_EXRFI+EX_R13(r13)
mfctr   r9
ld  r10,PACA_RFI_FLUSH_FALLBACK_AREA(r13)
-   ld  r11,PACA_L1D_FLUSH_SETS(r13)
-   ld  

Re: [PATCH] fs: proc: use down_read_killable in proc_pid_cmdline_read()

2018-02-23 Thread Alexey Dobriyan
On Fri, Feb 23, 2018 at 11:42:34AM -0800, Yang Shi wrote:
> 
> 
> On 2/23/18 11:33 AM, Alexey Dobriyan wrote:
> > On Wed, Feb 21, 2018 at 03:13:10PM -0800, Yang Shi wrote:
> >
> > 2) access_remote_vm() et al will do the same ->mmap_sem, and
>  Yes, it does. But, __access_remote_vm() is called by access_process_vm()
>  too, which is used by much more places, i.e. ptrace, so I was not sure
>  if it is preferred to convert to killable version. So, I leave it 
>  untouched.
> >>> Yeah, but ->mmap_sem is taken 3 times per /proc/*/cmdline read
> >>> and your scalability tests should trigger next backtrace right away.
> >> Yes, however, I didn't run into it if mmap_sem is acquired earlier.
> >>
> >> How about defining a killable version, like
> >> __access_remote_vm_killable() which use down_read_killable(), then the
> >> killable version can be used by proc/*/cmdline? There might be other
> >> users in the future.
> > It would be a disaster as interfaces multiply.
> 
> Might be not that bad.

Maybe.

But you need to explain why there is no backtrace several lines later:

access_remote_vm
__access_remote_vm
down_read(>mmap_sem)


[PATCH 4.9 087/145] powerpc/64s: Fix conversion of slb_miss_common to use RFI_TO_USER/KERNEL

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Michael Ellerman 

The back port of commit c7305645eb0c ("powerpc/64s: Convert
slb_miss_common to use RFI_TO_USER/KERNEL") missed a hunk needed to
restore cr6.

Fixes: 48cc95d4e4d6 ("powerpc/64s: Convert slb_miss_common to use 
RFI_TO_USER/KERNEL")
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/powerpc/kernel/exceptions-64s.S |1 +
 1 file changed, 1 insertion(+)

--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -680,6 +680,7 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_TYPE_R
 .machine   push
 .machine   "power4"
mtcrf   0x80,r9
+   mtcrf   0x02,r9 /* I/D indication is in cr6 */
mtcrf   0x01,r9 /* slb_allocate uses cr0 and cr7 */
 .machine   pop
 




[PATCH 4.9 087/145] powerpc/64s: Fix conversion of slb_miss_common to use RFI_TO_USER/KERNEL

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Michael Ellerman 

The back port of commit c7305645eb0c ("powerpc/64s: Convert
slb_miss_common to use RFI_TO_USER/KERNEL") missed a hunk needed to
restore cr6.

Fixes: 48cc95d4e4d6 ("powerpc/64s: Convert slb_miss_common to use 
RFI_TO_USER/KERNEL")
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/powerpc/kernel/exceptions-64s.S |1 +
 1 file changed, 1 insertion(+)

--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -680,6 +680,7 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_TYPE_R
 .machine   push
 .machine   "power4"
mtcrf   0x80,r9
+   mtcrf   0x02,r9 /* I/D indication is in cr6 */
mtcrf   0x01,r9 /* slb_allocate uses cr0 and cr7 */
 .machine   pop
 




[PATCH 4.9 088/145] powerpc/64s: Simple RFI macro conversions

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Nicholas Piggin 

commit 222f20f140623ef6033491d0103ee0875fe87d35 upstream.

This commit does simple conversions of rfi/rfid to the new macros that
include the expected destination context. By simple we mean cases
where there is a single well known destination context, and it's
simply a matter of substituting the instruction for the appropriate
macro.

Signed-off-by: Nicholas Piggin 
[mpe: Backport to 4.9, use RFI_TO_KERNEL in idle_book3s.S]
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/powerpc/include/asm/exception-64s.h |2 +-
 arch/powerpc/kernel/entry_64.S   |9 -
 arch/powerpc/kernel/exceptions-64s.S |   22 +++---
 arch/powerpc/kernel/idle_book3s.S|7 ---
 arch/powerpc/kvm/book3s_hv_rmhandlers.S  |7 +++
 arch/powerpc/kvm/book3s_rmhandlers.S |7 +--
 arch/powerpc/kvm/book3s_segment.S|4 ++--
 7 files changed, 30 insertions(+), 28 deletions(-)

--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -242,7 +242,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
mtspr   SPRN_##h##SRR0,r12; \
mfspr   r12,SPRN_##h##SRR1; /* and SRR1 */  \
mtspr   SPRN_##h##SRR1,r10; \
-   h##rfid;\
+   h##RFI_TO_KERNEL;   \
b   .   /* prevent speculative execution */
 #define EXCEPTION_PROLOG_PSERIES_1(label, h)   \
__EXCEPTION_PROLOG_PSERIES_1(label, h)
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -401,8 +401,7 @@ tabort_syscall:
mtmsrd  r10, 1
mtspr   SPRN_SRR0, r11
mtspr   SPRN_SRR1, r12
-
-   rfid
+   RFI_TO_USER
b   .   /* prevent speculative execution */
 #endif
 
@@ -1078,7 +1077,7 @@ _GLOBAL(enter_rtas)

mtspr   SPRN_SRR0,r5
mtspr   SPRN_SRR1,r6
-   rfid
+   RFI_TO_KERNEL
b   .   /* prevent speculative execution */
 
 rtas_return_loc:
@@ -1103,7 +1102,7 @@ rtas_return_loc:
 
mtspr   SPRN_SRR0,r3
mtspr   SPRN_SRR1,r4
-   rfid
+   RFI_TO_KERNEL
b   .   /* prevent speculative execution */
 
.align  3
@@ -1174,7 +1173,7 @@ _GLOBAL(enter_prom)
LOAD_REG_IMMEDIATE(r12, MSR_SF | MSR_ISF | MSR_LE)
andcr11,r11,r12
mtsrr1  r11
-   rfid
+   RFI_TO_KERNEL
 #endif /* CONFIG_PPC_BOOK3E */
 
 1: /* Return from OF */
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -244,7 +244,7 @@ BEGIN_FTR_SECTION
LOAD_HANDLER(r12, machine_check_handle_early)
 1: mtspr   SPRN_SRR0,r12
mtspr   SPRN_SRR1,r11
-   rfid
+   RFI_TO_KERNEL
b   .   /* prevent speculative execution */
 2:
/* Stack overflow. Stay on emergency stack and panic.
@@ -280,7 +280,7 @@ machine_check_pSeries_0:
mtspr   SPRN_SRR0,r12
mfspr   r12,SPRN_SRR1
mtspr   SPRN_SRR1,r10
-   rfid
+   RFI_TO_KERNEL
b   .   /* prevent speculative execution */
 
 TRAMP_KVM_SKIP(PACA_EXMC, 0x200)
@@ -446,7 +446,7 @@ EXC_COMMON_BEGIN(machine_check_handle_ea
li  r3,MSR_ME
andcr10,r10,r3  /* Turn off MSR_ME */
mtspr   SPRN_SRR1,r10
-   rfid
+   RFI_TO_KERNEL
b   .
 2:
/*
@@ -464,7 +464,7 @@ EXC_COMMON_BEGIN(machine_check_handle_ea
 */
bl  machine_check_queue_event
MACHINE_CHECK_HANDLER_WINDUP
-   rfid
+   RFI_TO_USER_OR_KERNEL
 9:
/* Deliver the machine check to host kernel in V mode. */
MACHINE_CHECK_HANDLER_WINDUP
@@ -706,7 +706,7 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_TYPE_R
mtspr   SPRN_SRR0,r10
ld  r10,PACAKMSR(r13)
mtspr   SPRN_SRR1,r10
-   rfid
+   RFI_TO_KERNEL
b   .
 
 EXC_COMMON_BEGIN(unrecov_slb)
@@ -893,7 +893,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE)
mtspr   SPRN_SRR0,r10 ; \
ld  r10,PACAKMSR(r13) ; \
mtspr   SPRN_SRR1,r10 ; \
-   rfid ;  \
+   RFI_TO_KERNEL ; \
b   . ; /* prevent speculative execution */
 
 #define SYSCALL_PSERIES_3  \
@@ -901,7 +901,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE)
 1: mfspr   r12,SPRN_SRR1 ; \
xorir12,r12,MSR_LE ;   

[PATCH 4.9 088/145] powerpc/64s: Simple RFI macro conversions

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Nicholas Piggin 

commit 222f20f140623ef6033491d0103ee0875fe87d35 upstream.

This commit does simple conversions of rfi/rfid to the new macros that
include the expected destination context. By simple we mean cases
where there is a single well known destination context, and it's
simply a matter of substituting the instruction for the appropriate
macro.

Signed-off-by: Nicholas Piggin 
[mpe: Backport to 4.9, use RFI_TO_KERNEL in idle_book3s.S]
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/powerpc/include/asm/exception-64s.h |2 +-
 arch/powerpc/kernel/entry_64.S   |9 -
 arch/powerpc/kernel/exceptions-64s.S |   22 +++---
 arch/powerpc/kernel/idle_book3s.S|7 ---
 arch/powerpc/kvm/book3s_hv_rmhandlers.S  |7 +++
 arch/powerpc/kvm/book3s_rmhandlers.S |7 +--
 arch/powerpc/kvm/book3s_segment.S|4 ++--
 7 files changed, 30 insertions(+), 28 deletions(-)

--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -242,7 +242,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
mtspr   SPRN_##h##SRR0,r12; \
mfspr   r12,SPRN_##h##SRR1; /* and SRR1 */  \
mtspr   SPRN_##h##SRR1,r10; \
-   h##rfid;\
+   h##RFI_TO_KERNEL;   \
b   .   /* prevent speculative execution */
 #define EXCEPTION_PROLOG_PSERIES_1(label, h)   \
__EXCEPTION_PROLOG_PSERIES_1(label, h)
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -401,8 +401,7 @@ tabort_syscall:
mtmsrd  r10, 1
mtspr   SPRN_SRR0, r11
mtspr   SPRN_SRR1, r12
-
-   rfid
+   RFI_TO_USER
b   .   /* prevent speculative execution */
 #endif
 
@@ -1078,7 +1077,7 @@ _GLOBAL(enter_rtas)

mtspr   SPRN_SRR0,r5
mtspr   SPRN_SRR1,r6
-   rfid
+   RFI_TO_KERNEL
b   .   /* prevent speculative execution */
 
 rtas_return_loc:
@@ -1103,7 +1102,7 @@ rtas_return_loc:
 
mtspr   SPRN_SRR0,r3
mtspr   SPRN_SRR1,r4
-   rfid
+   RFI_TO_KERNEL
b   .   /* prevent speculative execution */
 
.align  3
@@ -1174,7 +1173,7 @@ _GLOBAL(enter_prom)
LOAD_REG_IMMEDIATE(r12, MSR_SF | MSR_ISF | MSR_LE)
andcr11,r11,r12
mtsrr1  r11
-   rfid
+   RFI_TO_KERNEL
 #endif /* CONFIG_PPC_BOOK3E */
 
 1: /* Return from OF */
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -244,7 +244,7 @@ BEGIN_FTR_SECTION
LOAD_HANDLER(r12, machine_check_handle_early)
 1: mtspr   SPRN_SRR0,r12
mtspr   SPRN_SRR1,r11
-   rfid
+   RFI_TO_KERNEL
b   .   /* prevent speculative execution */
 2:
/* Stack overflow. Stay on emergency stack and panic.
@@ -280,7 +280,7 @@ machine_check_pSeries_0:
mtspr   SPRN_SRR0,r12
mfspr   r12,SPRN_SRR1
mtspr   SPRN_SRR1,r10
-   rfid
+   RFI_TO_KERNEL
b   .   /* prevent speculative execution */
 
 TRAMP_KVM_SKIP(PACA_EXMC, 0x200)
@@ -446,7 +446,7 @@ EXC_COMMON_BEGIN(machine_check_handle_ea
li  r3,MSR_ME
andcr10,r10,r3  /* Turn off MSR_ME */
mtspr   SPRN_SRR1,r10
-   rfid
+   RFI_TO_KERNEL
b   .
 2:
/*
@@ -464,7 +464,7 @@ EXC_COMMON_BEGIN(machine_check_handle_ea
 */
bl  machine_check_queue_event
MACHINE_CHECK_HANDLER_WINDUP
-   rfid
+   RFI_TO_USER_OR_KERNEL
 9:
/* Deliver the machine check to host kernel in V mode. */
MACHINE_CHECK_HANDLER_WINDUP
@@ -706,7 +706,7 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_TYPE_R
mtspr   SPRN_SRR0,r10
ld  r10,PACAKMSR(r13)
mtspr   SPRN_SRR1,r10
-   rfid
+   RFI_TO_KERNEL
b   .
 
 EXC_COMMON_BEGIN(unrecov_slb)
@@ -893,7 +893,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE)
mtspr   SPRN_SRR0,r10 ; \
ld  r10,PACAKMSR(r13) ; \
mtspr   SPRN_SRR1,r10 ; \
-   rfid ;  \
+   RFI_TO_KERNEL ; \
b   . ; /* prevent speculative execution */
 
 #define SYSCALL_PSERIES_3  \
@@ -901,7 +901,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE)
 1: mfspr   r12,SPRN_SRR1 ; \
xorir12,r12,MSR_LE ;\
mtspr   SPRN_SRR1,r12 ; \
- 

[PATCH 4.9 082/145] mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Dave Young 


[ Upstream commit 7f6f60a1ba52538c16f26930bfbcfe193d9d746a ]

earlyprintk=efi,keep does not work any more with a warning
in mm/early_ioremap.c: WARN_ON(system_state != SYSTEM_BOOTING):
Boot just hangs because of the earlyprintk within the earlyprintk
implementation code itself.

This is caused by a new introduced middle state in:

  69a78ff226fe ("init: Introduce SYSTEM_SCHEDULING state")

early_ioremap() is fine in both SYSTEM_BOOTING and SYSTEM_SCHEDULING
states, original condition should be updated accordingly.

Signed-off-by: Dave Young 
Acked-by: Thomas Gleixner 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: b...@suse.de
Cc: linux-...@vger.kernel.org
Cc: linux...@kvack.org
Link: http://lkml.kernel.org/r/20171209041610.ga3...@dhcp-128-65.nay.redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 mm/early_ioremap.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/early_ioremap.c
+++ b/mm/early_ioremap.c
@@ -103,7 +103,7 @@ __early_ioremap(resource_size_t phys_add
enum fixed_addresses idx;
int i, slot;
 
-   WARN_ON(system_state != SYSTEM_BOOTING);
+   WARN_ON(system_state >= SYSTEM_RUNNING);
 
slot = -1;
for (i = 0; i < FIX_BTMAPS_SLOTS; i++) {




[PATCH 4.9 090/145] crypto: talitos - fix Kernel Oops on hashing an empty file

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: LEROY Christophe 

commit 87a81dce53b1ea61acaeefa5191a0376a2d1d721 upstream.

Performing the hash of an empty file leads to a kernel Oops

[   44.504600] Unable to handle kernel paging request for data at address 
0x000c
[   44.512819] Faulting instruction address: 0xc02d2be8
[   44.524088] Oops: Kernel access of bad area, sig: 11 [#1]
[   44.529171] BE PREEMPT CMPC885
[   44.532232] CPU: 0 PID: 491 Comm: md5sum Not tainted 
4.15.0-rc8-00211-g3a968610b6ea #81
[   44.540814] NIP:  c02d2be8 LR: c02d2984 CTR: 
[   44.545812] REGS: c6813c90 TRAP: 0300   Not tainted  
(4.15.0-rc8-00211-g3a968610b6ea)
[   44.554223] MSR:  9032   CR: 48222822  XER: 2000
[   44.560855] DAR: 000c DSISR: c000
[   44.560855] GPR00: c02d28fc c6813d40 c6828000 c646fa40 0001 0001 
0001 
[   44.560855] GPR08: 004c  c000bfcc  28222822 100280d4 
 10020008
[   44.560855] GPR16:  0020   10024008  
c646f9f0 c6179a10
[   44.560855] GPR24:  0001 c62f0018 c6179a10  c6367a30 
c62f c646f9c0
[   44.598542] NIP [c02d2be8] ahash_process_req+0x448/0x700
[   44.603751] LR [c02d2984] ahash_process_req+0x1e4/0x700
[   44.608868] Call Trace:
[   44.611329] [c6813d40] [c02d28fc] ahash_process_req+0x15c/0x700 (unreliable)
[   44.618302] [c6813d90] [c02060c4] hash_recvmsg+0x11c/0x210
[   44.623716] [c6813db0] [c0331354] ___sys_recvmsg+0x98/0x138
[   44.629226] [c6813eb0] [c03332c0] __sys_recvmsg+0x40/0x84
[   44.634562] [c6813f10] [c03336c0] SyS_socketcall+0xb8/0x1d4
[   44.640073] [c6813f40] [c000d1ac] ret_from_syscall+0x0/0x38
[   44.645530] Instruction dump:
[   44.648465] 38c1 7f63db78 4e800421 7c791b78 54690ffe 0f09 80ff0190 
2f87
[   44.656122] 40befe50 2f990001 409e0210 813f01bc <8129000c> b39e003a 7d29c214 
913e003c

This patch fixes that Oops by checking if src is NULL.

Fixes: 6a1e8d14156d4 ("crypto: talitos - making mapping helpers more generic")
Cc: 
Signed-off-by: Christophe Leroy 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 


---
 drivers/crypto/talitos.c |5 +
 1 file changed, 5 insertions(+)

--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1124,6 +1124,11 @@ int talitos_sg_map(struct device *dev, s
struct talitos_private *priv = dev_get_drvdata(dev);
bool is_sec1 = has_ftr_sec1(priv);
 
+   if (!src) {
+   *ptr = zero_entry;
+   return 1;
+   }
+
to_talitos_ptr_len(ptr, len, is_sec1);
to_talitos_ptr_ext_set(ptr, 0, is_sec1);
 




[PATCH 4.9 082/145] mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Dave Young 


[ Upstream commit 7f6f60a1ba52538c16f26930bfbcfe193d9d746a ]

earlyprintk=efi,keep does not work any more with a warning
in mm/early_ioremap.c: WARN_ON(system_state != SYSTEM_BOOTING):
Boot just hangs because of the earlyprintk within the earlyprintk
implementation code itself.

This is caused by a new introduced middle state in:

  69a78ff226fe ("init: Introduce SYSTEM_SCHEDULING state")

early_ioremap() is fine in both SYSTEM_BOOTING and SYSTEM_SCHEDULING
states, original condition should be updated accordingly.

Signed-off-by: Dave Young 
Acked-by: Thomas Gleixner 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: b...@suse.de
Cc: linux-...@vger.kernel.org
Cc: linux...@kvack.org
Link: http://lkml.kernel.org/r/20171209041610.ga3...@dhcp-128-65.nay.redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 mm/early_ioremap.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/early_ioremap.c
+++ b/mm/early_ioremap.c
@@ -103,7 +103,7 @@ __early_ioremap(resource_size_t phys_add
enum fixed_addresses idx;
int i, slot;
 
-   WARN_ON(system_state != SYSTEM_BOOTING);
+   WARN_ON(system_state >= SYSTEM_RUNNING);
 
slot = -1;
for (i = 0; i < FIX_BTMAPS_SLOTS; i++) {




[PATCH 4.9 090/145] crypto: talitos - fix Kernel Oops on hashing an empty file

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: LEROY Christophe 

commit 87a81dce53b1ea61acaeefa5191a0376a2d1d721 upstream.

Performing the hash of an empty file leads to a kernel Oops

[   44.504600] Unable to handle kernel paging request for data at address 
0x000c
[   44.512819] Faulting instruction address: 0xc02d2be8
[   44.524088] Oops: Kernel access of bad area, sig: 11 [#1]
[   44.529171] BE PREEMPT CMPC885
[   44.532232] CPU: 0 PID: 491 Comm: md5sum Not tainted 
4.15.0-rc8-00211-g3a968610b6ea #81
[   44.540814] NIP:  c02d2be8 LR: c02d2984 CTR: 
[   44.545812] REGS: c6813c90 TRAP: 0300   Not tainted  
(4.15.0-rc8-00211-g3a968610b6ea)
[   44.554223] MSR:  9032   CR: 48222822  XER: 2000
[   44.560855] DAR: 000c DSISR: c000
[   44.560855] GPR00: c02d28fc c6813d40 c6828000 c646fa40 0001 0001 
0001 
[   44.560855] GPR08: 004c  c000bfcc  28222822 100280d4 
 10020008
[   44.560855] GPR16:  0020   10024008  
c646f9f0 c6179a10
[   44.560855] GPR24:  0001 c62f0018 c6179a10  c6367a30 
c62f c646f9c0
[   44.598542] NIP [c02d2be8] ahash_process_req+0x448/0x700
[   44.603751] LR [c02d2984] ahash_process_req+0x1e4/0x700
[   44.608868] Call Trace:
[   44.611329] [c6813d40] [c02d28fc] ahash_process_req+0x15c/0x700 (unreliable)
[   44.618302] [c6813d90] [c02060c4] hash_recvmsg+0x11c/0x210
[   44.623716] [c6813db0] [c0331354] ___sys_recvmsg+0x98/0x138
[   44.629226] [c6813eb0] [c03332c0] __sys_recvmsg+0x40/0x84
[   44.634562] [c6813f10] [c03336c0] SyS_socketcall+0xb8/0x1d4
[   44.640073] [c6813f40] [c000d1ac] ret_from_syscall+0x0/0x38
[   44.645530] Instruction dump:
[   44.648465] 38c1 7f63db78 4e800421 7c791b78 54690ffe 0f09 80ff0190 
2f87
[   44.656122] 40befe50 2f990001 409e0210 813f01bc <8129000c> b39e003a 7d29c214 
913e003c

This patch fixes that Oops by checking if src is NULL.

Fixes: 6a1e8d14156d4 ("crypto: talitos - making mapping helpers more generic")
Cc: 
Signed-off-by: Christophe Leroy 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 


---
 drivers/crypto/talitos.c |5 +
 1 file changed, 5 insertions(+)

--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1124,6 +1124,11 @@ int talitos_sg_map(struct device *dev, s
struct talitos_private *priv = dev_get_drvdata(dev);
bool is_sec1 = has_ftr_sec1(priv);
 
+   if (!src) {
+   *ptr = zero_entry;
+   return 1;
+   }
+
to_talitos_ptr_len(ptr, len, is_sec1);
to_talitos_ptr_ext_set(ptr, 0, is_sec1);
 




[PATCH 4.9 134/145] drm/i915: hide unused intel_panel_set_backlight function

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit fd94d53e55bd487368dfee9f1af24da78b2bb582 upstream.

Building i915 without backlight support results in a harmless warning
for intel_panel_set_backlight:

drivers/gpu/drm/i915/intel_panel.c:653:13: error: 'intel_panel_set_backlight' 
defined but not used [-Werror=unused-function]

This moves it into the CONFIG_BACKLIGHT_CLASS_DEVICE section that
its caller is in.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20171127151239.1813673-2-a...@arndb.de
[arnd: manually rebased to 4.9]
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/i915/intel_panel.c |   86 ++---
 1 file changed, 43 insertions(+), 43 deletions(-)

--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -544,25 +544,6 @@ static u32 pwm_get_backlight(struct inte
return DIV_ROUND_UP(duty_ns * 100, CRC_PMIC_PWM_PERIOD_NS);
 }
 
-static u32 intel_panel_get_backlight(struct intel_connector *connector)
-{
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-   struct intel_panel *panel = >panel;
-   u32 val = 0;
-
-   mutex_lock(_priv->backlight_lock);
-
-   if (panel->backlight.enabled) {
-   val = panel->backlight.get(connector);
-   val = intel_panel_compute_brightness(connector, val);
-   }
-
-   mutex_unlock(_priv->backlight_lock);
-
-   DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
-   return val;
-}
-
 static void lpt_set_backlight(struct intel_connector *connector, u32 level)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -646,30 +627,6 @@ intel_panel_actually_set_backlight(struc
panel->backlight.set(connector, level);
 }
 
-/* set backlight brightness to level in range [0..max], scaling wrt hw min */
-static void intel_panel_set_backlight(struct intel_connector *connector,
- u32 user_level, u32 user_max)
-{
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-   struct intel_panel *panel = >panel;
-   u32 hw_level;
-
-   if (!panel->backlight.present)
-   return;
-
-   mutex_lock(_priv->backlight_lock);
-
-   WARN_ON(panel->backlight.max == 0);
-
-   hw_level = scale_user_to_hw(connector, user_level, user_max);
-   panel->backlight.level = hw_level;
-
-   if (panel->backlight.enabled)
-   intel_panel_actually_set_backlight(connector, hw_level);
-
-   mutex_unlock(_priv->backlight_lock);
-}
-
 /* set backlight brightness to level in range [0..max], assuming hw min is
  * respected.
  */
@@ -1122,6 +1079,49 @@ void intel_panel_enable_backlight(struct
 }
 
 #if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
+static u32 intel_panel_get_backlight(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
+   u32 val = 0;
+
+   mutex_lock(_priv->backlight_lock);
+
+   if (panel->backlight.enabled) {
+   val = panel->backlight.get(connector);
+   val = intel_panel_compute_brightness(connector, val);
+   }
+
+   mutex_unlock(_priv->backlight_lock);
+
+   DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
+   return val;
+}
+
+/* set backlight brightness to level in range [0..max], scaling wrt hw min */
+static void intel_panel_set_backlight(struct intel_connector *connector,
+ u32 user_level, u32 user_max)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
+   u32 hw_level;
+
+   if (!panel->backlight.present)
+   return;
+
+   mutex_lock(_priv->backlight_lock);
+
+   WARN_ON(panel->backlight.max == 0);
+
+   hw_level = scale_user_to_hw(connector, user_level, user_max);
+   panel->backlight.level = hw_level;
+
+   if (panel->backlight.enabled)
+   intel_panel_actually_set_backlight(connector, hw_level);
+
+   mutex_unlock(_priv->backlight_lock);
+}
+
 static int intel_backlight_device_update_status(struct backlight_device *bd)
 {
struct intel_connector *connector = bl_get_data(bd);




[PATCH 4.9 134/145] drm/i915: hide unused intel_panel_set_backlight function

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit fd94d53e55bd487368dfee9f1af24da78b2bb582 upstream.

Building i915 without backlight support results in a harmless warning
for intel_panel_set_backlight:

drivers/gpu/drm/i915/intel_panel.c:653:13: error: 'intel_panel_set_backlight' 
defined but not used [-Werror=unused-function]

This moves it into the CONFIG_BACKLIGHT_CLASS_DEVICE section that
its caller is in.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20171127151239.1813673-2-a...@arndb.de
[arnd: manually rebased to 4.9]
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/i915/intel_panel.c |   86 ++---
 1 file changed, 43 insertions(+), 43 deletions(-)

--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -544,25 +544,6 @@ static u32 pwm_get_backlight(struct inte
return DIV_ROUND_UP(duty_ns * 100, CRC_PMIC_PWM_PERIOD_NS);
 }
 
-static u32 intel_panel_get_backlight(struct intel_connector *connector)
-{
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-   struct intel_panel *panel = >panel;
-   u32 val = 0;
-
-   mutex_lock(_priv->backlight_lock);
-
-   if (panel->backlight.enabled) {
-   val = panel->backlight.get(connector);
-   val = intel_panel_compute_brightness(connector, val);
-   }
-
-   mutex_unlock(_priv->backlight_lock);
-
-   DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
-   return val;
-}
-
 static void lpt_set_backlight(struct intel_connector *connector, u32 level)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -646,30 +627,6 @@ intel_panel_actually_set_backlight(struc
panel->backlight.set(connector, level);
 }
 
-/* set backlight brightness to level in range [0..max], scaling wrt hw min */
-static void intel_panel_set_backlight(struct intel_connector *connector,
- u32 user_level, u32 user_max)
-{
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-   struct intel_panel *panel = >panel;
-   u32 hw_level;
-
-   if (!panel->backlight.present)
-   return;
-
-   mutex_lock(_priv->backlight_lock);
-
-   WARN_ON(panel->backlight.max == 0);
-
-   hw_level = scale_user_to_hw(connector, user_level, user_max);
-   panel->backlight.level = hw_level;
-
-   if (panel->backlight.enabled)
-   intel_panel_actually_set_backlight(connector, hw_level);
-
-   mutex_unlock(_priv->backlight_lock);
-}
-
 /* set backlight brightness to level in range [0..max], assuming hw min is
  * respected.
  */
@@ -1122,6 +1079,49 @@ void intel_panel_enable_backlight(struct
 }
 
 #if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
+static u32 intel_panel_get_backlight(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
+   u32 val = 0;
+
+   mutex_lock(_priv->backlight_lock);
+
+   if (panel->backlight.enabled) {
+   val = panel->backlight.get(connector);
+   val = intel_panel_compute_brightness(connector, val);
+   }
+
+   mutex_unlock(_priv->backlight_lock);
+
+   DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
+   return val;
+}
+
+/* set backlight brightness to level in range [0..max], scaling wrt hw min */
+static void intel_panel_set_backlight(struct intel_connector *connector,
+ u32 user_level, u32 user_max)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
+   u32 hw_level;
+
+   if (!panel->backlight.present)
+   return;
+
+   mutex_lock(_priv->backlight_lock);
+
+   WARN_ON(panel->backlight.max == 0);
+
+   hw_level = scale_user_to_hw(connector, user_level, user_max);
+   panel->backlight.level = hw_level;
+
+   if (panel->backlight.enabled)
+   intel_panel_actually_set_backlight(connector, hw_level);
+
+   mutex_unlock(_priv->backlight_lock);
+}
+
 static int intel_backlight_device_update_status(struct backlight_device *bd)
 {
struct intel_connector *connector = bl_get_data(bd);




[PATCH 4.9 133/145] kasan: rework Kconfig settings

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit e7c52b84fb18f08ce49b6067ae6285aca79084a8 upstream.

We get a lot of very large stack frames using gcc-7.0.1 with the default
-fsanitize-address-use-after-scope --param asan-stack=1 options, which can
easily cause an overflow of the kernel stack, e.g.

  drivers/gpu/drm/i915/gvt/handlers.c:2434:1: warning: the frame size of 46176 
bytes is larger than 3072 bytes
  drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame 
size of 23632 bytes is larger than 3072 bytes
  lib/atomic64_test.c:250:1: warning: the frame size of 11200 bytes is larger 
than 3072 bytes
  drivers/gpu/drm/i915/gvt/handlers.c:2621:1: warning: the frame size of 9208 
bytes is larger than 3072 bytes
  drivers/media/dvb-frontends/stv090x.c:3431:1: warning: the frame size of 6816 
bytes is larger than 3072 bytes
  fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger 
than 3072 bytes

To reduce this risk, -fsanitize-address-use-after-scope is now split out
into a separate CONFIG_KASAN_EXTRA Kconfig option, leading to stack
frames that are smaller than 2 kilobytes most of the time on x86_64.  An
earlier version of this patch also prevented combining KASAN_EXTRA with
KASAN_INLINE, but that is no longer necessary with gcc-7.0.1.

All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y
and CONFIG_KASAN_EXTRA=n have been merged by maintainers now, so we can
bring back that default now.  KASAN_EXTRA=y still causes lots of
warnings but now defaults to !COMPILE_TEST to disable it in
allmodconfig, and it remains disabled in all other defconfigs since it
is a new option.  I arbitrarily raise the warning limit for KASAN_EXTRA
to 3072 to reduce the noise, but an allmodconfig kernel still has around
50 warnings on gcc-7.

I experimented a bit more with smaller stack frames and have another
follow-up series that reduces the warning limit for 64-bit architectures
to 1280 bytes (without CONFIG_KASAN).

With earlier versions of this patch series, I also had patches to address
the warnings we get with KASAN and/or KASAN_EXTRA, using a
"noinline_if_stackbloat" annotation.

That annotation now got replaced with a gcc-8 bugfix (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715) and a workaround for
older compilers, which means that KASAN_EXTRA is now just as bad as
before and will lead to an instant stack overflow in a few extreme
cases.

This reverts parts of commit 3f181b4d8652 ("lib/Kconfig.debug: disable
-Wframe-larger-than warnings with KASAN=y").  Two patches in linux-next
should be merged first to avoid introducing warnings in an allmodconfig
build:
  3cd890dbe2a4 ("media: dvb-frontends: fix i2c access helpers for KASAN")
  16c3ada89cff ("media: r820t: fix r820t_write_reg for KASAN")

Do we really need to backport this?

I think we do: without this patch, enabling KASAN will lead to
unavoidable kernel stack overflow in certain device drivers when built
with gcc-7 or higher on linux-4.10+ or any version that contains a
backport of commit c5caf21ab0cf8.  Most people are probably still on
older compilers, but it will get worse over time as they upgrade their
distros.

The warnings we get on kernels older than this should all be for code
that uses dangerously large stack frames, though most of them do not
cause an actual stack overflow by themselves.The asan-stack option was
added in linux-4.0, and commit 3f181b4d8652 ("lib/Kconfig.debug:
disable -Wframe-larger-than warnings with KASAN=y") effectively turned
off the warning for allmodconfig kernels, so I would like to see this
fix backported to any kernels later than 4.0.

I have done dozens of fixes for individual functions with stack frames
larger than 2048 bytes with asan-stack, and I plan to make sure that
all those fixes make it into the stable kernels as well (most are
already there).

Part of the complication here is that asan-stack (from 4.0) was
originally assumed to always require much larger stacks, but that
turned out to be a combination of multiple gcc bugs that we have now
worked around and fixed, but sanitize-address-use-after-scope (from
v4.10) has a much higher inherent stack usage and also suffers from at
least three other problems that we have analyzed but not yet fixed
upstream, each of them makes the stack usage more severe than it should
be.

Link: http://lkml.kernel.org/r/20171221134744.2295529-1-a...@arndb.de
Signed-off-by: Arnd Bergmann 
Acked-by: Andrey Ryabinin 
Cc: Mauro Carvalho Chehab 
Cc: Andrey Ryabinin 
Cc: Alexander Potapenko 
Cc: Dmitry Vyukov 
Cc: Andrey Konovalov 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[arnd: rebase to v4.9; 

[PATCH 4.9 133/145] kasan: rework Kconfig settings

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit e7c52b84fb18f08ce49b6067ae6285aca79084a8 upstream.

We get a lot of very large stack frames using gcc-7.0.1 with the default
-fsanitize-address-use-after-scope --param asan-stack=1 options, which can
easily cause an overflow of the kernel stack, e.g.

  drivers/gpu/drm/i915/gvt/handlers.c:2434:1: warning: the frame size of 46176 
bytes is larger than 3072 bytes
  drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame 
size of 23632 bytes is larger than 3072 bytes
  lib/atomic64_test.c:250:1: warning: the frame size of 11200 bytes is larger 
than 3072 bytes
  drivers/gpu/drm/i915/gvt/handlers.c:2621:1: warning: the frame size of 9208 
bytes is larger than 3072 bytes
  drivers/media/dvb-frontends/stv090x.c:3431:1: warning: the frame size of 6816 
bytes is larger than 3072 bytes
  fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger 
than 3072 bytes

To reduce this risk, -fsanitize-address-use-after-scope is now split out
into a separate CONFIG_KASAN_EXTRA Kconfig option, leading to stack
frames that are smaller than 2 kilobytes most of the time on x86_64.  An
earlier version of this patch also prevented combining KASAN_EXTRA with
KASAN_INLINE, but that is no longer necessary with gcc-7.0.1.

All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y
and CONFIG_KASAN_EXTRA=n have been merged by maintainers now, so we can
bring back that default now.  KASAN_EXTRA=y still causes lots of
warnings but now defaults to !COMPILE_TEST to disable it in
allmodconfig, and it remains disabled in all other defconfigs since it
is a new option.  I arbitrarily raise the warning limit for KASAN_EXTRA
to 3072 to reduce the noise, but an allmodconfig kernel still has around
50 warnings on gcc-7.

I experimented a bit more with smaller stack frames and have another
follow-up series that reduces the warning limit for 64-bit architectures
to 1280 bytes (without CONFIG_KASAN).

With earlier versions of this patch series, I also had patches to address
the warnings we get with KASAN and/or KASAN_EXTRA, using a
"noinline_if_stackbloat" annotation.

That annotation now got replaced with a gcc-8 bugfix (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715) and a workaround for
older compilers, which means that KASAN_EXTRA is now just as bad as
before and will lead to an instant stack overflow in a few extreme
cases.

This reverts parts of commit 3f181b4d8652 ("lib/Kconfig.debug: disable
-Wframe-larger-than warnings with KASAN=y").  Two patches in linux-next
should be merged first to avoid introducing warnings in an allmodconfig
build:
  3cd890dbe2a4 ("media: dvb-frontends: fix i2c access helpers for KASAN")
  16c3ada89cff ("media: r820t: fix r820t_write_reg for KASAN")

Do we really need to backport this?

I think we do: without this patch, enabling KASAN will lead to
unavoidable kernel stack overflow in certain device drivers when built
with gcc-7 or higher on linux-4.10+ or any version that contains a
backport of commit c5caf21ab0cf8.  Most people are probably still on
older compilers, but it will get worse over time as they upgrade their
distros.

The warnings we get on kernels older than this should all be for code
that uses dangerously large stack frames, though most of them do not
cause an actual stack overflow by themselves.The asan-stack option was
added in linux-4.0, and commit 3f181b4d8652 ("lib/Kconfig.debug:
disable -Wframe-larger-than warnings with KASAN=y") effectively turned
off the warning for allmodconfig kernels, so I would like to see this
fix backported to any kernels later than 4.0.

I have done dozens of fixes for individual functions with stack frames
larger than 2048 bytes with asan-stack, and I plan to make sure that
all those fixes make it into the stable kernels as well (most are
already there).

Part of the complication here is that asan-stack (from 4.0) was
originally assumed to always require much larger stacks, but that
turned out to be a combination of multiple gcc bugs that we have now
worked around and fixed, but sanitize-address-use-after-scope (from
v4.10) has a much higher inherent stack usage and also suffers from at
least three other problems that we have analyzed but not yet fixed
upstream, each of them makes the stack usage more severe than it should
be.

Link: http://lkml.kernel.org/r/20171221134744.2295529-1-a...@arndb.de
Signed-off-by: Arnd Bergmann 
Acked-by: Andrey Ryabinin 
Cc: Mauro Carvalho Chehab 
Cc: Andrey Ryabinin 
Cc: Alexander Potapenko 
Cc: Dmitry Vyukov 
Cc: Andrey Konovalov 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[arnd: rebase to v4.9; only re-enable warning]
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 
---
 lib/Kconfig.debug |1 -
 1 file changed, 1 deletion(-)

--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -197,7 +197,6 @@ config 

[PATCH 4.9 132/145] clk: meson: gxbb: fix build error without RESET_CONTROLLER

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Tobias Regnery 

commit dbed87a9d3a857a86f602775b5845f5f6d9652b5 upstream.

With CONFIG_RESET_CONTROLLER=n we see the following link error in the
meson gxbb clk driver:

drivers/built-in.o: In function 'gxbb_aoclkc_probe':
drivers/clk/meson/gxbb-aoclk.c:161: undefined reference to 
'devm_reset_controller_register'

Fix this by selecting the reset controller subsystem.

Fixes: f8c11f79912d ("clk: meson: Add GXBB AO Clock and Reset controller 
driver")
Signed-off-by: Tobias Regnery 
Acked-by: Neil Armstrong 
[narmstrong: Added fixes-by tag]
Signed-off-by: Neil Armstrong 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/clk/meson/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -14,6 +14,7 @@ config COMMON_CLK_MESON8B
 config COMMON_CLK_GXBB
bool
depends on COMMON_CLK_AMLOGIC
+   select RESET_CONTROLLER
help
  Support for the clock controller on AmLogic S905 devices, aka gxbb.
  Say Y if you want peripherals and CPU frequency scaling to work.




[PATCH 4.9 136/145] binfmt_elf: compat: avoid unused function warning

2018-02-23 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

When CONFIG_ELF_CORE is disabled, we get a harmless warning in the compat
version of binfmt_elf:

fs/compat_binfmt_elf.c:58:13: error: 'cputime_to_compat_timeval' defined but 
not used [-Werror=unused-function]

This was addressed in mainline Linux as part of a larger rework with commit
cd19c364b313 ("fs/binfmt: Convert obsolete cputime type to nsecs").

For 4.9 and earlier, this just shuts up the warning by adding an #ifdef
around the function definition.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 
---
 fs/compat_binfmt_elf.c |2 ++
 1 file changed, 2 insertions(+)

--- a/fs/compat_binfmt_elf.c
+++ b/fs/compat_binfmt_elf.c
@@ -51,6 +51,7 @@
 #define elf_prstatus   compat_elf_prstatus
 #define elf_prpsinfo   compat_elf_prpsinfo
 
+#ifdef CONFIG_ELF_CORE
 /*
  * Compat version of cputime_to_compat_timeval, perhaps this
  * should be an inline in .
@@ -63,6 +64,7 @@ static void cputime_to_compat_timeval(co
value->tv_sec = tv.tv_sec;
value->tv_usec = tv.tv_usec;
 }
+#endif
 
 #undef cputime_to_timeval
 #define cputime_to_timeval cputime_to_compat_timeval




<    5   6   7   8   9   10   11   12   13   14   >