[PATCH 5.11 424/775] powerpc/sstep: Fix load-store and update emulation

2021-03-01 Thread Greg Kroah-Hartman
From: Sandipan Das 

[ Upstream commit bbda4b6c7d7c7f79da71f95c92a5d76be22c3efd ]

The Power ISA says that the fixed-point load and update instructions
must neither use R0 for the base address (RA) nor have the
destination (RT) and the base address (RA) as the same register.
Similarly, for fixed-point stores and floating-point loads and stores,
the instruction is invalid when R0 is used as the base address (RA).

This is applicable to the following instructions.
  * Load Byte and Zero with Update (lbzu)
  * Load Byte and Zero with Update Indexed (lbzux)
  * Load Halfword and Zero with Update (lhzu)
  * Load Halfword and Zero with Update Indexed (lhzux)
  * Load Halfword Algebraic with Update (lhau)
  * Load Halfword Algebraic with Update Indexed (lhaux)
  * Load Word and Zero with Update (lwzu)
  * Load Word and Zero with Update Indexed (lwzux)
  * Load Word Algebraic with Update Indexed (lwaux)
  * Load Doubleword with Update (ldu)
  * Load Doubleword with Update Indexed (ldux)
  * Load Floating Single with Update (lfsu)
  * Load Floating Single with Update Indexed (lfsux)
  * Load Floating Double with Update (lfdu)
  * Load Floating Double with Update Indexed (lfdux)
  * Store Byte with Update (stbu)
  * Store Byte with Update Indexed (stbux)
  * Store Halfword with Update (sthu)
  * Store Halfword with Update Indexed (sthux)
  * Store Word with Update (stwu)
  * Store Word with Update Indexed (stwux)
  * Store Doubleword with Update (stdu)
  * Store Doubleword with Update Indexed (stdux)
  * Store Floating Single with Update (stfsu)
  * Store Floating Single with Update Indexed (stfsux)
  * Store Floating Double with Update (stfdu)
  * Store Floating Double with Update Indexed (stfdux)

E.g. the following behaviour is observed for an invalid load and
update instruction having RA = RT.

While a userspace program having an instruction word like 0xe9ce0001,
i.e. ldu r14, 0(r14), runs without getting receiving a SIGILL on a
Power system (observed on P8 and P9), the outcome of executing that
instruction word varies and its behaviour can be considered to be
undefined.

Attaching an uprobe at that instruction's address results in emulation
which currently performs the load as well as writes the effective
address back to the base register. This might not match the outcome
from hardware.

To remove any inconsistencies, this adds additional checks for the
aforementioned instructions to make sure that the emulation
infrastructure treats them as unknown. The kernel can then fallback to
executing such instructions on hardware.

