This is a note to let you know that I've just added the patch titled
[media] v4l: vsp1: Prevent multiple streamon race commencing pipeline early
to the 4.9-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:
v4l-vsp1-prevent-multiple-streamon-race-commencing-pipeline-early.patch
and it can be found in the queue-4.9 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 Sun Mar 18 16:55:33 CET 2018
From: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com>
Date: Fri, 6 Jan 2017 10:15:28 -0200
Subject: [media] v4l: vsp1: Prevent multiple streamon race commencing pipeline early
From: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com>
[ Upstream commit 4461c84b52b4a952c657505ef7e4e06b016783df ]
With multiple inputs through the BRU it is feasible for the streams to
race each other at stream-on.
Multiple VIDIOC_STREAMON calls racing each other could have process
N-1 skipping over the pipeline setup section and then start the pipeline
early, if videobuf2 has already enqueued buffers to the driver for
process N but not called the .start_streaming() operation yet
In the case of the video pipelines, this
can present two serious issues.
1) A null-dereference if the pipe->dl is committed at the same time as
the vsp1_video_setup_pipeline() is processing
2) A hardware hang, where a display list is committed without having
called vsp1_video_setup_pipeline() first
Repair this issue, by ensuring that only the stream which configures the
pipeline is able to start it.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/platform/vsp1/vsp1_video.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -792,6 +792,7 @@ static int vsp1_video_start_streaming(st
{
struct vsp1_video *video = vb2_get_drv_priv(vq);
struct vsp1_pipeline *pipe = video->rwpf->pipe;
+ bool start_pipeline = false;
unsigned long flags;
int ret;
@@ -802,11 +803,23 @@ static int vsp1_video_start_streaming(st
mutex_unlock(&pipe->lock);
return ret;
}
+
+ start_pipeline = true;
}
pipe->stream_count++;
mutex_unlock(&pipe->lock);
+ /*
+ * vsp1_pipeline_ready() is not sufficient to establish that all streams
+ * are prepared and the pipeline is configured, as multiple streams
+ * can race through streamon with buffers already queued; Therefore we
+ * don't even attempt to start the pipeline until the last stream has
+ * called through here.
+ */
+ if (!start_pipeline)
+ return 0;
+
spin_lock_irqsave(&pipe->irqlock, flags);
if (vsp1_pipeline_ready(pipe))
vsp1_video_pipeline_run(pipe);
Patches currently in stable-queue which might be from kieran.bingham+renesas(a)ideasonboard.com are
queue-4.9/v4l-vsp1-prevent-multiple-streamon-race-commencing-pipeline-early.patch
queue-4.9/v4l-vsp1-register-pipe-with-output-wpf.patch
queue-4.9/media-vsp1-prevent-suspending-and-resuming-drm-pipelines.patch
This is a note to let you know that I've just added the patch titled
userns: Don't fail follow_automount based on s_user_ns
to the 4.9-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:
userns-don-t-fail-follow_automount-based-on-s_user_ns.patch
and it can be found in the queue-4.9 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 Sun Mar 18 16:55:33 CET 2018
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Wed, 29 Nov 2017 17:29:20 -0600
Subject: userns: Don't fail follow_automount based on s_user_ns
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
[ Upstream commit bbc3e471011417598e598707486f5d8814ec9c01 ]
When vfs_submount was added the test to limit automounts from
filesystems that with s_user_ns != &init_user_ns accidentially left
in follow_automount. The test was never about any security concerns
and was always about how do we implement this for filesystems whose
s_user_ns != &init_user_ns.
At the moment this check makes no difference as there are no
filesystems that both set FS_USERNS_MOUNT and implement d_automount.
Remove this check now while I am thinking about it so there will not
be odd booby traps for someone who does want to make this combination
work.
vfs_submount still needs improvements to allow this combination to work,
and vfs_submount contains a check that presents a warning.
The autofs4 filesystem could be modified to set FS_USERNS_MOUNT and it would
need not work on this code path, as userspace performs the mounts.
Fixes: 93faccbbfa95 ("fs: Better permission checking for submounts")
Fixes: aeaa4a79ff6a ("fs: Call d_automount with the filesystems creds")
Acked-by: Ian Kent <raven(a)themaw.net>
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/namei.c | 3 ---
1 file changed, 3 deletions(-)
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1121,9 +1121,6 @@ static int follow_automount(struct path
path->dentry->d_inode)
return -EISDIR;
- if (path->dentry->d_sb->s_user_ns != &init_user_ns)
- return -EACCES;
-
nd->total_link_count++;
if (nd->total_link_count >= 40)
return -ELOOP;
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-4.9/userns-don-t-fail-follow_automount-based-on-s_user_ns.patch
This is a note to let you know that I've just added the patch titled
usb: misc: lvs: fix race condition in disconnect handling
to the 4.9-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-misc-lvs-fix-race-condition-in-disconnect-handling.patch
and it can be found in the queue-4.9 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 Sun Mar 18 16:55:33 CET 2018
From: Oliver Neukum <oneukum(a)suse.com>
Date: Tue, 14 Mar 2017 12:05:07 +0100
Subject: usb: misc: lvs: fix race condition in disconnect handling
From: Oliver Neukum <oneukum(a)suse.com>
[ Upstream commit c4ba329cabca7c839ab48fb58b5bcc2582951a48 ]
There is a small window during which the an URB may
remain active after disconnect has returned. If in that case
already freed memory may be accessed and executed.
The fix is to poison the URB befotre the work is flushed.
Signed-off-by: Oliver Neukum <oneukum(a)suse.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>
---
drivers/usb/misc/lvstest.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/misc/lvstest.c
+++ b/drivers/usb/misc/lvstest.c
@@ -433,6 +433,7 @@ static void lvs_rh_disconnect(struct usb
struct lvs_rh *lvs = usb_get_intfdata(intf);
sysfs_remove_group(&intf->dev.kobj, &lvs_attr_group);
+ usb_poison_urb(lvs->urb); /* used in scheduled work */
flush_work(&lvs->rh_work);
usb_free_urb(lvs->urb);
}
Patches currently in stable-queue which might be from oneukum(a)suse.com are
queue-4.9/usb-misc-lvs-fix-race-condition-in-disconnect-handling.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 4.9-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-4.9 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 Sun Mar 18 16:55:33 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
@@ -2103,16 +2103,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);
@@ -2283,14 +2280,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-4.9/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
usb: dwc3: make sure UX_EXIT_PX is cleared
to the 4.9-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-dwc3-make-sure-ux_exit_px-is-cleared.patch
and it can be found in the queue-4.9 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 Sun Mar 18 16:55:33 CET 2018
From: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Date: Wed, 3 Aug 2016 14:16:15 +0300
Subject: usb: dwc3: make sure UX_EXIT_PX is cleared
From: Felipe Balbi <felipe.balbi(a)linux.intel.com>
[ Upstream commit 1966b8657d058ecb95031809b607bf3fd1e01c10 ]
This bit is only supposed to be used with known
buggy PHYs, however some platforms might erroneously
set it. In order to avoid it, let's make sure this
bit is always cleared. If some PHY needs this, we
will need to add a quirk flag.
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/dwc3/core.c | 6 ++++++
drivers/usb/dwc3/core.h | 1 +
2 files changed, 7 insertions(+)
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -464,6 +464,12 @@ static int dwc3_phy_setup(struct dwc3 *d
reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
/*
+ * Make sure UX_EXIT_PX is cleared as that causes issues with some
+ * PHYs. Also, this bit is not supposed to be used in normal operation.
+ */
+ reg &= ~DWC3_GUSB3PIPECTL_UX_EXIT_PX;
+
+ /*
* Above 1.94a, it is recommended to set DWC3_GUSB3PIPECTL_SUSPHY
* to '0' during coreConsultant configuration. So default value
* will be '0' when the core is reset. Application needs to set it
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -223,6 +223,7 @@
#define DWC3_GUSB3PIPECTL_PHYSOFTRST (1 << 31)
#define DWC3_GUSB3PIPECTL_U2SSINP3OK (1 << 29)
#define DWC3_GUSB3PIPECTL_DISRXDETINP3 (1 << 28)
+#define DWC3_GUSB3PIPECTL_UX_EXIT_PX (1 << 27)
#define DWC3_GUSB3PIPECTL_REQP1P2P3 (1 << 24)
#define DWC3_GUSB3PIPECTL_DEP1P2P3(n) ((n) << 19)
#define DWC3_GUSB3PIPECTL_DEP1P2P3_MASK DWC3_GUSB3PIPECTL_DEP1P2P3(7)
Patches currently in stable-queue which might be from felipe.balbi(a)linux.intel.com are
queue-4.9/usb-dwc2-make-sure-we-disconnect-the-gadget-state.patch
queue-4.9/usb-gadget-dummy_hcd-fix-wrong-power-status-bit-clear-reset-in-dummy_hub_control.patch
queue-4.9/usb-dwc3-make-sure-ux_exit_px-is-cleared.patch
This is a note to let you know that I've just added the patch titled
usb: dwc2: Make sure we disconnect the gadget state
to the 4.9-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-dwc2-make-sure-we-disconnect-the-gadget-state.patch
and it can be found in the queue-4.9 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 Sun Mar 18 16:55:33 CET 2018
From: John Stultz <john.stultz(a)linaro.org>
Date: Mon, 13 Feb 2017 20:08:08 -0800
Subject: usb: dwc2: Make sure we disconnect the gadget state
From: John Stultz <john.stultz(a)linaro.org>
[ Upstream commit dad3f793f20fbb5c0c342f0f5a0bdf69a4d76089 ]
I had seen some odd behavior with HiKey's usb-gadget interface
that I finally seemed to have chased down. Basically every other
time I plugged in the OTG port, the gadget interface would
properly initialize. The other times, I'd get a big WARN_ON
in dwc2_hsotg_init_fifo() about the fifo_map not being clear.
Ends up if we don't disconnect the gadget state, the fifo-map
doesn't get cleared properly, which causes WARN_ON messages and
also results in the device not properly being setup as a gadget
every other time the OTG port is connected.
So this patch adds a call to dwc2_hsotg_disconnect() in the
reset path so the state is properly cleared.
With it, the gadget interface initializes properly on every
plug in.
Cc: Wei Xu <xuwei5(a)hisilicon.com>
Cc: Guodong Xu <guodong.xu(a)linaro.org>
Cc: Amit Pundir <amit.pundir(a)linaro.org>
Cc: Rob Herring <robh+dt(a)kernel.org>
Cc: John Youn <johnyoun(a)synopsys.com>
Cc: Douglas Anderson <dianders(a)chromium.org>
Cc: Chen Yu <chenyu56(a)huawei.com>
Cc: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: linux-usb(a)vger.kernel.org
Acked-by: John Youn <johnyoun(a)synopsys.com>
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
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/dwc2/hcd.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -3220,6 +3220,7 @@ static void dwc2_conn_id_status_change(s
dwc2_core_init(hsotg, false);
dwc2_enable_global_interrupts(hsotg);
spin_lock_irqsave(&hsotg->lock, flags);
+ dwc2_hsotg_disconnect(hsotg);
dwc2_hsotg_core_init_disconnected(hsotg, false);
spin_unlock_irqrestore(&hsotg->lock, flags);
dwc2_hsotg_core_connect(hsotg);
Patches currently in stable-queue which might be from john.stultz(a)linaro.org are
queue-4.9/usb-dwc2-make-sure-we-disconnect-the-gadget-state.patch
queue-4.9/sysrq-reset-the-watchdog-timers-while-displaying-high-resolution-timers.patch
queue-4.9/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
tty: amba-pl011: Fix spurious TX interrupts
to the 4.9-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:
tty-amba-pl011-fix-spurious-tx-interrupts.patch
and it can be found in the queue-4.9 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 Sun Mar 18 16:55:33 CET 2018
From: Jayachandran C <jnair(a)caviumnetworks.com>
Date: Sat, 1 Apr 2017 19:42:09 +0000
Subject: tty: amba-pl011: Fix spurious TX interrupts
From: Jayachandran C <jnair(a)caviumnetworks.com>
[ Upstream commit 7d05587c9e0e4611650bb403812e2d492c178a9f ]
On SMP systems, we see a lot of spurious TX interrupts when a
program generates a steady stream of output to the pl011 UART.
The problem can be easily seen when one CPU generates the output
while another CPU handles the pl011 interrupts, and the rate of
output is low enough not to fill the TX FIFO. The problem seems
to be:
-- CPU a -- -- CPU b --
(take port lock)
pl011_start_tx
pl011_start_tx_pio
enable TXIM in REG_IMSC -> causes uart tx intr (pl011_int)
pl011_tx_chars pl011_int
...tx chars, all done... (wait for port lock)
pl011_stop_tx .
disable TXIM .
(release port lock) -> (take port lock)
check for TXIM, not enabled
(release port lock)
return IRQ_NONE
Enabling the TXIM in pl011_start_tx_pio() causes the interrupt
to be generated and delivered to CPU b, even though pl011_tx_chars()
is able to complete the TX and then disable the tx interrupt.
Fix this by enabling TXIM only after pl011_tx_chars, if it is needed.
pl011_tx_chars will return a boolean indicating whether the TX
interrupts have to be enabled.
Debugged-by: Vijaya Kumar <Vijaya.Kumar(a)cavium.com>
Signed-off-by: Jayachandran C <jnair(a)caviumnetworks.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>
---
drivers/tty/serial/amba-pl011.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1302,14 +1302,15 @@ static void pl011_stop_tx(struct uart_po
pl011_dma_tx_stop(uap);
}
-static void pl011_tx_chars(struct uart_amba_port *uap, bool from_irq);
+static bool pl011_tx_chars(struct uart_amba_port *uap, bool from_irq);
/* Start TX with programmed I/O only (no DMA) */
static void pl011_start_tx_pio(struct uart_amba_port *uap)
{
- uap->im |= UART011_TXIM;
- pl011_write(uap->im, uap, REG_IMSC);
- pl011_tx_chars(uap, false);
+ if (pl011_tx_chars(uap, false)) {
+ uap->im |= UART011_TXIM;
+ pl011_write(uap->im, uap, REG_IMSC);
+ }
}
static void pl011_start_tx(struct uart_port *port)
@@ -1389,25 +1390,26 @@ static bool pl011_tx_char(struct uart_am
return true;
}
-static void pl011_tx_chars(struct uart_amba_port *uap, bool from_irq)
+/* Returns true if tx interrupts have to be (kept) enabled */
+static bool pl011_tx_chars(struct uart_amba_port *uap, bool from_irq)
{
struct circ_buf *xmit = &uap->port.state->xmit;
int count = uap->fifosize >> 1;
if (uap->port.x_char) {
if (!pl011_tx_char(uap, uap->port.x_char, from_irq))
- return;
+ return true;
uap->port.x_char = 0;
--count;
}
if (uart_circ_empty(xmit) || uart_tx_stopped(&uap->port)) {
pl011_stop_tx(&uap->port);
- return;
+ return false;
}
/* If we are using DMA mode, try to send some characters. */
if (pl011_dma_tx_irq(uap))
- return;
+ return true;
do {
if (likely(from_irq) && count-- == 0)
@@ -1422,8 +1424,11 @@ static void pl011_tx_chars(struct uart_a
if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
uart_write_wakeup(&uap->port);
- if (uart_circ_empty(xmit))
+ if (uart_circ_empty(xmit)) {
pl011_stop_tx(&uap->port);
+ return false;
+ }
+ return true;
}
static void pl011_modem_status(struct uart_amba_port *uap)
Patches currently in stable-queue which might be from jnair(a)caviumnetworks.com are
queue-4.9/tty-amba-pl011-fix-spurious-tx-interrupts.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 4.9-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-4.9 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 Sun Mar 18 16:55:33 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
@@ -463,7 +463,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-4.9/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
timers, sched_clock: Update timeout for clock wrap
to the 4.9-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-4.9 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 Sun Mar 18 16:55:33 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
@@ -205,6 +205,11 @@ sched_clock_register(u64 (*read)(void),
update_clock_read_data(&rd);
+ 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-4.9/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
test_firmware: fix setting old custom fw path back on exit
to the 4.9-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:
test_firmware-fix-setting-old-custom-fw-path-back-on-exit.patch
and it can be found in the queue-4.9 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 Sun Mar 18 16:55:33 CET 2018
From: "Luis R. Rodriguez" <mcgrof(a)kernel.org>
Date: Mon, 20 Nov 2017 09:45:35 -0800
Subject: test_firmware: fix setting old custom fw path back on exit
From: "Luis R. Rodriguez" <mcgrof(a)kernel.org>
[ Upstream commit 65c79230576873b312c3599479c1e42355c9f349 ]
The file /sys/module/firmware_class/parameters/path can be used
to set a custom firmware path. The fw_filesystem.sh script creates
a temporary directory to add a test firmware file to be used during
testing, in order for this to work it uses the custom path syfs file
and it was supposed to reset back the file on execution exit. The
script failed to do this due to a typo, it was using OLD_PATH instead
of OLD_FWPATH, since its inception since v3.17.
Its not as easy to just keep the old setting, it turns out that
resetting an empty setting won't actually do what we want, we need
to check if it was empty and set an empty space.
Without this we end up having the temporary path always set after
we run these tests.
Fixes: 0a8adf58475 ("test: add firmware_class loader test")
Signed-off-by: Luis R. Rodriguez <mcgrof(a)kernel.org>
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/testing/selftests/firmware/fw_filesystem.sh | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/tools/testing/selftests/firmware/fw_filesystem.sh
+++ b/tools/testing/selftests/firmware/fw_filesystem.sh
@@ -28,7 +28,10 @@ test_finish()
if [ "$HAS_FW_LOADER_USER_HELPER" = "yes" ]; then
echo "$OLD_TIMEOUT" >/sys/class/firmware/timeout
fi
- echo -n "$OLD_PATH" >/sys/module/firmware_class/parameters/path
+ if [ "$OLD_FWPATH" = "" ]; then
+ OLD_FWPATH=" "
+ fi
+ echo -n "$OLD_FWPATH" >/sys/module/firmware_class/parameters/path
rm -f "$FW"
rmdir "$FWPATH"
}
Patches currently in stable-queue which might be from mcgrof(a)kernel.org are
queue-4.9/test_firmware-fix-setting-old-custom-fw-path-back-on-exit.patch