This is a note to let you know that I've just added the patch titled
veth: set peer GSO values
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
veth-set-peer-gso-values.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Stephen Hemminger <stephen(a)networkplumber.org>
Date: Thu, 7 Dec 2017 15:40:20 -0800
Subject: veth: set peer GSO values
From: Stephen Hemminger <stephen(a)networkplumber.org>
[ Upstream commit 72d24955b44a4039db54a1c252b5031969eeaac3 ]
When new veth is created, and GSO values have been configured
on one device, clone those values to the peer.
For example:
# ip link add dev vm1 gso_max_size 65530 type veth peer name vm2
This should create vm1 <--> vm2 with both having GSO maximum
size set to 65530.
Signed-off-by: Stephen Hemminger <sthemmin(a)microsoft.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/veth.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -382,6 +382,9 @@ static int veth_newlink(struct net *src_
if (ifmp && (dev->ifindex != 0))
peer->ifindex = ifmp->ifi_index;
+ peer->gso_max_size = dev->gso_max_size;
+ peer->gso_max_segs = dev->gso_max_segs;
+
err = register_netdevice(peer);
put_net(net);
net = NULL;
Patches currently in stable-queue which might be from stephen(a)networkplumber.org are
queue-3.18/veth-set-peer-gso-values.patch
This is a note to let you know that I've just added the patch titled
tools/usbip: fixes build with musl libc toolchain
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tools-usbip-fixes-build-with-musl-libc-toolchain.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Julien BOIBESSOT <julien.boibessot(a)armadeus.com>
Date: Tue, 5 Dec 2017 18:48:14 +0100
Subject: tools/usbip: fixes build with musl libc toolchain
From: Julien BOIBESSOT <julien.boibessot(a)armadeus.com>
[ Upstream commit 77be4c878c72e411ad22af96b6f81dd45c26450a ]
Indeed musl doesn't define old SIGCLD signal name but only new one SIGCHLD.
SIGCHLD is the new POSIX name for that signal so it doesn't change
anything on other libcs.
This fixes this kind of build error:
usbipd.c: In function ‘set_signal’:
usbipd.c:459:12: error: 'SIGCLD' undeclared (first use in this function)
sigaction(SIGCLD, &act, NULL);
^~~~~~
usbipd.c:459:12: note: each undeclared identifier is reported only once
for each function it appears in
Makefile:407: recipe for target 'usbipd.o' failed
make[3]: *** [usbipd.o] Error 1
Signed-off-by: Julien BOIBESSOT <julien.boibessot(a)armadeus.com>
Acked-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/usb/usbip/src/usbipd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/usb/usbip/src/usbipd.c
+++ b/tools/usb/usbip/src/usbipd.c
@@ -453,7 +453,7 @@ static void set_signal(void)
sigaction(SIGTERM, &act, NULL);
sigaction(SIGINT, &act, NULL);
act.sa_handler = SIG_IGN;
- sigaction(SIGCLD, &act, NULL);
+ sigaction(SIGCHLD, &act, NULL);
}
static const char *pid_file;
Patches currently in stable-queue which might be from julien.boibessot(a)armadeus.com are
queue-3.18/tools-usbip-fixes-build-with-musl-libc-toolchain.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: dummy_hcd: Fix wrong power status bit clear/reset in dummy_hub_control()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-gadget-dummy_hcd-fix-wrong-power-status-bit-clear-reset-in-dummy_hub_control.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Yuyang Du <yuyang.du(a)intel.com>
Date: Fri, 24 Mar 2017 04:06:11 +0800
Subject: usb: gadget: dummy_hcd: Fix wrong power status bit clear/reset in dummy_hub_control()
From: Yuyang Du <yuyang.du(a)intel.com>
[ Upstream commit 9f20dfb44d03745d0d3cef2ffb3abf8d8024fa61 ]
This fixes the commit: 1cd8fd2887e1 ("usb: gadget: dummy_hcd: add
SuperSpeed support").
In the case of ClearPortFeature and USB_PORT_FEAT_POWER, simply clear
the right bit regardless of what the wValue is.
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Signed-off-by: Yuyang Du <yuyang.du(a)intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/udc/dummy_hcd.c | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -2001,16 +2001,13 @@ static int dummy_hub_control(
}
break;
case USB_PORT_FEAT_POWER:
- if (hcd->speed == HCD_USB3) {
- if (dum_hcd->port_status & USB_PORT_STAT_POWER)
- dev_dbg(dummy_dev(dum_hcd),
- "power-off\n");
- } else
- if (dum_hcd->port_status &
- USB_SS_PORT_STAT_POWER)
- dev_dbg(dummy_dev(dum_hcd),
- "power-off\n");
- /* FALLS THROUGH */
+ dev_dbg(dummy_dev(dum_hcd), "power-off\n");
+ if (hcd->speed == HCD_USB3)
+ dum_hcd->port_status &= ~USB_SS_PORT_STAT_POWER;
+ else
+ dum_hcd->port_status &= ~USB_PORT_STAT_POWER;
+ set_link_state(dum_hcd);
+ break;
default:
dum_hcd->port_status &= ~(1 << wValue);
set_link_state(dum_hcd);
@@ -2181,14 +2178,13 @@ static int dummy_hub_control(
if ((dum_hcd->port_status &
USB_SS_PORT_STAT_POWER) != 0) {
dum_hcd->port_status |= (1 << wValue);
- set_link_state(dum_hcd);
}
} else
if ((dum_hcd->port_status &
USB_PORT_STAT_POWER) != 0) {
dum_hcd->port_status |= (1 << wValue);
- set_link_state(dum_hcd);
}
+ set_link_state(dum_hcd);
}
break;
case GetPortErrorCount:
Patches currently in stable-queue which might be from yuyang.du(a)intel.com are
queue-3.18/usb-gadget-dummy_hcd-fix-wrong-power-status-bit-clear-reset-in-dummy_hub_control.patch
This is a note to let you know that I've just added the patch titled
timers, sched_clock: Update timeout for clock wrap
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
timers-sched_clock-update-timeout-for-clock-wrap.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: David Engraf <david.engraf(a)sysgo.com>
Date: Fri, 17 Feb 2017 08:51:03 +0100
Subject: timers, sched_clock: Update timeout for clock wrap
From: David Engraf <david.engraf(a)sysgo.com>
[ Upstream commit 1b8955bc5ac575009835e371ae55e7f3af2197a9 ]
The scheduler clock framework may not use the correct timeout for the clock
wrap. This happens when a new clock driver calls sched_clock_register()
after the kernel called sched_clock_postinit(). In this case the clock wrap
timeout is too long thus sched_clock_poll() is called too late and the clock
already wrapped.
On my ARM system the scheduler was no longer scheduling any other task than
the idle task because the sched_clock() wrapped.
Signed-off-by: David Engraf <david.engraf(a)sysgo.com>
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/time/sched_clock.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -146,6 +146,11 @@ void __init sched_clock_register(u64 (*r
cd.epoch_ns = ns;
raw_write_seqcount_end(&cd.seq);
+ if (sched_clock_timer.function != NULL) {
+ /* update timeout for clock wrap */
+ hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
+ }
+
r = rate;
if (r >= 4000000) {
r /= 1000000;
Patches currently in stable-queue which might be from david.engraf(a)sysgo.com are
queue-3.18/timers-sched_clock-update-timeout-for-clock-wrap.patch
This is a note to let you know that I've just added the patch titled
spi: sun6i: disable/unprepare clocks on remove
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
spi-sun6i-disable-unprepare-clocks-on-remove.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
Date: Thu, 7 Dec 2017 15:04:53 +0100
Subject: spi: sun6i: disable/unprepare clocks on remove
From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
[ Upstream commit 2d9bbd02c54094ceffa555143b0d68cd06504d63 ]
sun6i_spi_probe() uses sun6i_spi_runtime_resume() to prepare/enable
clocks, so sun6i_spi_remove() should use sun6i_spi_runtime_suspend() to
disable/unprepare them if we're not suspended.
Replacing pm_runtime_disable() by pm_runtime_force_suspend() will ensure
that sun6i_spi_runtime_suspend() is called if needed.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 3558fe900e8af (spi: sunxi: Add Allwinner A31 SPI controller driver)
Signed-off-by: Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
Acked-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/spi/spi-sun6i.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -457,7 +457,7 @@ err_free_master:
static int sun6i_spi_remove(struct platform_device *pdev)
{
- pm_runtime_disable(&pdev->dev);
+ pm_runtime_force_suspend(&pdev->dev);
return 0;
}
Patches currently in stable-queue which might be from Tobias.Jordan(a)elektrobit.com are
queue-3.18/spi-sun6i-disable-unprepare-clocks-on-remove.patch
This is a note to let you know that I've just added the patch titled
tcp: sysctl: Fix a race to avoid unexpected 0 window from space
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tcp-sysctl-fix-a-race-to-avoid-unexpected-0-window-from-space.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Gao Feng <fgao(a)ikuai8.com>
Date: Fri, 24 Mar 2017 07:05:12 +0800
Subject: tcp: sysctl: Fix a race to avoid unexpected 0 window from space
From: Gao Feng <fgao(a)ikuai8.com>
[ Upstream commit c48367427a39ea0b85c7cf018fe4256627abfd9e ]
Because sysctl_tcp_adv_win_scale could be changed any time, so there
is one race in tcp_win_from_space.
For example,
1.sysctl_tcp_adv_win_scale<=0 (sysctl_tcp_adv_win_scale is negative now)
2.space>>(-sysctl_tcp_adv_win_scale) (sysctl_tcp_adv_win_scale is postive now)
As a result, tcp_win_from_space returns 0. It is unexpected.
Certainly if the compiler put the sysctl_tcp_adv_win_scale into one
register firstly, then use the register directly, it would be ok.
But we could not depend on the compiler behavior.
Signed-off-by: Gao Feng <fgao(a)ikuai8.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/net/tcp.h | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1099,9 +1099,11 @@ void tcp_select_initial_window(int __spa
static inline int tcp_win_from_space(int space)
{
- return sysctl_tcp_adv_win_scale<=0 ?
- (space>>(-sysctl_tcp_adv_win_scale)) :
- space - (space>>sysctl_tcp_adv_win_scale);
+ int tcp_adv_win_scale = sysctl_tcp_adv_win_scale;
+
+ return tcp_adv_win_scale <= 0 ?
+ (space>>(-tcp_adv_win_scale)) :
+ space - (space>>tcp_adv_win_scale);
}
/* Note: caller must be prepared to deal with negative returns */
Patches currently in stable-queue which might be from fgao(a)ikuai8.com are
queue-3.18/tcp-sysctl-fix-a-race-to-avoid-unexpected-0-window-from-space.patch
This is a note to let you know that I've just added the patch titled
selinux: check for address length in selinux_socket_bind()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
selinux-check-for-address-length-in-selinux_socket_bind.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Alexander Potapenko <glider(a)google.com>
Date: Mon, 6 Mar 2017 19:46:14 +0100
Subject: selinux: check for address length in selinux_socket_bind()
From: Alexander Potapenko <glider(a)google.com>
[ Upstream commit e2f586bd83177d22072b275edd4b8b872daba924 ]
KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of
uninitialized memory in selinux_socket_bind():
==================================================================
BUG: KMSAN: use of unitialized memory
inter: 0
CPU: 3 PID: 1074 Comm: packet2 Tainted: G B 4.8.0-rc6+ #1916
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
0000000000000000 ffff8800882ffb08 ffffffff825759c8 ffff8800882ffa48
ffffffff818bf551 ffffffff85bab870 0000000000000092 ffffffff85bab550
0000000000000000 0000000000000092 00000000bb0009bb 0000000000000002
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff825759c8>] dump_stack+0x238/0x290 lib/dump_stack.c:51
[<ffffffff818bdee6>] kmsan_report+0x276/0x2e0 mm/kmsan/kmsan.c:1008
[<ffffffff818bf0fb>] __msan_warning+0x5b/0xb0 mm/kmsan/kmsan_instr.c:424
[<ffffffff822dae71>] selinux_socket_bind+0xf41/0x1080 security/selinux/hooks.c:4288
[<ffffffff8229357c>] security_socket_bind+0x1ec/0x240 security/security.c:1240
[<ffffffff84265d98>] SYSC_bind+0x358/0x5f0 net/socket.c:1366
[<ffffffff84265a22>] SyS_bind+0x82/0xa0 net/socket.c:1356
[<ffffffff81005678>] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292
[<ffffffff8518217c>] entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.o:?
chained origin: 00000000ba6009bb
[<ffffffff810bb7a7>] save_stack_trace+0x27/0x50 arch/x86/kernel/stacktrace.c:67
[< inline >] kmsan_save_stack_with_flags mm/kmsan/kmsan.c:322
[< inline >] kmsan_save_stack mm/kmsan/kmsan.c:337
[<ffffffff818bd2b8>] kmsan_internal_chain_origin+0x118/0x1e0 mm/kmsan/kmsan.c:530
[<ffffffff818bf033>] __msan_set_alloca_origin4+0xc3/0x130 mm/kmsan/kmsan_instr.c:380
[<ffffffff84265b69>] SYSC_bind+0x129/0x5f0 net/socket.c:1356
[<ffffffff84265a22>] SyS_bind+0x82/0xa0 net/socket.c:1356
[<ffffffff81005678>] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292
[<ffffffff8518217c>] return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.o:?
origin description: ----address@SYSC_bind (origin=00000000b8c00900)
==================================================================
(the line numbers are relative to 4.8-rc6, but the bug persists upstream)
, when I run the following program as root:
=======================================================
#include <string.h>
#include <sys/socket.h>
#include <netinet/in.h>
int main(int argc, char *argv[]) {
struct sockaddr addr;
int size = 0;
if (argc > 1) {
size = atoi(argv[1]);
}
memset(&addr, 0, sizeof(addr));
int fd = socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP);
bind(fd, &addr, size);
return 0;
}
=======================================================
(for different values of |size| other error reports are printed).
This happens because bind() unconditionally copies |size| bytes of
|addr| to the kernel, leaving the rest uninitialized. Then
security_socket_bind() reads the IP address bytes, including the
uninitialized ones, to determine the port, or e.g. pass them further to
sel_netnode_find(), which uses them to calculate a hash.
Signed-off-by: Alexander Potapenko <glider(a)google.com>
Acked-by: Eric Dumazet <edumazet(a)google.com>
[PM: fixed some whitespace damage]
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/selinux/hooks.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -4061,10 +4061,18 @@ static int selinux_socket_bind(struct so
u32 sid, node_perm;
if (family == PF_INET) {
+ if (addrlen < sizeof(struct sockaddr_in)) {
+ err = -EINVAL;
+ goto out;
+ }
addr4 = (struct sockaddr_in *)address;
snum = ntohs(addr4->sin_port);
addrp = (char *)&addr4->sin_addr.s_addr;
} else {
+ if (addrlen < SIN6_LEN_RFC2133) {
+ err = -EINVAL;
+ goto out;
+ }
addr6 = (struct sockaddr_in6 *)address;
snum = ntohs(addr6->sin6_port);
addrp = (char *)&addr6->sin6_addr.s6_addr;
Patches currently in stable-queue which might be from glider(a)google.com are
queue-3.18/selinux-check-for-address-length-in-selinux_socket_bind.patch
This is a note to let you know that I've just added the patch titled
spi: omap2-mcspi: poll OMAP2_MCSPI_CHSTAT_RXS for PIO transfer
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
spi-omap2-mcspi-poll-omap2_mcspi_chstat_rxs-for-pio-transfer.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Akinobu Mita <akinobu.mita(a)gmail.com>
Date: Wed, 22 Mar 2017 09:18:26 +0900
Subject: spi: omap2-mcspi: poll OMAP2_MCSPI_CHSTAT_RXS for PIO transfer
From: Akinobu Mita <akinobu.mita(a)gmail.com>
[ Upstream commit 812613591cb652344186c4cd912304ed02138566 ]
When running the spi-loopback-test with slower clock rate like 10 KHz,
the test for 251 bytes transfer was failed. This failure triggered an
spi-omap2-mcspi's error message "DMA RX last word empty".
This message means that PIO for reading the remaining bytes due to the
DMA transfer length reduction is failed. This problem can be fixed by
polling OMAP2_MCSPI_CHSTAT_RXS bit in channel status register to wait
until the receive buffer register is filled.
Cc: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Akinobu Mita <akinobu.mita(a)gmail.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/spi/spi-omap2-mcspi.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -441,6 +441,8 @@ omap2_mcspi_rx_dma(struct spi_device *sp
int elements = 0;
int word_len, element_count;
struct omap2_mcspi_cs *cs = spi->controller_state;
+ void __iomem *chstat_reg = cs->base + OMAP2_MCSPI_CHSTAT0;
+
mcspi = spi_master_get_devdata(spi->master);
mcspi_dma = &mcspi->dma_channels[spi->chip_select];
count = xfer->len;
@@ -501,8 +503,8 @@ omap2_mcspi_rx_dma(struct spi_device *sp
if (l & OMAP2_MCSPI_CHCONF_TURBO) {
elements--;
- if (likely(mcspi_read_cs_reg(spi, OMAP2_MCSPI_CHSTAT0)
- & OMAP2_MCSPI_CHSTAT_RXS)) {
+ if (!mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_RXS)) {
u32 w;
w = mcspi_read_cs_reg(spi, OMAP2_MCSPI_RX0);
@@ -520,8 +522,7 @@ omap2_mcspi_rx_dma(struct spi_device *sp
return count;
}
}
- if (likely(mcspi_read_cs_reg(spi, OMAP2_MCSPI_CHSTAT0)
- & OMAP2_MCSPI_CHSTAT_RXS)) {
+ if (!mcspi_wait_for_reg_bit(chstat_reg, OMAP2_MCSPI_CHSTAT_RXS)) {
u32 w;
w = mcspi_read_cs_reg(spi, OMAP2_MCSPI_RX0);
Patches currently in stable-queue which might be from akinobu.mita(a)gmail.com are
queue-3.18/spi-omap2-mcspi-poll-omap2_mcspi_chstat_rxs-for-pio-transfer.patch
This is a note to let you know that I've just added the patch titled
scsi: sg: check for valid direction before starting the request
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-sg-check-for-valid-direction-before-starting-the-request.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Johannes Thumshirn <jthumshirn(a)suse.de>
Date: Fri, 7 Apr 2017 09:34:15 +0200
Subject: scsi: sg: check for valid direction before starting the request
From: Johannes Thumshirn <jthumshirn(a)suse.de>
[ Upstream commit 28676d869bbb5257b5f14c0c95ad3af3a7019dd5 ]
Check for a valid direction before starting the request, otherwise we
risk running into an assertion in the scsi midlayer checking for valid
requests.
[mkp: fixed typo]
Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Link: http://www.spinics.net/lists/linux-scsi/msg104400.html
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: Hannes Reinecke <hare(a)suse.com>
Tested-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sg.c | 46 ++++++++++++++++++++++++++++++++++------------
1 file changed, 34 insertions(+), 12 deletions(-)
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -674,18 +674,14 @@ sg_write(struct file *filp, const char _
* is a non-zero input_size, so emit a warning.
*/
if (hp->dxfer_direction == SG_DXFER_TO_FROM_DEV) {
- static char cmd[TASK_COMM_LEN];
- if (strcmp(current->comm, cmd)) {
- printk_ratelimited(KERN_WARNING
- "sg_write: data in/out %d/%d bytes "
- "for SCSI command 0x%x-- guessing "
- "data in;\n program %s not setting "
- "count and/or reply_len properly\n",
- old_hdr.reply_len - (int)SZ_SG_HEADER,
- input_size, (unsigned int) cmnd[0],
- current->comm);
- strcpy(cmd, current->comm);
- }
+ printk_ratelimited(KERN_WARNING
+ "sg_write: data in/out %d/%d bytes "
+ "for SCSI command 0x%x-- guessing "
+ "data in;\n program %s not setting "
+ "count and/or reply_len properly\n",
+ old_hdr.reply_len - (int)SZ_SG_HEADER,
+ input_size, (unsigned int) cmnd[0],
+ current->comm);
}
k = sg_common_write(sfp, srp, cmnd, sfp->timeout, blocking);
return (k < 0) ? k : count;
@@ -764,6 +760,29 @@ sg_new_write(Sg_fd *sfp, struct file *fi
return count;
}
+static bool sg_is_valid_dxfer(sg_io_hdr_t *hp)
+{
+ switch (hp->dxfer_direction) {
+ case SG_DXFER_NONE:
+ if (hp->dxferp || hp->dxfer_len > 0)
+ return false;
+ return true;
+ case SG_DXFER_TO_DEV:
+ case SG_DXFER_FROM_DEV:
+ case SG_DXFER_TO_FROM_DEV:
+ if (!hp->dxferp || hp->dxfer_len == 0)
+ return false;
+ return true;
+ case SG_DXFER_UNKNOWN:
+ if ((!hp->dxferp && hp->dxfer_len) ||
+ (hp->dxferp && hp->dxfer_len == 0))
+ return false;
+ return true;
+ default:
+ return false;
+ }
+}
+
static int
sg_common_write(Sg_fd * sfp, Sg_request * srp,
unsigned char *cmnd, int timeout, int blocking)
@@ -784,6 +803,9 @@ sg_common_write(Sg_fd * sfp, Sg_request
"sg_common_write: scsi opcode=0x%02x, cmd_size=%d\n",
(int) cmnd[0], (int) hp->cmd_len));
+ if (!sg_is_valid_dxfer(hp))
+ return -EINVAL;
+
k = sg_start_req(srp, cmnd);
if (k) {
SCSI_LOG_TIMEOUT(1, sg_printk(KERN_INFO, sfp->parentdp,
Patches currently in stable-queue which might be from jthumshirn(a)suse.de are
queue-3.18/scsi-sg-check-for-valid-direction-before-starting-the-request.patch
queue-3.18/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch
This is a note to let you know that I've just added the patch titled
scsi: sg: close race condition in sg_remove_sfp_usercontext()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Hannes Reinecke <hare(a)suse.de>
Date: Fri, 7 Apr 2017 09:34:17 +0200
Subject: scsi: sg: close race condition in sg_remove_sfp_usercontext()
From: Hannes Reinecke <hare(a)suse.de>
[ Upstream commit 97d27b0dd015e980ade63fda111fd1353276e28b ]
sg_remove_sfp_usercontext() is clearing any sg requests, but needs to
take 'rq_list_lock' when modifying the list.
Reported-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Hannes Reinecke <hare(a)suse.com>
Reviewed-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Tested-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sg.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -535,6 +535,7 @@ sg_read(struct file *filp, char __user *
} else
count = (old_hdr->result == 0) ? 0 : -EIO;
sg_finish_rem_req(srp);
+ sg_remove_request(sfp, srp);
retval = count;
free_old_hdr:
kfree(old_hdr);
@@ -575,6 +576,7 @@ sg_new_read(Sg_fd * sfp, char __user *bu
}
err_out:
err2 = sg_finish_rem_req(srp);
+ sg_remove_request(sfp, srp);
return err ? : err2 ? : count;
}
@@ -811,6 +813,7 @@ sg_common_write(Sg_fd * sfp, Sg_request
SCSI_LOG_TIMEOUT(1, sg_printk(KERN_INFO, sfp->parentdp,
"sg_common_write: start_req err=%d\n", k));
sg_finish_rem_req(srp);
+ sg_remove_request(sfp, srp);
return k; /* probably out of space --> ENOMEM */
}
if (atomic_read(&sdp->detaching)) {
@@ -823,6 +826,7 @@ sg_common_write(Sg_fd * sfp, Sg_request
}
sg_finish_rem_req(srp);
+ sg_remove_request(sfp, srp);
return -ENODEV;
}
@@ -1353,6 +1357,7 @@ sg_rq_end_io_usercontext(struct work_str
struct sg_fd *sfp = srp->parentfp;
sg_finish_rem_req(srp);
+ sg_remove_request(sfp, srp);
kref_put(&sfp->f_ref, sg_remove_sfp);
}
@@ -1902,8 +1907,6 @@ sg_finish_rem_req(Sg_request *srp)
else
sg_remove_scat(sfp, req_schp);
- sg_remove_request(sfp, srp);
-
return ret;
}
@@ -2250,12 +2253,17 @@ sg_remove_sfp_usercontext(struct work_st
struct sg_fd *sfp = container_of(work, struct sg_fd, ew.work);
struct sg_device *sdp = sfp->parentdp;
Sg_request *srp;
+ unsigned long iflags;
/* Cleanup any responses which were never read(). */
+ write_lock_irqsave(&sfp->rq_list_lock, iflags);
while (!list_empty(&sfp->rq_list)) {
srp = list_first_entry(&sfp->rq_list, Sg_request, entry);
sg_finish_rem_req(srp);
+ list_del(&srp->entry);
+ srp->parentfp = NULL;
}
+ write_unlock_irqrestore(&sfp->rq_list_lock, iflags);
if (sfp->reserve.bufflen > 0) {
SCSI_LOG_TIMEOUT(6, sg_printk(KERN_INFO, sdp,
Patches currently in stable-queue which might be from hare(a)suse.de are
queue-3.18/scsi-devinfo-apply-to-hp-xp-the-same-flags-as-hitachi-vsp.patch
queue-3.18/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch