Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-Wconstant-logical-operand in drivers/net/ethernet/toshiba/tc35815.c #608

Closed
nathanchance opened this issue Jul 17, 2019 · 5 comments

Comments

@nathanchance
Copy link
Member

commented Jul 17, 2019

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical '&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.
diff --git a/drivers/net/ethernet/toshiba/tc35815.c b/drivers/net/ethernet/toshiba/tc35815.c
index 8479a440527b..12466a72cefc 100644
--- a/drivers/net/ethernet/toshiba/tc35815.c
+++ b/drivers/net/ethernet/toshiba/tc35815.c
@@ -1504,7 +1504,7 @@ tc35815_rx(struct net_device *dev, int limit)
                        pci_unmap_single(lp->pci_dev,
                                         lp->rx_skbs[cur_bd].skb_dma,
                                         RX_BUF_SIZE, PCI_DMA_FROMDEVICE);
-                       if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
+                       if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN != 0)
                                memmove(skb->data, skb->data - NET_IP_ALIGN,
                                        pkt_len);
                        data = skb_put(skb, pkt_len);

I'll write up a proper commit message and send it along in the series that fixes the majority of the MIPS warnings I have found.

@nickdesaulniers

This comment has been minimized.

Copy link
Member

commented Jul 17, 2019

Can either of these not be a constant?

nathanchance added a commit that referenced this issue Jul 18, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which is most likely
what was intended.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: #608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
nathanchance added a commit that referenced this issue Jul 19, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which is most likely
what was intended.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: #608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
nathanchance added a commit that referenced this issue Jul 25, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which is most likely
what was intended.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: #608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
nathanchance added a commit that referenced this issue Jul 27, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which is most likely
what was intended.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: #608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
nathanchance added a commit that referenced this issue Jul 27, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which is most likely
what was intended.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: #608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
nathanchance added a commit that referenced this issue Aug 3, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which is most likely
what was intended.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: #608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
@nathanchance

This comment has been minimized.

nathanchance added a commit that referenced this issue Aug 12, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: #608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
idosch pushed a commit to jpirko/linux_mlxsw that referenced this issue Aug 12, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
@nathanchance

This comment has been minimized.

@nathanchance

This comment has been minimized.

Copy link
Member Author

commented Aug 20, 2019

mrchapp pushed a commit to mrchapp/linux that referenced this issue Sep 8, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mrchapp pushed a commit to mrchapp/linux that referenced this issue Sep 8, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mrchapp pushed a commit to mrchapp/linux that referenced this issue Sep 8, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mrchapp pushed a commit to mrchapp/linux that referenced this issue Sep 8, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mrchapp pushed a commit to mrchapp/linux that referenced this issue Sep 9, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Sep 10, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Sep 10, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Sep 10, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Sep 10, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Sep 10, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
isjerryxiao added a commit to archlinux-jerry/Amlogic_s905-kernel that referenced this issue Sep 10, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
freeza-inc added a commit to freeza-inc/bm-galaxy-note9-exynos-pie-remix that referenced this issue Sep 10, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928db560 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ctfrommn added a commit to ctfrommn/kernel_bonito that referenced this issue Sep 10, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ctfrommn added a commit to ctfrommn/kernel_bonito that referenced this issue Sep 11, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/linux-mvista-2.6 that referenced this issue Sep 11, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
Source: Kernel.org
MR: 99884
Type: Integration
Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-4.19.y
ChangeID: 7b7a11549dc102fb7517e142a053e53ef6ac2c9b
Description:

[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Armin Kuster <akuster@mvista.com>
catuva21 added a commit to catuva21/kernel_RN7 that referenced this issue Sep 11, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928db560 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
EviraKernel added a commit to EviraKernel/Evira_Aosp that referenced this issue Sep 11, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ctfrommn added a commit to ctfrommn/kernel_bonito that referenced this issue Sep 12, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
zxc070 added a commit to zxc070/kernel_xiaomi_lavender that referenced this issue Sep 12, 2019
Merge tag 4.4.192 into eas-pie
commit 8a227a3afe03f5b864b43233fe258c57719d25a3
Merge: 1b3d0a42f2aa 882f8791e141
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Tue Sep 10 15:31:55 2019 -0700

    Merge 4.4.192 into kernel.lnx.4.4.r34-rel

    Changes in 4.4.192: (24 commits)
            net: tundra: tsi108: use spin_lock_irqsave instead of spin_lock_irq in IRQ context
            net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
            Bluetooth: btqca: Add a short delay before downloading the NVM
            ibmveth: Convert multicast list size for little-endian system
            gpio: Fix build error of function redefinition
            cxgb4: fix a memory leak bug
            net: myri10ge: fix memory leaks
            cx82310_eth: fix a memory leak bug
            net: kalmia: fix memory leaks
            wimax/i2400m: fix a memory leak bug
            ravb: Fix use-after-free ravb_tstamp_skb
            Tools: hv: kvp: eliminate 'may be used uninitialized' warning
            IB/mlx4: Fix memory leaks
            ceph: fix buffer free while holding i_ceph_lock in __ceph_setxattr()
            KVM: arm/arm64: Only skip MMIO insn once
            libceph: allow ceph_buffer_put() to receive a NULL ceph_buffer
            spi: bcm2835aux: ensure interrupts are enabled for shared handler
            spi: bcm2835aux: unifying code between polling and interrupt driven code
            spi: bcm2835aux: remove dangerous uncontrolled read of fifo
            spi: bcm2835aux: fix corruptions for longer spi transfers
            Revert "x86/apic: Include the LDR when clearing out APIC registers"
            net: fix skb use after free in netpoll
            net: stmmac: dwmac-rk: Don't fail if phy regulator is absent
            Linux 4.4.192

    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>

commit 882f8791e1412d81e5cc7a4c379c73195155b40f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Sep 10 10:29:50 2019 +0100

    Linux 4.4.192

commit 89e0660bc5316acef9a4dc7bf8ec1ffed8a57c8c
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Thu Aug 29 11:17:24 2019 +0800

    net: stmmac: dwmac-rk: Don't fail if phy regulator is absent

    [ Upstream commit 3b25528e1e355c803e73aa326ce657b5606cda73 ]

    The devicetree binding lists the phy phy as optional. As such, the
    driver should not bail out if it can't find a regulator. Instead it
    should just skip the remaining regulator related code and continue
    on normally.

    Skip the remainder of phy_power_on() if a regulator supply isn't
    available. This also gets rid of the bogus return code.

    Fixes: 2e12f536635f ("net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator")
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6198d2b4ff0195ebc228a231f96918855ce722f
Author: Feng Sun <loyou85@gmail.com>
Date:   Mon Aug 26 14:46:04 2019 +0800

    net: fix skb use after free in netpoll

    [ Upstream commit 2c1644cf6d46a8267d79ed95cb9b563839346562 ]

    After commit baeababb5b85d5c4e6c917efe2a1504179438d3b
    ("tun: return NET_XMIT_DROP for dropped packets"),
    when tun_net_xmit drop packets, it will free skb and return NET_XMIT_DROP,
    netpoll_send_skb_on_dev will run into following use after free cases:
    1. retry netpoll_start_xmit with freed skb;
    2. queue freed skb in npinfo->txq.
    queue_process will also run into use after free case.

    hit netpoll_send_skb_on_dev first case with following kernel log:

    [  117.864773] kernel BUG at mm/slub.c:306!
    [  117.864773] invalid opcode: 0000 [#1] SMP PTI
    [  117.864774] CPU: 3 PID: 2627 Comm: loop_printmsg Kdump: loaded Tainted: P           OE     5.3.0-050300rc5-generic #201908182231
    [  117.864775] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [  117.864775] RIP: 0010:kmem_cache_free+0x28d/0x2b0
    [  117.864781] Call Trace:
    [  117.864781]  ? tun_net_xmit+0x21c/0x460
    [  117.864781]  kfree_skbmem+0x4e/0x60
    [  117.864782]  kfree_skb+0x3a/0xa0
    [  117.864782]  tun_net_xmit+0x21c/0x460
    [  117.864782]  netpoll_start_xmit+0x11d/0x1b0
    [  117.864788]  netpoll_send_skb_on_dev+0x1b8/0x200
    [  117.864789]  __br_forward+0x1b9/0x1e0 [bridge]
    [  117.864789]  ? skb_clone+0x53/0xd0
    [  117.864790]  ? __skb_clone+0x2e/0x120
    [  117.864790]  deliver_clone+0x37/0x50 [bridge]
    [  117.864790]  maybe_deliver+0x89/0xc0 [bridge]
    [  117.864791]  br_flood+0x6c/0x130 [bridge]
    [  117.864791]  br_dev_xmit+0x315/0x3c0 [bridge]
    [  117.864792]  netpoll_start_xmit+0x11d/0x1b0
    [  117.864792]  netpoll_send_skb_on_dev+0x1b8/0x200
    [  117.864792]  netpoll_send_udp+0x2c6/0x3e8
    [  117.864793]  write_msg+0xd9/0xf0 [netconsole]
    [  117.864793]  console_unlock+0x386/0x4e0
    [  117.864793]  vprintk_emit+0x17e/0x280
    [  117.864794]  vprintk_default+0x29/0x50
    [  117.864794]  vprintk_func+0x4c/0xbc
    [  117.864794]  printk+0x58/0x6f
    [  117.864795]  loop_fun+0x24/0x41 [printmsg_loop]
    [  117.864795]  kthread+0x104/0x140
    [  117.864795]  ? 0xffffffffc05b1000
    [  117.864796]  ? kthread_park+0x80/0x80
    [  117.864796]  ret_from_fork+0x35/0x40

    Signed-off-by: Feng Sun <loyou85@gmail.com>
    Signed-off-by: Xiaojun Zhao <xiaojunzhao141@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94eb5357f6d688b364eaf52d4f7fa187102396a7
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Sep 7 14:25:54 2019 -0700

    Revert "x86/apic: Include the LDR when clearing out APIC registers"

    [ Upstream commit 950b07c14e8c59444e2359f15fd70ed5112e11a0 ]

    This reverts commit 558682b5291937a70748d36fd9ba757fb25b99ae.

    Chris Wilson reports that it breaks his CPU hotplug test scripts.  In
    particular, it breaks offlining and then re-onlining the boot CPU, which
    we treat specially (and the BIOS does too).

    The symptoms are that we can offline the CPU, but it then does not come
    back online again:

        smpboot: CPU 0 is now offline
        smpboot: Booting Node 0 Processor 0 APIC 0x0
        smpboot: do_boot_cpu failed(-1) to wakeup CPU#0

    Thomas says he knows why it's broken (my personal suspicion: our magic
    handling of the "cpu0_logical_apicid" thing), but for 5.3 the right fix
    is to just revert it, since we've never touched the LDR bits before, and
    it's not worth the risk to do anything else at this stage.

    [ Hotpluging of the boot CPU is special anyway, and should be off by
      default. See the "BOOTPARAM_HOTPLUG_CPU0" config option and the
      cpu0_hotplug kernel parameter.

      In general you should not do it, and it has various known limitations
      (hibernate and suspend require the boot CPU, for example).

      But it should work, even if the boot CPU is special and needs careful
      treatment       - Linus ]

    Link: https://lore.kernel.org/lkml/156785100521.13300.14461504732265570003@skylake-alporthouse-com/
    Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Bandan Das <bsd@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e187a57fc653cfc3016875b80f53f78af4eac172
Author: Martin Sperl <kernel@martin.sperl.org>
Date:   Sat Mar 30 09:31:00 2019 +0000

    spi: bcm2835aux: fix corruptions for longer spi transfers

    [ Upstream commit 73b114ee7db1750c0b535199fae383b109bd61d0 ]

    On long running tests with a mcp2517fd can controller it showed that
    on rare occations the data read shows corruptions for longer spi transfers.

    Example of a 22 byte transfer:

    expected (as captured on logic analyzer):
    FF FF 78 00 00 00 08 06 00 00 91 20 77 56 84 85 86 87 88 89 8a 8b

    read by the driver:
    FF FF 78 00 00 00 08 06 00 00 91 20 77 56 84 88 89 8a 00 00 8b 9b

    To fix this use BCM2835_AUX_SPI_STAT_RX_LVL to determine when we may
    read data from the fifo reliably without any corruption.

    Surprisingly the only values ever empirically read in
    BCM2835_AUX_SPI_STAT_RX_LVL are 0x00, 0x10, 0x20 and 0x30.
    So whenever the mask is not 0 we can read from the fifo in a safe manner.

    The patch has now been tested intensively and we are no longer
    able to reproduce the "RX" issue any longer.

    Fixes: 1ea29b39f4c812ec ("spi: bcm2835aux: add bcm2835 auxiliary spi device...")
    Reported-by: Hubert Denkmair <h.denkmair@intence.de>
    Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
    Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2f16660fc8687febdc133f9b5082482f2a280fc
Author: Martin Sperl <kernel@martin.sperl.org>
Date:   Sat Mar 30 09:30:59 2019 +0000

    spi: bcm2835aux: remove dangerous uncontrolled read of fifo

    [ Upstream commit c7de8500fd8ecbb544846dd5f11dca578c3777e1 ]

    This read of the fifo is a potential candidate for a race condition
    as the spi transfer is not necessarily finished and so can lead to
    an early read of the fifo that still misses data.

    So it has been removed.

    Fixes: 1ea29b39f4c812ec ("spi: bcm2835aux: add bcm2835 auxiliary spi device...")
    Suggested-by: Hubert Denkmair <h.denkmair@intence.de>
    Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
    Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5473cd1dbf972ff06d89400d42973eb31c72dec1
Author: Martin Sperl <kernel@martin.sperl.org>
Date:   Sat Mar 30 09:30:58 2019 +0000

    spi: bcm2835aux: unifying code between polling and interrupt driven code

    [ Upstream commit 7188a6f0eee3f1fae5d826cfc6d569657ff950ec ]

    Sharing more code between polling and interrupt-driven mode.

    Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
    Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c99ad4f20c5b4d550745e1beaeaa24ed2cf873ba
Author: Rob Herring <robh@kernel.org>
Date:   Thu May 3 13:09:44 2018 -0500

    spi: bcm2835aux: ensure interrupts are enabled for shared handler

    [ Upstream commit bc519d9574618e47a0c788000fb78da95e18d953 ]

    The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
    Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
    DT change which breaks compatibility with older kernels. The AUX irqchip
    was already rejected for upstream[1] and the DT change would break
    working systems if the DTB is updated to a newer one. The latter issue
    was brought to my attention by Alex Graf.

    The root cause however is a bug in the shared handler. Shared handlers
    must check that interrupts are actually enabled before servicing the
    interrupt. Add a check that the TXEMPTY or IDLE interrupts are enabled.

    [1] https://patchwork.kernel.org/patch/9781221/

    Cc: Alexander Graf <agraf@suse.de>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Eric Anholt <eric@anholt.net>
    Cc: Stefan Wahren <stefan.wahren@i2se.com>
    Cc: Florian Fainelli <f.fainelli@gmail.com>
    Cc: Ray Jui <rjui@broadcom.com>
    Cc: Scott Branden <sbranden@broadcom.com>
    Cc: bcm-kernel-feedback-list@broadcom.com
    Cc: linux-spi@vger.kernel.org
    Cc: linux-rpi-kernel@lists.infradead.org
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Rob Herring <robh@kernel.org>
    Reviewed-by: Eric Anholt <eric@anholt.net>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c3083eff1b1b3bdae7389ff0e2fb7ae9423561e4
Author: Luis Henriques <lhenriques@suse.com>
Date:   Fri Jul 19 15:32:19 2019 +0100

    libceph: allow ceph_buffer_put() to receive a NULL ceph_buffer

    [ Upstream commit 5c498950f730aa17c5f8a2cdcb903524e4002ed2 ]

    Signed-off-by: Luis Henriques <lhenriques@suse.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bce83d9ccca56b9ea9b7cd88499681d10d5062ea
Author: Andrew Jones <drjones@redhat.com>
Date:   Thu Aug 22 13:03:05 2019 +0200

    KVM: arm/arm64: Only skip MMIO insn once

    [ Upstream commit 2113c5f62b7423e4a72b890bd479704aa85c81ba ]

    If after an MMIO exit to userspace a VCPU is immediately run with an
    immediate_exit request, such as when a signal is delivered or an MMIO
    emulation completion is needed, then the VCPU completes the MMIO
    emulation and immediately returns to userspace. As the exit_reason
    does not get changed from KVM_EXIT_MMIO in these cases we have to
    be careful not to complete the MMIO emulation again, when the VCPU is
    eventually run again, because the emulation does an instruction skip
    (and doing too many skips would be a waste of guest code :-) We need
    to use additional VCPU state to track if the emulation is complete.
    As luck would have it, we already have 'mmio_needed', which even
    appears to be used in this way by other architectures already.

    Fixes: 0d640732dbeb ("arm64: KVM: Skip MMIO insn after emulation")
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Andrew Jones <drjones@redhat.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1d86cb8d3204337e1853b84d69ea0f30dc0ba973
Author: Luis Henriques <lhenriques@suse.com>
Date:   Fri Jul 19 15:32:20 2019 +0100

    ceph: fix buffer free while holding i_ceph_lock in __ceph_setxattr()

    [ Upstream commit 86968ef21596515958d5f0a40233d02be78ecec0 ]

    Calling ceph_buffer_put() in __ceph_setxattr() may end up freeing the
    i_xattrs.prealloc_blob buffer while holding the i_ceph_lock.  This can be
    fixed by postponing the call until later, when the lock is released.

    The following backtrace was triggered by fstests generic/117.

      BUG: sleeping function called from invalid context at mm/vmalloc.c:2283
      in_atomic(): 1, irqs_disabled(): 0, pid: 650, name: fsstress
      3 locks held by fsstress/650:
       #0: 00000000870a0fe8 (sb_writers#8){.+.+}, at: mnt_want_write+0x20/0x50
       #1: 00000000ba0c4c74 (&type->i_mutex_dir_key#6){++++}, at: vfs_setxattr+0x55/0xa0
       #2: 000000008dfbb3f2 (&(&ci->i_ceph_lock)->rlock){+.+.}, at: __ceph_setxattr+0x297/0x810
      CPU: 1 PID: 650 Comm: fsstress Not tainted 5.2.0+ #437
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-prebuilt.qemu.org 04/01/2014
      Call Trace:
       dump_stack+0x67/0x90
       ___might_sleep.cold+0x9f/0xb1
       vfree+0x4b/0x60
       ceph_buffer_release+0x1b/0x60
       __ceph_setxattr+0x2b4/0x810
       __vfs_setxattr+0x66/0x80
       __vfs_setxattr_noperm+0x59/0xf0
       vfs_setxattr+0x81/0xa0
       setxattr+0x115/0x230
       ? filename_lookup+0xc9/0x140
       ? rcu_read_lock_sched_held+0x74/0x80
       ? rcu_sync_lockdep_assert+0x2e/0x60
       ? __sb_start_write+0x142/0x1a0
       ? mnt_want_write+0x20/0x50
       path_setxattr+0xba/0xd0
       __x64_sys_lsetxattr+0x24/0x30
       do_syscall_64+0x50/0x1c0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x7ff23514359a

    Signed-off-by: Luis Henriques <lhenriques@suse.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bc68ba54a2d32e2e3eaf826159b1dc8878cb109b
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Sun Aug 18 15:23:01 2019 -0500

    IB/mlx4: Fix memory leaks

    [ Upstream commit 5c1baaa82cea2c815a5180ded402a7cd455d1810 ]

    In mlx4_ib_alloc_pv_bufs(), 'tun_qp->tx_ring' is allocated through
    kcalloc(). However, it is not always deallocated in the following execution
    if an error occurs, leading to memory leaks. To fix this issue, free
    'tun_qp->tx_ring' whenever an error occurs.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Acked-by: Leon Romanovsky <leonro@mellanox.com>
    Link: https://lore.kernel.org/r/1566159781-4642-1-git-send-email-wenwen@cs.uga.edu
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6442370b5642d38c6f9ae8edb71d514aaa6c3dab
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Mon Aug 19 16:44:09 2019 +0200

    Tools: hv: kvp: eliminate 'may be used uninitialized' warning

    [ Upstream commit 89eb4d8d25722a0a0194cf7fa47ba602e32a6da7 ]

    When building hv_kvp_daemon GCC-8.3 complains:

    hv_kvp_daemon.c: In function ‘kvp_get_ip_info.constprop’:
    hv_kvp_daemon.c:812:30: warning: ‘ip_buffer’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      struct hv_kvp_ipaddr_value *ip_buffer;

    this seems to be a false positive: we only use ip_buffer when
    op == KVP_OP_GET_IP_INFO and it is only unset when op == KVP_OP_ENUMERATE.

    Silence the warning by initializing ip_buffer to NULL.

    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf3583e15956de79e9c37c5ca609434a04f8a224
Author: Tho Vu <tho.vu.wh@rvc.renesas.com>
Date:   Fri Aug 16 17:17:02 2019 +0200

    ravb: Fix use-after-free ravb_tstamp_skb

    [ Upstream commit cfef46d692efd852a0da6803f920cc756eea2855 ]

    When a Tx timestamp is requested, a pointer to the skb is stored in the
    ravb_tstamp_skb struct. This was done without an skb_get. There exists
    the possibility that the skb could be freed by ravb_tx_free (when
    ravb_tx_free is called from ravb_start_xmit) before the timestamp was
    processed, leading to a use-after-free bug.

    Use skb_get when filling a ravb_tstamp_skb struct, and add appropriate
    frees/consumes when a ravb_tstamp_skb struct is freed.

    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Signed-off-by: Tho Vu <tho.vu.wh@rvc.renesas.com>
    Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
    Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62b1e22efe3e6eb629d8a7130bf3e69ec86e6293
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Thu Aug 15 15:29:51 2019 -0500

    wimax/i2400m: fix a memory leak bug

    [ Upstream commit 44ef3a03252844a8753479b0cea7f29e4a804bdc ]

    In i2400m_barker_db_init(), 'options_orig' is allocated through kstrdup()
    to hold the original command line options. Then, the options are parsed.
    However, if an error occurs during the parsing process, 'options_orig' is
    not deallocated, leading to a memory leak bug. To fix this issue, free
    'options_orig' before returning the error.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b25f01d604ed86d379420f038c91555faef0afc
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Wed Aug 14 13:56:43 2019 -0500

    net: kalmia: fix memory leaks

    [ Upstream commit f1472cb09f11ddb41d4be84f0650835cb65a9073 ]

    In kalmia_init_and_get_ethernet_addr(), 'usb_buf' is allocated through
    kmalloc(). In the following execution, if the 'status' returned by
    kalmia_send_init_packet() is not 0, 'usb_buf' is not deallocated, leading
    to memory leaks. To fix this issue, add the 'out' label to free 'usb_buf'.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d28afe7a79edf0f2afd1005d9c2a83fab1a1ab6
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Wed Aug 14 13:03:38 2019 -0500

    cx82310_eth: fix a memory leak bug

    [ Upstream commit 1eca92eef18719027d394bf1a2d276f43e7cf886 ]

    In cx82310_bind(), 'dev->partial_data' is allocated through kmalloc().
    Then, the execution waits for the firmware to become ready. If the firmware
    is not ready in time, the execution is terminated. However, the allocated
    'dev->partial_data' is not deallocated on this path, leading to a memory
    leak bug. To fix this issue, free 'dev->partial_data' before returning the
    error.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6f3170c57da89158b1aa920fc547f481d278480
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Wed Aug 14 01:38:39 2019 -0500

    net: myri10ge: fix memory leaks

    [ Upstream commit 20fb7c7a39b5c719e2e619673b5f5729ee7d2306 ]

    In myri10ge_probe(), myri10ge_alloc_slices() is invoked to allocate slices
    related structures. Later on, myri10ge_request_irq() is used to get an irq.
    However, if this process fails, the allocated slices related structures are
    not deallocated, leading to memory leaks. To fix this issue, revise the
    target label of the goto statement to 'abort_with_slices'.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa6d2679e5cac2fd5ece39c8edb5f503064c5fcd
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Tue Aug 13 04:18:52 2019 -0500

    cxgb4: fix a memory leak bug

    [ Upstream commit c554336efa9bbc28d6ec14efbee3c7d63c61a34f ]

    In blocked_fl_write(), 't' is not deallocated if bitmap_parse_user() fails,
    leading to a memory leak bug. To fix this issue, free t before returning
    the error.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f46a46a9de0f1e005f64ade70336f9505a067a6e
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Wed Jul 31 20:38:14 2019 +0800

    gpio: Fix build error of function redefinition

    [ Upstream commit 68e03b85474a51ec1921b4d13204782594ef7223 ]

    when do randbuilding, I got this error:

    In file included from drivers/hwmon/pmbus/ucd9000.c:19:0:
    ./include/linux/gpio/driver.h:576:1: error: redefinition of gpiochip_add_pin_range
     gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
     ^~~~~~~~~~~~~~~~~~~~~~
    In file included from drivers/hwmon/pmbus/ucd9000.c:18:0:
    ./include/linux/gpio.h:245:1: note: previous definition of gpiochip_add_pin_range was here
     gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
     ^~~~~~~~~~~~~~~~~~~~~~

    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: 964cb341882f ("gpio: move pincontrol calls to <linux/gpio/driver.h>")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Link: https://lore.kernel.org/r/20190731123814.46624-1-yuehaibing@huawei.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da5cc03c7562d25a3b66c748b845d9717d6d22b3
Author: Thomas Falcon <tlfalcon@linux.ibm.com>
Date:   Mon Aug 12 16:13:06 2019 -0500

    ibmveth: Convert multicast list size for little-endian system

    [ Upstream commit 66cf4710b23ab2adda11155684a2c8826f4fe732 ]

    The ibm,mac-address-filters property defines the maximum number of
    addresses the hypervisor's multicast filter list can support. It is
    encoded as a big-endian integer in the OF device tree, but the virtual
    ethernet driver does not convert it for use by little-endian systems.
    As a result, the driver is not behaving as it should on affected systems
    when a large number of multicast addresses are assigned to the device.

    Reported-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
    Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5694f0d1cb10e9b9faaf47ba5b21f1d664f3a3ba
Author: Matthias Kaehlcke <mka@chromium.org>
Date:   Tue Jul 9 15:44:50 2019 -0700

    Bluetooth: btqca: Add a short delay before downloading the NVM

    [ Upstream commit 8059ba0bd0e4694e51c2ee6438a77b325f06c0d5 ]

    On WCN3990 downloading the NVM sometimes fails with a "TLV response
    size mismatch" error:

    [  174.949955] Bluetooth: btqca.c:qca_download_firmware() hci0: QCA Downloading qca/crnv21.bin
    [  174.958718] Bluetooth: btqca.c:qca_tlv_send_segment() hci0: QCA TLV response size mismatch

    It seems the controller needs a short time after downloading the
    firmware before it is ready for the NVM. A delay as short as 1 ms
    seems sufficient, make it 10 ms just in case. No event is received
    during the delay, hence we don't just silently drop an extra event.

    Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffb54f3eae723ca6d7ff34187bdfce91a0d28fce
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Sun Aug 11 20:13:45 2019 -0700

    net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx

    [ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

    clang warns:

    drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
    '&&' with constant operand [-Wconstant-logical-operand]
                            if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                      ^  ~~~~~~~~~~~~
    drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
    bitwise operation
                            if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                      ^~
                                                      &
    drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
    silence this warning
                            if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                     ~^~~~~~~~~~~~~~~
    1 warning generated.

    Explicitly check that NET_IP_ALIGN is not zero, which matches how this
    is checked in other parts of the tree. Because NET_IP_ALIGN is a build
    time constant, this check will be constant folded away during
    optimization.

    Fixes: 82a9928db560 ("tc35815: Enable StripCRC feature")
    Link: https://github.com/ClangBuiltLinux/linux/issues/608
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e040f074d49fb6fde93112a2350af5462a494c04
Author: Fuqian Huang <huangfq.daxian@gmail.com>
Date:   Fri Aug 9 13:35:39 2019 +0800

    net: tundra: tsi108: use spin_lock_irqsave instead of spin_lock_irq in IRQ context

    [ Upstream commit 8c25d0887a8bd0e1ca2074ac0c6dff173787a83b ]

    As spin_unlock_irq will enable interrupts.
    Function tsi108_stat_carry is called from interrupt handler tsi108_irq.
    Interrupts are enabled in interrupt handler.
    Use spin_lock_irqsave/spin_unlock_irqrestore instead of spin_(un)lock_irq
    in IRQ context to avoid this.

    Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b3d0a42f2aad1204dd1b489bb8d46c158ddb41f
Merge: 41bd92eff615 efbc4a364bd5
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Fri Sep 6 09:02:34 2019 -0700

    Merge 4.4.191 into kernel.lnx.4.4.r34-rel

    Changes in 4.4.191: (77 commits)
            HID: Add 044f:b320 ThrustMaster, Inc. 2 in 1 DT
            MIPS: kernel: only use i8253 clocksource with periodic clockevent
            netfilter: ebtables: fix a memory leak bug in compat
            bonding: Force slave speed check after link state recovery for 802.3ad
            can: dev: call netif_carrier_off() in register_candev()
            st21nfca_connectivity_event_received: null check the allocation
            st_nci_hci_connectivity_event_received: null check the allocation
            ASoC: ti: davinci-mcasp: Correct slot_width posed constraint
            net: usb: qmi_wwan: Add the BroadMobi BM818 card
            isdn: mISDN: hfcsusb: Fix possible null-pointer dereferences in start_isoc_chain()
            isdn: hfcsusb: Fix mISDN driver crash caused by transfer buffer on the stack
            perf bench numa: Fix cpu0 binding
            can: sja1000: force the string buffer NULL-terminated
            can: peak_usb: force the string buffer NULL-terminated
            NFSv4: Fix a potential sleep while atomic in nfs4_do_reclaim()
            net: cxgb3_main: Fix a resource leak in a error path in 'init_one()'
            net: hisilicon: make hip04_tx_reclaim non-reentrant
            net: hisilicon: fix hip04-xmit never return TX_BUSY
            net: hisilicon: Fix dma_map_single failed on arm64
            libata: add SG safety checks in SFF pio transfers
            selftests: kvm: Adding config fragments
            HID: wacom: correct misreported EKR ring values
            Revert "dm bufio: fix deadlock with loop device"
            userfaultfd_release: always remove uffd flags and clear vm_userfaultfd_ctx
            x86/retpoline: Don't clobber RFLAGS during CALL_NOSPEC on i386
            x86/apic: Handle missing global clockevent gracefully
            x86/boot: Save fields explicitly, zero out everything else
            x86/boot: Fix boot regression caused by bootparam sanitizing
            dm btree: fix order of block initialization in btree_split_beneath
            dm space map metadata: fix missing store of apply_bops() return value
            dm table: fix invalid memory accesses with too high sector number
            cgroup: Disable IRQs while holding css_set_lock
            GFS2: don't set rgrp gl_object until it's inserted into rgrp tree
            net: arc_emac: fix koops caused by sk_buff free
            vhost-net: set packet weight of tx polling to 2 * vq size
            vhost_net: use packet weight for rx handler, too
            vhost_net: introduce vhost_exceeds_weight()
            vhost: introduce vhost_exceeds_weight()
            vhost_net: fix possible infinite loop
            vhost: scsi: add weight support
            siphash: add cryptographically secure PRF
            siphash: implement HalfSipHash1-3 for hash tables
            inet: switch IP ID generator to siphash
            netfilter: ctnetlink: don't use conntrack/expect object addresses as id
            netfilter: conntrack: Use consistent ct id hash calculation
            Revert "perf test 6: Fix missing kvm module load for s390"
            x86/pm: Introduce quirk framework to save/restore extra MSR registers around suspend/resume
            x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h
            scsi: ufs: Fix NULL pointer dereference in ufshcd_config_vreg_hpm()
            dmaengine: ste_dma40: fix unneeded variable warning
            usb: gadget: composite: Clear "suspended" on reset/disconnect
            usb: host: fotg2: restart hcd after port reset
            tools: hv: fix KVP and VSS daemons exit code
            watchdog: bcm2835_wdt: Fix module autoload
            tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
            ALSA: usb-audio: Fix a stack buffer overflow bug in check_input_term
            ALSA: usb-audio: Fix an OOB bug in parse_audio_mixer_unit
            tcp: make sure EPOLLOUT wont be missed
            ALSA: seq: Fix potential concurrent access to the deleted pool
            KVM: x86: Don't update RIP or do single-step on faulting emulation
            x86/apic: Do not initialize LDR and DFR for bigsmp
            x86/apic: Include the LDR when clearing out APIC registers
            usb-storage: Add new JMS567 revision to unusual_devs
            USB: cdc-wdm: fix race between write and disconnect due to flag abuse
            usb: host: ohci: fix a race condition between shutdown and irq
            USB: storage: ums-realtek: Update module parameter description for auto_delink_en
            USB: storage: ums-realtek: Whitelist auto-delink support
            ptrace,x86: Make user_64bit_mode() available to 32-bit builds
            uprobes/x86: Fix detection of 32-bit user mode
            mmc: sdhci-of-at91: add quirk for broken HS200
            mmc: core: Fix init of SD cards reporting an invalid VDD range
            stm class: Fix a double free of stm_source_device
            VMCI: Release resource if the work is already queued
            Revert "cfg80211: fix processing world regdomain when non modular"
            mac80211: fix possible sta leak
            x86/ptrace: fix up botched merge of spectrev1 fix
            Linux 4.4.191

    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>

    Conflicts:
    	drivers/scsi/ufs/ufshcd.c
    	fs/userfaultfd.c
    	kernel/cgroup.c
    	sound/usb/mixer.c

commit efbc4a364bd5469a616668127439e7cfca4c1d7b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Sep 6 10:18:17 2019 +0200

    Linux 4.4.191

commit 61263fbe574b0b74c50552983bdcc2bb9a409b1e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Sep 4 12:27:18 2019 +0200

    x86/ptrace: fix up botched merge of spectrev1 fix

    I incorrectly merged commit 31a2fbb390fe ("x86/ptrace: Fix possible
    spectre-v1 in ptrace_get_debugreg()") when backporting it, as was
    graciously pointed out at
    https://grsecurity.net/teardown_of_a_failed_linux_lts_spectre_fix.php

    Resolve the upstream difference with the stable kernel merge to properly
    protect things.

    Reported-by: Brad Spengler <spender@grsecurity.net>
    Cc: Dianzhang Chen <dianzhangchen0@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: <bp@alien8.de>
    Cc: <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c0932cd8197d290195dc281ff6534e13d9d97e8
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Aug 1 09:30:33 2019 +0200

    mac80211: fix possible sta leak

    commit 5fd2f91ad483baffdbe798f8a08f1b41442d1e24 upstream.

    If TDLS station addition is rejected, the sta memory is leaked.
    Avoid this by moving the check before the allocation.

    Cc: stable@vger.kernel.org
    Fixes: 7ed5285396c2 ("mac80211: don't initiate TDLS connection if station is not associated to AP")
    Link: https://lore.kernel.org/r/20190801073033.7892-1-johannes@sipsolutions.net
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3161dea144dde71e8d8dd1cd8b736b6e431b7ee7
Author: Hodaszi, Robert <Robert.Hodaszi@digi.com>
Date:   Fri Jun 14 13:16:01 2019 +0000

    Revert "cfg80211: fix processing world regdomain when non modular"

    commit 0d31d4dbf38412f5b8b11b4511d07b840eebe8cb upstream.

    This reverts commit 96cce12ff6e0 ("cfg80211: fix processing world
    regdomain when non modular").

    Re-triggering a reg_process_hint with the last request on all events,
    can make the regulatory domain fail in case of multiple WiFi modules. On
    slower boards (espacially with mdev), enumeration of the WiFi modules
    can end up in an intersected regulatory domain, and user cannot set it
    with 'iw reg set' anymore.

    This is happening, because:
    - 1st module enumerates, queues up a regulatory request
    - request gets processed by __reg_process_hint_driver():
      - checks if previous was set by CORE -> yes
        - checks if regulator domain changed -> yes, from '00' to e.g. 'US'
          -> sends request to the 'crda'
    - 2nd module enumerates, queues up a regulator request (which triggers
      the reg_todo() work)
    - reg_todo() -> reg_process_pending_hints() sees, that the last request
      is not processed yet, so it tries to process it again.
      __reg_process_hint driver() will run again, and:
      - checks if the last request's initiator was the core -> no, it was
        the driver (1st WiFi module)
      - checks, if the previous initiator was the driver -> yes
        - checks if the regulator domain changed -> yes, it was '00' (set by
          core, and crda call did not return yet), and should be changed to 'US'

    ------> __reg_process_hint_driver calls an intersect

    Besides, the reg_process_hint call with the last request is meaningless
    since the crda call has a timeout work. If that timeout expires, the
    first module's request will lost.

    Cc: stable@vger.kernel.org
    Fixes: 96cce12ff6e0 ("cfg80211: fix processing world regdomain when non modular")
    Signed-off-by: Robert Hodaszi <robert.hodaszi@digi.com>
    Link: https://lore.kernel.org/r/20190614131600.GA13897@a1-hr
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16ab568881f8d2bc2e3b66dab55ab6ea72d9849b
Author: Nadav Amit <namit@vmware.com>
Date:   Tue Aug 20 13:26:38 2019 -0700

    VMCI: Release resource if the work is already queued

    commit ba03a9bbd17b149c373c0ea44017f35fc2cd0f28 upstream.

    Francois reported that VMware balloon gets stuck after a balloon reset,
    when the VMCI doorbell is removed. A similar error can occur when the
    balloon driver is removed with the following splat:

    [ 1088.622000] INFO: task modprobe:3565 blocked for more than 120 seconds.
    [ 1088.622035]       Tainted: G        W         5.2.0 #4
    [ 1088.622087] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 1088.622205] modprobe        D    0  3565   1450 0x00000000
    [ 1088.622210] Call Trace:
    [ 1088.622246]  __schedule+0x2a8/0x690
    [ 1088.622248]  schedule+0x2d/0x90
    [ 1088.622250]  schedule_timeout+0x1d3/0x2f0
    [ 1088.622252]  wait_for_completion+0xba/0x140
    [ 1088.622320]  ? wake_up_q+0x80/0x80
    [ 1088.622370]  vmci_resource_remove+0xb9/0xc0 [vmw_vmci]
    [ 1088.622373]  vmci_doorbell_destroy+0x9e/0xd0 [vmw_vmci]
    [ 1088.622379]  vmballoon_vmci_cleanup+0x6e/0xf0 [vmw_balloon]
    [ 1088.622381]  vmballoon_exit+0x18/0xcc8 [vmw_balloon]
    [ 1088.622394]  __x64_sys_delete_module+0x146/0x280
    [ 1088.622408]  do_syscall_64+0x5a/0x130
    [ 1088.622410]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [ 1088.622415] RIP: 0033:0x7f54f62791b7
    [ 1088.622421] Code: Bad RIP value.
    [ 1088.622421] RSP: 002b:00007fff2a949008 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
    [ 1088.622426] RAX: ffffffffffffffda RBX: 000055dff8b55d00 RCX: 00007f54f62791b7
    [ 1088.622426] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055dff8b55d68
    [ 1088.622427] RBP: 000055dff8b55d00 R08: 00007fff2a947fb1 R09: 0000000000000000
    [ 1088.622427] R10: 00007f54f62f5cc0 R11: 0000000000000206 R12: 000055dff8b55d68
    [ 1088.622428] R13: 0000000000000001 R14: 000055dff8b55d68 R15: 00007fff2a94a3f0

    The cause for the bug is that when the "delayed" doorbell is invoked, it
    takes a reference on the doorbell entry and schedules work that is
    supposed to run the appropriate code and drop the doorbell entry
    reference. The code ignores the fact that if the work is already queued,
    it will not be scheduled to run one more time. As a result one of the
    references would not be dropped. When the code waits for the reference
    to get to zero, during balloon reset or module removal, it gets stuck.

    Fix it. Drop the reference if schedule_work() indicates that the work is
    already queued.

    Note that this bug got more apparent (or apparent at all) due to
    commit ce664331b248 ("vmw_balloon: VMCI_DOORBELL_SET does not check status").

    Fixes: 83e2ec765be03 ("VMCI: doorbell implementation.")
    Reported-by: Francois Rigault <rigault.francois@gmail.com>
    Cc: Jorgen Hansen <jhansen@vmware.com>
    Cc: Adit Ranadive <aditr@vmware.com>
    Cc: Alexios Zavras <alexios.zavras@intel.com>
    Cc: Vishnu DASA <vdasa@vmware.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Nadav Amit <namit@vmware.com>
    Reviewed-by: Vishnu Dasa <vdasa@vmware.com>
    Link: https://lore.kernel.org/r/20190820202638.49003-1-namit@vmware.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c25b7d78f0e871b10a38a0da9dbc9c538217bef9
Author: Ding Xiang <dingxiang@cmss.chinamobile.com>
Date:   Wed Aug 21 10:49:52 2019 +0300

    stm class: Fix a double free of stm_source_device

    commit 961b6ffe0e2c403b09a8efe4a2e986b3c415391a upstream.

    In the error path of stm_source_register_device(), the kfree is
    unnecessary, as the put_device() before it ends up calling
    stm_source_device_release() to free stm_source_device, leading to
    a double free at the outer kfree() call. Remove it.

    Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com>
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Fixes: 7bd1d4093c2fa ("stm class: Introduce an abstraction for System Trace Module devices")
    Link: https://lore.kernel.org/linux-arm-kernel/1563354988-23826-1-git-send-email-dingxiang@cmss.chinamobile.com/
    Cc: stable@vger.kernel.org # v4.4+
    Link: https://lore.kernel.org/r/20190821074955.3925-2-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2f1509fca476d763d94eb0026b28c22ab110688
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Tue Aug 27 10:10:43 2019 +0200

    mmc: core: Fix init of SD cards reporting an invalid VDD range

    commit 72741084d903e65e121c27bd29494d941729d4a1 upstream.

    The OCR register defines the supported range of VDD voltages for SD cards.
    However, it has turned out that some SD cards reports an invalid voltage
    range, for example having bit7 set.

    When a host supports MMC_CAP2_FULL_PWR_CYCLE and some of the voltages from
    the invalid VDD range, this triggers the core to run a power cycle of the
    card to try to initialize it at the lowest common supported voltage.
    Obviously this fails, since the card can't support it.

    Let's fix this problem, by clearing invalid bits from the read OCR register
    for SD cards, before proceeding with the VDD voltage negotiation.

    Cc: stable@vger.kernel.org
    Reported-by: Philip Langdale <philipl@overt.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Reviewed-by: Philip Langdale <philipl@overt.org>
    Tested-by: Philip Langdale <philipl@overt.org>
    Tested-by: Manuel Presnitz <mail@mpy.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12a897daa78b640bcdfd6422bf2d697c442549e1
Author: Eugen Hristev <eugen.hristev@microchip.com>
Date:   Thu Aug 8 08:35:40 2019 +0000

    mmc: sdhci-of-at91: add quirk for broken HS200

    commit 7871aa60ae0086fe4626abdf5ed13eeddf306c61 upstream.

    HS200 is not implemented in the driver, but the controller claims it
    through caps. Remove it via a quirk, to make sure the mmc core do not try
    to enable HS200, as it causes the eMMC initialization to fail.

    Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Fixes: bb5f8ea4d514 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC")
    Cc: stable@vger.kernel.org # v4.4+
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d1a41682781c2a268160d15eb8adf63024c4e70
Author: Sebastian Mayr <me@sam.st>
Date:   Sun Jul 28 17:26:17 2019 +0200

    uprobes/x86: Fix detection of 32-bit user mode

    [ Upstream commit 9212ec7d8357ea630031e89d0d399c761421c83b ]

    32-bit processes running on a 64-bit kernel are not always detected
    correctly, causing the process to crash when uretprobes are installed.

    The reason for the crash is that in_ia32_syscall() is used to determine the
    process's mode, which only works correctly when called from a syscall.

    In the case of uretprobes, however, the function is called from a exception
    and always returns 'false' on a 64-bit kernel. In consequence this leads to
    corruption of the process's return address.

    Fix this by using user_64bit_mode() instead of in_ia32_syscall(), which
    is correct in any situation.

    [ tglx: Add a comment and the following historical info ]

    This should have been detected by the rename which happened in commit

      abfb9498ee13 ("x86/entry: Rename is_{ia32,x32}_task() to in_{ia32,x32}_syscall()")

    which states in the changelog:

        The is_ia32_task()/is_x32_task() function names are a big misnomer: they
        suggests that the compat-ness of a system call is a task property, which
        is not true, the compatness of a system call purely depends on how it
        was invoked through the system call layer.
        .....

    and then it went and blindly renamed every call site.

    Sadly enough this was already mentioned here:

       8faaed1b9f50 ("uprobes/x86: Introduce sizeof_long(), cleanup adjust_ret_addr() and
    arch_uretprobe_hijack_return_addr()")

    where the changelog says:

        TODO: is_ia32_task() is not what we actually want, TS_COMPAT does
        not necessarily mean 32bit. Fortunately syscall-like insns can't be
        probed so it actually works, but it would be better to rename and
        use is_ia32_frame().

    and goes all the way back to:

        0326f5a94dde ("uprobes/core: Handle breakpoint and singlestep exceptions")

    Oh well. 7+ years until someone actually tried a uretprobe on a 32bit
    process on a 64bit kernel....

    Fixes: 0326f5a94dde ("uprobes/core: Handle breakpoint and singlestep exceptions")
    Signed-off-by: Sebastian Mayr <me@sam.st>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190728152617.7308-1-me@sam.st
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6029fe64cefa148900b58596e5335ac70ffb570
Author: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Date:   Fri Oct 27 13:25:30 2017 -0700

    ptrace,x86: Make user_64bit_mode() available to 32-bit builds

    [ Upstream commit e27c310af5c05cf876d9cad006928076c27f54d4 ]

    In its current form, user_64bit_mode() can only be used when CONFIG_X86_64
    is selected. This implies that code built with CONFIG_X86_64=n cannot use
    it. If a piece of code needs to be built for both CONFIG_X86_64=y and
    CONFIG_X86_64=n and wants to use this function, it needs to wrap it in
    an #ifdef/#endif; potentially, in multiple places.

    This can be easily avoided with a single #ifdef/#endif pair within
    user_64bit_mode() itself.

    Suggested-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Cc: "Michael S. Tsirkin" <mst@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: ricardo.neri@intel.com
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: Huang Rui <ray.huang@amd.com>
    Cc: Qiaowei Ren <qiaowei.ren@intel.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
    Cc: Chris Metcalf <cmetcalf@mellanox.com>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Colin Ian King <colin.king@canonical.com>
    Cc: Chen Yucong <slaoub@gmail.com>
    Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Lorenzo Stoakes <lstoakes@gmail.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Thomas Garnier <thgarnie@google.com>
    Link: https://lkml.kernel.org/r/1509135945-13762-4-git-send-email-ricardo.neri-calderon@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4761474088761cd0705a80943dfafa0f723696d1
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Aug 28 01:34:50 2019 +0800

    USB: storage: ums-realtek: Whitelist auto-delink support

    commit 1902a01e2bcc3abd7c9a18dc05e78c7ab4a53c54 upstream.

    Auto-delink requires writing special registers to ums-realtek devices.
    Unconditionally enable auto-delink may break newer devices.

    So only enable auto-delink by default for the original three IDs,
    0x0138, 0x0158 and 0x0159.

    Realtek is working on a patch to properly support auto-delink for other
    IDs.

    BugLink: https://bugs.launchpad.net/bugs/1838886
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190827173450.13572-2-kai.heng.feng@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00087c6e434e8705d97ef8c0f796b573894e981b
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Aug 28 01:34:49 2019 +0800

    USB: storage: ums-realtek: Update module parameter description for auto_delink_en

    commit f6445b6b2f2bb1745080af4a0926049e8bca2617 upstream.

    The option named "auto_delink_en" is a bit misleading, as setting it to
    false doesn't really disable auto-delink but let auto-delink be firmware
    controlled.

    Update the description to reflect the real usage of this parameter.

    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190827173450.13572-1-kai.heng.feng@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb1ff5020b3e55f88be1f506042b003d9478cbfd
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Tue Aug 27 12:51:50 2019 +0900

    usb: host: ohci: fix a race condition between shutdown and irq

    commit a349b95d7ca0cea71be4a7dac29830703de7eb62 upstream.

    This patch fixes an issue that the following error is
    possible to happen when ohci hardware causes an interruption
    and the system is shutting down at the same time.

    [   34.851754] usb 2-1: USB disconnect, device number 2
    [   35.166658] irq 156: nobody cared (try booting with the "irqpoll" option)
    [   35.173445] CPU: 0 PID: 22 Comm: kworker/0:1 Not tainted 5.3.0-rc5 #85
    [   35.179964] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)
    [   35.187886] Workqueue: usb_hub_wq hub_event
    [   35.192063] Call trace:
    [   35.194509]  dump_backtrace+0x0/0x150
    [   35.198165]  show_stack+0x14/0x20
    [   35.201475]  dump_stack+0xa0/0xc4
    [   35.204785]  __report_bad_irq+0x34/0xe8
    [   35.208614]  note_interrupt+0x2cc/0x318
    [   35.212446]  handle_irq_event_percpu+0x5c/0x88
    [   35.216883]  handle_irq_event+0x48/0x78
    [   35.220712]  handle_fasteoi_irq+0xb4/0x188
    [   35.224802]  generic_handle_irq+0x24/0x38
    [   35.228804]  __handle_domain_irq+0x5c/0xb0
    [   35.232893]  gic_handle_irq+0x58/0xa8
    [   35.236548]  el1_irq+0xb8/0x180
    [   35.239681]  __do_softirq+0x94/0x23c
    [   35.243253]  irq_exit+0xd0/0xd8
    [   35.246387]  __handle_domain_irq+0x60/0xb0
    [   35.250475]  gic_handle_irq+0x58/0xa8
    [   35.254130]  el1_irq+0xb8/0x180
    [   35.257268]  kernfs_find_ns+0x5c/0x120
    [   35.261010]  kernfs_find_and_get_ns+0x3c/0x60
    [   35.265361]  sysfs_unmerge_group+0x20/0x68
    [   35.269454]  dpm_sysfs_remove+0x2c/0x68
    [   35.273284]  device_del+0x80/0x370
    [   35.276683]  hid_destroy_device+0x28/0x60
    [   35.280686]  usbhid_disconnect+0x4c/0x80
    [   35.284602]  usb_unbind_interface+0x6c/0x268
    [   35.288867]  device_release_driver_internal+0xe4/0x1b0
    [   35.293998]  device_release_driver+0x14/0x20
    [   35.298261]  bus_remove_device+0x110/0x128
    [   35.302350]  device_del+0x148/0x370
    [   35.305832]  usb_disable_device+0x8c/0x1d0
    [   35.309921]  usb_disconnect+0xc8/0x2d0
    [   35.313663]  hub_event+0x6e0/0x1128
    [   35.317146]  process_one_work+0x1e0/0x320
    [   35.321148]  worker_thread+0x40/0x450
    [   35.324805]  kthread+0x124/0x128
    [   35.328027]  ret_from_fork+0x10/0x18
    [   35.331594] handlers:
    [   35.333862] [<0000000079300c1d>] usb_hcd_irq
    [   35.338126] [<0000000079300c1d>] usb_hcd_irq
    [   35.342389] Disabling IRQ #156

    ohci_shutdown() disables all the interrupt and rh_state is set to
    OHCI_RH_HALTED. In other hand, ohci_irq() is possible to enable
    OHCI_INTR_SF and OHCI_INTR_MIE on ohci_irq(). Note that OHCI_INTR_SF
    is possible to be set by start_ed_unlink() which is called:
     ohci_irq()
      -> process_done_list()
       -> takeback_td()
        -> start_ed_unlink()

    So, ohci_irq() has the following condition, the issue happens by
    &ohci->regs->intrenable = OHCI_INTR_MIE | OHCI_INTR_SF and
    ohci->rh_state = OHCI_RH_HALTED:

    	/* interrupt for some other device? */
    	if (ints == 0 || unlikely(ohci->rh_state == OHCI_RH_HALTED))
    		return IRQ_NOTMINE;

    To fix the issue, ohci_shutdown() holds the spin lock while disabling
    the interruption and changing the rh_state flag to prevent reenable
    the OHCI_INTR_MIE unexpectedly. Note that io_watchdog_func() also
    calls the ohci_shutdown() and it already held the spin lock, so that
    the patch makes a new function as _ohci_shutdown().

    This patch is inspired by a Renesas R-Car Gen3 BSP patch
    from Tho Vu.

    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/1566877910-6020-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d743d816acea90068b76cf2294f2e3b88bdaa41
Author: Oliver Neukum <oneukum@suse.com>
Date:   Tue Aug 27 12:34:36 2019 +0200

    USB: cdc-wdm: fix race between write and disconnect due to flag abuse

    commit 1426bd2c9f7e3126e2678e7469dca9fd9fc6dd3e upstream.

    In case of a disconnect an ongoing flush() has to be made fail.
    Nevertheless we cannot be sure that any pending URB has already
    finished, so although they will never succeed, they still must
    not be touched.
    The clean solution for this is to check for WDM_IN_USE
    and WDM_DISCONNECTED in flush(). There is no point in ever
    clearing WDM_IN_USE, as no further writes make sense.

    The issue is as old as the driver.

    Fixes: afba937e540c9 ("USB: CDC WDM driver")
    Reported-by: syzbot+d232cca6ec42c2edb3fc@syzkaller.appspotmail.com
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190827103436.21143-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f575b509cce81910666bdb0f4958cd01ab6d265
Author: Henk van der Laan <opensource@henkvdlaan.com>
Date:   Fri Aug 16 22:08:47 2019 +0200

    usb-storage: Add new JMS567 revision to unusual_devs

    commit 08d676d1685c2a29e4d0e1b0242324e564d4589e upstream.

    Revision 0x0117 suffers from an identical issue to earlier revisions,
    therefore it should be added to the quirks list.

    Signed-off-by: Henk van der Laan <opensource@henkvdlaan.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190816200847.21366-1-opensource@henkvdlaan.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bd0d83e2d5a5cc6e40e2d24020bfedb63b81995
Author: Bandan Das <bsd@redhat.com>
Date:   Mon Aug 26 06:15:13 2019 -0400

    x86/apic: Include the LDR when clearing out APIC registers

    commit 558682b5291937a70748d36fd9ba757fb25b99ae upstream.

    Although APIC initialization will typically clear out the LDR before
    setting it, the APIC cleanup code should reset the LDR.

    This was discovered with a 32-bit KVM guest jumping into a kdump
    kernel. The stale bits in the LDR triggered a bug in the KVM APIC
    implementation which caused the destination mapping for VCPUs to be
    corrupted.

    Note that this isn't intended to paper over the KVM APIC bug. The kernel
    has to clear the LDR when resetting the APIC registers except when X2APIC
    is enabled.

    This lacks a Fixes tag because missing to clear LDR goes way back into pre
    git history.

    [ tglx: Made x2apic_enabled a function call as required ]

    Signed-off-by: Bandan Das <bsd@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190826101513.5080-3-bsd@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26285030611e4b410c1e30afc2c9d1601fa7a128
Author: Bandan Das <bsd@redhat.com>
Date:   Mon Aug 26 06:15:12 2019 -0400

    x86/apic: Do not initialize LDR and DFR for bigsmp

    commit bae3a8d3308ee69a7dbdf145911b18dfda8ade0d upstream.

    Legacy apic init uses bigsmp for smp systems with 8 and more CPUs. The
    bigsmp APIC implementation uses physical destination mode, but it
    nevertheless initializes LDR and DFR. The LDR even ends up incorrectly with
    multiple bit being set.

    This does not cause a functional problem because LDR and DFR are ignored
    when physical destination mode is active, but it triggered a problem on a
    32-bit KVM guest which jumps into a kdump kernel.

    The multiple bits set unearthed a bug in the KVM APIC implementation. The
    code which creates the logical destination map for VCPUs ignores the
    disabled state of the APIC and ends up overwriting an existing valid entry
    and as a result, APIC calibration hangs in the guest during kdump
    initialization.

    Remove the bogus LDR/DFR initialization.

    This is not intended to work around the KVM APIC bug. The LDR/DFR
    ininitalization is wrong on its own.

    The issue goes back into the pre git history. The fixes tag is the commit
    in the bitkeeper import which introduced bigsmp support in 2003.

      git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git

    Fixes: db7b9e9f26b8 ("[PATCH] Clustered APIC setup for >8 CPU systems")
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Bandan Das <bsd@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190826101513.5080-2-bsd@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fff074fc4aecfb437bfa8bb690b7847a7d7a4d2
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Fri Aug 23 13:55:44 2019 -0700

    KVM: x86: Don't update RIP or do single-step on faulting emulation

    commit 75ee23b30dc712d80d2421a9a547e7ab6e379b44 upstream.

    Don't advance RIP or inject a single-step #DB if emulation signals a
    fault.  This logic applies to all state updates that are conditional on
    clean retirement of the emulation instruction, e.g. updating RFLAGS was
    previously handled by commit 38827dbd3fb85 ("KVM: x86: Do not update
    EFLAGS on faulting emulation").

    Not advancing RIP is likely a nop, i.e. ctxt->eip isn't updated with
    ctxt->_eip until emulation "retires" anyways.  Skipping #DB injection
    fixes a bug reported by Andy Lutomirski where a #UD on SYSCALL due to
    invalid state with EFLAGS.TF=1 would loop indefinitely due to emulation
    overwriting the #UD with #DB and thus restarting the bad SYSCALL over
    and over.

    Cc: Nadav Amit <nadav.amit@gmail.com>
    Cc: stable@vger.kernel.org
    Reported-by: Andy Lutomirski <luto@kernel.org>
    Fixes: 663f4c61b803 ("KVM: x86: handle singlestep during emulation")
    Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3abf92c855c9439f57880b89f1ae8267a99ab45
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sun Aug 25 09:21:44 2019 +0200

    ALSA: seq: Fix potential concurrent access to the deleted pool

    commit 75545304eba6a3d282f923b96a466dc25a81e359 upstream.

    The input pool of a client might be deleted via the resize ioctl, the
    the access to it should be covered by the proper locks.  Currently the
    only missing place is the call in snd_seq_ioctl_get_client_pool(), and
    this patch papers over it.

    Reported-by: syzbot+4a75454b9ca2777f35c7@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec1933594cbb1039f0341847d457c320a2b663a4
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Aug 16 21:26:22 2019 -0700

    tcp: make sure EPOLLOUT wont be missed

    [ Upstream commit ef8d8ccdc216f797e66cb4a1372f5c4c285ce1e4 ]

    As Jason Baron explained in commit 790ba4566c1a ("tcp: set SOCK_NOSPACE
    under memory pressure"), it is crucial we properly set SOCK_NOSPACE
    when needed.

    However, Jason patch had a bug, because the 'nonblocking' status
    as far as sk_stream_wait_memory() is concerned is governed
    by MSG_DONTWAIT flag passed at sendmsg() time :

        long timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT);

    So it is very possible that tcp sendmsg() calls sk_stream_wait_memory(),
    and that sk_stream_wait_memory() returns -EAGAIN with SOCK_NOSPACE
    cleared, if sk->sk_sndtimeo has been set to a small (but not zero)
    value.

    This patch removes the 'noblock' variable since we must always
    set SOCK_NOSPACE if -EAGAIN is returned.

    It also renames the do_nonblock label since we might reach this
    code path even if we were in blocking mode.

    Fixes: 790ba4566c1a ("tcp: set SOCK_NOSPACE under memory pressure")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jason Baron <jbaron@akamai.com>
    Reported-by: Vladimir Rutsky  <rutsky@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Acked-by: Jason Baron <jbaron@akamai.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a485888b5189845f0b6c58ae89661a402a80402a
Author: Hui Peng <benquike@gmail.com>
Date:   Tue Aug 13 22:34:04 2019 -0400

    ALSA: usb-audio: Fix an OOB bug in parse_audio_mixer_unit

    commit daac07156b330b18eb5071aec4b3ddca1c377f2c upstream.

    The `uac_mixer_unit_descriptor` shown as below is read from the
    device side. In `parse_audio_mixer_unit`, `baSourceID` field is
    accessed from index 0 to `bNrInPins` - 1, the current implementation
    assumes that descriptor is always valid (the length  of descriptor
    is no shorter than 5 + `bNrInPins`). If a descriptor read from
    the device side is invalid, it may trigger out-of-bound memory
    access.

    ```
    struct uac_mixer_unit_descriptor {
    	__u8 bLength;
    	__u8 bDescriptorType;
    	__u8 bDescriptorSubtype;
    	__u8 bUnitID;
    	__u8 bNrInPins;
    	__u8 baSourceID[];
    }
    ```

    This patch fixes the bug by add a sanity check on the length of
    the descriptor.

    Reported-by: Hui Peng <benquike@gmail.com>
    Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Hui Peng <benquike@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 735a16d1afc01320392669f4ea64c84d435faf1c
Author: Hui Peng <benquike@gmail.com>
Date:   Thu Aug 15 00:31:34 2019 -0400

    ALSA: usb-audio: Fix a stack buffer overflow bug in check_input_term

    commit 19bce474c45be69a284ecee660aa12d8f1e88f18 upstream.

    `check_input_term` recursively calls itself with input from
    device side (e.g., uac_input_terminal_descriptor.bCSourceID)
    as argument (id). In `check_input_term`, if `check_input_term`
    is called with the same `id` argument as the caller, it triggers
    endless recursive call, resulting kernel space stack overflow.

    This patch fixes the bug by adding a bitmap to `struct mixer_build`
    to keep track of the checked ids and stop the execution if some id
    has been checked (similar to how parse_audio_unit handles unitid
    argument).

    Reported-by: Hui Peng <benquike@gmail.com>
   …
zxc070 added a commit to zxc070/kernel_xiaomi_lavender that referenced this issue Sep 12, 2019
Merge tag 4.4.191 and 4.4.192 into eas-pie
commit 8a227a3afe03f5b864b43233fe258c57719d25a3
Merge: 1b3d0a42f2aa 882f8791e141
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Tue Sep 10 15:31:55 2019 -0700

    Merge 4.4.192 into kernel.lnx.4.4.r34-rel

    Changes in 4.4.192: (24 commits)
            net: tundra: tsi108: use spin_lock_irqsave instead of spin_lock_irq in IRQ context
            net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
            Bluetooth: btqca: Add a short delay before downloading the NVM
            ibmveth: Convert multicast list size for little-endian system
            gpio: Fix build error of function redefinition
            cxgb4: fix a memory leak bug
            net: myri10ge: fix memory leaks
            cx82310_eth: fix a memory leak bug
            net: kalmia: fix memory leaks
            wimax/i2400m: fix a memory leak bug
            ravb: Fix use-after-free ravb_tstamp_skb
            Tools: hv: kvp: eliminate 'may be used uninitialized' warning
            IB/mlx4: Fix memory leaks
            ceph: fix buffer free while holding i_ceph_lock in __ceph_setxattr()
            KVM: arm/arm64: Only skip MMIO insn once
            libceph: allow ceph_buffer_put() to receive a NULL ceph_buffer
            spi: bcm2835aux: ensure interrupts are enabled for shared handler
            spi: bcm2835aux: unifying code between polling and interrupt driven code
            spi: bcm2835aux: remove dangerous uncontrolled read of fifo
            spi: bcm2835aux: fix corruptions for longer spi transfers
            Revert "x86/apic: Include the LDR when clearing out APIC registers"
            net: fix skb use after free in netpoll
            net: stmmac: dwmac-rk: Don't fail if phy regulator is absent
            Linux 4.4.192

    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>

commit 882f8791e1412d81e5cc7a4c379c73195155b40f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Sep 10 10:29:50 2019 +0100

    Linux 4.4.192

commit 89e0660bc5316acef9a4dc7bf8ec1ffed8a57c8c
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Thu Aug 29 11:17:24 2019 +0800

    net: stmmac: dwmac-rk: Don't fail if phy regulator is absent

    [ Upstream commit 3b25528e1e355c803e73aa326ce657b5606cda73 ]

    The devicetree binding lists the phy phy as optional. As such, the
    driver should not bail out if it can't find a regulator. Instead it
    should just skip the remaining regulator related code and continue
    on normally.

    Skip the remainder of phy_power_on() if a regulator supply isn't
    available. This also gets rid of the bogus return code.

    Fixes: 2e12f536635f ("net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator")
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6198d2b4ff0195ebc228a231f96918855ce722f
Author: Feng Sun <loyou85@gmail.com>
Date:   Mon Aug 26 14:46:04 2019 +0800

    net: fix skb use after free in netpoll

    [ Upstream commit 2c1644cf6d46a8267d79ed95cb9b563839346562 ]

    After commit baeababb5b85d5c4e6c917efe2a1504179438d3b
    ("tun: return NET_XMIT_DROP for dropped packets"),
    when tun_net_xmit drop packets, it will free skb and return NET_XMIT_DROP,
    netpoll_send_skb_on_dev will run into following use after free cases:
    1. retry netpoll_start_xmit with freed skb;
    2. queue freed skb in npinfo->txq.
    queue_process will also run into use after free case.

    hit netpoll_send_skb_on_dev first case with following kernel log:

    [  117.864773] kernel BUG at mm/slub.c:306!
    [  117.864773] invalid opcode: 0000 [#1] SMP PTI
    [  117.864774] CPU: 3 PID: 2627 Comm: loop_printmsg Kdump: loaded Tainted: P           OE     5.3.0-050300rc5-generic #201908182231
    [  117.864775] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [  117.864775] RIP: 0010:kmem_cache_free+0x28d/0x2b0
    [  117.864781] Call Trace:
    [  117.864781]  ? tun_net_xmit+0x21c/0x460
    [  117.864781]  kfree_skbmem+0x4e/0x60
    [  117.864782]  kfree_skb+0x3a/0xa0
    [  117.864782]  tun_net_xmit+0x21c/0x460
    [  117.864782]  netpoll_start_xmit+0x11d/0x1b0
    [  117.864788]  netpoll_send_skb_on_dev+0x1b8/0x200
    [  117.864789]  __br_forward+0x1b9/0x1e0 [bridge]
    [  117.864789]  ? skb_clone+0x53/0xd0
    [  117.864790]  ? __skb_clone+0x2e/0x120
    [  117.864790]  deliver_clone+0x37/0x50 [bridge]
    [  117.864790]  maybe_deliver+0x89/0xc0 [bridge]
    [  117.864791]  br_flood+0x6c/0x130 [bridge]
    [  117.864791]  br_dev_xmit+0x315/0x3c0 [bridge]
    [  117.864792]  netpoll_start_xmit+0x11d/0x1b0
    [  117.864792]  netpoll_send_skb_on_dev+0x1b8/0x200
    [  117.864792]  netpoll_send_udp+0x2c6/0x3e8
    [  117.864793]  write_msg+0xd9/0xf0 [netconsole]
    [  117.864793]  console_unlock+0x386/0x4e0
    [  117.864793]  vprintk_emit+0x17e/0x280
    [  117.864794]  vprintk_default+0x29/0x50
    [  117.864794]  vprintk_func+0x4c/0xbc
    [  117.864794]  printk+0x58/0x6f
    [  117.864795]  loop_fun+0x24/0x41 [printmsg_loop]
    [  117.864795]  kthread+0x104/0x140
    [  117.864795]  ? 0xffffffffc05b1000
    [  117.864796]  ? kthread_park+0x80/0x80
    [  117.864796]  ret_from_fork+0x35/0x40

    Signed-off-by: Feng Sun <loyou85@gmail.com>
    Signed-off-by: Xiaojun Zhao <xiaojunzhao141@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94eb5357f6d688b364eaf52d4f7fa187102396a7
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Sep 7 14:25:54 2019 -0700

    Revert "x86/apic: Include the LDR when clearing out APIC registers"

    [ Upstream commit 950b07c14e8c59444e2359f15fd70ed5112e11a0 ]

    This reverts commit 558682b5291937a70748d36fd9ba757fb25b99ae.

    Chris Wilson reports that it breaks his CPU hotplug test scripts.  In
    particular, it breaks offlining and then re-onlining the boot CPU, which
    we treat specially (and the BIOS does too).

    The symptoms are that we can offline the CPU, but it then does not come
    back online again:

        smpboot: CPU 0 is now offline
        smpboot: Booting Node 0 Processor 0 APIC 0x0
        smpboot: do_boot_cpu failed(-1) to wakeup CPU#0

    Thomas says he knows why it's broken (my personal suspicion: our magic
    handling of the "cpu0_logical_apicid" thing), but for 5.3 the right fix
    is to just revert it, since we've never touched the LDR bits before, and
    it's not worth the risk to do anything else at this stage.

    [ Hotpluging of the boot CPU is special anyway, and should be off by
      default. See the "BOOTPARAM_HOTPLUG_CPU0" config option and the
      cpu0_hotplug kernel parameter.

      In general you should not do it, and it has various known limitations
      (hibernate and suspend require the boot CPU, for example).

      But it should work, even if the boot CPU is special and needs careful
      treatment       - Linus ]

    Link: https://lore.kernel.org/lkml/156785100521.13300.14461504732265570003@skylake-alporthouse-com/
    Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Bandan Das <bsd@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e187a57fc653cfc3016875b80f53f78af4eac172
Author: Martin Sperl <kernel@martin.sperl.org>
Date:   Sat Mar 30 09:31:00 2019 +0000

    spi: bcm2835aux: fix corruptions for longer spi transfers

    [ Upstream commit 73b114ee7db1750c0b535199fae383b109bd61d0 ]

    On long running tests with a mcp2517fd can controller it showed that
    on rare occations the data read shows corruptions for longer spi transfers.

    Example of a 22 byte transfer:

    expected (as captured on logic analyzer):
    FF FF 78 00 00 00 08 06 00 00 91 20 77 56 84 85 86 87 88 89 8a 8b

    read by the driver:
    FF FF 78 00 00 00 08 06 00 00 91 20 77 56 84 88 89 8a 00 00 8b 9b

    To fix this use BCM2835_AUX_SPI_STAT_RX_LVL to determine when we may
    read data from the fifo reliably without any corruption.

    Surprisingly the only values ever empirically read in
    BCM2835_AUX_SPI_STAT_RX_LVL are 0x00, 0x10, 0x20 and 0x30.
    So whenever the mask is not 0 we can read from the fifo in a safe manner.

    The patch has now been tested intensively and we are no longer
    able to reproduce the "RX" issue any longer.

    Fixes: 1ea29b39f4c812ec ("spi: bcm2835aux: add bcm2835 auxiliary spi device...")
    Reported-by: Hubert Denkmair <h.denkmair@intence.de>
    Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
    Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2f16660fc8687febdc133f9b5082482f2a280fc
Author: Martin Sperl <kernel@martin.sperl.org>
Date:   Sat Mar 30 09:30:59 2019 +0000

    spi: bcm2835aux: remove dangerous uncontrolled read of fifo

    [ Upstream commit c7de8500fd8ecbb544846dd5f11dca578c3777e1 ]

    This read of the fifo is a potential candidate for a race condition
    as the spi transfer is not necessarily finished and so can lead to
    an early read of the fifo that still misses data.

    So it has been removed.

    Fixes: 1ea29b39f4c812ec ("spi: bcm2835aux: add bcm2835 auxiliary spi device...")
    Suggested-by: Hubert Denkmair <h.denkmair@intence.de>
    Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
    Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5473cd1dbf972ff06d89400d42973eb31c72dec1
Author: Martin Sperl <kernel@martin.sperl.org>
Date:   Sat Mar 30 09:30:58 2019 +0000

    spi: bcm2835aux: unifying code between polling and interrupt driven code

    [ Upstream commit 7188a6f0eee3f1fae5d826cfc6d569657ff950ec ]

    Sharing more code between polling and interrupt-driven mode.

    Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
    Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c99ad4f20c5b4d550745e1beaeaa24ed2cf873ba
Author: Rob Herring <robh@kernel.org>
Date:   Thu May 3 13:09:44 2018 -0500

    spi: bcm2835aux: ensure interrupts are enabled for shared handler

    [ Upstream commit bc519d9574618e47a0c788000fb78da95e18d953 ]

    The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
    Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
    DT change which breaks compatibility with older kernels. The AUX irqchip
    was already rejected for upstream[1] and the DT change would break
    working systems if the DTB is updated to a newer one. The latter issue
    was brought to my attention by Alex Graf.

    The root cause however is a bug in the shared handler. Shared handlers
    must check that interrupts are actually enabled before servicing the
    interrupt. Add a check that the TXEMPTY or IDLE interrupts are enabled.

    [1] https://patchwork.kernel.org/patch/9781221/

    Cc: Alexander Graf <agraf@suse.de>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Eric Anholt <eric@anholt.net>
    Cc: Stefan Wahren <stefan.wahren@i2se.com>
    Cc: Florian Fainelli <f.fainelli@gmail.com>
    Cc: Ray Jui <rjui@broadcom.com>
    Cc: Scott Branden <sbranden@broadcom.com>
    Cc: bcm-kernel-feedback-list@broadcom.com
    Cc: linux-spi@vger.kernel.org
    Cc: linux-rpi-kernel@lists.infradead.org
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Rob Herring <robh@kernel.org>
    Reviewed-by: Eric Anholt <eric@anholt.net>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c3083eff1b1b3bdae7389ff0e2fb7ae9423561e4
Author: Luis Henriques <lhenriques@suse.com>
Date:   Fri Jul 19 15:32:19 2019 +0100

    libceph: allow ceph_buffer_put() to receive a NULL ceph_buffer

    [ Upstream commit 5c498950f730aa17c5f8a2cdcb903524e4002ed2 ]

    Signed-off-by: Luis Henriques <lhenriques@suse.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bce83d9ccca56b9ea9b7cd88499681d10d5062ea
Author: Andrew Jones <drjones@redhat.com>
Date:   Thu Aug 22 13:03:05 2019 +0200

    KVM: arm/arm64: Only skip MMIO insn once

    [ Upstream commit 2113c5f62b7423e4a72b890bd479704aa85c81ba ]

    If after an MMIO exit to userspace a VCPU is immediately run with an
    immediate_exit request, such as when a signal is delivered or an MMIO
    emulation completion is needed, then the VCPU completes the MMIO
    emulation and immediately returns to userspace. As the exit_reason
    does not get changed from KVM_EXIT_MMIO in these cases we have to
    be careful not to complete the MMIO emulation again, when the VCPU is
    eventually run again, because the emulation does an instruction skip
    (and doing too many skips would be a waste of guest code :-) We need
    to use additional VCPU state to track if the emulation is complete.
    As luck would have it, we already have 'mmio_needed', which even
    appears to be used in this way by other architectures already.

    Fixes: 0d640732dbeb ("arm64: KVM: Skip MMIO insn after emulation")
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Andrew Jones <drjones@redhat.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1d86cb8d3204337e1853b84d69ea0f30dc0ba973
Author: Luis Henriques <lhenriques@suse.com>
Date:   Fri Jul 19 15:32:20 2019 +0100

    ceph: fix buffer free while holding i_ceph_lock in __ceph_setxattr()

    [ Upstream commit 86968ef21596515958d5f0a40233d02be78ecec0 ]

    Calling ceph_buffer_put() in __ceph_setxattr() may end up freeing the
    i_xattrs.prealloc_blob buffer while holding the i_ceph_lock.  This can be
    fixed by postponing the call until later, when the lock is released.

    The following backtrace was triggered by fstests generic/117.

      BUG: sleeping function called from invalid context at mm/vmalloc.c:2283
      in_atomic(): 1, irqs_disabled(): 0, pid: 650, name: fsstress
      3 locks held by fsstress/650:
       #0: 00000000870a0fe8 (sb_writers#8){.+.+}, at: mnt_want_write+0x20/0x50
       #1: 00000000ba0c4c74 (&type->i_mutex_dir_key#6){++++}, at: vfs_setxattr+0x55/0xa0
       #2: 000000008dfbb3f2 (&(&ci->i_ceph_lock)->rlock){+.+.}, at: __ceph_setxattr+0x297/0x810
      CPU: 1 PID: 650 Comm: fsstress Not tainted 5.2.0+ #437
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-prebuilt.qemu.org 04/01/2014
      Call Trace:
       dump_stack+0x67/0x90
       ___might_sleep.cold+0x9f/0xb1
       vfree+0x4b/0x60
       ceph_buffer_release+0x1b/0x60
       __ceph_setxattr+0x2b4/0x810
       __vfs_setxattr+0x66/0x80
       __vfs_setxattr_noperm+0x59/0xf0
       vfs_setxattr+0x81/0xa0
       setxattr+0x115/0x230
       ? filename_lookup+0xc9/0x140
       ? rcu_read_lock_sched_held+0x74/0x80
       ? rcu_sync_lockdep_assert+0x2e/0x60
       ? __sb_start_write+0x142/0x1a0
       ? mnt_want_write+0x20/0x50
       path_setxattr+0xba/0xd0
       __x64_sys_lsetxattr+0x24/0x30
       do_syscall_64+0x50/0x1c0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x7ff23514359a

    Signed-off-by: Luis Henriques <lhenriques@suse.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bc68ba54a2d32e2e3eaf826159b1dc8878cb109b
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Sun Aug 18 15:23:01 2019 -0500

    IB/mlx4: Fix memory leaks

    [ Upstream commit 5c1baaa82cea2c815a5180ded402a7cd455d1810 ]

    In mlx4_ib_alloc_pv_bufs(), 'tun_qp->tx_ring' is allocated through
    kcalloc(). However, it is not always deallocated in the following execution
    if an error occurs, leading to memory leaks. To fix this issue, free
    'tun_qp->tx_ring' whenever an error occurs.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Acked-by: Leon Romanovsky <leonro@mellanox.com>
    Link: https://lore.kernel.org/r/1566159781-4642-1-git-send-email-wenwen@cs.uga.edu
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6442370b5642d38c6f9ae8edb71d514aaa6c3dab
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Mon Aug 19 16:44:09 2019 +0200

    Tools: hv: kvp: eliminate 'may be used uninitialized' warning

    [ Upstream commit 89eb4d8d25722a0a0194cf7fa47ba602e32a6da7 ]

    When building hv_kvp_daemon GCC-8.3 complains:

    hv_kvp_daemon.c: In function ‘kvp_get_ip_info.constprop’:
    hv_kvp_daemon.c:812:30: warning: ‘ip_buffer’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      struct hv_kvp_ipaddr_value *ip_buffer;

    this seems to be a false positive: we only use ip_buffer when
    op == KVP_OP_GET_IP_INFO and it is only unset when op == KVP_OP_ENUMERATE.

    Silence the warning by initializing ip_buffer to NULL.

    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf3583e15956de79e9c37c5ca609434a04f8a224
Author: Tho Vu <tho.vu.wh@rvc.renesas.com>
Date:   Fri Aug 16 17:17:02 2019 +0200

    ravb: Fix use-after-free ravb_tstamp_skb

    [ Upstream commit cfef46d692efd852a0da6803f920cc756eea2855 ]

    When a Tx timestamp is requested, a pointer to the skb is stored in the
    ravb_tstamp_skb struct. This was done without an skb_get. There exists
    the possibility that the skb could be freed by ravb_tx_free (when
    ravb_tx_free is called from ravb_start_xmit) before the timestamp was
    processed, leading to a use-after-free bug.

    Use skb_get when filling a ravb_tstamp_skb struct, and add appropriate
    frees/consumes when a ravb_tstamp_skb struct is freed.

    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Signed-off-by: Tho Vu <tho.vu.wh@rvc.renesas.com>
    Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
    Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62b1e22efe3e6eb629d8a7130bf3e69ec86e6293
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Thu Aug 15 15:29:51 2019 -0500

    wimax/i2400m: fix a memory leak bug

    [ Upstream commit 44ef3a03252844a8753479b0cea7f29e4a804bdc ]

    In i2400m_barker_db_init(), 'options_orig' is allocated through kstrdup()
    to hold the original command line options. Then, the options are parsed.
    However, if an error occurs during the parsing process, 'options_orig' is
    not deallocated, leading to a memory leak bug. To fix this issue, free
    'options_orig' before returning the error.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b25f01d604ed86d379420f038c91555faef0afc
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Wed Aug 14 13:56:43 2019 -0500

    net: kalmia: fix memory leaks

    [ Upstream commit f1472cb09f11ddb41d4be84f0650835cb65a9073 ]

    In kalmia_init_and_get_ethernet_addr(), 'usb_buf' is allocated through
    kmalloc(). In the following execution, if the 'status' returned by
    kalmia_send_init_packet() is not 0, 'usb_buf' is not deallocated, leading
    to memory leaks. To fix this issue, add the 'out' label to free 'usb_buf'.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d28afe7a79edf0f2afd1005d9c2a83fab1a1ab6
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Wed Aug 14 13:03:38 2019 -0500

    cx82310_eth: fix a memory leak bug

    [ Upstream commit 1eca92eef18719027d394bf1a2d276f43e7cf886 ]

    In cx82310_bind(), 'dev->partial_data' is allocated through kmalloc().
    Then, the execution waits for the firmware to become ready. If the firmware
    is not ready in time, the execution is terminated. However, the allocated
    'dev->partial_data' is not deallocated on this path, leading to a memory
    leak bug. To fix this issue, free 'dev->partial_data' before returning the
    error.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6f3170c57da89158b1aa920fc547f481d278480
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Wed Aug 14 01:38:39 2019 -0500

    net: myri10ge: fix memory leaks

    [ Upstream commit 20fb7c7a39b5c719e2e619673b5f5729ee7d2306 ]

    In myri10ge_probe(), myri10ge_alloc_slices() is invoked to allocate slices
    related structures. Later on, myri10ge_request_irq() is used to get an irq.
    However, if this process fails, the allocated slices related structures are
    not deallocated, leading to memory leaks. To fix this issue, revise the
    target label of the goto statement to 'abort_with_slices'.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa6d2679e5cac2fd5ece39c8edb5f503064c5fcd
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Tue Aug 13 04:18:52 2019 -0500

    cxgb4: fix a memory leak bug

    [ Upstream commit c554336efa9bbc28d6ec14efbee3c7d63c61a34f ]

    In blocked_fl_write(), 't' is not deallocated if bitmap_parse_user() fails,
    leading to a memory leak bug. To fix this issue, free t before returning
    the error.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f46a46a9de0f1e005f64ade70336f9505a067a6e
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Wed Jul 31 20:38:14 2019 +0800

    gpio: Fix build error of function redefinition

    [ Upstream commit 68e03b85474a51ec1921b4d13204782594ef7223 ]

    when do randbuilding, I got this error:

    In file included from drivers/hwmon/pmbus/ucd9000.c:19:0:
    ./include/linux/gpio/driver.h:576:1: error: redefinition of gpiochip_add_pin_range
     gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
     ^~~~~~~~~~~~~~~~~~~~~~
    In file included from drivers/hwmon/pmbus/ucd9000.c:18:0:
    ./include/linux/gpio.h:245:1: note: previous definition of gpiochip_add_pin_range was here
     gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
     ^~~~~~~~~~~~~~~~~~~~~~

    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: 964cb341882f ("gpio: move pincontrol calls to <linux/gpio/driver.h>")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Link: https://lore.kernel.org/r/20190731123814.46624-1-yuehaibing@huawei.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da5cc03c7562d25a3b66c748b845d9717d6d22b3
Author: Thomas Falcon <tlfalcon@linux.ibm.com>
Date:   Mon Aug 12 16:13:06 2019 -0500

    ibmveth: Convert multicast list size for little-endian system

    [ Upstream commit 66cf4710b23ab2adda11155684a2c8826f4fe732 ]

    The ibm,mac-address-filters property defines the maximum number of
    addresses the hypervisor's multicast filter list can support. It is
    encoded as a big-endian integer in the OF device tree, but the virtual
    ethernet driver does not convert it for use by little-endian systems.
    As a result, the driver is not behaving as it should on affected systems
    when a large number of multicast addresses are assigned to the device.

    Reported-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
    Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5694f0d1cb10e9b9faaf47ba5b21f1d664f3a3ba
Author: Matthias Kaehlcke <mka@chromium.org>
Date:   Tue Jul 9 15:44:50 2019 -0700

    Bluetooth: btqca: Add a short delay before downloading the NVM

    [ Upstream commit 8059ba0bd0e4694e51c2ee6438a77b325f06c0d5 ]

    On WCN3990 downloading the NVM sometimes fails with a "TLV response
    size mismatch" error:

    [  174.949955] Bluetooth: btqca.c:qca_download_firmware() hci0: QCA Downloading qca/crnv21.bin
    [  174.958718] Bluetooth: btqca.c:qca_tlv_send_segment() hci0: QCA TLV response size mismatch

    It seems the controller needs a short time after downloading the
    firmware before it is ready for the NVM. A delay as short as 1 ms
    seems sufficient, make it 10 ms just in case. No event is received
    during the delay, hence we don't just silently drop an extra event.

    Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffb54f3eae723ca6d7ff34187bdfce91a0d28fce
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Sun Aug 11 20:13:45 2019 -0700

    net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx

    [ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

    clang warns:

    drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
    '&&' with constant operand [-Wconstant-logical-operand]
                            if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                      ^  ~~~~~~~~~~~~
    drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
    bitwise operation
                            if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                      ^~
                                                      &
    drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
    silence this warning
                            if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                     ~^~~~~~~~~~~~~~~
    1 warning generated.

    Explicitly check that NET_IP_ALIGN is not zero, which matches how this
    is checked in other parts of the tree. Because NET_IP_ALIGN is a build
    time constant, this check will be constant folded away during
    optimization.

    Fixes: 82a9928db560 ("tc35815: Enable StripCRC feature")
    Link: https://github.com/ClangBuiltLinux/linux/issues/608
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e040f074d49fb6fde93112a2350af5462a494c04
Author: Fuqian Huang <huangfq.daxian@gmail.com>
Date:   Fri Aug 9 13:35:39 2019 +0800

    net: tundra: tsi108: use spin_lock_irqsave instead of spin_lock_irq in IRQ context

    [ Upstream commit 8c25d0887a8bd0e1ca2074ac0c6dff173787a83b ]

    As spin_unlock_irq will enable interrupts.
    Function tsi108_stat_carry is called from interrupt handler tsi108_irq.
    Interrupts are enabled in interrupt handler.
    Use spin_lock_irqsave/spin_unlock_irqrestore instead of spin_(un)lock_irq
    in IRQ context to avoid this.

    Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b3d0a42f2aad1204dd1b489bb8d46c158ddb41f
Merge: 41bd92eff615 efbc4a364bd5
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Fri Sep 6 09:02:34 2019 -0700

    Merge 4.4.191 into kernel.lnx.4.4.r34-rel

    Changes in 4.4.191: (77 commits)
            HID: Add 044f:b320 ThrustMaster, Inc. 2 in 1 DT
            MIPS: kernel: only use i8253 clocksource with periodic clockevent
            netfilter: ebtables: fix a memory leak bug in compat
            bonding: Force slave speed check after link state recovery for 802.3ad
            can: dev: call netif_carrier_off() in register_candev()
            st21nfca_connectivity_event_received: null check the allocation
            st_nci_hci_connectivity_event_received: null check the allocation
            ASoC: ti: davinci-mcasp: Correct slot_width posed constraint
            net: usb: qmi_wwan: Add the BroadMobi BM818 card
            isdn: mISDN: hfcsusb: Fix possible null-pointer dereferences in start_isoc_chain()
            isdn: hfcsusb: Fix mISDN driver crash caused by transfer buffer on the stack
            perf bench numa: Fix cpu0 binding
            can: sja1000: force the string buffer NULL-terminated
            can: peak_usb: force the string buffer NULL-terminated
            NFSv4: Fix a potential sleep while atomic in nfs4_do_reclaim()
            net: cxgb3_main: Fix a resource leak in a error path in 'init_one()'
            net: hisilicon: make hip04_tx_reclaim non-reentrant
            net: hisilicon: fix hip04-xmit never return TX_BUSY
            net: hisilicon: Fix dma_map_single failed on arm64
            libata: add SG safety checks in SFF pio transfers
            selftests: kvm: Adding config fragments
            HID: wacom: correct misreported EKR ring values
            Revert "dm bufio: fix deadlock with loop device"
            userfaultfd_release: always remove uffd flags and clear vm_userfaultfd_ctx
            x86/retpoline: Don't clobber RFLAGS during CALL_NOSPEC on i386
            x86/apic: Handle missing global clockevent gracefully
            x86/boot: Save fields explicitly, zero out everything else
            x86/boot: Fix boot regression caused by bootparam sanitizing
            dm btree: fix order of block initialization in btree_split_beneath
            dm space map metadata: fix missing store of apply_bops() return value
            dm table: fix invalid memory accesses with too high sector number
            cgroup: Disable IRQs while holding css_set_lock
            GFS2: don't set rgrp gl_object until it's inserted into rgrp tree
            net: arc_emac: fix koops caused by sk_buff free
            vhost-net: set packet weight of tx polling to 2 * vq size
            vhost_net: use packet weight for rx handler, too
            vhost_net: introduce vhost_exceeds_weight()
            vhost: introduce vhost_exceeds_weight()
            vhost_net: fix possible infinite loop
            vhost: scsi: add weight support
            siphash: add cryptographically secure PRF
            siphash: implement HalfSipHash1-3 for hash tables
            inet: switch IP ID generator to siphash
            netfilter: ctnetlink: don't use conntrack/expect object addresses as id
            netfilter: conntrack: Use consistent ct id hash calculation
            Revert "perf test 6: Fix missing kvm module load for s390"
            x86/pm: Introduce quirk framework to save/restore extra MSR registers around suspend/resume
            x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h
            scsi: ufs: Fix NULL pointer dereference in ufshcd_config_vreg_hpm()
            dmaengine: ste_dma40: fix unneeded variable warning
            usb: gadget: composite: Clear "suspended" on reset/disconnect
            usb: host: fotg2: restart hcd after port reset
            tools: hv: fix KVP and VSS daemons exit code
            watchdog: bcm2835_wdt: Fix module autoload
            tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
            ALSA: usb-audio: Fix a stack buffer overflow bug in check_input_term
            ALSA: usb-audio: Fix an OOB bug in parse_audio_mixer_unit
            tcp: make sure EPOLLOUT wont be missed
            ALSA: seq: Fix potential concurrent access to the deleted pool
            KVM: x86: Don't update RIP or do single-step on faulting emulation
            x86/apic: Do not initialize LDR and DFR for bigsmp
            x86/apic: Include the LDR when clearing out APIC registers
            usb-storage: Add new JMS567 revision to unusual_devs
            USB: cdc-wdm: fix race between write and disconnect due to flag abuse
            usb: host: ohci: fix a race condition between shutdown and irq
            USB: storage: ums-realtek: Update module parameter description for auto_delink_en
            USB: storage: ums-realtek: Whitelist auto-delink support
            ptrace,x86: Make user_64bit_mode() available to 32-bit builds
            uprobes/x86: Fix detection of 32-bit user mode
            mmc: sdhci-of-at91: add quirk for broken HS200
            mmc: core: Fix init of SD cards reporting an invalid VDD range
            stm class: Fix a double free of stm_source_device
            VMCI: Release resource if the work is already queued
            Revert "cfg80211: fix processing world regdomain when non modular"
            mac80211: fix possible sta leak
            x86/ptrace: fix up botched merge of spectrev1 fix
            Linux 4.4.191

    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>

    Conflicts:
    	drivers/scsi/ufs/ufshcd.c
    	fs/userfaultfd.c
    	kernel/cgroup.c
    	sound/usb/mixer.c

commit efbc4a364bd5469a616668127439e7cfca4c1d7b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Sep 6 10:18:17 2019 +0200

    Linux 4.4.191

commit 61263fbe574b0b74c50552983bdcc2bb9a409b1e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Sep 4 12:27:18 2019 +0200

    x86/ptrace: fix up botched merge of spectrev1 fix

    I incorrectly merged commit 31a2fbb390fe ("x86/ptrace: Fix possible
    spectre-v1 in ptrace_get_debugreg()") when backporting it, as was
    graciously pointed out at
    https://grsecurity.net/teardown_of_a_failed_linux_lts_spectre_fix.php

    Resolve the upstream difference with the stable kernel merge to properly
    protect things.

    Reported-by: Brad Spengler <spender@grsecurity.net>
    Cc: Dianzhang Chen <dianzhangchen0@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: <bp@alien8.de>
    Cc: <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c0932cd8197d290195dc281ff6534e13d9d97e8
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Aug 1 09:30:33 2019 +0200

    mac80211: fix possible sta leak

    commit 5fd2f91ad483baffdbe798f8a08f1b41442d1e24 upstream.

    If TDLS station addition is rejected, the sta memory is leaked.
    Avoid this by moving the check before the allocation.

    Cc: stable@vger.kernel.org
    Fixes: 7ed5285396c2 ("mac80211: don't initiate TDLS connection if station is not associated to AP")
    Link: https://lore.kernel.org/r/20190801073033.7892-1-johannes@sipsolutions.net
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3161dea144dde71e8d8dd1cd8b736b6e431b7ee7
Author: Hodaszi, Robert <Robert.Hodaszi@digi.com>
Date:   Fri Jun 14 13:16:01 2019 +0000

    Revert "cfg80211: fix processing world regdomain when non modular"

    commit 0d31d4dbf38412f5b8b11b4511d07b840eebe8cb upstream.

    This reverts commit 96cce12ff6e0 ("cfg80211: fix processing world
    regdomain when non modular").

    Re-triggering a reg_process_hint with the last request on all events,
    can make the regulatory domain fail in case of multiple WiFi modules. On
    slower boards (espacially with mdev), enumeration of the WiFi modules
    can end up in an intersected regulatory domain, and user cannot set it
    with 'iw reg set' anymore.

    This is happening, because:
    - 1st module enumerates, queues up a regulatory request
    - request gets processed by __reg_process_hint_driver():
      - checks if previous was set by CORE -> yes
        - checks if regulator domain changed -> yes, from '00' to e.g. 'US'
          -> sends request to the 'crda'
    - 2nd module enumerates, queues up a regulator request (which triggers
      the reg_todo() work)
    - reg_todo() -> reg_process_pending_hints() sees, that the last request
      is not processed yet, so it tries to process it again.
      __reg_process_hint driver() will run again, and:
      - checks if the last request's initiator was the core -> no, it was
        the driver (1st WiFi module)
      - checks, if the previous initiator was the driver -> yes
        - checks if the regulator domain changed -> yes, it was '00' (set by
          core, and crda call did not return yet), and should be changed to 'US'

    ------> __reg_process_hint_driver calls an intersect

    Besides, the reg_process_hint call with the last request is meaningless
    since the crda call has a timeout work. If that timeout expires, the
    first module's request will lost.

    Cc: stable@vger.kernel.org
    Fixes: 96cce12ff6e0 ("cfg80211: fix processing world regdomain when non modular")
    Signed-off-by: Robert Hodaszi <robert.hodaszi@digi.com>
    Link: https://lore.kernel.org/r/20190614131600.GA13897@a1-hr
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16ab568881f8d2bc2e3b66dab55ab6ea72d9849b
Author: Nadav Amit <namit@vmware.com>
Date:   Tue Aug 20 13:26:38 2019 -0700

    VMCI: Release resource if the work is already queued

    commit ba03a9bbd17b149c373c0ea44017f35fc2cd0f28 upstream.

    Francois reported that VMware balloon gets stuck after a balloon reset,
    when the VMCI doorbell is removed. A similar error can occur when the
    balloon driver is removed with the following splat:

    [ 1088.622000] INFO: task modprobe:3565 blocked for more than 120 seconds.
    [ 1088.622035]       Tainted: G        W         5.2.0 #4
    [ 1088.622087] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 1088.622205] modprobe        D    0  3565   1450 0x00000000
    [ 1088.622210] Call Trace:
    [ 1088.622246]  __schedule+0x2a8/0x690
    [ 1088.622248]  schedule+0x2d/0x90
    [ 1088.622250]  schedule_timeout+0x1d3/0x2f0
    [ 1088.622252]  wait_for_completion+0xba/0x140
    [ 1088.622320]  ? wake_up_q+0x80/0x80
    [ 1088.622370]  vmci_resource_remove+0xb9/0xc0 [vmw_vmci]
    [ 1088.622373]  vmci_doorbell_destroy+0x9e/0xd0 [vmw_vmci]
    [ 1088.622379]  vmballoon_vmci_cleanup+0x6e/0xf0 [vmw_balloon]
    [ 1088.622381]  vmballoon_exit+0x18/0xcc8 [vmw_balloon]
    [ 1088.622394]  __x64_sys_delete_module+0x146/0x280
    [ 1088.622408]  do_syscall_64+0x5a/0x130
    [ 1088.622410]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [ 1088.622415] RIP: 0033:0x7f54f62791b7
    [ 1088.622421] Code: Bad RIP value.
    [ 1088.622421] RSP: 002b:00007fff2a949008 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
    [ 1088.622426] RAX: ffffffffffffffda RBX: 000055dff8b55d00 RCX: 00007f54f62791b7
    [ 1088.622426] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055dff8b55d68
    [ 1088.622427] RBP: 000055dff8b55d00 R08: 00007fff2a947fb1 R09: 0000000000000000
    [ 1088.622427] R10: 00007f54f62f5cc0 R11: 0000000000000206 R12: 000055dff8b55d68
    [ 1088.622428] R13: 0000000000000001 R14: 000055dff8b55d68 R15: 00007fff2a94a3f0

    The cause for the bug is that when the "delayed" doorbell is invoked, it
    takes a reference on the doorbell entry and schedules work that is
    supposed to run the appropriate code and drop the doorbell entry
    reference. The code ignores the fact that if the work is already queued,
    it will not be scheduled to run one more time. As a result one of the
    references would not be dropped. When the code waits for the reference
    to get to zero, during balloon reset or module removal, it gets stuck.

    Fix it. Drop the reference if schedule_work() indicates that the work is
    already queued.

    Note that this bug got more apparent (or apparent at all) due to
    commit ce664331b248 ("vmw_balloon: VMCI_DOORBELL_SET does not check status").

    Fixes: 83e2ec765be03 ("VMCI: doorbell implementation.")
    Reported-by: Francois Rigault <rigault.francois@gmail.com>
    Cc: Jorgen Hansen <jhansen@vmware.com>
    Cc: Adit Ranadive <aditr@vmware.com>
    Cc: Alexios Zavras <alexios.zavras@intel.com>
    Cc: Vishnu DASA <vdasa@vmware.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Nadav Amit <namit@vmware.com>
    Reviewed-by: Vishnu Dasa <vdasa@vmware.com>
    Link: https://lore.kernel.org/r/20190820202638.49003-1-namit@vmware.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c25b7d78f0e871b10a38a0da9dbc9c538217bef9
Author: Ding Xiang <dingxiang@cmss.chinamobile.com>
Date:   Wed Aug 21 10:49:52 2019 +0300

    stm class: Fix a double free of stm_source_device

    commit 961b6ffe0e2c403b09a8efe4a2e986b3c415391a upstream.

    In the error path of stm_source_register_device(), the kfree is
    unnecessary, as the put_device() before it ends up calling
    stm_source_device_release() to free stm_source_device, leading to
    a double free at the outer kfree() call. Remove it.

    Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com>
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Fixes: 7bd1d4093c2fa ("stm class: Introduce an abstraction for System Trace Module devices")
    Link: https://lore.kernel.org/linux-arm-kernel/1563354988-23826-1-git-send-email-dingxiang@cmss.chinamobile.com/
    Cc: stable@vger.kernel.org # v4.4+
    Link: https://lore.kernel.org/r/20190821074955.3925-2-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2f1509fca476d763d94eb0026b28c22ab110688
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Tue Aug 27 10:10:43 2019 +0200

    mmc: core: Fix init of SD cards reporting an invalid VDD range

    commit 72741084d903e65e121c27bd29494d941729d4a1 upstream.

    The OCR register defines the supported range of VDD voltages for SD cards.
    However, it has turned out that some SD cards reports an invalid voltage
    range, for example having bit7 set.

    When a host supports MMC_CAP2_FULL_PWR_CYCLE and some of the voltages from
    the invalid VDD range, this triggers the core to run a power cycle of the
    card to try to initialize it at the lowest common supported voltage.
    Obviously this fails, since the card can't support it.

    Let's fix this problem, by clearing invalid bits from the read OCR register
    for SD cards, before proceeding with the VDD voltage negotiation.

    Cc: stable@vger.kernel.org
    Reported-by: Philip Langdale <philipl@overt.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Reviewed-by: Philip Langdale <philipl@overt.org>
    Tested-by: Philip Langdale <philipl@overt.org>
    Tested-by: Manuel Presnitz <mail@mpy.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12a897daa78b640bcdfd6422bf2d697c442549e1
Author: Eugen Hristev <eugen.hristev@microchip.com>
Date:   Thu Aug 8 08:35:40 2019 +0000

    mmc: sdhci-of-at91: add quirk for broken HS200

    commit 7871aa60ae0086fe4626abdf5ed13eeddf306c61 upstream.

    HS200 is not implemented in the driver, but the controller claims it
    through caps. Remove it via a quirk, to make sure the mmc core do not try
    to enable HS200, as it causes the eMMC initialization to fail.

    Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Fixes: bb5f8ea4d514 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC")
    Cc: stable@vger.kernel.org # v4.4+
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d1a41682781c2a268160d15eb8adf63024c4e70
Author: Sebastian Mayr <me@sam.st>
Date:   Sun Jul 28 17:26:17 2019 +0200

    uprobes/x86: Fix detection of 32-bit user mode

    [ Upstream commit 9212ec7d8357ea630031e89d0d399c761421c83b ]

    32-bit processes running on a 64-bit kernel are not always detected
    correctly, causing the process to crash when uretprobes are installed.

    The reason for the crash is that in_ia32_syscall() is used to determine the
    process's mode, which only works correctly when called from a syscall.

    In the case of uretprobes, however, the function is called from a exception
    and always returns 'false' on a 64-bit kernel. In consequence this leads to
    corruption of the process's return address.

    Fix this by using user_64bit_mode() instead of in_ia32_syscall(), which
    is correct in any situation.

    [ tglx: Add a comment and the following historical info ]

    This should have been detected by the rename which happened in commit

      abfb9498ee13 ("x86/entry: Rename is_{ia32,x32}_task() to in_{ia32,x32}_syscall()")

    which states in the changelog:

        The is_ia32_task()/is_x32_task() function names are a big misnomer: they
        suggests that the compat-ness of a system call is a task property, which
        is not true, the compatness of a system call purely depends on how it
        was invoked through the system call layer.
        .....

    and then it went and blindly renamed every call site.

    Sadly enough this was already mentioned here:

       8faaed1b9f50 ("uprobes/x86: Introduce sizeof_long(), cleanup adjust_ret_addr() and
    arch_uretprobe_hijack_return_addr()")

    where the changelog says:

        TODO: is_ia32_task() is not what we actually want, TS_COMPAT does
        not necessarily mean 32bit. Fortunately syscall-like insns can't be
        probed so it actually works, but it would be better to rename and
        use is_ia32_frame().

    and goes all the way back to:

        0326f5a94dde ("uprobes/core: Handle breakpoint and singlestep exceptions")

    Oh well. 7+ years until someone actually tried a uretprobe on a 32bit
    process on a 64bit kernel....

    Fixes: 0326f5a94dde ("uprobes/core: Handle breakpoint and singlestep exceptions")
    Signed-off-by: Sebastian Mayr <me@sam.st>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190728152617.7308-1-me@sam.st
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6029fe64cefa148900b58596e5335ac70ffb570
Author: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Date:   Fri Oct 27 13:25:30 2017 -0700

    ptrace,x86: Make user_64bit_mode() available to 32-bit builds

    [ Upstream commit e27c310af5c05cf876d9cad006928076c27f54d4 ]

    In its current form, user_64bit_mode() can only be used when CONFIG_X86_64
    is selected. This implies that code built with CONFIG_X86_64=n cannot use
    it. If a piece of code needs to be built for both CONFIG_X86_64=y and
    CONFIG_X86_64=n and wants to use this function, it needs to wrap it in
    an #ifdef/#endif; potentially, in multiple places.

    This can be easily avoided with a single #ifdef/#endif pair within
    user_64bit_mode() itself.

    Suggested-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Cc: "Michael S. Tsirkin" <mst@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: ricardo.neri@intel.com
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: Huang Rui <ray.huang@amd.com>
    Cc: Qiaowei Ren <qiaowei.ren@intel.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
    Cc: Chris Metcalf <cmetcalf@mellanox.com>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Colin Ian King <colin.king@canonical.com>
    Cc: Chen Yucong <slaoub@gmail.com>
    Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Lorenzo Stoakes <lstoakes@gmail.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Thomas Garnier <thgarnie@google.com>
    Link: https://lkml.kernel.org/r/1509135945-13762-4-git-send-email-ricardo.neri-calderon@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4761474088761cd0705a80943dfafa0f723696d1
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Aug 28 01:34:50 2019 +0800

    USB: storage: ums-realtek: Whitelist auto-delink support

    commit 1902a01e2bcc3abd7c9a18dc05e78c7ab4a53c54 upstream.

    Auto-delink requires writing special registers to ums-realtek devices.
    Unconditionally enable auto-delink may break newer devices.

    So only enable auto-delink by default for the original three IDs,
    0x0138, 0x0158 and 0x0159.

    Realtek is working on a patch to properly support auto-delink for other
    IDs.

    BugLink: https://bugs.launchpad.net/bugs/1838886
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190827173450.13572-2-kai.heng.feng@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00087c6e434e8705d97ef8c0f796b573894e981b
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Aug 28 01:34:49 2019 +0800

    USB: storage: ums-realtek: Update module parameter description for auto_delink_en

    commit f6445b6b2f2bb1745080af4a0926049e8bca2617 upstream.

    The option named "auto_delink_en" is a bit misleading, as setting it to
    false doesn't really disable auto-delink but let auto-delink be firmware
    controlled.

    Update the description to reflect the real usage of this parameter.

    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190827173450.13572-1-kai.heng.feng@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb1ff5020b3e55f88be1f506042b003d9478cbfd
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Tue Aug 27 12:51:50 2019 +0900

    usb: host: ohci: fix a race condition between shutdown and irq

    commit a349b95d7ca0cea71be4a7dac29830703de7eb62 upstream.

    This patch fixes an issue that the following error is
    possible to happen when ohci hardware causes an interruption
    and the system is shutting down at the same time.

    [   34.851754] usb 2-1: USB disconnect, device number 2
    [   35.166658] irq 156: nobody cared (try booting with the "irqpoll" option)
    [   35.173445] CPU: 0 PID: 22 Comm: kworker/0:1 Not tainted 5.3.0-rc5 #85
    [   35.179964] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)
    [   35.187886] Workqueue: usb_hub_wq hub_event
    [   35.192063] Call trace:
    [   35.194509]  dump_backtrace+0x0/0x150
    [   35.198165]  show_stack+0x14/0x20
    [   35.201475]  dump_stack+0xa0/0xc4
    [   35.204785]  __report_bad_irq+0x34/0xe8
    [   35.208614]  note_interrupt+0x2cc/0x318
    [   35.212446]  handle_irq_event_percpu+0x5c/0x88
    [   35.216883]  handle_irq_event+0x48/0x78
    [   35.220712]  handle_fasteoi_irq+0xb4/0x188
    [   35.224802]  generic_handle_irq+0x24/0x38
    [   35.228804]  __handle_domain_irq+0x5c/0xb0
    [   35.232893]  gic_handle_irq+0x58/0xa8
    [   35.236548]  el1_irq+0xb8/0x180
    [   35.239681]  __do_softirq+0x94/0x23c
    [   35.243253]  irq_exit+0xd0/0xd8
    [   35.246387]  __handle_domain_irq+0x60/0xb0
    [   35.250475]  gic_handle_irq+0x58/0xa8
    [   35.254130]  el1_irq+0xb8/0x180
    [   35.257268]  kernfs_find_ns+0x5c/0x120
    [   35.261010]  kernfs_find_and_get_ns+0x3c/0x60
    [   35.265361]  sysfs_unmerge_group+0x20/0x68
    [   35.269454]  dpm_sysfs_remove+0x2c/0x68
    [   35.273284]  device_del+0x80/0x370
    [   35.276683]  hid_destroy_device+0x28/0x60
    [   35.280686]  usbhid_disconnect+0x4c/0x80
    [   35.284602]  usb_unbind_interface+0x6c/0x268
    [   35.288867]  device_release_driver_internal+0xe4/0x1b0
    [   35.293998]  device_release_driver+0x14/0x20
    [   35.298261]  bus_remove_device+0x110/0x128
    [   35.302350]  device_del+0x148/0x370
    [   35.305832]  usb_disable_device+0x8c/0x1d0
    [   35.309921]  usb_disconnect+0xc8/0x2d0
    [   35.313663]  hub_event+0x6e0/0x1128
    [   35.317146]  process_one_work+0x1e0/0x320
    [   35.321148]  worker_thread+0x40/0x450
    [   35.324805]  kthread+0x124/0x128
    [   35.328027]  ret_from_fork+0x10/0x18
    [   35.331594] handlers:
    [   35.333862] [<0000000079300c1d>] usb_hcd_irq
    [   35.338126] [<0000000079300c1d>] usb_hcd_irq
    [   35.342389] Disabling IRQ #156

    ohci_shutdown() disables all the interrupt and rh_state is set to
    OHCI_RH_HALTED. In other hand, ohci_irq() is possible to enable
    OHCI_INTR_SF and OHCI_INTR_MIE on ohci_irq(). Note that OHCI_INTR_SF
    is possible to be set by start_ed_unlink() which is called:
     ohci_irq()
      -> process_done_list()
       -> takeback_td()
        -> start_ed_unlink()

    So, ohci_irq() has the following condition, the issue happens by
    &ohci->regs->intrenable = OHCI_INTR_MIE | OHCI_INTR_SF and
    ohci->rh_state = OHCI_RH_HALTED:

    	/* interrupt for some other device? */
    	if (ints == 0 || unlikely(ohci->rh_state == OHCI_RH_HALTED))
    		return IRQ_NOTMINE;

    To fix the issue, ohci_shutdown() holds the spin lock while disabling
    the interruption and changing the rh_state flag to prevent reenable
    the OHCI_INTR_MIE unexpectedly. Note that io_watchdog_func() also
    calls the ohci_shutdown() and it already held the spin lock, so that
    the patch makes a new function as _ohci_shutdown().

    This patch is inspired by a Renesas R-Car Gen3 BSP patch
    from Tho Vu.

    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/1566877910-6020-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d743d816acea90068b76cf2294f2e3b88bdaa41
Author: Oliver Neukum <oneukum@suse.com>
Date:   Tue Aug 27 12:34:36 2019 +0200

    USB: cdc-wdm: fix race between write and disconnect due to flag abuse

    commit 1426bd2c9f7e3126e2678e7469dca9fd9fc6dd3e upstream.

    In case of a disconnect an ongoing flush() has to be made fail.
    Nevertheless we cannot be sure that any pending URB has already
    finished, so although they will never succeed, they still must
    not be touched.
    The clean solution for this is to check for WDM_IN_USE
    and WDM_DISCONNECTED in flush(). There is no point in ever
    clearing WDM_IN_USE, as no further writes make sense.

    The issue is as old as the driver.

    Fixes: afba937e540c9 ("USB: CDC WDM driver")
    Reported-by: syzbot+d232cca6ec42c2edb3fc@syzkaller.appspotmail.com
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190827103436.21143-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f575b509cce81910666bdb0f4958cd01ab6d265
Author: Henk van der Laan <opensource@henkvdlaan.com>
Date:   Fri Aug 16 22:08:47 2019 +0200

    usb-storage: Add new JMS567 revision to unusual_devs

    commit 08d676d1685c2a29e4d0e1b0242324e564d4589e upstream.

    Revision 0x0117 suffers from an identical issue to earlier revisions,
    therefore it should be added to the quirks list.

    Signed-off-by: Henk van der Laan <opensource@henkvdlaan.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190816200847.21366-1-opensource@henkvdlaan.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bd0d83e2d5a5cc6e40e2d24020bfedb63b81995
Author: Bandan Das <bsd@redhat.com>
Date:   Mon Aug 26 06:15:13 2019 -0400

    x86/apic: Include the LDR when clearing out APIC registers

    commit 558682b5291937a70748d36fd9ba757fb25b99ae upstream.

    Although APIC initialization will typically clear out the LDR before
    setting it, the APIC cleanup code should reset the LDR.

    This was discovered with a 32-bit KVM guest jumping into a kdump
    kernel. The stale bits in the LDR triggered a bug in the KVM APIC
    implementation which caused the destination mapping for VCPUs to be
    corrupted.

    Note that this isn't intended to paper over the KVM APIC bug. The kernel
    has to clear the LDR when resetting the APIC registers except when X2APIC
    is enabled.

    This lacks a Fixes tag because missing to clear LDR goes way back into pre
    git history.

    [ tglx: Made x2apic_enabled a function call as required ]

    Signed-off-by: Bandan Das <bsd@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190826101513.5080-3-bsd@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26285030611e4b410c1e30afc2c9d1601fa7a128
Author: Bandan Das <bsd@redhat.com>
Date:   Mon Aug 26 06:15:12 2019 -0400

    x86/apic: Do not initialize LDR and DFR for bigsmp

    commit bae3a8d3308ee69a7dbdf145911b18dfda8ade0d upstream.

    Legacy apic init uses bigsmp for smp systems with 8 and more CPUs. The
    bigsmp APIC implementation uses physical destination mode, but it
    nevertheless initializes LDR and DFR. The LDR even ends up incorrectly with
    multiple bit being set.

    This does not cause a functional problem because LDR and DFR are ignored
    when physical destination mode is active, but it triggered a problem on a
    32-bit KVM guest which jumps into a kdump kernel.

    The multiple bits set unearthed a bug in the KVM APIC implementation. The
    code which creates the logical destination map for VCPUs ignores the
    disabled state of the APIC and ends up overwriting an existing valid entry
    and as a result, APIC calibration hangs in the guest during kdump
    initialization.

    Remove the bogus LDR/DFR initialization.

    This is not intended to work around the KVM APIC bug. The LDR/DFR
    ininitalization is wrong on its own.

    The issue goes back into the pre git history. The fixes tag is the commit
    in the bitkeeper import which introduced bigsmp support in 2003.

      git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git

    Fixes: db7b9e9f26b8 ("[PATCH] Clustered APIC setup for >8 CPU systems")
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Bandan Das <bsd@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190826101513.5080-2-bsd@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fff074fc4aecfb437bfa8bb690b7847a7d7a4d2
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Fri Aug 23 13:55:44 2019 -0700

    KVM: x86: Don't update RIP or do single-step on faulting emulation

    commit 75ee23b30dc712d80d2421a9a547e7ab6e379b44 upstream.

    Don't advance RIP or inject a single-step #DB if emulation signals a
    fault.  This logic applies to all state updates that are conditional on
    clean retirement of the emulation instruction, e.g. updating RFLAGS was
    previously handled by commit 38827dbd3fb85 ("KVM: x86: Do not update
    EFLAGS on faulting emulation").

    Not advancing RIP is likely a nop, i.e. ctxt->eip isn't updated with
    ctxt->_eip until emulation "retires" anyways.  Skipping #DB injection
    fixes a bug reported by Andy Lutomirski where a #UD on SYSCALL due to
    invalid state with EFLAGS.TF=1 would loop indefinitely due to emulation
    overwriting the #UD with #DB and thus restarting the bad SYSCALL over
    and over.

    Cc: Nadav Amit <nadav.amit@gmail.com>
    Cc: stable@vger.kernel.org
    Reported-by: Andy Lutomirski <luto@kernel.org>
    Fixes: 663f4c61b803 ("KVM: x86: handle singlestep during emulation")
    Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3abf92c855c9439f57880b89f1ae8267a99ab45
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sun Aug 25 09:21:44 2019 +0200

    ALSA: seq: Fix potential concurrent access to the deleted pool

    commit 75545304eba6a3d282f923b96a466dc25a81e359 upstream.

    The input pool of a client might be deleted via the resize ioctl, the
    the access to it should be covered by the proper locks.  Currently the
    only missing place is the call in snd_seq_ioctl_get_client_pool(), and
    this patch papers over it.

    Reported-by: syzbot+4a75454b9ca2777f35c7@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec1933594cbb1039f0341847d457c320a2b663a4
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Aug 16 21:26:22 2019 -0700

    tcp: make sure EPOLLOUT wont be missed

    [ Upstream commit ef8d8ccdc216f797e66cb4a1372f5c4c285ce1e4 ]

    As Jason Baron explained in commit 790ba4566c1a ("tcp: set SOCK_NOSPACE
    under memory pressure"), it is crucial we properly set SOCK_NOSPACE
    when needed.

    However, Jason patch had a bug, because the 'nonblocking' status
    as far as sk_stream_wait_memory() is concerned is governed
    by MSG_DONTWAIT flag passed at sendmsg() time :

        long timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT);

    So it is very possible that tcp sendmsg() calls sk_stream_wait_memory(),
    and that sk_stream_wait_memory() returns -EAGAIN with SOCK_NOSPACE
    cleared, if sk->sk_sndtimeo has been set to a small (but not zero)
    value.

    This patch removes the 'noblock' variable since we must always
    set SOCK_NOSPACE if -EAGAIN is returned.

    It also renames the do_nonblock label since we might reach this
    code path even if we were in blocking mode.

    Fixes: 790ba4566c1a ("tcp: set SOCK_NOSPACE under memory pressure")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jason Baron <jbaron@akamai.com>
    Reported-by: Vladimir Rutsky  <rutsky@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Acked-by: Jason Baron <jbaron@akamai.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a485888b5189845f0b6c58ae89661a402a80402a
Author: Hui Peng <benquike@gmail.com>
Date:   Tue Aug 13 22:34:04 2019 -0400

    ALSA: usb-audio: Fix an OOB bug in parse_audio_mixer_unit

    commit daac07156b330b18eb5071aec4b3ddca1c377f2c upstream.

    The `uac_mixer_unit_descriptor` shown as below is read from the
    device side. In `parse_audio_mixer_unit`, `baSourceID` field is
    accessed from index 0 to `bNrInPins` - 1, the current implementation
    assumes that descriptor is always valid (the length  of descriptor
    is no shorter than 5 + `bNrInPins`). If a descriptor read from
    the device side is invalid, it may trigger out-of-bound memory
    access.

    ```
    struct uac_mixer_unit_descriptor {
    	__u8 bLength;
    	__u8 bDescriptorType;
    	__u8 bDescriptorSubtype;
    	__u8 bUnitID;
    	__u8 bNrInPins;
    	__u8 baSourceID[];
    }
    ```

    This patch fixes the bug by add a sanity check on the length of
    the descriptor.

    Reported-by: Hui Peng <benquike@gmail.com>
    Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Hui Peng <benquike@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 735a16d1afc01320392669f4ea64c84d435faf1c
Author: Hui Peng <benquike@gmail.com>
Date:   Thu Aug 15 00:31:34 2019 -0400

    ALSA: usb-audio: Fix a stack buffer overflow bug in check_input_term

    commit 19bce474c45be69a284ecee660aa12d8f1e88f18 upstream.

    `check_input_term` recursively calls itself with input from
    device side (e.g., uac_input_terminal_descriptor.bCSourceID)
    as argument (id). In `check_input_term`, if `check_input_term`
    is called with the same `id` argument as the caller, it triggers
    endless recursive call, resulting kernel space stack overflow.

    This patch fixes the bug by adding a bitmap to `struct mixer_build`
    to keep track of the checked ids and stop the execution if some id
    has been checked (similar to how parse_audio_unit handles unitid
    argument).

    Reported-by: Hui Peng <benquike@gm…
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/linux-mvista-2.4 that referenced this issue Sep 12, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
Source: Kernel.org
MR: 99885
Type: Integration
Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-414.y
ChangeID: 7a28a90d94802c6f3f460dc3aa408b93d96adecf
Description:

[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Armin Kuster <akuster@mvista.com>
crimsonthunder pushed a commit to crimsonthunder/Crystal_Kernel_OP6T that referenced this issue Sep 12, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mdeejay added a commit to BeastRoms-Devices/kernel_xiaomi_laurel_sprout that referenced this issue Sep 12, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Blacksuan19 added a commit to Blacksuan19/android_kernel_dark_ages that referenced this issue Sep 12, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
catuva21 added a commit to catuva21/kernel_RN7 that referenced this issue Sep 13, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928db560 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firebird11 added a commit to crdroidandroid/android_kernel_oneplus_sdm845 that referenced this issue Sep 13, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
catuva21 added a commit to catuva21/kernel_RN7 that referenced this issue Sep 14, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928db560 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
catuva21 added a commit to catuva21/kernel_RN7 that referenced this issue Sep 14, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928db560 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
zxc070 added a commit to zxc070/kernel_xiaomi_lavender that referenced this issue Sep 17, 2019
Merge 4.4.193 into eas-pie
commit 5f6d28ee883a77a88db64ceeffbdbc349d9a4e78
Merge: 8a227a3afe03 e19c5132f78a
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Mon Sep 16 11:17:49 2019 -0700

    Merge 4.4.193 into kernel.lnx.4.4.r34-rel

    Changes in 4.4.193: (10 commits)
            ALSA: hda - Fix potential endless loop at applying quirks
            ALSA: hda/realtek - Fix overridden device-specific initialization
            xfrm: clean up xfrm protocol checks
            vhost/test: fix build for vhost test
            scripts/decode_stacktrace: match basepath using shell prefix operator, not regex
            clk: s2mps11: Add used attribute to s2mps11_dt_match
            x86, boot: Remove multiple copy of static function sanitize_boot_params()
            af_packet: tone down the Tx-ring unsupported spew.
            vhost: make sure log_num < in_num
            Linux 4.4.193

    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>

commit e19c5132f78a70cc53745558c0e728fecc74030a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Sep 16 08:13:37 2019 +0200

    Linux 4.4.193

commit 35b29a78cc9b2523f6b0c080e6b44d2eeb367023
Author: yongduan <yongduan@tencent.com>
Date:   Wed Sep 11 17:44:24 2019 +0800

    vhost: make sure log_num < in_num

    commit 060423bfdee3f8bc6e2c1bac97de24d5415e2bc4 upstream.

    The code assumes log_num < in_num everywhere, and that is true as long as
    in_num is incremented by descriptor iov count, and log_num by 1. However
    this breaks if there's a zero sized descriptor.

    As a result, if a malicious guest creates a vring desc with desc.len = 0,
    it may cause the host kernel to crash by overflowing the log array. This
    bug can be triggered during the VM migration.

    There's no need to log when desc.len = 0, so just don't increment log_num
    in this case.

    Fixes: 3a4d5c94e959 ("vhost_net: a kernel-level virtio server")
    Cc: stable@vger.kernel.org
    Reviewed-by: Lidong Chen <lidongchen@tencent.com>
    Signed-off-by: ruippan <ruippan@tencent.com>
    Signed-off-by: yongduan <yongduan@tencent.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8cc953562e2e293575514c40806eee438a967364
Author: Dave Jones <davej@codemonkey.org.uk>
Date:   Mon Apr 4 15:11:50 2016 -0400

    af_packet: tone down the Tx-ring unsupported spew.

    [ Upstream commit 6ae81ced378820c4c6434b1dedba14a7122df310 ]

    Trinity and other fuzzers can hit this WARN on far too easily,
    resulting in a tainted kernel that hinders automated fuzzing.

    Replace it with a rate-limited printk.

    Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 52b0d2ee55cafcaa7cd4b12cb65fc7432b30dcf6
Author: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Date:   Tue Jul 16 21:18:12 2019 +0800

    x86, boot: Remove multiple copy of static function sanitize_boot_params()

    commit 8c5477e8046ca139bac250386c08453da37ec1ae upstream.

    Kernel build warns:
     'sanitize_boot_params' defined but not used [-Wunused-function]

    at below files:
      arch/x86/boot/compressed/cmdline.c
      arch/x86/boot/compressed/error.c
      arch/x86/boot/compressed/early_serial_console.c
      arch/x86/boot/compressed/acpi.c

    That's becausethey each include misc.h which includes a definition of
    sanitize_boot_params() via bootparam_utils.h.

    Remove the inclusion from misc.h and have the c file including
    bootparam_utils.h directly.

    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lkml.kernel.org/r/1563283092-1189-1-git-send-email-zhenzhong.duan@oracle.com
    [nc: Fixed conflict around lack of 67b6662559f7f]
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f935c9418992a865856418619ddd74114218ed01
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Thu Oct 18 12:13:40 2018 -0700

    clk: s2mps11: Add used attribute to s2mps11_dt_match

    [ Upstream commit 9c940bbe2bb47e03ca5e937d30b6a50bf9c0e671 ]

    Clang warns after commit 8985167ecf57 ("clk: s2mps11: Fix matching when
    built as module and DT node contains compatible"):

    drivers/clk/clk-s2mps11.c:242:34: warning: variable 's2mps11_dt_match'
    is not needed and will not be emitted [-Wunneeded-internal-declaration]
    static const struct of_device_id s2mps11_dt_match[] = {
                                     ^
    1 warning generated.

    This warning happens when a variable is used in some construct that
    doesn't require a reference to that variable to be emitted in the symbol
    table; in this case, it's MODULE_DEVICE_TABLE, which only needs to hold
    the data of the variable, not the variable itself.

    $ nm -S drivers/clk/clk-s2mps11.o | rg s2mps11_dt_match
    00000078 000003d4 R __mod_of__s2mps11_dt_match_device_table

    Normally, with device ID table variables, it means that the variable
    just needs to be tied to the device declaration at the bottom of the
    file, like s2mps11_clk_id:

    $ nm -S drivers/clk/clk-s2mps11.o | rg s2mps11_clk_id
    00000000 00000078 R __mod_platform__s2mps11_clk_id_device_table
    00000000 00000078 r s2mps11_clk_id

    However, because the comment above this deliberately doesn't want this
    variable added to .of_match_table, we need to mark s2mps11_dt_match as
    __used to silence this warning. This makes it clear to Clang that the
    variable is used for something, even if a reference to it isn't being
    emitted.

    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Fixes: 8985167ecf57 ("clk: s2mps11: Fix matching when built as module and DT node contains compatible")
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7ab6e38aec38e1077679b35d93b28d70b756c853
Author: Nicolas Boichat <drinkcat@chromium.org>
Date:   Thu Jul 11 20:52:27 2019 -0700

    scripts/decode_stacktrace: match basepath using shell prefix operator, not regex

    [ Upstream commit 31013836a71e07751a6827f9d2ad41ef502ddaff ]

    The basepath may contain special characters, which would confuse the regex
    matcher.  ${var#prefix} does the right thing.

    Link: http://lkml.kernel.org/r/20190518055946.181563-1-drinkcat@chromium.org
    Fixes: 67a28de47faa8358 ("scripts/decode_stacktrace: only strip base path when a prefix of the path")
    Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 17b919f0e667ea326549e499a3f54433478447c3
Author: Tiwei Bie <tiwei.bie@intel.com>
Date:   Wed Aug 28 13:37:00 2019 +0800

    vhost/test: fix build for vhost test

    commit 264b563b8675771834419057cbe076c1a41fb666 upstream.

    Since vhost_exceeds_weight() was introduced, callers need to specify
    the packet weight and byte weight in vhost_dev_init(). Note that, the
    packet weight isn't counted in this patch to keep the original behavior
    unchanged.

    Fixes: e82b9b0727ff ("vhost: introduce vhost_exceeds_weight()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1b22f7a0b273e2b6ff50afe950f6161ca8e3e58
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Fri Mar 22 16:26:19 2019 -0700

    xfrm: clean up xfrm protocol checks

    commit dbb2483b2a46fbaf833cfb5deb5ed9cace9c7399 upstream.

    In commit 6a53b7593233 ("xfrm: check id proto in validate_tmpl()")
    I introduced a check for xfrm protocol, but according to Herbert
    IPSEC_PROTO_ANY should only be used as a wildcard for lookup, so
    it should be removed from validate_tmpl().

    And, IPSEC_PROTO_ANY is expected to only match 3 IPSec-specific
    protocols, this is why xfrm_state_flush() could still miss
    IPPROTO_ROUTING, which leads that those entries are left in
    net->xfrm.state_all before exit net. Fix this by replacing
    IPSEC_PROTO_ANY with zero.

    This patch also extracts the check from validate_tmpl() to
    xfrm_id_proto_valid() and uses it in parse_ipsecrequest().
    With this, no other protocols should be added into xfrm.

    Fixes: 6a53b7593233 ("xfrm: check id proto in validate_tmpl()")
    Reported-by: syzbot+0bf0519d6e0de15914fe@syzkaller.appspotmail.com
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Zubin Mithra <zsm@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 949f4ca254ddb4b080c228ca35c8967ff1dd07e0
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Aug 30 12:03:38 2019 +0200

    ALSA: hda/realtek - Fix overridden device-specific initialization

    commit 89781d0806c2c4f29072d3f00cb2dd4274aabc3d upstream.

    The recent change to shuffle the codec initialization procedure for
    Realtek via commit 607ca3bd220f ("ALSA: hda/realtek - EAPD turn on
    later") caused the silent output on some machines.  This change was
    supposed to be safe, but it isn't actually; some devices have quirk
    setups to override the EAPD via COEF or BTL in the additional verb
    table, which is applied at the beginning of snd_hda_gen_init().  And
    this EAPD setup is again overridden in alc_auto_init_amp().

    For recovering from the regression, tell snd_hda_gen_init() not to
    apply the verbs there by a new flag, then apply the verbs in
    alc_init().

    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204727
    Fixes: 607ca3bd220f ("ALSA: hda/realtek - EAPD turn on later")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 272e1835861ee3d05035ea3cbfc1f225347ed18f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Aug 29 09:52:02 2019 +0200

    ALSA: hda - Fix potential endless loop at applying quirks

    commit 333f31436d3db19f4286f8862a00ea1d8d8420a1 upstream.

    Since the chained quirks via chained_before flag is applied before the
    depth check, it may lead to the endless recursive calls, when the
    chain were set up incorrectly.  Fix it by moving the depth check at
    the beginning of the loop.

    Fixes: 1f57825077dc ("ALSA: hda - Add chained_before flag to the fixup entry")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a227a3afe03f5b864b43233fe258c57719d25a3
Merge: 1b3d0a42f2aa 882f8791e141
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Tue Sep 10 15:31:55 2019 -0700

    Merge 4.4.192 into kernel.lnx.4.4.r34-rel

    Changes in 4.4.192: (24 commits)
            net: tundra: tsi108: use spin_lock_irqsave instead of spin_lock_irq in IRQ context
            net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
            Bluetooth: btqca: Add a short delay before downloading the NVM
            ibmveth: Convert multicast list size for little-endian system
            gpio: Fix build error of function redefinition
            cxgb4: fix a memory leak bug
            net: myri10ge: fix memory leaks
            cx82310_eth: fix a memory leak bug
            net: kalmia: fix memory leaks
            wimax/i2400m: fix a memory leak bug
            ravb: Fix use-after-free ravb_tstamp_skb
            Tools: hv: kvp: eliminate 'may be used uninitialized' warning
            IB/mlx4: Fix memory leaks
            ceph: fix buffer free while holding i_ceph_lock in __ceph_setxattr()
            KVM: arm/arm64: Only skip MMIO insn once
            libceph: allow ceph_buffer_put() to receive a NULL ceph_buffer
            spi: bcm2835aux: ensure interrupts are enabled for shared handler
            spi: bcm2835aux: unifying code between polling and interrupt driven code
            spi: bcm2835aux: remove dangerous uncontrolled read of fifo
            spi: bcm2835aux: fix corruptions for longer spi transfers
            Revert "x86/apic: Include the LDR when clearing out APIC registers"
            net: fix skb use after free in netpoll
            net: stmmac: dwmac-rk: Don't fail if phy regulator is absent
            Linux 4.4.192

    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>

commit 882f8791e1412d81e5cc7a4c379c73195155b40f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Sep 10 10:29:50 2019 +0100

    Linux 4.4.192

commit 89e0660bc5316acef9a4dc7bf8ec1ffed8a57c8c
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Thu Aug 29 11:17:24 2019 +0800

    net: stmmac: dwmac-rk: Don't fail if phy regulator is absent

    [ Upstream commit 3b25528e1e355c803e73aa326ce657b5606cda73 ]

    The devicetree binding lists the phy phy as optional. As such, the
    driver should not bail out if it can't find a regulator. Instead it
    should just skip the remaining regulator related code and continue
    on normally.

    Skip the remainder of phy_power_on() if a regulator supply isn't
    available. This also gets rid of the bogus return code.

    Fixes: 2e12f536635f ("net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator")
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6198d2b4ff0195ebc228a231f96918855ce722f
Author: Feng Sun <loyou85@gmail.com>
Date:   Mon Aug 26 14:46:04 2019 +0800

    net: fix skb use after free in netpoll

    [ Upstream commit 2c1644cf6d46a8267d79ed95cb9b563839346562 ]

    After commit baeababb5b85d5c4e6c917efe2a1504179438d3b
    ("tun: return NET_XMIT_DROP for dropped packets"),
    when tun_net_xmit drop packets, it will free skb and return NET_XMIT_DROP,
    netpoll_send_skb_on_dev will run into following use after free cases:
    1. retry netpoll_start_xmit with freed skb;
    2. queue freed skb in npinfo->txq.
    queue_process will also run into use after free case.

    hit netpoll_send_skb_on_dev first case with following kernel log:

    [  117.864773] kernel BUG at mm/slub.c:306!
    [  117.864773] invalid opcode: 0000 [#1] SMP PTI
    [  117.864774] CPU: 3 PID: 2627 Comm: loop_printmsg Kdump: loaded Tainted: P           OE     5.3.0-050300rc5-generic #201908182231
    [  117.864775] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [  117.864775] RIP: 0010:kmem_cache_free+0x28d/0x2b0
    [  117.864781] Call Trace:
    [  117.864781]  ? tun_net_xmit+0x21c/0x460
    [  117.864781]  kfree_skbmem+0x4e/0x60
    [  117.864782]  kfree_skb+0x3a/0xa0
    [  117.864782]  tun_net_xmit+0x21c/0x460
    [  117.864782]  netpoll_start_xmit+0x11d/0x1b0
    [  117.864788]  netpoll_send_skb_on_dev+0x1b8/0x200
    [  117.864789]  __br_forward+0x1b9/0x1e0 [bridge]
    [  117.864789]  ? skb_clone+0x53/0xd0
    [  117.864790]  ? __skb_clone+0x2e/0x120
    [  117.864790]  deliver_clone+0x37/0x50 [bridge]
    [  117.864790]  maybe_deliver+0x89/0xc0 [bridge]
    [  117.864791]  br_flood+0x6c/0x130 [bridge]
    [  117.864791]  br_dev_xmit+0x315/0x3c0 [bridge]
    [  117.864792]  netpoll_start_xmit+0x11d/0x1b0
    [  117.864792]  netpoll_send_skb_on_dev+0x1b8/0x200
    [  117.864792]  netpoll_send_udp+0x2c6/0x3e8
    [  117.864793]  write_msg+0xd9/0xf0 [netconsole]
    [  117.864793]  console_unlock+0x386/0x4e0
    [  117.864793]  vprintk_emit+0x17e/0x280
    [  117.864794]  vprintk_default+0x29/0x50
    [  117.864794]  vprintk_func+0x4c/0xbc
    [  117.864794]  printk+0x58/0x6f
    [  117.864795]  loop_fun+0x24/0x41 [printmsg_loop]
    [  117.864795]  kthread+0x104/0x140
    [  117.864795]  ? 0xffffffffc05b1000
    [  117.864796]  ? kthread_park+0x80/0x80
    [  117.864796]  ret_from_fork+0x35/0x40

    Signed-off-by: Feng Sun <loyou85@gmail.com>
    Signed-off-by: Xiaojun Zhao <xiaojunzhao141@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94eb5357f6d688b364eaf52d4f7fa187102396a7
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Sep 7 14:25:54 2019 -0700

    Revert "x86/apic: Include the LDR when clearing out APIC registers"

    [ Upstream commit 950b07c14e8c59444e2359f15fd70ed5112e11a0 ]

    This reverts commit 558682b5291937a70748d36fd9ba757fb25b99ae.

    Chris Wilson reports that it breaks his CPU hotplug test scripts.  In
    particular, it breaks offlining and then re-onlining the boot CPU, which
    we treat specially (and the BIOS does too).

    The symptoms are that we can offline the CPU, but it then does not come
    back online again:

        smpboot: CPU 0 is now offline
        smpboot: Booting Node 0 Processor 0 APIC 0x0
        smpboot: do_boot_cpu failed(-1) to wakeup CPU#0

    Thomas says he knows why it's broken (my personal suspicion: our magic
    handling of the "cpu0_logical_apicid" thing), but for 5.3 the right fix
    is to just revert it, since we've never touched the LDR bits before, and
    it's not worth the risk to do anything else at this stage.

    [ Hotpluging of the boot CPU is special anyway, and should be off by
      default. See the "BOOTPARAM_HOTPLUG_CPU0" config option and the
      cpu0_hotplug kernel parameter.

      In general you should not do it, and it has various known limitations
      (hibernate and suspend require the boot CPU, for example).

      But it should work, even if the boot CPU is special and needs careful
      treatment       - Linus ]

    Link: https://lore.kernel.org/lkml/156785100521.13300.14461504732265570003@skylake-alporthouse-com/
    Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Bandan Das <bsd@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e187a57fc653cfc3016875b80f53f78af4eac172
Author: Martin Sperl <kernel@martin.sperl.org>
Date:   Sat Mar 30 09:31:00 2019 +0000

    spi: bcm2835aux: fix corruptions for longer spi transfers

    [ Upstream commit 73b114ee7db1750c0b535199fae383b109bd61d0 ]

    On long running tests with a mcp2517fd can controller it showed that
    on rare occations the data read shows corruptions for longer spi transfers.

    Example of a 22 byte transfer:

    expected (as captured on logic analyzer):
    FF FF 78 00 00 00 08 06 00 00 91 20 77 56 84 85 86 87 88 89 8a 8b

    read by the driver:
    FF FF 78 00 00 00 08 06 00 00 91 20 77 56 84 88 89 8a 00 00 8b 9b

    To fix this use BCM2835_AUX_SPI_STAT_RX_LVL to determine when we may
    read data from the fifo reliably without any corruption.

    Surprisingly the only values ever empirically read in
    BCM2835_AUX_SPI_STAT_RX_LVL are 0x00, 0x10, 0x20 and 0x30.
    So whenever the mask is not 0 we can read from the fifo in a safe manner.

    The patch has now been tested intensively and we are no longer
    able to reproduce the "RX" issue any longer.

    Fixes: 1ea29b39f4c812ec ("spi: bcm2835aux: add bcm2835 auxiliary spi device...")
    Reported-by: Hubert Denkmair <h.denkmair@intence.de>
    Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
    Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2f16660fc8687febdc133f9b5082482f2a280fc
Author: Martin Sperl <kernel@martin.sperl.org>
Date:   Sat Mar 30 09:30:59 2019 +0000

    spi: bcm2835aux: remove dangerous uncontrolled read of fifo

    [ Upstream commit c7de8500fd8ecbb544846dd5f11dca578c3777e1 ]

    This read of the fifo is a potential candidate for a race condition
    as the spi transfer is not necessarily finished and so can lead to
    an early read of the fifo that still misses data.

    So it has been removed.

    Fixes: 1ea29b39f4c812ec ("spi: bcm2835aux: add bcm2835 auxiliary spi device...")
    Suggested-by: Hubert Denkmair <h.denkmair@intence.de>
    Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
    Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5473cd1dbf972ff06d89400d42973eb31c72dec1
Author: Martin Sperl <kernel@martin.sperl.org>
Date:   Sat Mar 30 09:30:58 2019 +0000

    spi: bcm2835aux: unifying code between polling and interrupt driven code

    [ Upstream commit 7188a6f0eee3f1fae5d826cfc6d569657ff950ec ]

    Sharing more code between polling and interrupt-driven mode.

    Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
    Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c99ad4f20c5b4d550745e1beaeaa24ed2cf873ba
Author: Rob Herring <robh@kernel.org>
Date:   Thu May 3 13:09:44 2018 -0500

    spi: bcm2835aux: ensure interrupts are enabled for shared handler

    [ Upstream commit bc519d9574618e47a0c788000fb78da95e18d953 ]

    The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
    Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
    DT change which breaks compatibility with older kernels. The AUX irqchip
    was already rejected for upstream[1] and the DT change would break
    working systems if the DTB is updated to a newer one. The latter issue
    was brought to my attention by Alex Graf.

    The root cause however is a bug in the shared handler. Shared handlers
    must check that interrupts are actually enabled before servicing the
    interrupt. Add a check that the TXEMPTY or IDLE interrupts are enabled.

    [1] https://patchwork.kernel.org/patch/9781221/

    Cc: Alexander Graf <agraf@suse.de>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Eric Anholt <eric@anholt.net>
    Cc: Stefan Wahren <stefan.wahren@i2se.com>
    Cc: Florian Fainelli <f.fainelli@gmail.com>
    Cc: Ray Jui <rjui@broadcom.com>
    Cc: Scott Branden <sbranden@broadcom.com>
    Cc: bcm-kernel-feedback-list@broadcom.com
    Cc: linux-spi@vger.kernel.org
    Cc: linux-rpi-kernel@lists.infradead.org
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Rob Herring <robh@kernel.org>
    Reviewed-by: Eric Anholt <eric@anholt.net>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c3083eff1b1b3bdae7389ff0e2fb7ae9423561e4
Author: Luis Henriques <lhenriques@suse.com>
Date:   Fri Jul 19 15:32:19 2019 +0100

    libceph: allow ceph_buffer_put() to receive a NULL ceph_buffer

    [ Upstream commit 5c498950f730aa17c5f8a2cdcb903524e4002ed2 ]

    Signed-off-by: Luis Henriques <lhenriques@suse.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bce83d9ccca56b9ea9b7cd88499681d10d5062ea
Author: Andrew Jones <drjones@redhat.com>
Date:   Thu Aug 22 13:03:05 2019 +0200

    KVM: arm/arm64: Only skip MMIO insn once

    [ Upstream commit 2113c5f62b7423e4a72b890bd479704aa85c81ba ]

    If after an MMIO exit to userspace a VCPU is immediately run with an
    immediate_exit request, such as when a signal is delivered or an MMIO
    emulation completion is needed, then the VCPU completes the MMIO
    emulation and immediately returns to userspace. As the exit_reason
    does not get changed from KVM_EXIT_MMIO in these cases we have to
    be careful not to complete the MMIO emulation again, when the VCPU is
    eventually run again, because the emulation does an instruction skip
    (and doing too many skips would be a waste of guest code :-) We need
    to use additional VCPU state to track if the emulation is complete.
    As luck would have it, we already have 'mmio_needed', which even
    appears to be used in this way by other architectures already.

    Fixes: 0d640732dbeb ("arm64: KVM: Skip MMIO insn after emulation")
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Andrew Jones <drjones@redhat.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1d86cb8d3204337e1853b84d69ea0f30dc0ba973
Author: Luis Henriques <lhenriques@suse.com>
Date:   Fri Jul 19 15:32:20 2019 +0100

    ceph: fix buffer free while holding i_ceph_lock in __ceph_setxattr()

    [ Upstream commit 86968ef21596515958d5f0a40233d02be78ecec0 ]

    Calling ceph_buffer_put() in __ceph_setxattr() may end up freeing the
    i_xattrs.prealloc_blob buffer while holding the i_ceph_lock.  This can be
    fixed by postponing the call until later, when the lock is released.

    The following backtrace was triggered by fstests generic/117.

      BUG: sleeping function called from invalid context at mm/vmalloc.c:2283
      in_atomic(): 1, irqs_disabled(): 0, pid: 650, name: fsstress
      3 locks held by fsstress/650:
       #0: 00000000870a0fe8 (sb_writers#8){.+.+}, at: mnt_want_write+0x20/0x50
       #1: 00000000ba0c4c74 (&type->i_mutex_dir_key#6){++++}, at: vfs_setxattr+0x55/0xa0
       #2: 000000008dfbb3f2 (&(&ci->i_ceph_lock)->rlock){+.+.}, at: __ceph_setxattr+0x297/0x810
      CPU: 1 PID: 650 Comm: fsstress Not tainted 5.2.0+ #437
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-prebuilt.qemu.org 04/01/2014
      Call Trace:
       dump_stack+0x67/0x90
       ___might_sleep.cold+0x9f/0xb1
       vfree+0x4b/0x60
       ceph_buffer_release+0x1b/0x60
       __ceph_setxattr+0x2b4/0x810
       __vfs_setxattr+0x66/0x80
       __vfs_setxattr_noperm+0x59/0xf0
       vfs_setxattr+0x81/0xa0
       setxattr+0x115/0x230
       ? filename_lookup+0xc9/0x140
       ? rcu_read_lock_sched_held+0x74/0x80
       ? rcu_sync_lockdep_assert+0x2e/0x60
       ? __sb_start_write+0x142/0x1a0
       ? mnt_want_write+0x20/0x50
       path_setxattr+0xba/0xd0
       __x64_sys_lsetxattr+0x24/0x30
       do_syscall_64+0x50/0x1c0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x7ff23514359a

    Signed-off-by: Luis Henriques <lhenriques@suse.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bc68ba54a2d32e2e3eaf826159b1dc8878cb109b
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Sun Aug 18 15:23:01 2019 -0500

    IB/mlx4: Fix memory leaks

    [ Upstream commit 5c1baaa82cea2c815a5180ded402a7cd455d1810 ]

    In mlx4_ib_alloc_pv_bufs(), 'tun_qp->tx_ring' is allocated through
    kcalloc(). However, it is not always deallocated in the following execution
    if an error occurs, leading to memory leaks. To fix this issue, free
    'tun_qp->tx_ring' whenever an error occurs.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Acked-by: Leon Romanovsky <leonro@mellanox.com>
    Link: https://lore.kernel.org/r/1566159781-4642-1-git-send-email-wenwen@cs.uga.edu
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6442370b5642d38c6f9ae8edb71d514aaa6c3dab
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Mon Aug 19 16:44:09 2019 +0200

    Tools: hv: kvp: eliminate 'may be used uninitialized' warning

    [ Upstream commit 89eb4d8d25722a0a0194cf7fa47ba602e32a6da7 ]

    When building hv_kvp_daemon GCC-8.3 complains:

    hv_kvp_daemon.c: In function ‘kvp_get_ip_info.constprop’:
    hv_kvp_daemon.c:812:30: warning: ‘ip_buffer’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      struct hv_kvp_ipaddr_value *ip_buffer;

    this seems to be a false positive: we only use ip_buffer when
    op == KVP_OP_GET_IP_INFO and it is only unset when op == KVP_OP_ENUMERATE.

    Silence the warning by initializing ip_buffer to NULL.

    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf3583e15956de79e9c37c5ca609434a04f8a224
Author: Tho Vu <tho.vu.wh@rvc.renesas.com>
Date:   Fri Aug 16 17:17:02 2019 +0200

    ravb: Fix use-after-free ravb_tstamp_skb

    [ Upstream commit cfef46d692efd852a0da6803f920cc756eea2855 ]

    When a Tx timestamp is requested, a pointer to the skb is stored in the
    ravb_tstamp_skb struct. This was done without an skb_get. There exists
    the possibility that the skb could be freed by ravb_tx_free (when
    ravb_tx_free is called from ravb_start_xmit) before the timestamp was
    processed, leading to a use-after-free bug.

    Use skb_get when filling a ravb_tstamp_skb struct, and add appropriate
    frees/consumes when a ravb_tstamp_skb struct is freed.

    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Signed-off-by: Tho Vu <tho.vu.wh@rvc.renesas.com>
    Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
    Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62b1e22efe3e6eb629d8a7130bf3e69ec86e6293
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Thu Aug 15 15:29:51 2019 -0500

    wimax/i2400m: fix a memory leak bug

    [ Upstream commit 44ef3a03252844a8753479b0cea7f29e4a804bdc ]

    In i2400m_barker_db_init(), 'options_orig' is allocated through kstrdup()
    to hold the original command line options. Then, the options are parsed.
    However, if an error occurs during the parsing process, 'options_orig' is
    not deallocated, leading to a memory leak bug. To fix this issue, free
    'options_orig' before returning the error.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b25f01d604ed86d379420f038c91555faef0afc
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Wed Aug 14 13:56:43 2019 -0500

    net: kalmia: fix memory leaks

    [ Upstream commit f1472cb09f11ddb41d4be84f0650835cb65a9073 ]

    In kalmia_init_and_get_ethernet_addr(), 'usb_buf' is allocated through
    kmalloc(). In the following execution, if the 'status' returned by
    kalmia_send_init_packet() is not 0, 'usb_buf' is not deallocated, leading
    to memory leaks. To fix this issue, add the 'out' label to free 'usb_buf'.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d28afe7a79edf0f2afd1005d9c2a83fab1a1ab6
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Wed Aug 14 13:03:38 2019 -0500

    cx82310_eth: fix a memory leak bug

    [ Upstream commit 1eca92eef18719027d394bf1a2d276f43e7cf886 ]

    In cx82310_bind(), 'dev->partial_data' is allocated through kmalloc().
    Then, the execution waits for the firmware to become ready. If the firmware
    is not ready in time, the execution is terminated. However, the allocated
    'dev->partial_data' is not deallocated on this path, leading to a memory
    leak bug. To fix this issue, free 'dev->partial_data' before returning the
    error.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6f3170c57da89158b1aa920fc547f481d278480
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Wed Aug 14 01:38:39 2019 -0500

    net: myri10ge: fix memory leaks

    [ Upstream commit 20fb7c7a39b5c719e2e619673b5f5729ee7d2306 ]

    In myri10ge_probe(), myri10ge_alloc_slices() is invoked to allocate slices
    related structures. Later on, myri10ge_request_irq() is used to get an irq.
    However, if this process fails, the allocated slices related structures are
    not deallocated, leading to memory leaks. To fix this issue, revise the
    target label of the goto statement to 'abort_with_slices'.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa6d2679e5cac2fd5ece39c8edb5f503064c5fcd
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Tue Aug 13 04:18:52 2019 -0500

    cxgb4: fix a memory leak bug

    [ Upstream commit c554336efa9bbc28d6ec14efbee3c7d63c61a34f ]

    In blocked_fl_write(), 't' is not deallocated if bitmap_parse_user() fails,
    leading to a memory leak bug. To fix this issue, free t before returning
    the error.

    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f46a46a9de0f1e005f64ade70336f9505a067a6e
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Wed Jul 31 20:38:14 2019 +0800

    gpio: Fix build error of function redefinition

    [ Upstream commit 68e03b85474a51ec1921b4d13204782594ef7223 ]

    when do randbuilding, I got this error:

    In file included from drivers/hwmon/pmbus/ucd9000.c:19:0:
    ./include/linux/gpio/driver.h:576:1: error: redefinition of gpiochip_add_pin_range
     gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
     ^~~~~~~~~~~~~~~~~~~~~~
    In file included from drivers/hwmon/pmbus/ucd9000.c:18:0:
    ./include/linux/gpio.h:245:1: note: previous definition of gpiochip_add_pin_range was here
     gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
     ^~~~~~~~~~~~~~~~~~~~~~

    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: 964cb341882f ("gpio: move pincontrol calls to <linux/gpio/driver.h>")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Link: https://lore.kernel.org/r/20190731123814.46624-1-yuehaibing@huawei.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da5cc03c7562d25a3b66c748b845d9717d6d22b3
Author: Thomas Falcon <tlfalcon@linux.ibm.com>
Date:   Mon Aug 12 16:13:06 2019 -0500

    ibmveth: Convert multicast list size for little-endian system

    [ Upstream commit 66cf4710b23ab2adda11155684a2c8826f4fe732 ]

    The ibm,mac-address-filters property defines the maximum number of
    addresses the hypervisor's multicast filter list can support. It is
    encoded as a big-endian integer in the OF device tree, but the virtual
    ethernet driver does not convert it for use by little-endian systems.
    As a result, the driver is not behaving as it should on affected systems
    when a large number of multicast addresses are assigned to the device.

    Reported-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
    Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5694f0d1cb10e9b9faaf47ba5b21f1d664f3a3ba
Author: Matthias Kaehlcke <mka@chromium.org>
Date:   Tue Jul 9 15:44:50 2019 -0700

    Bluetooth: btqca: Add a short delay before downloading the NVM

    [ Upstream commit 8059ba0bd0e4694e51c2ee6438a77b325f06c0d5 ]

    On WCN3990 downloading the NVM sometimes fails with a "TLV response
    size mismatch" error:

    [  174.949955] Bluetooth: btqca.c:qca_download_firmware() hci0: QCA Downloading qca/crnv21.bin
    [  174.958718] Bluetooth: btqca.c:qca_tlv_send_segment() hci0: QCA TLV response size mismatch

    It seems the controller needs a short time after downloading the
    firmware before it is ready for the NVM. A delay as short as 1 ms
    seems sufficient, make it 10 ms just in case. No event is received
    during the delay, hence we don't just silently drop an extra event.

    Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffb54f3eae723ca6d7ff34187bdfce91a0d28fce
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Sun Aug 11 20:13:45 2019 -0700

    net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx

    [ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

    clang warns:

    drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
    '&&' with constant operand [-Wconstant-logical-operand]
                            if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                      ^  ~~~~~~~~~~~~
    drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
    bitwise operation
                            if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                      ^~
                                                      &
    drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
    silence this warning
                            if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                     ~^~~~~~~~~~~~~~~
    1 warning generated.

    Explicitly check that NET_IP_ALIGN is not zero, which matches how this
    is checked in other parts of the tree. Because NET_IP_ALIGN is a build
    time constant, this check will be constant folded away during
    optimization.

    Fixes: 82a9928db560 ("tc35815: Enable StripCRC feature")
    Link: https://github.com/ClangBuiltLinux/linux/issues/608
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e040f074d49fb6fde93112a2350af5462a494c04
Author: Fuqian Huang <huangfq.daxian@gmail.com>
Date:   Fri Aug 9 13:35:39 2019 +0800

    net: tundra: tsi108: use spin_lock_irqsave instead of spin_lock_irq in IRQ context

    [ Upstream commit 8c25d0887a8bd0e1ca2074ac0c6dff173787a83b ]

    As spin_unlock_irq will enable interrupts.
    Function tsi108_stat_carry is called from interrupt handler tsi108_irq.
    Interrupts are enabled in interrupt handler.
    Use spin_lock_irqsave/spin_unlock_irqrestore instead of spin_(un)lock_irq
    in IRQ context to avoid this.

    Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b3d0a42f2aad1204dd1b489bb8d46c158ddb41f
Merge: 41bd92eff615 efbc4a364bd5
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Fri Sep 6 09:02:34 2019 -0700

    Merge 4.4.191 into kernel.lnx.4.4.r34-rel

    Changes in 4.4.191: (77 commits)
            HID: Add 044f:b320 ThrustMaster, Inc. 2 in 1 DT
            MIPS: kernel: only use i8253 clocksource with periodic clockevent
            netfilter: ebtables: fix a memory leak bug in compat
            bonding: Force slave speed check after link state recovery for 802.3ad
            can: dev: call netif_carrier_off() in register_candev()
            st21nfca_connectivity_event_received: null check the allocation
            st_nci_hci_connectivity_event_received: null check the allocation
            ASoC: ti: davinci-mcasp: Correct slot_width posed constraint
            net: usb: qmi_wwan: Add the BroadMobi BM818 card
            isdn: mISDN: hfcsusb: Fix possible null-pointer dereferences in start_isoc_chain()
            isdn: hfcsusb: Fix mISDN driver crash caused by transfer buffer on the stack
            perf bench numa: Fix cpu0 binding
            can: sja1000: force the string buffer NULL-terminated
            can: peak_usb: force the string buffer NULL-terminated
            NFSv4: Fix a potential sleep while atomic in nfs4_do_reclaim()
            net: cxgb3_main: Fix a resource leak in a error path in 'init_one()'
            net: hisilicon: make hip04_tx_reclaim non-reentrant
            net: hisilicon: fix hip04-xmit never return TX_BUSY
            net: hisilicon: Fix dma_map_single failed on arm64
            libata: add SG safety checks in SFF pio transfers
            selftests: kvm: Adding config fragments
            HID: wacom: correct misreported EKR ring values
            Revert "dm bufio: fix deadlock with loop device"
            userfaultfd_release: always remove uffd flags and clear vm_userfaultfd_ctx
            x86/retpoline: Don't clobber RFLAGS during CALL_NOSPEC on i386
            x86/apic: Handle missing global clockevent gracefully
            x86/boot: Save fields explicitly, zero out everything else
            x86/boot: Fix boot regression caused by bootparam sanitizing
            dm btree: fix order of block initialization in btree_split_beneath
            dm space map metadata: fix missing store of apply_bops() return value
            dm table: fix invalid memory accesses with too high sector number
            cgroup: Disable IRQs while holding css_set_lock
            GFS2: don't set rgrp gl_object until it's inserted into rgrp tree
            net: arc_emac: fix koops caused by sk_buff free
            vhost-net: set packet weight of tx polling to 2 * vq size
            vhost_net: use packet weight for rx handler, too
            vhost_net: introduce vhost_exceeds_weight()
            vhost: introduce vhost_exceeds_weight()
            vhost_net: fix possible infinite loop
            vhost: scsi: add weight support
            siphash: add cryptographically secure PRF
            siphash: implement HalfSipHash1-3 for hash tables
            inet: switch IP ID generator to siphash
            netfilter: ctnetlink: don't use conntrack/expect object addresses as id
            netfilter: conntrack: Use consistent ct id hash calculation
            Revert "perf test 6: Fix missing kvm module load for s390"
            x86/pm: Introduce quirk framework to save/restore extra MSR registers around suspend/resume
            x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h
            scsi: ufs: Fix NULL pointer dereference in ufshcd_config_vreg_hpm()
            dmaengine: ste_dma40: fix unneeded variable warning
            usb: gadget: composite: Clear "suspended" on reset/disconnect
            usb: host: fotg2: restart hcd after port reset
            tools: hv: fix KVP and VSS daemons exit code
            watchdog: bcm2835_wdt: Fix module autoload
            tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
            ALSA: usb-audio: Fix a stack buffer overflow bug in check_input_term
            ALSA: usb-audio: Fix an OOB bug in parse_audio_mixer_unit
            tcp: make sure EPOLLOUT wont be missed
            ALSA: seq: Fix potential concurrent access to the deleted pool
            KVM: x86: Don't update RIP or do single-step on faulting emulation
            x86/apic: Do not initialize LDR and DFR for bigsmp
            x86/apic: Include the LDR when clearing out APIC registers
            usb-storage: Add new JMS567 revision to unusual_devs
            USB: cdc-wdm: fix race between write and disconnect due to flag abuse
            usb: host: ohci: fix a race condition between shutdown and irq
            USB: storage: ums-realtek: Update module parameter description for auto_delink_en
            USB: storage: ums-realtek: Whitelist auto-delink support
            ptrace,x86: Make user_64bit_mode() available to 32-bit builds
            uprobes/x86: Fix detection of 32-bit user mode
            mmc: sdhci-of-at91: add quirk for broken HS200
            mmc: core: Fix init of SD cards reporting an invalid VDD range
            stm class: Fix a double free of stm_source_device
            VMCI: Release resource if the work is already queued
            Revert "cfg80211: fix processing world regdomain when non modular"
            mac80211: fix possible sta leak
            x86/ptrace: fix up botched merge of spectrev1 fix
            Linux 4.4.191

    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>

    Conflicts:
    	drivers/scsi/ufs/ufshcd.c
    	fs/userfaultfd.c
    	kernel/cgroup.c
    	sound/usb/mixer.c

commit efbc4a364bd5469a616668127439e7cfca4c1d7b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Sep 6 10:18:17 2019 +0200

    Linux 4.4.191

commit 61263fbe574b0b74c50552983bdcc2bb9a409b1e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Sep 4 12:27:18 2019 +0200

    x86/ptrace: fix up botched merge of spectrev1 fix

    I incorrectly merged commit 31a2fbb390fe ("x86/ptrace: Fix possible
    spectre-v1 in ptrace_get_debugreg()") when backporting it, as was
    graciously pointed out at
    https://grsecurity.net/teardown_of_a_failed_linux_lts_spectre_fix.php

    Resolve the upstream difference with the stable kernel merge to properly
    protect things.

    Reported-by: Brad Spengler <spender@grsecurity.net>
    Cc: Dianzhang Chen <dianzhangchen0@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: <bp@alien8.de>
    Cc: <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c0932cd8197d290195dc281ff6534e13d9d97e8
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Aug 1 09:30:33 2019 +0200

    mac80211: fix possible sta leak

    commit 5fd2f91ad483baffdbe798f8a08f1b41442d1e24 upstream.

    If TDLS station addition is rejected, the sta memory is leaked.
    Avoid this by moving the check before the allocation.

    Cc: stable@vger.kernel.org
    Fixes: 7ed5285396c2 ("mac80211: don't initiate TDLS connection if station is not associated to AP")
    Link: https://lore.kernel.org/r/20190801073033.7892-1-johannes@sipsolutions.net
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3161dea144dde71e8d8dd1cd8b736b6e431b7ee7
Author: Hodaszi, Robert <Robert.Hodaszi@digi.com>
Date:   Fri Jun 14 13:16:01 2019 +0000

    Revert "cfg80211: fix processing world regdomain when non modular"

    commit 0d31d4dbf38412f5b8b11b4511d07b840eebe8cb upstream.

    This reverts commit 96cce12ff6e0 ("cfg80211: fix processing world
    regdomain when non modular").

    Re-triggering a reg_process_hint with the last request on all events,
    can make the regulatory domain fail in case of multiple WiFi modules. On
    slower boards (espacially with mdev), enumeration of the WiFi modules
    can end up in an intersected regulatory domain, and user cannot set it
    with 'iw reg set' anymore.

    This is happening, because:
    - 1st module enumerates, queues up a regulatory request
    - request gets processed by __reg_process_hint_driver():
      - checks if previous was set by CORE -> yes
        - checks if regulator domain changed -> yes, from '00' to e.g. 'US'
          -> sends request to the 'crda'
    - 2nd module enumerates, queues up a regulator request (which triggers
      the reg_todo() work)
    - reg_todo() -> reg_process_pending_hints() sees, that the last request
      is not processed yet, so it tries to process it again.
      __reg_process_hint driver() will run again, and:
      - checks if the last request's initiator was the core -> no, it was
        the driver (1st WiFi module)
      - checks, if the previous initiator was the driver -> yes
        - checks if the regulator domain changed -> yes, it was '00' (set by
          core, and crda call did not return yet), and should be changed to 'US'

    ------> __reg_process_hint_driver calls an intersect

    Besides, the reg_process_hint call with the last request is meaningless
    since the crda call has a timeout work. If that timeout expires, the
    first module's request will lost.

    Cc: stable@vger.kernel.org
    Fixes: 96cce12ff6e0 ("cfg80211: fix processing world regdomain when non modular")
    Signed-off-by: Robert Hodaszi <robert.hodaszi@digi.com>
    Link: https://lore.kernel.org/r/20190614131600.GA13897@a1-hr
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16ab568881f8d2bc2e3b66dab55ab6ea72d9849b
Author: Nadav Amit <namit@vmware.com>
Date:   Tue Aug 20 13:26:38 2019 -0700

    VMCI: Release resource if the work is already queued

    commit ba03a9bbd17b149c373c0ea44017f35fc2cd0f28 upstream.

    Francois reported that VMware balloon gets stuck after a balloon reset,
    when the VMCI doorbell is removed. A similar error can occur when the
    balloon driver is removed with the following splat:

    [ 1088.622000] INFO: task modprobe:3565 blocked for more than 120 seconds.
    [ 1088.622035]       Tainted: G        W         5.2.0 #4
    [ 1088.622087] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 1088.622205] modprobe        D    0  3565   1450 0x00000000
    [ 1088.622210] Call Trace:
    [ 1088.622246]  __schedule+0x2a8/0x690
    [ 1088.622248]  schedule+0x2d/0x90
    [ 1088.622250]  schedule_timeout+0x1d3/0x2f0
    [ 1088.622252]  wait_for_completion+0xba/0x140
    [ 1088.622320]  ? wake_up_q+0x80/0x80
    [ 1088.622370]  vmci_resource_remove+0xb9/0xc0 [vmw_vmci]
    [ 1088.622373]  vmci_doorbell_destroy+0x9e/0xd0 [vmw_vmci]
    [ 1088.622379]  vmballoon_vmci_cleanup+0x6e/0xf0 [vmw_balloon]
    [ 1088.622381]  vmballoon_exit+0x18/0xcc8 [vmw_balloon]
    [ 1088.622394]  __x64_sys_delete_module+0x146/0x280
    [ 1088.622408]  do_syscall_64+0x5a/0x130
    [ 1088.622410]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [ 1088.622415] RIP: 0033:0x7f54f62791b7
    [ 1088.622421] Code: Bad RIP value.
    [ 1088.622421] RSP: 002b:00007fff2a949008 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
    [ 1088.622426] RAX: ffffffffffffffda RBX: 000055dff8b55d00 RCX: 00007f54f62791b7
    [ 1088.622426] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055dff8b55d68
    [ 1088.622427] RBP: 000055dff8b55d00 R08: 00007fff2a947fb1 R09: 0000000000000000
    [ 1088.622427] R10: 00007f54f62f5cc0 R11: 0000000000000206 R12: 000055dff8b55d68
    [ 1088.622428] R13: 0000000000000001 R14: 000055dff8b55d68 R15: 00007fff2a94a3f0

    The cause for the bug is that when the "delayed" doorbell is invoked, it
    takes a reference on the doorbell entry and schedules work that is
    supposed to run the appropriate code and drop the doorbell entry
    reference. The code ignores the fact that if the work is already queued,
    it will not be scheduled to run one more time. As a result one of the
    references would not be dropped. When the code waits for the reference
    to get to zero, during balloon reset or module removal, it gets stuck.

    Fix it. Drop the reference if schedule_work() indicates that the work is
    already queued.

    Note that this bug got more apparent (or apparent at all) due to
    commit ce664331b248 ("vmw_balloon: VMCI_DOORBELL_SET does not check status").

    Fixes: 83e2ec765be03 ("VMCI: doorbell implementation.")
    Reported-by: Francois Rigault <rigault.francois@gmail.com>
    Cc: Jorgen Hansen <jhansen@vmware.com>
    Cc: Adit Ranadive <aditr@vmware.com>
    Cc: Alexios Zavras <alexios.zavras@intel.com>
    Cc: Vishnu DASA <vdasa@vmware.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Nadav Amit <namit@vmware.com>
    Reviewed-by: Vishnu Dasa <vdasa@vmware.com>
    Link: https://lore.kernel.org/r/20190820202638.49003-1-namit@vmware.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c25b7d78f0e871b10a38a0da9dbc9c538217bef9
Author: Ding Xiang <dingxiang@cmss.chinamobile.com>
Date:   Wed Aug 21 10:49:52 2019 +0300

    stm class: Fix a double free of stm_source_device

    commit 961b6ffe0e2c403b09a8efe4a2e986b3c415391a upstream.

    In the error path of stm_source_register_device(), the kfree is
    unnecessary, as the put_device() before it ends up calling
    stm_source_device_release() to free stm_source_device, leading to
    a double free at the outer kfree() call. Remove it.

    Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com>
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Fixes: 7bd1d4093c2fa ("stm class: Introduce an abstraction for System Trace Module devices")
    Link: https://lore.kernel.org/linux-arm-kernel/1563354988-23826-1-git-send-email-dingxiang@cmss.chinamobile.com/
    Cc: stable@vger.kernel.org # v4.4+
    Link: https://lore.kernel.org/r/20190821074955.3925-2-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2f1509fca476d763d94eb0026b28c22ab110688
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Tue Aug 27 10:10:43 2019 +0200

    mmc: core: Fix init of SD cards reporting an invalid VDD range

    commit 72741084d903e65e121c27bd29494d941729d4a1 upstream.

    The OCR register defines the supported range of VDD voltages for SD cards.
    However, it has turned out that some SD cards reports an invalid voltage
    range, for example having bit7 set.

    When a host supports MMC_CAP2_FULL_PWR_CYCLE and some of the voltages from
    the invalid VDD range, this triggers the core to run a power cycle of the
    card to try to initialize it at the lowest common supported voltage.
    Obviously this fails, since the card can't support it.

    Let's fix this problem, by clearing invalid bits from the read OCR register
    for SD cards, before proceeding with the VDD voltage negotiation.

    Cc: stable@vger.kernel.org
    Reported-by: Philip Langdale <philipl@overt.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Reviewed-by: Philip Langdale <philipl@overt.org>
    Tested-by: Philip Langdale <philipl@overt.org>
    Tested-by: Manuel Presnitz <mail@mpy.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12a897daa78b640bcdfd6422bf2d697c442549e1
Author: Eugen Hristev <eugen.hristev@microchip.com>
Date:   Thu Aug 8 08:35:40 2019 +0000

    mmc: sdhci-of-at91: add quirk for broken HS200

    commit 7871aa60ae0086fe4626abdf5ed13eeddf306c61 upstream.

    HS200 is not implemented in the driver, but the controller claims it
    through caps. Remove it via a quirk, to make sure the mmc core do not try
    to enable HS200, as it causes the eMMC initialization to fail.

    Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Fixes: bb5f8ea4d514 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC")
    Cc: stable@vger.kernel.org # v4.4+
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d1a41682781c2a268160d15eb8adf63024c4e70
Author: Sebastian Mayr <me@sam.st>
Date:   Sun Jul 28 17:26:17 2019 +0200

    uprobes/x86: Fix detection of 32-bit user mode

    [ Upstream commit 9212ec7d8357ea630031e89d0d399c761421c83b ]

    32-bit processes running on a 64-bit kernel are not always detected
    correctly, causing the process to crash when uretprobes are installed.

    The reason for the crash is that in_ia32_syscall() is used to determine the
    process's mode, which only works correctly when called from a syscall.

    In the case of uretprobes, however, the function is called from a exception
    and always returns 'false' on a 64-bit kernel. In consequence this leads to
    corruption of the process's return address.

    Fix this by using user_64bit_mode() instead of in_ia32_syscall(), which
    is correct in any situation.

    [ tglx: Add a comment and the following historical info ]

    This should have been detected by the rename which happened in commit

      abfb9498ee13 ("x86/entry: Rename is_{ia32,x32}_task() to in_{ia32,x32}_syscall()")

    which states in the changelog:

        The is_ia32_task()/is_x32_task() function names are a big misnomer: they
        suggests that the compat-ness of a system call is a task property, which
        is not true, the compatness of a system call purely depends on how it
        was invoked through the system call layer.
        .....

    and then it went and blindly renamed every call site.

    Sadly enough this was already mentioned here:

       8faaed1b9f50 ("uprobes/x86: Introduce sizeof_long(), cleanup adjust_ret_addr() and
    arch_uretprobe_hijack_return_addr()")

    where the changelog says:

        TODO: is_ia32_task() is not what we actually want, TS_COMPAT does
        not necessarily mean 32bit. Fortunately syscall-like insns can't be
        probed so it actually works, but it would be better to rename and
        use is_ia32_frame().

    and goes all the way back to:

        0326f5a94dde ("uprobes/core: Handle breakpoint and singlestep exceptions")

    Oh well. 7+ years until someone actually tried a uretprobe on a 32bit
    process on a 64bit kernel....

    Fixes: 0326f5a94dde ("uprobes/core: Handle breakpoint and singlestep exceptions")
    Signed-off-by: Sebastian Mayr <me@sam.st>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190728152617.7308-1-me@sam.st
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6029fe64cefa148900b58596e5335ac70ffb570
Author: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Date:   Fri Oct 27 13:25:30 2017 -0700

    ptrace,x86: Make user_64bit_mode() available to 32-bit builds

    [ Upstream commit e27c310af5c05cf876d9cad006928076c27f54d4 ]

    In its current form, user_64bit_mode() can only be used when CONFIG_X86_64
    is selected. This implies that code built with CONFIG_X86_64=n cannot use
    it. If a piece of code needs to be built for both CONFIG_X86_64=y and
    CONFIG_X86_64=n and wants to use this function, it needs to wrap it in
    an #ifdef/#endif; potentially, in multiple places.

    This can be easily avoided with a single #ifdef/#endif pair within
    user_64bit_mode() itself.

    Suggested-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Cc: "Michael S. Tsirkin" <mst@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: ricardo.neri@intel.com
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: Huang Rui <ray.huang@amd.com>
    Cc: Qiaowei Ren <qiaowei.ren@intel.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
    Cc: Chris Metcalf <cmetcalf@mellanox.com>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Colin Ian King <colin.king@canonical.com>
    Cc: Chen Yucong <slaoub@gmail.com>
    Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Lorenzo Stoakes <lstoakes@gmail.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Thomas Garnier <thgarnie@google.com>
    Link: https://lkml.kernel.org/r/1509135945-13762-4-git-send-email-ricardo.neri-calderon@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4761474088761cd0705a80943dfafa0f723696d1
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Aug 28 01:34:50 2019 +0800

    USB: storage: ums-realtek: Whitelist auto-delink support

    commit 1902a01e2bcc3abd7c9a18dc05e78c7ab4a53c54 upstream.

    Auto-delink requires writing special registers to ums-realtek devices.
    Unconditionally enable auto-delink may break newer devices.

    So only enable auto-delink by default for the original three IDs,
    0x0138, 0x0158 and 0x0159.

    Realtek is working on a patch to properly support auto-delink for other
    IDs.

    BugLink: https://bugs.launchpad.net/bugs/1838886
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190827173450.13572-2-kai.heng.feng@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00087c6e434e8705d97ef8c0f796b573894e981b
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Aug 28 01:34:49 2019 +0800

    USB: storage: ums-realtek: Update module parameter description for auto_delink_en

    commit f6445b6b2f2bb1745080af4a0926049e8bca2617 upstream.

    The option named "auto_delink_en" is a bit misleading, as setting it to
    false doesn't really disable auto-delink but let auto-delink be firmware
    controlled.

    Update the description to reflect the real usage of this parameter.

    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190827173450.13572-1-kai.heng.feng@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb1ff5020b3e55f88be1f506042b003d9478cbfd
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Tue Aug 27 12:51:50 2019 +0900

    usb: host: ohci: fix a race condition between shutdown and irq

    commit a349b95d7ca0cea71be4a7dac29830703de7eb62 upstream.

    This patch fixes an issue that the following error is
    possible to happen when ohci hardware causes an interruption
    and the system is shutting down at the same time.

    [   34.851754] usb 2-1: USB disconnect, device number 2
    [   35.166658] irq 156: nobody cared (try booting with the "irqpoll" option)
    [   35.173445] CPU: 0 PID: 22 Comm: kworker/0:1 Not tainted 5.3.0-rc5 #85
    [   35.179964] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)
    [   35.187886] Workqueue: usb_hub_wq hub_event
    [   35.192063] Call trace:
    [   35.194509]  dump_backtrace+0x0/0x150
    [   35.198165]  show_stack+0x14/0x20
    [   35.201475]  dump_stack+0xa0/0xc4
    [   35.204785]  __report_bad_irq+0x34/0xe8
    [   35.208614]  note_interrupt+0x2cc/0x318
    [   35.212446]  handle_irq_event_percpu+0x5c/0x88
    [   35.216883]  handle_irq_event+0x48/0x78
    [   35.220712]  handle_fasteoi_irq+0xb4/0x188
    [   35.224802]  generic_handle_irq+0x24/0x38
    [   35.228804]  __handle_domain_irq+0x5c/0xb0
    [   35.232893]  gic_handle_irq+0x58/0xa8
    [   35.236548]  el1_irq+0xb8/0x180
    [   35.239681]  __do_softirq+0x94/0x23c
    [   35.243253]  irq_exit+0xd0/0xd8
    [   35.246387]  __handle_domain_irq+0x60/0xb0
    [   35.250475]  gic_handle_irq+0x58/0xa8
    [   35.254130]  el1_irq+0xb8/0x180
    [   35.257268]  kernfs_find_ns+0x5c/0x120
    [   35.261010]  kernfs_find_and_get_ns+0x3c/0x60
    [   35.265361]  sysfs_unmerge_group+0x20/0x68
    [   35.269454]  dpm_sysfs_remove+0x2c/0x68
    [   35.273284]  device_del+0x80/0x370
    [   35.276683]  hid_destroy_device+0x28/0x60
    [   35.280686]  usbhid_disconnect+0x4c/0x80
    [   35.284602]  usb_unbind_interface+0x6c/0x268
    [   35.288867]  device_release_driver_internal+0xe4/0x1b0
    [   35.293998]  device_release_driver+0x14/0x20
    [   35.298261]  bus_remove_device+0x110/0x128
    [   35.302350]  device_del+0x148/0x370
    [   35.305832]  usb_disable_device+0x8c/0x1d0
    [   35.309921]  usb_disconnect+0xc8/0x2d0
    [   35.313663]  hub_event+0x6e0/0x1128
    [   35.317146]  process_one_work+0x1e0/0x320
    [   35.321148]  worker_thread+0x40/0x450
    [   35.324805]  kthread+0x124/0x128
    [   35.328027]  ret_from_fork+0x10/0x18
    [   35.331594] handlers:
    [   35.333862] [<0000000079300c1d>] usb_hcd_irq
    [   35.338126] [<0000000079300c1d>] usb_hcd_irq
    [   35.342389] Disabling IRQ #156

    ohci_shutdown() disables all the interrupt and rh_state is set to
    OHCI_RH_HALTED. In other hand, ohci_irq() is possible to enable
    OHCI_INTR_SF and OHCI_INTR_MIE on ohci_irq(). Note that OHCI_INTR_SF
    is possible to be set by start_ed_unlink() which is called:
     ohci_irq()
      -> process_done_list()
       -> takeback_td()
        -> start_ed_unlink()

    So, ohci_irq() has the following condition, the issue happens by
    &ohci->regs->intrenable = OHCI_INTR_MIE | OHCI_INTR_SF and
    ohci->rh_state = OHCI_RH_HALTED:

    	/* interrupt for some other device? */
    	if (ints == 0 || unlikely(ohci->rh_state == OHCI_RH_HALTED))
    		return IRQ_NOTMINE;

    To fix the issue, ohci_shutdown() holds the spin lock while disabling
    the interruption and …
mdeejay added a commit to BeastRoms-Devices/kernel_xiaomi_laurel_sprout that referenced this issue Sep 19, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
catuva21 added a commit to catuva21/kernel_RN7 that referenced this issue Sep 19, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928db560 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Blacksuan19 added a commit to Blacksuan19/android_kernel_dark_ages that referenced this issue Sep 20, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
hritikutekar added a commit to hritikutekar/android_kernel_nokia_sdm660 that referenced this issue Sep 20, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
fiqri14082019 added a commit to fiqri14082019/kernel_xiaomi_vince-4.9 that referenced this issue Sep 21, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mylove90 added a commit to mylove90/android_kernel_xiaomi_onc that referenced this issue Sep 22, 2019
net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                  ^~
                                                  &
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928 ("tc35815: Enable StripCRC feature")
Link: ClangBuiltLinux/linux#608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.