Fixes: 0016a4cf5582 ("powerpc: Emulate most Book I instructions in 
emulate_step()")
Signed-off-by: Sandipan Das 
Reviewed-by: Naveen N. Rao 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20210204080744.135785-1-sandi...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/lib/sstep.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 33935869e4976..25cfa9c622c58 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -3019,6 +3019,20 @@ int analyse_instr(struct instruction_op *op, const 
struct pt_regs *regs,
 
}
 
+   if (OP_IS_LOAD_STORE(op->type) && (op->type & UPDATE)) {
+   switch (GETTYPE(op->type)) {
+   case LOAD:
+   if (ra == rd)
+   goto unknown_opcode;
+   fallthrough;
+   case STORE:
+   case LOAD_FP:
+   case STORE_FP:
+   if (ra == 0)
+   goto unknown_opcode;
+   }
+   }
+
 #ifdef CONFIG_VSX
if ((GETTYPE(op->type) == LOAD_VSX ||
 GETTYPE(op->type) == STORE_VSX) &&
-- 
2.27.0





[PATCH 5.11 426/775] clk: qcom: gfm-mux: fix clk mask

2021-03-01 Thread Greg Kroah-Hartman
From: Srinivas Kandagatla 

[ Upstream commit 78ddb79cab178534b2c1d9ab95823f2af882ee8e ]

For some reason global GFM_MASK ended up with bit 1 instead of bit 0.
Remove the global GFM_MASK and reuse mux_mask field.

Fixes: a2d8f507803e ("clk: qcom: Add support to LPASS AUDIO_CC Glitch Free Mux 
clocks")
Signed-off-by: Srinivas Kandagatla 
Link: 
https://lore.kernel.org/r/20210119113851.18946-1-srinivas.kandaga...@linaro.org
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin 
---
 drivers/clk/qcom/lpass-gfm-sm8250.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/qcom/lpass-gfm-sm8250.c 
b/drivers/clk/qcom/lpass-gfm-sm8250.c
index d366c7c2abc77..f5e31e692b9b4 100644
--- a/drivers/clk/qcom/lpass-gfm-sm8250.c
+++ b/drivers/clk/qcom/lpass-gfm-sm8250.c
@@ -33,14 +33,13 @@ struct clk_gfm {
void __iomem *gfm_mux;
 };
 
-#define GFM_MASK   BIT(1)
 #define to_clk_gfm(_hw) container_of(_hw, struct clk_gfm, hw)
 
 static u8 clk_gfm_get_parent(struct clk_hw *hw)
 {
struct clk_gfm *clk = to_clk_gfm(hw);
 
-   return readl(clk->gfm_mux) & GFM_MASK;
+   return readl(clk->gfm_mux) & clk->mux_mask;
 }
 
 static int clk_gfm_set_parent(struct clk_hw *hw, u8 index)
@@ -51,9 +50,10 @@ static int clk_gfm_set_parent(struct clk_hw *hw, u8 index)
val = readl(clk->gfm_mux);
 
if (index)
-   val |= GFM_MASK;
+   val |= clk->mux_mask;
else
-   val &= ~GFM_MASK;
+   val &= ~clk->mux_mask;
+
 
writel(val, clk->gfm_mux);
 
-- 
2.27.0





[PATCH 5.11 425/775] powerpc/sstep: Fix darn emulation

2021-03-01 Thread Greg Kroah-Hartman
From: Sandipan Das 

[ Upstream commit 22b89ba178dd0a66a26699ead014a3e73ff8e044 ]

Commit 8813ff49607e ("powerpc/sstep: Check instruction validity
against ISA version before emulation") introduced a proper way to skip
unknown instructions. This makes sure that the same is used for the
darn instruction when the range selection bits have a reserved value.

Fixes: a23987ef267a ("powerpc: sstep: Add support for darn instruction")
Signed-off-by: Sandipan Das 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20210204080744.135785-2-sandi...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/lib/sstep.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 25cfa9c622c58..bb5c20d4ca91c 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1918,7 +1918,7 @@ int analyse_instr(struct instruction_op *op, const struct 
pt_regs *regs,
goto compute_done;
}
 
-   return -1;
+   goto unknown_opcode;
 #ifdef __powerpc64__
case 777:   /* modsd */
if (!cpu_has_feature(CPU_FTR_ARCH_300))
-- 
2.27.0





Re: [PATCH] can: c_can: move runtime PM enable/disable to c_can_platform

2021-03-01 Thread Marc Kleine-Budde
On 28.02.2021 23:15:48, Tong Zhang wrote:
> Currently doing modprobe c_can_pci will make kernel complain
> "Unbalanced pm_runtime_enable!", this is caused by pm_runtime_enable()
> called before pm is initialized in register_candev() and doing so will

I don't see where register_candev() is doing any pm related
initialization.

> also cause it to enable twice.

> This fix is similar to 227619c3ff7c, move those pm_enable/disable code to
> c_can_platform.

As I understand 227619c3ff7c ("can: m_can: move runtime PM
enable/disable to m_can_platform"), PCI devices automatically enable PM,
when the "PCI device is added".

Please clarify the above point, otherwise the code looks OK, small
nitpick inline:

> Signed-off-by: Tong Zhang 
> ---
>  drivers/net/can/c_can/c_can.c  | 26 ++
>  drivers/net/can/c_can/c_can_platform.c |  6 +-
>  2 files changed, 7 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
> index ef474bae47a1..04f783b3d9d3 100644
> --- a/drivers/net/can/c_can/c_can.c
> +++ b/drivers/net/can/c_can/c_can.c
> @@ -212,18 +212,6 @@ static const struct can_bittiming_const 
> c_can_bittiming_const = {
>   .brp_inc = 1,
>  };
>  
> -static inline void c_can_pm_runtime_enable(const struct c_can_priv *priv)
> -{
> - if (priv->device)
> - pm_runtime_enable(priv->device);
> -}
> -
> -static inline void c_can_pm_runtime_disable(const struct c_can_priv *priv)
> -{
> - if (priv->device)
> - pm_runtime_disable(priv->device);
> -}
> -
>  static inline void c_can_pm_runtime_get_sync(const struct c_can_priv *priv)
>  {
>   if (priv->device)
> @@ -1335,7 +1323,6 @@ static const struct net_device_ops c_can_netdev_ops = {
>  
>  int register_c_can_dev(struct net_device *dev)
>  {
> - struct c_can_priv *priv = netdev_priv(dev);
>   int err;
>  
>   /* Deactivate pins to prevent DRA7 DCAN IP from being
> @@ -1345,28 +1332,19 @@ int register_c_can_dev(struct net_device *dev)
>*/
>   pinctrl_pm_select_sleep_state(dev->dev.parent);
>  
> - c_can_pm_runtime_enable(priv);
> -
>   dev->flags |= IFF_ECHO; /* we support local echo */
>   dev->netdev_ops = _can_netdev_ops;
>  
>   err = register_candev(dev);
> - if (err)
> - c_can_pm_runtime_disable(priv);
> - else
> - devm_can_led_init(dev);
> -
> + if (!err)
> +   devm_can_led_init(dev);

Please indent with two tabs here.

regards,
Marc

-- 
Pengutronix e.K. | Marc Kleine-Budde   |
Embedded Linux   | https://www.pengutronix.de  |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917- |


signature.asc
Description: PGP signature


[PATCH 5.11 398/775] mmc: usdhi6rol0: Fix a resource leak in the error handling path of the probe

2021-03-01 Thread Greg Kroah-Hartman
From: Christophe JAILLET 

[ Upstream commit 6052b3c370fb82dec28bcfff6d7ec0da84ac087a ]

A call to 'ausdhi6_dma_release()' to undo a previous call to
'usdhi6_dma_request()' is missing in the error handling path of the probe
function.

It is already present in the remove function.

Fixes: 75fa9ea6e3c0 ("mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host 
controller")
Signed-off-by: Christophe JAILLET 
Link: 
https://lore.kernel.org/r/20201217210922.165340-1-christophe.jail...@wanadoo.fr
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin 
---
 drivers/mmc/host/usdhi6rol0.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/usdhi6rol0.c b/drivers/mmc/host/usdhi6rol0.c
index e2d5112d809dc..615f3d008af1e 100644
--- a/drivers/mmc/host/usdhi6rol0.c
+++ b/drivers/mmc/host/usdhi6rol0.c
@@ -1858,10 +1858,12 @@ static int usdhi6_probe(struct platform_device *pdev)
 
ret = mmc_add_host(mmc);
if (ret < 0)
-   goto e_clk_off;
+   goto e_release_dma;
 
return 0;
 
+e_release_dma:
+   usdhi6_dma_release(host);
 e_clk_off:
clk_disable_unprepare(host->clk);
 e_free_mmc:
-- 
2.27.0





[PATCH 5.11 422/775] powerpc/pseries/dlpar: handle ibm, configure-connector delay status

2021-03-01 Thread Greg Kroah-Hartman
From: Nathan Lynch 

[ Upstream commit 768d70e19ba525debd571b36e6d0ab19956c63d7 ]

dlpar_configure_connector() has two problems in its handling of
ibm,configure-connector's return status:

1. When the status is -2 (busy, call again), we call
   ibm,configure-connector again immediately without checking whether
   to schedule, which can result in monopolizing the CPU.
2. Extended delay status (9900..9905) goes completely unhandled,
   causing the configuration to unnecessarily terminate.

Fix both of these issues by using rtas_busy_delay().

Fixes: ab519a011caa ("powerpc/pseries: Kernel DLPAR Infrastructure")
Signed-off-by: Nathan Lynch 
Reviewed-by: Tyrel Datwyler 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20210107025900.410369-1-nath...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/pseries/dlpar.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/dlpar.c 
b/arch/powerpc/platforms/pseries/dlpar.c
index 16e86ba8aa209..f6b7749d6ada7 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -127,7 +127,6 @@ void dlpar_free_cc_nodes(struct device_node *dn)
 #define NEXT_PROPERTY   3
 #define PREV_PARENT 4
 #define MORE_MEMORY 5
-#define CALL_AGAIN -2
 #define ERR_CFG_USE -9003
 
 struct device_node *dlpar_configure_connector(__be32 drc_index,
@@ -168,6 +167,9 @@ struct device_node *dlpar_configure_connector(__be32 
drc_index,
 
spin_unlock(_data_buf_lock);
 
+   if (rtas_busy_delay(rc))
+   continue;
+
switch (rc) {
case COMPLETE:
break;
@@ -216,9 +218,6 @@ struct device_node *dlpar_configure_connector(__be32 
drc_index,
last_dn = last_dn->parent;
break;
 
-   case CALL_AGAIN:
-   break;
-
case MORE_MEMORY:
case ERR_CFG_USE:
default:
-- 
2.27.0





[PATCH 5.11 421/775] mfd: wm831x-auxadc: Prevent use after free in wm831x_auxadc_read_irq()

2021-03-01 Thread Greg Kroah-Hartman
From: Dan Carpenter 

[ Upstream commit 26783d74cc6a440ee3ef9836a008a697981013d0 ]

The "req" struct is always added to the "wm831x->auxadc_pending" list,
but it's only removed from the list on the success path.  If a failure
occurs then the "req" struct is freed but it's still on the list,
leading to a use after free.

Fixes: 78bb3688ea18 ("mfd: Support multiple active WM831x AUXADC conversions")
Signed-off-by: Dan Carpenter 
Acked-by: Charles Keepax 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin 
---
 drivers/mfd/wm831x-auxadc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/mfd/wm831x-auxadc.c b/drivers/mfd/wm831x-auxadc.c
index 8a7cc0f86958b..65b98f3fbd929 100644
--- a/drivers/mfd/wm831x-auxadc.c
+++ b/drivers/mfd/wm831x-auxadc.c
@@ -93,11 +93,10 @@ static int wm831x_auxadc_read_irq(struct wm831x *wm831x,
wait_for_completion_timeout(>done, msecs_to_jiffies(500));
 
mutex_lock(>auxadc_lock);
-
-   list_del(>list);
ret = req->val;
 
 out:
+   list_del(>list);
mutex_unlock(>auxadc_lock);
 
kfree(req);
-- 
2.27.0





Re: [PATCH v3 5/6] can: c_can: prepare to up the message objects number

2021-03-01 Thread Marc Kleine-Budde
On 01.03.2021 14:08:45, Marc Kleine-Budde wrote:
> On 01.03.2021 12:38:05, Marc Kleine-Budde wrote:
> > On 28.02.2021 11:38:54, Dario Binacchi wrote:
> > [...]
> > 
> > > @@ -730,7 +728,7 @@ static void c_can_do_tx(struct net_device *dev)
> > >   while ((idx = ffs(pend))) {
> > >   idx--;
> > >   pend &= ~(1 << idx);
> > > - obj = idx + C_CAN_MSG_OBJ_TX_FIRST;
> > > + obj = idx + priv->msg_obj_tx_first;
> > >   c_can_inval_tx_object(dev, IF_TX, obj);
> > >   can_get_echo_skb(dev, idx, NULL);
> > >   bytes += priv->dlc[idx];
> > > @@ -740,7 +738,7 @@ static void c_can_do_tx(struct net_device *dev)
> > >   /* Clear the bits in the tx_active mask */
> > >   atomic_sub(clr, >tx_active);
> > >  
> > > - if (clr & (1 << (C_CAN_MSG_OBJ_TX_NUM - 1)))
> > > + if (clr & (1 << (priv->msg_obj_tx_num - 1)))
> > 
> > Do we need 1UL here, too?
> 
> There are several more "1 <<" in the driver. As the right side of the
> sift operation can be up to 32, I think you should replace all "1 <<"
> with "1UL <<".

Even better use BIT() for setting single bits and GENMASK() to generate
masks.

Marc

-- 
Pengutronix e.K. | Marc Kleine-Budde   |
Embedded Linux   | https://www.pengutronix.de  |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917- |


signature.asc
Description: PGP signature


[PATCH 5.11 417/775] RDMA/rxe: Fix coding error in rxe_rcv_mcast_pkt

2021-03-01 Thread Greg Kroah-Hartman
From: Bob Pearson 

[ Upstream commit 8fc1b7027fc162738d5a85c82410e501a371a404 ]

rxe_rcv_mcast_pkt() in rxe_recv.c can leak SKBs in error path code. The
loop over the QPs attached to a multicast group creates new cloned SKBs
for all but the last QP in the list and passes the SKB and its clones to
rxe_rcv_pkt() for further processing. Any QPs that do not pass some checks
are skipped.  If the last QP in the list fails the tests the SKB is
leaked.  This patch checks if the SKB for the last QP was used and if not
frees it. Also removes a redundant loop invariant assignment.

Fixes: 8700e3e7c485 ("Soft RoCE driver")
Fixes: 71abf20b28ff ("RDMA/rxe: Handle skb_clone() failure in rxe_recv.c")
Link: https://lore.kernel.org/r/20210128174752.16128-1-rpear...@hpe.com
Signed-off-by: Bob Pearson 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/sw/rxe/rxe_recv.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/infiniband/sw/rxe/rxe_recv.c 
b/drivers/infiniband/sw/rxe/rxe_recv.c
index db0ee5c3962e4..cb69a125e2806 100644
--- a/drivers/infiniband/sw/rxe/rxe_recv.c
+++ b/drivers/infiniband/sw/rxe/rxe_recv.c
@@ -257,7 +257,6 @@ static void rxe_rcv_mcast_pkt(struct rxe_dev *rxe, struct 
sk_buff *skb)
 
list_for_each_entry(mce, >qp_list, qp_list) {
qp = mce->qp;
-   pkt = SKB_TO_PKT(skb);
 
/* validate qp for incoming packet */
err = check_type_state(rxe, pkt, qp);
@@ -269,12 +268,18 @@ static void rxe_rcv_mcast_pkt(struct rxe_dev *rxe, struct 
sk_buff *skb)
continue;
 
/* for all but the last qp create a new clone of the
-* skb and pass to the qp.
+* skb and pass to the qp. If an error occurs in the
+* checks for the last qp in the list we need to
+* free the skb since it hasn't been passed on to
+* rxe_rcv_pkt() which would free it later.
 */
-   if (mce->qp_list.next != >qp_list)
+   if (mce->qp_list.next != >qp_list) {
per_qp_skb = skb_clone(skb, GFP_ATOMIC);
-   else
+   } else {
per_qp_skb = skb;
+   /* show we have consumed the skb */
+   skb = NULL;
+   }
 
if (unlikely(!per_qp_skb))
continue;
@@ -289,9 +294,8 @@ static void rxe_rcv_mcast_pkt(struct rxe_dev *rxe, struct 
sk_buff *skb)
 
rxe_drop_ref(mcg);  /* drop ref from rxe_pool_get_key. */
 
-   return;
-
 err1:
+   /* free skb if not consumed */
kfree_skb(skb);
 }
 
-- 
2.27.0





Re: [PATCH v3 5/6] can: c_can: prepare to up the message objects number

2021-03-01 Thread Marc Kleine-Budde
On 01.03.2021 18:24:31, Dario Binacchi wrote:
> Hi Marc,
> 
> > Il 01/03/2021 14:08 Marc Kleine-Budde  ha scritto:
> > 
> >  
> > On 01.03.2021 12:38:05, Marc Kleine-Budde wrote:
> > > On 28.02.2021 11:38:54, Dario Binacchi wrote:
> > > [...]
> > > 
> > > > @@ -730,7 +728,7 @@ static void c_can_do_tx(struct net_device *dev)
> > > > while ((idx = ffs(pend))) {
> > > > idx--;
> > > > pend &= ~(1 << idx);
> > > > -   obj = idx + C_CAN_MSG_OBJ_TX_FIRST;
> > > > +   obj = idx + priv->msg_obj_tx_first;
> > > > c_can_inval_tx_object(dev, IF_TX, obj);
> > > > can_get_echo_skb(dev, idx, NULL);
> > > > bytes += priv->dlc[idx];
> > > > @@ -740,7 +738,7 @@ static void c_can_do_tx(struct net_device *dev)
> > > > /* Clear the bits in the tx_active mask */
> > > > atomic_sub(clr, >tx_active);
> > > >  
> > > > -   if (clr & (1 << (C_CAN_MSG_OBJ_TX_NUM - 1)))
> > > > +   if (clr & (1 << (priv->msg_obj_tx_num - 1)))
> > > 
> > > Do we need 1UL here, too?
> > 
> > There are several more "1 <<" in the driver. As the right side of the
> > sift operation can be up to 32, I think you should replace all "1 <<"
> > with "1UL <<".
> 
> Do you agree if I use the BIT macro for all these shift operations?

No, only use BIT(), where you want to set a single bit, use GENMASK()
for masks.

regards,
Marc

-- 
Pengutronix e.K. | Marc Kleine-Budde   |
Embedded Linux   | https://www.pengutronix.de  |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917- |


signature.asc
Description: PGP signature


[PATCH 5.11 419/775] spi: stm32: properly handle 0 byte transfer

2021-03-01 Thread Greg Kroah-Hartman
From: Alain Volmat 

[ Upstream commit 2269f5a8b1a7b38651d62676b98182828f29d11a ]

On 0 byte transfer request, return straight from the
xfer function after finalizing the transfer.

Fixes: dcbe0d84dfa5 ("spi: add driver for STM32 SPI controller")
Signed-off-by: Alain Volmat 
Link: 
https://lore.kernel.org/r/1612551572-495-2-git-send-email-alain.vol...@foss.st.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 drivers/spi/spi-stm32.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c
index 6017209c6d2f7..6eeb39669a866 100644
--- a/drivers/spi/spi-stm32.c
+++ b/drivers/spi/spi-stm32.c
@@ -1677,6 +1677,10 @@ static int stm32_spi_transfer_one(struct spi_master 
*master,
struct stm32_spi *spi = spi_master_get_devdata(master);
int ret;
 
+   /* Don't do anything on 0 bytes transfers */
+   if (transfer->len == 0)
+   return 0;
+
spi->tx_buf = transfer->tx_buf;
spi->rx_buf = transfer->rx_buf;
spi->tx_len = spi->tx_buf ? transfer->len : 0;
-- 
2.27.0





[PATCH 5.11 418/775] RDMA/rxe: Correct skb on loopback path

2021-03-01 Thread Greg Kroah-Hartman
From: Bob Pearson 

[ Upstream commit 5120bf0a5fc15dec210a0fe0f39e4a256bb6e349 ]

rxe_net.c sends packets at the IP layer with skb->data pointing at the IP
header but receives packets from a UDP tunnel with skb->data pointing at
the UDP header.  On the loopback path this was not correctly accounted
for.  This patch corrects for this by using sbk_pull() to strip the IP
header from the skb on received packets.

Fixes: 8700e3e7c485 ("Soft RoCE driver")
Link: https://lore.kernel.org/r/20210128182301.16859-1-rpear...@hpe.com
Signed-off-by: Bob Pearson 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/sw/rxe/rxe_net.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/infiniband/sw/rxe/rxe_net.c 
b/drivers/infiniband/sw/rxe/rxe_net.c
index 943914c2a50c7..bce44502ab0ed 100644
--- a/drivers/infiniband/sw/rxe/rxe_net.c
+++ b/drivers/infiniband/sw/rxe/rxe_net.c
@@ -414,6 +414,11 @@ int rxe_send(struct rxe_pkt_info *pkt, struct sk_buff *skb)
 
 void rxe_loopback(struct sk_buff *skb)
 {
+   if (skb->protocol == htons(ETH_P_IP))
+   skb_pull(skb, sizeof(struct iphdr));
+   else
+   skb_pull(skb, sizeof(struct ipv6hdr));
+
rxe_rcv(skb);
 }
 
-- 
2.27.0





[PATCH 5.11 420/775] mfd: altera-sysmgr: Fix physical address storing more

2021-03-01 Thread Greg Kroah-Hartman
From: Arnd Bergmann 

[ Upstream commit b0b5b16b78cea1b2b990a69ab8e07a42ccf7a2ed ]

A recent fix improved the way the resource gets passed to
the low-level accessors, but left one warning that appears
in configurations with a resource_size_t that is wider than
a pointer:

In file included from drivers/mfd/altera-sysmgr.c:19:
drivers/mfd/altera-sysmgr.c: In function 'sysmgr_probe':
drivers/mfd/altera-sysmgr.c:148:40: error: cast to pointer from integer of 
different size [-Werror=int-to-pointer-cast]
  148 |   regmap = devm_regmap_init(dev, NULL, (void *)res->start,
  |^
include/linux/regmap.h:646:6: note: in definition of macro 
'__regmap_lockdep_wrapper'
  646 |   fn(__VA_ARGS__, &_key, \
  |  ^~~
drivers/mfd/altera-sysmgr.c:148:12: note: in expansion of macro 
'devm_regmap_init'
  148 |   regmap = devm_regmap_init(dev, NULL, (void *)res->start,
  |^~~~

I had tried a different approach that would store the address
in the private data as a phys_addr_t, but the easiest solution
now seems to be to add a double cast to shut up the warning.

As the address is passed to an inline assembly, it is guaranteed
to not be wider than a register anyway.

Fixes: d9ca7801b6e5 ("mfd: altera-sysmgr: Fix physical address storing hacks")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin 
---
 drivers/mfd/altera-sysmgr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/altera-sysmgr.c b/drivers/mfd/altera-sysmgr.c
index 193a96c8b1eab..20cb294c75122 100644
--- a/drivers/mfd/altera-sysmgr.c
+++ b/drivers/mfd/altera-sysmgr.c
@@ -145,7 +145,8 @@ static int sysmgr_probe(struct platform_device *pdev)
sysmgr_config.reg_write = s10_protected_reg_write;
 
/* Need physical address for SMCC call */
-   regmap = devm_regmap_init(dev, NULL, (void *)res->start,
+   regmap = devm_regmap_init(dev, NULL,
+ (void *)(uintptr_t)res->start,
  _config);
} else {
base = devm_ioremap(dev, res->start, resource_size(res));
-- 
2.27.0





[PATCH 5.11 411/775] platform/x86: intel_pmt: Make INTEL_PMT_CLASS non-user-selectable

2021-03-01 Thread Greg Kroah-Hartman
From: David E. Box 

[ Upstream commit 35d8a973fe4d38afee944db636c3d2b1df3741a7 ]

Fix error in Kconfig that exposed INTEL_PMT_CLASS as a user selectable
option. It is already selected by INTEL_PMT_TELEMETRY and
INTEL_PMT_CRASHLOG which are user selectable.

Fixes: e2729113ce66 ("platform/x86: Intel PMT class driver")
Signed-off-by: David E. Box 
Link: 
https://lore.kernel.org/r/20210126205508.30907-1-david.e@linux.intel.com
Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin 
---
 drivers/platform/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 91e6176cdfbdf..af75c3342c061 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1369,7 +1369,7 @@ config INTEL_PMC_CORE
- MPHY/PLL gating status (Sunrisepoint PCH only)
 
 config INTEL_PMT_CLASS
-   tristate "Intel Platform Monitoring Technology (PMT) Class driver"
+   tristate
help
  The Intel Platform Monitoring Technology (PMT) class driver provides
  the basic sysfs interface and file hierarchy uses by PMT devices.
-- 
2.27.0





[PATCH 5.11 397/775] mmc: sdhci-sprd: Fix some resource leaks in the remove function

2021-03-01 Thread Greg Kroah-Hartman
From: Christophe JAILLET 

[ Upstream commit c9c256a8b0dc09c305c409d6264cc016af2ba38d ]

'sdhci_remove_host()' and 'sdhci_pltfm_free()' should be used in place of
'mmc_remove_host()' and 'mmc_free_host()'.

This avoids some resource leaks, is more in line with the error handling
path of the probe function, and is more consistent with other drivers.

Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host 
controller")
Signed-off-by: Christophe JAILLET 
Acked-by: Orson Zhai 
Acked-by: Adrian Hunter 
Link: 
https://lore.kernel.org/r/20201217204236.163446-1-christophe.jail...@wanadoo.fr
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin 
---
 drivers/mmc/host/sdhci-sprd.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci-sprd.c b/drivers/mmc/host/sdhci-sprd.c
index f85171edabeb9..5dc36efff47ff 100644
--- a/drivers/mmc/host/sdhci-sprd.c
+++ b/drivers/mmc/host/sdhci-sprd.c
@@ -708,14 +708,14 @@ static int sdhci_sprd_remove(struct platform_device *pdev)
 {
struct sdhci_host *host = platform_get_drvdata(pdev);
struct sdhci_sprd_host *sprd_host = TO_SPRD_HOST(host);
-   struct mmc_host *mmc = host->mmc;
 
-   mmc_remove_host(mmc);
+   sdhci_remove_host(host, 0);
+
clk_disable_unprepare(sprd_host->clk_sdio);
clk_disable_unprepare(sprd_host->clk_enable);
clk_disable_unprepare(sprd_host->clk_2x_enable);
 
-   mmc_free_host(mmc);
+   sdhci_pltfm_free(pdev);
 
return 0;
 }
-- 
2.27.0





[PATCH 5.11 416/775] RDMA/rxe: Fix coding error in rxe_recv.c

2021-03-01 Thread Greg Kroah-Hartman
From: Bob Pearson 

[ Upstream commit 7d9ae80e31df57dd3253e1ec514faa588a81 ]

check_type_state() in rxe_recv.c is written as if the type bits in the
packet opcode were a bit mask which is not correct. This patch corrects
this code to compare all 3 type bits to the required type.

Fixes: 8700e3e7c485 ("Soft RoCE driver")
Link: https://lore.kernel.org/r/20210127214500.3707-1-rpear...@hpe.com
Signed-off-by: Bob Pearson 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/sw/rxe/rxe_recv.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/sw/rxe/rxe_recv.c 
b/drivers/infiniband/sw/rxe/rxe_recv.c
index c9984a28eecc7..db0ee5c3962e4 100644
--- a/drivers/infiniband/sw/rxe/rxe_recv.c
+++ b/drivers/infiniband/sw/rxe/rxe_recv.c
@@ -9,21 +9,26 @@
 #include "rxe.h"
 #include "rxe_loc.h"
 
+/* check that QP matches packet opcode type and is in a valid state */
 static int check_type_state(struct rxe_dev *rxe, struct rxe_pkt_info *pkt,
struct rxe_qp *qp)
 {
+   unsigned int pkt_type;
+
if (unlikely(!qp->valid))
goto err1;
 
+   pkt_type = pkt->opcode & 0xe0;
+
switch (qp_type(qp)) {
case IB_QPT_RC:
-   if (unlikely((pkt->opcode & IB_OPCODE_RC) != 0)) {
+   if (unlikely(pkt_type != IB_OPCODE_RC)) {
pr_warn_ratelimited("bad qp type\n");
goto err1;
}
break;
case IB_QPT_UC:
-   if (unlikely(!(pkt->opcode & IB_OPCODE_UC))) {
+   if (unlikely(pkt_type != IB_OPCODE_UC)) {
pr_warn_ratelimited("bad qp type\n");
goto err1;
}
@@ -31,7 +36,7 @@ static int check_type_state(struct rxe_dev *rxe, struct 
rxe_pkt_info *pkt,
case IB_QPT_UD:
case IB_QPT_SMI:
case IB_QPT_GSI:
-   if (unlikely(!(pkt->opcode & IB_OPCODE_UD))) {
+   if (unlikely(pkt_type != IB_OPCODE_UD)) {
pr_warn_ratelimited("bad qp type\n");
goto err1;
}
-- 
2.27.0





[PATCH 5.11 413/775] platform/x86: intel_pmt_crashlog: Add dependency on MFD_INTEL_PMT

2021-03-01 Thread Greg Kroah-Hartman
From: David E. Box 

[ Upstream commit fdd3feb37e36bec2ad75d76f8ac4d0273c5c0a91 ]

All devices that expose Intel Platform Monitoring Technology (PMT)
crashlog are currently owned by the intel_pmt MFD driver. Therefore make
the crashlog driver depend on the MFD driver for build.

Fixes: 5ef9998c96b0 ("platform/x86: Intel PMT Crashlog capability driver")
Signed-off-by: David E. Box 
Link: 
https://lore.kernel.org/r/20210126205508.30907-3-david.e@linux.intel.com
Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin 
---
 drivers/platform/x86/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 9948c5f4928d4..ac4125ec06603 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1394,6 +1394,7 @@ config INTEL_PMT_TELEMETRY
 
 config INTEL_PMT_CRASHLOG
tristate "Intel Platform Monitoring Technology (PMT) Crashlog driver"
+   depends on MFD_INTEL_PMT
select INTEL_PMT_CLASS
help
  The Intel Platform Monitoring Technology (PMT) crashlog driver 
provides
-- 
2.27.0





[PATCH 5.11 414/775] perf tools: Fix DSO filtering when not finding a map for a sampled address

2021-03-01 Thread Greg Kroah-Hartman
From: Arnaldo Carvalho de Melo 

[ Upstream commit c69bf11ad3d30b6bf01cfa538ddff1a59467c734 ]

When we lookup an address and don't find a map we should filter that
sample if the user specified a list of --dso entries to filter on, fix
it.

Before:

  $ perf script
 sleep 274800  2843.556162:  1 cycles:u:  bb26bff4 
[unknown] ([unknown])
 sleep 274800  2843.556168:  1 cycles:u:  bb2b047d 
[unknown] ([unknown])
 sleep 274800  2843.556171:  1 cycles:u:  bb2706b2 
[unknown] ([unknown])
 sleep 274800  2843.556174:  6 cycles:u:  bb2b0267 
[unknown] ([unknown])
 sleep 274800  2843.556176: 59 cycles:u:  bb2b03b1 
[unknown] ([unknown])
 sleep 274800  2843.556180:691 cycles:u:  bb26bff4 
[unknown] ([unknown])
 sleep 274800  2843.556189:   9160 cycles:u:  7fa9550eeaa3 
__GI___tunables_init+0xf3 (/usr/lib64/ld-2.32.so)
 sleep 274800  2843.556312:  86937 cycles:u:  7fa9550e157b 
_dl_lookup_symbol_x+0x4b (/usr/lib64/ld-2.32.so)
  $

So we have some samples we somehow didn't find in a map for, if we now
do:

  $ perf report --stdio --dso /usr/lib64/ld-2.32.so
  # dso: /usr/lib64/ld-2.32.so
  #
  # Total Lost Samples: 0
  #
  # Samples: 8  of event 'cycles:u'
  # Event count (approx.): 96856
  #
  # Overhead  Command  Symbol
  #   ...  
  #
  89.76%  sleep[.] _dl_lookup_symbol_x
   9.46%  sleep[.] __GI___tunables_init
   0.71%  sleep[k] 0xbb26bff4
   0.06%  sleep[k] 0xbb2b03b1
   0.01%  sleep[k] 0xbb2b0267
   0.00%  sleep[k] 0xbb2706b2
   0.00%  sleep[k] 0xbb2b047d
  $

After this patch we get the right output with just entries for the DSOs
specified in --dso:

  $ perf report --stdio --dso /usr/lib64/ld-2.32.so
  # dso: /usr/lib64/ld-2.32.so
  #
  # Total Lost Samples: 0
  #
  # Samples: 8  of event 'cycles:u'
  # Event count (approx.): 96856
  #
  # Overhead  Command  Symbol
  #   ...  
  #
  89.76%  sleep[.] _dl_lookup_symbol_x
   9.46%  sleep[.] __GI___tunables_init
  $
  #

Fixes: 96415e4d3f5fdf9c ("perf symbols: Avoid unnecessary symbol loading when 
dso list is specified")
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Ingo Molnar 
Cc: Jin Yao 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lore.kernel.org/lkml/20210128131209.gd775...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/util/event.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 05616d4138a96..7e440fa90c938 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -673,6 +673,8 @@ int machine__resolve(struct machine *machine, struct 
addr_location *al,
}
 
al->sym = map__find_symbol(al->map, al->addr);
+   } else if (symbol_conf.dso_list) {
+   al->filtered |= (1 << HIST_FILTER__DSO);
}
 
if (symbol_conf.sym_list) {
-- 
2.27.0





[PATCH 5.11 412/775] platform/x86: intel_pmt_telemetry: Add dependency on MFD_INTEL_PMT

2021-03-01 Thread Greg Kroah-Hartman
From: David E. Box 

[ Upstream commit f3f6da5014dea3cc005b36948abe3664b5d1f7d3 ]

All devices that expose Intel Platform Monitoring Technology (PMT)
telemetry are currently owned by the intel_pmt MFD driver. Therefore make
the telemetry driver depend on the MFD driver for build.

Fixes: 68fe8e6e2c4b ("platform/x86: Intel PMT Telemetry capability driver")
Signed-off-by: David E. Box 
Link: 
https://lore.kernel.org/r/20210126205508.30907-2-david.e@linux.intel.com
Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin 
---
 drivers/platform/x86/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index af75c3342c061..9948c5f4928d4 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1382,6 +1382,7 @@ config INTEL_PMT_CLASS
 
 config INTEL_PMT_TELEMETRY
tristate "Intel Platform Monitoring Technology (PMT) Telemetry driver"
+   depends on MFD_INTEL_PMT
select INTEL_PMT_CLASS
help
  The Intel Platform Monitory Technology (PMT) Telemetry driver provides
-- 
2.27.0





[PATCH 5.11 387/775] IB/umad: Return EIO in case of when device disassociated

2021-03-01 Thread Greg Kroah-Hartman
From: Shay Drory 

[ Upstream commit 4fc5461823c9cad547a9bdfbf17d13f0da0d6bb5 ]

MAD message received by the user has EINVAL error in all flows
including when the device is disassociated. That makes it impossible
for the applications to treat such flow differently.

Change it to return EIO, so the applications will be able to perform
disassociation recovery.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Link: https://lore.kernel.org/r/20210125121339.837518-2-l...@kernel.org
Signed-off-by: Shay Drory 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/core/user_mad.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/user_mad.c 
b/drivers/infiniband/core/user_mad.c
index 19104a6756915..7ec1918431f70 100644
--- a/drivers/infiniband/core/user_mad.c
+++ b/drivers/infiniband/core/user_mad.c
@@ -379,6 +379,11 @@ static ssize_t ib_umad_read(struct file *filp, char __user 
*buf,
 
mutex_lock(>mutex);
 
+   if (file->agents_dead) {
+   mutex_unlock(>mutex);
+   return -EIO;
+   }
+
while (list_empty(>recv_list)) {
mutex_unlock(>mutex);
 
@@ -524,7 +529,7 @@ static ssize_t ib_umad_write(struct file *filp, const char 
__user *buf,
 
agent = __get_agent(file, packet->mad.hdr.id);
if (!agent) {
-   ret = -EINVAL;
+   ret = -EIO;
goto err_up;
}
 
-- 
2.27.0





[PATCH 5.11 410/775] rtc: zynqmp: depend on HAS_IOMEM

2021-03-01 Thread Greg Kroah-Hartman
From: David Gow 

[ Upstream commit ddd0521549a975e6148732d6ca6b89ffa862c0e5 ]

The Xilinx zynqmp RTC driver makes use of IOMEM functions like
devm_platform_ioremap_resource(), which are only available if
CONFIG_HAS_IOMEM is defined.

This causes the driver not to be enable under make ARCH=um allyesconfig,
even though it won't build.

By adding a dependency on HAS_IOMEM, the driver will not be enabled on
architectures which don't support it.

Fixes: 09ef18bcd5ac ("rtc: use devm_platform_ioremap_resource() to simplify 
code")
Signed-off-by: David Gow 
Signed-off-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/20210127035146.1523286-1-david...@google.com
Signed-off-by: Sasha Levin 
---
 drivers/rtc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index e4bef40831c75..4e2b3a175607b 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1301,7 +1301,7 @@ config RTC_DRV_OPAL
 
 config RTC_DRV_ZYNQMP
tristate "Xilinx Zynq Ultrascale+ MPSoC RTC"
-   depends on OF
+   depends on OF && HAS_IOMEM
help
  If you say yes here you get support for the RTC controller found on
  Xilinx Zynq Ultrascale+ MPSoC.
-- 
2.27.0





[PATCH 5.11 409/775] tracepoint: Do not fail unregistering a probe due to memory failure

2021-03-01 Thread Greg Kroah-Hartman
From: Steven Rostedt (VMware) 

[ Upstream commit befe6d946551d65cddbd32b9cb0170b0249fd5ed ]

The list of tracepoint callbacks is managed by an array that is protected
by RCU. To update this array, a new array is allocated, the updates are
copied over to the new array, and then the list of functions for the
tracepoint is switched over to the new array. After a completion of an RCU
grace period, the old array is freed.

This process happens for both adding a callback as well as removing one.
But on removing a callback, if the new array fails to be allocated, the
callback is not removed, and may be used after it is freed by the clients
of the tracepoint.

There's really no reason to fail if the allocation for a new array fails
when removing a function. Instead, the function can simply be replaced by a
stub function that could be cleaned up on the next modification of the
array. That is, instead of calling the function registered to the
tracepoint, it would call a stub function in its place.

Link: https://lore.kernel.org/r/20201115055256.65625-1-mmull...@mmlx.us
Link: https://lore.kernel.org/r/20201116175107.02db3...@gandalf.local.home
Link: https://lore.kernel.org/r/20201117211836.54aca...@oasis.local.home
Link: https://lkml.kernel.org/r/20201118093405.7a6d2...@gandalf.local.home

[ Note, this version does use undefined compiler behavior (assuming that
  a stub function with no parameters or return, can be called by a location
  that thinks it has parameters but still no return value. Static calls
  do the same thing, so this trick is not without precedent.

  There's another solution that uses RCU tricks and is more complex, but
  can be an alternative if this solution becomes an issue.

  Link: https://lore.kernel.org/lkml/20210127170721.58bce...@gandalf.local.home/
]

Cc: Peter Zijlstra 
Cc: Josh Poimboeuf 
Cc: Mathieu Desnoyers 
Cc: Ingo Molnar 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Dmitry Vyukov 
Cc: Martin KaFai Lau 
Cc: Song Liu 
Cc: Yonghong Song 
Cc: Andrii Nakryiko 
Cc: John Fastabend 
Cc: KP Singh 
Cc: netdev 
Cc: bpf 
Cc: Kees Cook 
Cc: Florian Weimer 
Fixes: 97e1c18e8d17b ("tracing: Kernel Tracepoints")
Reported-by: syzbot+83aa762ef23b6f0d1...@syzkaller.appspotmail.com
Reported-by: syzbot+d29e58bb557324e55...@syzkaller.appspotmail.com
Reported-by: Matt Mullins 
Signed-off-by: Steven Rostedt (VMware) 
Tested-by: Matt Mullins 
Signed-off-by: Sasha Levin 
---
 kernel/tracepoint.c | 80 -
 1 file changed, 64 insertions(+), 16 deletions(-)

diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
index 7261fa0f5e3cc..e8f20ae29c18f 100644
--- a/kernel/tracepoint.c
+++ b/kernel/tracepoint.c
@@ -53,6 +53,12 @@ struct tp_probes {
struct tracepoint_func probes[];
 };
 
+/* Called in removal of a func but failed to allocate a new tp_funcs */
+static void tp_stub_func(void)
+{
+   return;
+}
+
 static inline void *allocate_probes(int count)
 {
struct tp_probes *p  = kmalloc(struct_size(p, probes, count),
@@ -131,6 +137,7 @@ func_add(struct tracepoint_func **funcs, struct 
tracepoint_func *tp_func,
 {
struct tracepoint_func *old, *new;
int nr_probes = 0;
+   int stub_funcs = 0;
int pos = -1;
 
if (WARN_ON(!tp_func->func))
@@ -147,14 +154,34 @@ func_add(struct tracepoint_func **funcs, struct 
tracepoint_func *tp_func,
if (old[nr_probes].func == tp_func->func &&
old[nr_probes].data == tp_func->data)
return ERR_PTR(-EEXIST);
+   if (old[nr_probes].func == tp_stub_func)
+   stub_funcs++;
}
}
-   /* + 2 : one for new probe, one for NULL func */
-   new = allocate_probes(nr_probes + 2);
+   /* + 2 : one for new probe, one for NULL func - stub functions */
+   new = allocate_probes(nr_probes + 2 - stub_funcs);
if (new == NULL)
return ERR_PTR(-ENOMEM);
if (old) {
-   if (pos < 0) {
+   if (stub_funcs) {
+   /* Need to copy one at a time to remove stubs */
+   int probes = 0;
+
+   pos = -1;
+   for (nr_probes = 0; old[nr_probes].func; nr_probes++) {
+   if (old[nr_probes].func == tp_stub_func)
+   continue;
+   if (pos < 0 && old[nr_probes].prio < prio)
+   pos = probes++;
+   new[probes++] = old[nr_probes];
+   }
+   nr_probes = probes;
+   if (pos < 0)
+   pos = probes;
+   else
+   nr_probes--; /* Account for insertion */
+
+   } else if (pos < 0) {
pos = nr_probes;

[PATCH 5.11 407/775] IB/mlx5: Return appropriate error code instead of ENOMEM

2021-03-01 Thread Greg Kroah-Hartman
From: Parav Pandit 

[ Upstream commit d286ac1d05210695c312b9018b3aa7c2048e9aca ]

When mlx5_ib_stage_init_init() fails, return the error code related to
failure instead of -ENOMEM.

Fixes: 16c1975f1032 ("IB/mlx5: Create profile infrastructure to add and remove 
stages")
Link: https://lore.kernel.org/r/20210127150010.1876121-8-l...@kernel.org
Signed-off-by: Parav Pandit 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/hw/mlx5/main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/infiniband/hw/mlx5/main.c 
b/drivers/infiniband/hw/mlx5/main.c
index 9b772457286f2..3562e69eacb14 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -3995,8 +3995,7 @@ static int mlx5_ib_stage_init_init(struct mlx5_ib_dev 
*dev)
 
 err_mp:
mlx5_ib_cleanup_multiport_master(dev);
-
-   return -ENOMEM;
+   return err;
 }
 
 static int mlx5_ib_enable_driver(struct ib_device *dev)
-- 
2.27.0





[PATCH 5.11 396/775] mmc: owl-mmc: Fix a resource leak in an error handling path and in the remove function

2021-03-01 Thread Greg Kroah-Hartman
From: Christophe JAILLET 

[ Upstream commit 5d15cbf63515c6183d2ed7c9dd0586b4db23ffb1 ]

'dma_request_chan()' calls should be balanced by a corresponding
'dma_release_channel()' call.

Add the missing call both in the error handling path of the probe function
and in the remove function.

Fixes: ff65ffe46d28 ("mmc: Add Actions Semi Owl SoCs SD/MMC driver")
Signed-off-by: Christophe JAILLET 
Link: 
https://lore.kernel.org/r/20201209194202.54099-1-christophe.jail...@wanadoo.fr
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin 
---
 drivers/mmc/host/owl-mmc.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/owl-mmc.c b/drivers/mmc/host/owl-mmc.c
index 53b81582f1afe..5490962dc8e53 100644
--- a/drivers/mmc/host/owl-mmc.c
+++ b/drivers/mmc/host/owl-mmc.c
@@ -640,7 +640,7 @@ static int owl_mmc_probe(struct platform_device *pdev)
owl_host->irq = platform_get_irq(pdev, 0);
if (owl_host->irq < 0) {
ret = -EINVAL;
-   goto err_free_host;
+   goto err_release_channel;
}
 
ret = devm_request_irq(>dev, owl_host->irq, owl_irq_handler,
@@ -648,19 +648,21 @@ static int owl_mmc_probe(struct platform_device *pdev)
if (ret) {
dev_err(>dev, "Failed to request irq %d\n",
owl_host->irq);
-   goto err_free_host;
+   goto err_release_channel;
}
 
ret = mmc_add_host(mmc);
if (ret) {
dev_err(>dev, "Failed to add host\n");
-   goto err_free_host;
+   goto err_release_channel;
}
 
dev_dbg(>dev, "Owl MMC Controller Initialized\n");
 
return 0;
 
+err_release_channel:
+   dma_release_channel(owl_host->dma);
 err_free_host:
mmc_free_host(mmc);
 
@@ -674,6 +676,7 @@ static int owl_mmc_remove(struct platform_device *pdev)
 
mmc_remove_host(mmc);
disable_irq(owl_host->irq);
+   dma_release_channel(owl_host->dma);
mmc_free_host(mmc);
 
return 0;
-- 
2.27.0





[PATCH 5.11 406/775] iommu: Properly pass gfp_t in _iommu_map() to avoid atomic sleeping

2021-03-01 Thread Greg Kroah-Hartman
From: Douglas Anderson 

[ Upstream commit b8437a3ef8c485903d05d1f261328aaf0c0a6cc2 ]

Sleeping while atomic = bad.  Let's fix an obvious typo to try to avoid it.

The warning that was seen (on a downstream kernel with the problematic
patch backported):

 BUG: sleeping function called from invalid context at mm/page_alloc.c:4726
 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 9, name: ksoftirqd/0
 CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 5.4.93-12508-gc10c93e28e39 #1
 Call trace:
  dump_backtrace+0x0/0x154
  show_stack+0x20/0x2c
  dump_stack+0xa0/0xfc
  ___might_sleep+0x11c/0x12c
  __might_sleep+0x50/0x84
  __alloc_pages_nodemask+0xf8/0x2bc
  __arm_lpae_alloc_pages+0x48/0x1b4
  __arm_lpae_map+0x124/0x274
  __arm_lpae_map+0x1cc/0x274
  arm_lpae_map+0x140/0x170
  arm_smmu_map+0x78/0xbc
  __iommu_map+0xd4/0x210
  _iommu_map+0x4c/0x84
  iommu_map_atomic+0x44/0x58
  __iommu_dma_map+0x8c/0xc4
  iommu_dma_map_page+0xac/0xf0

Fixes: d8c1df02ac7f ("iommu: Move iotlb_sync_map out from __iommu_map")
Signed-off-by: Douglas Anderson 
Reviewed-by: Yong Wu 
Acked-by: Will Deacon 
Link: 
https://lore.kernel.org/r/20210201170611.1.I64a7b62579287d668d7c89e105dcedf45d641063@changeid
Signed-off-by: Joerg Roedel 
Signed-off-by: Sasha Levin 
---
 drivers/iommu/iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index c304a6a30d42e..fd5f59373fc62 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2441,7 +2441,7 @@ static int _iommu_map(struct iommu_domain *domain, 
unsigned long iova,
const struct iommu_ops *ops = domain->ops;
int ret;
 
-   ret = __iommu_map(domain, iova, paddr, size, prot, GFP_KERNEL);
+   ret = __iommu_map(domain, iova, paddr, size, prot, gfp);
if (ret == 0 && ops->iotlb_sync_map)
ops->iotlb_sync_map(domain);
 
-- 
2.27.0





[PATCH 5.11 405/775] iommu: Move iotlb_sync_map out from __iommu_map

2021-03-01 Thread Greg Kroah-Hartman
From: Yong Wu 

[ Upstream commit d8c1df02ac7f2c802a9b2afc0f5c888c4217f1d5 ]

In the end of __iommu_map, It alway call iotlb_sync_map.

This patch moves iotlb_sync_map out from __iommu_map since it is
unnecessary to call this for each sg segment especially iotlb_sync_map
is flush tlb all currently. Add a little helper _iommu_map for this.

Signed-off-by: Yong Wu 
Reviewed-by: Robin Murphy 
Acked-by: Will Deacon 
Link: https://lore.kernel.org/r/20210107122909.16317-2-yong...@mediatek.com
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin 
---
 drivers/iommu/iommu.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index ffeebda8d6def..c304a6a30d42e 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2426,9 +2426,6 @@ static int __iommu_map(struct iommu_domain *domain, 
unsigned long iova,
size -= pgsize;
}
 
-   if (ops->iotlb_sync_map)
-   ops->iotlb_sync_map(domain);
-
/* unroll mapping in case something went wrong */
if (ret)
iommu_unmap(domain, orig_iova, orig_size - size);
@@ -2438,18 +2435,31 @@ static int __iommu_map(struct iommu_domain *domain, 
unsigned long iova,
return ret;
 }
 
+static int _iommu_map(struct iommu_domain *domain, unsigned long iova,
+ phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
+{
+   const struct iommu_ops *ops = domain->ops;
+   int ret;
+
+   ret = __iommu_map(domain, iova, paddr, size, prot, GFP_KERNEL);
+   if (ret == 0 && ops->iotlb_sync_map)
+   ops->iotlb_sync_map(domain);
+
+   return ret;
+}
+
 int iommu_map(struct iommu_domain *domain, unsigned long iova,
  phys_addr_t paddr, size_t size, int prot)
 {
might_sleep();
-   return __iommu_map(domain, iova, paddr, size, prot, GFP_KERNEL);
+   return _iommu_map(domain, iova, paddr, size, prot, GFP_KERNEL);
 }
 EXPORT_SYMBOL_GPL(iommu_map);
 
 int iommu_map_atomic(struct iommu_domain *domain, unsigned long iova,
  phys_addr_t paddr, size_t size, int prot)
 {
-   return __iommu_map(domain, iova, paddr, size, prot, GFP_ATOMIC);
+   return _iommu_map(domain, iova, paddr, size, prot, GFP_ATOMIC);
 }
 EXPORT_SYMBOL_GPL(iommu_map_atomic);
 
@@ -2533,6 +2543,7 @@ static size_t __iommu_map_sg(struct iommu_domain *domain, 
unsigned long iova,
 struct scatterlist *sg, unsigned int nents, int 
prot,
 gfp_t gfp)
 {
+   const struct iommu_ops *ops = domain->ops;
size_t len = 0, mapped = 0;
phys_addr_t start;
unsigned int i = 0;
@@ -2563,6 +2574,8 @@ static size_t __iommu_map_sg(struct iommu_domain *domain, 
unsigned long iova,
sg = sg_next(sg);
}
 
+   if (ops->iotlb_sync_map)
+   ops->iotlb_sync_map(domain);
return mapped;
 
 out_err:
-- 
2.27.0





[PATCH 5.11 408/775] IB/cm: Avoid a loop when device has 255 ports

2021-03-01 Thread Greg Kroah-Hartman
From: Parav Pandit 

[ Upstream commit 131be26750379592f0dd6244b2a90bbb504a10bb ]

When RDMA device has 255 ports, loop iterator i overflows.  Due to which
cm_add_one() port iterator loops infinitely.  Use core provided port
iterator to avoid the infinite loop.

Fixes: a977049dacde ("[PATCH] IB: Add the kernel CM implementation")
Link: https://lore.kernel.org/r/20210127150010.1876121-9-l...@kernel.org
Signed-off-by: Mark Bloch 
Signed-off-by: Parav Pandit 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/core/cm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index 98165589c8ab6..be996dba040cc 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -4333,7 +4333,7 @@ static int cm_add_one(struct ib_device *ib_device)
unsigned long flags;
int ret;
int count = 0;
-   u8 i;
+   unsigned int i;
 
cm_dev = kzalloc(struct_size(cm_dev, port, ib_device->phys_port_cnt),
 GFP_KERNEL);
@@ -4345,7 +4345,7 @@ static int cm_add_one(struct ib_device *ib_device)
cm_dev->going_down = 0;
 
set_bit(IB_MGMT_METHOD_SEND, reg_req.method_mask);
-   for (i = 1; i <= ib_device->phys_port_cnt; i++) {
+   rdma_for_each_port (ib_device, i) {
if (!rdma_cap_ib_cm(ib_device, i))
continue;
 
@@ -4431,7 +4431,7 @@ static void cm_remove_one(struct ib_device *ib_device, 
void *client_data)
.clr_port_cap_mask = IB_PORT_CM_SUP
};
unsigned long flags;
-   int i;
+   unsigned int i;
 
write_lock_irqsave(_lock, flags);
list_del(_dev->list);
@@ -4441,7 +4441,7 @@ static void cm_remove_one(struct ib_device *ib_device, 
void *client_data)
cm_dev->going_down = 1;
spin_unlock_irq();
 
-   for (i = 1; i <= ib_device->phys_port_cnt; i++) {
+   rdma_for_each_port (ib_device, i) {
if (!rdma_cap_ib_cm(ib_device, i))
continue;
 
-- 
2.27.0





[PATCH 5.11 363/775] certs: Fix blacklist flag type confusion

2021-03-01 Thread Greg Kroah-Hartman
From: David Howells 

[ Upstream commit 4993e1f9479a4161fd7d93e2b8b30b438f00cb0f ]

KEY_FLAG_KEEP is not meant to be passed to keyring_alloc() or key_alloc(),
as these only take KEY_ALLOC_* flags.  KEY_FLAG_KEEP has the same value as
KEY_ALLOC_BYPASS_RESTRICTION, but fortunately only key_create_or_update()
uses it.  LSMs using the key_alloc hook don't check that flag.

KEY_FLAG_KEEP is then ignored but fortunately (again) the root user cannot
write to the blacklist keyring, so it is not possible to remove a key/hash
from it.

Fix this by adding a KEY_ALLOC_SET_KEEP flag that tells key_alloc() to set
KEY_FLAG_KEEP on the new key.  blacklist_init() can then, correctly, pass
this to keyring_alloc().

We can also use this in ima_mok_init() rather than setting the flag
manually.

Note that this doesn't fix an observable bug with the current
implementation but it is required to allow addition of new hashes to the
blacklist in the future without making it possible for them to be removed.

Fixes: 734114f8782f ("KEYS: Add a system blacklist keyring")
Reported-by: Mickaël Salaün 
Signed-off-by: David Howells 
cc: Mickaël Salaün 
cc: Mimi Zohar 
Cc: David Woodhouse 
Signed-off-by: Sasha Levin 
---
 certs/blacklist.c| 2 +-
 include/linux/key.h  | 1 +
 security/integrity/ima/ima_mok.c | 5 ++---
 security/keys/key.c  | 2 ++
 4 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/certs/blacklist.c b/certs/blacklist.c
index 6514f9ebc943f..f1c434b04b5e4 100644
--- a/certs/blacklist.c
+++ b/certs/blacklist.c
@@ -162,7 +162,7 @@ static int __init blacklist_init(void)
  KEY_USR_VIEW | KEY_USR_READ |
  KEY_USR_SEARCH,
  KEY_ALLOC_NOT_IN_QUOTA |
- KEY_FLAG_KEEP,
+ KEY_ALLOC_SET_KEEP,
  NULL, NULL);
if (IS_ERR(blacklist_keyring))
panic("Can't allocate system blacklist keyring\n");
diff --git a/include/linux/key.h b/include/linux/key.h
index 0f2e24f13c2bd..eed3ce139a32e 100644
--- a/include/linux/key.h
+++ b/include/linux/key.h
@@ -289,6 +289,7 @@ extern struct key *key_alloc(struct key_type *type,
 #define KEY_ALLOC_BUILT_IN 0x0004  /* Key is built into kernel */
 #define KEY_ALLOC_BYPASS_RESTRICTION   0x0008  /* Override the check on 
restricted keyrings */
 #define KEY_ALLOC_UID_KEYRING  0x0010  /* allocating a user or user 
session keyring */
+#define KEY_ALLOC_SET_KEEP 0x0020  /* Set the KEEP flag on the 
key/keyring */
 
 extern void key_revoke(struct key *key);
 extern void key_invalidate(struct key *key);
diff --git a/security/integrity/ima/ima_mok.c b/security/integrity/ima/ima_mok.c
index 36cadadbfba47..1e5c019161738 100644
--- a/security/integrity/ima/ima_mok.c
+++ b/security/integrity/ima/ima_mok.c
@@ -38,13 +38,12 @@ __init int ima_mok_init(void)
(KEY_POS_ALL & ~KEY_POS_SETATTR) |
KEY_USR_VIEW | KEY_USR_READ |
KEY_USR_WRITE | KEY_USR_SEARCH,
-   KEY_ALLOC_NOT_IN_QUOTA,
+   KEY_ALLOC_NOT_IN_QUOTA |
+   KEY_ALLOC_SET_KEEP,
restriction, NULL);
 
if (IS_ERR(ima_blacklist_keyring))
panic("Can't allocate IMA blacklist keyring.");
-
-   set_bit(KEY_FLAG_KEEP, _blacklist_keyring->flags);
return 0;
 }
 device_initcall(ima_mok_init);
diff --git a/security/keys/key.c b/security/keys/key.c
index ebe752b137aa1..c45afdd1dfbb4 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -303,6 +303,8 @@ struct key *key_alloc(struct key_type *type, const char 
*desc,
key->flags |= 1 << KEY_FLAG_BUILTIN;
if (flags & KEY_ALLOC_UID_KEYRING)
key->flags |= 1 << KEY_FLAG_UID_KEYRING;
+   if (flags & KEY_ALLOC_SET_KEEP)
+   key->flags |= 1 << KEY_FLAG_KEEP;
 
 #ifdef KEY_DEBUGGING
key->magic = KEY_DEBUG_MAGIC;
-- 
2.27.0





[PATCH 5.11 372/775] scsi: isci: Pass gfp_t flags in isci_port_bc_change_received()

2021-03-01 Thread Greg Kroah-Hartman
From: Ahmed S. Darwish 

[ Upstream commit 71dca5539fcf977aead0c9ea1962e70e78484b8e ]

Use the new libsas event notifiers API, which requires callers to
explicitly pass the gfp_t memory allocation flags.

libsas sas_notify_port_event() is called from
isci_port_bc_change_received(). Below is the context analysis for all of
its call chains:

host.c: sci_controller_error_handler(): atomic, irq handler (*)
OR host.c: sci_controller_completion_handler(), atomic, tasklet (*)
  -> sci_controller_process_completions()
-> sci_controller_event_completion()
  -> phy.c: sci_phy_event_handler()
-> port.c: sci_port_broadcast_change_received()
  -> isci_port_bc_change_received()

host.c: isci_host_init()(@)
spin_lock_irq(isci_host::scic_lock)
  -> sci_controller_initialize(), atomic(*)
-> port_config.c: sci_port_configuration_agent_initialize()
  -> sci_mpc_agent_validate_phy_configuration()
-> port.c: sci_port_add_phy()
  -> sci_port_set_phy()
-> phy.c: sci_phy_set_port()
  -> port.c: sci_port_broadcast_change_received()
-> isci_port_bc_change_received()

port_config.c: apc_agent_timeout(), atomic, timer callback  (*)
  -> sci_apc_agent_configure_ports()
-> port.c: sci_port_add_phy()
  -> sci_port_set_phy()
-> phy.c: sci_phy_set_port()
  -> port.c: sci_port_broadcast_change_received()
-> isci_port_bc_change_received()

phy.c: enter SCI state: *SCI_PHY_STOPPED*   # Cont. from [1]
  -> sci_phy_stopped_state_enter()
-> host.c: sci_controller_link_down()
  -> ->link_down_handler()
  == port_config.c: sci_apc_agent_link_down()
-> port.c: sci_port_remove_phy()
  -> sci_port_clear_phy()
-> phy.c: sci_phy_set_port()
  -> port.c: sci_port_broadcast_change_received()
-> isci_port_bc_change_received()

phy.c: enter SCI state: *SCI_PHY_STARTING*  # Cont. from [2]
  -> sci_phy_starting_state_enter()
-> host.c: sci_controller_link_down()
  -> ->link_down_handler()
  == port_config.c: sci_apc_agent_link_down()
-> port.c: sci_port_remove_phy()
  -> sci_port_clear_phy()
-> phy.c: sci_phy_set_port()
  -> port.c: sci_port_broadcast_change_received()
-> isci_port_bc_change_received()

[1] Call chains for entering state: *SCI_PHY_STOPPED*
-

host.c: isci_host_init()(@)
spin_lock_irq(isci_host::scic_lock)
  -> sci_controller_initialize(), atomic(*)
  -> phy.c: sci_phy_initialize()
-> phy.c: sci_phy_link_layer_initialization()
  -> phy.c: sci_change_state(SCI_PHY_STOPPED)

init.c: PCI ->remove() || PM_OPS ->suspend,  process context(+)
  -> host.c: isci_host_deinit()
-> sci_controller_stop_phys()
  -> phy.c: sci_phy_stop()
-> sci_change_state(SCI_PHY_STOPPED)

phy.c: isci_phy_control()
spin_lock_irqsave(isci_host::scic_lock, )
  -> sci_phy_stop(), atomic (*)
-> sci_change_state(SCI_PHY_STOPPED)

[2] Call chains for entering state: *SCI_PHY_STARTING*
--

phy.c: phy_sata_timeout(), atimer, timer callback   (*)
spin_lock_irqsave(isci_host::scic_lock, )
  -> sci_change_state(SCI_PHY_STARTING)

host.c: phy_startup_timeout(), atomic, timer callback   (*)
spin_lock_irqsave(isci_host::scic_lock, )
  -> sci_controller_start_next_phy()
-> sci_phy_start()
  -> sci_change_state(SCI_PHY_STARTING)

host.c: isci_host_start()   (@)
spin_lock_irq(isci_host::scic_lock)
  -> sci_controller_start(), atomic (*)
-> sci_controller_start_next_phy()
  -> sci_phy_start()
-> sci_change_state(SCI_PHY_STARTING)

phy.c: Enter SCI state *SCI_PHY_SUB_FINAL*  # Cont. from 
[2A]
  -> sci_change_state(SCI_PHY_SUB_FINAL)
-> sci_phy_starting_final_substate_enter()
  -> sci_change_state(SCI_PHY_READY)
-> Enter SCI state: *SCI_PHY_READY*
  -> sci_phy_ready_state_enter()
-> host.c: sci_controller_link_up()
  -> sci_controller_start_next_phy()
-> sci_phy_start()
  -> sci_change_state(SCI_PHY_STARTING)

phy.c: sci_phy_event_handler(), atomic, discussed earlier   (*)
  -> sci_change_state(SCI_PHY_STARTING), 11 instances

port.c: isci_port_perform_hard_reset()
spin_lock_irqsave(isci_host::scic_lock, )
  -> port.c: sci_port_hard_reset(), atomic  (*)
-> phy.c: sci_phy_reset()
  -> sci_change_state(SCI_PHY_RESETTING)
-> enter SCI PHY state: *SCI_PHY_RESETTING*
  -> sci_phy_resetting_state_enter()
-> 

[PATCH 5.11 371/775] scsi: isci: Pass gfp_t flags in isci_port_link_up()

2021-03-01 Thread Greg Kroah-Hartman
From: Ahmed S. Darwish 

[ Upstream commit 5ce7902902adb8d154d67ba494f06daa29360ef0 ]

Use the new libsas event notifiers API, which requires callers to
explicitly pass the gfp_t memory allocation flags.

libsas sas_notify_port_event() is called from isci_port_link_up().  Below
is the context analysis for all of its call chains:

host.c: isci_host_init()(@)
spin_lock_irq(isci_host::scic_lock)
  -> sci_controller_initialize(), atomic(*)
-> port_config.c: sci_port_configuration_agent_initialize()
  -> sci_mpc_agent_validate_phy_configuration()
-> port.c: sci_port_add_phy()
  -> sci_port_general_link_up_handler()
-> sci_port_activate_phy()
  -> isci_port_link_up()

port_config.c: apc_agent_timeout(), atomic, timer callback  (*)
  -> sci_apc_agent_configure_ports()
-> port.c: sci_port_add_phy()
  -> sci_port_general_link_up_handler()
-> sci_port_activate_phy()
  -> isci_port_link_up()

phy.c: enter SCI state: *SCI_PHY_SUB_FINAL* # Cont. from [1]
  -> phy.c: sci_phy_starting_final_substate_enter()
-> phy.c: sci_change_state(SCI_PHY_READY)
  -> enter SCI state: *SCI_PHY_READY*
-> phy.c: sci_phy_ready_state_enter()
  -> host.c: sci_controller_link_up()
-> .link_up_handler()
== port_config.c: sci_apc_agent_link_up()
  -> port.c: sci_port_link_up()
-> (continue at [A])
== port_config.c: sci_mpc_agent_link_up()
  -> port.c: sci_port_link_up()
-> (continue at [A])

port_config.c: mpc_agent_timeout(), atomic, timer callback  (*)
spin_lock_irqsave(isci_host::scic_lock, )
  -> ->link_up_handler()
  == port_config.c: sci_apc_agent_link_up()
-> port.c: sci_port_link_up()
  -> (continue at [A])
  == port_config.c: sci_mpc_agent_link_up()
-> port.c: sci_port_link_up()
  -> (continue at [A])

[A] port.c: sci_port_link_up()
  -> sci_port_activate_phy()
-> isci_port_link_up()
  -> sci_port_general_link_up_handler()
-> sci_port_activate_phy()
  -> isci_port_link_up()

[1] Call chains for entering SCI state: *SCI_PHY_SUB_FINAL*
---

host.c: power_control_timeout(), atomic, timer callback (*)
spin_lock_irqsave(isci_host::scic_lock, )
  -> phy.c: sci_phy_consume_power_handler()
-> phy.c: sci_change_state(SCI_PHY_SUB_FINAL)

host.c: sci_controller_error_handler(): atomic, irq handler (*)
OR host.c: sci_controller_completion_handler(), atomic, tasklet (*)
  -> sci_controller_process_completions()
-> sci_controller_unsolicited_frame()
  -> phy.c: sci_phy_frame_handler()
-> sci_change_state(SCI_PHY_SUB_AWAIT_SAS_POWER)
  -> sci_phy_starting_await_sas_power_substate_enter()
-> host.c: sci_controller_power_control_queue_insert()
  -> phy.c: sci_phy_consume_power_handler()
-> sci_change_state(SCI_PHY_SUB_FINAL)
-> sci_change_state(SCI_PHY_SUB_FINAL)
-> sci_controller_event_completion()
  -> phy.c: sci_phy_event_handler()
-> sci_phy_start_sata_link_training()
  -> sci_change_state(SCI_PHY_SUB_AWAIT_SATA_POWER)
-> sci_phy_starting_await_sata_power_substate_enter
  -> host.c: sci_controller_power_control_queue_insert()
-> phy.c: sci_phy_consume_power_handler()
  -> sci_change_state(SCI_PHY_SUB_FINAL)

As can be seen from the "(*)" markers above, all the call-chains are
atomic.  Pass GFP_ATOMIC to libsas port event notifier.

Note, the now-replaced libsas APIs used in_interrupt() to implicitly decide
which memory allocation type to use.  This was only partially correct, as
it fails to choose the correct GFP flags when just preemption or interrupts
are disabled. Such buggy code paths are marked with "(@)" in the call
chains above.

Link: https://lore.kernel.org/r/20210118100955.1761652-7-a.darw...@linutronix.de
Fixes: 1c393b970e0f ("scsi: libsas: Use dynamic alloced work to avoid sas event 
lost")
Cc: Artur Paszkiewicz 
Reviewed-by: John Garry 
Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/isci/port.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/isci/port.c b/drivers/scsi/isci/port.c
index a3c58718c2600..10136ae466e20 100644
--- a/drivers/scsi/isci/port.c
+++ b/drivers/scsi/isci/port.c
@@ -223,7 +223,8 @@ static void isci_port_link_up(struct isci_host *isci_host,
/* Notify libsas that we have an address frame, if indeed
 * we've found an SSP, SMP, or STP target */
if (success)
-   sas_notify_port_event(>sas_phy, PORTE_BYTES_DMAED);
+   sas_notify_port_event_gfp(>sas_phy,
+ PORTE_BYTES_DMAED, GFP_ATOMIC);
 }
 
 
-- 
2.27.0





[PATCH 5.11 368/775] scsi: libsas: Introduce a _gfp() variant of event notifiers

2021-03-01 Thread Greg Kroah-Hartman
From: Ahmed S. Darwish 

[ Upstream commit c2d0f1a65ab9fbabebb463bf36f50ea8f4633386 ]

sas_alloc_event() uses in_interrupt() to decide which allocation should be
used.

The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be separated or the context be conveyed in an argument passed by the
caller, which usually knows the context.

The in_interrupt() check is also only partially correct, because it fails
to choose the correct code path when just preemption or interrupts are
disabled. For example, as in the following call chain:

  mvsas/mv_sas.c: mvs_work_queue() [process context]
  spin_lock_irqsave(mvs_info::lock, )
-> libsas/sas_event.c: sas_notify_phy_event()
  -> sas_alloc_event()
-> in_interrupt() = false
  -> invalid GFP_KERNEL allocation
-> libsas/sas_event.c: sas_notify_port_event()
  -> sas_alloc_event()
-> in_interrupt() = false
  -> invalid GFP_KERNEL allocation

Introduce sas_alloc_event_gfp(), sas_notify_port_event_gfp(), and
sas_notify_phy_event_gfp(), which all behave like the non _gfp() variants
but use a caller-passed GFP mask for allocations.

For bisectability, all callers will be modified first to pass GFP context,
then the non _gfp() libsas API variants will be modified to take a gfp_t by
default.

Link: https://lore.kernel.org/r/20210118100955.1761652-4-a.darw...@linutronix.de
Fixes: 1c393b970e0f ("scsi: libsas: Use dynamic alloced work to avoid sas event 
lost")
Cc: Jason Yan 
Reviewed-by: John Garry 
Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 Documentation/scsi/libsas.rst  |  2 +
 drivers/scsi/libsas/sas_event.c| 65 --
 drivers/scsi/libsas/sas_init.c | 21 +++---
 drivers/scsi/libsas/sas_internal.h |  4 ++
 include/scsi/libsas.h  |  4 ++
 5 files changed, 79 insertions(+), 17 deletions(-)

diff --git a/Documentation/scsi/libsas.rst b/Documentation/scsi/libsas.rst
index 210df1aba1409..de422253b0ab7 100644
--- a/Documentation/scsi/libsas.rst
+++ b/Documentation/scsi/libsas.rst
@@ -192,6 +192,8 @@ The event interface::
void (*notify_ha_event)(struct sas_ha_struct *, enum ha_event);
void sas_notify_port_event(struct sas_phy *, enum port_event);
void sas_notify_phy_event(struct sas_phy *, enum phy_event);
+   void sas_notify_port_event_gfp(struct sas_phy *, enum port_event, 
gfp_t);
+   void sas_notify_phy_event_gfp(struct sas_phy *, enum phy_event, gfp_t);
 
 The port notification::
 
diff --git a/drivers/scsi/libsas/sas_event.c b/drivers/scsi/libsas/sas_event.c
index 112a1b76f63b1..ba266a17250ae 100644
--- a/drivers/scsi/libsas/sas_event.c
+++ b/drivers/scsi/libsas/sas_event.c
@@ -131,18 +131,15 @@ static void sas_phy_event_worker(struct work_struct *work)
sas_free_event(ev);
 }
 
-int sas_notify_port_event(struct asd_sas_phy *phy, enum port_event event)
+static int __sas_notify_port_event(struct asd_sas_phy *phy,
+  enum port_event event,
+  struct asd_sas_event *ev)
 {
-   struct asd_sas_event *ev;
struct sas_ha_struct *ha = phy->ha;
int ret;
 
BUG_ON(event >= PORT_NUM_EVENTS);
 
-   ev = sas_alloc_event(phy);
-   if (!ev)
-   return -ENOMEM;
-
INIT_SAS_EVENT(ev, sas_port_event_worker, phy, event);
 
ret = sas_queue_event(event, >work, ha);
@@ -151,20 +148,41 @@ int sas_notify_port_event(struct asd_sas_phy *phy, enum 
port_event event)
 
return ret;
 }
-EXPORT_SYMBOL_GPL(sas_notify_port_event);
 
-int sas_notify_phy_event(struct asd_sas_phy *phy, enum phy_event event)
+int sas_notify_port_event_gfp(struct asd_sas_phy *phy, enum port_event event,
+ gfp_t gfp_flags)
 {
struct asd_sas_event *ev;
-   struct sas_ha_struct *ha = phy->ha;
-   int ret;
 
-   BUG_ON(event >= PHY_NUM_EVENTS);
+   ev = sas_alloc_event_gfp(phy, gfp_flags);
+   if (!ev)
+   return -ENOMEM;
+
+   return __sas_notify_port_event(phy, event, ev);
+}
+EXPORT_SYMBOL_GPL(sas_notify_port_event_gfp);
+
+int sas_notify_port_event(struct asd_sas_phy *phy, enum port_event event)
+{
+   struct asd_sas_event *ev;
 
ev = sas_alloc_event(phy);
if (!ev)
return -ENOMEM;
 
+   return __sas_notify_port_event(phy, event, ev);
+}
+EXPORT_SYMBOL_GPL(sas_notify_port_event);
+
+static inline int __sas_notify_phy_event(struct asd_sas_phy *phy,
+enum phy_event event,
+struct asd_sas_event *ev)
+{
+   struct sas_ha_struct *ha = phy->ha;
+   int ret;
+
+   BUG_ON(event >= PHY_NUM_EVENTS);
+
INIT_SAS_EVENT(ev, sas_phy_event_worker, phy, event);
 
ret = sas_queue_event(event, >work, ha);
@@ -173,5 

[PATCH 5.11 369/775] scsi: mvsas: Pass gfp_t flags to libsas event notifiers

2021-03-01 Thread Greg Kroah-Hartman
From: Ahmed S. Darwish 

[ Upstream commit feb18e900f0048001ff375dca639eaa327ab3c1b ]

mvsas calls the non _gfp version of the libsas event notifiers API, leading
to the buggy call chains below:

  mvsas/mv_sas.c: mvs_work_queue() [process context]
  spin_lock_irqsave(mvs_info::lock, )
-> libsas/sas_event.c: sas_notify_phy_event()
  -> sas_alloc_event()
-> in_interrupt() = false
  -> invalid GFP_KERNEL allocation
-> libsas/sas_event.c: sas_notify_port_event()
  -> sas_alloc_event()
-> in_interrupt() = false
  -> invalid GFP_KERNEL allocation

Use the new event notifiers API instead, which requires callers to
explicitly pass the gfp_t memory allocation flags.

Below are context analysis for the modified functions:

=> mvs_bytes_dmaed():

Since it is invoked from both process and atomic contexts, let its callers
pass the gfp_t flags. Call chains:

  scsi_scan.c: do_scsi_scan_host() [has msleep()]
-> shost->hostt->scan_start()
-> [mvsas/mv_init.c: Scsi_Host::scsi_host_template .scan_start = 
mvs_scan_start()]
-> mvsas/mv_sas.c: mvs_scan_start()
  -> mvs_bytes_dmaed(..., GFP_KERNEL)

  mvsas/mv_sas.c: mvs_work_queue()
  spin_lock_irqsave(mvs_info::lock,)
-> mvs_bytes_dmaed(..., GFP_ATOMIC)

  mvsas/mv_64xx.c: mvs_64xx_isr() || mvsas/mv_94xx.c: mvs_94xx_isr()
-> mvsas/mv_chips.h: mvs_int_full()
  -> mvsas/mv_sas.c: mvs_int_port()
-> mvs_bytes_dmaed(..., GFP_ATOMIC);

=> mvs_work_queue():

Invoked from process context, but it calls all the libsas event notifier
APIs under a spin_lock_irqsave(). Pass GFP_ATOMIC.

Link: https://lore.kernel.org/r/20210118100955.1761652-5-a.darw...@linutronix.de
Fixes: 1c393b970e0f ("scsi: libsas: Use dynamic alloced work to avoid sas event 
lost")
Cc: Jason Yan 
Reviewed-by: John Garry 
Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/mvsas/mv_sas.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/mvsas/mv_sas.c b/drivers/scsi/mvsas/mv_sas.c
index e5e3e95f78b0c..484e01428da28 100644
--- a/drivers/scsi/mvsas/mv_sas.c
+++ b/drivers/scsi/mvsas/mv_sas.c
@@ -216,7 +216,7 @@ void mvs_set_sas_addr(struct mvs_info *mvi, int port_id, 
u32 off_lo,
MVS_CHIP_DISP->write_port_cfg_data(mvi, port_id, hi);
 }
 
-static void mvs_bytes_dmaed(struct mvs_info *mvi, int i)
+static void mvs_bytes_dmaed(struct mvs_info *mvi, int i, gfp_t gfp_flags)
 {
struct mvs_phy *phy = >phy[i];
struct asd_sas_phy *sas_phy = >sas_phy;
@@ -229,7 +229,7 @@ static void mvs_bytes_dmaed(struct mvs_info *mvi, int i)
return;
}
 
-   sas_notify_phy_event(sas_phy, PHYE_OOB_DONE);
+   sas_notify_phy_event_gfp(sas_phy, PHYE_OOB_DONE, gfp_flags);
 
if (sas_phy->phy) {
struct sas_phy *sphy = sas_phy->phy;
@@ -261,7 +261,7 @@ static void mvs_bytes_dmaed(struct mvs_info *mvi, int i)
 
sas_phy->frame_rcvd_size = phy->frame_rcvd_size;
 
-   sas_notify_port_event(sas_phy, PORTE_BYTES_DMAED);
+   sas_notify_port_event_gfp(sas_phy, PORTE_BYTES_DMAED, gfp_flags);
 }
 
 void mvs_scan_start(struct Scsi_Host *shost)
@@ -277,7 +277,7 @@ void mvs_scan_start(struct Scsi_Host *shost)
for (j = 0; j < core_nr; j++) {
mvi = ((struct mvs_prv_info *)sha->lldd_ha)->mvi[j];
for (i = 0; i < mvi->chip->n_phy; ++i)
-   mvs_bytes_dmaed(mvi, i);
+   mvs_bytes_dmaed(mvi, i, GFP_KERNEL);
}
mvs_prv->scan_finished = 1;
 }
@@ -1892,20 +1892,21 @@ static void mvs_work_queue(struct work_struct *work)
if (!(tmp & PHY_READY_MASK)) {
sas_phy_disconnected(sas_phy);
mvs_phy_disconnected(phy);
-   sas_notify_phy_event(sas_phy,
-   PHYE_LOSS_OF_SIGNAL);
+   sas_notify_phy_event_gfp(sas_phy,
+   PHYE_LOSS_OF_SIGNAL, GFP_ATOMIC);
mv_dprintk("phy%d Removed Device\n", phy_no);
} else {
MVS_CHIP_DISP->detect_porttype(mvi, phy_no);
mvs_update_phyinfo(mvi, phy_no, 1);
-   mvs_bytes_dmaed(mvi, phy_no);
+   mvs_bytes_dmaed(mvi, phy_no, GFP_ATOMIC);
mvs_port_notify_formed(sas_phy, 0);
mv_dprintk("phy%d Attached Device\n", phy_no);
}
}
} else if (mwq->handler & EXP_BRCT_CHG) {
phy->phy_event &= ~EXP_BRCT_CHG;
-   sas_notify_port_event(sas_phy, PORTE_BROADCAST_RCVD);
+   sas_notify_port_event_gfp(sas_phy,
+   PORTE_BROADCAST_RCVD, 

[PATCH 5.11 370/775] scsi: isci: Pass gfp_t flags in isci_port_link_down()

2021-03-01 Thread Greg Kroah-Hartman
From: Ahmed S. Darwish 

[ Upstream commit 885ab3b8926fdf9cdd7163dfad99deb9b0662b39 ]

Use the new libsas event notifiers API, which requires callers to
explicitly pass the gfp_t memory allocation flags.

sas_notify_phy_event() is exclusively called by isci_port_link_down().
Below is the context analysis for all of its call chains:

port.c: port_timeout(), atomic, timer callback  (*)
spin_lock_irqsave(isci_host::scic_lock, )
  -> port_state_machine_change(..., SCI_PORT_FAILED)
-> enter SCI port state: *SCI_PORT_FAILED*
  -> sci_port_failed_state_enter()
-> isci_port_hard_reset_complete()
  -> isci_port_link_down()

port.c: isci_port_perform_hard_reset()
spin_lock_irqsave(isci_host::scic_lock, )
  -> port.c: sci_port_hard_reset(), atomic  (*)
-> phy.c: sci_phy_reset()
  -> sci_change_state(SCI_PHY_RESETTING)
-> enter SCI PHY state: *SCI_PHY_RESETTING*
  -> sci_phy_resetting_state_enter()
-> port.c: sci_port_deactivate_phy()
  -> isci_port_link_down()

port.c: enter SCI port state: *SCI_PORT_READY*  # Cont. from [1]
  -> sci_port_ready_state_enter()
-> isci_port_hard_reset_complete()
  -> isci_port_link_down()

phy.c: enter SCI state: *SCI_PHY_STOPPED*   # Cont. from [2]
  -> sci_phy_stopped_state_enter()
-> host.c: sci_controller_link_down()
  -> ->link_down_handler()
  == port_config.c: sci_apc_agent_link_down()
-> port.c: sci_port_remove_phy()
  -> sci_port_deactivate_phy()
-> isci_port_link_down()
  == port_config.c: sci_mpc_agent_link_down()
-> port.c: sci_port_link_down()
  -> sci_port_deactivate_phy()
-> isci_port_link_down()

phy.c: enter SCI state: *SCI_PHY_STARTING*  # Cont. from [3]
  -> sci_phy_starting_state_enter()
-> host.c: sci_controller_link_down()
  -> ->link_down_handler()
  == port_config.c: sci_apc_agent_link_down()
-> port.c: sci_port_remove_phy()
  -> isci_port_link_down()
  == port_config.c: sci_mpc_agent_link_down()
-> port.c: sci_port_link_down()
  -> sci_port_deactivate_phy()
-> isci_port_link_down()

[1] Call chains for 'enter SCI port state: *SCI_PORT_READY*'


host.c: isci_host_init()(@)
spin_lock_irq(isci_host::scic_lock)
  -> sci_controller_initialize(), atomic(*)
-> port_config.c: sci_port_configuration_agent_initialize()
  -> sci_mpc_agent_validate_phy_configuration()
-> port.c: sci_port_add_phy()
  -> sci_port_general_link_up_handler()
-> port_state_machine_change(, SCI_PORT_READY)
  -> enter port state *SCI_PORT_READY*

host.c: isci_host_start()   (@)
spin_lock_irq(isci_host::scic_lock)
  -> host.c: sci_controller_start(), atomic (*)
-> host.c: sci_port_start()
  -> port.c: port_state_machine_change(, SCI_PORT_READY)
-> enter port state *SCI_PORT_READY*

port_config.c: apc_agent_timeout(), atomic, timer callback  (*)
  -> sci_apc_agent_configure_ports()
-> port.c: sci_port_add_phy()
  -> sci_port_general_link_up_handler()
-> port_state_machine_change(, SCI_PORT_READY)
  -> enter port state *SCI_PORT_READY*

port_config.c: mpc_agent_timeout(), atomic, timer callback  (*)
spin_lock_irqsave(isci_host::scic_lock, )
  -> ->link_up_handler()
  == port.c: sci_apc_agent_link_up()
-> sci_port_general_link_up_handler()
  -> port_state_machine_change(, SCI_PORT_READY)
-> enter port state *SCI_PORT_READY*
  == port.c: sci_mpc_agent_link_up()
-> port.c: sci_port_link_up()
  -> sci_port_general_link_up_handler()
-> port_state_machine_change(, SCI_PORT_READY)
  -> enter port state *SCI_PORT_READY*

phy.c: enter SCI state: SCI_PHY_SUB_FINAL   # Cont. from 
[1A]
  -> sci_phy_starting_final_substate_enter()
-> sci_change_state(SCI_PHY_READY)
  -> enter SCI state: *SCI_PHY_READY*
-> sci_phy_ready_state_enter()
  -> host.c: sci_controller_link_up()
-> port_agent.link_up_handler()
== port_config.c: sci_apc_agent_link_up()
  -> port.c: sci_port_link_up()
-> sci_port_general_link_up_handler()
  -> port_state_machine_change(, SCI_PORT_READY)
-> enter port state *SCI_PORT_READY*
== port_config.c: sci_mpc_agent_link_up()
  -> port.c: sci_port_link_up()
-> sci_port_general_link_up_handler()
  -> port_state_machine_change(, SCI_PORT_READY)
-> enter port state *SCI_PORT_READY*

[1A] Call chains for entering SCI state: *SCI_PHY_SUB_FINAL*

Re: [PATCH] can: c_can_pci: fix use-after-free

2021-03-01 Thread Marc Kleine-Budde
On 3/1/21 3:45 AM, Tong Zhang wrote:
> There is a UAF in c_can_pci_remove().
> dev is released by free_c_can_dev() and is used by
> pci_iounmap(pdev, priv->base) later.
> To fix this issue, save the mmio address before releasing dev.
> 
> [ 1795.746699] 
> ==
> [ 1795.747093] BUG: KASAN: use-after-free in c_can_pci_remove+0x34/0x70 
> [c_can_pci]
> [ 1795.747503] Read of size 8 at addr 888103db0be8 by task modprobe/98
> [ 1795.747867]
> [ 1795.747957] CPU: 0 PID: 98 Comm: modprobe Not tainted 
> 5.11.0-11746-g06d5d309a3f1-dirty #56
> [ 1795.748410] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
> rel-1.13.0-48-gd9c812dda519-4
> [ 1795.749025] Call Trace:
> [ 1795.749176]  dump_stack+0x8a/0xb5
> [ 1795.749385]  print_address_description.constprop.0+0x1a/0x140
> [ 1795.749713]  ? c_can_pci_remove+0x34/0x70 [c_can_pci]
> [ 1795.750001]  ? c_can_pci_remove+0x34/0x70 [c_can_pci]
> [ 1795.750285]  kasan_report.cold+0x7f/0x111
> [ 1795.750513]  ? c_can_pci_remove+0x34/0x70 [c_can_pci]
> [ 1795.750797]  c_can_pci_remove+0x34/0x70 [c_can_pci]
> [ 1795.751071]  pci_device_remove+0x62/0xe0
> [ 1795.751308]  device_release_driver_internal+0x148/0x270
> [ 1795.751609]  driver_detach+0x76/0xe0
> [ 1795.751812]  bus_remove_driver+0x7e/0x100
> [ 1795.752051]  pci_unregister_driver+0x28/0xf0
> [ 1795.752286]  __x64_sys_delete_module+0x268/0x300
> [ 1795.752547]  ? __ia32_sys_delete_module+0x300/0x300
> [ 1795.752815]  ? call_rcu+0x3e4/0x580
> [ 1795.753014]  ? fpregs_assert_state_consistent+0x4d/0x60
> [ 1795.753305]  ? exit_to_user_mode_prepare+0x2f/0x130
> [ 1795.753574]  do_syscall_64+0x33/0x40
> [ 1795.753782]  entry_SYSCALL_64_after_hwframe+0x44/0xae
> [ 1795.754060] RIP: 0033:0x7f02dcf7
> [ 1795.754257] Code: 48 89 57 30 48 8b 04 24 48 89 47 38 e9 1d a0 02 00 48 89 
> f8 48 89 f7 48 89 d6 41
> [ 1795.755248] RSP: 002b:7ffd06037208 EFLAGS: 0202 ORIG_RAX: 
> 00b0
> [ 1795.755655] RAX: ffda RBX: 7f0ab690 RCX: 
> 7f02dcf7
> [ 1795.756038] RDX:  RSI: 0080 RDI: 
> 00d20b10
> [ 1795.756420] RBP: 00d20ac0 R08: 2f2f2f2f2f2f2f2f R09: 
> 00d20ac0
> [ 1795.756801] R10: fefefefefefefeff R11: 0202 R12: 
> 00d20ac0
> [ 1795.757183] R13: 00d2abf0 R14:  R15: 
> 0001
> [ 1795.757565]
> [ 1795.757651] The buggy address belongs to the page:
> [ 1795.757912] page:(ptrval) refcount:0 mapcount:-128 
> mapping: index:0x0 pfn0
> [ 1795.758427] flags: 0x200()
> [ 1795.758633] raw: 0200 ea00040f7608 88817fffab18 
> 
> [ 1795.759047] raw:  0003 ff7f 
> 
> [ 1795.759460] page dumped because: kasan: bad access detected
> [ 1795.759759]
> [ 1795.759845] Memory state around the buggy address:
> [ 1795.760104]  888103db0a80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff
> [ 1795.760490]  888103db0b00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff
> [ 1795.760878] >888103db0b80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff
> [ 1795.761264]   ^
> [ 1795.761618]  888103db0c00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff
> [ 1795.762007]  888103db0c80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff
> [ 1795.762392] 
> ==

I've removed the kasan report, as your problem description is sufficient.

> 
> Signed-off-by: Tong Zhang 
> ---
>  drivers/net/can/c_can/c_can_pci.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/can/c_can/c_can_pci.c 
> b/drivers/net/can/c_can/c_can_pci.c
> index 406b4847e5dc..a378383a99fb 100644
> --- a/drivers/net/can/c_can/c_can_pci.c
> +++ b/drivers/net/can/c_can/c_can_pci.c
> @@ -239,12 +239,13 @@ static void c_can_pci_remove(struct pci_dev *pdev)
>  {
>   struct net_device *dev = pci_get_drvdata(pdev);
>   struct c_can_priv *priv = netdev_priv(dev);
> -
> + void __iomem *addr = priv->base;
> +  

Please don't add trailing whitespace.

I've removed them while applying.

Marc

-- 
Pengutronix e.K. | Marc Kleine-Budde   |
Embedded Linux   | https://www.pengutronix.de  |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917- |



signature.asc
Description: OpenPGP digital signature


[PATCH 5.10 411/663] drm/msm: Fix race of GPU init vs timestamp power management.

2021-03-01 Thread Greg Kroah-Hartman
From: Eric Anholt 

[ Upstream commit 7a7cbf2a819740674455ad36155c662367261296 ]

We were using the same force-poweron bit in the two codepaths, so they
could race to have one of them lose GPU power early.

freedreno CI was seeing intermittent errors like:
[drm:_a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set GPU_SET: 0x0
and this issue could have contributed to it.

Signed-off-by: Eric Anholt 
Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support")
Reviewed-by: Jordan Crouse 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 25 ++---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h |  8 
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c |  4 ++--
 3 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 491fee410dafe..8d78d95d29fcd 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -266,6 +266,16 @@ int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum 
a6xx_gmu_oob_state state)
}
name = "GPU_SET";
break;
+   case GMU_OOB_PERFCOUNTER_SET:
+   if (gmu->legacy) {
+   request = GMU_OOB_PERFCOUNTER_REQUEST;
+   ack = GMU_OOB_PERFCOUNTER_ACK;
+   } else {
+   request = GMU_OOB_PERFCOUNTER_REQUEST_NEW;
+   ack = GMU_OOB_PERFCOUNTER_ACK_NEW;
+   }
+   name = "PERFCOUNTER";
+   break;
case GMU_OOB_BOOT_SLUMBER:
request = GMU_OOB_BOOT_SLUMBER_REQUEST;
ack = GMU_OOB_BOOT_SLUMBER_ACK;
@@ -303,9 +313,14 @@ int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum 
a6xx_gmu_oob_state state)
 void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state)
 {
if (!gmu->legacy) {
-   WARN_ON(state != GMU_OOB_GPU_SET);
-   gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
-   1 << GMU_OOB_GPU_SET_CLEAR_NEW);
+   if (state == GMU_OOB_GPU_SET) {
+   gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
+   1 << GMU_OOB_GPU_SET_CLEAR_NEW);
+   } else {
+   WARN_ON(state != GMU_OOB_PERFCOUNTER_SET);
+   gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
+   1 << GMU_OOB_PERFCOUNTER_CLEAR_NEW);
+   }
return;
}
 
@@ -314,6 +329,10 @@ void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum 
a6xx_gmu_oob_state state)
gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
1 << GMU_OOB_GPU_SET_CLEAR);
break;
+   case GMU_OOB_PERFCOUNTER_SET:
+   gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
+   1 << GMU_OOB_PERFCOUNTER_CLEAR);
+   break;
case GMU_OOB_BOOT_SLUMBER:
gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
1 << GMU_OOB_BOOT_SLUMBER_CLEAR);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index c6d2bced8e5de..9fa278de2106a 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -156,6 +156,7 @@ enum a6xx_gmu_oob_state {
GMU_OOB_BOOT_SLUMBER = 0,
GMU_OOB_GPU_SET,
GMU_OOB_DCVS_SET,
+   GMU_OOB_PERFCOUNTER_SET,
 };
 
 /* These are the interrupt / ack bits for each OOB request that are set
@@ -190,6 +191,13 @@ enum a6xx_gmu_oob_state {
 #define GMU_OOB_GPU_SET_ACK_NEW31
 #define GMU_OOB_GPU_SET_CLEAR_NEW  31
 
+#define GMU_OOB_PERFCOUNTER_REQUEST17
+#define GMU_OOB_PERFCOUNTER_ACK25
+#define GMU_OOB_PERFCOUNTER_CLEAR  25
+
+#define GMU_OOB_PERFCOUNTER_REQUEST_NEW28
+#define GMU_OOB_PERFCOUNTER_ACK_NEW30
+#define GMU_OOB_PERFCOUNTER_CLEAR_NEW  30
 
 void a6xx_hfi_init(struct a6xx_gmu *gmu);
 int a6xx_hfi_start(struct a6xx_gmu *gmu, int boot_state);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 420ca4a0eb5f7..9fda02550d80d 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1068,12 +1068,12 @@ static int a6xx_get_timestamp(struct msm_gpu *gpu, 
uint64_t *value)
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
 
/* Force the GPU power on so we can read this register */
-   a6xx_gmu_set_oob(_gpu->gmu, GMU_OOB_GPU_SET);
+   a6xx_gmu_set_oob(_gpu->gmu, GMU_OOB_PERFCOUNTER_SET);
 
*value = gpu_read64(gpu, REG_A6XX_RBBM_PERFCTR_CP_0_LO,
REG_A6XX_RBBM_PERFCTR_CP_0_HI);
 
-   a6xx_gmu_clear_oob(_gpu->gmu, GMU_OOB_GPU_SET);
+   a6xx_gmu_clear_oob(_gpu->gmu, GMU_OOB_PERFCOUNTER_SET);
return 0;
 }
 
-- 
2.27.0





[PATCH 5.10 530/663] KEYS: trusted: Reserve TPM for seal and unseal operations

2021-03-01 Thread Greg Kroah-Hartman
From: Jarkko Sakkinen 

commit 8c657a0590de585b1115847c17b34a58025f2f4b upstream.

When TPM 2.0 trusted keys code was moved to the trusted keys subsystem,
the operations were unwrapped from tpm_try_get_ops() and tpm_put_ops(),
which are used to take temporarily the ownership of the TPM chip. The
ownership is only taken inside tpm_send(), but this is not sufficient,
as in the key load TPM2_CC_LOAD, TPM2_CC_UNSEAL and TPM2_FLUSH_CONTEXT
need to be done as a one single atom.

Take the TPM chip ownership before sending anything with
tpm_try_get_ops() and tpm_put_ops(), and use tpm_transmit_cmd() to send
TPM commands instead of tpm_send(), reverting back to the old behaviour.

Fixes: 2e19e10131a0 ("KEYS: trusted: Move TPM2 trusted keys code")
Reported-by: "James E.J. Bottomley" 
Cc: sta...@vger.kernel.org
Cc: David Howells 
Cc: Mimi Zohar 
Cc: Sumit Garg 
Acked-by Sumit Garg 
Tested-by: Mimi Zohar 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/char/tpm/tpm.h|4 
 include/linux/tpm.h   |5 -
 security/keys/trusted-keys/trusted_tpm2.c |   22 ++
 3 files changed, 22 insertions(+), 9 deletions(-)

--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -164,8 +164,6 @@ extern const struct file_operations tpmr
 extern struct idr dev_nums_idr;
 
 ssize_t tpm_transmit(struct tpm_chip *chip, u8 *buf, size_t bufsiz);
-ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_buf *buf,
-size_t min_rsp_body_length, const char *desc);
 int tpm_get_timeouts(struct tpm_chip *);
 int tpm_auto_startup(struct tpm_chip *chip);
 
@@ -194,8 +192,6 @@ static inline void tpm_msleep(unsigned i
 int tpm_chip_start(struct tpm_chip *chip);
 void tpm_chip_stop(struct tpm_chip *chip);
 struct tpm_chip *tpm_find_get_ops(struct tpm_chip *chip);
-__must_check int tpm_try_get_ops(struct tpm_chip *chip);
-void tpm_put_ops(struct tpm_chip *chip);
 
 struct tpm_chip *tpm_chip_alloc(struct device *dev,
const struct tpm_class_ops *ops);
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -397,6 +397,10 @@ static inline u32 tpm2_rc_value(u32 rc)
 #if defined(CONFIG_TCG_TPM) || defined(CONFIG_TCG_TPM_MODULE)
 
 extern int tpm_is_tpm2(struct tpm_chip *chip);
+extern __must_check int tpm_try_get_ops(struct tpm_chip *chip);
+extern void tpm_put_ops(struct tpm_chip *chip);
+extern ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_buf *buf,
+   size_t min_rsp_body_length, const char *desc);
 extern int tpm_pcr_read(struct tpm_chip *chip, u32 pcr_idx,
struct tpm_digest *digest);
 extern int tpm_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
@@ -410,7 +414,6 @@ static inline int tpm_is_tpm2(struct tpm
 {
return -ENODEV;
 }
-
 static inline int tpm_pcr_read(struct tpm_chip *chip, int pcr_idx,
   struct tpm_digest *digest)
 {
--- a/security/keys/trusted-keys/trusted_tpm2.c
+++ b/security/keys/trusted-keys/trusted_tpm2.c
@@ -83,6 +83,12 @@ int tpm2_seal_trusted(struct tpm_chip *c
if (rc)
return rc;
 
+   rc = tpm_buf_init(, TPM2_ST_SESSIONS, TPM2_CC_CREATE);
+   if (rc) {
+   tpm_put_ops(chip);
+   return rc;
+   }
+
tpm_buf_append_u32(, options->keyhandle);
tpm2_buf_append_auth(, TPM2_RS_PW,
 NULL /* nonce */, 0,
@@ -130,7 +136,7 @@ int tpm2_seal_trusted(struct tpm_chip *c
goto out;
}
 
-   rc = tpm_send(chip, buf.data, tpm_buf_length());
+   rc = tpm_transmit_cmd(chip, , 4, "sealing data");
if (rc)
goto out;
 
@@ -157,6 +163,7 @@ out:
rc = -EPERM;
}
 
+   tpm_put_ops(chip);
return rc;
 }
 
@@ -211,7 +218,7 @@ static int tpm2_load_cmd(struct tpm_chip
goto out;
}
 
-   rc = tpm_send(chip, buf.data, tpm_buf_length());
+   rc = tpm_transmit_cmd(chip, , 4, "loading blob");
if (!rc)
*blob_handle = be32_to_cpup(
(__be32 *) [TPM_HEADER_SIZE]);
@@ -260,7 +267,7 @@ static int tpm2_unseal_cmd(struct tpm_ch
 options->blobauth /* hmac */,
 TPM_DIGEST_SIZE);
 
-   rc = tpm_send(chip, buf.data, tpm_buf_length());
+   rc = tpm_transmit_cmd(chip, , 6, "unsealing");
if (rc > 0)
rc = -EPERM;
 
@@ -304,12 +311,19 @@ int tpm2_unseal_trusted(struct tpm_chip
u32 blob_handle;
int rc;
 
-   rc = tpm2_load_cmd(chip, payload, options, _handle);
+   rc = tpm_try_get_ops(chip);
if (rc)
return rc;
 
+   rc = tpm2_load_cmd(chip, payload, options, _handle);
+   if (rc)
+   goto out;
+
rc = tpm2_unseal_cmd(chip, payload, options, blob_handle);
tpm2_flush_context(chip, 

[PATCH 5.10 467/663] i2c: brcmstb: Fix brcmstd_send_i2c_cmd condition

2021-03-01 Thread Greg Kroah-Hartman
From: Maxime Ripard 

[ Upstream commit a1858ce0cfe31368b23ba55794e409fb57ced4a4 ]

The brcmstb_send_i2c_cmd currently has a condition that is (CMD_RD ||
CMD_WR) which always evaluates to true, while the obvious fix is to test
whether the cmd variable passed as parameter holds one of these two
values.

Fixes: dd1aa2524bc5 ("i2c: brcmstb: Add Broadcom settop SoC i2c controller 
driver")
Reported-by: Dave Stevenson 
Signed-off-by: Maxime Ripard 
Acked-by: Florian Fainelli 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
---
 drivers/i2c/busses/i2c-brcmstb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-brcmstb.c b/drivers/i2c/busses/i2c-brcmstb.c
index d4e0a0f6732ae..ba766d24219ef 100644
--- a/drivers/i2c/busses/i2c-brcmstb.c
+++ b/drivers/i2c/busses/i2c-brcmstb.c
@@ -316,7 +316,7 @@ static int brcmstb_send_i2c_cmd(struct brcmstb_i2c_dev *dev,
goto cmd_out;
}
 
-   if ((CMD_RD || CMD_WR) &&
+   if ((cmd == CMD_RD || cmd == CMD_WR) &&
bsc_readl(dev, iic_enable) & BSC_IIC_EN_NOACK_MASK) {
rc = -EREMOTEIO;
dev_dbg(dev->device, "controller received NOACK intr for %s\n",
-- 
2.27.0





[PATCH 5.11 152/775] arm64: dts: mt8183: rename rdma fifo size

2021-03-01 Thread Greg Kroah-Hartman
From: Yongqiang Niu 

[ Upstream commit 431368c2648b59e5485a1b5f1276a83d885fb44b ]

property name must include only lowercase and '-'

Fixes: 91f9c963ce79 ("arm64: dts: mt8183: Add display nodes for MT8183")
Signed-off-by: Yongqiang Niu 
Signed-off-by: Hsin-Yi Wang 
Reviewed-by: Chun-Kuang Hu 
Reviewed-by: Enric Balletbo i Serra 
Link: https://lore.kernel.org/r/20210128112314.1304160-2-hsi...@chromium.org
Signed-off-by: Matthias Brugger 
Signed-off-by: Sasha Levin 
---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 5b782a4769e7e..6c84ccb709af6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -1011,7 +1011,7 @@
clocks = < CLK_MM_DISP_RDMA0>;
iommus = < M4U_PORT_DISP_RDMA0>;
mediatek,larb = <>;
-   mediatek,rdma_fifo_size = <5120>;
+   mediatek,rdma-fifo-size = <5120>;
mediatek,gce-client-reg = < SUBSYS_1400 0xb000 
0x1000>;
};
 
@@ -1023,7 +1023,7 @@
clocks = < CLK_MM_DISP_RDMA1>;
iommus = < M4U_PORT_DISP_RDMA1>;
mediatek,larb = <>;
-   mediatek,rdma_fifo_size = <2048>;
+   mediatek,rdma-fifo-size = <2048>;
mediatek,gce-client-reg = < SUBSYS_1400 0xc000 
0x1000>;
};
 
-- 
2.27.0





[PATCH 5.11 391/775] powerpc/47x: Disable 256k page size

2021-03-01 Thread Greg Kroah-Hartman
From: Christophe Leroy 

[ Upstream commit 910a0cb6d259736a0c86e795d4c2f42af8d0d775 ]

PPC47x_TLBE_SIZE isn't defined for 256k pages, leading to a build
break if 256k pages is selected.

So change the kconfig so that 256k pages can't be selected for 47x.

Fixes: e7f75ad01d59 ("powerpc/47x: Base ppc476 support")
Reported-by: kernel test robot 
Signed-off-by: Christophe Leroy 
[mpe: Expand change log to mention build break]
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/2fed79b1154c872194f98bac4422c23918325e61.1611128938.git.christophe.le...@csgroup.eu
Signed-off-by: Sasha Levin 
---
 arch/powerpc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 107bb4319e0e0..a685e42d39932 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -772,7 +772,7 @@ config PPC_64K_PAGES
 
 config PPC_256K_PAGES
bool "256k page size"
-   depends on 44x && !STDBINUTILS
+   depends on 44x && !STDBINUTILS && !PPC_47x
help
  Make the page size 256k.
 
-- 
2.27.0





[PATCH 5.11 394/775] powerpc/time: Enable sched clock for irqtime

2021-03-01 Thread Greg Kroah-Hartman
From: Pingfan Liu 

[ Upstream commit b709e32ef570b8b91dfbcb63cffac4324c87799f ]

When CONFIG_IRQ_TIME_ACCOUNTING and CONFIG_VIRT_CPU_ACCOUNTING_GEN, powerpc
does not enable "sched_clock_irqtime" and can not utilize irq time
accounting.

Like x86, powerpc does not use the sched_clock_register() interface. So it
needs an dedicated call to enable_sched_clock_irqtime() to enable irq time
accounting.

Fixes: 518470fe962e ("powerpc: Add HAVE_IRQ_TIME_ACCOUNTING")
Signed-off-by: Pingfan Liu 
[mpe: Add fixes tag]
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/1603349479-26185-1-git-send-email-kernelf...@gmail.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/time.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 67feb35244606..83633a24ce788 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -53,6 +53,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1030,6 +1031,7 @@ void __init time_init(void)
tick_setup_hrtimer_broadcast();
 
of_clk_init(NULL);
+   enable_sched_clock_irqtime();
 }
 
 /*
-- 
2.27.0





[PATCH 5.11 393/775] powerpc/sstep: Fix incorrect return from analyze_instr()

2021-03-01 Thread Greg Kroah-Hartman
From: Ananth N Mavinakayanahalli 

[ Upstream commit 718aae916fa6619c57c348beaedd675835cf1aa1 ]

We currently just percolate the return value from analyze_instr()
to the caller of emulate_step(), especially if it is a -1.

For one particular case (opcode = 4) for instructions that aren't
currently emulated, we are returning 'should not be single-stepped'
while we should have returned 0 which says 'did not emulate, may
have to single-step'.

Fixes: 930d6288a26787 ("powerpc: sstep: Add support for maddhd, maddhdu, maddld 
instructions")
Signed-off-by: Ananth N Mavinakayanahalli 
Suggested-by: Michael Ellerman 
Tested-by: Naveen N. Rao 
Reviewed-by: Sandipan Das 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/161157999039.64773.14950289716779364766.stgit@thinktux.local
Signed-off-by: Sasha Levin 
---
 arch/powerpc/lib/sstep.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 5e725ed24d772..33935869e4976 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1447,6 +1447,11 @@ int analyse_instr(struct instruction_op *op, const 
struct pt_regs *regs,
 
 #ifdef __powerpc64__
case 4:
+   /*
+* There are very many instructions with this primary opcode
+* introduced in the ISA as early as v2.03. However, the ones
+* we currently emulate were all introduced with ISA 3.0
+*/
if (!cpu_has_feature(CPU_FTR_ARCH_300))
goto unknown_opcode;
 
@@ -1474,7 +1479,7 @@ int analyse_instr(struct instruction_op *op, const struct 
pt_regs *regs,
 * There are other instructions from ISA 3.0 with the same
 * primary opcode which do not have emulation support yet.
 */
-   return -1;
+   goto unknown_opcode;
 #endif
 
case 7: /* mulli */
-- 
2.27.0





[PATCH 5.11 392/775] powerpc/sstep: Check instruction validity against ISA version before emulation

2021-03-01 Thread Greg Kroah-Hartman
From: Ananth N Mavinakayanahalli 

[ Upstream commit 8813ff49607eab3caaf40fe8929b0ce7dc68e85f ]

We currently unconditionally try to emulate newer instructions on older
Power versions that could cause issues. Gate it.

Fixes: 350779a29f11 ("powerpc: Handle most loads and stores in instruction 
emulation code")
Signed-off-by: Ananth N Mavinakayanahalli 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/161157995977.64773.13794501093457185080.stgit@thinktux.local
Signed-off-by: Sasha Levin 
---
 arch/powerpc/lib/sstep.c | 78 +++-
 1 file changed, 62 insertions(+), 16 deletions(-)

diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index ede093e962347..5e725ed24d772 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1306,9 +1306,11 @@ int analyse_instr(struct instruction_op *op, const 
struct pt_regs *regs,
if ((word & 0xfe2) == 2)
op->type = SYSCALL;
else if (IS_ENABLED(CONFIG_PPC_BOOK3S_64) &&
-   (word & 0xfe3) == 1)
+   (word & 0xfe3) == 1) {  /* scv */
op->type = SYSCALL_VECTORED_0;
-   else
+   if (!cpu_has_feature(CPU_FTR_ARCH_300))
+   goto unknown_opcode;
+   } else
op->type = UNKNOWN;
return 0;
 #endif
@@ -1412,7 +1414,7 @@ int analyse_instr(struct instruction_op *op, const struct 
pt_regs *regs,
 #ifdef __powerpc64__
case 1:
if (!cpu_has_feature(CPU_FTR_ARCH_31))
-   return -1;
+   goto unknown_opcode;
 
prefix_r = GET_PREFIX_R(word);
ra = GET_PREFIX_RA(suffix);
@@ -1446,7 +1448,7 @@ int analyse_instr(struct instruction_op *op, const struct 
pt_regs *regs,
 #ifdef __powerpc64__
case 4:
if (!cpu_has_feature(CPU_FTR_ARCH_300))
-   return -1;
+   goto unknown_opcode;
 
switch (word & 0x3f) {
case 48:/* maddhd */
@@ -1532,6 +1534,8 @@ int analyse_instr(struct instruction_op *op, const struct 
pt_regs *regs,
case 19:
if (((word >> 1) & 0x1f) == 2) {
/* addpcis */
+   if (!cpu_has_feature(CPU_FTR_ARCH_300))
+   goto unknown_opcode;
imm = (short) (word & 0xffc1);  /* d0 + d2 fields */
imm |= (word >> 15) & 0x3e; /* d1 field */
op->val = regs->nip + (imm << 16) + 4;
@@ -1844,7 +1848,7 @@ int analyse_instr(struct instruction_op *op, const struct 
pt_regs *regs,
 #ifdef __powerpc64__
case 265:   /* modud */
if (!cpu_has_feature(CPU_FTR_ARCH_300))
-   return -1;
+   goto unknown_opcode;
op->val = regs->gpr[ra] % regs->gpr[rb];
goto compute_done;
 #endif
@@ -1854,7 +1858,7 @@ int analyse_instr(struct instruction_op *op, const struct 
pt_regs *regs,
 
case 267:   /* moduw */
if (!cpu_has_feature(CPU_FTR_ARCH_300))
-   return -1;
+   goto unknown_opcode;
op->val = (unsigned int) regs->gpr[ra] %
(unsigned int) regs->gpr[rb];
goto compute_done;
@@ -1891,7 +1895,7 @@ int analyse_instr(struct instruction_op *op, const struct 
pt_regs *regs,
 #endif
case 755:   /* darn */
if (!cpu_has_feature(CPU_FTR_ARCH_300))
-   return -1;
+   goto unknown_opcode;
switch (ra & 0x3) {
case 0:
/* 32-bit conditioned */
@@ -1913,14 +1917,14 @@ int analyse_instr(struct instruction_op *op, const 
struct pt_regs *regs,
 #ifdef __powerpc64__
case 777:   /* modsd */
if (!cpu_has_feature(CPU_FTR_ARCH_300))
-   return -1;
+   goto unknown_opcode;
op->val = (long int) regs->gpr[ra] %
(long int) regs->gpr[rb];
goto compute_done;
 #endif
case 779:   /* modsw */
if (!cpu_has_feature(CPU_FTR_ARCH_300))
-   return -1;
+   goto unknown_opcode;
op->val = (int) regs->gpr[ra] %
(int) regs->gpr[rb];
goto compute_done;
@@ -1997,14 +2001,14 @@ int analyse_instr(struct instruction_op *op, const 
struct 

[PATCH 5.11 366/775] regulator: s5m8767: Drop regulators OF node reference

2021-03-01 Thread Greg Kroah-Hartman
From: Krzysztof Kozlowski 

[ Upstream commit a5872bd3398d0ff2ce4c77794bc7837899c69024 ]

The device node reference obtained with of_get_child_by_name() should be
dropped on error paths.

Fixes: 26aec009f6b6 ("regulator: add device tree support for s5m8767")
Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20210121155914.48034-1-k...@kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 drivers/regulator/s5m8767.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index 48dd95b3ff45a..7c111bbdc2afa 100644
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@ -544,14 +544,18 @@ static int s5m8767_pmic_dt_parse_pdata(struct 
platform_device *pdev,
rdata = devm_kcalloc(>dev,
 pdata->num_regulators, sizeof(*rdata),
 GFP_KERNEL);
-   if (!rdata)
+   if (!rdata) {
+   of_node_put(regulators_np);
return -ENOMEM;
+   }
 
rmode = devm_kcalloc(>dev,
 pdata->num_regulators, sizeof(*rmode),
 GFP_KERNEL);
-   if (!rmode)
+   if (!rmode) {
+   of_node_put(regulators_np);
return -ENOMEM;
+   }
 
pdata->regulators = rdata;
pdata->opmode = rmode;
-- 
2.27.0





[PATCH 5.10 188/663] media: lmedm04: Fix misuse of comma

2021-03-01 Thread Greg Kroah-Hartman
From: Joe Perches 

[ Upstream commit 59a3e78f8cc33901fe39035c1ab681374bba95ad ]

There's a comma used instead of a semicolon that causes multiple
statements to be executed after an if instead of just the intended
single statement.

Replace the comma with a semicolon.

Fixes: 15e1ce33182d ("[media] lmedm04: Fix usb_submit_urb BOGUS urb xfer, pipe 
1 != type 3 in interrupt urb")
Signed-off-by: Joe Perches 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
---
 drivers/media/usb/dvb-usb-v2/lmedm04.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c 
b/drivers/media/usb/dvb-usb-v2/lmedm04.c
index 5a7a9522d46da..9ddda8d68ee0f 100644
--- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
+++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
@@ -391,7 +391,7 @@ static int lme2510_int_read(struct dvb_usb_adapter *adap)
ep = usb_pipe_endpoint(d->udev, lme_int->lme_urb->pipe);
 
if (usb_endpoint_type(>desc) == USB_ENDPOINT_XFER_BULK)
-   lme_int->lme_urb->pipe = usb_rcvbulkpipe(d->udev, 0xa),
+   lme_int->lme_urb->pipe = usb_rcvbulkpipe(d->udev, 0xa);
 
usb_submit_urb(lme_int->lme_urb, GFP_ATOMIC);
info("INT Interrupt Service Started");
-- 
2.27.0





[PATCH 5.11 390/775] powerpc/kvm: Force selection of CONFIG_PPC_FPU

2021-03-01 Thread Greg Kroah-Hartman
From: Christophe Leroy 

[ Upstream commit 27f699579b64dbf27caf31e5c0eac567ec0aa8b8 ]

book3s/32 kvm is designed with the assumption that
an FPU is always present.

Force selection of FPU support in the kernel when
build KVM.

Fixes: 7d68c8916950 ("powerpc/32s: Allow deselecting CONFIG_PPC_FPU on mpc832x")
Reported-by: kernel test robot 
Signed-off-by: Christophe Leroy 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/74461a99fa1466f361532ca794ca0753be3d9f86.1611038044.git.christophe.le...@csgroup.eu
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kvm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index 549591d9aaa2c..e45644657d49d 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -54,6 +54,7 @@ config KVM_BOOK3S_32
select KVM
select KVM_BOOK3S_32_HANDLER
select KVM_BOOK3S_PR_POSSIBLE
+   select PPC_FPU
help
  Support running unmodified book3s_32 guest kernels
  in virtual machines on book3s_32 host processors.
-- 
2.27.0





[PATCH 5.11 367/775] scsi: libsas: Remove notifier indirection

2021-03-01 Thread Greg Kroah-Hartman
From: John Garry 

[ Upstream commit 121181f3f839c29d8dd9fdc3cc9babbdc74227f8 ]

LLDDs report events to libsas with .notify_port_event and .notify_phy_event
callbacks.

These callbacks are fixed and so there is no reason why the functions
cannot be called directly, so do that.

This neatens the code slightly, makes it more obvious, and reduces function
pointer usage, which is generally a good thing. Downside is that there are
2x more symbol exports.

[a.darw...@linutronix.de: Remove the now unused "sas_ha" local variables]

Link: https://lore.kernel.org/r/20210118100955.1761652-3-a.darw...@linutronix.de
Reviewed-by: Christoph Hellwig 
Reviewed-by: Jack Wang 
Signed-off-by: John Garry 
Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 Documentation/scsi/libsas.rst  |  9 ++
 drivers/scsi/aic94xx/aic94xx_scb.c | 20 ++---
 drivers/scsi/hisi_sas/hisi_sas_main.c  | 12 +++-
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c |  3 +-
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c |  3 +-
 drivers/scsi/hisi_sas/hisi_sas_v3_hw.c |  3 +-
 drivers/scsi/isci/port.c   |  7 ++---
 drivers/scsi/libsas/sas_event.c| 13 +++--
 drivers/scsi/libsas/sas_init.c |  6 
 drivers/scsi/libsas/sas_internal.h |  1 -
 drivers/scsi/mvsas/mv_sas.c| 14 -
 drivers/scsi/pm8001/pm8001_hwi.c   | 40 --
 drivers/scsi/pm8001/pm8001_sas.c   |  7 ++---
 drivers/scsi/pm8001/pm80xx_hwi.c   | 35 ++
 include/scsi/libsas.h  |  7 ++---
 15 files changed, 70 insertions(+), 110 deletions(-)

diff --git a/Documentation/scsi/libsas.rst b/Documentation/scsi/libsas.rst
index f9b77c7879dbb..210df1aba1409 100644
--- a/Documentation/scsi/libsas.rst
+++ b/Documentation/scsi/libsas.rst
@@ -189,12 +189,9 @@ num_phys
 The event interface::
 
/* LLDD calls these to notify the class of an event. */
-   void (*notify_port_event)(struct sas_phy *, enum port_event);
-   void (*notify_phy_event)(struct sas_phy *, enum phy_event);
-
-When sas_register_ha() returns, those are set and can be
-called by the LLDD to notify the SAS layer of such events
-the SAS layer.
+   void (*notify_ha_event)(struct sas_ha_struct *, enum ha_event);
+   void sas_notify_port_event(struct sas_phy *, enum port_event);
+   void sas_notify_phy_event(struct sas_phy *, enum phy_event);
 
 The port notification::
 
diff --git a/drivers/scsi/aic94xx/aic94xx_scb.c 
b/drivers/scsi/aic94xx/aic94xx_scb.c
index 13677973da5cf..770546177ca46 100644
--- a/drivers/scsi/aic94xx/aic94xx_scb.c
+++ b/drivers/scsi/aic94xx/aic94xx_scb.c
@@ -68,7 +68,6 @@ static void asd_phy_event_tasklet(struct asd_ascb *ascb,
 struct done_list_struct *dl)
 {
struct asd_ha_struct *asd_ha = ascb->ha;
-   struct sas_ha_struct *sas_ha = _ha->sas_ha;
int phy_id = dl->status_block[0] & DL_PHY_MASK;
struct asd_phy *phy = _ha->phys[phy_id];
 
@@ -81,7 +80,7 @@ static void asd_phy_event_tasklet(struct asd_ascb *ascb,
ASD_DPRINTK("phy%d: device unplugged\n", phy_id);
asd_turn_led(asd_ha, phy_id, 0);
sas_phy_disconnected(>sas_phy);
-   sas_ha->notify_phy_event(>sas_phy, PHYE_LOSS_OF_SIGNAL);
+   sas_notify_phy_event(>sas_phy, PHYE_LOSS_OF_SIGNAL);
break;
case CURRENT_OOB_DONE:
/* hot plugged device */
@@ -89,12 +88,12 @@ static void asd_phy_event_tasklet(struct asd_ascb *ascb,
get_lrate_mode(phy, oob_mode);
ASD_DPRINTK("phy%d device plugged: lrate:0x%x, proto:0x%x\n",
phy_id, phy->sas_phy.linkrate, phy->sas_phy.iproto);
-   sas_ha->notify_phy_event(>sas_phy, PHYE_OOB_DONE);
+   sas_notify_phy_event(>sas_phy, PHYE_OOB_DONE);
break;
case CURRENT_SPINUP_HOLD:
/* hot plug SATA, no COMWAKE sent */
asd_turn_led(asd_ha, phy_id, 1);
-   sas_ha->notify_phy_event(>sas_phy, PHYE_SPINUP_HOLD);
+   sas_notify_phy_event(>sas_phy, PHYE_SPINUP_HOLD);
break;
case CURRENT_GTO_TIMEOUT:
case CURRENT_OOB_ERROR:
@@ -102,7 +101,7 @@ static void asd_phy_event_tasklet(struct asd_ascb *ascb,
dl->status_block[1]);
asd_turn_led(asd_ha, phy_id, 0);
sas_phy_disconnected(>sas_phy);
-   sas_ha->notify_phy_event(>sas_phy, PHYE_OOB_ERROR);
+   sas_notify_phy_event(>sas_phy, PHYE_OOB_ERROR);
break;
}
 }
@@ -222,7 +221,6 @@ static void asd_bytes_dmaed_tasklet(struct asd_ascb *ascb,
int edb_el = edb_id + ascb->edb_index;
struct asd_dma_tok *edb = ascb->ha->seq.edb_arr[edb_el];
struct asd_phy *phy = >ha->phys[phy_id];
-   struct sas_ha_struct *sas_ha = 

[PATCH 5.10 355/663] kselftests: dmabuf-heaps: Fix Makefiles inclusion of the kernels usr/include dir

2021-03-01 Thread Greg Kroah-Hartman
From: John Stultz 

[ Upstream commit 64ba3d591c9d2be2a9c09e99b00732afe002ad0d ]

Copied in from somewhere else, the makefile was including
the kerne's usr/include dir, which caused the asm/ioctl.h file
to be used.

Unfortunately, that file has different values for _IOC_SIZEBITS
and _IOC_WRITE than include/uapi/asm-generic/ioctl.h which then
causes the _IOCW macros to give the wrong ioctl numbers,
specifically for DMA_BUF_IOCTL_SYNC.

This patch simply removes the extra include from the Makefile

Cc: Shuah Khan 
Cc: Brian Starkey 
Cc: Sumit Semwal 
Cc: Laura Abbott 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kselft...@vger.kernel.org
Fixes: a8779927fd86c ("kselftests: Add dma-heap test")
Signed-off-by: John Stultz 
Signed-off-by: Shuah Khan 
Signed-off-by: Sasha Levin 
---
 tools/testing/selftests/dmabuf-heaps/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile 
b/tools/testing/selftests/dmabuf-heaps/Makefile
index 607c2acd20829..604b43ece15f5 100644
--- a/tools/testing/selftests/dmabuf-heaps/Makefile
+++ b/tools/testing/selftests/dmabuf-heaps/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
-CFLAGS += -static -O3 -Wl,-no-as-needed -Wall -I../../../../usr/include
+CFLAGS += -static -O3 -Wl,-no-as-needed -Wall
 
 TEST_GEN_PROGS = dmabuf-heap
 
-- 
2.27.0





[PATCH 5.11 271/775] KVM: x86: Restore all 64 bits of DR6 and DR7 during RSM on x86-64

2021-03-01 Thread Greg Kroah-Hartman
From: Sean Christopherson 

[ Upstream commit 2644312052d54e2e7543c7d186899a36ed22f0bf ]

Restore the full 64-bit values of DR6 and DR7 when emulating RSM on
x86-64, as defined by both Intel's SDM and AMD's APM.

Note, bits 63:32 of DR6 and DR7 are reserved, so this is a glorified nop
unless the SMM handler is poking into SMRAM, which it most definitely
shouldn't be doing since both Intel and AMD list the DR6 and DR7 fields
as read-only.

Fixes: 660a5d517aaa ("KVM: x86: save/load state on SMM switch")
Signed-off-by: Sean Christopherson 
Message-Id: <20210205012458.3872687-3-sea...@google.com>
Signed-off-by: Paolo Bonzini 
Signed-off-by: Sasha Levin 
---
 arch/x86/kvm/emulate.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 66a08322988f2..1453b9b794425 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2564,12 +2564,12 @@ static int rsm_load_state_64(struct x86_emulate_ctxt 
*ctxt,
ctxt->_eip   = GET_SMSTATE(u64, smstate, 0x7f78);
ctxt->eflags = GET_SMSTATE(u32, smstate, 0x7f70) | X86_EFLAGS_FIXED;
 
-   val = GET_SMSTATE(u32, smstate, 0x7f68);
+   val = GET_SMSTATE(u64, smstate, 0x7f68);
 
if (ctxt->ops->set_dr(ctxt, 6, (val & DR6_VOLATILE) | DR6_FIXED_1))
return X86EMUL_UNHANDLEABLE;
 
-   val = GET_SMSTATE(u32, smstate, 0x7f60);
+   val = GET_SMSTATE(u64, smstate, 0x7f60);
 
if (ctxt->ops->set_dr(ctxt, 7, (val & DR7_VOLATILE) | DR7_FIXED_1))
return X86EMUL_UNHANDLEABLE;
-- 
2.27.0





[PATCH 5.10 036/663] Bluetooth: hci_qca: Fix memleak in qca_controller_memdump

2021-03-01 Thread Greg Kroah-Hartman
From: Dinghao Liu 

[ Upstream commit 71f8e707557b9bc25dc90a59a752528d4e7c1cbf ]

When __le32_to_cpu() fails, qca_memdump should be freed
just like when vmalloc() fails.

Fixes: d841502c79e3f ("Bluetooth: hci_qca: Collect controller memory dump 
during SSR")
Signed-off-by: Dinghao Liu 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 drivers/bluetooth/hci_qca.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 244b8feba5232..5c26c7d941731 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1020,7 +1020,9 @@ static void qca_controller_memdump(struct work_struct 
*work)
dump_size = __le32_to_cpu(dump->dump_size);
if (!(dump_size)) {
bt_dev_err(hu->hdev, "Rx invalid memdump size");
+   kfree(qca_memdump);
kfree_skb(skb);
+   qca->qca_memdump = NULL;
mutex_unlock(>hci_memdump_lock);
return;
}
-- 
2.27.0





[PATCH 5.10 338/663] iommu: Properly pass gfp_t in _iommu_map() to avoid atomic sleeping

2021-03-01 Thread Greg Kroah-Hartman
From: Douglas Anderson 

[ Upstream commit b8437a3ef8c485903d05d1f261328aaf0c0a6cc2 ]

Sleeping while atomic = bad.  Let's fix an obvious typo to try to avoid it.

The warning that was seen (on a downstream kernel with the problematic
patch backported):

 BUG: sleeping function called from invalid context at mm/page_alloc.c:4726
 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 9, name: ksoftirqd/0
 CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 5.4.93-12508-gc10c93e28e39 #1
 Call trace:
  dump_backtrace+0x0/0x154
  show_stack+0x20/0x2c
  dump_stack+0xa0/0xfc
  ___might_sleep+0x11c/0x12c
  __might_sleep+0x50/0x84
  __alloc_pages_nodemask+0xf8/0x2bc
  __arm_lpae_alloc_pages+0x48/0x1b4
  __arm_lpae_map+0x124/0x274
  __arm_lpae_map+0x1cc/0x274
  arm_lpae_map+0x140/0x170
  arm_smmu_map+0x78/0xbc
  __iommu_map+0xd4/0x210
  _iommu_map+0x4c/0x84
  iommu_map_atomic+0x44/0x58
  __iommu_dma_map+0x8c/0xc4
  iommu_dma_map_page+0xac/0xf0

Fixes: d8c1df02ac7f ("iommu: Move iotlb_sync_map out from __iommu_map")
Signed-off-by: Douglas Anderson 
Reviewed-by: Yong Wu 
Acked-by: Will Deacon 
Link: 
https://lore.kernel.org/r/20210201170611.1.I64a7b62579287d668d7c89e105dcedf45d641063@changeid
Signed-off-by: Joerg Roedel 
Signed-off-by: Sasha Levin 
---
 drivers/iommu/iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index a25a85a0bba5b..0d9adce6d812f 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2424,7 +2424,7 @@ static int _iommu_map(struct iommu_domain *domain, 
unsigned long iova,
const struct iommu_ops *ops = domain->ops;
int ret;
 
-   ret = __iommu_map(domain, iova, paddr, size, prot, GFP_KERNEL);
+   ret = __iommu_map(domain, iova, paddr, size, prot, gfp);
if (ret == 0 && ops->iotlb_sync_map)
ops->iotlb_sync_map(domain);
 
-- 
2.27.0





[PATCH 5.10 001/663] vmlinux.lds.h: add DWARF v5 sections

2021-03-01 Thread Greg Kroah-Hartman
From: Nick Desaulniers 

commit 3c4fa46b30c551b1df2fb1574a684f68bc22067c upstream.

We expect toolchains to produce these new debug info sections as part of
DWARF v5. Add explicit placements to prevent the linker warnings from
--orphan-section=warn.

Compilers may produce such sections with explicit -gdwarf-5, or based on
the implicit default version of DWARF when -g is used via DEBUG_INFO.
This implicit default changes over time, and has changed to DWARF v5
with GCC 11.

.debug_sup was mentioned in review, but without compilers producing it
today, let's wait to add it until it becomes necessary.

Cc: sta...@vger.kernel.org
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1922707
Reported-by: Chris Murphy 
Suggested-by: Fangrui Song 
Reviewed-by: Nathan Chancellor 
Reviewed-by: Mark Wielaard 
Tested-by: Sedat Dilek 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Greg Kroah-Hartman 
---
 include/asm-generic/vmlinux.lds.h |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -828,8 +828,13 @@
/* DWARF 4 */   \
.debug_types0 : { *(.debug_types) } \
/* DWARF 5 */   \
+   .debug_addr 0 : { *(.debug_addr) }  \
+   .debug_line_str 0 : { *(.debug_line_str) }  \
+   .debug_loclists 0 : { *(.debug_loclists) }  \
.debug_macro0 : { *(.debug_macro) } \
-   .debug_addr 0 : { *(.debug_addr) }
+   .debug_names0 : { *(.debug_names) } \
+   .debug_rnglists 0 : { *(.debug_rnglists) }  \
+   .debug_str_offsets  0 : { *(.debug_str_offsets) }
 
 /* Stabs debugging sections. */
 #define STABS_DEBUG\




[PATCH 5.10 625/663] proc: dont allow async path resolution of /proc/thread-self components

2021-03-01 Thread Greg Kroah-Hartman
From: Jens Axboe 

commit 0d4370cfe36b7f1719123b621a4ec4d9c7a25f89 upstream.

If this is attempted by an io-wq kthread, then return -EOPNOTSUPP as we
don't currently support that. Once we can get task_pid_ptr() doing the
right thing, then this can go away again.

Use PF_IO_WORKER for this to speciically target the io_uring workers.
Modify the /proc/self/ check to use PF_IO_WORKER as well.

Cc: sta...@vger.kernel.org
Fixes: 8d4c3e76e3be ("proc: don't allow async path resolution of /proc/self 
components")
Reported-by: Eric W. Biederman 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 
---
 fs/proc/self.c|2 +-
 fs/proc/thread_self.c |7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

--- a/fs/proc/self.c
+++ b/fs/proc/self.c
@@ -20,7 +20,7 @@ static const char *proc_self_get_link(st
 * Not currently supported. Once we can inherit all of struct pid,
 * we can allow this.
 */
-   if (current->flags & PF_KTHREAD)
+   if (current->flags & PF_IO_WORKER)
return ERR_PTR(-EOPNOTSUPP);
 
if (!tgid)
--- a/fs/proc/thread_self.c
+++ b/fs/proc/thread_self.c
@@ -17,6 +17,13 @@ static const char *proc_thread_self_get_
pid_t pid = task_pid_nr_ns(current, ns);
char *name;
 
+   /*
+* Not currently supported. Once we can inherit all of struct pid,
+* we can allow this.
+*/
+   if (current->flags & PF_IO_WORKER)
+   return ERR_PTR(-EOPNOTSUPP);
+
if (!pid)
return ERR_PTR(-ENOENT);
name = kmalloc(10 + 6 + 10 + 1, dentry ? GFP_KERNEL : GFP_ATOMIC);




[PATCH 5.10 525/663] erofs: initialized fields can only be observed after bit is set

2021-03-01 Thread Greg Kroah-Hartman
From: Gao Xiang 

commit ce063129181312f8781a047a50be439c5859747b upstream.

Currently, although set_bit() & test_bit() pairs are used as a fast-
path for initialized configurations. However, these atomic ops are
actually relaxed forms. Instead, load-acquire & store-release form is
needed to make sure uninitialized fields won't be observed in advance
here (yet no such corresponding bitops so use full barriers instead.)

Link: https://lore.kernel.org/r/20210209130618.15838-1-hsiang...@aol.com
Fixes: 62dc45979f3f ("staging: erofs: fix race of initializing xattrs of a 
inode at the same time")
Fixes: 152a333a5895 ("staging: erofs: add compacted compression indexes 
support")
Cc:  # 5.3+
Reported-by: Huang Jianan 
Reviewed-by: Chao Yu 
Signed-off-by: Gao Xiang 
Signed-off-by: Greg Kroah-Hartman 
---
 fs/erofs/xattr.c |   10 +-
 fs/erofs/zmap.c  |   10 +-
 2 files changed, 18 insertions(+), 2 deletions(-)

--- a/fs/erofs/xattr.c
+++ b/fs/erofs/xattr.c
@@ -48,8 +48,14 @@ static int init_inode_xattrs(struct inod
int ret = 0;
 
/* the most case is that xattrs of this inode are initialized. */
-   if (test_bit(EROFS_I_EA_INITED_BIT, >flags))
+   if (test_bit(EROFS_I_EA_INITED_BIT, >flags)) {
+   /*
+* paired with smp_mb() at the end of the function to ensure
+* fields will only be observed after the bit is set.
+*/
+   smp_mb();
return 0;
+   }
 
if (wait_on_bit_lock(>flags, EROFS_I_BL_XATTR_BIT, TASK_KILLABLE))
return -ERESTARTSYS;
@@ -137,6 +143,8 @@ static int init_inode_xattrs(struct inod
}
xattr_iter_end(, atomic_map);
 
+   /* paired with smp_mb() at the beginning of the function. */
+   smp_mb();
set_bit(EROFS_I_EA_INITED_BIT, >flags);
 
 out_unlock:
--- a/fs/erofs/zmap.c
+++ b/fs/erofs/zmap.c
@@ -36,8 +36,14 @@ static int z_erofs_fill_inode_lazy(struc
void *kaddr;
struct z_erofs_map_header *h;
 
-   if (test_bit(EROFS_I_Z_INITED_BIT, >flags))
+   if (test_bit(EROFS_I_Z_INITED_BIT, >flags)) {
+   /*
+* paired with smp_mb() at the end of the function to ensure
+* fields will only be observed after the bit is set.
+*/
+   smp_mb();
return 0;
+   }
 
if (wait_on_bit_lock(>flags, EROFS_I_BL_Z_BIT, TASK_KILLABLE))
return -ERESTARTSYS;
@@ -83,6 +89,8 @@ static int z_erofs_fill_inode_lazy(struc
 
vi->z_physical_clusterbits[1] = vi->z_logical_clusterbits +
((h->h_clusterbits >> 5) & 7);
+   /* paired with smp_mb() at the beginning of the function */
+   smp_mb();
set_bit(EROFS_I_Z_INITED_BIT, >flags);
 unmap_done:
kunmap_atomic(kaddr);




[PATCH 5.4 292/340] arm64: uprobe: Return EOPNOTSUPP for AARCH32 instruction probing

2021-03-01 Thread Greg Kroah-Hartman
From: He Zhe 

commit d47422d953e258ad587b5edf2274eb95d08bdc7d upstream.

As stated in linux/errno.h, ENOTSUPP should never be seen by user programs.
When we set up uprobe with 32-bit perf and arm64 kernel, we would see the
following vague error without useful hint.

The sys_perf_event_open() syscall returned with 524 (INTERNAL ERROR:
strerror_r(524, [buf], 128)=22)

Use EOPNOTSUPP instead to indicate such cases.

Signed-off-by: He Zhe 
Link: https://lore.kernel.org/r/20210223082535.48730-1-zhe...@windriver.com
Cc: 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm64/kernel/probes/uprobes.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm64/kernel/probes/uprobes.c
+++ b/arch/arm64/kernel/probes/uprobes.c
@@ -38,7 +38,7 @@ int arch_uprobe_analyze_insn(struct arch
 
/* TODO: Currently we do not support AARCH32 instruction probing */
if (mm->context.flags & MMCF_AARCH32)
-   return -ENOTSUPP;
+   return -EOPNOTSUPP;
else if (!IS_ALIGNED(addr, AARCH64_INSN_SIZE))
return -EINVAL;
 




[PATCH 5.10 550/663] soc: samsung: exynos-asv: handle reading revision register error

2021-03-01 Thread Greg Kroah-Hartman
From: Krzysztof Kozlowski 

commit 4561560dfb4f847a0b327d48bdd1f45bf1b6261f upstream.

If regmap_read() fails, the product_id local variable will contain
random value from the stack.  Do not try to parse such value and fail
the ASV driver probe.

Fixes: 5ea428595cc5 ("soc: samsung: Add Exynos Adaptive Supply Voltage driver")
Cc: 
Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Pankaj Dubey 
Link: https://lore.kernel.org/r/20201207190517.262051-3-k...@kernel.org
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/soc/samsung/exynos-asv.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- a/drivers/soc/samsung/exynos-asv.c
+++ b/drivers/soc/samsung/exynos-asv.c
@@ -129,7 +129,13 @@ static int exynos_asv_probe(struct platf
return PTR_ERR(asv->chipid_regmap);
}
 
-   regmap_read(asv->chipid_regmap, EXYNOS_CHIPID_REG_PRO_ID, _id);
+   ret = regmap_read(asv->chipid_regmap, EXYNOS_CHIPID_REG_PRO_ID,
+ _id);
+   if (ret < 0) {
+   dev_err(>dev, "Cannot read revision from ChipID: %d\n",
+   ret);
+   return -ENODEV;
+   }
 
switch (product_id & EXYNOS_MASK) {
case 0xE5422000:




[PATCH 5.11 388/775] IB/umad: Return EPOLLERR in case of when device disassociated

2021-03-01 Thread Greg Kroah-Hartman
From: Shay Drory 

[ Upstream commit def4cd43f522253645b72c97181399c241b54536 ]

Currently, polling a umad device will always works, even if the device was
disassociated. A disassociated device should immediately return EPOLLERR
from poll(). Otherwise userspace is endlessly hung on poll() with no idea
that the device has been removed from the system.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Link: https://lore.kernel.org/r/20210125121339.837518-3-l...@kernel.org
Signed-off-by: Shay Drory 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/core/user_mad.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/infiniband/core/user_mad.c 
b/drivers/infiniband/core/user_mad.c
index 7ec1918431f70..dd7f3b437c6be 100644
--- a/drivers/infiniband/core/user_mad.c
+++ b/drivers/infiniband/core/user_mad.c
@@ -397,6 +397,11 @@ static ssize_t ib_umad_read(struct file *filp, char __user 
*buf,
mutex_lock(>mutex);
}
 
+   if (file->agents_dead) {
+   mutex_unlock(>mutex);
+   return -EIO;
+   }
+
packet = list_entry(file->recv_list.next, struct ib_umad_packet, list);
list_del(>list);
 
@@ -658,10 +663,14 @@ static __poll_t ib_umad_poll(struct file *filp, struct 
poll_table_struct *wait)
/* we will always be able to post a MAD send */
__poll_t mask = EPOLLOUT | EPOLLWRNORM;
 
+   mutex_lock(>mutex);
poll_wait(filp, >recv_wait, wait);
 
if (!list_empty(>recv_list))
mask |= EPOLLIN | EPOLLRDNORM;
+   if (file->agents_dead)
+   mask = EPOLLERR;
+   mutex_unlock(>mutex);
 
return mask;
 }
@@ -1341,6 +1350,7 @@ static void ib_umad_kill_port(struct ib_umad_port *port)
list_for_each_entry(file, >file_list, port_list) {
mutex_lock(>mutex);
file->agents_dead = 1;
+   wake_up_interruptible(>recv_wait);
mutex_unlock(>mutex);
 
for (id = 0; id < IB_UMAD_MAX_AGENTS; ++id)
-- 
2.27.0





[PATCH 5.11 389/775] KVM: PPC: Make the VMX instruction emulation routines static

2021-03-01 Thread Greg Kroah-Hartman
From: Cédric Le Goater 

[ Upstream commit 9236f57a9e51c72ce426ccd2e53e123de7196a0f ]

These are only used locally. It fixes these W=1 compile errors :

../arch/powerpc/kvm/powerpc.c:1521:5: error: no previous prototype for 
‘kvmppc_get_vmx_dword’ [-Werror=missing-prototypes]
 1521 | int kvmppc_get_vmx_dword(struct kvm_vcpu *vcpu, int index, u64 *val)
  | ^~~~
../arch/powerpc/kvm/powerpc.c:1539:5: error: no previous prototype for 
‘kvmppc_get_vmx_word’ [-Werror=missing-prototypes]
 1539 | int kvmppc_get_vmx_word(struct kvm_vcpu *vcpu, int index, u64 *val)
  | ^~~
../arch/powerpc/kvm/powerpc.c:1557:5: error: no previous prototype for 
‘kvmppc_get_vmx_hword’ [-Werror=missing-prototypes]
 1557 | int kvmppc_get_vmx_hword(struct kvm_vcpu *vcpu, int index, u64 *val)
  | ^~~~
../arch/powerpc/kvm/powerpc.c:1575:5: error: no previous prototype for 
‘kvmppc_get_vmx_byte’ [-Werror=missing-prototypes]
 1575 | int kvmppc_get_vmx_byte(struct kvm_vcpu *vcpu, int index, u64 *val)
  | ^~~

Fixes: acc9eb9305fe ("KVM: PPC: Reimplement LOAD_VMX/STORE_VMX instruction mmio 
emulation with analyse_instr() input")
Signed-off-by: Cédric Le Goater 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20210104143206.695198-19-...@kaod.org
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kvm/powerpc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index cf52d26f49cd7..25966ae3271ef 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -1518,7 +1518,7 @@ int kvmppc_handle_vmx_load(struct kvm_vcpu *vcpu,
return emulated;
 }
 
-int kvmppc_get_vmx_dword(struct kvm_vcpu *vcpu, int index, u64 *val)
+static int kvmppc_get_vmx_dword(struct kvm_vcpu *vcpu, int index, u64 *val)
 {
union kvmppc_one_reg reg;
int vmx_offset = 0;
@@ -1536,7 +1536,7 @@ int kvmppc_get_vmx_dword(struct kvm_vcpu *vcpu, int 
index, u64 *val)
return result;
 }
 
-int kvmppc_get_vmx_word(struct kvm_vcpu *vcpu, int index, u64 *val)
+static int kvmppc_get_vmx_word(struct kvm_vcpu *vcpu, int index, u64 *val)
 {
union kvmppc_one_reg reg;
int vmx_offset = 0;
@@ -1554,7 +1554,7 @@ int kvmppc_get_vmx_word(struct kvm_vcpu *vcpu, int index, 
u64 *val)
return result;
 }
 
-int kvmppc_get_vmx_hword(struct kvm_vcpu *vcpu, int index, u64 *val)
+static int kvmppc_get_vmx_hword(struct kvm_vcpu *vcpu, int index, u64 *val)
 {
union kvmppc_one_reg reg;
int vmx_offset = 0;
@@ -1572,7 +1572,7 @@ int kvmppc_get_vmx_hword(struct kvm_vcpu *vcpu, int 
index, u64 *val)
return result;
 }
 
-int kvmppc_get_vmx_byte(struct kvm_vcpu *vcpu, int index, u64 *val)
+static int kvmppc_get_vmx_byte(struct kvm_vcpu *vcpu, int index, u64 *val)
 {
union kvmppc_one_reg reg;
int vmx_offset = 0;
-- 
2.27.0





[PATCH 5.11 153/775] arm64: dts: mt8183: refine gamma compatible name

2021-03-01 Thread Greg Kroah-Hartman
From: Yongqiang Niu 

[ Upstream commit 9a2cb5eba7ad4fa7ccb3a4aa754f5263111e8f96 ]

mt8183 gamma is different with mt8173
remove mt8173 compatible name for mt8183 gamma

Fixes: 91f9c963ce79 ("arm64: dts: mt8183: Add display nodes for MT8183")
Signed-off-by: Yongqiang Niu 
Signed-off-by: Hsin-Yi Wang 
Reviewed-by: Enric Balletbo i Serra 
Link: https://lore.kernel.org/r/20210128112314.1304160-3-hsi...@chromium.org
Signed-off-by: Matthias Brugger 
Signed-off-by: Sasha Levin 
---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 6c84ccb709af6..9c0073cfad452 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -1055,8 +1055,7 @@
};
 
gamma0: gamma@14011000 {
-   compatible = "mediatek,mt8183-disp-gamma",
-"mediatek,mt8173-disp-gamma";
+   compatible = "mediatek,mt8183-disp-gamma";
reg = <0 0x14011000 0 0x1000>;
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
-- 
2.27.0





[PATCH 5.4 334/340] xfrm: interface: use icmp_ndo_send helper

2021-03-01 Thread Greg Kroah-Hartman
From: Jason A. Donenfeld 

commit 45942ba890e6f35232727a5fa33d732681f4eb9f upstream.

Because xfrmi is calling icmp from network device context, it should use
the ndo helper so that the rate limiting applies correctly.

Signed-off-by: Jason A. Donenfeld 
Cc: Nicolas Dichtel 
Cc: Steffen Klassert 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/xfrm/xfrm_interface.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/net/xfrm/xfrm_interface.c
+++ b/net/xfrm/xfrm_interface.c
@@ -300,10 +300,10 @@ xfrmi_xmit2(struct sk_buff *skb, struct
if (mtu < IPV6_MIN_MTU)
mtu = IPV6_MIN_MTU;
 
-   icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu);
+   icmpv6_ndo_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu);
} else {
-   icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
- htonl(mtu));
+   icmp_ndo_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
+ htonl(mtu));
}
 
dst_release(dst);




[PATCH 5.4 295/340] mtd: spi-nor: sfdp: Fix last erase region marking

2021-03-01 Thread Greg Kroah-Hartman
From: Takahiro Kuwano 

commit 9166f4af32db74e1544a2149aef231ff24515ea3 upstream.

The place of spi_nor_region_mark_end() must be moved, because 'i' is
re-used for the index of erase[].

Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter Table")
Cc: sta...@vger.kernel.org
Signed-off-by: Takahiro Kuwano 
[ta: Add Fixes tag and Cc to stable]
Signed-off-by: Tudor Ambarus 
Link: 
https://lore.kernel.org/r/02ce8d84b7989ebee33382f6494df53778dd508e.1601612872.git.takahiro.kuw...@infineon.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/mtd/spi-nor/spi-nor.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -3770,6 +3770,7 @@ spi_nor_init_non_uniform_erase_map(struc
offset = (region[i].offset & ~SNOR_ERASE_FLAGS_MASK) +
 region[i].size;
}
+   spi_nor_region_mark_end([i - 1]);
 
save_uniform_erase_type = map->uniform_erase_type;
map->uniform_erase_type = spi_nor_sort_erase_mask(map,
@@ -3793,8 +3794,6 @@ spi_nor_init_non_uniform_erase_map(struc
if (!(regions_erase_type & BIT(erase[i].idx)))
spi_nor_set_erase_type([i], 0, 0xFF);
 
-   spi_nor_region_mark_end([i - 1]);
-
return 0;
 }
 




[PATCH 5.4 318/340] sparc32: fix a user-triggerable oops in clear_user()

2021-03-01 Thread Greg Kroah-Hartman
From: Al Viro 

commit 7780918b36489f0b2f9a3749d7be00c2ceaec513 upstream.

Back in 2.1.29 the clear_user() guts (__bzero()) had been merged
with memset().  Unfortunately, while all exception handlers had been
copied, one of the exception table entries got lost.  As the result,
clear_user() starting at 128*n bytes before the end of page and
spanning between 8 and 127 bytes into the next page would oops when
the second page is unmapped.  It's trivial to reproduce - all
it takes is

main()
{
int fd = open("/dev/zero", O_RDONLY);
char *p = mmap(NULL, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANON, -1, 0);
munmap(p + 8192, 8192);
read(fd, p + 8192 - 128, 192);
}

which had been oopsing since March 1997.  Says something about
the quality of test coverage... ;-/  And while today sparc32 port
is nearly dead, back in '97 it had been very much alive; in fact,
sparc64 had only been in mainline for 3 months by that point...

Cc: sta...@kernel.org
Fixes: v2.1.29
Signed-off-by: Al Viro 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/sparc/lib/memset.S |1 +
 1 file changed, 1 insertion(+)

--- a/arch/sparc/lib/memset.S
+++ b/arch/sparc/lib/memset.S
@@ -142,6 +142,7 @@ __bzero:
ZERO_LAST_BLOCKS(%o0, 0x48, %g2)
ZERO_LAST_BLOCKS(%o0, 0x08, %g2)
 13:
+   EXT(12b, 13b, 21f)
be  8f
 andcc  %o1, 4, %g0
 




RE: [EXTERNAL] Re: [RFC PATCH 12/12] HV/Storvsc: Add bounce buffer support for Storvsc

2021-03-01 Thread Sunil Muthuswamy
> Hi Christoph:
>   Thanks a lot for your review. There are some reasons.
>   1) Vmbus drivers don't use DMA API now.
What is blocking us from making the Hyper-V drivers use the DMA API's? They
will be a null-op generally, when there is no bounce buffer support needed.

>   2) Hyper-V Vmbus channel ring buffer already play bounce buffer
> role for most vmbus drivers. Just two kinds of packets from
> netvsc/storvsc are uncovered.
How does this make a difference here?

>   3) In AMD SEV-SNP based Hyper-V guest, the access physical address
> of shared memory should be bounce buffer memory physical address plus
> with a shared memory boundary(e.g, 48bit) reported Hyper-V CPUID. It's
> called virtual top of memory(vTom) in AMD spec and works as a watermark.
> So it needs to ioremap/memremap the associated physical address above
> the share memory boundary before accessing them. swiotlb_bounce() uses
> low end physical address to access bounce buffer and this doesn't work
> in this senario. If something wrong, please help me correct me.
> 
There are alternative implementations of swiotlb on top of the core swiotlb
API's. One option is to have Hyper-V specific swiotlb wrapper DMA API's with
the custom logic above.

> Thanks.
> 
> 
> On 3/1/2021 2:54 PM, Christoph Hellwig wrote:
> > This should be handled by the DMA mapping layer, just like for native
> > SEV support.
I agree with Christoph's comment that in principle, this should be handled using
the DMA API's


[PATCH 5.10 640/663] gfs2: Recursive gfs2_quota_hold in gfs2_iomap_end

2021-03-01 Thread Greg Kroah-Hartman
From: Andreas Gruenbacher 

commit 7009fa9cd9a5262944b30eb7efb1f0561d074b68 upstream.

When starting an iomap write, gfs2_quota_lock_check -> gfs2_quota_lock
-> gfs2_quota_hold is called from gfs2_iomap_begin.  At the end of the
write, before unlocking the quotas, punch_hole -> gfs2_quota_hold can be
called again in gfs2_iomap_end, which is incorrect and leads to a failed
assertion.  Instead, move the call to gfs2_quota_unlock before the call
to punch_hole to fix that.

Fixes: 64bc06bb32ee ("gfs2: iomap buffered write support")
Cc: sta...@vger.kernel.org # v4.19+
Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Greg Kroah-Hartman 
---
 fs/gfs2/bmap.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/fs/gfs2/bmap.c
+++ b/fs/gfs2/bmap.c
@@ -1230,6 +1230,9 @@ static int gfs2_iomap_end(struct inode *
 
gfs2_inplace_release(ip);
 
+   if (ip->i_qadata && ip->i_qadata->qa_qd_num)
+   gfs2_quota_unlock(ip);
+
if (length != written && (iomap->flags & IOMAP_F_NEW)) {
/* Deallocate blocks that were just allocated. */
loff_t blockmask = i_blocksize(inode) - 1;
@@ -1242,9 +1245,6 @@ static int gfs2_iomap_end(struct inode *
}
}
 
-   if (ip->i_qadata && ip->i_qadata->qa_qd_num)
-   gfs2_quota_unlock(ip);
-
if (unlikely(!written))
goto out_unlock;
 




[PATCH 5.11 127/775] bpf: Clear subreg_def for global function return values

2021-03-01 Thread Greg Kroah-Hartman
From: Ilya Leoshkevich 

[ Upstream commit 45159b27637b0fef6d5ddb86fc7c46b13c77960f ]

test_global_func4 fails on s390 as reported by Yauheni in [1].

The immediate problem is that the zext code includes the instruction,
whose result needs to be zero-extended, into the zero-extension
patchlet, and if this instruction happens to be a branch, then its
delta is not adjusted. As a result, the verifier rejects the program
later.

However, according to [2], as far as the verifier's algorithm is
concerned and as specified by the insn_no_def() function, branching
insns do not define anything. This includes call insns, even though
one might argue that they define %r0.

This means that the real problem is that zero extension kicks in at
all. This happens because clear_caller_saved_regs() sets BPF_REG_0's
subreg_def after global function calls. This can be fixed in many
ways; this patch mimics what helper function call handling already
does.

  [1] 
https://lore.kernel.org/bpf/20200903140542.156624-1-yauheni.kali...@redhat.com/
  [2] 
https://lore.kernel.org/bpf/caadnvq+2rpkcftzw8d+b1uwb35cpbhpf5u3oocnh90d9pet...@mail.gmail.com/

Fixes: 51c39bb1d5d1 ("bpf: Introduce function-by-function verification")
Reported-by: Yauheni Kaliuta 
Signed-off-by: Ilya Leoshkevich 
Signed-off-by: Daniel Borkmann 
Link: https://lore.kernel.org/bpf/20210212040408.90109-1-...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 kernel/bpf/verifier.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 20babdd06278f..33683eafea90e 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -4834,8 +4834,9 @@ static int check_func_call(struct bpf_verifier_env *env, 
struct bpf_insn *insn,
subprog);
clear_caller_saved_regs(env, caller->regs);
 
-   /* All global functions return SCALAR_VALUE */
+   /* All global functions return a 64-bit SCALAR_VALUE */
mark_reg_unknown(env, caller->regs, BPF_REG_0);
+   caller->regs[BPF_REG_0].subreg_def = DEF_NOT_SUBREG;
 
/* continue with next insn after call */
return 0;
-- 
2.27.0





[PATCH 5.10 547/663] crypto: sun4i-ss - handle BigEndian for cipher

2021-03-01 Thread Greg Kroah-Hartman
From: Corentin Labbe 

commit 5ab6177fa02df15cd8a02a1f1fb361d2d5d8b946 upstream.

Ciphers produce invalid results on BE.
Key and IV need to be written in LE.

Fixes: 6298e948215f2 ("crypto: sunxi-ss - Add Allwinner Security System crypto 
accelerator")
Cc: 
Signed-off-by: Corentin Labbe 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

--- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c
+++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c
@@ -54,13 +54,13 @@ static int noinline_for_stack sun4i_ss_o
 
spin_lock_irqsave(>slock, flags);
 
-   for (i = 0; i < op->keylen; i += 4)
-   writel(*(op->key + i / 4), ss->base + SS_KEY0 + i);
+   for (i = 0; i < op->keylen / 4; i++)
+   writesl(ss->base + SS_KEY0 + i * 4, >key[i], 1);
 
if (areq->iv) {
for (i = 0; i < 4 && i < ivsize / 4; i++) {
v = *(u32 *)(areq->iv + i * 4);
-   writel(v, ss->base + SS_IV0 + i * 4);
+   writesl(ss->base + SS_IV0 + i * 4, , 1);
}
}
writel(mode, ss->base + SS_CTL);
@@ -238,13 +238,13 @@ static int sun4i_ss_cipher_poll(struct s
 
spin_lock_irqsave(>slock, flags);
 
-   for (i = 0; i < op->keylen; i += 4)
-   writel(*(op->key + i / 4), ss->base + SS_KEY0 + i);
+   for (i = 0; i < op->keylen / 4; i++)
+   writesl(ss->base + SS_KEY0 + i * 4, >key[i], 1);
 
if (areq->iv) {
for (i = 0; i < 4 && i < ivsize / 4; i++) {
v = *(u32 *)(areq->iv + i * 4);
-   writel(v, ss->base + SS_IV0 + i * 4);
+   writesl(ss->base + SS_IV0 + i * 4, , 1);
}
}
writel(mode, ss->base + SS_CTL);




[PATCH 5.11 360/775] platform/chrome: cros_ec_proto: Add LID and BATTERY to default mask

2021-03-01 Thread Greg Kroah-Hartman
From: Evan Benn 

[ Upstream commit 852405d8efcbca0e02f14592fb1d1dcd0d3fb508 ]

After 'platform/chrome: cros_ec_proto: Use EC_HOST_EVENT_MASK not BIT'
some of the flags are not quite correct.
LID_CLOSED is used to suspend the device, so it makes sense to ignore that.
BATTERY events are also frequent and causing spurious wakes on elm/hana
mt8173 devices.

Fixes: c214e564acb2 ("platform/chrome: cros_ec_proto: ignore unnecessary 
wakeups on old ECs")
Signed-off-by: Evan Benn 
Reviewed-by: Brian Norris 
Signed-off-by: Enric Balletbo i Serra 
Link: 
https://lore.kernel.org/r/20201209220306.2.I3291bf83e4884c206b097ede34780e014fa3e265@changeid
Signed-off-by: Sasha Levin 
---
 drivers/platform/chrome/cros_ec_proto.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/chrome/cros_ec_proto.c 
b/drivers/platform/chrome/cros_ec_proto.c
index 3ad60190e11c6..aa7f7aa772971 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -526,9 +526,11 @@ int cros_ec_query_all(struct cros_ec_device *ec_dev)
 * power), not wake up.
 */
ec_dev->host_event_wake_mask = U32_MAX &
-   ~(EC_HOST_EVENT_MASK(EC_HOST_EVENT_AC_DISCONNECTED) |
+   ~(EC_HOST_EVENT_MASK(EC_HOST_EVENT_LID_CLOSED) |
+ EC_HOST_EVENT_MASK(EC_HOST_EVENT_AC_DISCONNECTED) |
  EC_HOST_EVENT_MASK(EC_HOST_EVENT_BATTERY_LOW) |
  EC_HOST_EVENT_MASK(EC_HOST_EVENT_BATTERY_CRITICAL) |
+ EC_HOST_EVENT_MASK(EC_HOST_EVENT_BATTERY) |
  EC_HOST_EVENT_MASK(EC_HOST_EVENT_PD_MCU) |
  EC_HOST_EVENT_MASK(EC_HOST_EVENT_BATTERY_STATUS));
/*
-- 
2.27.0





[PATCH 5.10 405/663] VMCI: Use set_page_dirty_lock() when unregistering guest memory

2021-03-01 Thread Greg Kroah-Hartman
From: Jorgen Hansen 

[ Upstream commit 5a16c535409f8dcb7568e20737309e3027ae3e49 ]

When the VMCI host support releases guest memory in the case where
the VM was killed, the pinned guest pages aren't locked. Use
set_page_dirty_lock() instead of set_page_dirty().

Testing done: Killed VM while having an active VMCI based vSocket
connection and observed warning from ext4. With this fix, no
warning was observed. Ran various vSocket tests without issues.

Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.")
Reviewed-by: Vishnu Dasa 
Signed-off-by: Jorgen Hansen 
Link: 
https://lore.kernel.org/r/1611160360-30299-1-git-send-email-jhan...@vmware.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/misc/vmw_vmci/vmci_queue_pair.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c 
b/drivers/misc/vmw_vmci/vmci_queue_pair.c
index c49065887e8f5..df6b19c4c49b5 100644
--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
+++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
@@ -630,7 +630,7 @@ static void qp_release_pages(struct page **pages,
 
for (i = 0; i < num_pages; i++) {
if (dirty)
-   set_page_dirty(pages[i]);
+   set_page_dirty_lock(pages[i]);
 
put_page(pages[i]);
pages[i] = NULL;
-- 
2.27.0





[PATCH 5.10 152/663] drm: rcar-du: Fix the return check of of_parse_phandle and of_find_device_by_node

2021-03-01 Thread Greg Kroah-Hartman
From: Wang Xiaojun 

[ Upstream commit 8d7d33f6be06f929ac2c5e8ea2323fec272790d4 ]

of_parse_phandle and of_find_device_by_node may return NULL
which cannot be checked by IS_ERR.

Fixes: 8de707aeb452 ("drm: rcar-du: kms: Initialize CMM instances")
Signed-off-by: Wang Xiaojun 
Reported-by: Hulk Robot 
Acked-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Kieran Bingham 

[Replace -ENODEV with -EINVAL]

Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 72dda446355fe..7015e22872bbe 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -700,10 +700,10 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
int ret;
 
cmm = of_parse_phandle(np, "renesas,cmms", i);
-   if (IS_ERR(cmm)) {
+   if (!cmm) {
dev_err(rcdu->dev,
"Failed to parse 'renesas,cmms' property\n");
-   return PTR_ERR(cmm);
+   return -EINVAL;
}
 
if (!of_device_is_available(cmm)) {
@@ -713,10 +713,10 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
}
 
pdev = of_find_device_by_node(cmm);
-   if (IS_ERR(pdev)) {
+   if (!pdev) {
dev_err(rcdu->dev, "No device found for CMM%u\n", i);
of_node_put(cmm);
-   return PTR_ERR(pdev);
+   return -EINVAL;
}
 
of_node_put(cmm);
-- 
2.27.0





[PATCH 5.11 220/775] macintosh/adb-iop: Use big-endian autopoll mask

2021-03-01 Thread Greg Kroah-Hartman
From: Finn Thain 

[ Upstream commit c396dd2ec5bbd1cb80eafe32a72ab6bd6b17cb5a ]

As usual, the available documentation is inadequate and leaves endianness
unspecified for message data. However, testing shows that this patch does
improve correctness. The mistake should have been detected earlier but it
was obscured by other bugs. In testing, this patch reinstated pre-v5.9
behaviour. The old driver bugs remain and ADB input devices may stop
working. But that appears to be unrelated.

Cc: Joshua Thompson 
Fixes: c66da95a39ec ("macintosh/adb-iop: Implement SRQ autopolling")
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
Signed-off-by: Geert Uytterhoeven 
Link: https://lore.kernel.org/r/20210125074524.3027452-1-ge...@linux-m68k.org
Signed-off-by: Sasha Levin 
---
 drivers/macintosh/adb-iop.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/macintosh/adb-iop.c b/drivers/macintosh/adb-iop.c
index 0ee3272491501..2633bc254935c 100644
--- a/drivers/macintosh/adb-iop.c
+++ b/drivers/macintosh/adb-iop.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -249,7 +250,7 @@ static void adb_iop_set_ap_complete(struct iop_msg *msg)
 {
struct adb_iopmsg *amsg = (struct adb_iopmsg *)msg->message;
 
-   autopoll_devs = (amsg->data[1] << 8) | amsg->data[0];
+   autopoll_devs = get_unaligned_be16(amsg->data);
if (autopoll_devs & (1 << autopoll_addr))
return;
autopoll_addr = autopoll_devs ? (ffs(autopoll_devs) - 1) : 0;
@@ -266,8 +267,7 @@ static int adb_iop_autopoll(int devs)
amsg.flags = ADB_IOP_SET_AUTOPOLL | (mask ? ADB_IOP_AUTOPOLL : 0);
amsg.count = 2;
amsg.cmd = 0;
-   amsg.data[0] = mask & 0xFF;
-   amsg.data[1] = (mask >> 8) & 0xFF;
+   put_unaligned_be16(mask, amsg.data);
 
iop_send_message(ADB_IOP, ADB_CHAN, NULL, sizeof(amsg), (__u8 *),
 adb_iop_set_ap_complete);
-- 
2.27.0





[PATCH 5.10 229/663] drm/vc4: hdmi: Move hdmi reset to bind

2021-03-01 Thread Greg Kroah-Hartman
From: Dom Cobley 

[ Upstream commit 902dc5c19a8fecd3113dd41cc601b34557bdede9 ]

The hdmi reset got moved to a later point in the commit 9045e91a476b
("drm/vc4: hdmi: Add reset callback").

However, the reset now occurs after vc4_hdmi_cec_init and so tramples
the setup of registers like HDMI_CEC_CNTRL_1

This only affects pi0-3 as on pi4 the cec registers are in a separate
block

Fixes: 9045e91a476b ("drm/vc4: hdmi: Add reset callback")
Reviewed-by: Dave Stevenson 
Signed-off-by: Dom Cobley 
Signed-off-by: Maxime Ripard 
Acked-by: Hans Verkuil 
Tested-by: Hans Verkuil 
Link: 
https://patchwork.freedesktop.org/patch/msgid/2021042309.193441-3-max...@cerno.tech
(cherry picked from commit 7155334f15f360f5c98391c5c7e12af4c13395c4)
Signed-off-by: Maarten Lankhorst 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index db06f52de9d91..1b2b5e3986ebd 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -661,9 +661,6 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct 
drm_encoder *encoder)
return;
}
 
-   if (vc4_hdmi->variant->reset)
-   vc4_hdmi->variant->reset(vc4_hdmi);
-
if (vc4_hdmi->variant->phy_init)
vc4_hdmi->variant->phy_init(vc4_hdmi, mode);
 
@@ -1744,6 +1741,9 @@ static int vc4_hdmi_bind(struct device *dev, struct 
device *master, void *data)
vc4_hdmi->disable_wifi_frequencies =
of_property_read_bool(dev->of_node, "wifi-2.4ghz-coexistence");
 
+   if (vc4_hdmi->variant->reset)
+   vc4_hdmi->variant->reset(vc4_hdmi);
+
pm_runtime_enable(dev);
 
drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
-- 
2.27.0





[PATCH 5.11 240/775] perf/arm-cmn: Fix PMU instance naming

2021-03-01 Thread Greg Kroah-Hartman
From: Robin Murphy 

[ Upstream commit 79d7c3dca99fa96033695ddf5d495b775a3a137b ]

Although it's neat to avoid the suffix for the typical case of a
single PMU, it means systems with multiple CMN instances end up with
inconsistent naming. I think it also breaks perf tool's "uncore alias"
logic if the common instance prefix is also the full name of one.

Avoid any surprises by not trying to be clever and simply numbering
every instance, even when it might technically prove redundant.

Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver")
Signed-off-by: Robin Murphy 
Link: 
https://lore.kernel.org/r/649a2281233f193d59240b13ed91b57337c77b32.1611839564.git.robin.mur...@arm.com
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin 
---
 Documentation/admin-guide/perf/arm-cmn.rst |  2 +-
 drivers/perf/arm-cmn.c | 13 -
 2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/Documentation/admin-guide/perf/arm-cmn.rst 
b/Documentation/admin-guide/perf/arm-cmn.rst
index 0e48093460140..796e25b7027b2 100644
--- a/Documentation/admin-guide/perf/arm-cmn.rst
+++ b/Documentation/admin-guide/perf/arm-cmn.rst
@@ -17,7 +17,7 @@ PMU events
 --
 
 The PMU driver registers a single PMU device for the whole interconnect,
-see /sys/bus/event_source/devices/arm_cmn. Multi-chip systems may link
+see /sys/bus/event_source/devices/arm_cmn_0. Multi-chip systems may link
 more than one CMN together via external CCIX links - in this situation,
 each mesh counts its own events entirely independently, and additional
 PMU devices will be named arm_cmn_{1..n}.
diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
index a76ff594f3ca4..f3071b5ddaaef 100644
--- a/drivers/perf/arm-cmn.c
+++ b/drivers/perf/arm-cmn.c
@@ -1502,7 +1502,7 @@ static int arm_cmn_probe(struct platform_device *pdev)
struct arm_cmn *cmn;
const char *name;
static atomic_t id;
-   int err, rootnode, this_id;
+   int err, rootnode;
 
cmn = devm_kzalloc(>dev, sizeof(*cmn), GFP_KERNEL);
if (!cmn)
@@ -1549,14 +1549,9 @@ static int arm_cmn_probe(struct platform_device *pdev)
.cancel_txn = arm_cmn_end_txn,
};
 
-   this_id = atomic_fetch_inc();
-   if (this_id == 0) {
-   name = "arm_cmn";
-   } else {
-   name = devm_kasprintf(cmn->dev, GFP_KERNEL, "arm_cmn_%d", 
this_id);
-   if (!name)
-   return -ENOMEM;
-   }
+   name = devm_kasprintf(cmn->dev, GFP_KERNEL, "arm_cmn_%d", 
atomic_fetch_inc());
+   if (!name)
+   return -ENOMEM;
 
err = cpuhp_state_add_instance(arm_cmn_hp_state, >cpuhp_node);
if (err)
-- 
2.27.0





[PATCH 5.10 385/663] perf intel-pt: Fix missing CYC processing in PSB

2021-03-01 Thread Greg Kroah-Hartman
From: Adrian Hunter 

[ Upstream commit 03fb0f859b45d1eb05c984ab4bd3bef67e45ede2 ]

Add missing CYC packet processing when walking through PSB+. This
improves the accuracy of timestamps that follow PSB+, until the next
MTC.

Fixes: 3d49807870f08 ("perf tools: Add new Intel PT packet definitions")
Signed-off-by: Adrian Hunter 
Reviewed-by: Andi Kleen 
Cc: Jiri Olsa 
Link: https://lore.kernel.org/r/20210205175350.23817-2-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c 
b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
index 697513f351549..91cba05827369 100644
--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
@@ -1761,6 +1761,9 @@ static int intel_pt_walk_psbend(struct intel_pt_decoder 
*decoder)
break;
 
case INTEL_PT_CYC:
+   intel_pt_calc_cyc_timestamp(decoder);
+   break;
+
case INTEL_PT_VMCS:
case INTEL_PT_MNT:
case INTEL_PT_PAD:
-- 
2.27.0





[PATCH 5.10 377/663] RDMA/ucma: Fix use-after-free bug in ucma_create_uevent

2021-03-01 Thread Greg Kroah-Hartman
From: Avihai Horon 

[ Upstream commit fe454dc31e84f8c14cb8942fcb61666c9f40745b ]

ucma_process_join() allocates struct ucma_multicast mc and frees it if an
error occurs during its run.  Specifically, if an error occurs in
copy_to_user(), a use-after-free might happen in the following scenario:

1. mc struct is allocated.
2. rdma_join_multicast() is called and succeeds. During its run,
   cma_iboe_join_multicast() enqueues a work that will later use the
   aforementioned mc struct.
3. copy_to_user() is called and fails.
4. mc struct is deallocated.
5. The work that was enqueued by cma_iboe_join_multicast() is run and
   calls ucma_create_uevent() which tries to access mc struct (which is
   freed by now).

Fix this bug by cancelling the work enqueued by cma_iboe_join_multicast().
Since cma_work_handler() frees struct cma_work, we don't use it in
cma_iboe_join_multicast() so we can safely cancel the work later.

The following syzkaller report revealed it:

   BUG: KASAN: use-after-free in ucma_create_uevent+0x2dd/0x;3f0 
drivers/infiniband/core/ucma.c:272
   Read of size 8 at addr 88810b3ad110 by task kworker/u8:1/108

   CPU: 1 PID: 108 Comm: kworker/u8:1 Not tainted 5.10.0-rc6+ #257
   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS   
rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
   Workqueue: rdma_cm cma_work_handler
   Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xbe/0xf9 lib/dump_stack.c:118
print_address_description.constprop.0+0x3e/0×60 mm/kasan/report.c:385
__kasan_report mm/kasan/report.c:545 [inline]
kasan_report.cold+0x1f/0×37 mm/kasan/report.c:562
ucma_create_uevent+0x2dd/0×3f0 drivers/infiniband/core/ucma.c:272
ucma_event_handler+0xb7/0×3c0 drivers/infiniband/core/ucma.c:349
cma_cm_event_handler+0x5d/0×1c0 drivers/infiniband/core/cma.c:1977
cma_work_handler+0xfa/0×190 drivers/infiniband/core/cma.c:2718
process_one_work+0x54c/0×930 kernel/workqueue.c:2272
worker_thread+0x82/0×830 kernel/workqueue.c:2418
kthread+0x1ca/0×220 kernel/kthread.c:292
ret_from_fork+0x1f/0×30 arch/x86/entry/entry_64.S:296

   Allocated by task 359:
 kasan_save_stack+0x1b/0×40 mm/kasan/common.c:48
 kasan_set_track mm/kasan/common.c:56 [inline]
 __kasan_kmalloc mm/kasan/common.c:461 [inline]
 __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:434
 kmalloc include/linux/slab.h:552 [inline]
 kzalloc include/linux/slab.h:664 [inline]
 ucma_process_join+0x16e/0×3f0 drivers/infiniband/core/ucma.c:1453
 ucma_join_multicast+0xda/0×140 drivers/infiniband/core/ucma.c:1538
 ucma_write+0x1f7/0×280 drivers/infiniband/core/ucma.c:1724
 vfs_write fs/read_write.c:603 [inline]
 vfs_write+0x191/0×4c0 fs/read_write.c:585
 ksys_write+0x1a1/0×1e0 fs/read_write.c:658
 do_syscall_64+0x2d/0×40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

   Freed by task 359:
 kasan_save_stack+0x1b/0×40 mm/kasan/common.c:48
 kasan_set_track+0x1c/0×30 mm/kasan/common.c:56
 kasan_set_free_info+0x1b/0×30 mm/kasan/generic.c:355
 __kasan_slab_free+0x112/0×160 mm/kasan/common.c:422
 slab_free_hook mm/slub.c:1544 [inline]
 slab_free_freelist_hook mm/slub.c:1577 [inline]
 slab_free mm/slub.c:3142 [inline]
 kfree+0xb3/0×3e0 mm/slub.c:4124
 ucma_process_join+0x22d/0×3f0 drivers/infiniband/core/ucma.c:1497
 ucma_join_multicast+0xda/0×140 drivers/infiniband/core/ucma.c:1538
 ucma_write+0x1f7/0×280 drivers/infiniband/core/ucma.c:1724
 vfs_write fs/read_write.c:603 [inline]
 vfs_write+0x191/0×4c0 fs/read_write.c:585
 ksys_write+0x1a1/0×1e0 fs/read_write.c:658
 do_syscall_64+0x2d/0×40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
 The buggy address belongs to the object at 88810b3ad100
 which belongs to the cache kmalloc-192 of size 192
 The buggy address is located 16 bytes inside of
 192-byte region [88810b3ad100, 88810b3ad1c0)

Fixes: b5de0c60cc30 ("RDMA/cma: Fix use after free race in roce multicast join")
Link: https://lore.kernel.org/r/20210211090517.1278415-1-l...@kernel.org
Reported-by: Amit Matityahu 
Signed-off-by: Avihai Horon 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/core/cma.c | 70 ---
 1 file changed, 41 insertions(+), 29 deletions(-)

diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index c51b84b2d2f37..e3638f80e1d52 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -352,7 +352,13 @@ struct ib_device *cma_get_ib_dev(struct cma_device 
*cma_dev)
 
 struct cma_multicast {
struct rdma_id_private *id_priv;
-   struct ib_sa_multicast *sa_mc;
+   union {
+   struct ib_sa_multicast *sa_mc;
+   struct {
+   struct work_struct work;
+ 

[PATCH 5.10 195/663] media: uvcvideo: Accept invalid bFormatIndex and bFrameIndex values

2021-03-01 Thread Greg Kroah-Hartman
From: Laurent Pinchart 

[ Upstream commit dc9455ffae02d7b7fb51ba1e007fffcb9dc5d890 ]

The Renkforce RF AC4K 300 Action Cam 4K reports invalid bFormatIndex and
bFrameIndex values when negotiating the video probe and commit controls.
The UVC descriptors report a single supported format and frame size,
with bFormatIndex and bFrameIndex both equal to 2, but the video probe
and commit controls report bFormatIndex and bFrameIndex set to 1.

The device otherwise operates correctly, but the driver rejects the
values and fails the format try operation. Fix it by ignoring the
invalid indices, and assuming that the format and frame requested by the
driver are accepted by the device.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=210767

Fixes: 8a652a17e3c0 ("media: uvcvideo: Ensure all probed info is returned to 
v4l2")
Reported-by: Till Dörges 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
---
 drivers/media/usb/uvc/uvc_v4l2.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index fa06bfa174ad3..c7172b8952a96 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -248,7 +248,9 @@ static int uvc_v4l2_try_format(struct uvc_streaming *stream,
goto done;
 
/* After the probe, update fmt with the values returned from
-* negotiation with the device.
+* negotiation with the device. Some devices return invalid bFormatIndex
+* and bFrameIndex values, in which case we can only assume they have
+* accepted the requested format as-is.
 */
for (i = 0; i < stream->nformats; ++i) {
if (probe->bFormatIndex == stream->format[i].index) {
@@ -257,11 +259,10 @@ static int uvc_v4l2_try_format(struct uvc_streaming 
*stream,
}
}
 
-   if (i == stream->nformats) {
-   uvc_trace(UVC_TRACE_FORMAT, "Unknown bFormatIndex %u\n",
+   if (i == stream->nformats)
+   uvc_trace(UVC_TRACE_FORMAT,
+ "Unknown bFormatIndex %u, using default\n",
  probe->bFormatIndex);
-   return -EINVAL;
-   }
 
for (i = 0; i < format->nframes; ++i) {
if (probe->bFrameIndex == format->frame[i].bFrameIndex) {
@@ -270,11 +271,10 @@ static int uvc_v4l2_try_format(struct uvc_streaming 
*stream,
}
}
 
-   if (i == format->nframes) {
-   uvc_trace(UVC_TRACE_FORMAT, "Unknown bFrameIndex %u\n",
+   if (i == format->nframes)
+   uvc_trace(UVC_TRACE_FORMAT,
+ "Unknown bFrameIndex %u, using default\n",
  probe->bFrameIndex);
-   return -EINVAL;
-   }
 
fmt->fmt.pix.width = frame->wWidth;
fmt->fmt.pix.height = frame->wHeight;
-- 
2.27.0





[PATCH 5.10 437/663] i40e: Fix addition of RX filters after enabling FW LLDP agent

2021-03-01 Thread Greg Kroah-Hartman
From: Mateusz Palczewski 

[ Upstream commit 28b1208e7a7fa3ddc9345b022bb93e53d9dcc28a ]

Fix addition of VLAN filter for PF after enabling FW LLDP agent.
Changing LLDP Agent causes FW to re-initialize per NVM settings.
Remove default PF filter and move "Enable/Disable" to currently used
reset flag.
Without this patch PF would try to add MAC VLAN filter with default
switch filter present. This causes AQ error and sets promiscuous mode
on.

Fixes: c65e78f87f81 ("i40e: Further implementation of LLDP")
Signed-off-by: Przemyslaw Patynowski 
Signed-off-by: Mateusz Palczewski 
Reviewed-by: Sylwester Dziedziuch 
Reviewed-by: Aleksandr Loktionov 
Tested-by: Tony Brelinski 
Signed-off-by: Tony Nguyen 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 16 +---
 drivers/net/ethernet/intel/i40e/i40e_main.c|  9 -
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c 
b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 26ba1f3eb2d85..9e81f85ee2d8d 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -4878,7 +4878,7 @@ static int i40e_set_priv_flags(struct net_device *dev, 
u32 flags)
enum i40e_admin_queue_err adq_err;
struct i40e_vsi *vsi = np->vsi;
struct i40e_pf *pf = vsi->back;
-   bool is_reset_needed;
+   u32 reset_needed = 0;
i40e_status status;
u32 i, j;
 
@@ -4923,9 +4923,11 @@ static int i40e_set_priv_flags(struct net_device *dev, 
u32 flags)
 flags_complete:
changed_flags = orig_flags ^ new_flags;
 
-   is_reset_needed = !!(changed_flags & (I40E_FLAG_VEB_STATS_ENABLED |
-   I40E_FLAG_LEGACY_RX | I40E_FLAG_SOURCE_PRUNING_DISABLED |
-   I40E_FLAG_DISABLE_FW_LLDP));
+   if (changed_flags & I40E_FLAG_DISABLE_FW_LLDP)
+   reset_needed = I40E_PF_RESET_AND_REBUILD_FLAG;
+   if (changed_flags & (I40E_FLAG_VEB_STATS_ENABLED |
+   I40E_FLAG_LEGACY_RX | I40E_FLAG_SOURCE_PRUNING_DISABLED))
+   reset_needed = BIT(__I40E_PF_RESET_REQUESTED);
 
/* Before we finalize any flag changes, we need to perform some
 * checks to ensure that the changes are supported and safe.
@@ -5057,7 +5059,7 @@ flags_complete:
case I40E_AQ_RC_EEXIST:
dev_warn(>pdev->dev,
 "FW LLDP agent is already 
running\n");
-   is_reset_needed = false;
+   reset_needed = 0;
break;
case I40E_AQ_RC_EPERM:
dev_warn(>pdev->dev,
@@ -5086,8 +5088,8 @@ flags_complete:
/* Issue reset to cause things to take effect, as additional bits
 * are added we will need to create a mask of bits requiring reset
 */
-   if (is_reset_needed)
-   i40e_do_reset(pf, BIT(__I40E_PF_RESET_REQUESTED), true);
+   if (reset_needed)
+   i40e_do_reset(pf, reset_needed, true);
 
return 0;
 }
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c 
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index bcfa6dcac29f7..b268adb3e1d44 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -8537,11 +8537,6 @@ void i40e_do_reset(struct i40e_pf *pf, u32 reset_flags, 
bool lock_acquired)
dev_dbg(>pdev->dev, "PFR requested\n");
i40e_handle_reset_warning(pf, lock_acquired);
 
-   dev_info(>pdev->dev,
-pf->flags & I40E_FLAG_DISABLE_FW_LLDP ?
-"FW LLDP is disabled\n" :
-"FW LLDP is enabled\n");
-
} else if (reset_flags & I40E_PF_RESET_AND_REBUILD_FLAG) {
/* Request a PF Reset
 *
@@ -8549,6 +8544,10 @@ void i40e_do_reset(struct i40e_pf *pf, u32 reset_flags, 
bool lock_acquired)
 */
i40e_prep_for_reset(pf, lock_acquired);
i40e_reset_and_rebuild(pf, true, lock_acquired);
+   dev_info(>pdev->dev,
+pf->flags & I40E_FLAG_DISABLE_FW_LLDP ?
+"FW LLDP is disabled\n" :
+"FW LLDP is enabled\n");
 
} else if (reset_flags & BIT_ULL(__I40E_REINIT_REQUESTED)) {
int v;
-- 
2.27.0





[PATCH 5.10 182/663] drm/amdgpu: toggle on DF Cstate after finishing xgmi injection

2021-03-01 Thread Greg Kroah-Hartman
From: Guchun Chen 

[ Upstream commit fe2d9f5abf19f2b3688b3b8da4e42f8d07886847 ]

Fixes: 5c23e9e05e42 ("drm/amdgpu: Update RAS XGMI error inject sequence")
Signed-off-by: Guchun Chen 
Reviewed-by: Hawking Zhang 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 82cd8e55595af..eb22a190c2423 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -844,7 +844,7 @@ static int amdgpu_ras_error_inject_xgmi(struct 
amdgpu_device *adev,
if (amdgpu_dpm_allow_xgmi_power_down(adev, true))
dev_warn(adev->dev, "Failed to allow XGMI power down");
 
-   if (amdgpu_dpm_set_df_cstate(adev, DF_CSTATE_DISALLOW))
+   if (amdgpu_dpm_set_df_cstate(adev, DF_CSTATE_ALLOW))
dev_warn(adev->dev, "Failed to allow df cstate");
 
return ret;
-- 
2.27.0





[PATCH 5.11 125/775] cxgb4/chtls/cxgbit: Keeping the max ofld immediate data size same in cxgb4 and ulds

2021-03-01 Thread Greg Kroah-Hartman
From: Ayush Sawal 

[ Upstream commit 2355a6773a2cb0d2dce13432dde78497f1d6617b ]

The Max imm data size in cxgb4 is not similar to the max imm data size
in the chtls. This caused an mismatch in output of is_ofld_imm() of
cxgb4 and chtls. So fixed this by keeping the max wreq size of imm data
same in both chtls and cxgb4 as MAX_IMM_OFLD_TX_DATA_WR_LEN.

As cxgb4's max imm. data value for ofld packets is changed to
MAX_IMM_OFLD_TX_DATA_WR_LEN. Using the same in cxgbit also.

Fixes: 36bedb3f2e5b8 ("crypto: chtls - Inline TLS record Tx")
Signed-off-by: Ayush Sawal 
Acked-by: Jakub Kicinski 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h|  3 +++
 drivers/net/ethernet/chelsio/cxgb4/sge.c  | 11 ---
 .../ethernet/chelsio/inline_crypto/chtls/chtls_cm.h   |  3 ---
 drivers/target/iscsi/cxgbit/cxgbit_target.c   |  3 +--
 4 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
index 1b49f2fa9b185..34546f5312eee 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
@@ -46,6 +46,9 @@
 #define MAX_ULD_QSETS 16
 #define MAX_ULD_NPORTS 4
 
+/* ulp_mem_io + ulptx_idata + payload + padding */
+#define MAX_IMM_ULPTX_WR_LEN (32 + 8 + 256 + 8)
+
 /* CPL message priority levels */
 enum {
CPL_PRIORITY_DATA = 0,  /* data messages */
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c 
b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index 196652a114c5f..3334c9e2152ab 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -2842,17 +2842,22 @@ int t4_mgmt_tx(struct adapter *adap, struct sk_buff 
*skb)
  * @skb: the packet
  *
  * Returns true if a packet can be sent as an offload WR with immediate
- * data.  We currently use the same limit as for Ethernet packets.
+ * data.
+ * FW_OFLD_TX_DATA_WR limits the payload to 255 bytes due to 8-bit field.
+ *  However, FW_ULPTX_WR commands have a 256 byte immediate only
+ *  payload limit.
  */
 static inline int is_ofld_imm(const struct sk_buff *skb)
 {
struct work_request_hdr *req = (struct work_request_hdr *)skb->data;
unsigned long opcode = FW_WR_OP_G(ntohl(req->wr_hi));
 
-   if (opcode == FW_CRYPTO_LOOKASIDE_WR)
+   if (unlikely(opcode == FW_ULPTX_WR))
+   return skb->len <= MAX_IMM_ULPTX_WR_LEN;
+   else if (opcode == FW_CRYPTO_LOOKASIDE_WR)
return skb->len <= SGE_MAX_WR_LEN;
else
-   return skb->len <= MAX_IMM_TX_PKT_LEN;
+   return skb->len <= MAX_IMM_OFLD_TX_DATA_WR_LEN;
 }
 
 /**
diff --git a/drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_cm.h 
b/drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_cm.h
index 47ba81e42f5d0..b1161bdeda4dc 100644
--- a/drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_cm.h
+++ b/drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_cm.h
@@ -50,9 +50,6 @@
 #define MIN_RCV_WND (24 * 1024U)
 #define LOOPBACK(x) (((x) & htonl(0xff00)) == htonl(0x7f00))
 
-/* ulp_mem_io + ulptx_idata + payload + padding */
-#define MAX_IMM_ULPTX_WR_LEN (32 + 8 + 256 + 8)
-
 /* for TX: a skb must have a headroom of at least TX_HEADER_LEN bytes */
 #define TX_HEADER_LEN \
(sizeof(struct fw_ofld_tx_data_wr) + sizeof(struct sge_opaque_hdr))
diff --git a/drivers/target/iscsi/cxgbit/cxgbit_target.c 
b/drivers/target/iscsi/cxgbit/cxgbit_target.c
index 9b3eb2e8c92ad..b926e1d6c7b8e 100644
--- a/drivers/target/iscsi/cxgbit/cxgbit_target.c
+++ b/drivers/target/iscsi/cxgbit/cxgbit_target.c
@@ -86,8 +86,7 @@ static int cxgbit_is_ofld_imm(const struct sk_buff *skb)
if (likely(cxgbit_skcb_flags(skb) & SKCBF_TX_ISO))
length += sizeof(struct cpl_tx_data_iso);
 
-#define MAX_IMM_TX_PKT_LEN 256
-   return length <= MAX_IMM_TX_PKT_LEN;
+   return length <= MAX_IMM_OFLD_TX_DATA_WR_LEN;
 }
 
 /*
-- 
2.27.0





[PATCH 5.10 138/663] fbdev: aty: SPARC64 requires FB_ATY_CT

2021-03-01 Thread Greg Kroah-Hartman
From: Randy Dunlap 

[ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ]

It looks like SPARC64 requires FB_ATY_CT to build without errors,
so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
instead of using "default y if SPARC64 && PCI", which is not strong
enough to prevent build errors.

As it currently is, FB_ATY_CT can be disabled, resulting in build
errors:

ERROR: modpost: "aty_postdividers" [drivers/video/fbdev/aty/atyfb.ko] undefined!
ERROR: modpost: "aty_ld_pll_ct" [drivers/video/fbdev/aty/atyfb.ko] undefined!

Reviewed-by: Geert Uytterhoeven 
Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev")
Signed-off-by: Randy Dunlap 
Cc: "David S. Miller" 
Cc: sparcli...@vger.kernel.org
Cc: Tomi Valkeinen 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Geert Uytterhoeven 
Signed-off-by: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20201127031752.10371-1-rdun...@infradead.org
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index cfb7f5612ef0f..4f02db65dedec 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1269,6 +1269,7 @@ config FB_ATY
select FB_CFB_IMAGEBLIT
select FB_BACKLIGHT if FB_ATY_BACKLIGHT
select FB_MACMODES if PPC
+   select FB_ATY_CT if SPARC64 && PCI
help
  This driver supports graphics boards with the ATI Mach64 chips.
  Say Y if you have such a graphics board.
@@ -1279,7 +1280,6 @@ config FB_ATY
 config FB_ATY_CT
bool "Mach64 CT/VT/GT/LT (incl. 3D RAGE) support"
depends on PCI && FB_ATY
-   default y if SPARC64 && PCI
help
  Say Y here to support use of ATI's 64-bit Rage boards (or other
  boards based on the Mach64 CT, VT, GT, and LT chipsets) as a
-- 
2.27.0





[PATCH 5.4 315/340] virtio/s390: implement virtio-ccw revision 2 correctly

2021-03-01 Thread Greg Kroah-Hartman
From: Cornelia Huck 

commit 182f709c5cff683e6732d04c78e328de0532284f upstream.

CCW_CMD_READ_STATUS was introduced with revision 2 of virtio-ccw,
and drivers should only rely on it being implemented when they
negotiated at least that revision with the device.

However, virtio_ccw_get_status() issued READ_STATUS for any
device operating at least at revision 1. If the device accepts
READ_STATUS regardless of the negotiated revision (which some
implementations like QEMU do, even though the spec currently does
not allow it), everything works as intended. While a device
rejecting the command should also be handled gracefully, we will
not be able to see any changes the device makes to the status,
such as setting NEEDS_RESET or setting the status to zero after
a completed reset.

We negotiated the revision to at most 1, as we never bumped the
maximum revision; let's do that now and properly send READ_STATUS
only if we are operating at least at revision 2.

Cc: sta...@vger.kernel.org
Fixes: 7d3ce5ab9430 ("virtio/s390: support READ_STATUS command for virtio-ccw")
Reviewed-by: Halil Pasic 
Signed-off-by: Cornelia Huck 
Signed-off-by: Vasily Gorbik 
Link: https://lore.kernel.org/r/20210216110645.1087321-1-coh...@redhat.com
Signed-off-by: Vasily Gorbik 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/s390/virtio/virtio_ccw.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/s390/virtio/virtio_ccw.c
+++ b/drivers/s390/virtio/virtio_ccw.c
@@ -117,7 +117,7 @@ struct virtio_rev_info {
 };
 
 /* the highest virtio-ccw revision we support */
-#define VIRTIO_CCW_REV_MAX 1
+#define VIRTIO_CCW_REV_MAX 2
 
 struct virtio_ccw_vq_info {
struct virtqueue *vq;
@@ -952,7 +952,7 @@ static u8 virtio_ccw_get_status(struct v
u8 old_status = vcdev->dma_area->status;
struct ccw1 *ccw;
 
-   if (vcdev->revision < 1)
+   if (vcdev->revision < 2)
return vcdev->dma_area->status;
 
ccw = ccw_device_dma_zalloc(vcdev->cdev, sizeof(*ccw));




[PATCH 5.10 380/663] RDMA/rtrs-srv: fix memory leak by missing kobject free

2021-03-01 Thread Greg Kroah-Hartman
From: Gioh Kim 

[ Upstream commit f7452a7e96c120d73100387d5f87de9fce7133cb ]

kmemleak reported an error as below:

  unreferenced object 0x8880674b7640 (size 64):
comm "kworker/4:1H", pid 113, jiffies 4296403507 (age 507.840s)
hex dump (first 32 bytes):
  69 70 3a 31 39 32 2e 31 36 38 2e 31 32 32 2e 31  ip:192.168.122.1
  31 30 40 69 70 3a 31 39 32 2e 31 36 38 2e 31 32  10@ip:192.168.12
backtrace:
  [<54413611>] kstrdup+0x2e/0x60
  [<78e3120a>] kobject_set_name_vargs+0x2f/0xb0
  [] kobject_init_and_add+0xb0/0x120
  [<62ba5e78>] rtrs_srv_create_sess_files+0x14c/0x314 [rtrs_server]
  [] rtrs_srv_info_req_done+0x5b1/0x800 [rtrs_server]
  [<8fc5aa8f>] __ib_process_cq+0x94/0x100 [ib_core]
  [] ib_cq_poll_work+0x32/0xc0 [ib_core]
  [] process_one_work+0x4bc/0x980
  [<16e5c96a>] worker_thread+0x78/0x5c0
  [] kthread+0x191/0x1e0
  [<6c9c0003>] ret_from_fork+0x3a/0x50

It is caused by the not-freed kobject of rtrs_srv_sess.  The kobject
embedded in rtrs_srv_sess has ref-counter 2 after calling
process_info_req(). Therefore it must call kobject_put twice.  Currently
it calls kobject_put only once at rtrs_srv_destroy_sess_files because
kobject_del removes the state_in_sysfs flag and then kobject_put in
free_sess() is not called.

This patch moves kobject_del() into free_sess() so that the kobject of
rtrs_srv_sess can be freed. And also this patch adds the missing call of
sysfs_remove_group() to clean-up the sysfs directory.

Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality")
Link: 
https://lore.kernel.org/r/20210212134525.103456-4-jinpu.w...@cloud.ionos.com
Signed-off-by: Gioh Kim 
Signed-off-by: Jack Wang 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c | 2 +-
 drivers/infiniband/ulp/rtrs/rtrs-srv.c   | 6 --
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c 
b/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c
index 6a320b9b480dd..1c5f97102103f 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c
@@ -308,7 +308,7 @@ void rtrs_srv_destroy_sess_files(struct rtrs_srv_sess *sess)
if (sess->kobj.state_in_sysfs) {
kobject_del(>stats->kobj_stats);
kobject_put(>stats->kobj_stats);
-   kobject_del(>kobj);
+   sysfs_remove_group(>kobj, _srv_sess_attr_group);
kobject_put(>kobj);
 
rtrs_srv_destroy_once_sysfs_root_folders(sess);
diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c 
b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
index 332418245dce3..717304c49d0c3 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
@@ -1492,10 +1492,12 @@ static bool __is_path_w_addr_exists(struct rtrs_srv 
*srv,
 
 static void free_sess(struct rtrs_srv_sess *sess)
 {
-   if (sess->kobj.state_in_sysfs)
+   if (sess->kobj.state_in_sysfs) {
+   kobject_del(>kobj);
kobject_put(>kobj);
-   else
+   } else {
kfree(sess);
+   }
 }
 
 static void rtrs_srv_close_work(struct work_struct *work)
-- 
2.27.0





[PATCH 5.11 031/775] ARM: dts: exynos: correct PMIC interrupt trigger level on Rinato

2021-03-01 Thread Greg Kroah-Hartman
From: Krzysztof Kozlowski 

[ Upstream commit 437ae60947716bb479e2f32466f49445c0509b1e ]

The Samsung PMIC datasheets describe the interrupt line as active low
with a requirement of acknowledge from the CPU.  Without specifying the
interrupt type in Devicetree, kernel might apply some fixed
configuration, not necessarily working for this hardware.

Fixes: faaf348ef468 ("ARM: dts: Add board dts file for exynos3250-rinato")
Signed-off-by: Krzysztof Kozlowski 
Tested-by: Marek Szyprowski 
Link: https://lore.kernel.org/r/20201210212903.216728-3-k...@kernel.org
Signed-off-by: Sasha Levin 
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index a26e3e582a7e7..d64ccf4b7d324 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -270,7 +270,7 @@
pmic@66 {
compatible = "samsung,s2mps14-pmic";
interrupt-parent = <>;
-   interrupts = <7 IRQ_TYPE_NONE>;
+   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
reg = <0x66>;
wakeup-source;
 
-- 
2.27.0





[PATCH 5.11 225/775] media: vidtv: psi: fix missing crc for PMT

2021-03-01 Thread Greg Kroah-Hartman
From: Daniel W. S. Almeida 

[ Upstream commit 0a933a7f73d6c545dcbecb4f7a92d272aef4417b ]

The PMT write function was refactored and this broke the CRC computation.

Fix it.

Fixes: db9569f67e2e ("media: vidtv: cleanup PMT write table function")
Signed-off-by: Daniel W. S. Almeida 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
---
 drivers/media/test-drivers/vidtv/vidtv_psi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/test-drivers/vidtv/vidtv_psi.c 
b/drivers/media/test-drivers/vidtv/vidtv_psi.c
index 4511a2a98405d..1724bb485e670 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_psi.c
+++ b/drivers/media/test-drivers/vidtv/vidtv_psi.c
@@ -1164,6 +1164,8 @@ u32 vidtv_psi_pmt_write_into(struct 
vidtv_psi_pmt_write_args *args)
struct vidtv_psi_desc *table_descriptor   = args->pmt->descriptor;
struct vidtv_psi_table_pmt_stream *stream = args->pmt->stream;
struct vidtv_psi_desc *stream_descriptor;
+   u32 crc = INITIAL_CRC;
+   u32 nbytes = 0;
struct header_write_args h_args = {
.dest_buf   = args->buf,
.dest_offset= args->offset,
@@ -1181,6 +1183,7 @@ u32 vidtv_psi_pmt_write_into(struct 
vidtv_psi_pmt_write_args *args)
.new_psi_section= false,
.is_crc = false,
.dest_buf_sz= args->buf_sz,
+   .crc= ,
};
struct desc_write_args d_args   = {
.dest_buf   = args->buf,
@@ -1193,8 +1196,6 @@ u32 vidtv_psi_pmt_write_into(struct 
vidtv_psi_pmt_write_args *args)
.pid= args->pid,
.dest_buf_sz= args->buf_sz,
};
-   u32 crc = INITIAL_CRC;
-   u32 nbytes = 0;
 
vidtv_psi_pmt_table_update_sec_len(args->pmt);
 
-- 
2.27.0





[PATCH 5.10 247/663] ima: Free IMA measurement buffer after kexec syscall

2021-03-01 Thread Greg Kroah-Hartman
From: Lakshmi Ramasubramanian 

[ Upstream commit f31e3386a4e92ba6eda7328cb508462956c94c64 ]

IMA allocates kernel virtual memory to carry forward the measurement
list, from the current kernel to the next kernel on kexec system call,
in ima_add_kexec_buffer() function.  This buffer is not freed before
completing the kexec system call resulting in memory leak.

Add ima_buffer field in "struct kimage" to store the virtual address
of the buffer allocated for the IMA measurement list.
Free the memory allocated for the IMA measurement list in
kimage_file_post_load_cleanup() function.

Signed-off-by: Lakshmi Ramasubramanian 
Suggested-by: Tyler Hicks 
Reviewed-by: Thiago Jung Bauermann 
Reviewed-by: Tyler Hicks 
Fixes: 7b8589cc29e7 ("ima: on soft reboot, save the measurement list")
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin 
---
 include/linux/kexec.h  | 5 +
 kernel/kexec_file.c| 5 +
 security/integrity/ima/ima_kexec.c | 2 ++
 3 files changed, 12 insertions(+)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 9e93bef529680..5f61389f5f361 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -300,6 +300,11 @@ struct kimage {
/* Information for loading purgatory */
struct purgatory_info purgatory_info;
 #endif
+
+#ifdef CONFIG_IMA_KEXEC
+   /* Virtual address of IMA measurement buffer for kexec syscall */
+   void *ima_buffer;
+#endif
 };
 
 /* kexec interface functions */
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index e21f6b9234f7a..7825adcc5efc3 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -166,6 +166,11 @@ void kimage_file_post_load_cleanup(struct kimage *image)
vfree(pi->sechdrs);
pi->sechdrs = NULL;
 
+#ifdef CONFIG_IMA_KEXEC
+   vfree(image->ima_buffer);
+   image->ima_buffer = NULL;
+#endif /* CONFIG_IMA_KEXEC */
+
/* See if architecture has anything to cleanup post load */
arch_kimage_file_post_load_cleanup(image);
 
diff --git a/security/integrity/ima/ima_kexec.c 
b/security/integrity/ima/ima_kexec.c
index 206ddcaa5c67a..e29bea3dd4ccd 100644
--- a/security/integrity/ima/ima_kexec.c
+++ b/security/integrity/ima/ima_kexec.c
@@ -129,6 +129,8 @@ void ima_add_kexec_buffer(struct kimage *image)
return;
}
 
+   image->ima_buffer = kexec_buffer;
+
pr_debug("kexec measurement buffer for the loaded kernel at 0x%lx.\n",
 kbuf.mem);
 }
-- 
2.27.0





[PATCH 5.10 260/663] clk: meson: clk-pll: fix initializing the old rate (fallback) for a PLL

2021-03-01 Thread Greg Kroah-Hartman
From: Martin Blumenstingl 

[ Upstream commit 2f290b7c67adf6459a17a4c978102af35cd62e4a ]

The "rate" parameter in meson_clk_pll_set_rate() contains the new rate.
Retrieve the old rate with clk_hw_get_rate() so we don't inifinitely try
to switch from the new rate to the same rate again.

Fixes: 7a29a869434e8b ("clk: meson: Add support for Meson clock controller")
Signed-off-by: Martin Blumenstingl 
Signed-off-by: Jerome Brunet 
Link: 
https://lore.kernel.org/r/20201226121556.975418-2-martin.blumensti...@googlemail.com
Signed-off-by: Sasha Levin 
---
 drivers/clk/meson/clk-pll.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
index b17a13e9337c4..9404609b5ebfa 100644
--- a/drivers/clk/meson/clk-pll.c
+++ b/drivers/clk/meson/clk-pll.c
@@ -371,7 +371,7 @@ static int meson_clk_pll_set_rate(struct clk_hw *hw, 
unsigned long rate,
if (parent_rate == 0 || rate == 0)
return -EINVAL;
 
-   old_rate = rate;
+   old_rate = clk_hw_get_rate(hw);
 
ret = meson_clk_get_pll_settings(rate, parent_rate, , , pll);
if (ret)
-- 
2.27.0





[PATCH 5.11 259/775] drm/mediatek: Fix aal size config

2021-03-01 Thread Greg Kroah-Hartman
[ Upstream commit 71dcadba34203d8dd35152e368720f977e9cdb81 ]

The orginal setting is not correct, fix it to follow hardware data sheet.
If keep this error setting, mt8173/mt8183 display ok
but mt8192 display abnormal.

Fixes: 0664d1392c26 ("drm/mediatek: Add AAL engine basic function")

Signed-off-by: Yongqiang Niu 
Signed-off-by: Chun-Kuang Hu 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 3064eac1a7507..7fcb717f256c9 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -180,7 +180,9 @@ static void mtk_aal_config(struct mtk_ddp_comp *comp, 
unsigned int w,
   unsigned int h, unsigned int vrefresh,
   unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
 {
-   mtk_ddp_write(cmdq_pkt, h << 16 | w, comp, DISP_AAL_SIZE);
+   struct mtk_ddp_comp_dev *priv = dev_get_drvdata(comp->dev);
+
+   mtk_ddp_write(cmdq_pkt, w << 16 | h, >cmdq_reg, priv->regs, 
DISP_AAL_SIZE);
 }
 
 static void mtk_aal_start(struct mtk_ddp_comp *comp)
-- 
2.27.0





[PATCH 5.11 296/775] ubifs: Fix memleak in ubifs_init_authentication

2021-03-01 Thread Greg Kroah-Hartman
From: Dinghao Liu 

[ Upstream commit 11b8ab3836454a2600e396f34731e491b661f9d5 ]

When crypto_shash_digestsize() fails, c->hmac_tfm
has not been freed before returning, which leads
to memleak.

Fixes: 49525e5eecca5 ("ubifs: Add helper functions for authentication support")
Signed-off-by: Dinghao Liu 
Reviewed-by: Zhihao Cheng 
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin 
---
 fs/ubifs/auth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ubifs/auth.c b/fs/ubifs/auth.c
index 51a7c8c2c3f0a..e564d5ff87816 100644
--- a/fs/ubifs/auth.c
+++ b/fs/ubifs/auth.c
@@ -327,7 +327,7 @@ int ubifs_init_authentication(struct ubifs_info *c)
ubifs_err(c, "hmac %s is bigger than maximum allowed hmac size 
(%d > %d)",
  hmac_name, c->hmac_desc_len, UBIFS_HMAC_ARR_SZ);
err = -EINVAL;
-   goto out_free_hash;
+   goto out_free_hmac;
}
 
err = crypto_shash_setkey(c->hmac_tfm, ukp->data, ukp->datalen);
-- 
2.27.0





[PATCH 5.10 220/663] ASoC: Intel: sof_sdw: add missing TGL_HDMI quirk for Dell SKU 0A3E

2021-03-01 Thread Greg Kroah-Hartman
From: Pierre-Louis Bossart 

[ Upstream commit 5ab3ff4d66960be766a544886667e7c002f17fd6 ]

We missed adding the TGL_HDMI quirk which is very much needed to
expose the 4 display pipelines and will be required on TGL topologies.

Fixes: e787f5b5b1406 ('ASoC: Intel: add support for new SoundWire hardware 
layout on TGL')
Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Guennadi Liakhovetski 
Reviewed-by: Kai Vehmanen 
Link: 
https://lore.kernel.org/r/20210204203312.27112-2-pierre-louis.boss...@linux.intel.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/intel/boards/sof_sdw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/soc/intel/boards/sof_sdw.c b/sound/soc/intel/boards/sof_sdw.c
index 3945cb61b95a0..07e72ca1dfbc9 100644
--- a/sound/soc/intel/boards/sof_sdw.c
+++ b/sound/soc/intel/boards/sof_sdw.c
@@ -54,7 +54,8 @@ static const struct dmi_system_id sof_sdw_quirk_table[] = {
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc"),
DMI_EXACT_MATCH(DMI_PRODUCT_SKU, "0A3E")
},
-   .driver_data = (void *)(SOF_RT711_JD_SRC_JD2 |
+   .driver_data = (void *)(SOF_SDW_TGL_HDMI |
+   SOF_RT711_JD_SRC_JD2 |
SOF_RT715_DAI_ID_FIX),
},
{
-- 
2.27.0





[PATCH 5.10 346/663] RDMA/rxe: Fix coding error in rxe_rcv_mcast_pkt

2021-03-01 Thread Greg Kroah-Hartman
From: Bob Pearson 

[ Upstream commit 8fc1b7027fc162738d5a85c82410e501a371a404 ]

rxe_rcv_mcast_pkt() in rxe_recv.c can leak SKBs in error path code. The
loop over the QPs attached to a multicast group creates new cloned SKBs
for all but the last QP in the list and passes the SKB and its clones to
rxe_rcv_pkt() for further processing. Any QPs that do not pass some checks
are skipped.  If the last QP in the list fails the tests the SKB is
leaked.  This patch checks if the SKB for the last QP was used and if not
frees it. Also removes a redundant loop invariant assignment.

Fixes: 8700e3e7c485 ("Soft RoCE driver")
Fixes: 71abf20b28ff ("RDMA/rxe: Handle skb_clone() failure in rxe_recv.c")
Link: https://lore.kernel.org/r/20210128174752.16128-1-rpear...@hpe.com
Signed-off-by: Bob Pearson 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/sw/rxe/rxe_recv.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/infiniband/sw/rxe/rxe_recv.c 
b/drivers/infiniband/sw/rxe/rxe_recv.c
index db0ee5c3962e4..cb69a125e2806 100644
--- a/drivers/infiniband/sw/rxe/rxe_recv.c
+++ b/drivers/infiniband/sw/rxe/rxe_recv.c
@@ -257,7 +257,6 @@ static void rxe_rcv_mcast_pkt(struct rxe_dev *rxe, struct 
sk_buff *skb)
 
list_for_each_entry(mce, >qp_list, qp_list) {
qp = mce->qp;
-   pkt = SKB_TO_PKT(skb);
 
/* validate qp for incoming packet */
err = check_type_state(rxe, pkt, qp);
@@ -269,12 +268,18 @@ static void rxe_rcv_mcast_pkt(struct rxe_dev *rxe, struct 
sk_buff *skb)
continue;
 
/* for all but the last qp create a new clone of the
-* skb and pass to the qp.
+* skb and pass to the qp. If an error occurs in the
+* checks for the last qp in the list we need to
+* free the skb since it hasn't been passed on to
+* rxe_rcv_pkt() which would free it later.
 */
-   if (mce->qp_list.next != >qp_list)
+   if (mce->qp_list.next != >qp_list) {
per_qp_skb = skb_clone(skb, GFP_ATOMIC);
-   else
+   } else {
per_qp_skb = skb;
+   /* show we have consumed the skb */
+   skb = NULL;
+   }
 
if (unlikely(!per_qp_skb))
continue;
@@ -289,9 +294,8 @@ static void rxe_rcv_mcast_pkt(struct rxe_dev *rxe, struct 
sk_buff *skb)
 
rxe_drop_ref(mcg);  /* drop ref from rxe_pool_get_key. */
 
-   return;
-
 err1:
+   /* free skb if not consumed */
kfree_skb(skb);
 }
 
-- 
2.27.0





[PATCH 5.10 205/663] drm/nouveau: bail out of nouveau_channel_new if channel init fails

2021-03-01 Thread Greg Kroah-Hartman
From: Frantisek Hrbata 

[ Upstream commit eaba3b28401f50e22d64351caa8afe8d29509f27 ]

Unprivileged user can crash kernel by using DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC
ioctl. This was reported by trinity[1] fuzzer.

[   71.073906] nouveau :01:00.0: crashme[1329]: channel failed to 
initialise, -17
[   71.081730] BUG: kernel NULL pointer dereference, address: 00a0
[   71.088928] #PF: supervisor read access in kernel mode
[   71.094059] #PF: error_code(0x) - not-present page
[   71.099189] PGD 119590067 P4D 119590067 PUD 1054f5067 PMD 0
[   71.104842] Oops:  [#1] SMP NOPTI
[   71.108498] CPU: 2 PID: 1329 Comm: crashme Not tainted 5.8.0-rc6+ #2
[   71.114993] Hardware name: AMD Pike/Pike, BIOS RPK1506A 09/03/2014
[   71.121213] RIP: 0010:nouveau_abi16_ioctl_channel_alloc+0x108/0x380 [nouveau]
[   71.128339] Code: 48 89 9d f0 00 00 00 41 8b 4c 24 04 41 8b 14 24 45 31 c0 
4c 8d 4b 10 48 89 ee 4c 89 f7 e8 10 11 00 00 85 c0 75 78 48 8b 43 10 <8b> 90 a0 
00 00 00 41 89 54 24 08 80 7d 3d 05 0f 86 bb 01 00 00 41
[   71.147074] RSP: 0018:b4a1809cfd38 EFLAGS: 00010246
[   71.152526] RAX:  RBX: 98cedbaa1d20 RCX: 03bf
[   71.159651] RDX: 03be RSI:  RDI: 00030160
[   71.166774] RBP: 98cee776de00 R08: dc0144198a08 R09: 98ceeefd4000
[   71.173901] R10: 98cee7e81780 R11: 0001 R12: b4a1809cfe08
[   71.181214] R13: 98cee776d000 R14: 98cec519e000 R15: 98cee776def0
[   71.188339] FS:  7fd926250500() GS:98ceeac8() 
knlGS:
[   71.196418] CS:  0010 DS:  ES:  CR0: 80050033
[   71.202155] CR2: 00a0 CR3: 000106622000 CR4: 000406e0
[   71.209297] Call Trace:
[   71.211777]  ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau]
[   71.218053]  drm_ioctl_kernel+0xac/0xf0 [drm]
[   71.222421]  drm_ioctl+0x211/0x3c0 [drm]
[   71.226379]  ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau]
[   71.232500]  nouveau_drm_ioctl+0x57/0xb0 [nouveau]
[   71.237285]  ksys_ioctl+0x86/0xc0
[   71.240595]  __x64_sys_ioctl+0x16/0x20
[   71.244340]  do_syscall_64+0x4c/0x90
[   71.248110]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   71.253162] RIP: 0033:0x7fd925d4b88b
[   71.256731] Code: Bad RIP value.
[   71.259955] RSP: 002b:7ffc743592d8 EFLAGS: 0206 ORIG_RAX: 
0010
[   71.267514] RAX: ffda RBX:  RCX: 7fd925d4b88b
[   71.274637] RDX: 00601080 RSI: c0586442 RDI: 0003
[   71.281986] RBP: 7ffc74359340 R08: 7fd926016ce0 R09: 7fd926016ce0
[   71.289111] R10: 0003 R11: 0206 R12: 00400620
[   71.296235] R13: 7ffc74359420 R14:  R15: 
[   71.303361] Modules linked in: rfkill sunrpc snd_hda_codec_realtek 
snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg 
snd_hda_codec snd_hda_core edac_mce_amd snd_hwdep kvm_amd snd_seq ccp 
snd_seq_device snd_pcm kvm snd_timer snd irqbypass soundcore sp5100_tco pcspkr 
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel wmi_bmof joydev i2c_piix4 
fam15h_power k10temp acpi_cpufreq ip_tables xfs libcrc32c sd_mod t10_pi sg 
nouveau video mxm_wmi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect 
sysimgblt fb_sys_fops ttm broadcom bcm_phy_lib ata_generic ahci drm e1000 
crc32c_intel libahci serio_raw tg3 libata firewire_ohci firewire_core wmi 
crc_itu_t dm_mirror dm_region_hash dm_log dm_mod
[   71.365269] CR2: 00a0

simplified reproducer
-8<
/*
 * gcc -o crashme crashme.c
 * ./crashme /dev/dri/renderD128
 */

struct drm_nouveau_channel_alloc {
uint32_t fb_ctxdma_handle;
uint32_t tt_ctxdma_handle;

int  channel;
uint32_t pushbuf_domains;

/* Notifier memory */
uint32_t notifier_handle;

/* DRM-enforced subchannel assignments */
struct {
uint32_t handle;
uint32_t grclass;
} subchan[8];
uint32_t nr_subchan;
};

static struct drm_nouveau_channel_alloc channel;

int main(int argc, char *argv[]) {
int fd;
int rv;

if (argc != 2)
die("usage: %s ", 0, argv[0]);

if ((fd = open(argv[1], O_RDONLY)) == -1)
die("open %s", errno, argv[1]);

if (ioctl(fd, DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC, ) == -1 &&
errno == EACCES)
die("ioctl %s", errno, argv[1]);

close(fd);

printf("PASS\n");

return 0;
}
-8<

[1] https://github.com/kernelslacker/trinity

Fixes: eeaf06ac1a55 ("drm/nouveau/svm: initial support for shared virtual 
memory")
Signed-off-by: Frantisek Hrbata 
Reviewed-by: Karol Herbst 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
---
 

[PATCH 5.10 499/663] phy: lantiq: rcu-usb2: wait after clock enable

2021-03-01 Thread Greg Kroah-Hartman
From: Mathias Kresin 

commit 36acd5e24e3000691fb8d1ee31cf959cb1582d35 upstream.

Commit 65dc2e725286 ("usb: dwc2: Update Core Reset programming flow.")
revealed that the phy isn't ready immediately after enabling it's
clocks. The dwc2_check_core_version() fails and the dwc2 usb driver
errors out.

Add a short delay to let the phy get up and running. There isn't any
documentation how much time is required, the value was chosen based on
tests.

Signed-off-by: Mathias Kresin 
Acked-by: Hauke Mehrtens 
Acked-by: Martin Blumenstingl 
Cc:  # v5.7+
Link: https://lore.kernel.org/r/20210107224901.2102479-1-...@kresin.me
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/phy/lantiq/phy-lantiq-rcu-usb2.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
+++ b/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
@@ -124,8 +124,16 @@ static int ltq_rcu_usb2_phy_power_on(str
reset_control_deassert(priv->phy_reset);
 
ret = clk_prepare_enable(priv->phy_gate_clk);
-   if (ret)
+   if (ret) {
dev_err(dev, "failed to enable PHY gate\n");
+   return ret;
+   }
+
+   /*
+* at least the xrx200 usb2 phy requires some extra time to be
+* operational after enabling the clock
+*/
+   usleep_range(100, 200);
 
return ret;
 }




[PATCH 5.11 097/775] ath9k: fix data bus crash when setting nf_override via debugfs

2021-03-01 Thread Greg Kroah-Hartman
From: Linus Lüssing 

[ Upstream commit 12c8f3d1cdd84f01ee777b756db9dddc1f1c9d17 ]

When trying to set the noise floor via debugfs, a "data bus error"
crash like the following can happen:

[   88.433133] Data bus error, epc == 80221c28, ra == 83314e60
[   88.438895] Oops[#1]:
[   88.441246] CPU: 0 PID: 7263 Comm: sh Not tainted 4.14.195 #0
[   88.447174] task: 838a1c20 task.stack: 82d5e000
[   88.451847] $ 0   :  0030 deadc0de 83141de4
[   88.457248] $ 4   : b810a2c4 a2c4 83230fd4 
[   88.462652] $ 8   : 000a  0001 
[   88.468055] $12   : 7f8ef318   77f802a0
[   88.473457] $16   : 83230080 0002 001b 83230080
[   88.478861] $20   : 83a1c3f8 00841000 77f7adb0 ff92
[   88.484263] $24   : 0fa4 77edd860
[   88.489665] $28   : 82d5e000 82d5fda8  83314e60
[   88.495070] Hi: 
[   88.498044] Lo: 
[   88.501040] epc   : 80221c28 ioread32+0x8/0x10
[   88.505671] ra: 83314e60 ath9k_hw_loadnf+0x88/0x520 [ath9k_hw]
[   88.512049] Status: 1000fc03 KERNEL EXL IE
[   88.516369] Cause : 5080801c (ExcCode 07)
[   88.520508] PrId  : 00019374 (MIPS 24Kc)
[   88.524556] Modules linked in: ath9k ath9k_common pppoe ppp_async l2tp_ppp 
cdc_mbim batman_adv ath9k_hw ath sr9700 smsc95xx sierra_net rndis_host qmi_wwan 
pppox ppp_generic pl2303 nf_conntrack_ipv6 mcs7830 mac80211 kalmia iptable_nat 
ipt_REJECT ipt_MASQUERADE huawei_cdc_ncm ftdi_sio dm9601 cfg80211 cdc_subset 
cdc_ncm cdc_ether cdc_eem ax88179_178a asix xt_time xt_tcpudp xt_tcpmss 
xt_statistic xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length 
xt_hl xt_ecn xt_dscp xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_NETMAP 
xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CLASSIFY usbserial usbnet usbhid slhc 
rtl8150 r8152 pegasus nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 
nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table 
nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack
[   88.597894]  libcrc32c kaweth iptable_mangle iptable_filter ipt_ECN ipheth 
ip_tables hso hid_generic crc_ccitt compat cdc_wdm cdc_acm br_netfilter hid 
evdev input_core nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter 
ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 l2tp_netlink l2tp_core 
udp_tunnel ip6_udp_tunnel xfrm6_mode_tunnel xfrm6_mode_transport 
xfrm6_mode_beet ipcomp6 xfrm6_tunnel esp6 ah6 xfrm4_tunnel xfrm4_mode_tunnel 
xfrm4_mode_transport xfrm4_mode_beet ipcomp esp4 ah4 tunnel6 tunnel4 tun 
xfrm_user xfrm_ipcomp af_key xfrm_algo sha256_generic sha1_generic 
jitterentropy_rng drbg md5 hmac echainiv des_generic deflate zlib_inflate 
zlib_deflate cbc authenc crypto_acompress ehci_platform ehci_hcd 
gpio_button_hotplug usbcore nls_base usb_common crc16 mii aead crypto_null 
cryptomgr crc32c_generic
[   88.671671]  crypto_hash
[   88.674292] Process sh (pid: 7263, threadinfo=82d5e000, task=838a1c20, 
tls=77f81efc)
[   88.682279] Stack : 8060 0008 0200    
 0002
[   88.690916] 8050 83230080 82d5fe22 00841000 77f7adb0  
 83156858
[   88.699553]  8352fa00 83ad62b0 835302a8  300a00f8 
0003 82d5fe38
[   88.708190] 82d5fef4 0001 77f54dc4 77f8 77f7adb0 c79fe901 
 
[   88.716828] 8051 0002 00841000 77f54dc4 77f8 801ce4cc 
000b 41824292
[   88.725465] ...
[   88.727994] Call Trace:
[   88.730532] [<80221c28>] ioread32+0x8/0x10
[   88.734765] Code:   8c82  000f <03e8>   08088708 
   aca4  03e8
[   88.744846]
[   88.746464] ---[ end trace db226b2de1b69b9e ]---
[   88.753477] Kernel panic - not syncing: Fatal exception
[   88.759981] Rebooting in 3 seconds..

The "REG_READ(ah, AR_PHY_AGC_CONTROL)" in ath9k_hw_loadnf() does not
like being called when the hardware is asleep, leading to this crash.

The easiest way to reproduce this is trying to set nf_override while
the hardware is down:

  $ ip link set down dev wlan0
  $ echo "-85" > /sys/kernel/debug/ieee80211/phy0/ath9k/nf_override

Fixing this crash by waking the hardware up before trying to set the
noise floor. Similar to what other ath9k debugfs files do.

Tested on a Lima board from 8devices, which has a QCA 4531 chipset.

Fixes: b90189759a7f ("ath9k: add noise floor override option")
Cc: Simon Wunderlich 
Signed-off-by: Linus Lüssing 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20210209184352.4272-1-linus.luess...@c0d3.blue
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/ath/ath9k/debug.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/debug.c 
b/drivers/net/wireless/ath/ath9k/debug.c
index 017a43bc400ca..4c81b1d7f4171 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -1223,8 +1223,11 @@ static ssize_t write_file_nf_override(struct file *file,
 

[PATCH 5.10 240/663] nvmet-tcp: fix receive data digest calculation for multiple h2cdata PDUs

2021-03-01 Thread Greg Kroah-Hartman
From: Sagi Grimberg 

[ Upstream commit fda871c0ba5d2eed2cd1c881573168129da70058 ]

When a host sends multiple h2cdata PDUs for a single command, we
should verify the data digest calculation per PDU and not
per command.

Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver")
Reported-by: Narayan Ayalasomayajula 
Tested-by: Narayan Ayalasomayajula 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/target/tcp.c | 31 ---
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c
index aacf06f0b4312..577ce7d403ae9 100644
--- a/drivers/nvme/target/tcp.c
+++ b/drivers/nvme/target/tcp.c
@@ -379,7 +379,7 @@ err:
return NVME_SC_INTERNAL;
 }
 
-static void nvmet_tcp_ddgst(struct ahash_request *hash,
+static void nvmet_tcp_send_ddgst(struct ahash_request *hash,
struct nvmet_tcp_cmd *cmd)
 {
ahash_request_set_crypt(hash, cmd->req.sg,
@@ -387,6 +387,23 @@ static void nvmet_tcp_ddgst(struct ahash_request *hash,
crypto_ahash_digest(hash);
 }
 
+static void nvmet_tcp_recv_ddgst(struct ahash_request *hash,
+   struct nvmet_tcp_cmd *cmd)
+{
+   struct scatterlist sg;
+   struct kvec *iov;
+   int i;
+
+   crypto_ahash_init(hash);
+   for (i = 0, iov = cmd->iov; i < cmd->nr_mapped; i++, iov++) {
+   sg_init_one(, iov->iov_base, iov->iov_len);
+   ahash_request_set_crypt(hash, , NULL, iov->iov_len);
+   crypto_ahash_update(hash);
+   }
+   ahash_request_set_crypt(hash, NULL, (void *)>exp_ddgst, 0);
+   crypto_ahash_final(hash);
+}
+
 static void nvmet_setup_c2h_data_pdu(struct nvmet_tcp_cmd *cmd)
 {
struct nvme_tcp_data_pdu *pdu = cmd->data_pdu;
@@ -411,7 +428,7 @@ static void nvmet_setup_c2h_data_pdu(struct nvmet_tcp_cmd 
*cmd)
 
if (queue->data_digest) {
pdu->hdr.flags |= NVME_TCP_F_DDGST;
-   nvmet_tcp_ddgst(queue->snd_hash, cmd);
+   nvmet_tcp_send_ddgst(queue->snd_hash, cmd);
}
 
if (cmd->queue->hdr_digest) {
@@ -1060,7 +1077,7 @@ static void nvmet_tcp_prep_recv_ddgst(struct 
nvmet_tcp_cmd *cmd)
 {
struct nvmet_tcp_queue *queue = cmd->queue;
 
-   nvmet_tcp_ddgst(queue->rcv_hash, cmd);
+   nvmet_tcp_recv_ddgst(queue->rcv_hash, cmd);
queue->offset = 0;
queue->left = NVME_TCP_DIGEST_LENGTH;
queue->rcv_state = NVMET_TCP_RECV_DDGST;
@@ -1081,14 +1098,14 @@ static int nvmet_tcp_try_recv_data(struct 
nvmet_tcp_queue *queue)
cmd->rbytes_done += ret;
}
 
+   if (queue->data_digest) {
+   nvmet_tcp_prep_recv_ddgst(cmd);
+   return 0;
+   }
nvmet_tcp_unmap_pdu_iovec(cmd);
 
if (!(cmd->flags & NVMET_TCP_F_INIT_FAILED) &&
cmd->rbytes_done == cmd->req.transfer_len) {
-   if (queue->data_digest) {
-   nvmet_tcp_prep_recv_ddgst(cmd);
-   return 0;
-   }
cmd->req.execute(>req);
}
 
-- 
2.27.0





[PATCH 5.10 175/663] drm/sun4i: tcon: fix inverted DCLK polarity

2021-03-01 Thread Greg Kroah-Hartman
From: Giulio Benetti 

[ Upstream commit 67f4aeb2b41a0629abde3794d463547f60b0cbdd ]

During commit 88bc4178568b ("drm: Use new
DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") DRM_BUS_FLAG_*
macros have been changed to avoid ambiguity but just because of this
ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning
_SAMPLE_ not _DRIVE_. This leads to DLCK inversion and need to fix but
instead of swapping phase values, let's adopt an easier approach Maxime
suggested:
It turned out that bit 26 of SUN4I_TCON0_IO_POL_REG is dedicated to
invert DCLK polarity and this makes things really easier than before. So
let's handle DCLK polarity by adding SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE
as bit 26 and activating according to bus_flags the same way it is done
for all the other signals polarity.

Fixes: 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE 
flags")
Suggested-by: Maxime Ripard 
Signed-off-by: Giulio Benetti 
Signed-off-by: Maxime Ripard 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20210114081732.9386-1-giulio.bene...@benettiengineering.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 21 ++---
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  1 +
 2 files changed, 3 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 1e643bc7e786a..9f06dec0fc61d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -569,30 +569,13 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE;
 
-   /*
-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
-   if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
-   clk_set_phase(tcon->dclk, 240);
-
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
-   clk_set_phase(tcon->dclk, 0);
+   val |= SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE;
 
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
   SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
   SUN4I_TCON0_IO_POL_VSYNC_POSITIVE |
+  SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE |
   SUN4I_TCON0_IO_POL_DE_NEGATIVE,
   val);
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index ee555318e3c2f..e624f6977eb84 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -113,6 +113,7 @@
 #define SUN4I_TCON0_IO_POL_REG 0x88
 #define SUN4I_TCON0_IO_POL_DCLK_PHASE(phase)   ((phase & 3) << 28)
 #define SUN4I_TCON0_IO_POL_DE_NEGATIVE BIT(27)
+#define SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE  BIT(26)
 #define SUN4I_TCON0_IO_POL_HSYNC_POSITIVE  BIT(25)
 #define SUN4I_TCON0_IO_POL_VSYNC_POSITIVE  BIT(24)
 
-- 
2.27.0





[PATCH 5.11 209/775] crypto: bcm - Rename struct device_private to bcm_device_private

2021-03-01 Thread Greg Kroah-Hartman
From: Jiri Olsa 

[ Upstream commit f7f2b43eaf6b4cfe54c75100709be31d5c4b52c8 ]

Renaming 'struct device_private' to 'struct bcm_device_private',
because it clashes with 'struct device_private' from
'drivers/base/base.h'.

While it's not a functional problem, it's causing two distinct
type hierarchies in BTF data. It also breaks build with options:
  CONFIG_DEBUG_INFO_BTF=y
  CONFIG_CRYPTO_DEV_BCM_SPU=y

as reported by Qais Yousef [1].

[1] https://lore.kernel.org/lkml/20201229151352.6hzmjvu3qh6p2qgg@e107158-lin/

Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
Signed-off-by: Jiri Olsa 
Tested-by: Qais Yousef 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
---
 drivers/crypto/bcm/cipher.c | 2 +-
 drivers/crypto/bcm/cipher.h | 4 ++--
 drivers/crypto/bcm/util.c   | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index 30390a7324b29..0e5537838ef36 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -42,7 +42,7 @@
 
 /* = Device Structure == */
 
-struct device_private iproc_priv;
+struct bcm_device_private iproc_priv;
 
 /*  Parameters = */
 
diff --git a/drivers/crypto/bcm/cipher.h b/drivers/crypto/bcm/cipher.h
index 0ad5892b445d3..71281a3bdbdc0 100644
--- a/drivers/crypto/bcm/cipher.h
+++ b/drivers/crypto/bcm/cipher.h
@@ -420,7 +420,7 @@ struct spu_hw {
u32 num_chan;
 };
 
-struct device_private {
+struct bcm_device_private {
struct platform_device *pdev;
 
struct spu_hw spu;
@@ -467,6 +467,6 @@ struct device_private {
struct mbox_chan **mbox;
 };
 
-extern struct device_private iproc_priv;
+extern struct bcm_device_private iproc_priv;
 
 #endif
diff --git a/drivers/crypto/bcm/util.c b/drivers/crypto/bcm/util.c
index 2b304fc780595..77aeedb840555 100644
--- a/drivers/crypto/bcm/util.c
+++ b/drivers/crypto/bcm/util.c
@@ -348,7 +348,7 @@ char *spu_alg_name(enum spu_cipher_alg alg, enum 
spu_cipher_mode mode)
 static ssize_t spu_debugfs_read(struct file *filp, char __user *ubuf,
size_t count, loff_t *offp)
 {
-   struct device_private *ipriv;
+   struct bcm_device_private *ipriv;
char *buf;
ssize_t ret, out_offset, out_count;
int i;
-- 
2.27.0





[PATCH 5.10 538/663] btrfs: account for new extents being deleted in total_bytes_pinned

2021-03-01 Thread Greg Kroah-Hartman
From: Josef Bacik 

commit 81e75ac74ecba929d1e922bf93f9fc467232e39f upstream.

My recent patch set "A variety of lock contention fixes", found here

https://lore.kernel.org/linux-btrfs/cover.1608319304.git.jo...@toxicpanda.com/
(Tracked in https://github.com/btrfs/linux/issues/86)

that reduce lock contention on the extent root by running delayed refs
less often resulted in a regression in generic/371.  This test
fallocate()'s the fs until it's full, deletes all the files, and then
tries to fallocate() until full again.

Before these patches we would run all of the delayed refs during
flushing, and then would commit the transaction because we had plenty of
pinned space to recover in order to allocate.  However my patches made
it so we weren't running the delayed refs as aggressively, which meant
that we appeared to have less pinned space when we were deciding to
commit the transaction.

We use the space_info->total_bytes_pinned to approximate how much space
we have pinned.  It's approximate because if we remove a reference to an
extent we may free it, but there may be more references to it than we
know of at that point, but we account it as pinned at the creation time,
and then it's properly accounted when the delayed ref runs.

The way we account for pinned space is if the
delayed_ref_head->total_ref_mod is < 0, because that is clearly a
freeing option.  However there is another case, and that is where
->total_ref_mod == 0 && ->must_insert_reserved == 1.

When we allocate a new extent, we have ->total_ref_mod == 1 and we have
->must_insert_reserved == 1.  This is used to indicate that it is a
brand new extent and will need to have its extent entry added before we
modify any references on the delayed ref head.  But if we subsequently
remove that extent reference, our ->total_ref_mod will be 0, and that
space will be pinned and freed.  Accounting for this case properly
allows for generic/371 to pass with my delayed refs patches applied.

It's important to note that this problem exists without the referenced
patches, it just was uncovered by them.

CC: sta...@vger.kernel.org # 5.10
Reviewed-by: Nikolay Borisov 
Signed-off-by: Josef Bacik 
Signed-off-by: David Sterba 
Signed-off-by: Greg Kroah-Hartman 
---
 fs/btrfs/delayed-ref.c |5 +
 fs/btrfs/extent-tree.c |   33 +++--
 2 files changed, 24 insertions(+), 14 deletions(-)

--- a/fs/btrfs/delayed-ref.c
+++ b/fs/btrfs/delayed-ref.c
@@ -732,11 +732,16 @@ static noinline void update_existing_hea
 * 2. We were negative and went to 0 or positive, so no longer can say
 *that the space would be pinned, decrement our counter from the
 *total_bytes_pinned counter.
+* 3. We are now at 0 and have ->must_insert_reserved set, which means
+*this was a new allocation and then we dropped it, and thus must
+*add our space to the total_bytes_pinned counter.
 */
if (existing->total_ref_mod < 0 && old_ref_mod >= 0)
btrfs_mod_total_bytes_pinned(fs_info, flags, 
existing->num_bytes);
else if (existing->total_ref_mod >= 0 && old_ref_mod < 0)
btrfs_mod_total_bytes_pinned(fs_info, flags, 
-existing->num_bytes);
+   else if (existing->total_ref_mod == 0 && existing->must_insert_reserved)
+   btrfs_mod_total_bytes_pinned(fs_info, flags, 
existing->num_bytes);
 
spin_unlock(>lock);
 }
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -1755,23 +1755,28 @@ void btrfs_cleanup_ref_head_accounting(s
 {
int nr_items = 1;   /* Dropping this ref head update. */
 
-   if (head->total_ref_mod < 0) {
+   /*
+* We had csum deletions accounted for in our delayed refs rsv, we need
+* to drop the csum leaves for this update from our delayed_refs_rsv.
+*/
+   if (head->total_ref_mod < 0 && head->is_data) {
+   spin_lock(_refs->lock);
+   delayed_refs->pending_csums -= head->num_bytes;
+   spin_unlock(_refs->lock);
+   nr_items += btrfs_csum_bytes_to_leaves(fs_info, 
head->num_bytes);
+   }
+
+   /*
+* We were dropping refs, or had a new ref and dropped it, and thus must
+* adjust down our total_bytes_pinned, the space may or may not have
+* been pinned and so is accounted for properly in the pinned space by
+* now.
+*/
+   if (head->total_ref_mod < 0 ||
+   (head->total_ref_mod == 0 && head->must_insert_reserved)) {
u64 flags = btrfs_ref_head_to_space_flags(head);
 
btrfs_mod_total_bytes_pinned(fs_info, flags, -head->num_bytes);
-
-   /*
-* We had csum deletions accounted for in our delayed refs rsv,
-* we need to drop the csum leaves for this update from our
-* delayed_refs_rsv.
-*/
-   if (head->is_data) {
-   

[PATCH 5.4 326/340] dm era: Fix bitset memory leaks

2021-03-01 Thread Greg Kroah-Hartman
From: Nikos Tsironis 

commit 904e6b266619c2da5c58b5dce14ae30629e39645 upstream.

Deallocate the memory allocated for the in-core bitsets when destroying
the target and in error paths.

Fixes: eec40579d84873 ("dm: add era target")
Cc: sta...@vger.kernel.org # v3.15+
Signed-off-by: Nikos Tsironis 
Reviewed-by: Ming-Hung Tsai 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/md/dm-era-target.c |6 ++
 1 file changed, 6 insertions(+)

--- a/drivers/md/dm-era-target.c
+++ b/drivers/md/dm-era-target.c
@@ -47,6 +47,7 @@ struct writeset {
 static void writeset_free(struct writeset *ws)
 {
vfree(ws->bits);
+   ws->bits = NULL;
 }
 
 static int setup_on_disk_bitset(struct dm_disk_bitset *info,
@@ -811,6 +812,8 @@ static struct era_metadata *metadata_ope
 
 static void metadata_close(struct era_metadata *md)
 {
+   writeset_free(>writesets[0]);
+   writeset_free(>writesets[1]);
destroy_persistent_data_objects(md);
kfree(md);
 }
@@ -848,6 +851,7 @@ static int metadata_resize(struct era_me
r = writeset_alloc(>writesets[1], *new_size);
if (r) {
DMERR("%s: writeset_alloc failed for writeset 1", __func__);
+   writeset_free(>writesets[0]);
return r;
}
 
@@ -858,6 +862,8 @@ static int metadata_resize(struct era_me
, >era_array_root);
if (r) {
DMERR("%s: dm_array_resize failed", __func__);
+   writeset_free(>writesets[0]);
+   writeset_free(>writesets[1]);
return r;
}
 




[PATCH 5.11 046/775] arm64: dts: allwinner: A64: properly connect USB PHY to port 0

2021-03-01 Thread Greg Kroah-Hartman
From: Andre Przywara 

[ Upstream commit cc72570747e43335f4933a24dd74d5653639176a ]

In recent Allwinner SoCs the first USB host controller (HCI0) shares
the first PHY with the MUSB controller. Probably to make this sharing
work, we were avoiding to declare this in the DT. This has two
shortcomings:
- U-Boot (which uses the same .dts) cannot use this port in host mode
  without a PHY linked, so we were loosing one USB port there.
- It requires the MUSB driver to be enabled and loaded, although we
  don't actually use it.

To avoid those issues, let's add this PHY link to the A64 .dtsi file.
After all PHY port 0 *is* connected to HCI0, so we should describe
it as this. Remove the part from the Pinebook DTS which already had
this property.

This makes it work in U-Boot, also improves compatiblity when no MUSB
driver is loaded (for instance in distribution installers).

Fixes: dc03a047df1d ("arm64: allwinner: a64: add EHCI0/OHCI0 nodes to A64 DTSI")
Signed-off-by: Andre Przywara 
Acked-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20210113152630.28810-2-andre.przyw...@arm.com
Signed-off-by: Sasha Levin 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts | 4 
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
index 896f34fd9fc3a..d07cf05549c32 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
@@ -126,8 +126,6 @@
 };
 
  {
-   phys = < 0>;
-   phy-names = "usb";
status = "okay";
 };
 
@@ -177,8 +175,6 @@
 };
 
  {
-   phys = < 0>;
-   phy-names = "usb";
status = "okay";
 };
 
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 51cc30e84e261..19e9b8ca8432f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -593,6 +593,8 @@
 < CLK_USB_OHCI0>;
resets = < RST_BUS_OHCI0>,
 < RST_BUS_EHCI0>;
+   phys = < 0>;
+   phy-names = "usb";
status = "disabled";
};
 
@@ -603,6 +605,8 @@
clocks = < CLK_BUS_OHCI0>,
 < CLK_USB_OHCI0>;
resets = < RST_BUS_OHCI0>;
+   phys = < 0>;
+   phy-names = "usb";
status = "disabled";
};
 
-- 
2.27.0





[PATCH 5.10 464/663] KVM: SVM: Intercept INVPCID when its disabled to inject #UD

2021-03-01 Thread Greg Kroah-Hartman
From: Sean Christopherson 

[ Upstream commit 0a8ed2eaac102c746d8d114f2787f06cb3e55dfb ]

Intercept INVPCID if it's disabled in the guest, even when using NPT,
as KVM needs to inject #UD in this case.

Fixes: 4407a797e941 ("KVM: SVM: Enable INVPCID feature on AMD")
Cc: Babu Moger 
Signed-off-by: Sean Christopherson 
Message-Id: <20210212003411.1102677-2-sea...@google.com>
Reviewed-by: Jim Mattson 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Sasha Levin 
---
 arch/x86/kvm/svm/svm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index f4ae3871e412a..76ab1ee0784ae 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -1092,12 +1092,12 @@ static u64 svm_write_l1_tsc_offset(struct kvm_vcpu 
*vcpu, u64 offset)
 static void svm_check_invpcid(struct vcpu_svm *svm)
 {
/*
-* Intercept INVPCID instruction only if shadow page table is
-* enabled. Interception is not required with nested page table
-* enabled.
+* Intercept INVPCID if shadow paging is enabled to sync/free shadow
+* roots, or if INVPCID is disabled in the guest to inject #UD.
 */
if (kvm_cpu_cap_has(X86_FEATURE_INVPCID)) {
-   if (!npt_enabled)
+   if (!npt_enabled ||
+   !guest_cpuid_has(>vcpu, X86_FEATURE_INVPCID))
svm_set_intercept(svm, INTERCEPT_INVPCID);
else
svm_clr_intercept(svm, INTERCEPT_INVPCID);
-- 
2.27.0





[PATCH 5.10 083/663] ath10k: Fix suspicious RCU usage warning in ath10k_wmi_tlv_parse_peer_stats_info()

2021-03-01 Thread Greg Kroah-Hartman
From: Anand K Mistry 

[ Upstream commit 2615e3cdbd9c0e864f5906279c952a309871d225 ]

The ieee80211_find_sta_by_ifaddr call in
ath10k_wmi_tlv_parse_peer_stats_info must be called while holding the
RCU read lock. Otherwise, the following warning will be seen when RCU
usage checking is enabled:

=
WARNING: suspicious RCU usage
5.10.3 #8 Tainted: GW
-
include/linux/rhashtable.h:594 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
no locks held by ksoftirqd/1/16.

stack backtrace:
CPU: 1 PID: 16 Comm: ksoftirqd/1 Tainted: GW 5.10.3 #8
Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.104.0 09/05/2019
Call Trace:
 dump_stack+0xab/0x115
 sta_info_hash_lookup+0x71/0x1e9 [mac80211]
 ? lock_is_held_type+0xe6/0x12f
 ? __kasan_kmalloc+0xfb/0x112
 ieee80211_find_sta_by_ifaddr+0x12/0x61 [mac80211]
 ath10k_wmi_tlv_parse_peer_stats_info+0xbd/0x10b [ath10k_core]
 ath10k_wmi_tlv_iter+0x8b/0x1a1 [ath10k_core]
 ? ath10k_wmi_tlv_iter+0x1a1/0x1a1 [ath10k_core]
 ath10k_wmi_tlv_event_peer_stats_info+0x103/0x13b [ath10k_core]
 ath10k_wmi_tlv_op_rx+0x722/0x80d [ath10k_core]
 ath10k_htc_rx_completion_handler+0x16e/0x1d7 [ath10k_core]
 ath10k_pci_process_rx_cb+0x116/0x22c [ath10k_pci]
 ? ath10k_htc_process_trailer+0x332/0x332 [ath10k_core]
 ? _raw_spin_unlock_irqrestore+0x34/0x61
 ? lockdep_hardirqs_on+0x8e/0x12e
 ath10k_ce_per_engine_service+0x55/0x74 [ath10k_core]
 ath10k_ce_per_engine_service_any+0x76/0x84 [ath10k_core]
 ath10k_pci_napi_poll+0x49/0x141 [ath10k_pci]
 net_rx_action+0x11a/0x347
 __do_softirq+0x2d3/0x539
 run_ksoftirqd+0x4b/0x86
 smpboot_thread_fn+0x1d0/0x2ab
 ? cpu_report_death+0x7f/0x7f
 kthread+0x189/0x191
 ? cpu_report_death+0x7f/0x7f
 ? kthread_blkcg+0x31/0x31
 ret_from_fork+0x22/0x30

Fixes: 0f7cb26830a6e ("ath10k: add rx bitrate report for SDIO")
Signed-off-by: Anand K Mistry 
Signed-off-by: Kalle Valo 
Link: 
https://lore.kernel.org/r/20210202134451.1.I0d2e83c42755671b7143504b62787fd06cd914ed@changeid
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/ath/ath10k/wmi-tlv.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c 
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 7b5834157fe51..e6135795719a1 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -240,8 +240,10 @@ static int ath10k_wmi_tlv_parse_peer_stats_info(struct 
ath10k *ar, u16 tag, u16
   __le32_to_cpu(stat->last_tx_rate_code),
   __le32_to_cpu(stat->last_tx_bitrate_kbps));
 
+   rcu_read_lock();
sta = ieee80211_find_sta_by_ifaddr(ar->hw, stat->peer_macaddr.addr, 
NULL);
if (!sta) {
+   rcu_read_unlock();
ath10k_warn(ar, "not found station for peer stats\n");
return -EINVAL;
}
@@ -251,6 +253,7 @@ static int ath10k_wmi_tlv_parse_peer_stats_info(struct 
ath10k *ar, u16 tag, u16
arsta->rx_bitrate_kbps = __le32_to_cpu(stat->last_rx_bitrate_kbps);
arsta->tx_rate_code = __le32_to_cpu(stat->last_tx_rate_code);
arsta->tx_bitrate_kbps = __le32_to_cpu(stat->last_tx_bitrate_kbps);
+   rcu_read_unlock();
 
return 0;
 }
-- 
2.27.0





[PATCH 5.10 596/663] mm: memcontrol: fix swap undercounting in cgroup2

2021-03-01 Thread Greg Kroah-Hartman
From: Muchun Song 

commit cae3af62b33aa931427a0f211e04347b22180b36 upstream.

When pages are swapped in, the VM may retain the swap copy to avoid
repeated writes in the future.  It's also retained if shared pages are
faulted back in some processes, but not in others.  During that time we
have an in-memory copy of the page, as well as an on-swap copy.  Cgroup1
and cgroup2 handle these overlapping lifetimes slightly differently due to
the nature of how they account memory and swap:

Cgroup1 has a unified memory+swap counter that tracks a data page
regardless whether it's in-core or swapped out.  On swapin, we transfer
the charge from the swap entry to the newly allocated swapcache page, even
though the swap entry might stick around for a while.  That's why we have
a mem_cgroup_uncharge_swap() call inside mem_cgroup_charge().

Cgroup2 tracks memory and swap as separate, independent resources and thus
has split memory and swap counters.  On swapin, we charge the newly
allocated swapcache page as memory, while the swap slot in turn must
remain charged to the swap counter as long as its allocated too.

The cgroup2 logic was broken by commit 2d1c498072de ("mm: memcontrol: make
swap tracking an integral part of memory control"), because it
accidentally removed the do_memsw_account() check in the branch inside
mem_cgroup_uncharge() that was supposed to tell the difference between the
charge transfer in cgroup1 and the separate counters in cgroup2.

As a result, cgroup2 currently undercounts retained swap to varying
degrees: swap slots are cached up to 50% of the configured limit or total
available swap space; partially faulted back shared pages are only limited
by physical capacity.  This in turn allows cgroups to significantly
overconsume their alloted swap space.

Add the do_memsw_account() check back to fix this problem.

Link: https://lkml.kernel.org/r/20210217153237.92484-1-songmuc...@bytedance.com
Fixes: 2d1c498072de ("mm: memcontrol: make swap tracking an integral part of 
memory control")
Signed-off-by: Muchun Song 
Acked-by: Johannes Weiner 
Reviewed-by: Shakeel Butt 
Acked-by: Michal Hocko 
Cc: Vladimir Davydov 
Cc: [5.8+]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
---
 mm/memcontrol.c |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6808,7 +6808,19 @@ int mem_cgroup_charge(struct page *page,
memcg_check_events(memcg, page);
local_irq_enable();
 
-   if (PageSwapCache(page)) {
+   /*
+* Cgroup1's unified memory+swap counter has been charged with the
+* new swapcache page, finish the transfer by uncharging the swap
+* slot. The swap slot would also get uncharged when it dies, but
+* it can stick around indefinitely and we'd count the page twice
+* the entire time.
+*
+* Cgroup2 has separate resource counters for memory and swap,
+* so this is a non-issue here. Memory and swap charge lifetimes
+* correspond 1:1 to page and swap slot lifetimes: we charge the
+* page to memory here, and uncharge swap when the slot is freed.
+*/
+   if (do_memsw_account() && PageSwapCache(page)) {
swp_entry_t entry = { .val = page_private(page) };
/*
 * The swap entry might not get freed for a long time,




<    3   4   5   6   7   8   9   10   11   12   >