This is a note to let you know that I've just added the patch titled
usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
to the 4.14-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-ohci-proper-handling-of-ed_rm_list-to-handle-race-condition-between-usb_kill_urb-and-finish_unlinks.patch
and it can be found in the queue-4.14 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 46408ea558df13b110e0866b99624384a33bdeba Mon Sep 17 00:00:00 2001
From: AMAN DEEP <aman.deep(a)samsung.com>
Date: Thu, 8 Feb 2018 11:55:01 +0800
Subject: usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
From: AMAN DEEP <aman.deep(a)samsung.com>
commit 46408ea558df13b110e0866b99624384a33bdeba upstream.
There is a race condition between finish_unlinks->finish_urb() function
and usb_kill_urb() in ohci controller case. The finish_urb calls
spin_unlock(&ohci->lock) before usb_hcd_giveback_urb() function call,
then if during this time, usb_kill_urb is called for another endpoint,
then new ed will be added to ed_rm_list at beginning for unlink, and
ed_rm_list will point to newly added.
When finish_urb() is completed in finish_unlinks() and ed->td_list
becomes empty as in below code (in finish_unlinks() function):
if (list_empty(&ed->td_list)) {
*last = ed->ed_next;
ed->ed_next = NULL;
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
*last = ed->ed_next;
ed->ed_next = NULL;
ed_schedule(ohci, ed);
}
The *last = ed->ed_next will make ed_rm_list to point to ed->ed_next
and previously added ed by usb_kill_urb will be left unreferenced by
ed_rm_list. This causes usb_kill_urb() hang forever waiting for
finish_unlink to remove added ed from ed_rm_list.
The main reason for hang in this race condtion is addition and removal
of ed from ed_rm_list in the beginning during usb_kill_urb and later
last* is modified in finish_unlinks().
As suggested by Alan Stern, the solution for proper handling of
ohci->ed_rm_list is to remove ed from the ed_rm_list before finishing
any URBs. Then at the end, we can add ed back to the list if necessary.
This properly handle the updated ohci->ed_rm_list in usb_kill_urb().
Fixes: 977dcfdc6031 ("USB: OHCI: don't lose track of EDs when a controller dies")
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
CC: <stable(a)vger.kernel.org>
Signed-off-by: Aman Deep <aman.deep(a)samsung.com>
Signed-off-by: Jeffy Chen <jeffy.chen(a)rock-chips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/ohci-q.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
--- a/drivers/usb/host/ohci-q.c
+++ b/drivers/usb/host/ohci-q.c
@@ -1018,6 +1018,8 @@ skip_ed:
* have modified this list. normally it's just prepending
* entries (which we'd ignore), but paranoia won't hurt.
*/
+ *last = ed->ed_next;
+ ed->ed_next = NULL;
modified = 0;
/* unlink urbs as requested, but rescan the list after
@@ -1076,21 +1078,22 @@ rescan_this:
goto rescan_this;
/*
- * If no TDs are queued, take ED off the ed_rm_list.
+ * If no TDs are queued, ED is now idle.
* Otherwise, if the HC is running, reschedule.
- * If not, leave it on the list for further dequeues.
+ * If the HC isn't running, add ED back to the
+ * start of the list for later processing.
*/
if (list_empty(&ed->td_list)) {
- *last = ed->ed_next;
- ed->ed_next = NULL;
ed->state = ED_IDLE;
list_del(&ed->in_use_list);
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
- *last = ed->ed_next;
- ed->ed_next = NULL;
ed_schedule(ohci, ed);
} else {
- last = &ed->ed_next;
+ ed->ed_next = ohci->ed_rm_list;
+ ohci->ed_rm_list = ed;
+ /* Don't loop on the same ED */
+ if (last == &ohci->ed_rm_list)
+ last = &ed->ed_next;
}
if (modified)
Patches currently in stable-queue which might be from aman.deep(a)samsung.com are
queue-4.14/usb-ohci-proper-handling-of-ed_rm_list-to-handle-race-condition-between-usb_kill_urb-and-finish_unlinks.patch
This is a note to let you know that I've just added the patch titled
usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
to the 4.14-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-renesas_usbhs-missed-the-running-flag-in-usb_dmac-with-rx-path.patch
and it can be found in the queue-4.14 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 17aa31f13cad25daa19d3f923323f552e87bc874 Mon Sep 17 00:00:00 2001
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Date: Mon, 5 Feb 2018 17:12:35 +0900
Subject: usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
commit 17aa31f13cad25daa19d3f923323f552e87bc874 upstream.
This fixes an issue that a gadget driver (usb_f_fs) is possible to
stop rx transactions after the usb-dmac is used because the following
functions missed to set/check the "running" flag.
- usbhsf_dma_prepare_pop_with_usb_dmac()
- usbhsf_dma_pop_done_with_usb_dmac()
So, if next transaction uses pio, the usbhsf_prepare_pop() can not
start the transaction because the "running" flag is 0.
Fixes: 8355b2b3082d ("usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle")
Cc: <stable(a)vger.kernel.org> # v3.19+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/renesas_usbhs/fifo.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -998,6 +998,10 @@ static int usbhsf_dma_prepare_pop_with_u
if ((uintptr_t)pkt->buf & (USBHS_USB_DMAC_XFER_SIZE - 1))
goto usbhsf_pio_prepare_pop;
+ /* return at this time if the pipe is running */
+ if (usbhs_pipe_is_running(pipe))
+ return 0;
+
usbhs_pipe_config_change_bfre(pipe, 1);
ret = usbhsf_fifo_select(pipe, fifo, 0);
@@ -1188,6 +1192,7 @@ static int usbhsf_dma_pop_done_with_usb_
usbhsf_fifo_clear(pipe, fifo);
pkt->actual = usbhs_dma_calc_received_size(pkt, chan, rcv_len);
+ usbhs_pipe_running(pipe, 0);
usbhsf_dma_stop(pipe, fifo);
usbhsf_dma_unmap(pkt);
usbhsf_fifo_unselect(pipe, pipe->fifo);
Patches currently in stable-queue which might be from yoshihiro.shimoda.uh(a)renesas.com are
queue-4.14/usb-renesas_usbhs-missed-the-running-flag-in-usb_dmac-with-rx-path.patch
This is a note to let you know that I've just added the patch titled
usb: host: ehci: use correct device pointer for dma ops
to the 4.14-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-host-ehci-use-correct-device-pointer-for-dma-ops.patch
and it can be found in the queue-4.14 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 02a10f061a3f8bca1b37332672f50a107198adbe Mon Sep 17 00:00:00 2001
From: Peter Chen <hzpeterchen(a)gmail.com>
Date: Thu, 1 Feb 2018 12:26:43 +0800
Subject: usb: host: ehci: use correct device pointer for dma ops
From: Peter Chen <hzpeterchen(a)gmail.com>
commit 02a10f061a3f8bca1b37332672f50a107198adbe upstream.
commit a8c06e407ef9 ("usb: separate out sysdev pointer from usb_bus")
converted to use hcd->self.sysdev for DMA operations instead of
hcd->self.controller, but forgot to do it for hcd test mode. Replace
the correct one in this commit.
Fixes: a8c06e407ef9 ("usb: separate out sysdev pointer from usb_bus")
Signed-off-by: Peter Chen <peter.chen(a)nxp.com>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/ehci-hub.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -787,12 +787,12 @@ static struct urb *request_single_step_s
atomic_inc(&urb->use_count);
atomic_inc(&urb->dev->urbnum);
urb->setup_dma = dma_map_single(
- hcd->self.controller,
+ hcd->self.sysdev,
urb->setup_packet,
sizeof(struct usb_ctrlrequest),
DMA_TO_DEVICE);
urb->transfer_dma = dma_map_single(
- hcd->self.controller,
+ hcd->self.sysdev,
urb->transfer_buffer,
urb->transfer_buffer_length,
DMA_FROM_DEVICE);
Patches currently in stable-queue which might be from hzpeterchen(a)gmail.com are
queue-4.14/usb-host-ehci-use-correct-device-pointer-for-dma-ops.patch
This is a note to let you know that I've just added the patch titled
usb: ldusb: add PIDs for new CASSY devices supported by this driver
to the 4.14-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-ldusb-add-pids-for-new-cassy-devices-supported-by-this-driver.patch
and it can be found in the queue-4.14 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 52ad2bd8918158266fc88a05f95429b56b6a33c5 Mon Sep 17 00:00:00 2001
From: Karsten Koop <kkoop(a)ld-didactic.de>
Date: Fri, 9 Feb 2018 09:12:06 +0000
Subject: usb: ldusb: add PIDs for new CASSY devices supported by this driver
From: Karsten Koop <kkoop(a)ld-didactic.de>
commit 52ad2bd8918158266fc88a05f95429b56b6a33c5 upstream.
This patch adds support for new CASSY devices to the ldusb driver. The
PIDs are also added to the ignore list in hid-quirks.
Signed-off-by: Karsten Koop <kkoop(a)ld-didactic.de>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-core.c | 3 +++
drivers/hid/hid-ids.h | 3 +++
drivers/usb/misc/ldusb.c | 6 ++++++
3 files changed, 12 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2716,6 +2716,9 @@ static const struct hid_device_id hid_ig
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTIME) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYPH) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_POWERANALYSERCASSY) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MACHINETESTCASSY) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_JWM) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_DMMP) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_UMIP) },
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -634,6 +634,9 @@
#define USB_DEVICE_ID_LD_MICROCASSYTIME 0x1033
#define USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE 0x1035
#define USB_DEVICE_ID_LD_MICROCASSYPH 0x1038
+#define USB_DEVICE_ID_LD_POWERANALYSERCASSY 0x1040
+#define USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY 0x1042
+#define USB_DEVICE_ID_LD_MACHINETESTCASSY 0x1043
#define USB_DEVICE_ID_LD_JWM 0x1080
#define USB_DEVICE_ID_LD_DMMP 0x1081
#define USB_DEVICE_ID_LD_UMIP 0x1090
--- a/drivers/usb/misc/ldusb.c
+++ b/drivers/usb/misc/ldusb.c
@@ -46,6 +46,9 @@
#define USB_DEVICE_ID_LD_MICROCASSYTIME 0x1033 /* USB Product ID of Micro-CASSY Time (reserved) */
#define USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE 0x1035 /* USB Product ID of Micro-CASSY Temperature */
#define USB_DEVICE_ID_LD_MICROCASSYPH 0x1038 /* USB Product ID of Micro-CASSY pH */
+#define USB_DEVICE_ID_LD_POWERANALYSERCASSY 0x1040 /* USB Product ID of Power Analyser CASSY */
+#define USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY 0x1042 /* USB Product ID of Converter Controller CASSY */
+#define USB_DEVICE_ID_LD_MACHINETESTCASSY 0x1043 /* USB Product ID of Machine Test CASSY */
#define USB_DEVICE_ID_LD_JWM 0x1080 /* USB Product ID of Joule and Wattmeter */
#define USB_DEVICE_ID_LD_DMMP 0x1081 /* USB Product ID of Digital Multimeter P (reserved) */
#define USB_DEVICE_ID_LD_UMIP 0x1090 /* USB Product ID of UMI P */
@@ -88,6 +91,9 @@ static const struct usb_device_id ld_usb
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTIME) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYPH) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_POWERANALYSERCASSY) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MACHINETESTCASSY) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_JWM) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_DMMP) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_UMIP) },
Patches currently in stable-queue which might be from kkoop(a)ld-didactic.de are
queue-4.14/usb-ldusb-add-pids-for-new-cassy-devices-supported-by-this-driver.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Use config_ep_by_speed()
to the 4.14-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-f_fs-use-config_ep_by_speed.patch
and it can be found in the queue-4.14 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 675272d092e4a5570bace92593776f7348daf4c5 Mon Sep 17 00:00:00 2001
From: Jack Pham <jackp(a)codeaurora.org>
Date: Wed, 24 Jan 2018 23:58:20 -0800
Subject: usb: gadget: f_fs: Use config_ep_by_speed()
From: Jack Pham <jackp(a)codeaurora.org>
commit 675272d092e4a5570bace92593776f7348daf4c5 upstream.
In commit 2bfa0719ac2a ("usb: gadget: function: f_fs: pass
companion descriptor along") there is a pointer arithmetic
bug where the comp_desc is obtained as follows:
comp_desc = (struct usb_ss_ep_comp_descriptor *)(ds +
USB_DT_ENDPOINT_SIZE);
Since ds is a pointer to usb_endpoint_descriptor, adding
7 to it ends up going out of bounds (7 * sizeof(struct
usb_endpoint_descriptor), which is actually 7*9 bytes) past
the SS descriptor. As a result the maxburst value will be
read incorrectly, and the UDC driver will also get a garbage
comp_desc (assuming it uses it).
Since Felipe wrote, "Eventually, f_fs.c should be converted
to use config_ep_by_speed() like all other functions, though",
let's finally do it. This allows the other usb_ep fields to
be properly populated, such as maxpacket and mult. It also
eliminates the awkward speed-based descriptor lookup since
config_ep_by_speed() does that already using the ones found
in struct usb_function.
Fixes: 2bfa0719ac2a ("usb: gadget: function: f_fs: pass companion descriptor along")
Cc: stable(a)vger.kernel.org
Signed-off-by: Jack Pham <jackp(a)codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/function/f_fs.c | 38 ++++++-------------------------------
1 file changed, 7 insertions(+), 31 deletions(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1856,44 +1856,20 @@ static int ffs_func_eps_enable(struct ff
spin_lock_irqsave(&func->ffs->eps_lock, flags);
while(count--) {
- struct usb_endpoint_descriptor *ds;
- struct usb_ss_ep_comp_descriptor *comp_desc = NULL;
- int needs_comp_desc = false;
- int desc_idx;
-
- if (ffs->gadget->speed == USB_SPEED_SUPER) {
- desc_idx = 2;
- needs_comp_desc = true;
- } else if (ffs->gadget->speed == USB_SPEED_HIGH)
- desc_idx = 1;
- else
- desc_idx = 0;
-
- /* fall-back to lower speed if desc missing for current speed */
- do {
- ds = ep->descs[desc_idx];
- } while (!ds && --desc_idx >= 0);
-
- if (!ds) {
- ret = -EINVAL;
- break;
- }
-
ep->ep->driver_data = ep;
- ep->ep->desc = ds;
- if (needs_comp_desc) {
- comp_desc = (struct usb_ss_ep_comp_descriptor *)(ds +
- USB_DT_ENDPOINT_SIZE);
- ep->ep->maxburst = comp_desc->bMaxBurst + 1;
- ep->ep->comp_desc = comp_desc;
+ ret = config_ep_by_speed(func->gadget, &func->function, ep->ep);
+ if (ret) {
+ pr_err("%s: config_ep_by_speed(%s) returned %d\n",
+ __func__, ep->ep->name, ret);
+ break;
}
ret = usb_ep_enable(ep->ep);
if (likely(!ret)) {
epfile->ep = ep;
- epfile->in = usb_endpoint_dir_in(ds);
- epfile->isoc = usb_endpoint_xfer_isoc(ds);
+ epfile->in = usb_endpoint_dir_in(ep->ep->desc);
+ epfile->isoc = usb_endpoint_xfer_isoc(ep->ep->desc);
} else {
break;
}
Patches currently in stable-queue which might be from jackp(a)codeaurora.org are
queue-4.14/usb-gadget-f_fs-use-config_ep_by_speed.patch
queue-4.14/usb-gadget-f_fs-process-all-descriptors-during-bind.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Process all descriptors during bind
to the 4.14-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-f_fs-process-all-descriptors-during-bind.patch
and it can be found in the queue-4.14 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 6cf439e0d37463e42784271179c8a308fd7493c6 Mon Sep 17 00:00:00 2001
From: Jack Pham <jackp(a)codeaurora.org>
Date: Wed, 24 Jan 2018 00:11:53 -0800
Subject: usb: gadget: f_fs: Process all descriptors during bind
From: Jack Pham <jackp(a)codeaurora.org>
commit 6cf439e0d37463e42784271179c8a308fd7493c6 upstream.
During _ffs_func_bind(), the received descriptors are evaluated
to prepare for binding with the gadget in order to allocate
endpoints and optionally set up OS descriptors. However, the
high- and super-speed descriptors are only parsed based on
whether the gadget_is_dualspeed() and gadget_is_superspeed()
calls are true, respectively.
This is a problem in case a userspace program always provides
all of the {full,high,super,OS} descriptors when configuring a
function. Then, for example if a gadget device is not capable
of SuperSpeed, the call to ffs_do_descs() for the SS descriptors
is skipped, resulting in an incorrect offset calculation for
the vla_ptr when moving on to the OS descriptors that follow.
This causes ffs_do_os_descs() to fail as it is now looking at
the SS descriptors' offset within the raw_descs buffer instead.
_ffs_func_bind() should evaluate the descriptors unconditionally,
so remove the checks for gadget speed.
Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support")
Cc: stable(a)vger.kernel.org
Co-Developed-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Jack Pham <jackp(a)codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/function/f_fs.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2980,10 +2980,8 @@ static int _ffs_func_bind(struct usb_con
struct ffs_data *ffs = func->ffs;
const int full = !!func->ffs->fs_descs_count;
- const int high = gadget_is_dualspeed(func->gadget) &&
- func->ffs->hs_descs_count;
- const int super = gadget_is_superspeed(func->gadget) &&
- func->ffs->ss_descs_count;
+ const int high = !!func->ffs->hs_descs_count;
+ const int super = !!func->ffs->ss_descs_count;
int fs_len, hs_len, ss_len, ret, i;
struct ffs_ep *eps_ptr;
Patches currently in stable-queue which might be from jackp(a)codeaurora.org are
queue-4.14/usb-gadget-f_fs-use-config_ep_by_speed.patch
queue-4.14/usb-gadget-f_fs-process-all-descriptors-during-bind.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: ep0: Reset TRB counter for ep0 IN
to the 4.14-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-ep0-reset-trb-counter-for-ep0-in.patch
and it can be found in the queue-4.14 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 f035d139ffece7b6a7b8bfb17bd0ba715ee57a04 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 12 Jan 2018 18:18:27 -0800
Subject: usb: dwc3: ep0: Reset TRB counter for ep0 IN
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
commit f035d139ffece7b6a7b8bfb17bd0ba715ee57a04 upstream.
DWC3 tracks TRB counter for each ep0 direction separately. In control
read transfer completion handler, the driver needs to reset the TRB
enqueue counter for ep0 IN direction. Currently the driver only resets
the TRB counter for control OUT endpoint. Check for the data direction
and properly reset the TRB counter from correct control endpoint.
Cc: stable(a)vger.kernel.org
Fixes: c2da2ff00606 ("usb: dwc3: ep0: don't use ep0in for transfers")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc3/ep0.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -884,7 +884,12 @@ static void dwc3_ep0_complete_data(struc
trb++;
trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
trace_dwc3_complete_trb(ep0, trb);
- ep0->trb_enqueue = 0;
+
+ if (r->direction)
+ dwc->eps[1]->trb_enqueue = 0;
+ else
+ dwc->eps[0]->trb_enqueue = 0;
+
dwc->ep0_bounced = false;
}
Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are
queue-4.14/usb-dwc3-ep0-reset-trb-counter-for-ep0-in.patch
queue-4.14/usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: gadget: Set maxpacket size for ep0 IN
to the 4.14-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-gadget-set-maxpacket-size-for-ep0-in.patch
and it can be found in the queue-4.14 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 6180026341e852a250e1f97ebdcf71684a3c81b9 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 12 Jan 2018 18:18:05 -0800
Subject: usb: dwc3: gadget: Set maxpacket size for ep0 IN
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
commit 6180026341e852a250e1f97ebdcf71684a3c81b9 upstream.
There are 2 control endpoint structures for DWC3. However, the driver
only updates the OUT direction control endpoint structure during
ConnectDone event. DWC3 driver needs to update the endpoint max packet
size for control IN endpoint as well. If the max packet size is not
properly set, then the driver will incorrectly calculate the data
transfer size and fail to send ZLP for HS/FS 3-stage control read
transfer.
The fix is simply to update the max packet size for the ep0 IN direction
during ConnectDone event.
Cc: stable(a)vger.kernel.org
Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc3/gadget.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2774,6 +2774,8 @@ static void dwc3_gadget_conndone_interru
break;
}
+ dwc->eps[1]->endpoint.maxpacket = dwc->gadget.ep0->maxpacket;
+
/* Enable USB2 LPM Capability */
if ((dwc->revision > DWC3_REVISION_194A) &&
Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are
queue-4.14/usb-dwc3-ep0-reset-trb-counter-for-ep0-in.patch
queue-4.14/usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch
This is a note to let you know that I've just added the patch titled
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
to the 4.14-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-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch
and it can be found in the queue-4.14 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 c39813652700f3df552b6557530f1e5f782dbe2f Mon Sep 17 00:00:00 2001
From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
Date: Tue, 23 Jan 2018 20:11:32 -0600
Subject: scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
commit c39813652700f3df552b6557530f1e5f782dbe2f upstream.
The fcp_rsp_info structure as defined in the FC spec has an initial 3
bytes reserved field. The ibmvfc driver mistakenly defined this field as
4 bytes resulting in the rsp_code field being defined in what should be
the start of the second reserved field and thus always being reported as
zero by the driver.
Ideally, we should wire ibmvfc up with libfc for the sake of code
deduplication, and ease of maintaining standardized structures in a
single place. However, for now simply fixup the definition in ibmvfc for
backporting to distros on older kernels. Wiring up with libfc will be
done in a followup patch.
Cc: <stable(a)vger.kernel.org>
Reported-by: Hannes Reinecke <hare(a)suse.de>
Signed-off-by: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/ibmvscsi/ibmvfc.h
+++ b/drivers/scsi/ibmvscsi/ibmvfc.h
@@ -367,7 +367,7 @@ enum ibmvfc_fcp_rsp_info_codes {
};
struct ibmvfc_fcp_rsp_info {
- __be16 reserved;
+ u8 reserved[3];
u8 rsp_code;
u8 reserved2[4];
}__attribute__((packed, aligned (2)));
Patches currently in stable-queue which might be from tyreld(a)linux.vnet.ibm.com are
queue-4.14/scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch
This is a note to let you know that I've just added the patch titled
Revert "usb: musb: host: don't start next rx urb if current one failed"
to the 4.14-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:
revert-usb-musb-host-don-t-start-next-rx-urb-if-current-one-failed.patch
and it can be found in the queue-4.14 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 44eb5e12b845cc8a0634f21b70ef07d774eb4b25 Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu(a)ti.com>
Date: Tue, 20 Feb 2018 07:31:35 -0600
Subject: Revert "usb: musb: host: don't start next rx urb if current one failed"
From: Bin Liu <b-liu(a)ti.com>
commit 44eb5e12b845cc8a0634f21b70ef07d774eb4b25 upstream.
This reverts commit dbac5d07d13e330e6706813c9fde477140fb5d80.
commit dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one failed")
along with commit b5801212229f ("usb: musb: host: clear rxcsr error bit if set")
try to solve the issue described in [1], but the latter alone is
sufficient, and the former causes the issue as in [2], so now revert it.
[1] https://marc.info/?l=linux-usb&m=146173995117456&w=2
[2] https://marc.info/?l=linux-usb&m=151689238420622&w=2
Cc: stable(a)vger.kernel.org # v4.7+
Signed-off-by: Bin Liu <b-liu(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/musb/musb_host.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -418,13 +418,7 @@ static void musb_advance_schedule(struct
}
}
- /*
- * The pipe must be broken if current urb->status is set, so don't
- * start next urb.
- * TODO: to minimize the risk of regression, only check urb->status
- * for RX, until we have a test case to understand the behavior of TX.
- */
- if ((!status || !is_in) && qh && qh->is_ready) {
+ if (qh != NULL && qh->is_ready) {
musb_dbg(musb, "... next ep%d %cX urb %p",
hw_ep->epnum, is_in ? 'R' : 'T', next_urb(qh));
musb_start_urb(musb, is_in, qh);
Patches currently in stable-queue which might be from b-liu(a)ti.com are
queue-4.14/revert-usb-musb-host-don-t-start-next-rx-urb-if-current-one-failed.patch
This is a note to let you know that I've just added the patch titled
RDMA/uverbs: Protect from races between lookup and destroy of uobjects
to the 4.14-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:
rdma-uverbs-protect-from-races-between-lookup-and-destroy-of-uobjects.patch
and it can be found in the queue-4.14 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 6623e3e3cd78020016d3fa42555763178e94ab64 Mon Sep 17 00:00:00 2001
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Tue, 13 Feb 2018 12:18:37 +0200
Subject: RDMA/uverbs: Protect from races between lookup and destroy of uobjects
From: Leon Romanovsky <leonro(a)mellanox.com>
commit 6623e3e3cd78020016d3fa42555763178e94ab64 upstream.
The race is between lookup_get_idr_uobject and
uverbs_idr_remove_uobj -> uverbs_uobject_put.
We deliberately do not call sychronize_rcu after the idr_remove in
uverbs_idr_remove_uobj for performance reasons, instead we call
kfree_rcu() during uverbs_uobject_put.
However, this means we can obtain pointers to uobj's that have
already been released and must protect against krefing them
using kref_get_unless_zero.
==================================================================
BUG: KASAN: use-after-free in copy_ah_attr_from_uverbs.isra.2+0x860/0xa00
Read of size 4 at addr ffff88005fda1ac8 by task syz-executor2/441
CPU: 1 PID: 441 Comm: syz-executor2 Not tainted 4.15.0-rc2+ #56
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
Call Trace:
dump_stack+0x8d/0xd4
print_address_description+0x73/0x290
kasan_report+0x25c/0x370
? copy_ah_attr_from_uverbs.isra.2+0x860/0xa00
copy_ah_attr_from_uverbs.isra.2+0x860/0xa00
? uverbs_try_lock_object+0x68/0xc0
? modify_qp.isra.7+0xdc4/0x10e0
modify_qp.isra.7+0xdc4/0x10e0
ib_uverbs_modify_qp+0xfe/0x170
? ib_uverbs_query_qp+0x970/0x970
? __lock_acquire+0xa11/0x1da0
ib_uverbs_write+0x55a/0xad0
? ib_uverbs_query_qp+0x970/0x970
? ib_uverbs_query_qp+0x970/0x970
? ib_uverbs_open+0x760/0x760
? futex_wake+0x147/0x410
? sched_clock_cpu+0x18/0x180
? check_prev_add+0x1680/0x1680
? do_futex+0x3b6/0xa30
? sched_clock_cpu+0x18/0x180
__vfs_write+0xf7/0x5c0
? ib_uverbs_open+0x760/0x760
? kernel_read+0x110/0x110
? lock_acquire+0x370/0x370
? __fget+0x264/0x3b0
vfs_write+0x18a/0x460
SyS_write+0xc7/0x1a0
? SyS_read+0x1a0/0x1a0
? trace_hardirqs_on_thunk+0x1a/0x1c
entry_SYSCALL_64_fastpath+0x18/0x85
RIP: 0033:0x448e29
RSP: 002b:00007f443fee0c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f443fee16bc RCX: 0000000000448e29
RDX: 0000000000000078 RSI: 00000000209f8000 RDI: 0000000000000012
RBP: 000000000070bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000008e98 R14: 00000000006ebf38 R15: 0000000000000000
Allocated by task 1:
kmem_cache_alloc_trace+0x16c/0x2f0
mlx5_alloc_cmd_msg+0x12e/0x670
cmd_exec+0x419/0x1810
mlx5_cmd_exec+0x40/0x70
mlx5_core_mad_ifc+0x187/0x220
mlx5_MAD_IFC+0xd7/0x1b0
mlx5_query_mad_ifc_gids+0x1f3/0x650
mlx5_ib_query_gid+0xa4/0xc0
ib_query_gid+0x152/0x1a0
ib_query_port+0x21e/0x290
mlx5_port_immutable+0x30f/0x490
ib_register_device+0x5dd/0x1130
mlx5_ib_add+0x3e7/0x700
mlx5_add_device+0x124/0x510
mlx5_register_interface+0x11f/0x1c0
mlx5_ib_init+0x56/0x61
do_one_initcall+0xa3/0x250
kernel_init_freeable+0x309/0x3b8
kernel_init+0x14/0x180
ret_from_fork+0x24/0x30
Freed by task 1:
kfree+0xeb/0x2f0
mlx5_free_cmd_msg+0xcd/0x140
cmd_exec+0xeba/0x1810
mlx5_cmd_exec+0x40/0x70
mlx5_core_mad_ifc+0x187/0x220
mlx5_MAD_IFC+0xd7/0x1b0
mlx5_query_mad_ifc_gids+0x1f3/0x650
mlx5_ib_query_gid+0xa4/0xc0
ib_query_gid+0x152/0x1a0
ib_query_port+0x21e/0x290
mlx5_port_immutable+0x30f/0x490
ib_register_device+0x5dd/0x1130
mlx5_ib_add+0x3e7/0x700
mlx5_add_device+0x124/0x510
mlx5_register_interface+0x11f/0x1c0
mlx5_ib_init+0x56/0x61
do_one_initcall+0xa3/0x250
kernel_init_freeable+0x309/0x3b8
kernel_init+0x14/0x180
ret_from_fork+0x24/0x30
The buggy address belongs to the object at ffff88005fda1ab0
which belongs to the cache kmalloc-32 of size 32
The buggy address is located 24 bytes inside of
32-byte region [ffff88005fda1ab0, ffff88005fda1ad0)
The buggy address belongs to the page:
page:00000000d5655c19 count:1 mapcount:0 mapping: (null)
index:0xffff88005fda1fc0
flags: 0x4000000000000100(slab)
raw: 4000000000000100 0000000000000000 ffff88005fda1fc0 0000000180550008
raw: ffffea00017f6780 0000000400000004 ffff88006c803980 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88005fda1980: fc fc fb fb fb fb fc fc fb fb fb fb fc fc fb fb
ffff88005fda1a00: fb fb fc fc fb fb fb fb fc fc 00 00 00 00 fc fc
ffff88005fda1a80: fb fb fb fb fc fc fb fb fb fb fc fc fb fb fb fb
ffff88005fda1b00: fc fc 00 00 00 00 fc fc fb fb fb fb fc fc fb fb
ffff88005fda1b80: fb fb fc fc fb fb fb fb fc fc fb fb fb fb fc fc
==================================================================@
Cc: syzkaller <syzkaller(a)googlegroups.com>
Cc: <stable(a)vger.kernel.org> # 4.11
Fixes: 3832125624b7 ("IB/core: Add support for idr types")
Reported-by: Noa Osherovich <noaos(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/rdma_core.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/infiniband/core/rdma_core.c
+++ b/drivers/infiniband/core/rdma_core.c
@@ -196,7 +196,15 @@ static struct ib_uobject *lookup_get_idr
goto free;
}
- uverbs_uobject_get(uobj);
+ /*
+ * The idr_find is guaranteed to return a pointer to something that
+ * isn't freed yet, or NULL, as the free after idr_remove goes through
+ * kfree_rcu(). However the object may still have been released and
+ * kfree() could be called at any time.
+ */
+ if (!kref_get_unless_zero(&uobj->ref))
+ uobj = ERR_PTR(-ENOENT);
+
free:
rcu_read_unlock();
return uobj;
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.14/rdma-uverbs-fix-bad-unlock-balance-in-ib_uverbs_close_xrcd.patch
queue-4.14/rdma-uverbs-fix-circular-locking-dependency.patch
queue-4.14/rdma-uverbs-sanitize-user-entered-port-numbers-prior-to-access-it.patch
queue-4.14/rdma-uverbs-protect-from-races-between-lookup-and-destroy-of-uobjects.patch
queue-4.14/rdma-uverbs-protect-from-command-mask-overflow.patch
This is a note to let you know that I've just added the patch titled
RDMA/uverbs: Protect from command mask overflow
to the 4.14-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:
rdma-uverbs-protect-from-command-mask-overflow.patch
and it can be found in the queue-4.14 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 3f802b162dbf4a558ff98986449eddc717826209 Mon Sep 17 00:00:00 2001
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Tue, 13 Feb 2018 12:18:41 +0200
Subject: RDMA/uverbs: Protect from command mask overflow
From: Leon Romanovsky <leonro(a)mellanox.com>
commit 3f802b162dbf4a558ff98986449eddc717826209 upstream.
The command number is not bounds checked against the command mask before it
is shifted, resulting in an ubsan hit. This does not cause malfunction since
the command number is eventually bounds checked, but we can make this ubsan
clean by moving the bounds check to before the mask check.
================================================================================
UBSAN: Undefined behaviour in
drivers/infiniband/core/uverbs_main.c:647:21
shift exponent 207 is too large for 64-bit type 'long long unsigned int'
CPU: 0 PID: 446 Comm: syz-executor3 Not tainted 4.15.0-rc2+ #61
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
Call Trace:
dump_stack+0xde/0x164
? dma_virt_map_sg+0x22c/0x22c
ubsan_epilogue+0xe/0x81
__ubsan_handle_shift_out_of_bounds+0x293/0x2f7
? debug_check_no_locks_freed+0x340/0x340
? __ubsan_handle_load_invalid_value+0x19b/0x19b
? lock_acquire+0x440/0x440
? lock_acquire+0x19d/0x440
? __might_fault+0xf4/0x240
? ib_uverbs_write+0x68d/0xe20
ib_uverbs_write+0x68d/0xe20
? __lock_acquire+0xcf7/0x3940
? uverbs_devnode+0x110/0x110
? cyc2ns_read_end+0x10/0x10
? sched_clock_cpu+0x18/0x200
? sched_clock_cpu+0x18/0x200
__vfs_write+0x10d/0x700
? uverbs_devnode+0x110/0x110
? kernel_read+0x170/0x170
? __fget+0x35b/0x5d0
? security_file_permission+0x93/0x260
vfs_write+0x1b0/0x550
SyS_write+0xc7/0x1a0
? SyS_read+0x1a0/0x1a0
? trace_hardirqs_on_thunk+0x1a/0x1c
entry_SYSCALL_64_fastpath+0x18/0x85
RIP: 0033:0x448e29
RSP: 002b:00007f033f567c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f033f5686bc RCX: 0000000000448e29
RDX: 0000000000000060 RSI: 0000000020001000 RDI: 0000000000000012
RBP: 000000000070bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000056a0 R14: 00000000006e8740 R15: 0000000000000000
================================================================================
Cc: syzkaller <syzkaller(a)googlegroups.com>
Cc: <stable(a)vger.kernel.org> # 4.5
Fixes: 2dbd5186a39c ("IB/core: IB/core: Allow legacy verbs through extended interfaces")
Reported-by: Noa Osherovich <noaos(a)mellanox.com>
Reviewed-by: Matan Barak <matanb(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/uverbs_main.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)
--- a/drivers/infiniband/core/uverbs_main.c
+++ b/drivers/infiniband/core/uverbs_main.c
@@ -647,12 +647,21 @@ static int verify_command_mask(struct ib
return -1;
}
+static bool verify_command_idx(u32 command, bool extended)
+{
+ if (extended)
+ return command < ARRAY_SIZE(uverbs_ex_cmd_table);
+
+ return command < ARRAY_SIZE(uverbs_cmd_table);
+}
+
static ssize_t ib_uverbs_write(struct file *filp, const char __user *buf,
size_t count, loff_t *pos)
{
struct ib_uverbs_file *file = filp->private_data;
struct ib_device *ib_dev;
struct ib_uverbs_cmd_hdr hdr;
+ bool extended_command;
__u32 command;
__u32 flags;
int srcu_key;
@@ -685,6 +694,15 @@ static ssize_t ib_uverbs_write(struct fi
}
command = hdr.command & IB_USER_VERBS_CMD_COMMAND_MASK;
+ flags = (hdr.command &
+ IB_USER_VERBS_CMD_FLAGS_MASK) >> IB_USER_VERBS_CMD_FLAGS_SHIFT;
+
+ extended_command = flags & IB_USER_VERBS_CMD_FLAG_EXTENDED;
+ if (!verify_command_idx(command, extended_command)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
if (verify_command_mask(ib_dev, command)) {
ret = -EOPNOTSUPP;
goto out;
@@ -696,12 +714,8 @@ static ssize_t ib_uverbs_write(struct fi
goto out;
}
- flags = (hdr.command &
- IB_USER_VERBS_CMD_FLAGS_MASK) >> IB_USER_VERBS_CMD_FLAGS_SHIFT;
-
if (!flags) {
- if (command >= ARRAY_SIZE(uverbs_cmd_table) ||
- !uverbs_cmd_table[command]) {
+ if (!uverbs_cmd_table[command]) {
ret = -EINVAL;
goto out;
}
@@ -722,8 +736,7 @@ static ssize_t ib_uverbs_write(struct fi
struct ib_udata uhw;
size_t written_count = count;
- if (command >= ARRAY_SIZE(uverbs_ex_cmd_table) ||
- !uverbs_ex_cmd_table[command]) {
+ if (!uverbs_ex_cmd_table[command]) {
ret = -ENOSYS;
goto out;
}
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.14/rdma-uverbs-fix-bad-unlock-balance-in-ib_uverbs_close_xrcd.patch
queue-4.14/rdma-uverbs-fix-circular-locking-dependency.patch
queue-4.14/rdma-uverbs-sanitize-user-entered-port-numbers-prior-to-access-it.patch
queue-4.14/rdma-uverbs-protect-from-races-between-lookup-and-destroy-of-uobjects.patch
queue-4.14/rdma-uverbs-protect-from-command-mask-overflow.patch
This is a note to let you know that I've just added the patch titled
RDMA/uverbs: Fix bad unlock balance in ib_uverbs_close_xrcd
to the 4.14-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:
rdma-uverbs-fix-bad-unlock-balance-in-ib_uverbs_close_xrcd.patch
and it can be found in the queue-4.14 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 5c2e1c4f926856717f3fd31932e926dc3fe77ebd Mon Sep 17 00:00:00 2001
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Wed, 14 Feb 2018 12:35:38 +0200
Subject: RDMA/uverbs: Fix bad unlock balance in ib_uverbs_close_xrcd
From: Leon Romanovsky <leonro(a)mellanox.com>
commit 5c2e1c4f926856717f3fd31932e926dc3fe77ebd upstream.
There is no matching lock for this mutex. Git history suggests this is
just a missed remnant from an earlier version of the function before
this locking was moved into uverbs_free_xrcd.
Originally this lock was protecting the xrcd_table_delete()
=====================================
WARNING: bad unlock balance detected!
4.15.0+ #87 Not tainted
-------------------------------------
syzkaller223405/269 is trying to release lock (&uverbs_dev->xrcd_tree_mutex) at:
[<00000000b8703372>] ib_uverbs_close_xrcd+0x195/0x1f0
but there are no more locks to release!
other info that might help us debug this:
1 lock held by syzkaller223405/269:
#0: (&uverbs_dev->disassociate_srcu){....}, at: [<000000005af3b960>] ib_uverbs_write+0x265/0xef0
stack backtrace:
CPU: 0 PID: 269 Comm: syzkaller223405 Not tainted 4.15.0+ #87
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
Call Trace:
dump_stack+0xde/0x164
? dma_virt_map_sg+0x22c/0x22c
? ib_uverbs_write+0x265/0xef0
? console_unlock+0x502/0xbd0
? ib_uverbs_close_xrcd+0x195/0x1f0
print_unlock_imbalance_bug+0x131/0x160
lock_release+0x59d/0x1100
? ib_uverbs_close_xrcd+0x195/0x1f0
? lock_acquire+0x440/0x440
? lock_acquire+0x440/0x440
__mutex_unlock_slowpath+0x88/0x670
? wait_for_completion+0x4c0/0x4c0
? rdma_lookup_get_uobject+0x145/0x2f0
ib_uverbs_close_xrcd+0x195/0x1f0
? ib_uverbs_open_xrcd+0xdd0/0xdd0
ib_uverbs_write+0x7f9/0xef0
? cyc2ns_read_end+0x10/0x10
? ib_uverbs_open_xrcd+0xdd0/0xdd0
? uverbs_devnode+0x110/0x110
? cyc2ns_read_end+0x10/0x10
? cyc2ns_read_end+0x10/0x10
? sched_clock_cpu+0x18/0x200
__vfs_write+0x10d/0x700
? uverbs_devnode+0x110/0x110
? kernel_read+0x170/0x170
? __fget+0x358/0x5d0
? security_file_permission+0x93/0x260
vfs_write+0x1b0/0x550
SyS_write+0xc7/0x1a0
? SyS_read+0x1a0/0x1a0
? trace_hardirqs_on_thunk+0x1a/0x1c
entry_SYSCALL_64_fastpath+0x1e/0x8b
RIP: 0033:0x4335c9
Cc: syzkaller <syzkaller(a)googlegroups.com>
Cc: <stable(a)vger.kernel.org> # 4.11
Fixes: fd3c7904db6e ("IB/core: Change idr objects to use the new schema")
Reported-by: Noa Osherovich <noaos(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/uverbs_cmd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -606,10 +606,8 @@ ssize_t ib_uverbs_close_xrcd(struct ib_u
uobj = uobj_get_write(uobj_get_type(xrcd), cmd.xrcd_handle,
file->ucontext);
- if (IS_ERR(uobj)) {
- mutex_unlock(&file->device->xrcd_tree_mutex);
+ if (IS_ERR(uobj))
return PTR_ERR(uobj);
- }
ret = uobj_remove_commit(uobj);
return ret ?: in_len;
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.14/rdma-uverbs-fix-bad-unlock-balance-in-ib_uverbs_close_xrcd.patch
queue-4.14/rdma-uverbs-fix-circular-locking-dependency.patch
queue-4.14/rdma-uverbs-sanitize-user-entered-port-numbers-prior-to-access-it.patch
queue-4.14/rdma-uverbs-protect-from-races-between-lookup-and-destroy-of-uobjects.patch
queue-4.14/rdma-uverbs-protect-from-command-mask-overflow.patch
This is a note to let you know that I've just added the patch titled
PKCS#7: fix certificate chain verification
to the 4.14-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:
pkcs-7-fix-certificate-chain-verification.patch
and it can be found in the queue-4.14 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 971b42c038dc83e3327872d294fe7131bab152fc Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Thu, 22 Feb 2018 14:38:33 +0000
Subject: PKCS#7: fix certificate chain verification
From: Eric Biggers <ebiggers(a)google.com>
commit 971b42c038dc83e3327872d294fe7131bab152fc upstream.
When pkcs7_verify_sig_chain() is building the certificate chain for a
SignerInfo using the certificates in the PKCS#7 message, it is passing
the wrong arguments to public_key_verify_signature(). Consequently,
when the next certificate is supposed to be used to verify the previous
certificate, the next certificate is actually used to verify itself.
An attacker can use this bug to create a bogus certificate chain that
has no cryptographic relationship between the beginning and end.
Fortunately I couldn't quite find a way to use this to bypass the
overall signature verification, though it comes very close. Here's the
reasoning: due to the bug, every certificate in the chain beyond the
first actually has to be self-signed (where "self-signed" here refers to
the actual key and signature; an attacker might still manipulate the
certificate fields such that the self_signed flag doesn't actually get
set, and thus the chain doesn't end immediately). But to pass trust
validation (pkcs7_validate_trust()), either the SignerInfo or one of the
certificates has to actually be signed by a trusted key. Since only
self-signed certificates can be added to the chain, the only way for an
attacker to introduce a trusted signature is to include a self-signed
trusted certificate.
But, when pkcs7_validate_trust_one() reaches that certificate, instead
of trying to verify the signature on that certificate, it will actually
look up the corresponding trusted key, which will succeed, and then try
to verify the *previous* certificate, which will fail. Thus, disaster
is narrowly averted (as far as I could tell).
Fixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier")
Cc: <stable(a)vger.kernel.org> # v4.7+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/asymmetric_keys/pkcs7_verify.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -273,7 +273,7 @@ static int pkcs7_verify_sig_chain(struct
sinfo->index);
return 0;
}
- ret = public_key_verify_signature(p->pub, p->sig);
+ ret = public_key_verify_signature(p->pub, x509->sig);
if (ret < 0)
return ret;
x509->signer = p;
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/pkcs-7-fix-certificate-blacklisting.patch
queue-4.14/x.509-fix-null-dereference-when-restricting-key-with-unsupported_sig.patch
queue-4.14/x.509-fix-bug_on-when-hash-algorithm-is-unsupported.patch
queue-4.14/pkcs-7-fix-certificate-chain-verification.patch
This is a note to let you know that I've just added the patch titled
PCI/cxgb4: Extend T3 PCI quirk to T4+ devices
to the 4.14-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:
pci-cxgb4-extend-t3-pci-quirk-to-t4-devices.patch
and it can be found in the queue-4.14 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 7dcf688d4c78a18ba9538b2bf1b11dc7a43fe9be Mon Sep 17 00:00:00 2001
From: Casey Leedom <leedom(a)chelsio.com>
Date: Thu, 15 Feb 2018 20:03:18 +0530
Subject: PCI/cxgb4: Extend T3 PCI quirk to T4+ devices
From: Casey Leedom <leedom(a)chelsio.com>
commit 7dcf688d4c78a18ba9538b2bf1b11dc7a43fe9be upstream.
We've run into a problem where our device is attached
to a Virtual Machine and the use of the new pci_set_vpd_size()
API doesn't help. The VM kernel has been informed that
the accesses are okay, but all of the actual VPD Capability
Accesses are trapped down into the KVM Hypervisor where it
goes ahead and imposes the silent denials.
The right idea is to follow the kernel.org
commit 1c7de2b4ff88 ("PCI: Enable access to non-standard VPD for
Chelsio devices (cxgb3)") which Alexey Kardashevskiy authored
to establish a PCI Quirk for our T3-based adapters. This commit
extends that PCI Quirk to cover Chelsio T4 devices and later.
The advantage of this approach is that the VPD Size gets set early
in the Base OS/Hypervisor Boot and doesn't require that the cxgb4
driver even be available in the Base OS/Hypervisor. Thus PF4 can
be exported to a Virtual Machine and everything should work.
Fixes: 67e658794ca1 ("cxgb4: Set VPD size so we can read both VPD structures")
Cc: <stable(a)vger.kernel.org> # v4.9+
Signed-off-by: Casey Leedom <leedom(a)chelsio.com>
Signed-off-by: Arjun Vynipadath <arjun(a)chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr(a)chelsio.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 10 --------
drivers/pci/quirks.c | 35 +++++++++++++++++------------
2 files changed, 21 insertions(+), 24 deletions(-)
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -2632,7 +2632,6 @@ void t4_get_regs(struct adapter *adap, v
}
#define EEPROM_STAT_ADDR 0x7bfc
-#define VPD_SIZE 0x800
#define VPD_BASE 0x400
#define VPD_BASE_OLD 0
#define VPD_LEN 1024
@@ -2670,15 +2669,6 @@ int t4_get_raw_vpd_params(struct adapter
if (!vpd)
return -ENOMEM;
- /* We have two VPD data structures stored in the adapter VPD area.
- * By default, Linux calculates the size of the VPD area by traversing
- * the first VPD area at offset 0x0, so we need to tell the OS what
- * our real VPD size is.
- */
- ret = pci_set_vpd_size(adapter->pdev, VPD_SIZE);
- if (ret < 0)
- goto out;
-
/* Card information normally starts at VPD_BASE but early cards had
* it at 0.
*/
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3412,22 +3412,29 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IN
static void quirk_chelsio_extend_vpd(struct pci_dev *dev)
{
- pci_set_vpd_size(dev, 8192);
+ int chip = (dev->device & 0xf000) >> 12;
+ int func = (dev->device & 0x0f00) >> 8;
+ int prod = (dev->device & 0x00ff) >> 0;
+
+ /*
+ * If this is a T3-based adapter, there's a 1KB VPD area at offset
+ * 0xc00 which contains the preferred VPD values. If this is a T4 or
+ * later based adapter, the special VPD is at offset 0x400 for the
+ * Physical Functions (the SR-IOV Virtual Functions have no VPD
+ * Capabilities). The PCI VPD Access core routines will normally
+ * compute the size of the VPD by parsing the VPD Data Structure at
+ * offset 0x000. This will result in silent failures when attempting
+ * to accesses these other VPD areas which are beyond those computed
+ * limits.
+ */
+ if (chip == 0x0 && prod >= 0x20)
+ pci_set_vpd_size(dev, 8192);
+ else if (chip >= 0x4 && func < 0x8)
+ pci_set_vpd_size(dev, 2048);
}
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x20, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x21, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x22, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x23, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x24, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x25, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x26, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x30, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x31, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x32, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x35, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x36, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x37, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
+ quirk_chelsio_extend_vpd);
#ifdef CONFIG_ACPI
/*
Patches currently in stable-queue which might be from leedom(a)chelsio.com are
queue-4.14/pci-cxgb4-extend-t3-pci-quirk-to-t4-devices.patch
This is a note to let you know that I've just added the patch titled
PKCS#7: fix certificate blacklisting
to the 4.14-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:
pkcs-7-fix-certificate-blacklisting.patch
and it can be found in the queue-4.14 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 29f4a67c17e19314b7d74b8569be935e6c7edf50 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Thu, 22 Feb 2018 14:38:33 +0000
Subject: PKCS#7: fix certificate blacklisting
From: Eric Biggers <ebiggers(a)google.com>
commit 29f4a67c17e19314b7d74b8569be935e6c7edf50 upstream.
If there is a blacklisted certificate in a SignerInfo's certificate
chain, then pkcs7_verify_sig_chain() sets sinfo->blacklisted and returns
0. But, pkcs7_verify() fails to handle this case appropriately, as it
actually continues on to the line 'actual_ret = 0;', indicating that the
SignerInfo has passed verification. Consequently, PKCS#7 signature
verification ignores the certificate blacklist.
Fix this by not considering blacklisted SignerInfos to have passed
verification.
Also fix the function comment with regards to when 0 is returned.
Fixes: 03bb79315ddc ("PKCS#7: Handle blacklisted certificates")
Cc: <stable(a)vger.kernel.org> # v4.12+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/asymmetric_keys/pkcs7_verify.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -369,8 +369,7 @@ static int pkcs7_verify_one(struct pkcs7
*
* (*) -EBADMSG if some part of the message was invalid, or:
*
- * (*) 0 if no signature chains were found to be blacklisted or to contain
- * unsupported crypto, or:
+ * (*) 0 if a signature chain passed verification, or:
*
* (*) -EKEYREJECTED if a blacklisted key was encountered, or:
*
@@ -426,8 +425,11 @@ int pkcs7_verify(struct pkcs7_message *p
for (sinfo = pkcs7->signed_infos; sinfo; sinfo = sinfo->next) {
ret = pkcs7_verify_one(pkcs7, sinfo);
- if (sinfo->blacklisted && actual_ret == -ENOPKG)
- actual_ret = -EKEYREJECTED;
+ if (sinfo->blacklisted) {
+ if (actual_ret == -ENOPKG)
+ actual_ret = -EKEYREJECTED;
+ continue;
+ }
if (ret < 0) {
if (ret == -ENOPKG) {
sinfo->unsupported_crypto = true;
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/pkcs-7-fix-certificate-blacklisting.patch
queue-4.14/x.509-fix-null-dereference-when-restricting-key-with-unsupported_sig.patch
queue-4.14/x.509-fix-bug_on-when-hash-algorithm-is-unsupported.patch
queue-4.14/pkcs-7-fix-certificate-chain-verification.patch
This is a note to let you know that I've just added the patch titled
ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()
to the 4.14-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:
ohci-hcd-fix-race-condition-caused-by-ohci_urb_enqueue-and-io_watchdog_func.patch
and it can be found in the queue-4.14 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 b2685bdacdaab065c172b97b55ab46c6be77a037 Mon Sep 17 00:00:00 2001
From: Shigeru Yoshida <shigeru.yoshida(a)windriver.com>
Date: Fri, 2 Feb 2018 13:51:39 +0800
Subject: ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()
From: Shigeru Yoshida <shigeru.yoshida(a)windriver.com>
commit b2685bdacdaab065c172b97b55ab46c6be77a037 upstream.
Running io_watchdog_func() while ohci_urb_enqueue() is running can
cause a race condition where ohci->prev_frame_no is corrupted and the
watchdog can mis-detect following error:
ohci-platform 664a0800.usb: frame counter not updating; disabled
ohci-platform 664a0800.usb: HC died; cleaning up
Specifically, following scenario causes a race condition:
1. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags)
and enters the critical section
2. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it
returns false
3. ohci_urb_enqueue() sets ohci->prev_frame_no to a frame number
read by ohci_frame_no(ohci)
4. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer()
5. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock,
flags) and exits the critical section
6. Later, ohci_urb_enqueue() is called
7. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags)
and enters the critical section
8. The timer scheduled on step 4 expires and io_watchdog_func() runs
9. io_watchdog_func() calls spin_lock_irqsave(&ohci->lock, flags)
and waits on it because ohci_urb_enqueue() is already in the
critical section on step 7
10. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it
returns false
11. ohci_urb_enqueue() sets ohci->prev_frame_no to new frame number
read by ohci_frame_no(ohci) because the frame number proceeded
between step 3 and 6
12. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer()
13. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock,
flags) and exits the critical section, then wake up
io_watchdog_func() which is waiting on step 9
14. io_watchdog_func() enters the critical section
15. io_watchdog_func() calls ohci_frame_no(ohci) and set frame_no
variable to the frame number
16. io_watchdog_func() compares frame_no and ohci->prev_frame_no
On step 16, because this calling of io_watchdog_func() is scheduled on
step 4, the frame number set in ohci->prev_frame_no is expected to the
number set on step 3. However, ohci->prev_frame_no is overwritten on
step 11. Because step 16 is executed soon after step 11, the frame
number might not proceed, so ohci->prev_frame_no must equals to
frame_no.
To address above scenario, this patch introduces a special sentinel
value IO_WATCHDOG_OFF and set this value to ohci->prev_frame_no when
the watchdog is not pending or running. When ohci_urb_enqueue()
schedules the watchdog (step 4 and 12 above), it compares
ohci->prev_frame_no to IO_WATCHDOG_OFF so that ohci->prev_frame_no is
not overwritten while io_watchdog_func() is running.
Signed-off-by: Shigeru Yoshida <Shigeru.Yoshida(a)windriver.com>
Signed-off-by: Haiqing Bai <Haiqing.Bai(a)windriver.com>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/ohci-hcd.c | 10 +++++++---
drivers/usb/host/ohci-hub.c | 4 +++-
2 files changed, 10 insertions(+), 4 deletions(-)
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -73,6 +73,7 @@ static const char hcd_name [] = "ohci_hc
#define STATECHANGE_DELAY msecs_to_jiffies(300)
#define IO_WATCHDOG_DELAY msecs_to_jiffies(275)
+#define IO_WATCHDOG_OFF 0xffffff00
#include "ohci.h"
#include "pci-quirks.h"
@@ -230,7 +231,7 @@ static int ohci_urb_enqueue (
}
/* Start up the I/O watchdog timer, if it's not running */
- if (!timer_pending(&ohci->io_watchdog) &&
+ if (ohci->prev_frame_no == IO_WATCHDOG_OFF &&
list_empty(&ohci->eds_in_use) &&
!(ohci->flags & OHCI_QUIRK_QEMU)) {
ohci->prev_frame_no = ohci_frame_no(ohci);
@@ -501,6 +502,7 @@ static int ohci_init (struct ohci_hcd *o
setup_timer(&ohci->io_watchdog, io_watchdog_func,
(unsigned long) ohci);
+ ohci->prev_frame_no = IO_WATCHDOG_OFF;
ohci->hcca = dma_alloc_coherent (hcd->self.controller,
sizeof(*ohci->hcca), &ohci->hcca_dma, GFP_KERNEL);
@@ -730,7 +732,7 @@ static void io_watchdog_func(unsigned lo
u32 head;
struct ed *ed;
struct td *td, *td_start, *td_next;
- unsigned frame_no;
+ unsigned frame_no, prev_frame_no = IO_WATCHDOG_OFF;
unsigned long flags;
spin_lock_irqsave(&ohci->lock, flags);
@@ -835,7 +837,7 @@ static void io_watchdog_func(unsigned lo
}
}
if (!list_empty(&ohci->eds_in_use)) {
- ohci->prev_frame_no = frame_no;
+ prev_frame_no = frame_no;
ohci->prev_wdh_cnt = ohci->wdh_cnt;
ohci->prev_donehead = ohci_readl(ohci,
&ohci->regs->donehead);
@@ -845,6 +847,7 @@ static void io_watchdog_func(unsigned lo
}
done:
+ ohci->prev_frame_no = prev_frame_no;
spin_unlock_irqrestore(&ohci->lock, flags);
}
@@ -973,6 +976,7 @@ static void ohci_stop (struct usb_hcd *h
if (quirk_nec(ohci))
flush_work(&ohci->nec_work);
del_timer_sync(&ohci->io_watchdog);
+ ohci->prev_frame_no = IO_WATCHDOG_OFF;
ohci_writel (ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
ohci_usb_reset(ohci);
--- a/drivers/usb/host/ohci-hub.c
+++ b/drivers/usb/host/ohci-hub.c
@@ -310,8 +310,10 @@ static int ohci_bus_suspend (struct usb_
rc = ohci_rh_suspend (ohci, 0);
spin_unlock_irq (&ohci->lock);
- if (rc == 0)
+ if (rc == 0) {
del_timer_sync(&ohci->io_watchdog);
+ ohci->prev_frame_no = IO_WATCHDOG_OFF;
+ }
return rc;
}
Patches currently in stable-queue which might be from shigeru.yoshida(a)windriver.com are
queue-4.14/ohci-hcd-fix-race-condition-caused-by-ohci_urb_enqueue-and-io_watchdog_func.patch
This is a note to let you know that I've just added the patch titled
mm, swap, frontswap: fix THP swap if frontswap enabled
to the 4.14-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:
mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled.patch
and it can be found in the queue-4.14 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 7ba716698cc53f8d5367766c93c538c7da6c68ce Mon Sep 17 00:00:00 2001
From: Huang Ying <huang.ying.caritas(a)gmail.com>
Date: Wed, 21 Feb 2018 14:45:39 -0800
Subject: mm, swap, frontswap: fix THP swap if frontswap enabled
From: Huang Ying <huang.ying.caritas(a)gmail.com>
commit 7ba716698cc53f8d5367766c93c538c7da6c68ce upstream.
It was reported by Sergey Senozhatsky that if THP (Transparent Huge
Page) and frontswap (via zswap) are both enabled, when memory goes low
so that swap is triggered, segfault and memory corruption will occur in
random user space applications as follow,
kernel: urxvt[338]: segfault at 20 ip 00007fc08889ae0d sp 00007ffc73a7fc40 error 6 in libc-2.26.so[7fc08881a000+1ae000]
#0 0x00007fc08889ae0d _int_malloc (libc.so.6)
#1 0x00007fc08889c2f3 malloc (libc.so.6)
#2 0x0000560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt)
#3 0x0000560e6005e75c n/a (urxvt)
#4 0x0000560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez (urxvt)
#5 0x0000560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt)
#6 0x0000560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt)
#7 0x0000560e6005c10f _Z17ev_invoke_pendingv (urxvt)
#8 0x0000560e6005cb55 ev_run (urxvt)
#9 0x0000560e6003b9b9 main (urxvt)
#10 0x00007fc08883af4a __libc_start_main (libc.so.6)
#11 0x0000560e6003f9da _start (urxvt)
After bisection, it was found the first bad commit is bd4c82c22c36 ("mm,
THP, swap: delay splitting THP after swapped out").
The root cause is as follows:
When the pages are written to swap device during swapping out in
swap_writepage(), zswap (fontswap) is tried to compress the pages to
improve performance. But zswap (frontswap) will treat THP as a normal
page, so only the head page is saved. After swapping in, tail pages
will not be restored to their original contents, causing memory
corruption in the applications.
This is fixed by refusing to save page in the frontswap store functions
if the page is a THP. So that the THP will be swapped out to swap
device.
Another choice is to split THP if frontswap is enabled. But it is found
that the frontswap enabling isn't flexible. For example, if
CONFIG_ZSWAP=y (cannot be module), frontswap will be enabled even if
zswap itself isn't enabled.
Frontswap has multiple backends, to make it easy for one backend to
enable THP support, the THP checking is put in backend frontswap store
functions instead of the general interfaces.
Link: http://lkml.kernel.org/r/20180209084947.22749-1-ying.huang@intel.com
Fixes: bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped out")
Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com>
Reported-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Tested-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Suggested-by: Minchan Kim <minchan(a)kernel.org> [put THP checking in backend]
Cc: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Cc: Dan Streetman <ddstreet(a)ieee.org>
Cc: Seth Jennings <sjenning(a)redhat.com>
Cc: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Cc: Shaohua Li <shli(a)kernel.org>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Shakeel Butt <shakeelb(a)google.com>
Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Cc: Juergen Gross <jgross(a)suse.com>
Cc: <stable(a)vger.kernel.org> [4.14]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/xen/tmem.c | 4 ++++
mm/zswap.c | 6 ++++++
2 files changed, 10 insertions(+)
--- a/drivers/xen/tmem.c
+++ b/drivers/xen/tmem.c
@@ -284,6 +284,10 @@ static int tmem_frontswap_store(unsigned
int pool = tmem_frontswap_poolid;
int ret;
+ /* THP isn't supported */
+ if (PageTransHuge(page))
+ return -1;
+
if (pool < 0)
return -1;
if (ind64 != ind)
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -970,6 +970,12 @@ static int zswap_frontswap_store(unsigne
u8 *src, *dst;
struct zswap_header *zhdr;
+ /* THP isn't supported */
+ if (PageTransHuge(page)) {
+ ret = -EINVAL;
+ goto reject;
+ }
+
if (!zswap_enabled || !tree) {
ret = -ENODEV;
goto reject;
Patches currently in stable-queue which might be from huang.ying.caritas(a)gmail.com are
queue-4.14/mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled.patch
This is a note to let you know that I've just added the patch titled
MIPS: Drop spurious __unused in struct compat_flock
to the 4.14-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:
mips-drop-spurious-__unused-in-struct-compat_flock.patch
and it can be found in the queue-4.14 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 6ae1756faddefd7494353380ee546dd38c2f97eb Mon Sep 17 00:00:00 2001
From: James Hogan <jhogan(a)kernel.org>
Date: Tue, 20 Feb 2018 15:44:37 +0000
Subject: MIPS: Drop spurious __unused in struct compat_flock
From: James Hogan <jhogan(a)kernel.org>
commit 6ae1756faddefd7494353380ee546dd38c2f97eb upstream.
MIPS' struct compat_flock doesn't match the 32-bit struct flock, as it
has an extra short __unused before pad[4], which combined with alignment
increases the size to 40 bytes compared with struct flock's 36 bytes.
Since commit 8c6657cb50cb ("Switch flock copyin/copyout primitives to
copy_{from,to}_user()"), put_compat_flock() writes the full compat_flock
struct to userland, which results in corruption of the userland word
after the struct flock when running 32-bit userlands on 64-bit kernels.
This was observed to cause a bus error exception when starting Firefox
on Debian 8 (Jessie).
Reported-by: Peter Mamonov <pmamonov(a)gmail.com>
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Tested-by: Peter Mamonov <pmamonov(a)gmail.com>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: linux-mips(a)linux-mips.org
Cc: <stable(a)vger.kernel.org> # 4.13+
Patchwork: https://patchwork.linux-mips.org/patch/18646/
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/include/asm/compat.h | 1 -
1 file changed, 1 deletion(-)
--- a/arch/mips/include/asm/compat.h
+++ b/arch/mips/include/asm/compat.h
@@ -86,7 +86,6 @@ struct compat_flock {
compat_off_t l_len;
s32 l_sysid;
compat_pid_t l_pid;
- short __unused;
s32 pad[4];
};
Patches currently in stable-queue which might be from jhogan(a)kernel.org are
queue-4.14/mips-drop-spurious-__unused-in-struct-compat_flock.patch
This is a note to let you know that I've just added the patch titled
Kbuild: always define endianess in kconfig.h
to the 4.14-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:
kbuild-always-define-endianess-in-kconfig.h.patch
and it can be found in the queue-4.14 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 101110f6271ce956a049250c907bc960030577f8 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 21 Feb 2018 14:45:20 -0800
Subject: Kbuild: always define endianess in kconfig.h
From: Arnd Bergmann <arnd(a)arndb.de>
commit 101110f6271ce956a049250c907bc960030577f8 upstream.
Build testing with LTO found a couple of files that get compiled
differently depending on whether asm/byteorder.h gets included early
enough or not. In particular, include/asm-generic/qrwlock_types.h is
affected by this, but there are probably others as well.
The symptom is a series of LTO link time warnings, including these:
net/netlabel/netlabel_unlabeled.h:223: error: type of 'netlbl_unlhsh_add' does not match original declaration [-Werror=lto-type-mismatch]
int netlbl_unlhsh_add(struct net *net,
net/netlabel/netlabel_unlabeled.c:377: note: 'netlbl_unlhsh_add' was previously declared here
include/net/ipv6.h:360: error: type of 'ipv6_renew_options_kern' does not match original declaration [-Werror=lto-type-mismatch]
ipv6_renew_options_kern(struct sock *sk,
net/ipv6/exthdrs.c:1162: note: 'ipv6_renew_options_kern' was previously declared here
net/core/dev.c:761: note: 'dev_get_by_name_rcu' was previously declared here
struct net_device *dev_get_by_name_rcu(struct net *net, const char *name)
net/core/dev.c:761: note: code may be misoptimized unless -fno-strict-aliasing is used
drivers/gpu/drm/i915/i915_drv.h:3377: error: type of 'i915_gem_object_set_to_wc_domain' does not match original declaration [-Werror=lto-type-mismatch]
i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object *obj, bool write);
drivers/gpu/drm/i915/i915_gem.c:3639: note: 'i915_gem_object_set_to_wc_domain' was previously declared here
include/linux/debugfs.h:92:9: error: type of 'debugfs_attr_read' does not match original declaration [-Werror=lto-type-mismatch]
ssize_t debugfs_attr_read(struct file *file, char __user *buf,
fs/debugfs/file.c:318: note: 'debugfs_attr_read' was previously declared here
include/linux/rwlock_api_smp.h:30: error: type of '_raw_read_unlock' does not match original declaration [-Werror=lto-type-mismatch]
void __lockfunc _raw_read_unlock(rwlock_t *lock) __releases(lock);
kernel/locking/spinlock.c:246:26: note: '_raw_read_unlock' was previously declared here
include/linux/fs.h:3308:5: error: type of 'simple_attr_open' does not match original declaration [-Werror=lto-type-mismatch]
int simple_attr_open(struct inode *inode, struct file *file,
fs/libfs.c:795: note: 'simple_attr_open' was previously declared here
All of the above are caused by include/asm-generic/qrwlock_types.h
failing to include asm/byteorder.h after commit e0d02285f16e
("locking/qrwlock: Use 'struct qrwlock' instead of 'struct __qrwlock'")
in linux-4.15.
Similar bugs may or may not exist in older kernels as well, but there is
no easy way to test those with link-time optimizations, and kernels
before 4.14 are harder to fix because they don't have Babu's patch
series
We had similar issues with CONFIG_ symbols in the past and ended up
always including the configuration headers though linux/kconfig.h. This
works around the issue through that same file, defining either
__BIG_ENDIAN or __LITTLE_ENDIAN depending on CONFIG_CPU_BIG_ENDIAN,
which is now always set on all architectures since commit 4c97a0c8fee3
("arch: define CPU_BIG_ENDIAN for all fixed big endian archs").
Link: http://lkml.kernel.org/r/20180202154104.1522809-2-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Babu Moger <babu.moger(a)amd.com>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Cc: Nicolas Pitre <nico(a)linaro.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/kconfig.h | 6 ++++++
1 file changed, 6 insertions(+)
--- a/include/linux/kconfig.h
+++ b/include/linux/kconfig.h
@@ -4,6 +4,12 @@
#include <generated/autoconf.h>
+#ifdef CONFIG_CPU_BIG_ENDIAN
+#define __BIG_ENDIAN 4321
+#else
+#define __LITTLE_ENDIAN 1234
+#endif
+
#define __ARG_PLACEHOLDER_1 0,
#define __take_second_arg(__ignored, val, ...) val
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-4.14/cfg80211-fix-cfg80211_beacon_dup.patch
queue-4.14/kbuild-always-define-endianess-in-kconfig.h.patch
This is a note to let you know that I've just added the patch titled
irqchip/mips-gic: Avoid spuriously handling masked interrupts
to the 4.14-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:
irqchip-mips-gic-avoid-spuriously-handling-masked-interrupts.patch
and it can be found in the queue-4.14 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 285cb4f62319737e6538252cf1a67ce9da5cf3d5 Mon Sep 17 00:00:00 2001
From: Matt Redfearn <matt.redfearn(a)mips.com>
Date: Mon, 5 Feb 2018 16:45:36 +0000
Subject: irqchip/mips-gic: Avoid spuriously handling masked interrupts
From: Matt Redfearn <matt.redfearn(a)mips.com>
commit 285cb4f62319737e6538252cf1a67ce9da5cf3d5 upstream.
Commit 7778c4b27cbe ("irqchip: mips-gic: Use pcpu_masks to avoid reading
GIC_SH_MASK*") removed the read of the hardware mask register when
handling shared interrupts, instead using the driver's shadow pcpu_masks
entry as the effective mask. Unfortunately this did not take account of
the write to pcpu_masks during gic_shared_irq_domain_map, which
effectively unmasks the interrupt early. If an interrupt is asserted,
gic_handle_shared_int decodes and processes the interrupt even though it
has not yet been unmasked via gic_unmask_irq, which also sets the
appropriate bit in pcpu_masks.
On the MIPS Boston board, when a console command line of
"console=ttyS0,115200n8r" is passed, the modem status IRQ is enabled in
the UART, which is immediately raised to the GIC. The interrupt has been
mapped, but no handler has yet been registered, nor is it expected to be
unmasked. However, the write to pcpu_masks in gic_shared_irq_domain_map
has effectively unmasked it, resulting in endless reports of:
[ 5.058454] irq 13, desc: ffffffff80a7ad80, depth: 1, count: 0, unhandled: 0
[ 5.062057] ->handle_irq(): ffffffff801b1838,
[ 5.062175] handle_bad_irq+0x0/0x2c0
Where IRQ 13 is the UART interrupt.
To fix this, just remove the write to pcpu_masks in
gic_shared_irq_domain_map. The existing write in gic_unmask_irq is the
correct place for what is now the effective unmasking.
Cc: stable(a)vger.kernel.org
Fixes: 7778c4b27cbe ("irqchip: mips-gic: Use pcpu_masks to avoid reading GIC_SH_MASK*")
Signed-off-by: Matt Redfearn <matt.redfearn(a)mips.com>
Reviewed-by: Paul Burton <paul.burton(a)mips.com>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-mips-gic.c | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -427,8 +427,6 @@ static int gic_shared_irq_domain_map(str
spin_lock_irqsave(&gic_lock, flags);
write_gic_map_pin(intr, GIC_MAP_PIN_MAP_TO_PIN | gic_cpu_pin);
write_gic_map_vp(intr, BIT(mips_cm_vp_id(cpu)));
- gic_clear_pcpu_masks(intr);
- set_bit(intr, per_cpu_ptr(pcpu_masks, cpu));
irq_data_update_effective_affinity(data, cpumask_of(cpu));
spin_unlock_irqrestore(&gic_lock, flags);
Patches currently in stable-queue which might be from matt.redfearn(a)mips.com are
queue-4.14/irqchip-mips-gic-avoid-spuriously-handling-masked-interrupts.patch
This is a note to let you know that I've just added the patch titled
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
to the 4.14-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:
irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch
and it can be found in the queue-4.14 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 21ec30c0ef5234fb1039cc7c7737d885bf875a9e Mon Sep 17 00:00:00 2001
From: Shanker Donthineni <shankerd(a)codeaurora.org>
Date: Wed, 31 Jan 2018 18:03:42 -0600
Subject: irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
From: Shanker Donthineni <shankerd(a)codeaurora.org>
commit 21ec30c0ef5234fb1039cc7c7737d885bf875a9e upstream.
A DMB instruction can be used to ensure the relative order of only
memory accesses before and after the barrier. Since writes to system
registers are not memory operations, barrier DMB is not sufficient
for observability of memory accesses that occur before ICC_SGI1R_EL1
writes.
A DSB instruction ensures that no instructions that appear in program
order after the DSB instruction, can execute until the DSB instruction
has completed.
Cc: stable(a)vger.kernel.org
Acked-by: Will Deacon <will.deacon(a)arm.com>,
Signed-off-by: Shanker Donthineni <shankerd(a)codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -660,7 +660,7 @@ static void gic_raise_softirq(const stru
* Ensure that stores to Normal memory are visible to the
* other CPUs before issuing the IPI.
*/
- smp_wmb();
+ wmb();
for_each_cpu(cpu, mask) {
unsigned long cluster_id = cpu_logical_map(cpu) & ~0xffUL;
Patches currently in stable-queue which might be from shankerd(a)codeaurora.org are
queue-4.14/irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch
queue-4.14/arm64-cpufeature-fix-ctr_el0-field-definitions.patch
This is a note to let you know that I've just added the patch titled
iio: srf08: fix link error "devm_iio_triggered_buffer_setup" undefined
to the 4.14-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:
iio-srf08-fix-link-error-devm_iio_triggered_buffer_setup-undefined.patch
and it can be found in the queue-4.14 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 511051d509ec54642dd6d30fdf2caa33c23619cc Mon Sep 17 00:00:00 2001
From: Andreas Klinger <ak(a)it-klinger.de>
Date: Thu, 1 Feb 2018 21:49:24 +0100
Subject: iio: srf08: fix link error "devm_iio_triggered_buffer_setup" undefined
From: Andreas Klinger <ak(a)it-klinger.de>
commit 511051d509ec54642dd6d30fdf2caa33c23619cc upstream.
Functions for triggered buffer support are needed by this module.
If they are not defined accidentally by another driver, there's an error
thrown out while linking.
Add a select of IIO_BUFFER and IIO_TRIGGERED_BUFFER in the Kconfig file.
Signed-off-by: Andreas Klinger <ak(a)it-klinger.de>
Fixes: a83195937151 ("iio: srf08: add triggered buffer support")
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/proximity/Kconfig | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/iio/proximity/Kconfig
+++ b/drivers/iio/proximity/Kconfig
@@ -58,6 +58,8 @@ config SX9500
config SRF08
tristate "Devantech SRF02/SRF08/SRF10 ultrasonic ranger sensor"
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
depends on I2C
help
Say Y here to build a driver for Devantech SRF02/SRF08/SRF10
Patches currently in stable-queue which might be from ak(a)it-klinger.de are
queue-4.14/iio-srf08-fix-link-error-devm_iio_triggered_buffer_setup-undefined.patch
This is a note to let you know that I've just added the patch titled
iio: adis_lib: Initialize trigger before requesting interrupt
to the 4.14-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:
iio-adis_lib-initialize-trigger-before-requesting-interrupt.patch
and it can be found in the queue-4.14 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 f027e0b3a774e10302207e91d304bbf99e3a8b36 Mon Sep 17 00:00:00 2001
From: Lars-Peter Clausen <lars(a)metafoo.de>
Date: Wed, 14 Feb 2018 15:43:00 +0100
Subject: iio: adis_lib: Initialize trigger before requesting interrupt
From: Lars-Peter Clausen <lars(a)metafoo.de>
commit f027e0b3a774e10302207e91d304bbf99e3a8b36 upstream.
The adis_probe_trigger() creates a new IIO trigger and requests an
interrupt associated with the trigger. The interrupt uses the generic
iio_trigger_generic_data_rdy_poll() function as its interrupt handler.
Currently the driver initializes some fields of the trigger structure after
the interrupt has been requested. But an interrupt can fire as soon as it
has been requested. This opens up a race condition.
iio_trigger_generic_data_rdy_poll() will access the trigger data structure
and dereference the ops field. If the ops field is not yet initialized this
will result in a NULL pointer deref.
It is not expected that the device generates an interrupt at this point, so
typically this issue did not surface unless e.g. due to a hardware
misconfiguration (wrong interrupt number, wrong polarity, etc.).
But some newer devices from the ADIS family start to generate periodic
interrupts in their power-on reset configuration and unfortunately the
interrupt can not be masked in the device. This makes the race condition
much more visible and the following crash has been observed occasionally
when booting a system using the ADIS16460.
Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = c0004000
[00000008] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257
Hardware name: Xilinx Zynq Platform
task: ef04f640 task.stack: ef050000
PC is at iio_trigger_notify_done+0x30/0x68
LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20
pc : [<c042d868>] lr : [<c042d924>] psr: 60000193
sp : ef051bb8 ip : 00000000 fp : ef106400
r10: c081d80a r9 : ef3bfa00 r8 : 00000087
r7 : ef051bec r6 : 00000000 r5 : ef3bfa00 r4 : ee92ab00
r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : ee97e400
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 18c5387d Table: 0000404a DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xef050210)
[<c042d868>] (iio_trigger_notify_done) from [<c0065b10>] (__handle_irq_event_percpu+0x88/0x118)
[<c0065b10>] (__handle_irq_event_percpu) from [<c0065bbc>] (handle_irq_event_percpu+0x1c/0x58)
[<c0065bbc>] (handle_irq_event_percpu) from [<c0065c30>] (handle_irq_event+0x38/0x5c)
[<c0065c30>] (handle_irq_event) from [<c0068e28>] (handle_level_irq+0xa4/0x130)
[<c0068e28>] (handle_level_irq) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c021ab7c>] (zynq_gpio_irqhandler+0xb8/0x13c)
[<c021ab7c>] (zynq_gpio_irqhandler) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c0065370>] (__handle_domain_irq+0x5c/0xb4)
[<c0065370>] (__handle_domain_irq) from [<c000940c>] (gic_handle_irq+0x48/0x8c)
[<c000940c>] (gic_handle_irq) from [<c0013e8c>] (__irq_svc+0x6c/0xa8)
To fix this make sure that the trigger is fully initialized before
requesting the interrupt.
Fixes: ccd2b52f4ac6 ("staging:iio: Add common ADIS library")
Reported-by: Robin Getz <Robin.Getz(a)analog.com>
Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de>
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/imu/adis_trigger.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/iio/imu/adis_trigger.c
+++ b/drivers/iio/imu/adis_trigger.c
@@ -47,6 +47,10 @@ int adis_probe_trigger(struct adis *adis
if (adis->trig == NULL)
return -ENOMEM;
+ adis->trig->dev.parent = &adis->spi->dev;
+ adis->trig->ops = &adis_trigger_ops;
+ iio_trigger_set_drvdata(adis->trig, adis);
+
ret = request_irq(adis->spi->irq,
&iio_trigger_generic_data_rdy_poll,
IRQF_TRIGGER_RISING,
@@ -55,9 +59,6 @@ int adis_probe_trigger(struct adis *adis
if (ret)
goto error_free_trig;
- adis->trig->dev.parent = &adis->spi->dev;
- adis->trig->ops = &adis_trigger_ops;
- iio_trigger_set_drvdata(adis->trig, adis);
ret = iio_trigger_register(adis->trig);
indio_dev->trig = iio_trigger_get(adis->trig);
Patches currently in stable-queue which might be from lars(a)metafoo.de are
queue-4.14/iio-adis_lib-initialize-trigger-before-requesting-interrupt.patch
This is a note to let you know that I've just added the patch titled
iio: buffer: check if a buffer has been set up when poll is called
to the 4.14-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:
iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.patch
and it can be found in the queue-4.14 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 4cd140bda6494543f1c1b0ccceceaa44b676eef6 Mon Sep 17 00:00:00 2001
From: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
Date: Thu, 15 Feb 2018 15:02:53 +0100
Subject: iio: buffer: check if a buffer has been set up when poll is called
From: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
commit 4cd140bda6494543f1c1b0ccceceaa44b676eef6 upstream.
If no iio buffer has been set up and poll is called return 0.
Without this check there will be a null pointer dereference when
calling poll on a iio driver without an iio buffer.
Cc: stable(a)vger.kernel.org
Signed-off-by: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/industrialio-buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -175,7 +175,7 @@ unsigned int iio_buffer_poll(struct file
struct iio_dev *indio_dev = filp->private_data;
struct iio_buffer *rb = indio_dev->buffer;
- if (!indio_dev->info)
+ if (!indio_dev->info || rb == NULL)
return 0;
poll_wait(filp, &rb->pollq, wait);
Patches currently in stable-queue which might be from stefan.windfeldt(a)axis.com are
queue-4.14/iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.patch
This is a note to let you know that I've just added the patch titled
iio: adc: stm32: fix stm32h7_adc_enable error handling
to the 4.14-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:
iio-adc-stm32-fix-stm32h7_adc_enable-error-handling.patch
and it can be found in the queue-4.14 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 a3b5655ebdb501a98a45c0d3265dca9f2fe0218a Mon Sep 17 00:00:00 2001
From: Fabrice Gasnier <fabrice.gasnier(a)st.com>
Date: Tue, 23 Jan 2018 17:04:56 +0100
Subject: iio: adc: stm32: fix stm32h7_adc_enable error handling
From: Fabrice Gasnier <fabrice.gasnier(a)st.com>
commit a3b5655ebdb501a98a45c0d3265dca9f2fe0218a upstream.
Error handling in stm32h7_adc_enable routine doesn't unwind enable
sequence correctly. ADEN can only be cleared by hardware (e.g. by
writing one to ADDIS).
It's also better to clear ADRDY just after it's been set by hardware.
Fixes: 95e339b6e85d ("iio: adc: stm32: add support for STM32H7")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier(a)st.com>
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/adc/stm32-adc.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/iio/adc/stm32-adc.c
+++ b/drivers/iio/adc/stm32-adc.c
@@ -764,8 +764,6 @@ static int stm32h7_adc_enable(struct stm
int ret;
u32 val;
- /* Clear ADRDY by writing one, then enable ADC */
- stm32_adc_set_bits(adc, STM32H7_ADC_ISR, STM32H7_ADRDY);
stm32_adc_set_bits(adc, STM32H7_ADC_CR, STM32H7_ADEN);
/* Poll for ADRDY to be set (after adc startup time) */
@@ -773,8 +771,11 @@ static int stm32h7_adc_enable(struct stm
val & STM32H7_ADRDY,
100, STM32_ADC_TIMEOUT_US);
if (ret) {
- stm32_adc_clr_bits(adc, STM32H7_ADC_CR, STM32H7_ADEN);
+ stm32_adc_set_bits(adc, STM32H7_ADC_CR, STM32H7_ADDIS);
dev_err(&indio_dev->dev, "Failed to enable ADC\n");
+ } else {
+ /* Clear ADRDY by writing one */
+ stm32_adc_set_bits(adc, STM32H7_ADC_ISR, STM32H7_ADRDY);
}
return ret;
Patches currently in stable-queue which might be from fabrice.gasnier(a)st.com are
queue-4.14/iio-adc-stm32-fix-stm32h7_adc_enable-error-handling.patch
This is a note to let you know that I've just added the patch titled
i2c: designware: must wait for enable
to the 4.14-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:
i2c-designware-must-wait-for-enable.patch
and it can be found in the queue-4.14 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 fba4adbbf670577e605f9ad306629db6031cd48b Mon Sep 17 00:00:00 2001
From: Ben Gardner <gardner.ben(a)gmail.com>
Date: Wed, 14 Feb 2018 09:29:52 -0600
Subject: i2c: designware: must wait for enable
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Ben Gardner <gardner.ben(a)gmail.com>
commit fba4adbbf670577e605f9ad306629db6031cd48b upstream.
One I2C bus on my Atom E3845 board has been broken since 4.9.
It has two devices, both declared by ACPI and with built-in drivers.
There are two back-to-back transactions originating from the kernel, one
targeting each device. The first transaction works, the second one locks
up the I2C controller. The controller never recovers.
These kernel logs show up whenever an I2C transaction is attempted after
this failure.
i2c-designware-pci 0000:00:18.3: timeout in disabling adapter
i2c-designware-pci 0000:00:18.3: timeout waiting for bus ready
Waiting for the I2C controller status to indicate that it is enabled
before programming it fixes the issue.
I have tested this patch on 4.14 and 4.15.
Fixes: commit 2702ea7dbec5 ("i2c: designware: wait for disable/enable only if necessary")
Cc: linux-stable <stable(a)vger.kernel.org> #4.13+
Signed-off-by: Ben Gardner <gardner.ben(a)gmail.com>
Acked-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com>
Reviewed-by: José Roberto de Souza <jose.souza(a)intel.com>
Signed-off-by: Wolfram Sang <wsa(a)the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/i2c/busses/i2c-designware-master.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/i2c/busses/i2c-designware-master.c
+++ b/drivers/i2c/busses/i2c-designware-master.c
@@ -207,7 +207,7 @@ static void i2c_dw_xfer_init(struct dw_i
i2c_dw_disable_int(dev);
/* Enable the adapter */
- __i2c_dw_enable(dev, true);
+ __i2c_dw_enable_and_wait(dev, true);
/* Clear and enable interrupts */
dw_readl(dev, DW_IC_CLR_INTR);
Patches currently in stable-queue which might be from gardner.ben(a)gmail.com are
queue-4.14/i2c-designware-must-wait-for-enable.patch
This is a note to let you know that I've just added the patch titled
i2c: bcm2835: Set up the rising/falling edge delays
to the 4.14-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:
i2c-bcm2835-set-up-the-rising-falling-edge-delays.patch
and it can be found in the queue-4.14 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 fe32a815f05c8568669a062587435e15f9345764 Mon Sep 17 00:00:00 2001
From: Eric Anholt <eric(a)anholt.net>
Date: Thu, 8 Feb 2018 14:54:05 +0100
Subject: i2c: bcm2835: Set up the rising/falling edge delays
From: Eric Anholt <eric(a)anholt.net>
commit fe32a815f05c8568669a062587435e15f9345764 upstream.
We were leaving them in the power on state (or the state the firmware
had set up for some client, if we were taking over from them). The
boot state was 30 core clocks, when we actually want to sample some
time after (to make sure that the new input bit has actually arrived).
Signed-off-by: Eric Anholt <eric(a)anholt.net>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Signed-off-by: Wolfram Sang <wsa(a)the-dreams.de>
Cc: stable(a)kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/i2c/busses/i2c-bcm2835.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
--- a/drivers/i2c/busses/i2c-bcm2835.c
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -50,6 +50,9 @@
#define BCM2835_I2C_S_CLKT BIT(9)
#define BCM2835_I2C_S_LEN BIT(10) /* Fake bit for SW error reporting */
+#define BCM2835_I2C_FEDL_SHIFT 16
+#define BCM2835_I2C_REDL_SHIFT 0
+
#define BCM2835_I2C_CDIV_MIN 0x0002
#define BCM2835_I2C_CDIV_MAX 0xFFFE
@@ -81,7 +84,7 @@ static inline u32 bcm2835_i2c_readl(stru
static int bcm2835_i2c_set_divider(struct bcm2835_i2c_dev *i2c_dev)
{
- u32 divider;
+ u32 divider, redl, fedl;
divider = DIV_ROUND_UP(clk_get_rate(i2c_dev->clk),
i2c_dev->bus_clk_rate);
@@ -100,6 +103,22 @@ static int bcm2835_i2c_set_divider(struc
bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_DIV, divider);
+ /*
+ * Number of core clocks to wait after falling edge before
+ * outputting the next data bit. Note that both FEDL and REDL
+ * can't be greater than CDIV/2.
+ */
+ fedl = max(divider / 16, 1u);
+
+ /*
+ * Number of core clocks to wait after rising edge before
+ * sampling the next incoming data bit.
+ */
+ redl = max(divider / 4, 1u);
+
+ bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_DEL,
+ (fedl << BCM2835_I2C_FEDL_SHIFT) |
+ (redl << BCM2835_I2C_REDL_SHIFT));
return 0;
}
Patches currently in stable-queue which might be from eric(a)anholt.net are
queue-4.14/i2c-bcm2835-set-up-the-rising-falling-edge-delays.patch
This is a note to let you know that I've just added the patch titled
extcon: int3496: process id-pin first so that we start with the right status
to the 4.14-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:
extcon-int3496-process-id-pin-first-so-that-we-start-with-the-right-status.patch
and it can be found in the queue-4.14 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 0434352d3d2e950cf5e743f6062abd87de22f960 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Tue, 13 Feb 2018 20:25:50 +0100
Subject: extcon: int3496: process id-pin first so that we start with the right status
From: Hans de Goede <hdegoede(a)redhat.com>
commit 0434352d3d2e950cf5e743f6062abd87de22f960 upstream.
Some other drivers may be waiting for our extcon to show-up, exiting their
probe methods with -EPROBE_DEFER until we show up.
These drivers will typically get the cable state directly after getting
the extcon, this commit changes the int3496 code to wait for the initial
processing of the id-pin to complete before exiting probe() with 0, which
will cause devices waiting on the defered probe to get reprobed.
This fixes a race where the initial work might still be running while other
drivers were already calling extcon_get_state().
Fixes: 2f556bdb9f2e ("extcon: int3496: Add Intel INT3496 ACPI ... driver")
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Chanwoo Choi <cw00.choi(a)samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/extcon/extcon-intel-int3496.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/extcon/extcon-intel-int3496.c
+++ b/drivers/extcon/extcon-intel-int3496.c
@@ -153,8 +153,9 @@ static int int3496_probe(struct platform
return ret;
}
- /* queue initial processing of id-pin */
+ /* process id-pin so that we start with the right status */
queue_delayed_work(system_wq, &data->work, 0);
+ flush_delayed_work(&data->work);
platform_set_drvdata(pdev, data);
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.14/extcon-int3496-process-id-pin-first-so-that-we-start-with-the-right-status.patch
This is a note to let you know that I've just added the patch titled
drm: Handle unexpected holes in color-eviction
to the 4.14-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:
drm-handle-unexpected-holes-in-color-eviction.patch
and it can be found in the queue-4.14 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 b8ff1802815913aad52695898cccbc9f77b7e726 Mon Sep 17 00:00:00 2001
From: Chris Wilson <chris(a)chris-wilson.co.uk>
Date: Mon, 19 Feb 2018 11:35:43 +0000
Subject: drm: Handle unexpected holes in color-eviction
From: Chris Wilson <chris(a)chris-wilson.co.uk>
commit b8ff1802815913aad52695898cccbc9f77b7e726 upstream.
During eviction, the driver may free more than one hole in the drm_mm
due to the side-effects in evicting the scanned nodes. However,
drm_mm_scan_color_evict() expects that the scan result is the first
available hole (in the mru freed hole_stack list):
kernel BUG at drivers/gpu/drm/drm_mm.c:844!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in: i915 snd_hda_codec_analog snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core lpc_ich snd_pcm e1000e mei_me prime_numbers mei
CPU: 1 PID: 1490 Comm: gem_userptr_bli Tainted: G U 4.16.0-rc1-g740f57c54ecf-kasan_6+ #1
Hardware name: Dell Inc. OptiPlex 755 /0PU052, BIOS A08 02/19/2008
RIP: 0010:drm_mm_scan_color_evict+0x2b8/0x3d0
RSP: 0018:ffff880057a573f8 EFLAGS: 00010287
RAX: ffff8800611f5980 RBX: ffff880057a575d0 RCX: dffffc0000000000
RDX: 00000000029d5000 RSI: 1ffff1000af4aec1 RDI: ffff8800611f5a10
RBP: ffff88005ab884d0 R08: ffff880057a57600 R09: 000000000afff000
R10: 1ffff1000b5710b5 R11: 0000000000001000 R12: 1ffff1000af4ae82
R13: ffff8800611f59b0 R14: ffff8800611f5980 R15: ffff880057a57608
FS: 00007f2de0c2e8c0(0000) GS:ffff88006ac40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2ddde1e000 CR3: 00000000609b2000 CR4: 00000000000006e0
Call Trace:
? drm_mm_scan_remove_block+0x330/0x330
? drm_mm_scan_remove_block+0x151/0x330
i915_gem_evict_something+0x711/0xbd0 [i915]
? igt_evict_contexts+0x50/0x50 [i915]
? nop_clear_range+0x10/0x10 [i915]
? igt_evict_something+0x90/0x90 [i915]
? i915_gem_gtt_reserve+0x1a1/0x320 [i915]
i915_gem_gtt_insert+0x237/0x400 [i915]
__i915_vma_do_pin+0xc25/0x1a20 [i915]
eb_lookup_vmas+0x1c63/0x3790 [i915]
? i915_gem_check_execbuffer+0x250/0x250 [i915]
? trace_hardirqs_on_caller+0x33f/0x590
? _raw_spin_unlock_irqrestore+0x39/0x60
? __pm_runtime_resume+0x7d/0xf0
i915_gem_do_execbuffer+0x86a/0x2ff0 [i915]
? __kmalloc+0x132/0x340
? i915_gem_execbuffer2_ioctl+0x10f/0x760 [i915]
? drm_ioctl_kernel+0x12e/0x1c0
? drm_ioctl+0x662/0x980
? eb_relocate_slow+0xa90/0xa90 [i915]
? i915_gem_execbuffer2_ioctl+0x10f/0x760 [i915]
? __might_fault+0xea/0x1a0
i915_gem_execbuffer2_ioctl+0x3cc/0x760 [i915]
? i915_gem_execbuffer_ioctl+0xba0/0xba0 [i915]
? lock_acquire+0x3c0/0x3c0
? i915_gem_execbuffer_ioctl+0xba0/0xba0 [i915]
drm_ioctl_kernel+0x12e/0x1c0
drm_ioctl+0x662/0x980
? i915_gem_execbuffer_ioctl+0xba0/0xba0 [i915]
? drm_getstats+0x20/0x20
? debug_check_no_obj_freed+0x2a6/0x8c0
do_vfs_ioctl+0x170/0xe70
? ioctl_preallocate+0x170/0x170
? task_work_run+0xbe/0x160
? lock_acquire+0x3c0/0x3c0
? trace_hardirqs_on_caller+0x33f/0x590
? _raw_spin_unlock_irq+0x2f/0x50
SyS_ioctl+0x36/0x70
? do_vfs_ioctl+0xe70/0xe70
do_syscall_64+0x18c/0x5d0
entry_SYSCALL_64_after_hwframe+0x26/0x9b
RIP: 0033:0x7f2ddf13b587
RSP: 002b:00007fff15c4f9d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f2ddf13b587
RDX: 00007fff15c4fa20 RSI: 0000000040406469 RDI: 0000000000000003
RBP: 00007fff15c4fa20 R08: 0000000000000000 R09: 00007f2ddf3fe120
R10: 0000000000000073 R11: 0000000000000246 R12: 0000000040406469
R13: 0000000000000003 R14: 00007fff15c4fa20 R15: 00000000000000c7
Code: 00 00 00 4a c7 44 22 08 00 00 00 00 42 c7 44 22 10 00 00 00 00 48 81 c4 b8 00 00 00 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 0b 0f 0b <0f> 0b 31 c0 eb c0 4c 89 ef e8 9a 09 41 ff e9 1e fe ff ff 4c 89
RIP: drm_mm_scan_color_evict+0x2b8/0x3d0 RSP: ffff880057a573f8
We can trivially relax this assumption by searching the hole_stack for
the scan result and warn instead if the driver called us without any
result.
Fixes: 3fa489dabea9 ("drm: Apply tight eviction scanning to color_adjust")
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org> # v4.11+
Reviewed-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219113543.8010-1-chris@c…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_mm.c | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -834,9 +834,24 @@ struct drm_mm_node *drm_mm_scan_color_ev
if (!mm->color_adjust)
return NULL;
- hole = list_first_entry(&mm->hole_stack, typeof(*hole), hole_stack);
- hole_start = __drm_mm_hole_node_start(hole);
- hole_end = hole_start + hole->hole_size;
+ /*
+ * The hole found during scanning should ideally be the first element
+ * in the hole_stack list, but due to side-effects in the driver it
+ * may not be.
+ */
+ list_for_each_entry(hole, &mm->hole_stack, hole_stack) {
+ hole_start = __drm_mm_hole_node_start(hole);
+ hole_end = hole_start + hole->hole_size;
+
+ if (hole_start <= scan->hit_start &&
+ hole_end >= scan->hit_end)
+ break;
+ }
+
+ /* We should only be called after we found the hole previously */
+ DRM_MM_BUG_ON(&hole->hole_stack == &mm->hole_stack);
+ if (unlikely(&hole->hole_stack == &mm->hole_stack))
+ return NULL;
DRM_MM_BUG_ON(hole_start > scan->hit_start);
DRM_MM_BUG_ON(hole_end < scan->hit_end);
Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are
queue-4.14/drm-handle-unexpected-holes-in-color-eviction.patch
This is a note to let you know that I've just added the patch titled
drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
to the 4.14-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:
drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.patch
and it can be found in the queue-4.14 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 06998a756a3865817b87a129a7e5d5bb66dc1ec3 Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Sun, 18 Feb 2018 16:53:59 +0800
Subject: drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit 06998a756a3865817b87a129a7e5d5bb66dc1ec3 upstream.
Similar to commit e10aec652f31 ("drm/edid: Add 6 bpc quirk for display
AEO model 0."), the EDID reports "DFP 1.x compliant TMDS" but it support
6bpc instead of 8 bpc.
Hence, use 6 bpc quirk for this panel.
Fixes: 196f954e2509 ("drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"")
BugLink: https://bugs.launchpad.net/bugs/1749420
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de(a)gmail.com>
Cc: <stable(a)vger.kernel.org> # v4.8+
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180218085359.7817-1-kai.hen…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -111,6 +111,9 @@ static const struct edid_quirk {
/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
{ "AEO", 0, EDID_QUIRK_FORCE_6BPC },
+ /* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */
+ { "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC },
+
/* Belinea 10 15 55 */
{ "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
{ "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.14/drm-amdgpu-add-new-device-to-use-atpx-quirk.patch
queue-4.14/drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.patch
This is a note to let you know that I've just added the patch titled
drm/cirrus: Load lut in crtc_commit
to the 4.14-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:
drm-cirrus-load-lut-in-crtc_commit.patch
and it can be found in the queue-4.14 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 745fd50f3b044db6a3922e1718306555613164b0 Mon Sep 17 00:00:00 2001
From: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Date: Wed, 31 Jan 2018 12:04:50 +0100
Subject: drm/cirrus: Load lut in crtc_commit
From: Daniel Vetter <daniel.vetter(a)ffwll.ch>
commit 745fd50f3b044db6a3922e1718306555613164b0 upstream.
In the past the ast driver relied upon the fbdev emulation helpers to
call ->load_lut at boot-up. But since
commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
Author: Peter Rosin <peda(a)axentia.se>
Date: Tue Jul 4 12:36:57 2017 +0200
drm/fb-helper: factor out pseudo-palette
that's cleaned up and drivers are expected to boot into a consistent
lut state. This patch fixes that.
Fixes: b8e2b0199cc3 ("drm/fb-helper: factor out pseudo-palette")
Cc: Peter Rosin <peda(a)axenita.se>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: <stable(a)vger.kernel.org> # v4.14+
References: https://bugzilla.kernel.org/show_bug.cgi?id=198123
Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20180131110450.22153-1-daniel.…
Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/cirrus/cirrus_mode.c | 40 ++++++++++++++++++++---------------
1 file changed, 23 insertions(+), 17 deletions(-)
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -294,22 +294,7 @@ static void cirrus_crtc_prepare(struct d
{
}
-/*
- * This is called after a mode is programmed. It should reverse anything done
- * by the prepare function
- */
-static void cirrus_crtc_commit(struct drm_crtc *crtc)
-{
-}
-
-/*
- * The core can pass us a set of gamma values to program. We actually only
- * use this for 8-bit mode so can't perform smooth fades on deeper modes,
- * but it's a requirement that we provide the function
- */
-static int cirrus_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
- u16 *blue, uint32_t size,
- struct drm_modeset_acquire_ctx *ctx)
+static void cirrus_crtc_load_lut(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
struct cirrus_device *cdev = dev->dev_private;
@@ -317,7 +302,7 @@ static int cirrus_crtc_gamma_set(struct
int i;
if (!crtc->enabled)
- return 0;
+ return;
r = crtc->gamma_store;
g = r + crtc->gamma_size;
@@ -330,6 +315,27 @@ static int cirrus_crtc_gamma_set(struct
WREG8(PALETTE_DATA, *g++ >> 8);
WREG8(PALETTE_DATA, *b++ >> 8);
}
+}
+
+/*
+ * This is called after a mode is programmed. It should reverse anything done
+ * by the prepare function
+ */
+static void cirrus_crtc_commit(struct drm_crtc *crtc)
+{
+ cirrus_crtc_load_lut(crtc);
+}
+
+/*
+ * The core can pass us a set of gamma values to program. We actually only
+ * use this for 8-bit mode so can't perform smooth fades on deeper modes,
+ * but it's a requirement that we provide the function
+ */
+static int cirrus_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
+ u16 *blue, uint32_t size,
+ struct drm_modeset_acquire_ctx *ctx)
+{
+ cirrus_crtc_load_lut(crtc);
return 0;
}
Patches currently in stable-queue which might be from daniel.vetter(a)ffwll.ch are
queue-4.14/drm-handle-unexpected-holes-in-color-eviction.patch
queue-4.14/drm-cirrus-load-lut-in-crtc_commit.patch
queue-4.14/drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: disable MMHUB power gating on raven
to the 4.14-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:
drm-amdgpu-disable-mmhub-power-gating-on-raven.patch
and it can be found in the queue-4.14 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 400b6afbaa949914460e5fd1d769c5e26ef1f6b8 Mon Sep 17 00:00:00 2001
From: Huang Rui <ray.huang(a)amd.com>
Date: Thu, 14 Dec 2017 13:47:16 +0800
Subject: drm/amdgpu: disable MMHUB power gating on raven
From: Huang Rui <ray.huang(a)amd.com>
commit 400b6afbaa949914460e5fd1d769c5e26ef1f6b8 upstream.
MMHUB power gating still has issue, and doesn't work on raven at current. So
disable it for the moment.
Signed-off-by: Huang Rui <ray.huang(a)amd.com>
Acked-by: Hawking Zhang <Hawking.Zhang(a)amd.com>
Acked-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -661,8 +661,8 @@ static int soc15_common_early_init(void
AMD_CG_SUPPORT_MC_LS |
AMD_CG_SUPPORT_SDMA_MGCG |
AMD_CG_SUPPORT_SDMA_LS;
- adev->pg_flags = AMD_PG_SUPPORT_SDMA |
- AMD_PG_SUPPORT_MMHUB;
+ adev->pg_flags = AMD_PG_SUPPORT_SDMA;
+
adev->external_rev_id = 0x1;
break;
default:
Patches currently in stable-queue which might be from ray.huang(a)amd.com are
queue-4.14/drm-amdgpu-disable-mmhub-power-gating-on-raven.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
to the 4.14-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:
drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.patch
and it can be found in the queue-4.14 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 458d876eb869d5a88b53074c6c271b8b9adc0f07 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Mon, 22 Jan 2018 23:13:32 -0500
Subject: drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
From: Alex Deucher <alexander.deucher(a)amd.com>
commit 458d876eb869d5a88b53074c6c271b8b9adc0f07 upstream.
We only support vga_switcheroo and runtime pm on PX/HG systems
so forcing runpm to 1 doesn't do anything useful anyway.
Only call vga_switcheroo_init_domain_pm_ops() for PX/HG so
that the cleanup path is correct as well. This mirrors what
radeon does as well.
v2: rework the patch originally sent by Lukas (Alex)
Acked-by: Lukas Wunner <lukas(a)wunner.de>
Reported-by: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de> (v1)
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2076,8 +2076,6 @@ int amdgpu_device_init(struct amdgpu_dev
* ignore it */
vga_client_register(adev->pdev, adev, NULL, amdgpu_vga_set_decode);
- if (amdgpu_runtime_pm == 1)
- runtime = true;
if (amdgpu_device_is_px(ddev))
runtime = true;
if (!pci_is_thunderbolt_attached(adev->pdev))
Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are
queue-4.14/drm-amdgpu-add-new-device-to-use-atpx-quirk.patch
queue-4.14/drm-amdgpu-add-dpm-quirk-for-jet-pro-v2.patch
queue-4.14/drm-amdgpu-only-check-mmbif_iov_func_identifier-on-tonga-fiji.patch
queue-4.14/drm-amdgpu-disable-mmhub-power-gating-on-raven.patch
queue-4.14/drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.patch
queue-4.14/drm-amdgpu-add-atpx-quirk-handling-v2.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: only check mmBIF_IOV_FUNC_IDENTIFIER on tonga/fiji
to the 4.14-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:
drm-amdgpu-only-check-mmbif_iov_func_identifier-on-tonga-fiji.patch
and it can be found in the queue-4.14 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 57ad33a307bf85cafda3a77c03a555c9f9ee4139 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Tue, 19 Dec 2017 09:52:31 -0500
Subject: drm/amdgpu: only check mmBIF_IOV_FUNC_IDENTIFIER on tonga/fiji
From: Alex Deucher <alexander.deucher(a)amd.com>
commit 57ad33a307bf85cafda3a77c03a555c9f9ee4139 upstream.
We only support SR-IOV on tonga/fiji. Don't check this register
on other VI parts.
Fixes: 048765ad5af7c89 (amdgpu: fix asic initialization for virtualized environments (v2))
Reviewed-by: Xiangliang Yu <Xiangliang.Yu(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/vi.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -448,14 +448,19 @@ static bool vi_read_bios_from_rom(struct
static void vi_detect_hw_virtualization(struct amdgpu_device *adev)
{
- uint32_t reg = RREG32(mmBIF_IOV_FUNC_IDENTIFIER);
- /* bit0: 0 means pf and 1 means vf */
- /* bit31: 0 means disable IOV and 1 means enable */
- if (reg & 1)
- adev->virt.caps |= AMDGPU_SRIOV_CAPS_IS_VF;
+ uint32_t reg = 0;
- if (reg & 0x80000000)
- adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV;
+ if (adev->asic_type == CHIP_TONGA ||
+ adev->asic_type == CHIP_FIJI) {
+ reg = RREG32(mmBIF_IOV_FUNC_IDENTIFIER);
+ /* bit0: 0 means pf and 1 means vf */
+ /* bit31: 0 means disable IOV and 1 means enable */
+ if (reg & 1)
+ adev->virt.caps |= AMDGPU_SRIOV_CAPS_IS_VF;
+
+ if (reg & 0x80000000)
+ adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV;
+ }
if (reg == 0) {
if (is_virtual_machine()) /* passthrough mode exclus sr-iov mode */
Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are
queue-4.14/drm-amdgpu-add-new-device-to-use-atpx-quirk.patch
queue-4.14/drm-amdgpu-add-dpm-quirk-for-jet-pro-v2.patch
queue-4.14/drm-amdgpu-only-check-mmbif_iov_func_identifier-on-tonga-fiji.patch
queue-4.14/drm-amdgpu-disable-mmhub-power-gating-on-raven.patch
queue-4.14/drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.patch
queue-4.14/drm-amdgpu-add-atpx-quirk-handling-v2.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: add new device to use atpx quirk
to the 4.14-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:
drm-amdgpu-add-new-device-to-use-atpx-quirk.patch
and it can be found in the queue-4.14 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 6e59de2048eb375a9bfcd39461ef841cd2a78962 Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Thu, 8 Feb 2018 17:46:01 +0800
Subject: drm/amdgpu: add new device to use atpx quirk
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit 6e59de2048eb375a9bfcd39461ef841cd2a78962 upstream.
The affected system (0x0813) is pretty similar to another one (0x0812),
it also needs to use ATPX power control.
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
@@ -568,6 +568,7 @@ static const struct amdgpu_px_quirk amdg
/* HG _PR3 doesn't seem to work on this A+A weston board */
{ 0x1002, 0x6900, 0x1002, 0x0124, AMDGPU_PX_QUIRK_FORCE_ATPX },
{ 0x1002, 0x6900, 0x1028, 0x0812, AMDGPU_PX_QUIRK_FORCE_ATPX },
+ { 0x1002, 0x6900, 0x1028, 0x0813, AMDGPU_PX_QUIRK_FORCE_ATPX },
{ 0, 0, 0, 0, 0 },
};
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.14/drm-amdgpu-add-new-device-to-use-atpx-quirk.patch
queue-4.14/drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: Add dpm quirk for Jet PRO (v2)
to the 4.14-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:
drm-amdgpu-add-dpm-quirk-for-jet-pro-v2.patch
and it can be found in the queue-4.14 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 f2e5262f75ecb40a6e56554e156a292ab9e1d1b7 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Tue, 21 Nov 2017 12:10:57 -0500
Subject: drm/amdgpu: Add dpm quirk for Jet PRO (v2)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Alex Deucher <alexander.deucher(a)amd.com>
commit f2e5262f75ecb40a6e56554e156a292ab9e1d1b7 upstream.
Fixes stability issues.
v2: clamp sclk to 600 Mhz
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103370
Acked-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
@@ -3465,6 +3465,11 @@ static void si_apply_state_adjust_rules(
(adev->pdev->device == 0x6667)) {
max_sclk = 75000;
}
+ if ((adev->pdev->revision == 0xC3) ||
+ (adev->pdev->device == 0x6665)) {
+ max_sclk = 60000;
+ max_mclk = 80000;
+ }
} else if (adev->asic_type == CHIP_OLAND) {
if ((adev->pdev->revision == 0xC7) ||
(adev->pdev->revision == 0x80) ||
Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are
queue-4.14/drm-amdgpu-add-new-device-to-use-atpx-quirk.patch
queue-4.14/drm-amdgpu-add-dpm-quirk-for-jet-pro-v2.patch
queue-4.14/drm-amdgpu-only-check-mmbif_iov_func_identifier-on-tonga-fiji.patch
queue-4.14/drm-amdgpu-disable-mmhub-power-gating-on-raven.patch
queue-4.14/drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.patch
queue-4.14/drm-amdgpu-add-atpx-quirk-handling-v2.patch
This is a note to let you know that I've just added the patch titled
cfg80211: fix cfg80211_beacon_dup
to the 4.14-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:
cfg80211-fix-cfg80211_beacon_dup.patch
and it can be found in the queue-4.14 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 bee92d06157fc39d5d7836a061c7d41289a55797 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Fri, 2 Feb 2018 16:31:23 +0100
Subject: cfg80211: fix cfg80211_beacon_dup
From: Arnd Bergmann <arnd(a)arndb.de>
commit bee92d06157fc39d5d7836a061c7d41289a55797 upstream.
gcc-8 warns about some obviously incorrect code:
net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':
net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
>From the context, I conclude that we want to copy from beacon into
new_beacon, as we do in the rest of the function.
Cc: stable(a)vger.kernel.org
Fixes: 73da7d5bab79 ("mac80211: add channel switch command and beacon callbacks")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2863,7 +2863,7 @@ cfg80211_beacon_dup(struct cfg80211_beac
}
if (beacon->probe_resp_len) {
new_beacon->probe_resp_len = beacon->probe_resp_len;
- beacon->probe_resp = pos;
+ new_beacon->probe_resp = pos;
memcpy(pos, beacon->probe_resp, beacon->probe_resp_len);
pos += beacon->probe_resp_len;
}
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-4.14/cfg80211-fix-cfg80211_beacon_dup.patch
queue-4.14/kbuild-always-define-endianess-in-kconfig.h.patch
This is a note to let you know that I've just added the patch titled
arm64: Remove unimplemented syscall log message
to the 4.14-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:
arm64-remove-unimplemented-syscall-log-message.patch
and it can be found in the queue-4.14 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 1962682d2b2fbe6cfa995a85c53c069fadda473e Mon Sep 17 00:00:00 2001
From: Michael Weiser <michael.weiser(a)gmx.de>
Date: Thu, 1 Feb 2018 23:13:36 +0100
Subject: arm64: Remove unimplemented syscall log message
From: Michael Weiser <michael.weiser(a)gmx.de>
commit 1962682d2b2fbe6cfa995a85c53c069fadda473e upstream.
Stop printing a (ratelimited) kernel message for each instance of an
unimplemented syscall being called. Userland making an unimplemented
syscall is not necessarily misbehaviour and to be expected with a
current userland running on an older kernel. Also, the current message
looks scary to users but does not actually indicate a real problem nor
help them narrow down the cause. Just rely on sys_ni_syscall() to return
-ENOSYS.
Cc: <stable(a)vger.kernel.org>
Acked-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Michael Weiser <michael.weiser(a)gmx.de>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/kernel/traps.c | 8 --------
1 file changed, 8 deletions(-)
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -573,14 +573,6 @@ asmlinkage long do_ni_syscall(struct pt_
}
#endif
- if (show_unhandled_signals_ratelimited()) {
- pr_info("%s[%d]: syscall %d\n", current->comm,
- task_pid_nr(current), regs->syscallno);
- dump_instr("", regs);
- if (user_mode(regs))
- __show_regs(regs);
- }
-
return sys_ni_syscall();
}
Patches currently in stable-queue which might be from michael.weiser(a)gmx.de are
queue-4.14/arm64-remove-unimplemented-syscall-log-message.patch
queue-4.14/arm64-disable-unhandled-signal-log-messages-by-default.patch
This is a note to let you know that I've just added the patch titled
arm64: Disable unhandled signal log messages by default
to the 4.14-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:
arm64-disable-unhandled-signal-log-messages-by-default.patch
and it can be found in the queue-4.14 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 5ee39a71fd89ab7240c5339d04161c44a8e03269 Mon Sep 17 00:00:00 2001
From: Michael Weiser <michael.weiser(a)gmx.de>
Date: Thu, 1 Feb 2018 23:13:38 +0100
Subject: arm64: Disable unhandled signal log messages by default
From: Michael Weiser <michael.weiser(a)gmx.de>
commit 5ee39a71fd89ab7240c5339d04161c44a8e03269 upstream.
aarch64 unhandled signal kernel messages are very verbose, suggesting
them to be more of a debugging aid:
sigsegv[33]: unhandled level 2 translation fault (11) at 0x00000000, esr
0x92000046, in sigsegv[400000+71000]
CPU: 1 PID: 33 Comm: sigsegv Tainted: G W 4.15.0-rc3+ #3
Hardware name: linux,dummy-virt (DT)
pstate: 60000000 (nZCv daif -PAN -UAO)
pc : 0x4003f4
lr : 0x4006bc
sp : 0000fffffe94a060
x29: 0000fffffe94a070 x28: 0000000000000000
x27: 0000000000000000 x26: 0000000000000000
x25: 0000000000000000 x24: 00000000004001b0
x23: 0000000000486ac8 x22: 00000000004001c8
x21: 0000000000000000 x20: 0000000000400be8
x19: 0000000000400b30 x18: 0000000000484728
x17: 000000000865ffc8 x16: 000000000000270f
x15: 00000000000000b0 x14: 0000000000000002
x13: 0000000000000001 x12: 0000000000000000
x11: 0000000000000000 x10: 0008000020008008
x9 : 000000000000000f x8 : ffffffffffffffff
x7 : 0004000000000000 x6 : ffffffffffffffff
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 00000000004003e4 x2 : 0000fffffe94a1e8
x1 : 000000000000000a x0 : 0000000000000000
Disable them by default, so they can be enabled using
/proc/sys/debug/exception-trace.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Michael Weiser <michael.weiser(a)gmx.de>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/kernel/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -56,7 +56,7 @@ static const char *handler[]= {
"Error"
};
-int show_unhandled_signals = 1;
+int show_unhandled_signals = 0;
/*
* Dump out the contents of some kernel memory nicely...
Patches currently in stable-queue which might be from michael.weiser(a)gmx.de are
queue-4.14/arm64-remove-unimplemented-syscall-log-message.patch
queue-4.14/arm64-disable-unhandled-signal-log-messages-by-default.patch
This is a note to let you know that I've just added the patch titled
arm64: cpufeature: Fix CTR_EL0 field definitions
to the 4.14-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:
arm64-cpufeature-fix-ctr_el0-field-definitions.patch
and it can be found in the queue-4.14 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 be68a8aaf925aaf35574260bf820bb09d2f9e07f Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon(a)arm.com>
Date: Mon, 19 Feb 2018 14:41:44 +0000
Subject: arm64: cpufeature: Fix CTR_EL0 field definitions
From: Will Deacon <will.deacon(a)arm.com>
commit be68a8aaf925aaf35574260bf820bb09d2f9e07f upstream.
Our field definitions for CTR_EL0 suffer from a number of problems:
- The IDC and DIC fields are missing, which causes us to enable CTR
trapping on CPUs with either of these returning non-zero values.
- The ERG is FTR_LOWER_SAFE, whereas it should be treated like CWG as
FTR_HIGHER_SAFE so that applications can use it to avoid false sharing.
- [nit] A RES1 field is described as "RAO"
This patch updates the CTR_EL0 field definitions to fix these issues.
Cc: <stable(a)vger.kernel.org>
Cc: Shanker Donthineni <shankerd(a)codeaurora.org>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/kernel/cpufeature.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -175,9 +175,11 @@ static const struct arm64_ftr_bits ftr_i
};
static const struct arm64_ftr_bits ftr_ctr[] = {
- ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, 31, 1, 1), /* RAO */
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, 31, 1, 1), /* RES1 */
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 29, 1, 1), /* DIC */
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 28, 1, 1), /* IDC */
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_SAFE, 24, 4, 0), /* CWG */
- ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 20, 4, 0), /* ERG */
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_SAFE, 20, 4, 0), /* ERG */
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 16, 4, 1), /* DminLine */
/*
* Linux can handle differing I-cache policies. Userspace JITs will
Patches currently in stable-queue which might be from will.deacon(a)arm.com are
queue-4.14/arm64-remove-unimplemented-syscall-log-message.patch
queue-4.14/arm64-mm-don-t-write-garbage-into-ttbr1_el1-register.patch
queue-4.14/arm64-disable-unhandled-signal-log-messages-by-default.patch
queue-4.14/irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch
queue-4.14/arm64-cpufeature-fix-ctr_el0-field-definitions.patch
queue-4.14/kbuild-always-define-endianess-in-kconfig.h.patch
This is a note to let you know that I've just added the patch titled
Add delay-init quirk for Corsair K70 RGB keyboards
to the 4.14-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:
add-delay-init-quirk-for-corsair-k70-rgb-keyboards.patch
and it can be found in the queue-4.14 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 7a1646d922577b5b48c0d222e03831141664bb59 Mon Sep 17 00:00:00 2001
From: Jack Stocker <jackstocker.93(a)gmail.com>
Date: Thu, 15 Feb 2018 18:24:10 +0000
Subject: Add delay-init quirk for Corsair K70 RGB keyboards
From: Jack Stocker <jackstocker.93(a)gmail.com>
commit 7a1646d922577b5b48c0d222e03831141664bb59 upstream.
Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
start correctly at boot.
Device ids found here:
usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-3: Product: Corsair K70 RGB Gaming Keyboard
Signed-off-by: Jack Stocker <jackstocker.93(a)gmail.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -225,6 +225,9 @@ static const struct usb_device_id usb_qu
{ USB_DEVICE(0x1a0a, 0x0200), .driver_info =
USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
+ /* Corsair K70 RGB */
+ { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* Corsair Strafe RGB */
{ USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
Patches currently in stable-queue which might be from jackstocker.93(a)gmail.com are
queue-4.14/add-delay-init-quirk-for-corsair-k70-rgb-keyboards.patch
The patch below does not apply to the 4.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From d61a5c1063515e855bedb1b81e20e50b0ac3541e Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Sun, 11 Feb 2018 10:38:28 +0100
Subject: [PATCH] drm/nouveau: Fix deadlock on runtime suspend
nouveau's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.
The output poll worker meanwhile calls pm_runtime_get_sync() in
nouveau_connector_detect() which waits for the ongoing suspend to finish,
causing a deadlock.
Fix by not acquiring a runtime PM ref if nouveau_connector_detect() is
called in the output poll worker's context. This is safe because
the poll worker is only enabled while runtime active and we know that
->runtime_suspend waits for it to finish.
Other contexts calling nouveau_connector_detect() do require a runtime
PM ref, these comprise:
status_store() drm sysfs interface
->fill_modes drm callback
drm_fb_helper_probe_connector_modes()
drm_mode_getconnector()
nouveau_connector_hotplug()
nouveau_display_hpd_work()
nv17_tv_set_property()
Stack trace for posterity:
INFO: task kworker/0:1:58 blocked for more than 120 seconds.
Workqueue: events output_poll_execute [drm_kms_helper]
Call Trace:
schedule+0x28/0x80
rpm_resume+0x107/0x6e0
__pm_runtime_resume+0x47/0x70
nouveau_connector_detect+0x7e/0x4a0 [nouveau]
nouveau_connector_detect_lvds+0x132/0x180 [nouveau]
drm_helper_probe_detect_ctx+0x85/0xd0 [drm_kms_helper]
output_poll_execute+0x11e/0x1c0 [drm_kms_helper]
process_one_work+0x184/0x380
worker_thread+0x2e/0x390
INFO: task kworker/0:2:252 blocked for more than 120 seconds.
Workqueue: pm pm_runtime_work
Call Trace:
schedule+0x28/0x80
schedule_timeout+0x1e3/0x370
wait_for_completion+0x123/0x190
flush_work+0x142/0x1c0
nouveau_pmops_runtime_suspend+0x7e/0xd0 [nouveau]
pci_pm_runtime_suspend+0x5c/0x180
vga_switcheroo_runtime_suspend+0x1e/0xa0
__rpm_callback+0xc1/0x200
rpm_callback+0x1f/0x70
rpm_suspend+0x13c/0x640
pm_runtime_work+0x6e/0x90
process_one_work+0x184/0x380
worker_thread+0x2e/0x390
Bugzilla: https://bugs.archlinux.org/task/53497
Bugzilla: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870523
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388#c33
Fixes: 5addcf0a5f0f ("nouveau: add runtime PM support (v0.9)")
Cc: stable(a)vger.kernel.org # v3.12+: 27d4ee03078a: workqueue: Allow retrieval of current task's work struct
Cc: stable(a)vger.kernel.org # v3.12+: 25c058ccaf2e: drm: Allow determining if current task is output poll worker
Cc: Ben Skeggs <bskeggs(a)redhat.com>
Cc: Dave Airlie <airlied(a)redhat.com>
Reviewed-by: Lyude Paul <lyude(a)redhat.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/b7d2cbb609a80f59ccabfdf479b9d…
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 69d6e61a01ec..6ed9cb053dfa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -570,9 +570,15 @@ nouveau_connector_detect(struct drm_connector *connector, bool force)
nv_connector->edid = NULL;
}
- ret = pm_runtime_get_sync(connector->dev->dev);
- if (ret < 0 && ret != -EACCES)
- return conn_status;
+ /* Outputs are only polled while runtime active, so acquiring a
+ * runtime PM ref here is unnecessary (and would deadlock upon
+ * runtime suspend because it waits for polling to finish).
+ */
+ if (!drm_kms_helper_is_poll_worker()) {
+ ret = pm_runtime_get_sync(connector->dev->dev);
+ if (ret < 0 && ret != -EACCES)
+ return conn_status;
+ }
nv_encoder = nouveau_connector_ddc_detect(connector);
if (nv_encoder && (i2c = nv_encoder->i2c) != NULL) {
@@ -647,8 +653,10 @@ nouveau_connector_detect(struct drm_connector *connector, bool force)
out:
- pm_runtime_mark_last_busy(connector->dev->dev);
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (!drm_kms_helper_is_poll_worker()) {
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ }
return conn_status;
}
This is a note to let you know that I've just added the patch titled
x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
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:
x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.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 85c615eb52222bc5fab6c7190d146bc59fac289e Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 20 Feb 2018 21:58:21 +0100
Subject: x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
From: Arnd Bergmann <arnd(a)arndb.de>
commit 85c615eb52222bc5fab6c7190d146bc59fac289e upstream.
GCC-8 shows a warning for the x86 oprofile code that copies per-CPU
data from CPU 0 to all other CPUs, which when building a non-SMP
kernel turns into a memcpy() with identical source and destination
pointers:
arch/x86/oprofile/nmi_int.c: In function 'mux_clone':
arch/x86/oprofile/nmi_int.c:285:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
memcpy(per_cpu(cpu_msrs, cpu).multiplex,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
per_cpu(cpu_msrs, 0).multiplex,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(struct op_msr) * model->num_virt_counters);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/oprofile/nmi_int.c: In function 'nmi_setup':
arch/x86/oprofile/nmi_int.c:466:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
arch/x86/oprofile/nmi_int.c:470:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
I have analyzed a number of such warnings now: some are valid and the
GCC warning is welcome. Others turned out to be false-positives, and
GCC was changed to not warn about those any more. This is a corner case
that is a false-positive but the GCC developers feel it's better to keep
warning about it.
In this case, it seems best to work around it by telling GCC
a little more clearly that this code path is never hit with
an IS_ENABLED() configuration check.
Cc:stable as we also want old kernels to build cleanly with GCC-8.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Jessica Yu <jeyu(a)kernel.org>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Martin Sebor <msebor(a)gcc.gnu.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Robert Richter <rric(a)kernel.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: oprofile-list(a)lists.sf.net
Cc: stable(a)vger.kernel.org
Link: http://lkml.kernel.org/r/20180220205826.2008875-1-arnd@arndb.de
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/oprofile/nmi_int.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/oprofile/nmi_int.c
+++ b/arch/x86/oprofile/nmi_int.c
@@ -472,7 +472,7 @@ static int nmi_setup(void)
goto fail;
for_each_possible_cpu(cpu) {
- if (!cpu)
+ if (!IS_ENABLED(CONFIG_SMP) || !cpu)
continue;
memcpy(per_cpu(cpu_msrs, cpu).counters,
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.9/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-4.9/cfg80211-fix-cfg80211_beacon_dup.patch
queue-4.9/kbuild-always-define-endianess-in-kconfig.h.patch
This is a note to let you know that I've just added the patch titled
X.509: fix BUG_ON() when hash algorithm is unsupported
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:
x.509-fix-bug_on-when-hash-algorithm-is-unsupported.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 437499eea4291ae9621e8763a41df027c110a1ef Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Thu, 22 Feb 2018 14:38:33 +0000
Subject: X.509: fix BUG_ON() when hash algorithm is unsupported
From: Eric Biggers <ebiggers(a)google.com>
commit 437499eea4291ae9621e8763a41df027c110a1ef upstream.
The X.509 parser mishandles the case where the certificate's signature's
hash algorithm is not available in the crypto API. In this case,
x509_get_sig_params() doesn't allocate the cert->sig->digest buffer;
this part seems to be intentional. However,
public_key_verify_signature() is still called via
x509_check_for_self_signed(), which triggers the 'BUG_ON(!sig->digest)'.
Fix this by making public_key_verify_signature() return -ENOPKG if the
hash buffer has not been allocated.
Reproducer when all the CONFIG_CRYPTO_SHA512* options are disabled:
openssl req -new -sha512 -x509 -batch -nodes -outform der \
| keyctl padd asymmetric desc @s
Fixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier")
Reported-by: Paolo Valente <paolo.valente(a)linaro.org>
Cc: Paolo Valente <paolo.valente(a)linaro.org>
Cc: <stable(a)vger.kernel.org> # v4.7+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/asymmetric_keys/public_key.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -93,9 +93,11 @@ int public_key_verify_signature(const st
BUG_ON(!pkey);
BUG_ON(!sig);
- BUG_ON(!sig->digest);
BUG_ON(!sig->s);
+ if (!sig->digest)
+ return -ENOPKG;
+
alg_name = sig->pkey_algo;
if (strcmp(sig->pkey_algo, "rsa") == 0) {
/* The data wangled by the RSA algorithm is typically padded
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/x.509-fix-bug_on-when-hash-algorithm-is-unsupported.patch
queue-4.9/pkcs-7-fix-certificate-chain-verification.patch
This is a note to let you know that I've just added the patch titled
usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
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-renesas_usbhs-missed-the-running-flag-in-usb_dmac-with-rx-path.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 17aa31f13cad25daa19d3f923323f552e87bc874 Mon Sep 17 00:00:00 2001
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Date: Mon, 5 Feb 2018 17:12:35 +0900
Subject: usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
commit 17aa31f13cad25daa19d3f923323f552e87bc874 upstream.
This fixes an issue that a gadget driver (usb_f_fs) is possible to
stop rx transactions after the usb-dmac is used because the following
functions missed to set/check the "running" flag.
- usbhsf_dma_prepare_pop_with_usb_dmac()
- usbhsf_dma_pop_done_with_usb_dmac()
So, if next transaction uses pio, the usbhsf_prepare_pop() can not
start the transaction because the "running" flag is 0.
Fixes: 8355b2b3082d ("usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle")
Cc: <stable(a)vger.kernel.org> # v3.19+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/renesas_usbhs/fifo.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -1001,6 +1001,10 @@ static int usbhsf_dma_prepare_pop_with_u
if ((uintptr_t)pkt->buf & (USBHS_USB_DMAC_XFER_SIZE - 1))
goto usbhsf_pio_prepare_pop;
+ /* return at this time if the pipe is running */
+ if (usbhs_pipe_is_running(pipe))
+ return 0;
+
usbhs_pipe_config_change_bfre(pipe, 1);
ret = usbhsf_fifo_select(pipe, fifo, 0);
@@ -1191,6 +1195,7 @@ static int usbhsf_dma_pop_done_with_usb_
usbhsf_fifo_clear(pipe, fifo);
pkt->actual = usbhs_dma_calc_received_size(pkt, chan, rcv_len);
+ usbhs_pipe_running(pipe, 0);
usbhsf_dma_stop(pipe, fifo);
usbhsf_dma_unmap(pkt);
usbhsf_fifo_unselect(pipe, pipe->fifo);
Patches currently in stable-queue which might be from yoshihiro.shimoda.uh(a)renesas.com are
queue-4.9/usb-renesas_usbhs-missed-the-running-flag-in-usb_dmac-with-rx-path.patch
This is a note to let you know that I've just added the patch titled
usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
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-ohci-proper-handling-of-ed_rm_list-to-handle-race-condition-between-usb_kill_urb-and-finish_unlinks.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 46408ea558df13b110e0866b99624384a33bdeba Mon Sep 17 00:00:00 2001
From: AMAN DEEP <aman.deep(a)samsung.com>
Date: Thu, 8 Feb 2018 11:55:01 +0800
Subject: usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
From: AMAN DEEP <aman.deep(a)samsung.com>
commit 46408ea558df13b110e0866b99624384a33bdeba upstream.
There is a race condition between finish_unlinks->finish_urb() function
and usb_kill_urb() in ohci controller case. The finish_urb calls
spin_unlock(&ohci->lock) before usb_hcd_giveback_urb() function call,
then if during this time, usb_kill_urb is called for another endpoint,
then new ed will be added to ed_rm_list at beginning for unlink, and
ed_rm_list will point to newly added.
When finish_urb() is completed in finish_unlinks() and ed->td_list
becomes empty as in below code (in finish_unlinks() function):
if (list_empty(&ed->td_list)) {
*last = ed->ed_next;
ed->ed_next = NULL;
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
*last = ed->ed_next;
ed->ed_next = NULL;
ed_schedule(ohci, ed);
}
The *last = ed->ed_next will make ed_rm_list to point to ed->ed_next
and previously added ed by usb_kill_urb will be left unreferenced by
ed_rm_list. This causes usb_kill_urb() hang forever waiting for
finish_unlink to remove added ed from ed_rm_list.
The main reason for hang in this race condtion is addition and removal
of ed from ed_rm_list in the beginning during usb_kill_urb and later
last* is modified in finish_unlinks().
As suggested by Alan Stern, the solution for proper handling of
ohci->ed_rm_list is to remove ed from the ed_rm_list before finishing
any URBs. Then at the end, we can add ed back to the list if necessary.
This properly handle the updated ohci->ed_rm_list in usb_kill_urb().
Fixes: 977dcfdc6031 ("USB: OHCI: don't lose track of EDs when a controller dies")
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
CC: <stable(a)vger.kernel.org>
Signed-off-by: Aman Deep <aman.deep(a)samsung.com>
Signed-off-by: Jeffy Chen <jeffy.chen(a)rock-chips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/ohci-q.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
--- a/drivers/usb/host/ohci-q.c
+++ b/drivers/usb/host/ohci-q.c
@@ -1018,6 +1018,8 @@ skip_ed:
* have modified this list. normally it's just prepending
* entries (which we'd ignore), but paranoia won't hurt.
*/
+ *last = ed->ed_next;
+ ed->ed_next = NULL;
modified = 0;
/* unlink urbs as requested, but rescan the list after
@@ -1076,21 +1078,22 @@ rescan_this:
goto rescan_this;
/*
- * If no TDs are queued, take ED off the ed_rm_list.
+ * If no TDs are queued, ED is now idle.
* Otherwise, if the HC is running, reschedule.
- * If not, leave it on the list for further dequeues.
+ * If the HC isn't running, add ED back to the
+ * start of the list for later processing.
*/
if (list_empty(&ed->td_list)) {
- *last = ed->ed_next;
- ed->ed_next = NULL;
ed->state = ED_IDLE;
list_del(&ed->in_use_list);
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
- *last = ed->ed_next;
- ed->ed_next = NULL;
ed_schedule(ohci, ed);
} else {
- last = &ed->ed_next;
+ ed->ed_next = ohci->ed_rm_list;
+ ohci->ed_rm_list = ed;
+ /* Don't loop on the same ED */
+ if (last == &ohci->ed_rm_list)
+ last = &ed->ed_next;
}
if (modified)
Patches currently in stable-queue which might be from aman.deep(a)samsung.com are
queue-4.9/usb-ohci-proper-handling-of-ed_rm_list-to-handle-race-condition-between-usb_kill_urb-and-finish_unlinks.patch
This is a note to let you know that I've just added the patch titled
usb: ldusb: add PIDs for new CASSY devices supported by this driver
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-ldusb-add-pids-for-new-cassy-devices-supported-by-this-driver.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 52ad2bd8918158266fc88a05f95429b56b6a33c5 Mon Sep 17 00:00:00 2001
From: Karsten Koop <kkoop(a)ld-didactic.de>
Date: Fri, 9 Feb 2018 09:12:06 +0000
Subject: usb: ldusb: add PIDs for new CASSY devices supported by this driver
From: Karsten Koop <kkoop(a)ld-didactic.de>
commit 52ad2bd8918158266fc88a05f95429b56b6a33c5 upstream.
This patch adds support for new CASSY devices to the ldusb driver. The
PIDs are also added to the ignore list in hid-quirks.
Signed-off-by: Karsten Koop <kkoop(a)ld-didactic.de>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-core.c | 3 +++
drivers/hid/hid-ids.h | 3 +++
drivers/usb/misc/ldusb.c | 6 ++++++
3 files changed, 12 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2443,6 +2443,9 @@ static const struct hid_device_id hid_ig
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTIME) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYPH) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_POWERANALYSERCASSY) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MACHINETESTCASSY) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_JWM) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_DMMP) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_UMIP) },
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -608,6 +608,9 @@
#define USB_DEVICE_ID_LD_MICROCASSYTIME 0x1033
#define USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE 0x1035
#define USB_DEVICE_ID_LD_MICROCASSYPH 0x1038
+#define USB_DEVICE_ID_LD_POWERANALYSERCASSY 0x1040
+#define USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY 0x1042
+#define USB_DEVICE_ID_LD_MACHINETESTCASSY 0x1043
#define USB_DEVICE_ID_LD_JWM 0x1080
#define USB_DEVICE_ID_LD_DMMP 0x1081
#define USB_DEVICE_ID_LD_UMIP 0x1090
--- a/drivers/usb/misc/ldusb.c
+++ b/drivers/usb/misc/ldusb.c
@@ -46,6 +46,9 @@
#define USB_DEVICE_ID_LD_MICROCASSYTIME 0x1033 /* USB Product ID of Micro-CASSY Time (reserved) */
#define USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE 0x1035 /* USB Product ID of Micro-CASSY Temperature */
#define USB_DEVICE_ID_LD_MICROCASSYPH 0x1038 /* USB Product ID of Micro-CASSY pH */
+#define USB_DEVICE_ID_LD_POWERANALYSERCASSY 0x1040 /* USB Product ID of Power Analyser CASSY */
+#define USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY 0x1042 /* USB Product ID of Converter Controller CASSY */
+#define USB_DEVICE_ID_LD_MACHINETESTCASSY 0x1043 /* USB Product ID of Machine Test CASSY */
#define USB_DEVICE_ID_LD_JWM 0x1080 /* USB Product ID of Joule and Wattmeter */
#define USB_DEVICE_ID_LD_DMMP 0x1081 /* USB Product ID of Digital Multimeter P (reserved) */
#define USB_DEVICE_ID_LD_UMIP 0x1090 /* USB Product ID of UMI P */
@@ -88,6 +91,9 @@ static const struct usb_device_id ld_usb
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTIME) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYPH) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_POWERANALYSERCASSY) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MACHINETESTCASSY) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_JWM) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_DMMP) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_UMIP) },
Patches currently in stable-queue which might be from kkoop(a)ld-didactic.de are
queue-4.9/usb-ldusb-add-pids-for-new-cassy-devices-supported-by-this-driver.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Process all descriptors during bind
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-f_fs-process-all-descriptors-during-bind.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 6cf439e0d37463e42784271179c8a308fd7493c6 Mon Sep 17 00:00:00 2001
From: Jack Pham <jackp(a)codeaurora.org>
Date: Wed, 24 Jan 2018 00:11:53 -0800
Subject: usb: gadget: f_fs: Process all descriptors during bind
From: Jack Pham <jackp(a)codeaurora.org>
commit 6cf439e0d37463e42784271179c8a308fd7493c6 upstream.
During _ffs_func_bind(), the received descriptors are evaluated
to prepare for binding with the gadget in order to allocate
endpoints and optionally set up OS descriptors. However, the
high- and super-speed descriptors are only parsed based on
whether the gadget_is_dualspeed() and gadget_is_superspeed()
calls are true, respectively.
This is a problem in case a userspace program always provides
all of the {full,high,super,OS} descriptors when configuring a
function. Then, for example if a gadget device is not capable
of SuperSpeed, the call to ffs_do_descs() for the SS descriptors
is skipped, resulting in an incorrect offset calculation for
the vla_ptr when moving on to the OS descriptors that follow.
This causes ffs_do_os_descs() to fail as it is now looking at
the SS descriptors' offset within the raw_descs buffer instead.
_ffs_func_bind() should evaluate the descriptors unconditionally,
so remove the checks for gadget speed.
Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support")
Cc: stable(a)vger.kernel.org
Co-Developed-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Jack Pham <jackp(a)codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/function/f_fs.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2956,10 +2956,8 @@ static int _ffs_func_bind(struct usb_con
struct ffs_data *ffs = func->ffs;
const int full = !!func->ffs->fs_descs_count;
- const int high = gadget_is_dualspeed(func->gadget) &&
- func->ffs->hs_descs_count;
- const int super = gadget_is_superspeed(func->gadget) &&
- func->ffs->ss_descs_count;
+ const int high = !!func->ffs->hs_descs_count;
+ const int super = !!func->ffs->ss_descs_count;
int fs_len, hs_len, ss_len, ret, i;
struct ffs_ep *eps_ptr;
Patches currently in stable-queue which might be from jackp(a)codeaurora.org are
queue-4.9/usb-gadget-f_fs-process-all-descriptors-during-bind.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: gadget: Set maxpacket size for ep0 IN
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-gadget-set-maxpacket-size-for-ep0-in.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 6180026341e852a250e1f97ebdcf71684a3c81b9 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 12 Jan 2018 18:18:05 -0800
Subject: usb: dwc3: gadget: Set maxpacket size for ep0 IN
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
commit 6180026341e852a250e1f97ebdcf71684a3c81b9 upstream.
There are 2 control endpoint structures for DWC3. However, the driver
only updates the OUT direction control endpoint structure during
ConnectDone event. DWC3 driver needs to update the endpoint max packet
size for control IN endpoint as well. If the max packet size is not
properly set, then the driver will incorrectly calculate the data
transfer size and fail to send ZLP for HS/FS 3-stage control read
transfer.
The fix is simply to update the max packet size for the ep0 IN direction
during ConnectDone event.
Cc: stable(a)vger.kernel.org
Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc3/gadget.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2528,6 +2528,8 @@ static void dwc3_gadget_conndone_interru
break;
}
+ dwc->eps[1]->endpoint.maxpacket = dwc->gadget.ep0->maxpacket;
+
/* Enable USB2 LPM Capability */
if ((dwc->revision > DWC3_REVISION_194A) &&
Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are
queue-4.9/usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch
This is a note to let you know that I've just added the patch titled
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
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:
scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.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 c39813652700f3df552b6557530f1e5f782dbe2f Mon Sep 17 00:00:00 2001
From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
Date: Tue, 23 Jan 2018 20:11:32 -0600
Subject: scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
commit c39813652700f3df552b6557530f1e5f782dbe2f upstream.
The fcp_rsp_info structure as defined in the FC spec has an initial 3
bytes reserved field. The ibmvfc driver mistakenly defined this field as
4 bytes resulting in the rsp_code field being defined in what should be
the start of the second reserved field and thus always being reported as
zero by the driver.
Ideally, we should wire ibmvfc up with libfc for the sake of code
deduplication, and ease of maintaining standardized structures in a
single place. However, for now simply fixup the definition in ibmvfc for
backporting to distros on older kernels. Wiring up with libfc will be
done in a followup patch.
Cc: <stable(a)vger.kernel.org>
Reported-by: Hannes Reinecke <hare(a)suse.de>
Signed-off-by: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/ibmvscsi/ibmvfc.h
+++ b/drivers/scsi/ibmvscsi/ibmvfc.h
@@ -367,7 +367,7 @@ enum ibmvfc_fcp_rsp_info_codes {
};
struct ibmvfc_fcp_rsp_info {
- __be16 reserved;
+ u8 reserved[3];
u8 rsp_code;
u8 reserved2[4];
}__attribute__((packed, aligned (2)));
Patches currently in stable-queue which might be from tyreld(a)linux.vnet.ibm.com are
queue-4.9/scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch
This is a note to let you know that I've just added the patch titled
Revert "usb: musb: host: don't start next rx urb if current one failed"
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:
revert-usb-musb-host-don-t-start-next-rx-urb-if-current-one-failed.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 44eb5e12b845cc8a0634f21b70ef07d774eb4b25 Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu(a)ti.com>
Date: Tue, 20 Feb 2018 07:31:35 -0600
Subject: Revert "usb: musb: host: don't start next rx urb if current one failed"
From: Bin Liu <b-liu(a)ti.com>
commit 44eb5e12b845cc8a0634f21b70ef07d774eb4b25 upstream.
This reverts commit dbac5d07d13e330e6706813c9fde477140fb5d80.
commit dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one failed")
along with commit b5801212229f ("usb: musb: host: clear rxcsr error bit if set")
try to solve the issue described in [1], but the latter alone is
sufficient, and the former causes the issue as in [2], so now revert it.
[1] https://marc.info/?l=linux-usb&m=146173995117456&w=2
[2] https://marc.info/?l=linux-usb&m=151689238420622&w=2
Cc: stable(a)vger.kernel.org # v4.7+
Signed-off-by: Bin Liu <b-liu(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/musb/musb_host.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -418,13 +418,7 @@ static void musb_advance_schedule(struct
}
}
- /*
- * The pipe must be broken if current urb->status is set, so don't
- * start next urb.
- * TODO: to minimize the risk of regression, only check urb->status
- * for RX, until we have a test case to understand the behavior of TX.
- */
- if ((!status || !is_in) && qh && qh->is_ready) {
+ if (qh != NULL && qh->is_ready) {
musb_dbg(musb, "... next ep%d %cX urb %p",
hw_ep->epnum, is_in ? 'R' : 'T', next_urb(qh));
musb_start_urb(musb, is_in, qh);
Patches currently in stable-queue which might be from b-liu(a)ti.com are
queue-4.9/revert-usb-musb-host-don-t-start-next-rx-urb-if-current-one-failed.patch
This is a note to let you know that I've just added the patch titled
RDMA/uverbs: Protect from command mask overflow
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:
rdma-uverbs-protect-from-command-mask-overflow.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 3f802b162dbf4a558ff98986449eddc717826209 Mon Sep 17 00:00:00 2001
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Tue, 13 Feb 2018 12:18:41 +0200
Subject: RDMA/uverbs: Protect from command mask overflow
From: Leon Romanovsky <leonro(a)mellanox.com>
commit 3f802b162dbf4a558ff98986449eddc717826209 upstream.
The command number is not bounds checked against the command mask before it
is shifted, resulting in an ubsan hit. This does not cause malfunction since
the command number is eventually bounds checked, but we can make this ubsan
clean by moving the bounds check to before the mask check.
================================================================================
UBSAN: Undefined behaviour in
drivers/infiniband/core/uverbs_main.c:647:21
shift exponent 207 is too large for 64-bit type 'long long unsigned int'
CPU: 0 PID: 446 Comm: syz-executor3 Not tainted 4.15.0-rc2+ #61
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
Call Trace:
dump_stack+0xde/0x164
? dma_virt_map_sg+0x22c/0x22c
ubsan_epilogue+0xe/0x81
__ubsan_handle_shift_out_of_bounds+0x293/0x2f7
? debug_check_no_locks_freed+0x340/0x340
? __ubsan_handle_load_invalid_value+0x19b/0x19b
? lock_acquire+0x440/0x440
? lock_acquire+0x19d/0x440
? __might_fault+0xf4/0x240
? ib_uverbs_write+0x68d/0xe20
ib_uverbs_write+0x68d/0xe20
? __lock_acquire+0xcf7/0x3940
? uverbs_devnode+0x110/0x110
? cyc2ns_read_end+0x10/0x10
? sched_clock_cpu+0x18/0x200
? sched_clock_cpu+0x18/0x200
__vfs_write+0x10d/0x700
? uverbs_devnode+0x110/0x110
? kernel_read+0x170/0x170
? __fget+0x35b/0x5d0
? security_file_permission+0x93/0x260
vfs_write+0x1b0/0x550
SyS_write+0xc7/0x1a0
? SyS_read+0x1a0/0x1a0
? trace_hardirqs_on_thunk+0x1a/0x1c
entry_SYSCALL_64_fastpath+0x18/0x85
RIP: 0033:0x448e29
RSP: 002b:00007f033f567c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f033f5686bc RCX: 0000000000448e29
RDX: 0000000000000060 RSI: 0000000020001000 RDI: 0000000000000012
RBP: 000000000070bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000056a0 R14: 00000000006e8740 R15: 0000000000000000
================================================================================
Cc: syzkaller <syzkaller(a)googlegroups.com>
Cc: <stable(a)vger.kernel.org> # 4.5
Fixes: 2dbd5186a39c ("IB/core: IB/core: Allow legacy verbs through extended interfaces")
Reported-by: Noa Osherovich <noaos(a)mellanox.com>
Reviewed-by: Matan Barak <matanb(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/uverbs_main.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)
--- a/drivers/infiniband/core/uverbs_main.c
+++ b/drivers/infiniband/core/uverbs_main.c
@@ -735,12 +735,21 @@ static int verify_command_mask(struct ib
return -1;
}
+static bool verify_command_idx(u32 command, bool extended)
+{
+ if (extended)
+ return command < ARRAY_SIZE(uverbs_ex_cmd_table);
+
+ return command < ARRAY_SIZE(uverbs_cmd_table);
+}
+
static ssize_t ib_uverbs_write(struct file *filp, const char __user *buf,
size_t count, loff_t *pos)
{
struct ib_uverbs_file *file = filp->private_data;
struct ib_device *ib_dev;
struct ib_uverbs_cmd_hdr hdr;
+ bool extended_command;
__u32 command;
__u32 flags;
int srcu_key;
@@ -770,6 +779,15 @@ static ssize_t ib_uverbs_write(struct fi
}
command = hdr.command & IB_USER_VERBS_CMD_COMMAND_MASK;
+ flags = (hdr.command &
+ IB_USER_VERBS_CMD_FLAGS_MASK) >> IB_USER_VERBS_CMD_FLAGS_SHIFT;
+
+ extended_command = flags & IB_USER_VERBS_CMD_FLAG_EXTENDED;
+ if (!verify_command_idx(command, extended_command)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
if (verify_command_mask(ib_dev, command)) {
ret = -EOPNOTSUPP;
goto out;
@@ -781,12 +799,8 @@ static ssize_t ib_uverbs_write(struct fi
goto out;
}
- flags = (hdr.command &
- IB_USER_VERBS_CMD_FLAGS_MASK) >> IB_USER_VERBS_CMD_FLAGS_SHIFT;
-
if (!flags) {
- if (command >= ARRAY_SIZE(uverbs_cmd_table) ||
- !uverbs_cmd_table[command]) {
+ if (!uverbs_cmd_table[command]) {
ret = -EINVAL;
goto out;
}
@@ -807,8 +821,7 @@ static ssize_t ib_uverbs_write(struct fi
struct ib_udata uhw;
size_t written_count = count;
- if (command >= ARRAY_SIZE(uverbs_ex_cmd_table) ||
- !uverbs_ex_cmd_table[command]) {
+ if (!uverbs_ex_cmd_table[command]) {
ret = -ENOSYS;
goto out;
}
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.9/rdma-uverbs-protect-from-command-mask-overflow.patch
This is a note to let you know that I've just added the patch titled
PKCS#7: fix certificate chain verification
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:
pkcs-7-fix-certificate-chain-verification.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 971b42c038dc83e3327872d294fe7131bab152fc Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Thu, 22 Feb 2018 14:38:33 +0000
Subject: PKCS#7: fix certificate chain verification
From: Eric Biggers <ebiggers(a)google.com>
commit 971b42c038dc83e3327872d294fe7131bab152fc upstream.
When pkcs7_verify_sig_chain() is building the certificate chain for a
SignerInfo using the certificates in the PKCS#7 message, it is passing
the wrong arguments to public_key_verify_signature(). Consequently,
when the next certificate is supposed to be used to verify the previous
certificate, the next certificate is actually used to verify itself.
An attacker can use this bug to create a bogus certificate chain that
has no cryptographic relationship between the beginning and end.
Fortunately I couldn't quite find a way to use this to bypass the
overall signature verification, though it comes very close. Here's the
reasoning: due to the bug, every certificate in the chain beyond the
first actually has to be self-signed (where "self-signed" here refers to
the actual key and signature; an attacker might still manipulate the
certificate fields such that the self_signed flag doesn't actually get
set, and thus the chain doesn't end immediately). But to pass trust
validation (pkcs7_validate_trust()), either the SignerInfo or one of the
certificates has to actually be signed by a trusted key. Since only
self-signed certificates can be added to the chain, the only way for an
attacker to introduce a trusted signature is to include a self-signed
trusted certificate.
But, when pkcs7_validate_trust_one() reaches that certificate, instead
of trying to verify the signature on that certificate, it will actually
look up the corresponding trusted key, which will succeed, and then try
to verify the *previous* certificate, which will fail. Thus, disaster
is narrowly averted (as far as I could tell).
Fixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier")
Cc: <stable(a)vger.kernel.org> # v4.7+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/asymmetric_keys/pkcs7_verify.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -261,7 +261,7 @@ static int pkcs7_verify_sig_chain(struct
sinfo->index);
return 0;
}
- ret = public_key_verify_signature(p->pub, p->sig);
+ ret = public_key_verify_signature(p->pub, x509->sig);
if (ret < 0)
return ret;
x509->signer = p;
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/x.509-fix-bug_on-when-hash-algorithm-is-unsupported.patch
queue-4.9/pkcs-7-fix-certificate-chain-verification.patch
This is a note to let you know that I've just added the patch titled
PCI/cxgb4: Extend T3 PCI quirk to T4+ devices
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:
pci-cxgb4-extend-t3-pci-quirk-to-t4-devices.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 7dcf688d4c78a18ba9538b2bf1b11dc7a43fe9be Mon Sep 17 00:00:00 2001
From: Casey Leedom <leedom(a)chelsio.com>
Date: Thu, 15 Feb 2018 20:03:18 +0530
Subject: PCI/cxgb4: Extend T3 PCI quirk to T4+ devices
From: Casey Leedom <leedom(a)chelsio.com>
commit 7dcf688d4c78a18ba9538b2bf1b11dc7a43fe9be upstream.
We've run into a problem where our device is attached
to a Virtual Machine and the use of the new pci_set_vpd_size()
API doesn't help. The VM kernel has been informed that
the accesses are okay, but all of the actual VPD Capability
Accesses are trapped down into the KVM Hypervisor where it
goes ahead and imposes the silent denials.
The right idea is to follow the kernel.org
commit 1c7de2b4ff88 ("PCI: Enable access to non-standard VPD for
Chelsio devices (cxgb3)") which Alexey Kardashevskiy authored
to establish a PCI Quirk for our T3-based adapters. This commit
extends that PCI Quirk to cover Chelsio T4 devices and later.
The advantage of this approach is that the VPD Size gets set early
in the Base OS/Hypervisor Boot and doesn't require that the cxgb4
driver even be available in the Base OS/Hypervisor. Thus PF4 can
be exported to a Virtual Machine and everything should work.
Fixes: 67e658794ca1 ("cxgb4: Set VPD size so we can read both VPD structures")
Cc: <stable(a)vger.kernel.org> # v4.9+
Signed-off-by: Casey Leedom <leedom(a)chelsio.com>
Signed-off-by: Arjun Vynipadath <arjun(a)chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr(a)chelsio.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 10 --------
drivers/pci/quirks.c | 35 +++++++++++++++++------------
2 files changed, 21 insertions(+), 24 deletions(-)
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -2596,7 +2596,6 @@ void t4_get_regs(struct adapter *adap, v
}
#define EEPROM_STAT_ADDR 0x7bfc
-#define VPD_SIZE 0x800
#define VPD_BASE 0x400
#define VPD_BASE_OLD 0
#define VPD_LEN 1024
@@ -2634,15 +2633,6 @@ int t4_get_raw_vpd_params(struct adapter
if (!vpd)
return -ENOMEM;
- /* We have two VPD data structures stored in the adapter VPD area.
- * By default, Linux calculates the size of the VPD area by traversing
- * the first VPD area at offset 0x0, so we need to tell the OS what
- * our real VPD size is.
- */
- ret = pci_set_vpd_size(adapter->pdev, VPD_SIZE);
- if (ret < 0)
- goto out;
-
/* Card information normally starts at VPD_BASE but early cards had
* it at 0.
*/
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3369,22 +3369,29 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IN
static void quirk_chelsio_extend_vpd(struct pci_dev *dev)
{
- pci_set_vpd_size(dev, 8192);
+ int chip = (dev->device & 0xf000) >> 12;
+ int func = (dev->device & 0x0f00) >> 8;
+ int prod = (dev->device & 0x00ff) >> 0;
+
+ /*
+ * If this is a T3-based adapter, there's a 1KB VPD area at offset
+ * 0xc00 which contains the preferred VPD values. If this is a T4 or
+ * later based adapter, the special VPD is at offset 0x400 for the
+ * Physical Functions (the SR-IOV Virtual Functions have no VPD
+ * Capabilities). The PCI VPD Access core routines will normally
+ * compute the size of the VPD by parsing the VPD Data Structure at
+ * offset 0x000. This will result in silent failures when attempting
+ * to accesses these other VPD areas which are beyond those computed
+ * limits.
+ */
+ if (chip == 0x0 && prod >= 0x20)
+ pci_set_vpd_size(dev, 8192);
+ else if (chip >= 0x4 && func < 0x8)
+ pci_set_vpd_size(dev, 2048);
}
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x20, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x21, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x22, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x23, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x24, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x25, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x26, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x30, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x31, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x32, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x35, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x36, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x37, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
+ quirk_chelsio_extend_vpd);
#ifdef CONFIG_ACPI
/*
Patches currently in stable-queue which might be from leedom(a)chelsio.com are
queue-4.9/pci-cxgb4-extend-t3-pci-quirk-to-t4-devices.patch
This is a note to let you know that I've just added the patch titled
ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()
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:
ohci-hcd-fix-race-condition-caused-by-ohci_urb_enqueue-and-io_watchdog_func.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 b2685bdacdaab065c172b97b55ab46c6be77a037 Mon Sep 17 00:00:00 2001
From: Shigeru Yoshida <shigeru.yoshida(a)windriver.com>
Date: Fri, 2 Feb 2018 13:51:39 +0800
Subject: ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()
From: Shigeru Yoshida <shigeru.yoshida(a)windriver.com>
commit b2685bdacdaab065c172b97b55ab46c6be77a037 upstream.
Running io_watchdog_func() while ohci_urb_enqueue() is running can
cause a race condition where ohci->prev_frame_no is corrupted and the
watchdog can mis-detect following error:
ohci-platform 664a0800.usb: frame counter not updating; disabled
ohci-platform 664a0800.usb: HC died; cleaning up
Specifically, following scenario causes a race condition:
1. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags)
and enters the critical section
2. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it
returns false
3. ohci_urb_enqueue() sets ohci->prev_frame_no to a frame number
read by ohci_frame_no(ohci)
4. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer()
5. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock,
flags) and exits the critical section
6. Later, ohci_urb_enqueue() is called
7. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags)
and enters the critical section
8. The timer scheduled on step 4 expires and io_watchdog_func() runs
9. io_watchdog_func() calls spin_lock_irqsave(&ohci->lock, flags)
and waits on it because ohci_urb_enqueue() is already in the
critical section on step 7
10. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it
returns false
11. ohci_urb_enqueue() sets ohci->prev_frame_no to new frame number
read by ohci_frame_no(ohci) because the frame number proceeded
between step 3 and 6
12. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer()
13. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock,
flags) and exits the critical section, then wake up
io_watchdog_func() which is waiting on step 9
14. io_watchdog_func() enters the critical section
15. io_watchdog_func() calls ohci_frame_no(ohci) and set frame_no
variable to the frame number
16. io_watchdog_func() compares frame_no and ohci->prev_frame_no
On step 16, because this calling of io_watchdog_func() is scheduled on
step 4, the frame number set in ohci->prev_frame_no is expected to the
number set on step 3. However, ohci->prev_frame_no is overwritten on
step 11. Because step 16 is executed soon after step 11, the frame
number might not proceed, so ohci->prev_frame_no must equals to
frame_no.
To address above scenario, this patch introduces a special sentinel
value IO_WATCHDOG_OFF and set this value to ohci->prev_frame_no when
the watchdog is not pending or running. When ohci_urb_enqueue()
schedules the watchdog (step 4 and 12 above), it compares
ohci->prev_frame_no to IO_WATCHDOG_OFF so that ohci->prev_frame_no is
not overwritten while io_watchdog_func() is running.
Signed-off-by: Shigeru Yoshida <Shigeru.Yoshida(a)windriver.com>
Signed-off-by: Haiqing Bai <Haiqing.Bai(a)windriver.com>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/ohci-hcd.c | 10 +++++++---
drivers/usb/host/ohci-hub.c | 4 +++-
2 files changed, 10 insertions(+), 4 deletions(-)
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -73,6 +73,7 @@ static const char hcd_name [] = "ohci_hc
#define STATECHANGE_DELAY msecs_to_jiffies(300)
#define IO_WATCHDOG_DELAY msecs_to_jiffies(275)
+#define IO_WATCHDOG_OFF 0xffffff00
#include "ohci.h"
#include "pci-quirks.h"
@@ -230,7 +231,7 @@ static int ohci_urb_enqueue (
}
/* Start up the I/O watchdog timer, if it's not running */
- if (!timer_pending(&ohci->io_watchdog) &&
+ if (ohci->prev_frame_no == IO_WATCHDOG_OFF &&
list_empty(&ohci->eds_in_use) &&
!(ohci->flags & OHCI_QUIRK_QEMU)) {
ohci->prev_frame_no = ohci_frame_no(ohci);
@@ -501,6 +502,7 @@ static int ohci_init (struct ohci_hcd *o
setup_timer(&ohci->io_watchdog, io_watchdog_func,
(unsigned long) ohci);
+ ohci->prev_frame_no = IO_WATCHDOG_OFF;
ohci->hcca = dma_alloc_coherent (hcd->self.controller,
sizeof(*ohci->hcca), &ohci->hcca_dma, GFP_KERNEL);
@@ -730,7 +732,7 @@ static void io_watchdog_func(unsigned lo
u32 head;
struct ed *ed;
struct td *td, *td_start, *td_next;
- unsigned frame_no;
+ unsigned frame_no, prev_frame_no = IO_WATCHDOG_OFF;
unsigned long flags;
spin_lock_irqsave(&ohci->lock, flags);
@@ -835,7 +837,7 @@ static void io_watchdog_func(unsigned lo
}
}
if (!list_empty(&ohci->eds_in_use)) {
- ohci->prev_frame_no = frame_no;
+ prev_frame_no = frame_no;
ohci->prev_wdh_cnt = ohci->wdh_cnt;
ohci->prev_donehead = ohci_readl(ohci,
&ohci->regs->donehead);
@@ -845,6 +847,7 @@ static void io_watchdog_func(unsigned lo
}
done:
+ ohci->prev_frame_no = prev_frame_no;
spin_unlock_irqrestore(&ohci->lock, flags);
}
@@ -973,6 +976,7 @@ static void ohci_stop (struct usb_hcd *h
if (quirk_nec(ohci))
flush_work(&ohci->nec_work);
del_timer_sync(&ohci->io_watchdog);
+ ohci->prev_frame_no = IO_WATCHDOG_OFF;
ohci_writel (ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
ohci_usb_reset(ohci);
--- a/drivers/usb/host/ohci-hub.c
+++ b/drivers/usb/host/ohci-hub.c
@@ -310,8 +310,10 @@ static int ohci_bus_suspend (struct usb_
rc = ohci_rh_suspend (ohci, 0);
spin_unlock_irq (&ohci->lock);
- if (rc == 0)
+ if (rc == 0) {
del_timer_sync(&ohci->io_watchdog);
+ ohci->prev_frame_no = IO_WATCHDOG_OFF;
+ }
return rc;
}
Patches currently in stable-queue which might be from shigeru.yoshida(a)windriver.com are
queue-4.9/ohci-hcd-fix-race-condition-caused-by-ohci_urb_enqueue-and-io_watchdog_func.patch
This is a note to let you know that I've just added the patch titled
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
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:
irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.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 21ec30c0ef5234fb1039cc7c7737d885bf875a9e Mon Sep 17 00:00:00 2001
From: Shanker Donthineni <shankerd(a)codeaurora.org>
Date: Wed, 31 Jan 2018 18:03:42 -0600
Subject: irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
From: Shanker Donthineni <shankerd(a)codeaurora.org>
commit 21ec30c0ef5234fb1039cc7c7737d885bf875a9e upstream.
A DMB instruction can be used to ensure the relative order of only
memory accesses before and after the barrier. Since writes to system
registers are not memory operations, barrier DMB is not sufficient
for observability of memory accesses that occur before ICC_SGI1R_EL1
writes.
A DSB instruction ensures that no instructions that appear in program
order after the DSB instruction, can execute until the DSB instruction
has completed.
Cc: stable(a)vger.kernel.org
Acked-by: Will Deacon <will.deacon(a)arm.com>,
Signed-off-by: Shanker Donthineni <shankerd(a)codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -616,7 +616,7 @@ static void gic_raise_softirq(const stru
* Ensure that stores to Normal memory are visible to the
* other CPUs before issuing the IPI.
*/
- smp_wmb();
+ wmb();
for_each_cpu(cpu, mask) {
unsigned long cluster_id = cpu_logical_map(cpu) & ~0xffUL;
Patches currently in stable-queue which might be from shankerd(a)codeaurora.org are
queue-4.9/irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch
This is a note to let you know that I've just added the patch titled
iio: adis_lib: Initialize trigger before requesting interrupt
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:
iio-adis_lib-initialize-trigger-before-requesting-interrupt.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 f027e0b3a774e10302207e91d304bbf99e3a8b36 Mon Sep 17 00:00:00 2001
From: Lars-Peter Clausen <lars(a)metafoo.de>
Date: Wed, 14 Feb 2018 15:43:00 +0100
Subject: iio: adis_lib: Initialize trigger before requesting interrupt
From: Lars-Peter Clausen <lars(a)metafoo.de>
commit f027e0b3a774e10302207e91d304bbf99e3a8b36 upstream.
The adis_probe_trigger() creates a new IIO trigger and requests an
interrupt associated with the trigger. The interrupt uses the generic
iio_trigger_generic_data_rdy_poll() function as its interrupt handler.
Currently the driver initializes some fields of the trigger structure after
the interrupt has been requested. But an interrupt can fire as soon as it
has been requested. This opens up a race condition.
iio_trigger_generic_data_rdy_poll() will access the trigger data structure
and dereference the ops field. If the ops field is not yet initialized this
will result in a NULL pointer deref.
It is not expected that the device generates an interrupt at this point, so
typically this issue did not surface unless e.g. due to a hardware
misconfiguration (wrong interrupt number, wrong polarity, etc.).
But some newer devices from the ADIS family start to generate periodic
interrupts in their power-on reset configuration and unfortunately the
interrupt can not be masked in the device. This makes the race condition
much more visible and the following crash has been observed occasionally
when booting a system using the ADIS16460.
Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = c0004000
[00000008] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257
Hardware name: Xilinx Zynq Platform
task: ef04f640 task.stack: ef050000
PC is at iio_trigger_notify_done+0x30/0x68
LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20
pc : [<c042d868>] lr : [<c042d924>] psr: 60000193
sp : ef051bb8 ip : 00000000 fp : ef106400
r10: c081d80a r9 : ef3bfa00 r8 : 00000087
r7 : ef051bec r6 : 00000000 r5 : ef3bfa00 r4 : ee92ab00
r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : ee97e400
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 18c5387d Table: 0000404a DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xef050210)
[<c042d868>] (iio_trigger_notify_done) from [<c0065b10>] (__handle_irq_event_percpu+0x88/0x118)
[<c0065b10>] (__handle_irq_event_percpu) from [<c0065bbc>] (handle_irq_event_percpu+0x1c/0x58)
[<c0065bbc>] (handle_irq_event_percpu) from [<c0065c30>] (handle_irq_event+0x38/0x5c)
[<c0065c30>] (handle_irq_event) from [<c0068e28>] (handle_level_irq+0xa4/0x130)
[<c0068e28>] (handle_level_irq) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c021ab7c>] (zynq_gpio_irqhandler+0xb8/0x13c)
[<c021ab7c>] (zynq_gpio_irqhandler) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c0065370>] (__handle_domain_irq+0x5c/0xb4)
[<c0065370>] (__handle_domain_irq) from [<c000940c>] (gic_handle_irq+0x48/0x8c)
[<c000940c>] (gic_handle_irq) from [<c0013e8c>] (__irq_svc+0x6c/0xa8)
To fix this make sure that the trigger is fully initialized before
requesting the interrupt.
Fixes: ccd2b52f4ac6 ("staging:iio: Add common ADIS library")
Reported-by: Robin Getz <Robin.Getz(a)analog.com>
Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de>
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/imu/adis_trigger.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/iio/imu/adis_trigger.c
+++ b/drivers/iio/imu/adis_trigger.c
@@ -47,6 +47,10 @@ int adis_probe_trigger(struct adis *adis
if (adis->trig == NULL)
return -ENOMEM;
+ adis->trig->dev.parent = &adis->spi->dev;
+ adis->trig->ops = &adis_trigger_ops;
+ iio_trigger_set_drvdata(adis->trig, adis);
+
ret = request_irq(adis->spi->irq,
&iio_trigger_generic_data_rdy_poll,
IRQF_TRIGGER_RISING,
@@ -55,9 +59,6 @@ int adis_probe_trigger(struct adis *adis
if (ret)
goto error_free_trig;
- adis->trig->dev.parent = &adis->spi->dev;
- adis->trig->ops = &adis_trigger_ops;
- iio_trigger_set_drvdata(adis->trig, adis);
ret = iio_trigger_register(adis->trig);
indio_dev->trig = iio_trigger_get(adis->trig);
Patches currently in stable-queue which might be from lars(a)metafoo.de are
queue-4.9/iio-adis_lib-initialize-trigger-before-requesting-interrupt.patch
This is a note to let you know that I've just added the patch titled
iio: buffer: check if a buffer has been set up when poll is called
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:
iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.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 4cd140bda6494543f1c1b0ccceceaa44b676eef6 Mon Sep 17 00:00:00 2001
From: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
Date: Thu, 15 Feb 2018 15:02:53 +0100
Subject: iio: buffer: check if a buffer has been set up when poll is called
From: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
commit 4cd140bda6494543f1c1b0ccceceaa44b676eef6 upstream.
If no iio buffer has been set up and poll is called return 0.
Without this check there will be a null pointer dereference when
calling poll on a iio driver without an iio buffer.
Cc: stable(a)vger.kernel.org
Signed-off-by: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/industrialio-buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -174,7 +174,7 @@ unsigned int iio_buffer_poll(struct file
struct iio_dev *indio_dev = filp->private_data;
struct iio_buffer *rb = indio_dev->buffer;
- if (!indio_dev->info)
+ if (!indio_dev->info || rb == NULL)
return 0;
poll_wait(filp, &rb->pollq, wait);
Patches currently in stable-queue which might be from stefan.windfeldt(a)axis.com are
queue-4.9/iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
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:
drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.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 458d876eb869d5a88b53074c6c271b8b9adc0f07 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Mon, 22 Jan 2018 23:13:32 -0500
Subject: drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
From: Alex Deucher <alexander.deucher(a)amd.com>
commit 458d876eb869d5a88b53074c6c271b8b9adc0f07 upstream.
We only support vga_switcheroo and runtime pm on PX/HG systems
so forcing runpm to 1 doesn't do anything useful anyway.
Only call vga_switcheroo_init_domain_pm_ops() for PX/HG so
that the cleanup path is correct as well. This mirrors what
radeon does as well.
v2: rework the patch originally sent by Lukas (Alex)
Acked-by: Lukas Wunner <lukas(a)wunner.de>
Reported-by: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de> (v1)
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1678,8 +1678,6 @@ int amdgpu_device_init(struct amdgpu_dev
* ignore it */
vga_client_register(adev->pdev, adev, NULL, amdgpu_vga_set_decode);
- if (amdgpu_runtime_pm == 1)
- runtime = true;
if (amdgpu_device_is_px(ddev))
runtime = true;
vga_switcheroo_register_client(adev->pdev, &amdgpu_switcheroo_ops, runtime);
Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are
queue-4.9/drm-amdgpu-add-new-device-to-use-atpx-quirk.patch
queue-4.9/drm-amdgpu-add-dpm-quirk-for-jet-pro-v2.patch
queue-4.9/drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.patch
queue-4.9/drm-amdgpu-add-atpx-quirk-handling-v2.patch
This is a note to let you know that I've just added the patch titled
drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
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:
drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.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 06998a756a3865817b87a129a7e5d5bb66dc1ec3 Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Sun, 18 Feb 2018 16:53:59 +0800
Subject: drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit 06998a756a3865817b87a129a7e5d5bb66dc1ec3 upstream.
Similar to commit e10aec652f31 ("drm/edid: Add 6 bpc quirk for display
AEO model 0."), the EDID reports "DFP 1.x compliant TMDS" but it support
6bpc instead of 8 bpc.
Hence, use 6 bpc quirk for this panel.
Fixes: 196f954e2509 ("drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"")
BugLink: https://bugs.launchpad.net/bugs/1749420
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de(a)gmail.com>
Cc: <stable(a)vger.kernel.org> # v4.8+
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180218085359.7817-1-kai.hen…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -107,6 +107,9 @@ static const struct edid_quirk {
/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
{ "AEO", 0, EDID_QUIRK_FORCE_6BPC },
+ /* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */
+ { "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC },
+
/* Belinea 10 15 55 */
{ "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
{ "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.9/drm-amdgpu-add-new-device-to-use-atpx-quirk.patch
queue-4.9/drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: add new device to use atpx quirk
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:
drm-amdgpu-add-new-device-to-use-atpx-quirk.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 6e59de2048eb375a9bfcd39461ef841cd2a78962 Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Thu, 8 Feb 2018 17:46:01 +0800
Subject: drm/amdgpu: add new device to use atpx quirk
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit 6e59de2048eb375a9bfcd39461ef841cd2a78962 upstream.
The affected system (0x0813) is pretty similar to another one (0x0812),
it also needs to use ATPX power control.
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
@@ -568,6 +568,7 @@ static const struct amdgpu_px_quirk amdg
/* HG _PR3 doesn't seem to work on this A+A weston board */
{ 0x1002, 0x6900, 0x1002, 0x0124, AMDGPU_PX_QUIRK_FORCE_ATPX },
{ 0x1002, 0x6900, 0x1028, 0x0812, AMDGPU_PX_QUIRK_FORCE_ATPX },
+ { 0x1002, 0x6900, 0x1028, 0x0813, AMDGPU_PX_QUIRK_FORCE_ATPX },
{ 0, 0, 0, 0, 0 },
};
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.9/drm-amdgpu-add-new-device-to-use-atpx-quirk.patch
queue-4.9/drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: Add dpm quirk for Jet PRO (v2)
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:
drm-amdgpu-add-dpm-quirk-for-jet-pro-v2.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 f2e5262f75ecb40a6e56554e156a292ab9e1d1b7 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Tue, 21 Nov 2017 12:10:57 -0500
Subject: drm/amdgpu: Add dpm quirk for Jet PRO (v2)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Alex Deucher <alexander.deucher(a)amd.com>
commit f2e5262f75ecb40a6e56554e156a292ab9e1d1b7 upstream.
Fixes stability issues.
v2: clamp sclk to 600 Mhz
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103370
Acked-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
@@ -3507,6 +3507,11 @@ static void si_apply_state_adjust_rules(
max_sclk = 75000;
max_mclk = 80000;
}
+ if ((adev->pdev->revision == 0xC3) ||
+ (adev->pdev->device == 0x6665)) {
+ max_sclk = 60000;
+ max_mclk = 80000;
+ }
} else if (adev->asic_type == CHIP_OLAND) {
if ((adev->pdev->revision == 0xC7) ||
(adev->pdev->revision == 0x80) ||
Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are
queue-4.9/drm-amdgpu-add-new-device-to-use-atpx-quirk.patch
queue-4.9/drm-amdgpu-add-dpm-quirk-for-jet-pro-v2.patch
queue-4.9/drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.patch
queue-4.9/drm-amdgpu-add-atpx-quirk-handling-v2.patch
This is a note to let you know that I've just added the patch titled
cfg80211: fix cfg80211_beacon_dup
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:
cfg80211-fix-cfg80211_beacon_dup.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 bee92d06157fc39d5d7836a061c7d41289a55797 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Fri, 2 Feb 2018 16:31:23 +0100
Subject: cfg80211: fix cfg80211_beacon_dup
From: Arnd Bergmann <arnd(a)arndb.de>
commit bee92d06157fc39d5d7836a061c7d41289a55797 upstream.
gcc-8 warns about some obviously incorrect code:
net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':
net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
>From the context, I conclude that we want to copy from beacon into
new_beacon, as we do in the rest of the function.
Cc: stable(a)vger.kernel.org
Fixes: 73da7d5bab79 ("mac80211: add channel switch command and beacon callbacks")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2792,7 +2792,7 @@ cfg80211_beacon_dup(struct cfg80211_beac
}
if (beacon->probe_resp_len) {
new_beacon->probe_resp_len = beacon->probe_resp_len;
- beacon->probe_resp = pos;
+ new_beacon->probe_resp = pos;
memcpy(pos, beacon->probe_resp, beacon->probe_resp_len);
pos += beacon->probe_resp_len;
}
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.9/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-4.9/cfg80211-fix-cfg80211_beacon_dup.patch
queue-4.9/kbuild-always-define-endianess-in-kconfig.h.patch
This is a note to let you know that I've just added the patch titled
arm64: Disable unhandled signal log messages by default
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:
arm64-disable-unhandled-signal-log-messages-by-default.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 5ee39a71fd89ab7240c5339d04161c44a8e03269 Mon Sep 17 00:00:00 2001
From: Michael Weiser <michael.weiser(a)gmx.de>
Date: Thu, 1 Feb 2018 23:13:38 +0100
Subject: arm64: Disable unhandled signal log messages by default
From: Michael Weiser <michael.weiser(a)gmx.de>
commit 5ee39a71fd89ab7240c5339d04161c44a8e03269 upstream.
aarch64 unhandled signal kernel messages are very verbose, suggesting
them to be more of a debugging aid:
sigsegv[33]: unhandled level 2 translation fault (11) at 0x00000000, esr
0x92000046, in sigsegv[400000+71000]
CPU: 1 PID: 33 Comm: sigsegv Tainted: G W 4.15.0-rc3+ #3
Hardware name: linux,dummy-virt (DT)
pstate: 60000000 (nZCv daif -PAN -UAO)
pc : 0x4003f4
lr : 0x4006bc
sp : 0000fffffe94a060
x29: 0000fffffe94a070 x28: 0000000000000000
x27: 0000000000000000 x26: 0000000000000000
x25: 0000000000000000 x24: 00000000004001b0
x23: 0000000000486ac8 x22: 00000000004001c8
x21: 0000000000000000 x20: 0000000000400be8
x19: 0000000000400b30 x18: 0000000000484728
x17: 000000000865ffc8 x16: 000000000000270f
x15: 00000000000000b0 x14: 0000000000000002
x13: 0000000000000001 x12: 0000000000000000
x11: 0000000000000000 x10: 0008000020008008
x9 : 000000000000000f x8 : ffffffffffffffff
x7 : 0004000000000000 x6 : ffffffffffffffff
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 00000000004003e4 x2 : 0000fffffe94a1e8
x1 : 000000000000000a x0 : 0000000000000000
Disable them by default, so they can be enabled using
/proc/sys/debug/exception-trace.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Michael Weiser <michael.weiser(a)gmx.de>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/kernel/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -50,7 +50,7 @@ static const char *handler[]= {
"Error"
};
-int show_unhandled_signals = 1;
+int show_unhandled_signals = 0;
/*
* Dump out the contents of some kernel memory nicely...
Patches currently in stable-queue which might be from michael.weiser(a)gmx.de are
queue-4.9/arm64-disable-unhandled-signal-log-messages-by-default.patch
This is a note to let you know that I've just added the patch titled
Add delay-init quirk for Corsair K70 RGB keyboards
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:
add-delay-init-quirk-for-corsair-k70-rgb-keyboards.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 7a1646d922577b5b48c0d222e03831141664bb59 Mon Sep 17 00:00:00 2001
From: Jack Stocker <jackstocker.93(a)gmail.com>
Date: Thu, 15 Feb 2018 18:24:10 +0000
Subject: Add delay-init quirk for Corsair K70 RGB keyboards
From: Jack Stocker <jackstocker.93(a)gmail.com>
commit 7a1646d922577b5b48c0d222e03831141664bb59 upstream.
Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
start correctly at boot.
Device ids found here:
usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-3: Product: Corsair K70 RGB Gaming Keyboard
Signed-off-by: Jack Stocker <jackstocker.93(a)gmail.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -225,6 +225,9 @@ static const struct usb_device_id usb_qu
{ USB_DEVICE(0x1a0a, 0x0200), .driver_info =
USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
+ /* Corsair K70 RGB */
+ { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* Corsair Strafe RGB */
{ USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
Patches currently in stable-queue which might be from jackstocker.93(a)gmail.com are
queue-4.9/add-delay-init-quirk-for-corsair-k70-rgb-keyboards.patch
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From d61a5c1063515e855bedb1b81e20e50b0ac3541e Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Sun, 11 Feb 2018 10:38:28 +0100
Subject: [PATCH] drm/nouveau: Fix deadlock on runtime suspend
nouveau's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.
The output poll worker meanwhile calls pm_runtime_get_sync() in
nouveau_connector_detect() which waits for the ongoing suspend to finish,
causing a deadlock.
Fix by not acquiring a runtime PM ref if nouveau_connector_detect() is
called in the output poll worker's context. This is safe because
the poll worker is only enabled while runtime active and we know that
->runtime_suspend waits for it to finish.
Other contexts calling nouveau_connector_detect() do require a runtime
PM ref, these comprise:
status_store() drm sysfs interface
->fill_modes drm callback
drm_fb_helper_probe_connector_modes()
drm_mode_getconnector()
nouveau_connector_hotplug()
nouveau_display_hpd_work()
nv17_tv_set_property()
Stack trace for posterity:
INFO: task kworker/0:1:58 blocked for more than 120 seconds.
Workqueue: events output_poll_execute [drm_kms_helper]
Call Trace:
schedule+0x28/0x80
rpm_resume+0x107/0x6e0
__pm_runtime_resume+0x47/0x70
nouveau_connector_detect+0x7e/0x4a0 [nouveau]
nouveau_connector_detect_lvds+0x132/0x180 [nouveau]
drm_helper_probe_detect_ctx+0x85/0xd0 [drm_kms_helper]
output_poll_execute+0x11e/0x1c0 [drm_kms_helper]
process_one_work+0x184/0x380
worker_thread+0x2e/0x390
INFO: task kworker/0:2:252 blocked for more than 120 seconds.
Workqueue: pm pm_runtime_work
Call Trace:
schedule+0x28/0x80
schedule_timeout+0x1e3/0x370
wait_for_completion+0x123/0x190
flush_work+0x142/0x1c0
nouveau_pmops_runtime_suspend+0x7e/0xd0 [nouveau]
pci_pm_runtime_suspend+0x5c/0x180
vga_switcheroo_runtime_suspend+0x1e/0xa0
__rpm_callback+0xc1/0x200
rpm_callback+0x1f/0x70
rpm_suspend+0x13c/0x640
pm_runtime_work+0x6e/0x90
process_one_work+0x184/0x380
worker_thread+0x2e/0x390
Bugzilla: https://bugs.archlinux.org/task/53497
Bugzilla: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870523
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388#c33
Fixes: 5addcf0a5f0f ("nouveau: add runtime PM support (v0.9)")
Cc: stable(a)vger.kernel.org # v3.12+: 27d4ee03078a: workqueue: Allow retrieval of current task's work struct
Cc: stable(a)vger.kernel.org # v3.12+: 25c058ccaf2e: drm: Allow determining if current task is output poll worker
Cc: Ben Skeggs <bskeggs(a)redhat.com>
Cc: Dave Airlie <airlied(a)redhat.com>
Reviewed-by: Lyude Paul <lyude(a)redhat.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/b7d2cbb609a80f59ccabfdf479b9d…
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 69d6e61a01ec..6ed9cb053dfa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -570,9 +570,15 @@ nouveau_connector_detect(struct drm_connector *connector, bool force)
nv_connector->edid = NULL;
}
- ret = pm_runtime_get_sync(connector->dev->dev);
- if (ret < 0 && ret != -EACCES)
- return conn_status;
+ /* Outputs are only polled while runtime active, so acquiring a
+ * runtime PM ref here is unnecessary (and would deadlock upon
+ * runtime suspend because it waits for polling to finish).
+ */
+ if (!drm_kms_helper_is_poll_worker()) {
+ ret = pm_runtime_get_sync(connector->dev->dev);
+ if (ret < 0 && ret != -EACCES)
+ return conn_status;
+ }
nv_encoder = nouveau_connector_ddc_detect(connector);
if (nv_encoder && (i2c = nv_encoder->i2c) != NULL) {
@@ -647,8 +653,10 @@ nouveau_connector_detect(struct drm_connector *connector, bool force)
out:
- pm_runtime_mark_last_busy(connector->dev->dev);
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (!drm_kms_helper_is_poll_worker()) {
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ }
return conn_status;
}
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From d61a5c1063515e855bedb1b81e20e50b0ac3541e Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Sun, 11 Feb 2018 10:38:28 +0100
Subject: [PATCH] drm/nouveau: Fix deadlock on runtime suspend
nouveau's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.
The output poll worker meanwhile calls pm_runtime_get_sync() in
nouveau_connector_detect() which waits for the ongoing suspend to finish,
causing a deadlock.
Fix by not acquiring a runtime PM ref if nouveau_connector_detect() is
called in the output poll worker's context. This is safe because
the poll worker is only enabled while runtime active and we know that
->runtime_suspend waits for it to finish.
Other contexts calling nouveau_connector_detect() do require a runtime
PM ref, these comprise:
status_store() drm sysfs interface
->fill_modes drm callback
drm_fb_helper_probe_connector_modes()
drm_mode_getconnector()
nouveau_connector_hotplug()
nouveau_display_hpd_work()
nv17_tv_set_property()
Stack trace for posterity:
INFO: task kworker/0:1:58 blocked for more than 120 seconds.
Workqueue: events output_poll_execute [drm_kms_helper]
Call Trace:
schedule+0x28/0x80
rpm_resume+0x107/0x6e0
__pm_runtime_resume+0x47/0x70
nouveau_connector_detect+0x7e/0x4a0 [nouveau]
nouveau_connector_detect_lvds+0x132/0x180 [nouveau]
drm_helper_probe_detect_ctx+0x85/0xd0 [drm_kms_helper]
output_poll_execute+0x11e/0x1c0 [drm_kms_helper]
process_one_work+0x184/0x380
worker_thread+0x2e/0x390
INFO: task kworker/0:2:252 blocked for more than 120 seconds.
Workqueue: pm pm_runtime_work
Call Trace:
schedule+0x28/0x80
schedule_timeout+0x1e3/0x370
wait_for_completion+0x123/0x190
flush_work+0x142/0x1c0
nouveau_pmops_runtime_suspend+0x7e/0xd0 [nouveau]
pci_pm_runtime_suspend+0x5c/0x180
vga_switcheroo_runtime_suspend+0x1e/0xa0
__rpm_callback+0xc1/0x200
rpm_callback+0x1f/0x70
rpm_suspend+0x13c/0x640
pm_runtime_work+0x6e/0x90
process_one_work+0x184/0x380
worker_thread+0x2e/0x390
Bugzilla: https://bugs.archlinux.org/task/53497
Bugzilla: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870523
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388#c33
Fixes: 5addcf0a5f0f ("nouveau: add runtime PM support (v0.9)")
Cc: stable(a)vger.kernel.org # v3.12+: 27d4ee03078a: workqueue: Allow retrieval of current task's work struct
Cc: stable(a)vger.kernel.org # v3.12+: 25c058ccaf2e: drm: Allow determining if current task is output poll worker
Cc: Ben Skeggs <bskeggs(a)redhat.com>
Cc: Dave Airlie <airlied(a)redhat.com>
Reviewed-by: Lyude Paul <lyude(a)redhat.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/b7d2cbb609a80f59ccabfdf479b9d…
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 69d6e61a01ec..6ed9cb053dfa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -570,9 +570,15 @@ nouveau_connector_detect(struct drm_connector *connector, bool force)
nv_connector->edid = NULL;
}
- ret = pm_runtime_get_sync(connector->dev->dev);
- if (ret < 0 && ret != -EACCES)
- return conn_status;
+ /* Outputs are only polled while runtime active, so acquiring a
+ * runtime PM ref here is unnecessary (and would deadlock upon
+ * runtime suspend because it waits for polling to finish).
+ */
+ if (!drm_kms_helper_is_poll_worker()) {
+ ret = pm_runtime_get_sync(connector->dev->dev);
+ if (ret < 0 && ret != -EACCES)
+ return conn_status;
+ }
nv_encoder = nouveau_connector_ddc_detect(connector);
if (nv_encoder && (i2c = nv_encoder->i2c) != NULL) {
@@ -647,8 +653,10 @@ nouveau_connector_detect(struct drm_connector *connector, bool force)
out:
- pm_runtime_mark_last_busy(connector->dev->dev);
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (!drm_kms_helper_is_poll_worker()) {
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ }
return conn_status;
}
This is a note to let you know that I've just added the patch titled
x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
to the 4.4-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:
x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
and it can be found in the queue-4.4 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 85c615eb52222bc5fab6c7190d146bc59fac289e Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 20 Feb 2018 21:58:21 +0100
Subject: x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
From: Arnd Bergmann <arnd(a)arndb.de>
commit 85c615eb52222bc5fab6c7190d146bc59fac289e upstream.
GCC-8 shows a warning for the x86 oprofile code that copies per-CPU
data from CPU 0 to all other CPUs, which when building a non-SMP
kernel turns into a memcpy() with identical source and destination
pointers:
arch/x86/oprofile/nmi_int.c: In function 'mux_clone':
arch/x86/oprofile/nmi_int.c:285:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
memcpy(per_cpu(cpu_msrs, cpu).multiplex,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
per_cpu(cpu_msrs, 0).multiplex,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(struct op_msr) * model->num_virt_counters);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/oprofile/nmi_int.c: In function 'nmi_setup':
arch/x86/oprofile/nmi_int.c:466:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
arch/x86/oprofile/nmi_int.c:470:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
I have analyzed a number of such warnings now: some are valid and the
GCC warning is welcome. Others turned out to be false-positives, and
GCC was changed to not warn about those any more. This is a corner case
that is a false-positive but the GCC developers feel it's better to keep
warning about it.
In this case, it seems best to work around it by telling GCC
a little more clearly that this code path is never hit with
an IS_ENABLED() configuration check.
Cc:stable as we also want old kernels to build cleanly with GCC-8.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Jessica Yu <jeyu(a)kernel.org>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Martin Sebor <msebor(a)gcc.gnu.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Robert Richter <rric(a)kernel.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: oprofile-list(a)lists.sf.net
Cc: stable(a)vger.kernel.org
Link: http://lkml.kernel.org/r/20180220205826.2008875-1-arnd@arndb.de
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/oprofile/nmi_int.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/oprofile/nmi_int.c
+++ b/arch/x86/oprofile/nmi_int.c
@@ -471,7 +471,7 @@ static int nmi_setup(void)
goto fail;
for_each_possible_cpu(cpu) {
- if (!cpu)
+ if (!IS_ENABLED(CONFIG_SMP) || !cpu)
continue;
memcpy(per_cpu(cpu_msrs, cpu).counters,
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-4.4/cfg80211-fix-cfg80211_beacon_dup.patch
This is a note to let you know that I've just added the patch titled
usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
to the 4.4-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-renesas_usbhs-missed-the-running-flag-in-usb_dmac-with-rx-path.patch
and it can be found in the queue-4.4 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 17aa31f13cad25daa19d3f923323f552e87bc874 Mon Sep 17 00:00:00 2001
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Date: Mon, 5 Feb 2018 17:12:35 +0900
Subject: usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
commit 17aa31f13cad25daa19d3f923323f552e87bc874 upstream.
This fixes an issue that a gadget driver (usb_f_fs) is possible to
stop rx transactions after the usb-dmac is used because the following
functions missed to set/check the "running" flag.
- usbhsf_dma_prepare_pop_with_usb_dmac()
- usbhsf_dma_pop_done_with_usb_dmac()
So, if next transaction uses pio, the usbhsf_prepare_pop() can not
start the transaction because the "running" flag is 0.
Fixes: 8355b2b3082d ("usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle")
Cc: <stable(a)vger.kernel.org> # v3.19+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/renesas_usbhs/fifo.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -999,6 +999,10 @@ static int usbhsf_dma_prepare_pop_with_u
if ((uintptr_t)pkt->buf & (USBHS_USB_DMAC_XFER_SIZE - 1))
goto usbhsf_pio_prepare_pop;
+ /* return at this time if the pipe is running */
+ if (usbhs_pipe_is_running(pipe))
+ return 0;
+
usbhs_pipe_config_change_bfre(pipe, 1);
ret = usbhsf_fifo_select(pipe, fifo, 0);
@@ -1189,6 +1193,7 @@ static int usbhsf_dma_pop_done_with_usb_
usbhsf_fifo_clear(pipe, fifo);
pkt->actual = usbhs_dma_calc_received_size(pkt, chan, rcv_len);
+ usbhs_pipe_running(pipe, 0);
usbhsf_dma_stop(pipe, fifo);
usbhsf_dma_unmap(pkt);
usbhsf_fifo_unselect(pipe, pipe->fifo);
Patches currently in stable-queue which might be from yoshihiro.shimoda.uh(a)renesas.com are
queue-4.4/usb-renesas_usbhs-missed-the-running-flag-in-usb_dmac-with-rx-path.patch
This is a note to let you know that I've just added the patch titled
usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
to the 4.4-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-ohci-proper-handling-of-ed_rm_list-to-handle-race-condition-between-usb_kill_urb-and-finish_unlinks.patch
and it can be found in the queue-4.4 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 46408ea558df13b110e0866b99624384a33bdeba Mon Sep 17 00:00:00 2001
From: AMAN DEEP <aman.deep(a)samsung.com>
Date: Thu, 8 Feb 2018 11:55:01 +0800
Subject: usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
From: AMAN DEEP <aman.deep(a)samsung.com>
commit 46408ea558df13b110e0866b99624384a33bdeba upstream.
There is a race condition between finish_unlinks->finish_urb() function
and usb_kill_urb() in ohci controller case. The finish_urb calls
spin_unlock(&ohci->lock) before usb_hcd_giveback_urb() function call,
then if during this time, usb_kill_urb is called for another endpoint,
then new ed will be added to ed_rm_list at beginning for unlink, and
ed_rm_list will point to newly added.
When finish_urb() is completed in finish_unlinks() and ed->td_list
becomes empty as in below code (in finish_unlinks() function):
if (list_empty(&ed->td_list)) {
*last = ed->ed_next;
ed->ed_next = NULL;
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
*last = ed->ed_next;
ed->ed_next = NULL;
ed_schedule(ohci, ed);
}
The *last = ed->ed_next will make ed_rm_list to point to ed->ed_next
and previously added ed by usb_kill_urb will be left unreferenced by
ed_rm_list. This causes usb_kill_urb() hang forever waiting for
finish_unlink to remove added ed from ed_rm_list.
The main reason for hang in this race condtion is addition and removal
of ed from ed_rm_list in the beginning during usb_kill_urb and later
last* is modified in finish_unlinks().
As suggested by Alan Stern, the solution for proper handling of
ohci->ed_rm_list is to remove ed from the ed_rm_list before finishing
any URBs. Then at the end, we can add ed back to the list if necessary.
This properly handle the updated ohci->ed_rm_list in usb_kill_urb().
Fixes: 977dcfdc6031 ("USB: OHCI: don't lose track of EDs when a controller dies")
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
CC: <stable(a)vger.kernel.org>
Signed-off-by: Aman Deep <aman.deep(a)samsung.com>
Signed-off-by: Jeffy Chen <jeffy.chen(a)rock-chips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/ohci-q.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
--- a/drivers/usb/host/ohci-q.c
+++ b/drivers/usb/host/ohci-q.c
@@ -1018,6 +1018,8 @@ skip_ed:
* have modified this list. normally it's just prepending
* entries (which we'd ignore), but paranoia won't hurt.
*/
+ *last = ed->ed_next;
+ ed->ed_next = NULL;
modified = 0;
/* unlink urbs as requested, but rescan the list after
@@ -1076,21 +1078,22 @@ rescan_this:
goto rescan_this;
/*
- * If no TDs are queued, take ED off the ed_rm_list.
+ * If no TDs are queued, ED is now idle.
* Otherwise, if the HC is running, reschedule.
- * If not, leave it on the list for further dequeues.
+ * If the HC isn't running, add ED back to the
+ * start of the list for later processing.
*/
if (list_empty(&ed->td_list)) {
- *last = ed->ed_next;
- ed->ed_next = NULL;
ed->state = ED_IDLE;
list_del(&ed->in_use_list);
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
- *last = ed->ed_next;
- ed->ed_next = NULL;
ed_schedule(ohci, ed);
} else {
- last = &ed->ed_next;
+ ed->ed_next = ohci->ed_rm_list;
+ ohci->ed_rm_list = ed;
+ /* Don't loop on the same ED */
+ if (last == &ohci->ed_rm_list)
+ last = &ed->ed_next;
}
if (modified)
Patches currently in stable-queue which might be from aman.deep(a)samsung.com are
queue-4.4/usb-ohci-proper-handling-of-ed_rm_list-to-handle-race-condition-between-usb_kill_urb-and-finish_unlinks.patch
This is a note to let you know that I've just added the patch titled
usb: ldusb: add PIDs for new CASSY devices supported by this driver
to the 4.4-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-ldusb-add-pids-for-new-cassy-devices-supported-by-this-driver.patch
and it can be found in the queue-4.4 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 52ad2bd8918158266fc88a05f95429b56b6a33c5 Mon Sep 17 00:00:00 2001
From: Karsten Koop <kkoop(a)ld-didactic.de>
Date: Fri, 9 Feb 2018 09:12:06 +0000
Subject: usb: ldusb: add PIDs for new CASSY devices supported by this driver
From: Karsten Koop <kkoop(a)ld-didactic.de>
commit 52ad2bd8918158266fc88a05f95429b56b6a33c5 upstream.
This patch adds support for new CASSY devices to the ldusb driver. The
PIDs are also added to the ignore list in hid-quirks.
Signed-off-by: Karsten Koop <kkoop(a)ld-didactic.de>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-core.c | 3 +++
drivers/hid/hid-ids.h | 3 +++
drivers/usb/misc/ldusb.c | 6 ++++++
3 files changed, 12 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2386,6 +2386,9 @@ static const struct hid_device_id hid_ig
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTIME) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYPH) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_POWERANALYSERCASSY) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MACHINETESTCASSY) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_JWM) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_DMMP) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_UMIP) },
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -570,6 +570,9 @@
#define USB_DEVICE_ID_LD_MICROCASSYTIME 0x1033
#define USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE 0x1035
#define USB_DEVICE_ID_LD_MICROCASSYPH 0x1038
+#define USB_DEVICE_ID_LD_POWERANALYSERCASSY 0x1040
+#define USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY 0x1042
+#define USB_DEVICE_ID_LD_MACHINETESTCASSY 0x1043
#define USB_DEVICE_ID_LD_JWM 0x1080
#define USB_DEVICE_ID_LD_DMMP 0x1081
#define USB_DEVICE_ID_LD_UMIP 0x1090
--- a/drivers/usb/misc/ldusb.c
+++ b/drivers/usb/misc/ldusb.c
@@ -46,6 +46,9 @@
#define USB_DEVICE_ID_LD_MICROCASSYTIME 0x1033 /* USB Product ID of Micro-CASSY Time (reserved) */
#define USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE 0x1035 /* USB Product ID of Micro-CASSY Temperature */
#define USB_DEVICE_ID_LD_MICROCASSYPH 0x1038 /* USB Product ID of Micro-CASSY pH */
+#define USB_DEVICE_ID_LD_POWERANALYSERCASSY 0x1040 /* USB Product ID of Power Analyser CASSY */
+#define USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY 0x1042 /* USB Product ID of Converter Controller CASSY */
+#define USB_DEVICE_ID_LD_MACHINETESTCASSY 0x1043 /* USB Product ID of Machine Test CASSY */
#define USB_DEVICE_ID_LD_JWM 0x1080 /* USB Product ID of Joule and Wattmeter */
#define USB_DEVICE_ID_LD_DMMP 0x1081 /* USB Product ID of Digital Multimeter P (reserved) */
#define USB_DEVICE_ID_LD_UMIP 0x1090 /* USB Product ID of UMI P */
@@ -88,6 +91,9 @@ static const struct usb_device_id ld_usb
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTIME) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYPH) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_POWERANALYSERCASSY) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MACHINETESTCASSY) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_JWM) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_DMMP) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_UMIP) },
Patches currently in stable-queue which might be from kkoop(a)ld-didactic.de are
queue-4.4/usb-ldusb-add-pids-for-new-cassy-devices-supported-by-this-driver.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Process all descriptors during bind
to the 4.4-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-f_fs-process-all-descriptors-during-bind.patch
and it can be found in the queue-4.4 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 6cf439e0d37463e42784271179c8a308fd7493c6 Mon Sep 17 00:00:00 2001
From: Jack Pham <jackp(a)codeaurora.org>
Date: Wed, 24 Jan 2018 00:11:53 -0800
Subject: usb: gadget: f_fs: Process all descriptors during bind
From: Jack Pham <jackp(a)codeaurora.org>
commit 6cf439e0d37463e42784271179c8a308fd7493c6 upstream.
During _ffs_func_bind(), the received descriptors are evaluated
to prepare for binding with the gadget in order to allocate
endpoints and optionally set up OS descriptors. However, the
high- and super-speed descriptors are only parsed based on
whether the gadget_is_dualspeed() and gadget_is_superspeed()
calls are true, respectively.
This is a problem in case a userspace program always provides
all of the {full,high,super,OS} descriptors when configuring a
function. Then, for example if a gadget device is not capable
of SuperSpeed, the call to ffs_do_descs() for the SS descriptors
is skipped, resulting in an incorrect offset calculation for
the vla_ptr when moving on to the OS descriptors that follow.
This causes ffs_do_os_descs() to fail as it is now looking at
the SS descriptors' offset within the raw_descs buffer instead.
_ffs_func_bind() should evaluate the descriptors unconditionally,
so remove the checks for gadget speed.
Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support")
Cc: stable(a)vger.kernel.org
Co-Developed-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Jack Pham <jackp(a)codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/function/f_fs.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2756,10 +2756,8 @@ static int _ffs_func_bind(struct usb_con
struct ffs_data *ffs = func->ffs;
const int full = !!func->ffs->fs_descs_count;
- const int high = gadget_is_dualspeed(func->gadget) &&
- func->ffs->hs_descs_count;
- const int super = gadget_is_superspeed(func->gadget) &&
- func->ffs->ss_descs_count;
+ const int high = !!func->ffs->hs_descs_count;
+ const int super = !!func->ffs->ss_descs_count;
int fs_len, hs_len, ss_len, ret, i;
struct ffs_ep *eps_ptr;
Patches currently in stable-queue which might be from jackp(a)codeaurora.org are
queue-4.4/usb-gadget-f_fs-process-all-descriptors-during-bind.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: gadget: Set maxpacket size for ep0 IN
to the 4.4-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-gadget-set-maxpacket-size-for-ep0-in.patch
and it can be found in the queue-4.4 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 6180026341e852a250e1f97ebdcf71684a3c81b9 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 12 Jan 2018 18:18:05 -0800
Subject: usb: dwc3: gadget: Set maxpacket size for ep0 IN
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
commit 6180026341e852a250e1f97ebdcf71684a3c81b9 upstream.
There are 2 control endpoint structures for DWC3. However, the driver
only updates the OUT direction control endpoint structure during
ConnectDone event. DWC3 driver needs to update the endpoint max packet
size for control IN endpoint as well. If the max packet size is not
properly set, then the driver will incorrectly calculate the data
transfer size and fail to send ZLP for HS/FS 3-stage control read
transfer.
The fix is simply to update the max packet size for the ep0 IN direction
during ConnectDone event.
Cc: stable(a)vger.kernel.org
Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc3/gadget.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2393,6 +2393,8 @@ static void dwc3_gadget_conndone_interru
break;
}
+ dwc->eps[1]->endpoint.maxpacket = dwc->gadget.ep0->maxpacket;
+
/* Enable USB2 LPM Capability */
if ((dwc->revision > DWC3_REVISION_194A)
Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are
queue-4.4/usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch
This is a note to let you know that I've just added the patch titled
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
to the 4.4-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-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch
and it can be found in the queue-4.4 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 c39813652700f3df552b6557530f1e5f782dbe2f Mon Sep 17 00:00:00 2001
From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
Date: Tue, 23 Jan 2018 20:11:32 -0600
Subject: scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
commit c39813652700f3df552b6557530f1e5f782dbe2f upstream.
The fcp_rsp_info structure as defined in the FC spec has an initial 3
bytes reserved field. The ibmvfc driver mistakenly defined this field as
4 bytes resulting in the rsp_code field being defined in what should be
the start of the second reserved field and thus always being reported as
zero by the driver.
Ideally, we should wire ibmvfc up with libfc for the sake of code
deduplication, and ease of maintaining standardized structures in a
single place. However, for now simply fixup the definition in ibmvfc for
backporting to distros on older kernels. Wiring up with libfc will be
done in a followup patch.
Cc: <stable(a)vger.kernel.org>
Reported-by: Hannes Reinecke <hare(a)suse.de>
Signed-off-by: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/ibmvscsi/ibmvfc.h
+++ b/drivers/scsi/ibmvscsi/ibmvfc.h
@@ -366,7 +366,7 @@ enum ibmvfc_fcp_rsp_info_codes {
};
struct ibmvfc_fcp_rsp_info {
- __be16 reserved;
+ u8 reserved[3];
u8 rsp_code;
u8 reserved2[4];
}__attribute__((packed, aligned (2)));
Patches currently in stable-queue which might be from tyreld(a)linux.vnet.ibm.com are
queue-4.4/scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch
This is a note to let you know that I've just added the patch titled
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
to the 4.4-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:
irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch
and it can be found in the queue-4.4 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 21ec30c0ef5234fb1039cc7c7737d885bf875a9e Mon Sep 17 00:00:00 2001
From: Shanker Donthineni <shankerd(a)codeaurora.org>
Date: Wed, 31 Jan 2018 18:03:42 -0600
Subject: irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
From: Shanker Donthineni <shankerd(a)codeaurora.org>
commit 21ec30c0ef5234fb1039cc7c7737d885bf875a9e upstream.
A DMB instruction can be used to ensure the relative order of only
memory accesses before and after the barrier. Since writes to system
registers are not memory operations, barrier DMB is not sufficient
for observability of memory accesses that occur before ICC_SGI1R_EL1
writes.
A DSB instruction ensures that no instructions that appear in program
order after the DSB instruction, can execute until the DSB instruction
has completed.
Cc: stable(a)vger.kernel.org
Acked-by: Will Deacon <will.deacon(a)arm.com>,
Signed-off-by: Shanker Donthineni <shankerd(a)codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -604,7 +604,7 @@ static void gic_raise_softirq(const stru
* Ensure that stores to Normal memory are visible to the
* other CPUs before issuing the IPI.
*/
- smp_wmb();
+ wmb();
for_each_cpu(cpu, mask) {
unsigned long cluster_id = cpu_logical_map(cpu) & ~0xffUL;
Patches currently in stable-queue which might be from shankerd(a)codeaurora.org are
queue-4.4/irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch
This is a note to let you know that I've just added the patch titled
iio: buffer: check if a buffer has been set up when poll is called
to the 4.4-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:
iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.patch
and it can be found in the queue-4.4 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 4cd140bda6494543f1c1b0ccceceaa44b676eef6 Mon Sep 17 00:00:00 2001
From: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
Date: Thu, 15 Feb 2018 15:02:53 +0100
Subject: iio: buffer: check if a buffer has been set up when poll is called
From: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
commit 4cd140bda6494543f1c1b0ccceceaa44b676eef6 upstream.
If no iio buffer has been set up and poll is called return 0.
Without this check there will be a null pointer dereference when
calling poll on a iio driver without an iio buffer.
Cc: stable(a)vger.kernel.org
Signed-off-by: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/industrialio-buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -174,7 +174,7 @@ unsigned int iio_buffer_poll(struct file
struct iio_dev *indio_dev = filp->private_data;
struct iio_buffer *rb = indio_dev->buffer;
- if (!indio_dev->info)
+ if (!indio_dev->info || rb == NULL)
return 0;
poll_wait(filp, &rb->pollq, wait);
Patches currently in stable-queue which might be from stefan.windfeldt(a)axis.com are
queue-4.4/iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.patch
This is a note to let you know that I've just added the patch titled
iio: adis_lib: Initialize trigger before requesting interrupt
to the 4.4-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:
iio-adis_lib-initialize-trigger-before-requesting-interrupt.patch
and it can be found in the queue-4.4 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 f027e0b3a774e10302207e91d304bbf99e3a8b36 Mon Sep 17 00:00:00 2001
From: Lars-Peter Clausen <lars(a)metafoo.de>
Date: Wed, 14 Feb 2018 15:43:00 +0100
Subject: iio: adis_lib: Initialize trigger before requesting interrupt
From: Lars-Peter Clausen <lars(a)metafoo.de>
commit f027e0b3a774e10302207e91d304bbf99e3a8b36 upstream.
The adis_probe_trigger() creates a new IIO trigger and requests an
interrupt associated with the trigger. The interrupt uses the generic
iio_trigger_generic_data_rdy_poll() function as its interrupt handler.
Currently the driver initializes some fields of the trigger structure after
the interrupt has been requested. But an interrupt can fire as soon as it
has been requested. This opens up a race condition.
iio_trigger_generic_data_rdy_poll() will access the trigger data structure
and dereference the ops field. If the ops field is not yet initialized this
will result in a NULL pointer deref.
It is not expected that the device generates an interrupt at this point, so
typically this issue did not surface unless e.g. due to a hardware
misconfiguration (wrong interrupt number, wrong polarity, etc.).
But some newer devices from the ADIS family start to generate periodic
interrupts in their power-on reset configuration and unfortunately the
interrupt can not be masked in the device. This makes the race condition
much more visible and the following crash has been observed occasionally
when booting a system using the ADIS16460.
Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = c0004000
[00000008] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257
Hardware name: Xilinx Zynq Platform
task: ef04f640 task.stack: ef050000
PC is at iio_trigger_notify_done+0x30/0x68
LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20
pc : [<c042d868>] lr : [<c042d924>] psr: 60000193
sp : ef051bb8 ip : 00000000 fp : ef106400
r10: c081d80a r9 : ef3bfa00 r8 : 00000087
r7 : ef051bec r6 : 00000000 r5 : ef3bfa00 r4 : ee92ab00
r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : ee97e400
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 18c5387d Table: 0000404a DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xef050210)
[<c042d868>] (iio_trigger_notify_done) from [<c0065b10>] (__handle_irq_event_percpu+0x88/0x118)
[<c0065b10>] (__handle_irq_event_percpu) from [<c0065bbc>] (handle_irq_event_percpu+0x1c/0x58)
[<c0065bbc>] (handle_irq_event_percpu) from [<c0065c30>] (handle_irq_event+0x38/0x5c)
[<c0065c30>] (handle_irq_event) from [<c0068e28>] (handle_level_irq+0xa4/0x130)
[<c0068e28>] (handle_level_irq) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c021ab7c>] (zynq_gpio_irqhandler+0xb8/0x13c)
[<c021ab7c>] (zynq_gpio_irqhandler) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c0065370>] (__handle_domain_irq+0x5c/0xb4)
[<c0065370>] (__handle_domain_irq) from [<c000940c>] (gic_handle_irq+0x48/0x8c)
[<c000940c>] (gic_handle_irq) from [<c0013e8c>] (__irq_svc+0x6c/0xa8)
To fix this make sure that the trigger is fully initialized before
requesting the interrupt.
Fixes: ccd2b52f4ac6 ("staging:iio: Add common ADIS library")
Reported-by: Robin Getz <Robin.Getz(a)analog.com>
Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de>
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/imu/adis_trigger.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/iio/imu/adis_trigger.c
+++ b/drivers/iio/imu/adis_trigger.c
@@ -47,6 +47,10 @@ int adis_probe_trigger(struct adis *adis
if (adis->trig == NULL)
return -ENOMEM;
+ adis->trig->dev.parent = &adis->spi->dev;
+ adis->trig->ops = &adis_trigger_ops;
+ iio_trigger_set_drvdata(adis->trig, adis);
+
ret = request_irq(adis->spi->irq,
&iio_trigger_generic_data_rdy_poll,
IRQF_TRIGGER_RISING,
@@ -55,9 +59,6 @@ int adis_probe_trigger(struct adis *adis
if (ret)
goto error_free_trig;
- adis->trig->dev.parent = &adis->spi->dev;
- adis->trig->ops = &adis_trigger_ops;
- iio_trigger_set_drvdata(adis->trig, adis);
ret = iio_trigger_register(adis->trig);
indio_dev->trig = iio_trigger_get(adis->trig);
Patches currently in stable-queue which might be from lars(a)metafoo.de are
queue-4.4/iio-adis_lib-initialize-trigger-before-requesting-interrupt.patch
This is a note to let you know that I've just added the patch titled
drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
to the 4.4-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:
drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.patch
and it can be found in the queue-4.4 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 06998a756a3865817b87a129a7e5d5bb66dc1ec3 Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Sun, 18 Feb 2018 16:53:59 +0800
Subject: drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit 06998a756a3865817b87a129a7e5d5bb66dc1ec3 upstream.
Similar to commit e10aec652f31 ("drm/edid: Add 6 bpc quirk for display
AEO model 0."), the EDID reports "DFP 1.x compliant TMDS" but it support
6bpc instead of 8 bpc.
Hence, use 6 bpc quirk for this panel.
Fixes: 196f954e2509 ("drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"")
BugLink: https://bugs.launchpad.net/bugs/1749420
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de(a)gmail.com>
Cc: <stable(a)vger.kernel.org> # v4.8+
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180218085359.7817-1-kai.hen…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -106,6 +106,9 @@ static struct edid_quirk {
/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
{ "AEO", 0, EDID_QUIRK_FORCE_6BPC },
+ /* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */
+ { "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC },
+
/* Belinea 10 15 55 */
{ "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
{ "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.4/drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
to the 4.4-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:
drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.patch
and it can be found in the queue-4.4 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 458d876eb869d5a88b53074c6c271b8b9adc0f07 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Mon, 22 Jan 2018 23:13:32 -0500
Subject: drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
From: Alex Deucher <alexander.deucher(a)amd.com>
commit 458d876eb869d5a88b53074c6c271b8b9adc0f07 upstream.
We only support vga_switcheroo and runtime pm on PX/HG systems
so forcing runpm to 1 doesn't do anything useful anyway.
Only call vga_switcheroo_init_domain_pm_ops() for PX/HG so
that the cleanup path is correct as well. This mirrors what
radeon does as well.
v2: rework the patch originally sent by Lukas (Alex)
Acked-by: Lukas Wunner <lukas(a)wunner.de>
Reported-by: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de> (v1)
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1467,8 +1467,6 @@ int amdgpu_device_init(struct amdgpu_dev
* ignore it */
vga_client_register(adev->pdev, adev, NULL, amdgpu_vga_set_decode);
- if (amdgpu_runtime_pm == 1)
- runtime = true;
if (amdgpu_device_is_px(ddev))
runtime = true;
vga_switcheroo_register_client(adev->pdev, &amdgpu_switcheroo_ops, runtime);
Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are
queue-4.4/drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.patch
This is a note to let you know that I've just added the patch titled
cfg80211: fix cfg80211_beacon_dup
to the 4.4-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:
cfg80211-fix-cfg80211_beacon_dup.patch
and it can be found in the queue-4.4 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 bee92d06157fc39d5d7836a061c7d41289a55797 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Fri, 2 Feb 2018 16:31:23 +0100
Subject: cfg80211: fix cfg80211_beacon_dup
From: Arnd Bergmann <arnd(a)arndb.de>
commit bee92d06157fc39d5d7836a061c7d41289a55797 upstream.
gcc-8 warns about some obviously incorrect code:
net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':
net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
>From the context, I conclude that we want to copy from beacon into
new_beacon, as we do in the rest of the function.
Cc: stable(a)vger.kernel.org
Fixes: 73da7d5bab79 ("mac80211: add channel switch command and beacon callbacks")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2877,7 +2877,7 @@ cfg80211_beacon_dup(struct cfg80211_beac
}
if (beacon->probe_resp_len) {
new_beacon->probe_resp_len = beacon->probe_resp_len;
- beacon->probe_resp = pos;
+ new_beacon->probe_resp = pos;
memcpy(pos, beacon->probe_resp, beacon->probe_resp_len);
pos += beacon->probe_resp_len;
}
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-4.4/cfg80211-fix-cfg80211_beacon_dup.patch
This is a note to let you know that I've just added the patch titled
arm64: Disable unhandled signal log messages by default
to the 4.4-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:
arm64-disable-unhandled-signal-log-messages-by-default.patch
and it can be found in the queue-4.4 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 5ee39a71fd89ab7240c5339d04161c44a8e03269 Mon Sep 17 00:00:00 2001
From: Michael Weiser <michael.weiser(a)gmx.de>
Date: Thu, 1 Feb 2018 23:13:38 +0100
Subject: arm64: Disable unhandled signal log messages by default
From: Michael Weiser <michael.weiser(a)gmx.de>
commit 5ee39a71fd89ab7240c5339d04161c44a8e03269 upstream.
aarch64 unhandled signal kernel messages are very verbose, suggesting
them to be more of a debugging aid:
sigsegv[33]: unhandled level 2 translation fault (11) at 0x00000000, esr
0x92000046, in sigsegv[400000+71000]
CPU: 1 PID: 33 Comm: sigsegv Tainted: G W 4.15.0-rc3+ #3
Hardware name: linux,dummy-virt (DT)
pstate: 60000000 (nZCv daif -PAN -UAO)
pc : 0x4003f4
lr : 0x4006bc
sp : 0000fffffe94a060
x29: 0000fffffe94a070 x28: 0000000000000000
x27: 0000000000000000 x26: 0000000000000000
x25: 0000000000000000 x24: 00000000004001b0
x23: 0000000000486ac8 x22: 00000000004001c8
x21: 0000000000000000 x20: 0000000000400be8
x19: 0000000000400b30 x18: 0000000000484728
x17: 000000000865ffc8 x16: 000000000000270f
x15: 00000000000000b0 x14: 0000000000000002
x13: 0000000000000001 x12: 0000000000000000
x11: 0000000000000000 x10: 0008000020008008
x9 : 000000000000000f x8 : ffffffffffffffff
x7 : 0004000000000000 x6 : ffffffffffffffff
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 00000000004003e4 x2 : 0000fffffe94a1e8
x1 : 000000000000000a x0 : 0000000000000000
Disable them by default, so they can be enabled using
/proc/sys/debug/exception-trace.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Michael Weiser <michael.weiser(a)gmx.de>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/kernel/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -49,7 +49,7 @@ static const char *handler[]= {
"Error"
};
-int show_unhandled_signals = 1;
+int show_unhandled_signals = 0;
/*
* Dump out the contents of some memory nicely...
Patches currently in stable-queue which might be from michael.weiser(a)gmx.de are
queue-4.4/arm64-disable-unhandled-signal-log-messages-by-default.patch
This is a note to let you know that I've just added the patch titled
Add delay-init quirk for Corsair K70 RGB keyboards
to the 4.4-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:
add-delay-init-quirk-for-corsair-k70-rgb-keyboards.patch
and it can be found in the queue-4.4 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 7a1646d922577b5b48c0d222e03831141664bb59 Mon Sep 17 00:00:00 2001
From: Jack Stocker <jackstocker.93(a)gmail.com>
Date: Thu, 15 Feb 2018 18:24:10 +0000
Subject: Add delay-init quirk for Corsair K70 RGB keyboards
From: Jack Stocker <jackstocker.93(a)gmail.com>
commit 7a1646d922577b5b48c0d222e03831141664bb59 upstream.
Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
start correctly at boot.
Device ids found here:
usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-3: Product: Corsair K70 RGB Gaming Keyboard
Signed-off-by: Jack Stocker <jackstocker.93(a)gmail.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -225,6 +225,9 @@ static const struct usb_device_id usb_qu
{ USB_DEVICE(0x1a0a, 0x0200), .driver_info =
USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
+ /* Corsair K70 RGB */
+ { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* Corsair Strafe RGB */
{ USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
Patches currently in stable-queue which might be from jackstocker.93(a)gmail.com are
queue-4.4/add-delay-init-quirk-for-corsair-k70-rgb-keyboards.patch
This is a note to let you know that I've just added the patch titled
x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
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:
x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.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 85c615eb52222bc5fab6c7190d146bc59fac289e Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 20 Feb 2018 21:58:21 +0100
Subject: x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
From: Arnd Bergmann <arnd(a)arndb.de>
commit 85c615eb52222bc5fab6c7190d146bc59fac289e upstream.
GCC-8 shows a warning for the x86 oprofile code that copies per-CPU
data from CPU 0 to all other CPUs, which when building a non-SMP
kernel turns into a memcpy() with identical source and destination
pointers:
arch/x86/oprofile/nmi_int.c: In function 'mux_clone':
arch/x86/oprofile/nmi_int.c:285:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
memcpy(per_cpu(cpu_msrs, cpu).multiplex,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
per_cpu(cpu_msrs, 0).multiplex,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(struct op_msr) * model->num_virt_counters);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/oprofile/nmi_int.c: In function 'nmi_setup':
arch/x86/oprofile/nmi_int.c:466:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
arch/x86/oprofile/nmi_int.c:470:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
I have analyzed a number of such warnings now: some are valid and the
GCC warning is welcome. Others turned out to be false-positives, and
GCC was changed to not warn about those any more. This is a corner case
that is a false-positive but the GCC developers feel it's better to keep
warning about it.
In this case, it seems best to work around it by telling GCC
a little more clearly that this code path is never hit with
an IS_ENABLED() configuration check.
Cc:stable as we also want old kernels to build cleanly with GCC-8.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Jessica Yu <jeyu(a)kernel.org>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Martin Sebor <msebor(a)gcc.gnu.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Robert Richter <rric(a)kernel.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: oprofile-list(a)lists.sf.net
Cc: stable(a)vger.kernel.org
Link: http://lkml.kernel.org/r/20180220205826.2008875-1-arnd@arndb.de
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/oprofile/nmi_int.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/oprofile/nmi_int.c
+++ b/arch/x86/oprofile/nmi_int.c
@@ -471,7 +471,7 @@ static int nmi_setup(void)
goto fail;
for_each_possible_cpu(cpu) {
- if (!cpu)
+ if (!IS_ENABLED(CONFIG_SMP) || !cpu)
continue;
memcpy(per_cpu(cpu_msrs, cpu).counters,
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-3.18/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-3.18/cfg80211-fix-cfg80211_beacon_dup.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Process all descriptors during 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:
usb-gadget-f_fs-process-all-descriptors-during-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 6cf439e0d37463e42784271179c8a308fd7493c6 Mon Sep 17 00:00:00 2001
From: Jack Pham <jackp(a)codeaurora.org>
Date: Wed, 24 Jan 2018 00:11:53 -0800
Subject: usb: gadget: f_fs: Process all descriptors during bind
From: Jack Pham <jackp(a)codeaurora.org>
commit 6cf439e0d37463e42784271179c8a308fd7493c6 upstream.
During _ffs_func_bind(), the received descriptors are evaluated
to prepare for binding with the gadget in order to allocate
endpoints and optionally set up OS descriptors. However, the
high- and super-speed descriptors are only parsed based on
whether the gadget_is_dualspeed() and gadget_is_superspeed()
calls are true, respectively.
This is a problem in case a userspace program always provides
all of the {full,high,super,OS} descriptors when configuring a
function. Then, for example if a gadget device is not capable
of SuperSpeed, the call to ffs_do_descs() for the SS descriptors
is skipped, resulting in an incorrect offset calculation for
the vla_ptr when moving on to the OS descriptors that follow.
This causes ffs_do_os_descs() to fail as it is now looking at
the SS descriptors' offset within the raw_descs buffer instead.
_ffs_func_bind() should evaluate the descriptors unconditionally,
so remove the checks for gadget speed.
Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support")
Cc: stable(a)vger.kernel.org
Co-Developed-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Jack Pham <jackp(a)codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/function/f_fs.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2727,10 +2727,8 @@ static int _ffs_func_bind(struct usb_con
struct ffs_data *ffs = func->ffs;
const int full = !!func->ffs->fs_descs_count;
- const int high = gadget_is_dualspeed(func->gadget) &&
- func->ffs->hs_descs_count;
- const int super = gadget_is_superspeed(func->gadget) &&
- func->ffs->ss_descs_count;
+ const int high = !!func->ffs->hs_descs_count;
+ const int super = !!func->ffs->ss_descs_count;
int fs_len, hs_len, ss_len, ret, i;
Patches currently in stable-queue which might be from jackp(a)codeaurora.org are
queue-3.18/usb-gadget-f_fs-process-all-descriptors-during-bind.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: gadget: Set maxpacket size for ep0 IN
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-dwc3-gadget-set-maxpacket-size-for-ep0-in.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 6180026341e852a250e1f97ebdcf71684a3c81b9 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 12 Jan 2018 18:18:05 -0800
Subject: usb: dwc3: gadget: Set maxpacket size for ep0 IN
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
commit 6180026341e852a250e1f97ebdcf71684a3c81b9 upstream.
There are 2 control endpoint structures for DWC3. However, the driver
only updates the OUT direction control endpoint structure during
ConnectDone event. DWC3 driver needs to update the endpoint max packet
size for control IN endpoint as well. If the max packet size is not
properly set, then the driver will incorrectly calculate the data
transfer size and fail to send ZLP for HS/FS 3-stage control read
transfer.
The fix is simply to update the max packet size for the ep0 IN direction
during ConnectDone event.
Cc: stable(a)vger.kernel.org
Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc3/gadget.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2345,6 +2345,8 @@ static void dwc3_gadget_conndone_interru
break;
}
+ dwc->eps[1]->endpoint.maxpacket = dwc->gadget.ep0->maxpacket;
+
/* Enable USB2 LPM Capability */
if ((dwc->revision > DWC3_REVISION_194A)
Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are
queue-3.18/usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch
This is a note to let you know that I've just added the patch titled
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
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-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.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 c39813652700f3df552b6557530f1e5f782dbe2f Mon Sep 17 00:00:00 2001
From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
Date: Tue, 23 Jan 2018 20:11:32 -0600
Subject: scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
commit c39813652700f3df552b6557530f1e5f782dbe2f upstream.
The fcp_rsp_info structure as defined in the FC spec has an initial 3
bytes reserved field. The ibmvfc driver mistakenly defined this field as
4 bytes resulting in the rsp_code field being defined in what should be
the start of the second reserved field and thus always being reported as
zero by the driver.
Ideally, we should wire ibmvfc up with libfc for the sake of code
deduplication, and ease of maintaining standardized structures in a
single place. However, for now simply fixup the definition in ibmvfc for
backporting to distros on older kernels. Wiring up with libfc will be
done in a followup patch.
Cc: <stable(a)vger.kernel.org>
Reported-by: Hannes Reinecke <hare(a)suse.de>
Signed-off-by: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/ibmvscsi/ibmvfc.h
+++ b/drivers/scsi/ibmvscsi/ibmvfc.h
@@ -366,7 +366,7 @@ enum ibmvfc_fcp_rsp_info_codes {
};
struct ibmvfc_fcp_rsp_info {
- __be16 reserved;
+ u8 reserved[3];
u8 rsp_code;
u8 reserved2[4];
}__attribute__((packed, aligned (2)));
Patches currently in stable-queue which might be from tyreld(a)linux.vnet.ibm.com are
queue-3.18/scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch
This is a note to let you know that I've just added the patch titled
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
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:
irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.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 21ec30c0ef5234fb1039cc7c7737d885bf875a9e Mon Sep 17 00:00:00 2001
From: Shanker Donthineni <shankerd(a)codeaurora.org>
Date: Wed, 31 Jan 2018 18:03:42 -0600
Subject: irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
From: Shanker Donthineni <shankerd(a)codeaurora.org>
commit 21ec30c0ef5234fb1039cc7c7737d885bf875a9e upstream.
A DMB instruction can be used to ensure the relative order of only
memory accesses before and after the barrier. Since writes to system
registers are not memory operations, barrier DMB is not sufficient
for observability of memory accesses that occur before ICC_SGI1R_EL1
writes.
A DSB instruction ensures that no instructions that appear in program
order after the DSB instruction, can execute until the DSB instruction
has completed.
Cc: stable(a)vger.kernel.org
Acked-by: Will Deacon <will.deacon(a)arm.com>,
Signed-off-by: Shanker Donthineni <shankerd(a)codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -503,7 +503,7 @@ static void gic_raise_softirq(const stru
* Ensure that stores to Normal memory are visible to the
* other CPUs before issuing the IPI.
*/
- smp_wmb();
+ wmb();
for_each_cpu_mask(cpu, *mask) {
u64 cluster_id = cpu_logical_map(cpu) & ~0xffUL;
Patches currently in stable-queue which might be from shankerd(a)codeaurora.org are
queue-3.18/irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch
This is a note to let you know that I've just added the patch titled
iio: buffer: check if a buffer has been set up when poll is called
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:
iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.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 4cd140bda6494543f1c1b0ccceceaa44b676eef6 Mon Sep 17 00:00:00 2001
From: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
Date: Thu, 15 Feb 2018 15:02:53 +0100
Subject: iio: buffer: check if a buffer has been set up when poll is called
From: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
commit 4cd140bda6494543f1c1b0ccceceaa44b676eef6 upstream.
If no iio buffer has been set up and poll is called return 0.
Without this check there will be a null pointer dereference when
calling poll on a iio driver without an iio buffer.
Cc: stable(a)vger.kernel.org
Signed-off-by: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/industrialio-buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -92,7 +92,7 @@ unsigned int iio_buffer_poll(struct file
struct iio_dev *indio_dev = filp->private_data;
struct iio_buffer *rb = indio_dev->buffer;
- if (!indio_dev->info)
+ if (!indio_dev->info || rb == NULL)
return 0;
poll_wait(filp, &rb->pollq, wait);
Patches currently in stable-queue which might be from stefan.windfeldt(a)axis.com are
queue-3.18/iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.patch
This is a note to let you know that I've just added the patch titled
iio: adis_lib: Initialize trigger before requesting interrupt
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:
iio-adis_lib-initialize-trigger-before-requesting-interrupt.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 f027e0b3a774e10302207e91d304bbf99e3a8b36 Mon Sep 17 00:00:00 2001
From: Lars-Peter Clausen <lars(a)metafoo.de>
Date: Wed, 14 Feb 2018 15:43:00 +0100
Subject: iio: adis_lib: Initialize trigger before requesting interrupt
From: Lars-Peter Clausen <lars(a)metafoo.de>
commit f027e0b3a774e10302207e91d304bbf99e3a8b36 upstream.
The adis_probe_trigger() creates a new IIO trigger and requests an
interrupt associated with the trigger. The interrupt uses the generic
iio_trigger_generic_data_rdy_poll() function as its interrupt handler.
Currently the driver initializes some fields of the trigger structure after
the interrupt has been requested. But an interrupt can fire as soon as it
has been requested. This opens up a race condition.
iio_trigger_generic_data_rdy_poll() will access the trigger data structure
and dereference the ops field. If the ops field is not yet initialized this
will result in a NULL pointer deref.
It is not expected that the device generates an interrupt at this point, so
typically this issue did not surface unless e.g. due to a hardware
misconfiguration (wrong interrupt number, wrong polarity, etc.).
But some newer devices from the ADIS family start to generate periodic
interrupts in their power-on reset configuration and unfortunately the
interrupt can not be masked in the device. This makes the race condition
much more visible and the following crash has been observed occasionally
when booting a system using the ADIS16460.
Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = c0004000
[00000008] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257
Hardware name: Xilinx Zynq Platform
task: ef04f640 task.stack: ef050000
PC is at iio_trigger_notify_done+0x30/0x68
LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20
pc : [<c042d868>] lr : [<c042d924>] psr: 60000193
sp : ef051bb8 ip : 00000000 fp : ef106400
r10: c081d80a r9 : ef3bfa00 r8 : 00000087
r7 : ef051bec r6 : 00000000 r5 : ef3bfa00 r4 : ee92ab00
r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : ee97e400
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 18c5387d Table: 0000404a DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xef050210)
[<c042d868>] (iio_trigger_notify_done) from [<c0065b10>] (__handle_irq_event_percpu+0x88/0x118)
[<c0065b10>] (__handle_irq_event_percpu) from [<c0065bbc>] (handle_irq_event_percpu+0x1c/0x58)
[<c0065bbc>] (handle_irq_event_percpu) from [<c0065c30>] (handle_irq_event+0x38/0x5c)
[<c0065c30>] (handle_irq_event) from [<c0068e28>] (handle_level_irq+0xa4/0x130)
[<c0068e28>] (handle_level_irq) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c021ab7c>] (zynq_gpio_irqhandler+0xb8/0x13c)
[<c021ab7c>] (zynq_gpio_irqhandler) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c0065370>] (__handle_domain_irq+0x5c/0xb4)
[<c0065370>] (__handle_domain_irq) from [<c000940c>] (gic_handle_irq+0x48/0x8c)
[<c000940c>] (gic_handle_irq) from [<c0013e8c>] (__irq_svc+0x6c/0xa8)
To fix this make sure that the trigger is fully initialized before
requesting the interrupt.
Fixes: ccd2b52f4ac6 ("staging:iio: Add common ADIS library")
Reported-by: Robin Getz <Robin.Getz(a)analog.com>
Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de>
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/imu/adis_trigger.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/iio/imu/adis_trigger.c
+++ b/drivers/iio/imu/adis_trigger.c
@@ -47,6 +47,10 @@ int adis_probe_trigger(struct adis *adis
if (adis->trig == NULL)
return -ENOMEM;
+ adis->trig->dev.parent = &adis->spi->dev;
+ adis->trig->ops = &adis_trigger_ops;
+ iio_trigger_set_drvdata(adis->trig, adis);
+
ret = request_irq(adis->spi->irq,
&iio_trigger_generic_data_rdy_poll,
IRQF_TRIGGER_RISING,
@@ -55,9 +59,6 @@ int adis_probe_trigger(struct adis *adis
if (ret)
goto error_free_trig;
- adis->trig->dev.parent = &adis->spi->dev;
- adis->trig->ops = &adis_trigger_ops;
- iio_trigger_set_drvdata(adis->trig, adis);
ret = iio_trigger_register(adis->trig);
indio_dev->trig = iio_trigger_get(adis->trig);
Patches currently in stable-queue which might be from lars(a)metafoo.de are
queue-3.18/iio-adis_lib-initialize-trigger-before-requesting-interrupt.patch
This is a note to let you know that I've just added the patch titled
cfg80211: fix cfg80211_beacon_dup
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:
cfg80211-fix-cfg80211_beacon_dup.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 bee92d06157fc39d5d7836a061c7d41289a55797 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Fri, 2 Feb 2018 16:31:23 +0100
Subject: cfg80211: fix cfg80211_beacon_dup
From: Arnd Bergmann <arnd(a)arndb.de>
commit bee92d06157fc39d5d7836a061c7d41289a55797 upstream.
gcc-8 warns about some obviously incorrect code:
net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':
net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
>From the context, I conclude that we want to copy from beacon into
new_beacon, as we do in the rest of the function.
Cc: stable(a)vger.kernel.org
Fixes: 73da7d5bab79 ("mac80211: add channel switch command and beacon callbacks")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2769,7 +2769,7 @@ cfg80211_beacon_dup(struct cfg80211_beac
}
if (beacon->probe_resp_len) {
new_beacon->probe_resp_len = beacon->probe_resp_len;
- beacon->probe_resp = pos;
+ new_beacon->probe_resp = pos;
memcpy(pos, beacon->probe_resp, beacon->probe_resp_len);
pos += beacon->probe_resp_len;
}
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-3.18/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-3.18/cfg80211-fix-cfg80211_beacon_dup.patch
This is a note to let you know that I've just added the patch titled
arm64: Disable unhandled signal log messages by default
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:
arm64-disable-unhandled-signal-log-messages-by-default.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 5ee39a71fd89ab7240c5339d04161c44a8e03269 Mon Sep 17 00:00:00 2001
From: Michael Weiser <michael.weiser(a)gmx.de>
Date: Thu, 1 Feb 2018 23:13:38 +0100
Subject: arm64: Disable unhandled signal log messages by default
From: Michael Weiser <michael.weiser(a)gmx.de>
commit 5ee39a71fd89ab7240c5339d04161c44a8e03269 upstream.
aarch64 unhandled signal kernel messages are very verbose, suggesting
them to be more of a debugging aid:
sigsegv[33]: unhandled level 2 translation fault (11) at 0x00000000, esr
0x92000046, in sigsegv[400000+71000]
CPU: 1 PID: 33 Comm: sigsegv Tainted: G W 4.15.0-rc3+ #3
Hardware name: linux,dummy-virt (DT)
pstate: 60000000 (nZCv daif -PAN -UAO)
pc : 0x4003f4
lr : 0x4006bc
sp : 0000fffffe94a060
x29: 0000fffffe94a070 x28: 0000000000000000
x27: 0000000000000000 x26: 0000000000000000
x25: 0000000000000000 x24: 00000000004001b0
x23: 0000000000486ac8 x22: 00000000004001c8
x21: 0000000000000000 x20: 0000000000400be8
x19: 0000000000400b30 x18: 0000000000484728
x17: 000000000865ffc8 x16: 000000000000270f
x15: 00000000000000b0 x14: 0000000000000002
x13: 0000000000000001 x12: 0000000000000000
x11: 0000000000000000 x10: 0008000020008008
x9 : 000000000000000f x8 : ffffffffffffffff
x7 : 0004000000000000 x6 : ffffffffffffffff
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 00000000004003e4 x2 : 0000fffffe94a1e8
x1 : 000000000000000a x0 : 0000000000000000
Disable them by default, so they can be enabled using
/proc/sys/debug/exception-trace.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Michael Weiser <michael.weiser(a)gmx.de>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/kernel/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -45,7 +45,7 @@ static const char *handler[]= {
"Error"
};
-int show_unhandled_signals = 1;
+int show_unhandled_signals = 0;
/*
* Dump out the contents of some memory nicely...
Patches currently in stable-queue which might be from michael.weiser(a)gmx.de are
queue-3.18/arm64-disable-unhandled-signal-log-messages-by-default.patch
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5ba4fa35d3d6a60fa5b669b319e2a95d5e0b6e7a Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Wed, 17 Jan 2018 09:07:29 -0500
Subject: [PATCH] drm/amdgpu: only check for ECC on Vega10
RV doesn't support it.
Reviewed-by: Junwei Zhang <Jerry.Zhang(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index eb8b1bb66389..2719937e09d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -634,14 +634,16 @@ static int gmc_v9_0_late_init(void *handle)
for(i = 0; i < AMDGPU_MAX_VMHUBS; ++i)
BUG_ON(vm_inv_eng[i] > 16);
- r = gmc_v9_0_ecc_available(adev);
- if (r == 1) {
- DRM_INFO("ECC is active.\n");
- } else if (r == 0) {
- DRM_INFO("ECC is not present.\n");
- } else {
- DRM_ERROR("gmc_v9_0_ecc_available() failed. r: %d\n", r);
- return r;
+ if (adev->asic_type == CHIP_VEGA10) {
+ r = gmc_v9_0_ecc_available(adev);
+ if (r == 1) {
+ DRM_INFO("ECC is active.\n");
+ } else if (r == 0) {
+ DRM_INFO("ECC is not present.\n");
+ } else {
+ DRM_ERROR("gmc_v9_0_ecc_available() failed. r: %d\n", r);
+ return r;
+ }
}
return amdgpu_irq_get(adev, &adev->mc.vm_fault, 0);
Changes since v2 [1]:
* Fix yet more compile breakage in the FS_DAX=n and DEV_DAX=y case.
(0day robot)
[1]: https://lists.01.org/pipermail/linux-nvdimm/2018-February/014046.html
---
The vfio interface, like RDMA, wants to setup long term (indefinite)
pins of the pages backing an address range so that a guest or userspace
driver can perform DMA to the with physical address. Given that this
pinning may lead to filesystem operations deadlocking in the
filesystem-dax case, the pinning request needs to be rejected.
The longer term fix for vfio, RDMA, and any other long term pin user, is
to provide a 'pin with lease' mechanism. Similar to the leases that are
hold for pNFS RDMA layouts, this userspace lease gives the kernel a way
to notify userspace that the block layout of the file is changing and
the kernel is revoking access to pinned pages.
---
Dan Williams (6):
dax: fix vma_is_fsdax() helper
dax: fix dax_mapping() definition in the FS_DAX=n + DEV_DAX=y case
xfs, dax: introduce IS_FSDAX()
dax: fix S_DAX definition
dax: short circuit vma_is_fsdax() in the CONFIG_FS_DAX=n case
vfio: disable filesystem-dax page pinning
drivers/vfio/vfio_iommu_type1.c | 18 +++++++++++++++---
fs/xfs/xfs_file.c | 14 +++++++-------
fs/xfs/xfs_ioctl.c | 4 ++--
fs/xfs/xfs_iomap.c | 6 +++---
fs/xfs/xfs_reflink.c | 2 +-
include/linux/dax.h | 9 ++++++---
include/linux/fs.h | 8 ++++++--
7 files changed, 40 insertions(+), 21 deletions(-)
The patch below does not apply to the 4.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5ba4fa35d3d6a60fa5b669b319e2a95d5e0b6e7a Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Wed, 17 Jan 2018 09:07:29 -0500
Subject: [PATCH] drm/amdgpu: only check for ECC on Vega10
RV doesn't support it.
Reviewed-by: Junwei Zhang <Jerry.Zhang(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index eb8b1bb66389..2719937e09d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -634,14 +634,16 @@ static int gmc_v9_0_late_init(void *handle)
for(i = 0; i < AMDGPU_MAX_VMHUBS; ++i)
BUG_ON(vm_inv_eng[i] > 16);
- r = gmc_v9_0_ecc_available(adev);
- if (r == 1) {
- DRM_INFO("ECC is active.\n");
- } else if (r == 0) {
- DRM_INFO("ECC is not present.\n");
- } else {
- DRM_ERROR("gmc_v9_0_ecc_available() failed. r: %d\n", r);
- return r;
+ if (adev->asic_type == CHIP_VEGA10) {
+ r = gmc_v9_0_ecc_available(adev);
+ if (r == 1) {
+ DRM_INFO("ECC is active.\n");
+ } else if (r == 0) {
+ DRM_INFO("ECC is not present.\n");
+ } else {
+ DRM_ERROR("gmc_v9_0_ecc_available() failed. r: %d\n", r);
+ return r;
+ }
}
return amdgpu_irq_get(adev, &adev->mc.vm_fault, 0);
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 4c63abb203db9cf23c746dcbcc64883e08977776 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig(a)amd.com>
Date: Tue, 16 Jan 2018 11:00:12 +0100
Subject: [PATCH] drm/amdgpu: fix typo in amdgpu_vce_validate_bo
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Otherwise buffer placement is very restrictive and might fail.
Fixes: "drm/amdgpu: fix VCE buffer placement restrictions v2"
Signed-off-by: Christian König <christian.koenig(a)amd.com>
Reported-by: Deng, Emily <Emily.Deng(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index 55a726a322e3..d274ae535530 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -585,8 +585,8 @@ static int amdgpu_vce_validate_bo(struct amdgpu_cs_parser *p, uint32_t ib_idx,
for (i = 0; i < bo->placement.num_placement; ++i) {
bo->placements[i].fpfn = max(bo->placements[i].fpfn, fpfn);
- bo->placements[i].lpfn = bo->placements[i].fpfn ?
- min(bo->placements[i].fpfn, lpfn) : lpfn;
+ bo->placements[i].lpfn = bo->placements[i].lpfn ?
+ min(bo->placements[i].lpfn, lpfn) : lpfn;
}
return ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
}
The patch below does not apply to the 4.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 4c63abb203db9cf23c746dcbcc64883e08977776 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig(a)amd.com>
Date: Tue, 16 Jan 2018 11:00:12 +0100
Subject: [PATCH] drm/amdgpu: fix typo in amdgpu_vce_validate_bo
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Otherwise buffer placement is very restrictive and might fail.
Fixes: "drm/amdgpu: fix VCE buffer placement restrictions v2"
Signed-off-by: Christian König <christian.koenig(a)amd.com>
Reported-by: Deng, Emily <Emily.Deng(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index 55a726a322e3..d274ae535530 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -585,8 +585,8 @@ static int amdgpu_vce_validate_bo(struct amdgpu_cs_parser *p, uint32_t ib_idx,
for (i = 0; i < bo->placement.num_placement; ++i) {
bo->placements[i].fpfn = max(bo->placements[i].fpfn, fpfn);
- bo->placements[i].lpfn = bo->placements[i].fpfn ?
- min(bo->placements[i].fpfn, lpfn) : lpfn;
+ bo->placements[i].lpfn = bo->placements[i].lpfn ?
+ min(bo->placements[i].lpfn, lpfn) : lpfn;
}
return ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
}
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 57ad33a307bf85cafda3a77c03a555c9f9ee4139 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Tue, 19 Dec 2017 09:52:31 -0500
Subject: [PATCH] drm/amdgpu: only check mmBIF_IOV_FUNC_IDENTIFIER on
tonga/fiji
We only support SR-IOV on tonga/fiji. Don't check this register
on other VI parts.
Fixes: 048765ad5af7c89 (amdgpu: fix asic initialization for virtualized environments (v2))
Reviewed-by: Xiangliang Yu <Xiangliang.Yu(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index d9bb26322850..c59b37365e4d 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -449,14 +449,19 @@ static bool vi_read_bios_from_rom(struct amdgpu_device *adev,
static void vi_detect_hw_virtualization(struct amdgpu_device *adev)
{
- uint32_t reg = RREG32(mmBIF_IOV_FUNC_IDENTIFIER);
- /* bit0: 0 means pf and 1 means vf */
- /* bit31: 0 means disable IOV and 1 means enable */
- if (reg & 1)
- adev->virt.caps |= AMDGPU_SRIOV_CAPS_IS_VF;
-
- if (reg & 0x80000000)
- adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV;
+ uint32_t reg = 0;
+
+ if (adev->asic_type == CHIP_TONGA ||
+ adev->asic_type == CHIP_FIJI) {
+ reg = RREG32(mmBIF_IOV_FUNC_IDENTIFIER);
+ /* bit0: 0 means pf and 1 means vf */
+ /* bit31: 0 means disable IOV and 1 means enable */
+ if (reg & 1)
+ adev->virt.caps |= AMDGPU_SRIOV_CAPS_IS_VF;
+
+ if (reg & 0x80000000)
+ adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV;
+ }
if (reg == 0) {
if (is_virtual_machine()) /* passthrough mode exclus sr-iov mode */
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 54f809cfbd6b4a43959039f5d33596ed3297ce16 Mon Sep 17 00:00:00 2001
From: "Leo (Sunpeng) Li" <sunpeng.li(a)amd.com>
Date: Wed, 17 Jan 2018 12:51:08 +0100
Subject: [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking
commits
During a non-blocking commit, it is possible to return before the
commit_tail work is queued (-ERESTARTSYS, for example).
Since a reference on the crtc commit object is obtained for the pending
vblank event when preparing the commit, the above situation will leave
us with an extra reference.
Therefore, if the commit_tail worker has not consumed the event at the
end of a commit, release it's reference.
Changes since v1:
- Also check for state->event->base.completion being set, to
handle the case where stall_checks() fails in setup_crtc_commit().
Changes since v2:
- Add a flag to drm_crtc_commit, to prevent dereferencing a freed event.
i915 may unreference the state in a worker.
Fixes: 24835e442f28 ("drm: reference count event->completion")
Cc: <stable(a)vger.kernel.org> # v4.11+
Signed-off-by: Leo (Sunpeng) Li <sunpeng.li(a)amd.com>
Acked-by: Harry Wentland <harry.wentland(a)amd.com> #v1
Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180117115108.29608-1-maarte…
Reviewed-by: Sean Paul <seanpaul(a)chromium.org>
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index b16f1d69a0bb..e8c249361d7e 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1778,6 +1778,8 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
new_crtc_state->event->base.completion = &commit->flip_done;
new_crtc_state->event->base.completion_release = release_crtc_commit;
drm_crtc_commit_get(commit);
+
+ commit->abort_completion = true;
}
for_each_oldnew_connector_in_state(state, conn, old_conn_state, new_conn_state, i) {
@@ -3327,8 +3329,21 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state)
{
if (state->commit) {
+ /*
+ * In the event that a non-blocking commit returns
+ * -ERESTARTSYS before the commit_tail work is queued, we will
+ * have an extra reference to the commit object. Release it, if
+ * the event has not been consumed by the worker.
+ *
+ * state->event may be freed, so we can't directly look at
+ * state->event->base.completion.
+ */
+ if (state->event && state->commit->abort_completion)
+ drm_crtc_commit_put(state->commit);
+
kfree(state->commit->event);
state->commit->event = NULL;
+
drm_crtc_commit_put(state->commit);
}
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 5afd6e364fb6..c63b0b48e884 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -134,6 +134,15 @@ struct drm_crtc_commit {
* &drm_pending_vblank_event pointer to clean up private events.
*/
struct drm_pending_vblank_event *event;
+
+ /**
+ * @abort_completion:
+ *
+ * A flag that's set after drm_atomic_helper_setup_commit takes a second
+ * reference for the completion of $drm_crtc_state.event. It's used by
+ * the free code to remove the second reference if commit fails.
+ */
+ bool abort_completion;
};
struct __drm_planes_state {
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 98112041bcca164676367e261c8c1073ef70cb51 Mon Sep 17 00:00:00 2001
From: Roger Quadros <rogerq(a)ti.com>
Date: Mon, 12 Feb 2018 15:30:08 +0200
Subject: [PATCH] usb: dwc3: core: Fix ULPI PHYs and prevent phy_get/ulpi_init
during suspend/resume
In order for ULPI PHYs to work, dwc3_phy_setup() and dwc3_ulpi_init()
must be doene before dwc3_core_get_phy().
commit 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys")
broke this.
The other issue is that dwc3_core_get_phy() and dwc3_ulpi_init() should
be called only once during the life cycle of the driver. However,
as dwc3_core_init() is called during system suspend/resume it will
result in multiple calls to dwc3_core_get_phy() and dwc3_ulpi_init()
which is wrong.
Fix this by moving dwc3_ulpi_init() out of dwc3_phy_setup()
into dwc3_core_ulpi_init(). Use a flag 'ulpi_ready' to ensure that
dwc3_core_ulpi_init() is called only once from dwc3_core_init().
Use another flag 'phys_ready' to call dwc3_core_get_phy() only once from
dwc3_core_init().
Fixes: 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys")
Fixes: f54edb539c11 ("usb: dwc3: core: initialize ULPI before trying to get the PHY")
Cc: linux-stable <stable(a)vger.kernel.org> # >= v4.13
Signed-off-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 59511f2cd3ac..f1d838a4acd6 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -486,6 +486,22 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
parms->hwparams8 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS8);
}
+static int dwc3_core_ulpi_init(struct dwc3 *dwc)
+{
+ int intf;
+ int ret = 0;
+
+ intf = DWC3_GHWPARAMS3_HSPHY_IFC(dwc->hwparams.hwparams3);
+
+ if (intf == DWC3_GHWPARAMS3_HSPHY_IFC_ULPI ||
+ (intf == DWC3_GHWPARAMS3_HSPHY_IFC_UTMI_ULPI &&
+ dwc->hsphy_interface &&
+ !strncmp(dwc->hsphy_interface, "ulpi", 4)))
+ ret = dwc3_ulpi_init(dwc);
+
+ return ret;
+}
+
/**
* dwc3_phy_setup - Configure USB PHY Interface of DWC3 Core
* @dwc: Pointer to our controller context structure
@@ -497,7 +513,6 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
static int dwc3_phy_setup(struct dwc3 *dwc)
{
u32 reg;
- int ret;
reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
@@ -568,9 +583,6 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
}
/* FALLTHROUGH */
case DWC3_GHWPARAMS3_HSPHY_IFC_ULPI:
- ret = dwc3_ulpi_init(dwc);
- if (ret)
- return ret;
/* FALLTHROUGH */
default:
break;
@@ -727,6 +739,7 @@ static void dwc3_core_setup_global_control(struct dwc3 *dwc)
}
static int dwc3_core_get_phy(struct dwc3 *dwc);
+static int dwc3_core_ulpi_init(struct dwc3 *dwc);
/**
* dwc3_core_init - Low-level initialization of DWC3 Core
@@ -758,17 +771,27 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc->maximum_speed = USB_SPEED_HIGH;
}
- ret = dwc3_core_get_phy(dwc);
+ ret = dwc3_phy_setup(dwc);
if (ret)
goto err0;
- ret = dwc3_core_soft_reset(dwc);
- if (ret)
- goto err0;
+ if (!dwc->ulpi_ready) {
+ ret = dwc3_core_ulpi_init(dwc);
+ if (ret)
+ goto err0;
+ dwc->ulpi_ready = true;
+ }
- ret = dwc3_phy_setup(dwc);
+ if (!dwc->phys_ready) {
+ ret = dwc3_core_get_phy(dwc);
+ if (ret)
+ goto err0a;
+ dwc->phys_ready = true;
+ }
+
+ ret = dwc3_core_soft_reset(dwc);
if (ret)
- goto err0;
+ goto err0a;
dwc3_core_setup_global_control(dwc);
dwc3_core_num_eps(dwc);
@@ -841,6 +864,9 @@ err1:
phy_exit(dwc->usb2_generic_phy);
phy_exit(dwc->usb3_generic_phy);
+err0a:
+ dwc3_ulpi_exit(dwc);
+
err0:
return ret;
}
@@ -1235,7 +1261,6 @@ err4:
err3:
dwc3_free_event_buffers(dwc);
- dwc3_ulpi_exit(dwc);
err2:
pm_runtime_allow(&pdev->dev);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 185b9603fd98..860d2bc184d1 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -797,7 +797,9 @@ struct dwc3_scratchpad_array {
* @usb3_phy: pointer to USB3 PHY
* @usb2_generic_phy: pointer to USB2 PHY
* @usb3_generic_phy: pointer to USB3 PHY
+ * @phys_ready: flag to indicate that PHYs are ready
* @ulpi: pointer to ulpi interface
+ * @ulpi_ready: flag to indicate that ULPI is initialized
* @u2sel: parameter from Set SEL request.
* @u2pel: parameter from Set SEL request.
* @u1sel: parameter from Set SEL request.
@@ -895,7 +897,10 @@ struct dwc3 {
struct phy *usb2_generic_phy;
struct phy *usb3_generic_phy;
+ bool phys_ready;
+
struct ulpi *ulpi;
+ bool ulpi_ready;
void __iomem *regs;
size_t regs_size;
The patch below does not apply to the 4.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 98112041bcca164676367e261c8c1073ef70cb51 Mon Sep 17 00:00:00 2001
From: Roger Quadros <rogerq(a)ti.com>
Date: Mon, 12 Feb 2018 15:30:08 +0200
Subject: [PATCH] usb: dwc3: core: Fix ULPI PHYs and prevent phy_get/ulpi_init
during suspend/resume
In order for ULPI PHYs to work, dwc3_phy_setup() and dwc3_ulpi_init()
must be doene before dwc3_core_get_phy().
commit 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys")
broke this.
The other issue is that dwc3_core_get_phy() and dwc3_ulpi_init() should
be called only once during the life cycle of the driver. However,
as dwc3_core_init() is called during system suspend/resume it will
result in multiple calls to dwc3_core_get_phy() and dwc3_ulpi_init()
which is wrong.
Fix this by moving dwc3_ulpi_init() out of dwc3_phy_setup()
into dwc3_core_ulpi_init(). Use a flag 'ulpi_ready' to ensure that
dwc3_core_ulpi_init() is called only once from dwc3_core_init().
Use another flag 'phys_ready' to call dwc3_core_get_phy() only once from
dwc3_core_init().
Fixes: 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys")
Fixes: f54edb539c11 ("usb: dwc3: core: initialize ULPI before trying to get the PHY")
Cc: linux-stable <stable(a)vger.kernel.org> # >= v4.13
Signed-off-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 59511f2cd3ac..f1d838a4acd6 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -486,6 +486,22 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
parms->hwparams8 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS8);
}
+static int dwc3_core_ulpi_init(struct dwc3 *dwc)
+{
+ int intf;
+ int ret = 0;
+
+ intf = DWC3_GHWPARAMS3_HSPHY_IFC(dwc->hwparams.hwparams3);
+
+ if (intf == DWC3_GHWPARAMS3_HSPHY_IFC_ULPI ||
+ (intf == DWC3_GHWPARAMS3_HSPHY_IFC_UTMI_ULPI &&
+ dwc->hsphy_interface &&
+ !strncmp(dwc->hsphy_interface, "ulpi", 4)))
+ ret = dwc3_ulpi_init(dwc);
+
+ return ret;
+}
+
/**
* dwc3_phy_setup - Configure USB PHY Interface of DWC3 Core
* @dwc: Pointer to our controller context structure
@@ -497,7 +513,6 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
static int dwc3_phy_setup(struct dwc3 *dwc)
{
u32 reg;
- int ret;
reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
@@ -568,9 +583,6 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
}
/* FALLTHROUGH */
case DWC3_GHWPARAMS3_HSPHY_IFC_ULPI:
- ret = dwc3_ulpi_init(dwc);
- if (ret)
- return ret;
/* FALLTHROUGH */
default:
break;
@@ -727,6 +739,7 @@ static void dwc3_core_setup_global_control(struct dwc3 *dwc)
}
static int dwc3_core_get_phy(struct dwc3 *dwc);
+static int dwc3_core_ulpi_init(struct dwc3 *dwc);
/**
* dwc3_core_init - Low-level initialization of DWC3 Core
@@ -758,17 +771,27 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc->maximum_speed = USB_SPEED_HIGH;
}
- ret = dwc3_core_get_phy(dwc);
+ ret = dwc3_phy_setup(dwc);
if (ret)
goto err0;
- ret = dwc3_core_soft_reset(dwc);
- if (ret)
- goto err0;
+ if (!dwc->ulpi_ready) {
+ ret = dwc3_core_ulpi_init(dwc);
+ if (ret)
+ goto err0;
+ dwc->ulpi_ready = true;
+ }
- ret = dwc3_phy_setup(dwc);
+ if (!dwc->phys_ready) {
+ ret = dwc3_core_get_phy(dwc);
+ if (ret)
+ goto err0a;
+ dwc->phys_ready = true;
+ }
+
+ ret = dwc3_core_soft_reset(dwc);
if (ret)
- goto err0;
+ goto err0a;
dwc3_core_setup_global_control(dwc);
dwc3_core_num_eps(dwc);
@@ -841,6 +864,9 @@ err1:
phy_exit(dwc->usb2_generic_phy);
phy_exit(dwc->usb3_generic_phy);
+err0a:
+ dwc3_ulpi_exit(dwc);
+
err0:
return ret;
}
@@ -1235,7 +1261,6 @@ err4:
err3:
dwc3_free_event_buffers(dwc);
- dwc3_ulpi_exit(dwc);
err2:
pm_runtime_allow(&pdev->dev);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 185b9603fd98..860d2bc184d1 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -797,7 +797,9 @@ struct dwc3_scratchpad_array {
* @usb3_phy: pointer to USB3 PHY
* @usb2_generic_phy: pointer to USB2 PHY
* @usb3_generic_phy: pointer to USB3 PHY
+ * @phys_ready: flag to indicate that PHYs are ready
* @ulpi: pointer to ulpi interface
+ * @ulpi_ready: flag to indicate that ULPI is initialized
* @u2sel: parameter from Set SEL request.
* @u2pel: parameter from Set SEL request.
* @u1sel: parameter from Set SEL request.
@@ -895,7 +897,10 @@ struct dwc3 {
struct phy *usb2_generic_phy;
struct phy *usb3_generic_phy;
+ bool phys_ready;
+
struct ulpi *ulpi;
+ bool ulpi_ready;
void __iomem *regs;
size_t regs_size;
The patch below does not apply to the 3.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From f035d139ffece7b6a7b8bfb17bd0ba715ee57a04 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 12 Jan 2018 18:18:27 -0800
Subject: [PATCH] usb: dwc3: ep0: Reset TRB counter for ep0 IN
DWC3 tracks TRB counter for each ep0 direction separately. In control
read transfer completion handler, the driver needs to reset the TRB
enqueue counter for ep0 IN direction. Currently the driver only resets
the TRB counter for control OUT endpoint. Check for the data direction
and properly reset the TRB counter from correct control endpoint.
Cc: stable(a)vger.kernel.org
Fixes: c2da2ff00606 ("usb: dwc3: ep0: don't use ep0in for transfers")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 9c2e4a17918e..18be31d5743a 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -854,7 +854,12 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
trb++;
trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
trace_dwc3_complete_trb(ep0, trb);
- ep0->trb_enqueue = 0;
+
+ if (r->direction)
+ dwc->eps[1]->trb_enqueue = 0;
+ else
+ dwc->eps[0]->trb_enqueue = 0;
+
dwc->ep0_bounced = false;
}
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From f035d139ffece7b6a7b8bfb17bd0ba715ee57a04 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 12 Jan 2018 18:18:27 -0800
Subject: [PATCH] usb: dwc3: ep0: Reset TRB counter for ep0 IN
DWC3 tracks TRB counter for each ep0 direction separately. In control
read transfer completion handler, the driver needs to reset the TRB
enqueue counter for ep0 IN direction. Currently the driver only resets
the TRB counter for control OUT endpoint. Check for the data direction
and properly reset the TRB counter from correct control endpoint.
Cc: stable(a)vger.kernel.org
Fixes: c2da2ff00606 ("usb: dwc3: ep0: don't use ep0in for transfers")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 9c2e4a17918e..18be31d5743a 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -854,7 +854,12 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
trb++;
trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
trace_dwc3_complete_trb(ep0, trb);
- ep0->trb_enqueue = 0;
+
+ if (r->direction)
+ dwc->eps[1]->trb_enqueue = 0;
+ else
+ dwc->eps[0]->trb_enqueue = 0;
+
dwc->ep0_bounced = false;
}
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From f035d139ffece7b6a7b8bfb17bd0ba715ee57a04 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 12 Jan 2018 18:18:27 -0800
Subject: [PATCH] usb: dwc3: ep0: Reset TRB counter for ep0 IN
DWC3 tracks TRB counter for each ep0 direction separately. In control
read transfer completion handler, the driver needs to reset the TRB
enqueue counter for ep0 IN direction. Currently the driver only resets
the TRB counter for control OUT endpoint. Check for the data direction
and properly reset the TRB counter from correct control endpoint.
Cc: stable(a)vger.kernel.org
Fixes: c2da2ff00606 ("usb: dwc3: ep0: don't use ep0in for transfers")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 9c2e4a17918e..18be31d5743a 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -854,7 +854,12 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
trb++;
trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
trace_dwc3_complete_trb(ep0, trb);
- ep0->trb_enqueue = 0;
+
+ if (r->direction)
+ dwc->eps[1]->trb_enqueue = 0;
+ else
+ dwc->eps[0]->trb_enqueue = 0;
+
dwc->ep0_bounced = false;
}
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From a06f818a70de21b4b3b4186816094208fc7accf9 Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon(a)arm.com>
Date: Mon, 19 Feb 2018 16:46:57 +0000
Subject: [PATCH] arm64: __show_regs: Only resolve kernel symbols when running
at EL1
__show_regs pretty prints PC and LR by attempting to map them to kernel
function names to improve the utility of crash reports. Unfortunately,
this mapping is applied even when the pt_regs corresponds to user mode,
resulting in a KASLR oracle.
Avoid this issue by only looking up the function symbols when the register
state indicates that we're actually running at EL1.
Cc: <stable(a)vger.kernel.org>
Reported-by: NCSC Security <security(a)ncsc.gov.uk>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index ad8aeb098b31..c0da6efe5465 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -220,8 +220,15 @@ void __show_regs(struct pt_regs *regs)
show_regs_print_info(KERN_DEFAULT);
print_pstate(regs);
- printk("pc : %pS\n", (void *)regs->pc);
- printk("lr : %pS\n", (void *)lr);
+
+ if (!user_mode(regs)) {
+ printk("pc : %pS\n", (void *)regs->pc);
+ printk("lr : %pS\n", (void *)lr);
+ } else {
+ printk("pc : %016llx\n", regs->pc);
+ printk("lr : %016llx\n", lr);
+ }
+
printk("sp : %016llx\n", sp);
i = top_reg;
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From a06f818a70de21b4b3b4186816094208fc7accf9 Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon(a)arm.com>
Date: Mon, 19 Feb 2018 16:46:57 +0000
Subject: [PATCH] arm64: __show_regs: Only resolve kernel symbols when running
at EL1
__show_regs pretty prints PC and LR by attempting to map them to kernel
function names to improve the utility of crash reports. Unfortunately,
this mapping is applied even when the pt_regs corresponds to user mode,
resulting in a KASLR oracle.
Avoid this issue by only looking up the function symbols when the register
state indicates that we're actually running at EL1.
Cc: <stable(a)vger.kernel.org>
Reported-by: NCSC Security <security(a)ncsc.gov.uk>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index ad8aeb098b31..c0da6efe5465 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -220,8 +220,15 @@ void __show_regs(struct pt_regs *regs)
show_regs_print_info(KERN_DEFAULT);
print_pstate(regs);
- printk("pc : %pS\n", (void *)regs->pc);
- printk("lr : %pS\n", (void *)lr);
+
+ if (!user_mode(regs)) {
+ printk("pc : %pS\n", (void *)regs->pc);
+ printk("lr : %pS\n", (void *)lr);
+ } else {
+ printk("pc : %016llx\n", regs->pc);
+ printk("lr : %016llx\n", lr);
+ }
+
printk("sp : %016llx\n", sp);
i = top_reg;
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From a06f818a70de21b4b3b4186816094208fc7accf9 Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon(a)arm.com>
Date: Mon, 19 Feb 2018 16:46:57 +0000
Subject: [PATCH] arm64: __show_regs: Only resolve kernel symbols when running
at EL1
__show_regs pretty prints PC and LR by attempting to map them to kernel
function names to improve the utility of crash reports. Unfortunately,
this mapping is applied even when the pt_regs corresponds to user mode,
resulting in a KASLR oracle.
Avoid this issue by only looking up the function symbols when the register
state indicates that we're actually running at EL1.
Cc: <stable(a)vger.kernel.org>
Reported-by: NCSC Security <security(a)ncsc.gov.uk>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index ad8aeb098b31..c0da6efe5465 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -220,8 +220,15 @@ void __show_regs(struct pt_regs *regs)
show_regs_print_info(KERN_DEFAULT);
print_pstate(regs);
- printk("pc : %pS\n", (void *)regs->pc);
- printk("lr : %pS\n", (void *)lr);
+
+ if (!user_mode(regs)) {
+ printk("pc : %pS\n", (void *)regs->pc);
+ printk("lr : %pS\n", (void *)lr);
+ } else {
+ printk("pc : %016llx\n", regs->pc);
+ printk("lr : %016llx\n", lr);
+ }
+
printk("sp : %016llx\n", sp);
i = top_reg;
Commit e864f39569f4 "fs: add RWF_DSYNC aand RWF_SYNC" added additional
way for direct IO to become synchronous and thus trigger fsync from the
IO completion handler. Then commit 9830f4be159b "fs: Use RWF_* flags for
AIO operations" allowed these flags to be set for AIO as well. However
that commit forgot to update the condition checking whether the IO
completion handling should be defered to a workqueue and thus AIO DIO
with RWF_[D]SYNC set will call fsync() from IRQ context resulting in
sleep in atomic.
Fix the problem by checking directly iocb flags (the same way as it is
done in dio_complete()) instead of checking all conditions that could
lead to IO being synchronous.
CC: Christoph Hellwig <hch(a)lst.de>
CC: Goldwyn Rodrigues <rgoldwyn(a)suse.com>
CC: stable(a)vger.kernel.org
Reported-by: Mark Rutland <mark.rutland(a)arm.com>
Tested-by: Mark Rutland <mark.rutland(a)arm.com>
Fixes: 9830f4be159b29399d107bffb99e0132bc5aedd4
Signed-off-by: Jan Kara <jack(a)suse.cz>
---
fs/direct-io.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/direct-io.c b/fs/direct-io.c
index a0ca9e48e993..1357ef563893 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -1274,8 +1274,7 @@ do_blockdev_direct_IO(struct kiocb *iocb, struct inode *inode,
*/
if (dio->is_async && iov_iter_rw(iter) == WRITE) {
retval = 0;
- if ((iocb->ki_filp->f_flags & O_DSYNC) ||
- IS_SYNC(iocb->ki_filp->f_mapping->host))
+ if (iocb->ki_flags & IOCB_DSYNC)
retval = dio_set_defer_completion(dio);
else if (!dio->inode->i_sb->s_dio_done_wq) {
/*
--
2.13.6
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 4b34968e77ad09628cfb3c4a7daf2adc2cefc6e8 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Thu, 22 Feb 2018 14:38:34 +0000
Subject: [PATCH] X.509: fix NULL dereference when restricting key with
unsupported_sig
The asymmetric key type allows an X.509 certificate to be added even if
its signature's hash algorithm is not available in the crypto API. In
that case 'payload.data[asym_auth]' will be NULL. But the key
restriction code failed to check for this case before trying to use the
signature, resulting in a NULL pointer dereference in
key_or_keyring_common() or in restrict_link_by_signature().
Fix this by returning -ENOPKG when the signature is unsupported.
Reproducer when all the CONFIG_CRYPTO_SHA512* options are disabled and
keyctl has support for the 'restrict_keyring' command:
keyctl new_session
keyctl restrict_keyring @s asymmetric builtin_trusted
openssl req -new -sha512 -x509 -batch -nodes -outform der \
| keyctl padd asymmetric desc @s
Fixes: a511e1af8b12 ("KEYS: Move the point of trust determination to __key_link()")
Cc: <stable(a)vger.kernel.org> # v4.7+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
diff --git a/crypto/asymmetric_keys/restrict.c b/crypto/asymmetric_keys/restrict.c
index 86fb68508952..7c93c7728454 100644
--- a/crypto/asymmetric_keys/restrict.c
+++ b/crypto/asymmetric_keys/restrict.c
@@ -67,8 +67,9 @@ __setup("ca_keys=", ca_keys_setup);
*
* Returns 0 if the new certificate was accepted, -ENOKEY if we couldn't find a
* matching parent certificate in the trusted list, -EKEYREJECTED if the
- * signature check fails or the key is blacklisted and some other error if
- * there is a matching certificate but the signature check cannot be performed.
+ * signature check fails or the key is blacklisted, -ENOPKG if the signature
+ * uses unsupported crypto, or some other error if there is a matching
+ * certificate but the signature check cannot be performed.
*/
int restrict_link_by_signature(struct key *dest_keyring,
const struct key_type *type,
@@ -88,6 +89,8 @@ int restrict_link_by_signature(struct key *dest_keyring,
return -EOPNOTSUPP;
sig = payload->data[asym_auth];
+ if (!sig)
+ return -ENOPKG;
if (!sig->auth_ids[0] && !sig->auth_ids[1])
return -ENOKEY;
@@ -139,6 +142,8 @@ static int key_or_keyring_common(struct key *dest_keyring,
return -EOPNOTSUPP;
sig = payload->data[asym_auth];
+ if (!sig)
+ return -ENOPKG;
if (!sig->auth_ids[0] && !sig->auth_ids[1])
return -ENOKEY;
@@ -222,9 +227,9 @@ static int key_or_keyring_common(struct key *dest_keyring,
*
* Returns 0 if the new certificate was accepted, -ENOKEY if we
* couldn't find a matching parent certificate in the trusted list,
- * -EKEYREJECTED if the signature check fails, and some other error if
- * there is a matching certificate but the signature check cannot be
- * performed.
+ * -EKEYREJECTED if the signature check fails, -ENOPKG if the signature uses
+ * unsupported crypto, or some other error if there is a matching certificate
+ * but the signature check cannot be performed.
*/
int restrict_link_by_key_or_keyring(struct key *dest_keyring,
const struct key_type *type,
@@ -249,9 +254,9 @@ int restrict_link_by_key_or_keyring(struct key *dest_keyring,
*
* Returns 0 if the new certificate was accepted, -ENOKEY if we
* couldn't find a matching parent certificate in the trusted list,
- * -EKEYREJECTED if the signature check fails, and some other error if
- * there is a matching certificate but the signature check cannot be
- * performed.
+ * -EKEYREJECTED if the signature check fails, -ENOPKG if the signature uses
+ * unsupported crypto, or some other error if there is a matching certificate
+ * but the signature check cannot be performed.
*/
int restrict_link_by_key_or_keyring_chain(struct key *dest_keyring,
const struct key_type *type,
This is a note to let you know that I've just added the patch titled
arm64: mm: don't write garbage into TTBR1_EL1 register
to the 4.4-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:
arm64-mm-don-t-write-garbage-into-ttbr1_el1-register.patch
and it can be found in the queue-4.4 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 ard.biesheuvel(a)linaro.org Mon Feb 26 13:53:22 2018
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Fri, 23 Feb 2018 18:29:02 +0000
Subject: arm64: mm: don't write garbage into TTBR1_EL1 register
To: linux-arm-kernel(a)lists.infradead.org
Cc: catalin.marinas(a)arm.com, will.deacon(a)arm.com, marc.zyngier(a)arm.com, mark.rutland(a)arm.com, nicolas.dechesne(a)linaro.org, gregkh(a)linuxfoundation.org, Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Message-ID: <20180223182902.24873-1-ard.biesheuvel(a)linaro.org>
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Stable backport commit 173358a49173 ("arm64: kpti: Add ->enable callback
to remap swapper using nG mappings") of upstream commit f992b4dfd58b did
not survive the backporting process unscathed, and ends up writing garbage
into the TTBR1_EL1 register, rather than pointing it to the zero page to
disable translations. Fix that.
Cc: <stable(a)vger.kernel.org> #v4.14
Reported-by: Nicolas Dechesne <nicolas.dechesne(a)linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Acked-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/mm/proc.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 08572f95bd8a..2b473ddeb7a3 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -155,7 +155,7 @@ ENDPROC(cpu_do_switch_mm)
.macro __idmap_cpu_set_reserved_ttbr1, tmp1, tmp2
adrp \tmp1, empty_zero_page
- msr ttbr1_el1, \tmp2
+ msr ttbr1_el1, \tmp1
isb
tlbi vmalle1
dsb nsh
--
2.11.0
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.4/arm64-mm-don-t-write-garbage-into-ttbr1_el1-register.patch
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: vivid: check if the cec_adapter is valid
Author: Hans Verkuil <hverkuil(a)xs4all.nl>
Date: Mon Feb 12 06:45:32 2018 -0500
If CEC is not enabled for the vivid driver, then the adap pointer is NULL
and 'adap->phys_addr' will fail.
Cc: <stable(a)vger.kernel.org> # for v4.12 and up
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
drivers/media/platform/vivid/vivid-vid-common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
---
diff --git a/drivers/media/platform/vivid/vivid-vid-common.c b/drivers/media/platform/vivid/vivid-vid-common.c
index cc67f403a808..e5914be0e12d 100644
--- a/drivers/media/platform/vivid/vivid-vid-common.c
+++ b/drivers/media/platform/vivid/vivid-vid-common.c
@@ -862,7 +862,8 @@ int vidioc_g_edid(struct file *file, void *_fh,
return -EINVAL;
if (edid->start_block + edid->blocks > dev->edid_blocks)
edid->blocks = dev->edid_blocks - edid->start_block;
- cec_set_edid_phys_addr(dev->edid, dev->edid_blocks * 128, adap->phys_addr);
+ if (adap)
+ cec_set_edid_phys_addr(dev->edid, dev->edid_blocks * 128, adap->phys_addr);
memcpy(edid->edid, dev->edid + edid->start_block * 128, edid->blocks * 128);
return 0;
}
This is a note to let you know that I've just added the patch titled
PCI: keystone: Fix interrupt-controller-node lookup
to the 4.4-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:
pci-keystone-fix-interrupt-controller-node-lookup.patch
and it can be found in the queue-4.4 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 eac56aa3bc8af3d9b9850345d0f2da9d83529134 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Fri, 17 Nov 2017 14:38:31 +0100
Subject: PCI: keystone: Fix interrupt-controller-node lookup
From: Johan Hovold <johan(a)kernel.org>
commit eac56aa3bc8af3d9b9850345d0f2da9d83529134 upstream.
Fix child-node lookup during initialisation which was using the wrong
OF-helper and ended up searching the whole device tree depth-first
starting at the parent rather than just matching on its children.
To make things worse, the parent pci node could end up being prematurely
freed as of_find_node_by_name() drops a reference to its first argument.
Any matching child interrupt-controller node was also leaked.
Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
Cc: stable <stable(a)vger.kernel.org> # 3.18
Acked-by: Murali Karicheri <m-karicheri2(a)ti.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
[lorenzo.pieralisi(a)arm.com: updated commit subject]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
[johan: backport to 4.4]
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/host/pci-keystone.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/pci/host/pci-keystone.c
+++ b/drivers/pci/host/pci-keystone.c
@@ -179,14 +179,16 @@ static int ks_pcie_get_irq_controller_in
}
/* interrupt controller is in a child node */
- *np_temp = of_find_node_by_name(np_pcie, controller);
+ *np_temp = of_get_child_by_name(np_pcie, controller);
if (!(*np_temp)) {
dev_err(dev, "Node for %s is absent\n", controller);
goto out;
}
temp = of_irq_count(*np_temp);
- if (!temp)
+ if (!temp) {
+ of_node_put(*np_temp);
goto out;
+ }
if (temp > max_host_irqs)
dev_warn(dev, "Too many %s interrupts defined %u\n",
(legacy ? "legacy" : "MSI"), temp);
@@ -200,6 +202,9 @@ static int ks_pcie_get_irq_controller_in
if (!host_irqs[temp])
break;
}
+
+ of_node_put(*np_temp);
+
if (temp) {
*num_irqs = temp;
ret = 0;
Patches currently in stable-queue which might be from johan(a)kernel.org are
queue-4.4/pci-keystone-fix-interrupt-controller-node-lookup.patch
This is a note to let you know that I've just added the patch titled
ip_tunnel: fix preempt warning in ip tunnel creation/updating
to the 4.4-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:
ip_tunnel-fix-preempt-warning-in-ip-tunnel-creation-updating.patch
and it can be found in the queue-4.4 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 f27337e16f2d0e52a8d05ea599ed13cd266ac291 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni(a)redhat.com>
Date: Thu, 28 Apr 2016 11:04:51 +0200
Subject: ip_tunnel: fix preempt warning in ip tunnel creation/updating
From: Paolo Abeni <pabeni(a)redhat.com>
commit f27337e16f2d0e52a8d05ea599ed13cd266ac291 upstream.
After the commit e09acddf873b ("ip_tunnel: replace dst_cache with generic
implementation"), a preemption debug warning is triggered on ip4
tunnels updating; the dst cache helper needs to be invoked in unpreemptible
context.
We don't need to load the cache on tunnel update, so this commit fixes
the warning replacing the load with a dst cache reset, which is
preempt safe.
Fixes: e09acddf873b ("ip_tunnel: replace dst_cache with generic implementation")
Reported-by: Eric Dumazet <eric.dumazet(a)gmail.com>
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
Acked-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ip_tunnel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -327,12 +327,12 @@ static int ip_tunnel_bind_dev(struct net
if (!IS_ERR(rt)) {
tdev = rt->dst.dev;
- dst_cache_set_ip4(&tunnel->dst_cache, &rt->dst,
- fl4.saddr);
ip_rt_put(rt);
}
if (dev->type != ARPHRD_ETHER)
dev->flags |= IFF_POINTOPOINT;
+
+ dst_cache_reset(&tunnel->dst_cache);
}
if (!tdev && tunnel->parms.link)
Patches currently in stable-queue which might be from pabeni(a)redhat.com are
queue-4.4/ip_tunnel-fix-preempt-warning-in-ip-tunnel-creation-updating.patch
queue-4.4/ip_tunnel-replace-dst_cache-with-generic-implementation.patch
queue-4.4/netfilter-drop-outermost-socket-lock-in-getsockopt.patch
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: vb2: core: Finish buffers at the end of the stream
Author: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Date: Fri Feb 2 05:08:59 2018 -0500
If buffers were prepared or queued and the buffers were released without
starting the queue, the finish mem op (corresponding to the prepare mem
op) was never called to the buffers.
Before commit a136f59c0a1f there was no need to do this as in such a case
the prepare mem op had not been called yet. Address the problem by
explicitly calling finish mem op when the queue is stopped if the buffer
is in either prepared or queued state.
Fixes: a136f59c0a1f ("[media] vb2: Move buffer cache synchronisation to prepare from queue")
Cc: stable(a)vger.kernel.org # for v4.13 and up
Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Tested-by: Devin Heitmueller <dheitmueller(a)kernellabs.com>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
drivers/media/common/videobuf2/videobuf2-core.c | 9 +++++++++
1 file changed, 9 insertions(+)
---
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c
index debe35fc66b4..d3f7bb33a54d 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -1696,6 +1696,15 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
for (i = 0; i < q->num_buffers; ++i) {
struct vb2_buffer *vb = q->bufs[i];
+ if (vb->state == VB2_BUF_STATE_PREPARED ||
+ vb->state == VB2_BUF_STATE_QUEUED) {
+ unsigned int plane;
+
+ for (plane = 0; plane < vb->num_planes; ++plane)
+ call_void_memop(vb, finish,
+ vb->planes[plane].mem_priv);
+ }
+
if (vb->state != VB2_BUF_STATE_DEQUEUED) {
vb->state = VB2_BUF_STATE_PREPARED;
call_void_vb_qop(vb, buf_finish, vb);
This is a note to let you know that I've just added the patch titled
MIPS: boot: Define __ASSEMBLY__ for its.S build
to the 4.15-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:
mips-boot-define-__assembly__-for-its.s-build.patch
and it can be found in the queue-4.15 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 0f9da844d87796ac31b04e81ee95e155e9043132 Mon Sep 17 00:00:00 2001
From: Kees Cook <keescook(a)chromium.org>
Date: Thu, 22 Feb 2018 16:59:26 -0800
Subject: MIPS: boot: Define __ASSEMBLY__ for its.S build
From: Kees Cook <keescook(a)chromium.org>
commit 0f9da844d87796ac31b04e81ee95e155e9043132 upstream.
The MIPS %.its.S compiler command did not define __ASSEMBLY__, which meant
when compiler_types.h was added to kconfig.h, unexpected things appeared
(e.g. struct declarations) which should not have been present. As done in
the general %.S compiler command, __ASSEMBLY__ is now included here too.
The failure was:
Error: arch/mips/boot/vmlinux.gz.its:201.1-2 syntax error
FATAL ERROR: Unable to parse input tree
/usr/bin/mkimage: Can't read arch/mips/boot/vmlinux.gz.itb.tmp: Invalid argument
/usr/bin/mkimage Can't add hashes to FIT blob
Reported-by: kbuild test robot <lkp(a)intel.com>
Fixes: 28128c61e08e ("kconfig.h: Include compiler types to avoid missed struct attributes")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/boot/Makefile | 1 +
1 file changed, 1 insertion(+)
--- a/arch/mips/boot/Makefile
+++ b/arch/mips/boot/Makefile
@@ -126,6 +126,7 @@ $(obj)/vmlinux.its.S: $(addprefix $(srct
quiet_cmd_cpp_its_S = ITS $@
cmd_cpp_its_S = $(CPP) $(cpp_flags) -P -C -o $@ $< \
+ -D__ASSEMBLY__ \
-DKERNEL_NAME="\"Linux $(KERNELRELEASE)\"" \
-DVMLINUX_BINARY="\"$(3)\"" \
-DVMLINUX_COMPRESSION="\"$(2)\"" \
Patches currently in stable-queue which might be from keescook(a)chromium.org are
queue-4.15/mips-boot-define-__assembly__-for-its.s-build.patch
queue-4.15/kconfig.h-include-compiler-types-to-avoid-missed-struct-attributes.patch
This is a note to let you know that I've just added the patch titled
kconfig.h: Include compiler types to avoid missed struct attributes
to the 4.15-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:
kconfig.h-include-compiler-types-to-avoid-missed-struct-attributes.patch
and it can be found in the queue-4.15 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 28128c61e08eaeced9cc8ec0e6b5d677b5b94690 Mon Sep 17 00:00:00 2001
From: Kees Cook <keescook(a)chromium.org>
Date: Thu, 22 Feb 2018 09:41:40 -0800
Subject: kconfig.h: Include compiler types to avoid missed struct attributes
From: Kees Cook <keescook(a)chromium.org>
commit 28128c61e08eaeced9cc8ec0e6b5d677b5b94690 upstream.
The header files for some structures could get included in such a way
that struct attributes (specifically __randomize_layout from path.h) would
be parsed as variable names instead of attributes. This could lead to
some instances of a structure being unrandomized, causing nasty GPFs, etc.
This patch makes sure the compiler_types.h header is included in
kconfig.h so that we've always got types and struct attributes defined,
since kconfig.h is included from the compiler command line.
Reported-by: Patrick McLean <chutzpah(a)gentoo.org>
Root-caused-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name>
Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Tested-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name>
Fixes: 3859a271a003 ("randstruct: Mark various structs for randomization")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/kconfig.h | 3 +++
1 file changed, 3 insertions(+)
--- a/include/linux/kconfig.h
+++ b/include/linux/kconfig.h
@@ -64,4 +64,7 @@
*/
#define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))
+/* Make sure we always have all types and struct attributes defined. */
+#include <linux/compiler_types.h>
+
#endif /* __LINUX_KCONFIG_H */
Patches currently in stable-queue which might be from keescook(a)chromium.org are
queue-4.15/mips-boot-define-__assembly__-for-its.s-build.patch
queue-4.15/kconfig.h-include-compiler-types-to-avoid-missed-struct-attributes.patch
This is a note to let you know that I've just added the patch titled
arm64: mm: don't write garbage into TTBR1_EL1 register
to the 4.15-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:
arm64-mm-don-t-write-garbage-into-ttbr1_el1-register.patch
and it can be found in the queue-4.15 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 ard.biesheuvel(a)linaro.org Mon Feb 26 13:53:22 2018
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Fri, 23 Feb 2018 18:29:02 +0000
Subject: arm64: mm: don't write garbage into TTBR1_EL1 register
To: linux-arm-kernel(a)lists.infradead.org
Cc: catalin.marinas(a)arm.com, will.deacon(a)arm.com, marc.zyngier(a)arm.com, mark.rutland(a)arm.com, nicolas.dechesne(a)linaro.org, gregkh(a)linuxfoundation.org, Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Message-ID: <20180223182902.24873-1-ard.biesheuvel(a)linaro.org>
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Stable backport commit 173358a49173 ("arm64: kpti: Add ->enable callback
to remap swapper using nG mappings") of upstream commit f992b4dfd58b did
not survive the backporting process unscathed, and ends up writing garbage
into the TTBR1_EL1 register, rather than pointing it to the zero page to
disable translations. Fix that.
Cc: <stable(a)vger.kernel.org> #v4.14
Reported-by: Nicolas Dechesne <nicolas.dechesne(a)linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Acked-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/mm/proc.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -155,7 +155,7 @@ ENDPROC(cpu_do_switch_mm)
.macro __idmap_cpu_set_reserved_ttbr1, tmp1, tmp2
adrp \tmp1, empty_zero_page
- msr ttbr1_el1, \tmp2
+ msr ttbr1_el1, \tmp1
isb
tlbi vmalle1
dsb nsh
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.15/arm64-mm-don-t-write-garbage-into-ttbr1_el1-register.patch
This is a note to let you know that I've just added the patch titled
MIPS: boot: Define __ASSEMBLY__ for its.S build
to the 4.14-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:
mips-boot-define-__assembly__-for-its.s-build.patch
and it can be found in the queue-4.14 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 0f9da844d87796ac31b04e81ee95e155e9043132 Mon Sep 17 00:00:00 2001
From: Kees Cook <keescook(a)chromium.org>
Date: Thu, 22 Feb 2018 16:59:26 -0800
Subject: MIPS: boot: Define __ASSEMBLY__ for its.S build
From: Kees Cook <keescook(a)chromium.org>
commit 0f9da844d87796ac31b04e81ee95e155e9043132 upstream.
The MIPS %.its.S compiler command did not define __ASSEMBLY__, which meant
when compiler_types.h was added to kconfig.h, unexpected things appeared
(e.g. struct declarations) which should not have been present. As done in
the general %.S compiler command, __ASSEMBLY__ is now included here too.
The failure was:
Error: arch/mips/boot/vmlinux.gz.its:201.1-2 syntax error
FATAL ERROR: Unable to parse input tree
/usr/bin/mkimage: Can't read arch/mips/boot/vmlinux.gz.itb.tmp: Invalid argument
/usr/bin/mkimage Can't add hashes to FIT blob
Reported-by: kbuild test robot <lkp(a)intel.com>
Fixes: 28128c61e08e ("kconfig.h: Include compiler types to avoid missed struct attributes")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/boot/Makefile | 1 +
1 file changed, 1 insertion(+)
--- a/arch/mips/boot/Makefile
+++ b/arch/mips/boot/Makefile
@@ -126,6 +126,7 @@ $(obj)/vmlinux.its.S: $(addprefix $(srct
quiet_cmd_cpp_its_S = ITS $@
cmd_cpp_its_S = $(CPP) $(cpp_flags) -P -C -o $@ $< \
+ -D__ASSEMBLY__ \
-DKERNEL_NAME="\"Linux $(KERNELRELEASE)\"" \
-DVMLINUX_BINARY="\"$(3)\"" \
-DVMLINUX_COMPRESSION="\"$(2)\"" \
Patches currently in stable-queue which might be from keescook(a)chromium.org are
queue-4.14/mips-boot-define-__assembly__-for-its.s-build.patch
queue-4.14/kconfig.h-include-compiler-types-to-avoid-missed-struct-attributes.patch
This is a note to let you know that I've just added the patch titled
kconfig.h: Include compiler types to avoid missed struct attributes
to the 4.14-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:
kconfig.h-include-compiler-types-to-avoid-missed-struct-attributes.patch
and it can be found in the queue-4.14 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 28128c61e08eaeced9cc8ec0e6b5d677b5b94690 Mon Sep 17 00:00:00 2001
From: Kees Cook <keescook(a)chromium.org>
Date: Thu, 22 Feb 2018 09:41:40 -0800
Subject: kconfig.h: Include compiler types to avoid missed struct attributes
From: Kees Cook <keescook(a)chromium.org>
commit 28128c61e08eaeced9cc8ec0e6b5d677b5b94690 upstream.
The header files for some structures could get included in such a way
that struct attributes (specifically __randomize_layout from path.h) would
be parsed as variable names instead of attributes. This could lead to
some instances of a structure being unrandomized, causing nasty GPFs, etc.
This patch makes sure the compiler_types.h header is included in
kconfig.h so that we've always got types and struct attributes defined,
since kconfig.h is included from the compiler command line.
Reported-by: Patrick McLean <chutzpah(a)gentoo.org>
Root-caused-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name>
Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Tested-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name>
Fixes: 3859a271a003 ("randstruct: Mark various structs for randomization")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/kconfig.h | 3 +++
1 file changed, 3 insertions(+)
--- a/include/linux/kconfig.h
+++ b/include/linux/kconfig.h
@@ -64,4 +64,7 @@
*/
#define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))
+/* Make sure we always have all types and struct attributes defined. */
+#include <linux/compiler_types.h>
+
#endif /* __LINUX_KCONFIG_H */
Patches currently in stable-queue which might be from keescook(a)chromium.org are
queue-4.14/mips-boot-define-__assembly__-for-its.s-build.patch
queue-4.14/kconfig.h-include-compiler-types-to-avoid-missed-struct-attributes.patch
This is a note to let you know that I've just added the patch titled
arm64: mm: don't write garbage into TTBR1_EL1 register
to the 4.14-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:
arm64-mm-don-t-write-garbage-into-ttbr1_el1-register.patch
and it can be found in the queue-4.14 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 ard.biesheuvel(a)linaro.org Mon Feb 26 13:53:22 2018
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Fri, 23 Feb 2018 18:29:02 +0000
Subject: arm64: mm: don't write garbage into TTBR1_EL1 register
To: linux-arm-kernel(a)lists.infradead.org
Cc: catalin.marinas(a)arm.com, will.deacon(a)arm.com, marc.zyngier(a)arm.com, mark.rutland(a)arm.com, nicolas.dechesne(a)linaro.org, gregkh(a)linuxfoundation.org, Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Message-ID: <20180223182902.24873-1-ard.biesheuvel(a)linaro.org>
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Stable backport commit 173358a49173 ("arm64: kpti: Add ->enable callback
to remap swapper using nG mappings") of upstream commit f992b4dfd58b did
not survive the backporting process unscathed, and ends up writing garbage
into the TTBR1_EL1 register, rather than pointing it to the zero page to
disable translations. Fix that.
Cc: <stable(a)vger.kernel.org> #v4.14
Reported-by: Nicolas Dechesne <nicolas.dechesne(a)linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Acked-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/mm/proc.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -155,7 +155,7 @@ ENDPROC(cpu_do_switch_mm)
.macro __idmap_cpu_set_reserved_ttbr1, tmp1, tmp2
adrp \tmp1, empty_zero_page
- msr ttbr1_el1, \tmp2
+ msr ttbr1_el1, \tmp1
isb
tlbi vmalle1
dsb nsh
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.14/arm64-mm-don-t-write-garbage-into-ttbr1_el1-register.patch
This is a note to let you know that I've just added the patch titled
PCI: keystone: Fix interrupt-controller-node lookup
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:
pci-keystone-fix-interrupt-controller-node-lookup.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 eac56aa3bc8af3d9b9850345d0f2da9d83529134 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Fri, 17 Nov 2017 14:38:31 +0100
Subject: PCI: keystone: Fix interrupt-controller-node lookup
From: Johan Hovold <johan(a)kernel.org>
commit eac56aa3bc8af3d9b9850345d0f2da9d83529134 upstream.
Fix child-node lookup during initialisation which was using the wrong
OF-helper and ended up searching the whole device tree depth-first
starting at the parent rather than just matching on its children.
To make things worse, the parent pci node could end up being prematurely
freed as of_find_node_by_name() drops a reference to its first argument.
Any matching child interrupt-controller node was also leaked.
Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
Cc: stable <stable(a)vger.kernel.org> # 3.18
Acked-by: Murali Karicheri <m-karicheri2(a)ti.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
[lorenzo.pieralisi(a)arm.com: updated commit subject]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
[johan: backport to 4.4]
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/host/pci-keystone.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/pci/host/pci-keystone.c
+++ b/drivers/pci/host/pci-keystone.c
@@ -179,14 +179,16 @@ static int ks_pcie_get_irq_controller_in
}
/* interrupt controller is in a child node */
- *np_temp = of_find_node_by_name(np_pcie, controller);
+ *np_temp = of_get_child_by_name(np_pcie, controller);
if (!(*np_temp)) {
dev_err(dev, "Node for %s is absent\n", controller);
goto out;
}
temp = of_irq_count(*np_temp);
- if (!temp)
+ if (!temp) {
+ of_node_put(*np_temp);
goto out;
+ }
if (temp > max_host_irqs)
dev_warn(dev, "Too many %s interrupts defined %u\n",
(legacy ? "legacy" : "MSI"), temp);
@@ -200,6 +202,9 @@ static int ks_pcie_get_irq_controller_in
if (host_irqs[temp] < 0)
break;
}
+
+ of_node_put(*np_temp);
+
if (temp) {
*num_irqs = temp;
ret = 0;
Patches currently in stable-queue which might be from johan(a)kernel.org are
queue-3.18/pci-keystone-fix-interrupt-controller-node-lookup.patch
commit 28128c61e08eaeced9cc8ec0e6b5d677b5b94690 upstream.
The header files for some structures could get included in such a way
that struct attributes (specifically __randomize_layout from path.h) would
be parsed as variable names instead of attributes. This could lead to
some instances of a structure being unrandomized, causing nasty GPFs, etc.
This patch makes sure the compiler_types.h header is included in path.h.
Reported-by: Patrick McLean <chutzpah(a)gentoo.org>
Root-caused-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name>
Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Tested-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name>
Fixes: 3859a271a003 ("randstruct: Mark various structs for randomization")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
[kees: Adjusted to just path.h for -stable, as this is a smaller change]
Signed-off-by: Kees Cook <keescook(a)chromium.org>
---
This is a much more narrow fix for the issue. I adjusted the commit subject
and body, but still reference the "full" upstream commit. Is this the best
way to handle this?
---
include/linux/path.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/path.h b/include/linux/path.h
index 81e65a5be7ce..74a59d190a3c 100644
--- a/include/linux/path.h
+++ b/include/linux/path.h
@@ -2,6 +2,8 @@
#ifndef _LINUX_PATH_H
#define _LINUX_PATH_H
+#include <linux/compiler_types.h>
+
struct dentry;
struct vfsmount;
--
2.7.4
--
Kees Cook
Pixel Security
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: usbtv: prevent double free in error case
Author: Oliver Neukum <oneukum(a)suse.com>
Date: Mon Jan 8 09:21:07 2018 -0500
Quoting the original report:
It looks like there is a double-free vulnerability in Linux usbtv driver
on an error path of usbtv_probe function. When audio registration fails,
usbtv_video_free function ends up freeing usbtv data structure, which
gets freed the second time under usbtv_video_fail label.
usbtv_audio_fail:
usbtv_video_free(usbtv); =>
v4l2_device_put(&usbtv->v4l2_dev);
=> v4l2_device_put
=> kref_put
=> v4l2_device_release
=> usbtv_release (CALLBACK)
=> kfree(usbtv) (1st time)
usbtv_video_fail:
usb_set_intfdata(intf, NULL);
usb_put_dev(usbtv->udev);
kfree(usbtv); (2nd time)
So, as we have refcounting, use it
Reported-by: Yavuz, Tuba <tuba(a)ece.ufl.edu>
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
CC: stable(a)vger.kernel.org
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
drivers/media/usb/usbtv/usbtv-core.c | 2 ++
1 file changed, 2 insertions(+)
---
diff --git a/drivers/media/usb/usbtv/usbtv-core.c b/drivers/media/usb/usbtv/usbtv-core.c
index 127f8a0c098b..0c2e628e8723 100644
--- a/drivers/media/usb/usbtv/usbtv-core.c
+++ b/drivers/media/usb/usbtv/usbtv-core.c
@@ -112,6 +112,8 @@ static int usbtv_probe(struct usb_interface *intf,
return 0;
usbtv_audio_fail:
+ /* we must not free at this point */
+ usb_get_dev(usbtv->udev);
usbtv_video_free(usbtv);
usbtv_video_fail:
The patch
ASoC: sun4i-i2s: Fix RX slot number of SUN8I
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 5a3386790a172cf738194e1574f631cd43c6140a Mon Sep 17 00:00:00 2001
From: Yong Deng <yong.deng(a)magewell.com>
Date: Mon, 26 Feb 2018 10:43:52 +0800
Subject: [PATCH] ASoC: sun4i-i2s: Fix RX slot number of SUN8I
I2S's RX slot number of SUN8I should be shifted 4 bit to left.
Fixes: 7d2993811a1e ("ASoC: sun4i-i2s: Add support for H3")
Signed-off-by: Yong Deng <yong.deng(a)magewell.com>
Reviewed-by: Chen-Yu Tsai <wens(a)csie.org>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
sound/soc/sunxi/sun4i-i2s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index dca1143c1150..a4aa931ebfae 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -104,7 +104,7 @@
#define SUN8I_I2S_CHAN_CFG_REG 0x30
#define SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM_MASK GENMASK(6, 4)
-#define SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM(chan) (chan - 1)
+#define SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM(chan) ((chan - 1) << 4)
#define SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM_MASK GENMASK(2, 0)
#define SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM(chan) (chan - 1)
--
2.16.1
commit eac56aa3bc8af3d9b9850345d0f2da9d83529134 upstream.
Fix child-node lookup during initialisation which was using the wrong
OF-helper and ended up searching the whole device tree depth-first
starting at the parent rather than just matching on its children.
To make things worse, the parent pci node could end up being prematurely
freed as of_find_node_by_name() drops a reference to its first argument.
Any matching child interrupt-controller node was also leaked.
Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
Cc: stable <stable(a)vger.kernel.org> # 3.18
Acked-by: Murali Karicheri <m-karicheri2(a)ti.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
[lorenzo.pieralisi(a)arm.com: updated commit subject]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
[johan: backport to 4.4]
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
drivers/pci/host/pci-keystone.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/host/pci-keystone.c b/drivers/pci/host/pci-keystone.c
index 0aa81bd3de12..fb682e8af74d 100644
--- a/drivers/pci/host/pci-keystone.c
+++ b/drivers/pci/host/pci-keystone.c
@@ -179,14 +179,16 @@ static int ks_pcie_get_irq_controller_info(struct keystone_pcie *ks_pcie,
}
/* interrupt controller is in a child node */
- *np_temp = of_find_node_by_name(np_pcie, controller);
+ *np_temp = of_get_child_by_name(np_pcie, controller);
if (!(*np_temp)) {
dev_err(dev, "Node for %s is absent\n", controller);
goto out;
}
temp = of_irq_count(*np_temp);
- if (!temp)
+ if (!temp) {
+ of_node_put(*np_temp);
goto out;
+ }
if (temp > max_host_irqs)
dev_warn(dev, "Too many %s interrupts defined %u\n",
(legacy ? "legacy" : "MSI"), temp);
@@ -200,6 +202,9 @@ static int ks_pcie_get_irq_controller_info(struct keystone_pcie *ks_pcie,
if (!host_irqs[temp])
break;
}
+
+ of_node_put(*np_temp);
+
if (temp) {
*num_irqs = temp;
ret = 0;
--
2.16.2
Changes since v1 [1]:
* Fix the detection of device-dax file instances in vma_is_fsdax().
(Haozhong, Gerd)
* Fix compile breakage in the FS_DAX=n and DEV_DAX=y case. (0day robot)
[1]: https://lists.01.org/pipermail/linux-nvdimm/2018-February/014046.html
---
The vfio interface, like RDMA, wants to setup long term (indefinite)
pins of the pages backing an address range so that a guest or userspace
driver can perform DMA to the with physical address. Given that this
pinning may lead to filesystem operations deadlocking in the
filesystem-dax case, the pinning request needs to be rejected.
The longer term fix for vfio, RDMA, and any other long term pin user, is
to provide a 'pin with lease' mechanism. Similar to the leases that are
hold for pNFS RDMA layouts, this userspace lease gives the kernel a way
to notify userspace that the block layout of the file is changing and
the kernel is revoking access to pinned pages.
---
Dan Williams (5):
dax: fix vma_is_fsdax() helper
dax: fix dax_mapping() definition in the FS_DAX=n + DEV_DAX=y case
dax: fix S_DAX definition
dax: short circuit vma_is_fsdax() in the CONFIG_FS_DAX=n case
vfio: disable filesystem-dax page pinning
drivers/vfio/vfio_iommu_type1.c | 18 +++++++++++++++---
include/linux/dax.h | 9 ++++++---
include/linux/fs.h | 6 ++++--
3 files changed, 25 insertions(+), 8 deletions(-)
The backport of commit aa8a5e0062ac ("powerpc/64s: Add support for RFI
flush of L1-D cache"), incorrectly placed the new RFI flush code
inside an existing #ifdef CONFIG_HARDLOCKUP_DETECTOR block.
This has the obvious effect of requiring HARDLOCKUP_DETECTOR to be
enabled in order for RFI flush to be enabled, which is a bug.
Fix it by moving the #endif up to where it belongs.
Fixes: c3892946315e ("powerpc/64s: Add support for RFI flush of L1-D cache")
Reported-by: Bernhard Kaindl <bernhard.kaindl(a)thalesgroup.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
---
arch/powerpc/kernel/setup_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index df4a87eb8da4..9eb469bed22b 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -835,6 +835,7 @@ static int __init disable_hardlockup_detector(void)
return 0;
}
early_initcall(disable_hardlockup_detector);
+#endif
#ifdef CONFIG_PPC_BOOK3S_64
static enum l1d_flush_type enabled_flush_types;
@@ -973,4 +974,3 @@ ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr, cha
return sprintf(buf, "Vulnerable\n");
}
#endif /* CONFIG_PPC_BOOK3S_64 */
-#endif
--
2.14.1
This is a note to let you know that I've just added the patch titled
netfilter: drop outermost socket lock in getsockopt()
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:
netfilter-drop-outermost-socket-lock-in-getsockopt.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 01ea306f2ac2baff98d472da719193e738759d93 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni(a)redhat.com>
Date: Thu, 8 Feb 2018 12:19:00 +0100
Subject: netfilter: drop outermost socket lock in getsockopt()
From: Paolo Abeni <pabeni(a)redhat.com>
commit 01ea306f2ac2baff98d472da719193e738759d93 upstream.
The Syzbot reported a possible deadlock in the netfilter area caused by
rtnl lock, xt lock and socket lock being acquired with a different order
on different code paths, leading to the following backtrace:
Reviewed-by: Xin Long <lucien.xin(a)gmail.com>
======================================================
WARNING: possible circular locking dependency detected
4.15.0+ #301 Not tainted
------------------------------------------------------
syzkaller233489/4179 is trying to acquire lock:
(rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
but task is already holding lock:
(&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
which lock already depends on the new lock.
===
Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
only in the required scope"), we already acquire the socket lock in
the innermost scope, where needed. In such commit I forgot to remove
the outer-most socket lock from the getsockopt() path, this commit
addresses the issues dropping it now.
v1 -> v2: fix bad subj, added relavant 'fixes' tag
Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
Fixes: 202f59afd441 ("netfilter: ipt_CLUSTERIP: do not hold dev")
Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
Reported-by: syzbot+ddde1c7b7ff7442d7f2d(a)syzkaller.appspotmail.com
Suggested-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ip_sockglue.c | 7 +------
net/ipv6/ipv6_sockglue.c | 10 ++--------
2 files changed, 3 insertions(+), 14 deletions(-)
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1552,10 +1552,7 @@ int ip_getsockopt(struct sock *sk, int l
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
return err;
@@ -1587,9 +1584,7 @@ int compat_ip_getsockopt(struct sock *sk
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
err = compat_nf_getsockopt(sk, PF_INET, optname, optval, &len);
- release_sock(sk);
if (err >= 0)
err = put_user(len, optlen);
return err;
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1343,10 +1343,7 @@ int ipv6_getsockopt(struct sock *sk, int
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET6, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
@@ -1385,10 +1382,7 @@ int compat_ipv6_getsockopt(struct sock *
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = compat_nf_getsockopt(sk, PF_INET6,
- optname, optval, &len);
- release_sock(sk);
+ err = compat_nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
Patches currently in stable-queue which might be from pabeni(a)redhat.com are
queue-4.9/netfilter-drop-outermost-socket-lock-in-getsockopt.patch
This is a note to let you know that I've just added the patch titled
netfilter: drop outermost socket lock in getsockopt()
to the 4.4-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:
netfilter-drop-outermost-socket-lock-in-getsockopt.patch
and it can be found in the queue-4.4 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 01ea306f2ac2baff98d472da719193e738759d93 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni(a)redhat.com>
Date: Thu, 8 Feb 2018 12:19:00 +0100
Subject: netfilter: drop outermost socket lock in getsockopt()
From: Paolo Abeni <pabeni(a)redhat.com>
commit 01ea306f2ac2baff98d472da719193e738759d93 upstream.
The Syzbot reported a possible deadlock in the netfilter area caused by
rtnl lock, xt lock and socket lock being acquired with a different order
on different code paths, leading to the following backtrace:
Reviewed-by: Xin Long <lucien.xin(a)gmail.com>
======================================================
WARNING: possible circular locking dependency detected
4.15.0+ #301 Not tainted
------------------------------------------------------
syzkaller233489/4179 is trying to acquire lock:
(rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
but task is already holding lock:
(&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
which lock already depends on the new lock.
===
Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
only in the required scope"), we already acquire the socket lock in
the innermost scope, where needed. In such commit I forgot to remove
the outer-most socket lock from the getsockopt() path, this commit
addresses the issues dropping it now.
v1 -> v2: fix bad subj, added relavant 'fixes' tag
Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
Fixes: 202f59afd441 ("netfilter: ipt_CLUSTERIP: do not hold dev")
Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
Reported-by: syzbot+ddde1c7b7ff7442d7f2d(a)syzkaller.appspotmail.com
Suggested-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ip_sockglue.c | 7 +------
net/ipv6/ipv6_sockglue.c | 10 ++--------
2 files changed, 3 insertions(+), 14 deletions(-)
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1527,10 +1527,7 @@ int ip_getsockopt(struct sock *sk, int l
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
return err;
@@ -1562,9 +1559,7 @@ int compat_ip_getsockopt(struct sock *sk
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
err = compat_nf_getsockopt(sk, PF_INET, optname, optval, &len);
- release_sock(sk);
if (err >= 0)
err = put_user(len, optlen);
return err;
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1340,10 +1340,7 @@ int ipv6_getsockopt(struct sock *sk, int
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET6, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
@@ -1382,10 +1379,7 @@ int compat_ipv6_getsockopt(struct sock *
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = compat_nf_getsockopt(sk, PF_INET6,
- optname, optval, &len);
- release_sock(sk);
+ err = compat_nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
Patches currently in stable-queue which might be from pabeni(a)redhat.com are
queue-4.4/netfilter-drop-outermost-socket-lock-in-getsockopt.patch
This is a note to let you know that I've just added the patch titled
netfilter: drop outermost socket lock in getsockopt()
to the 4.15-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:
netfilter-drop-outermost-socket-lock-in-getsockopt.patch
and it can be found in the queue-4.15 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 01ea306f2ac2baff98d472da719193e738759d93 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni(a)redhat.com>
Date: Thu, 8 Feb 2018 12:19:00 +0100
Subject: netfilter: drop outermost socket lock in getsockopt()
From: Paolo Abeni <pabeni(a)redhat.com>
commit 01ea306f2ac2baff98d472da719193e738759d93 upstream.
The Syzbot reported a possible deadlock in the netfilter area caused by
rtnl lock, xt lock and socket lock being acquired with a different order
on different code paths, leading to the following backtrace:
Reviewed-by: Xin Long <lucien.xin(a)gmail.com>
======================================================
WARNING: possible circular locking dependency detected
4.15.0+ #301 Not tainted
------------------------------------------------------
syzkaller233489/4179 is trying to acquire lock:
(rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
but task is already holding lock:
(&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
which lock already depends on the new lock.
===
Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
only in the required scope"), we already acquire the socket lock in
the innermost scope, where needed. In such commit I forgot to remove
the outer-most socket lock from the getsockopt() path, this commit
addresses the issues dropping it now.
v1 -> v2: fix bad subj, added relavant 'fixes' tag
Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
Fixes: 202f59afd441 ("netfilter: ipt_CLUSTERIP: do not hold dev")
Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
Reported-by: syzbot+ddde1c7b7ff7442d7f2d(a)syzkaller.appspotmail.com
Suggested-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ip_sockglue.c | 7 +------
net/ipv6/ipv6_sockglue.c | 10 ++--------
2 files changed, 3 insertions(+), 14 deletions(-)
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1563,10 +1563,7 @@ int ip_getsockopt(struct sock *sk, int l
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
return err;
@@ -1598,9 +1595,7 @@ int compat_ip_getsockopt(struct sock *sk
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
err = compat_nf_getsockopt(sk, PF_INET, optname, optval, &len);
- release_sock(sk);
if (err >= 0)
err = put_user(len, optlen);
return err;
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1367,10 +1367,7 @@ int ipv6_getsockopt(struct sock *sk, int
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET6, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
@@ -1409,10 +1406,7 @@ int compat_ipv6_getsockopt(struct sock *
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = compat_nf_getsockopt(sk, PF_INET6,
- optname, optval, &len);
- release_sock(sk);
+ err = compat_nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
Patches currently in stable-queue which might be from pabeni(a)redhat.com are
queue-4.15/netfilter-drop-outermost-socket-lock-in-getsockopt.patch
This is a note to let you know that I've just added the patch titled
netfilter: drop outermost socket lock in getsockopt()
to the 4.14-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:
netfilter-drop-outermost-socket-lock-in-getsockopt.patch
and it can be found in the queue-4.14 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 01ea306f2ac2baff98d472da719193e738759d93 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni(a)redhat.com>
Date: Thu, 8 Feb 2018 12:19:00 +0100
Subject: netfilter: drop outermost socket lock in getsockopt()
From: Paolo Abeni <pabeni(a)redhat.com>
commit 01ea306f2ac2baff98d472da719193e738759d93 upstream.
The Syzbot reported a possible deadlock in the netfilter area caused by
rtnl lock, xt lock and socket lock being acquired with a different order
on different code paths, leading to the following backtrace:
Reviewed-by: Xin Long <lucien.xin(a)gmail.com>
======================================================
WARNING: possible circular locking dependency detected
4.15.0+ #301 Not tainted
------------------------------------------------------
syzkaller233489/4179 is trying to acquire lock:
(rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
but task is already holding lock:
(&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
which lock already depends on the new lock.
===
Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
only in the required scope"), we already acquire the socket lock in
the innermost scope, where needed. In such commit I forgot to remove
the outer-most socket lock from the getsockopt() path, this commit
addresses the issues dropping it now.
v1 -> v2: fix bad subj, added relavant 'fixes' tag
Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
Fixes: 202f59afd441 ("netfilter: ipt_CLUSTERIP: do not hold dev")
Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
Reported-by: syzbot+ddde1c7b7ff7442d7f2d(a)syzkaller.appspotmail.com
Suggested-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ip_sockglue.c | 7 +------
net/ipv6/ipv6_sockglue.c | 10 ++--------
2 files changed, 3 insertions(+), 14 deletions(-)
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1563,10 +1563,7 @@ int ip_getsockopt(struct sock *sk, int l
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
return err;
@@ -1598,9 +1595,7 @@ int compat_ip_getsockopt(struct sock *sk
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
err = compat_nf_getsockopt(sk, PF_INET, optname, optval, &len);
- release_sock(sk);
if (err >= 0)
err = put_user(len, optlen);
return err;
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1355,10 +1355,7 @@ int ipv6_getsockopt(struct sock *sk, int
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET6, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
@@ -1397,10 +1394,7 @@ int compat_ipv6_getsockopt(struct sock *
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = compat_nf_getsockopt(sk, PF_INET6,
- optname, optval, &len);
- release_sock(sk);
+ err = compat_nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
Patches currently in stable-queue which might be from pabeni(a)redhat.com are
queue-4.14/netfilter-drop-outermost-socket-lock-in-getsockopt.patch
This is a note to let you know that I've just added the patch titled
netfilter: drop outermost socket lock in getsockopt()
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:
netfilter-drop-outermost-socket-lock-in-getsockopt.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 01ea306f2ac2baff98d472da719193e738759d93 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni(a)redhat.com>
Date: Thu, 8 Feb 2018 12:19:00 +0100
Subject: netfilter: drop outermost socket lock in getsockopt()
From: Paolo Abeni <pabeni(a)redhat.com>
commit 01ea306f2ac2baff98d472da719193e738759d93 upstream.
The Syzbot reported a possible deadlock in the netfilter area caused by
rtnl lock, xt lock and socket lock being acquired with a different order
on different code paths, leading to the following backtrace:
Reviewed-by: Xin Long <lucien.xin(a)gmail.com>
======================================================
WARNING: possible circular locking dependency detected
4.15.0+ #301 Not tainted
------------------------------------------------------
syzkaller233489/4179 is trying to acquire lock:
(rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
but task is already holding lock:
(&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
which lock already depends on the new lock.
===
Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
only in the required scope"), we already acquire the socket lock in
the innermost scope, where needed. In such commit I forgot to remove
the outer-most socket lock from the getsockopt() path, this commit
addresses the issues dropping it now.
v1 -> v2: fix bad subj, added relavant 'fixes' tag
Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
Fixes: 202f59afd441 ("netfilter: ipt_CLUSTERIP: do not hold dev")
Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
Reported-by: syzbot+ddde1c7b7ff7442d7f2d(a)syzkaller.appspotmail.com
Suggested-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ip_sockglue.c | 7 +------
net/ipv6/ipv6_sockglue.c | 10 ++--------
2 files changed, 3 insertions(+), 14 deletions(-)
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1375,10 +1375,7 @@ int ip_getsockopt(struct sock *sk, int l
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
return err;
@@ -1410,9 +1407,7 @@ int compat_ip_getsockopt(struct sock *sk
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
err = compat_nf_getsockopt(sk, PF_INET, optname, optval, &len);
- release_sock(sk);
if (err >= 0)
err = put_user(len, optlen);
return err;
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1314,10 +1314,7 @@ int ipv6_getsockopt(struct sock *sk, int
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET6, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
@@ -1356,10 +1353,7 @@ int compat_ipv6_getsockopt(struct sock *
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = compat_nf_getsockopt(sk, PF_INET6,
- optname, optval, &len);
- release_sock(sk);
+ err = compat_nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
Patches currently in stable-queue which might be from pabeni(a)redhat.com are
queue-3.18/netfilter-drop-outermost-socket-lock-in-getsockopt.patch
From: Jack Wang <jinpu.wang(a)profitbricks.com>
Hi Greg,
I notice there are some stable bugfix missing on stable-4.4, so I did
backport from 4.9, most of them are simple cherry-pick, some need to
adjust context a bit, I did some regression tests/ltp/kvm-unit-tests,
looks fine, there are still some patches to port, not sure if worth the
effort.
Note: patches base on 4.4.117
Thanks,
Jack Wang
Andi Kleen (1):
module/retpoline: Warn about missing retpoline in module
Borislav Petkov (2):
x86/nospec: Fix header guards names
x86/bugs: Drop one "mitigation" from dmesg
Colin Ian King (1):
x86/spectre: Fix spelling mistake: "vunerable"-> "vulnerable"
Dan Williams (9):
array_index_nospec: Sanitize speculative array de-references
x86: Implement array_index_mask_nospec
x86: Introduce barrier_nospec
x86/get_user: Use pointer masking to limit speculation
x86/syscall: Sanitize syscall table de-references under speculation
vfs, fdtable: Prevent bounds-check bypass via speculative execution
nl80211: Sanitize array index in parse_txq_params
x86/spectre: Report get_user mitigation for spectre_v1
x86/kvm: Update spectre-v1 mitigation
Darren Kenny (1):
x86/speculation: Fix typo IBRS_ATT, which should be IBRS_ALL
David Hildenbrand (2):
KVM: nVMX: kmap() can't fail
KVM: nVMX: vmx_complete_nested_posted_interrupt() can't fail
David Woodhouse (1):
x86/retpoline: Avoid retpolines for built-in __init functions
Dou Liyang (1):
x86/spectre: Check CONFIG_RETPOLINE in command line parser
Jan Dakinevich (2):
KVM: VMX: clean up declaration of VPID/EPT invalidation types
KVM: nVMX: invvpid handling improvements
Jim Mattson (1):
kvm: nVMX: Fix kernel panics induced by illegal INVEPT/INVVPID types
Josh Poimboeuf (1):
x86/paravirt: Remove 'noreplace-paravirt' cmdline option
KarimAllah Ahmed (1):
x86/spectre: Simplify spectre_v2 command line parsing
Mark Rutland (1):
Documentation: Document array_index_nospec
Peter Zijlstra (2):
KVM: x86: Make indirect calls in emulator speculation safe
KVM: VMX: Make indirect call speculation safe
Thomas Gleixner (1):
x86/cpu/bugs: Make retpoline module warning conditional
Waiman Long (1):
x86/retpoline: Remove the esp/rsp thunk
Wanpeng Li (1):
KVM: async_pf: Fix #DF due to inject "Page not Present" and "Page
Ready" exceptions simultaneously
Documentation/kernel-parameters.txt | 2 -
Documentation/speculation.txt | 90 +++++++++++++++++++++++++
arch/x86/entry/common.c | 2 +
arch/x86/include/asm/asm-prototypes.h | 1 -
arch/x86/include/asm/barrier.h | 28 ++++++++
arch/x86/include/asm/msr.h | 3 +-
arch/x86/include/asm/nospec-branch.h | 8 +--
arch/x86/include/asm/vmx.h | 5 +-
arch/x86/kernel/alternative.c | 14 ----
arch/x86/kernel/cpu/bugs.c | 122 ++++++++++++++++++++++++----------
arch/x86/kvm/emulate.c | 9 +--
arch/x86/kvm/vmx.c | 83 +++++++++++------------
arch/x86/kvm/x86.c | 34 +++++++---
arch/x86/lib/getuser.S | 10 +++
arch/x86/lib/retpoline.S | 1 -
include/linux/fdtable.h | 5 +-
include/linux/init.h | 9 ++-
include/linux/module.h | 9 +++
include/linux/nospec.h | 72 ++++++++++++++++++++
kernel/module.c | 11 +++
net/wireless/nl80211.c | 9 ++-
scripts/mod/modpost.c | 9 +++
22 files changed, 417 insertions(+), 119 deletions(-)
create mode 100644 Documentation/speculation.txt
create mode 100644 include/linux/nospec.h
--
2.7.4
This is the start of the stable review cycle for the 4.15.6 release.
There are 45 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun Feb 25 17:06:43 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.6-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.15.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.15.6-rc1
Michal Hocko <mhocko(a)suse.com>
vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems
Tomas Winkler <tomas.winkler(a)intel.com>
mei: me: add cannon point device ids for 4th device
Alexander Usyskin <alexander.usyskin(a)intel.com>
mei: me: add cannon point device ids
Kamil Konieczny <k.konieczny(a)partner.samsung.com>
crypto: s5p-sss - Fix kernel Oops in AES-ECB mode
Shuah Khan <shuah(a)kernel.org>
usbip: keep usbip_device sockfd state in sync with tcp_socket
Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
xhci: fix xhci debugfs errors in xhci_stop
Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
xhci: xhci debugfs device nodes weren't removed after device plugged out
Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
xhci: Fix xhci debugfs devices node disappearance after hibernation
Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
xhci: Fix NULL pointer in xhci debugfs
Alexandru Ardelean <alexandru.ardelean(a)analog.com>
staging: iio: ad5933: switch buffer mode to software
Alexandru Ardelean <alexandru.ardelean(a)analog.com>
staging: iio: adc: ad7192: fix external frequency setting
Arnd Bergmann <arnd(a)arndb.de>
staging: fsl-mc: fix build testing on x86
Todd Kjos <tkjos(a)android.com>
binder: replace "%p" with "%pK"
Eric Biggers <ebiggers(a)google.com>
binder: check for binder_thread allocation failure in binder_poll()
Ben Hutchings <ben(a)decadent.org.uk>
staging: android: ashmem: Fix a race condition in pin ioctls
Martijn Coenen <maco(a)android.com>
ANDROID: binder: synchronize_rcu() when using POLLFREE.
Todd Kjos <tkjos(a)android.com>
ANDROID: binder: remove WARN() for redundant txn error
Paolo Abeni <pabeni(a)redhat.com>
dn_getsockoptdecnet: move nf_{get/set}sockopt outside sock lock
Arnd Bergmann <arnd(a)arndb.de>
arm64: dts: add #cooling-cells to CPU nodes
Arnd Bergmann <arnd(a)arndb.de>
ARM: 8743/1: bL_switcher: add MODULE_LICENSE tag
Arnd Bergmann <arnd(a)arndb.de>
video: fbdev/mmp: add MODULE_LICENSE
Arnd Bergmann <arnd(a)arndb.de>
ASoC: ux500: add MODULE_LICENSE tag
Jesse Chan <jc(a)linux.com>
soc: qcom: rmtfs_mem: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
Eric Dumazet <edumazet(a)google.com>
net_sched: gen_estimator: fix lockdep splat
Willem de Bruijn <willemb(a)google.com>
net: avoid skb_warn_bad_offload on IS_ERR
Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete
Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
rds: tcp: correctly sequence cleanup on netns deletion.
Cong Wang <xiyou.wangcong(a)gmail.com>
netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
Cong Wang <xiyou.wangcong(a)gmail.com>
netfilter: xt_cgroup: initialize info->priv in cgroup_mt_check_v1()
Paolo Abeni <pabeni(a)redhat.com>
netfilter: on sockopt() acquire sock lock only in the required scope
Dmitry Vyukov <dvyukov(a)google.com>
netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()
Eric Dumazet <edumazet(a)google.com>
netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
Dmitry Vyukov <dvyukov(a)google.com>
netfilter: x_tables: fix int overflow in xt_alloc_table_info()
Dmitry Vyukov <dvyukov(a)google.com>
kcov: detect double association with a single task
Wanpeng Li <wanpeng.li(a)hotmail.com>
KVM: x86: fix escape of guest dr6 to the host
Douglas Gilbert <dgilbert(a)interlog.com>
blk_rq_map_user_iov: fix error override
Laura Abbott <labbott(a)redhat.com>
staging: android: ion: Switch from WARN to pr_warn
Laura Abbott <labbott(a)redhat.com>
staging: android: ion: Add __GFP_NOWARN for system contig heap
Eric Biggers <ebiggers(a)google.com>
crypto: x86/twofish-3way - Fix %rbp usage
Andrey Konovalov <andreyknvl(a)google.com>
media: pvrusb2: properly check endpoint types
Paul Moore <paul(a)paul-moore.com>
selinux: skip bounded transition processing if the policy isn't loaded
Paul Moore <paul(a)paul-moore.com>
selinux: ensure the context is NUL terminated in security_context_to_sid_core()
Jason Wang <jasowang(a)redhat.com>
ptr_ring: try vmalloc() when kmalloc() fails
Jason Wang <jasowang(a)redhat.com>
ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE
Eric Dumazet <edumazet(a)google.com>
tun: fix tun_napi_alloc_frags() frag allocator
-------------
Diffstat:
Makefile | 4 +-
arch/arm/common/bL_switcher_dummy_if.c | 4 +
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 +
arch/x86/crypto/twofish-x86_64-asm_64-3way.S | 112 +++++++++++++-----------
arch/x86/kvm/x86.c | 6 ++
block/blk-map.c | 4 +-
drivers/android/binder.c | 29 ++++--
drivers/crypto/s5p-sss.c | 12 ++-
drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 12 +++
drivers/misc/mei/hw-me-regs.h | 5 ++
drivers/misc/mei/pci-me.c | 5 ++
drivers/net/tun.c | 16 ++--
drivers/soc/qcom/rmtfs_mem.c | 4 +
drivers/staging/android/ashmem.c | 19 ++--
drivers/staging/android/ion/ion-ioctl.c | 4 +-
drivers/staging/android/ion/ion_system_heap.c | 2 +-
drivers/staging/fsl-mc/bus/Kconfig | 2 +-
drivers/staging/iio/adc/ad7192.c | 27 ++++--
drivers/staging/iio/impedance-analyzer/ad5933.c | 4 +-
drivers/usb/host/xhci-debugfs.c | 4 +-
drivers/usb/host/xhci.c | 10 +--
drivers/usb/usbip/stub_dev.c | 3 +
drivers/usb/usbip/vhci_hcd.c | 2 +
drivers/video/fbdev/mmp/core.c | 5 ++
include/linux/ptr_ring.h | 15 ++--
kernel/kcov.c | 4 +-
mm/vmalloc.c | 10 ++-
net/core/dev.c | 2 +-
net/core/gen_estimator.c | 4 +
net/decnet/af_decnet.c | 62 +++++++------
net/ipv4/ip_sockglue.c | 14 +--
net/ipv4/netfilter/ipt_CLUSTERIP.c | 16 +++-
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 6 +-
net/ipv6/ipv6_sockglue.c | 17 ++--
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c | 18 ++--
net/netfilter/x_tables.c | 9 +-
net/netfilter/xt_RATEEST.c | 22 +++--
net/netfilter/xt_cgroup.c | 1 +
net/rds/connection.c | 3 +-
net/rds/rds.h | 6 +-
net/rds/tcp.c | 13 ++-
net/rds/tcp.h | 1 +
security/selinux/ss/services.c | 21 ++---
sound/soc/ux500/mop500.c | 4 +
sound/soc/ux500/ux500_pcm.c | 5 ++
45 files changed, 348 insertions(+), 202 deletions(-)
In commit c713fb071edc ("rtlwifi: rtl8821ae: Fix connection lost problem
correctly") a problem in rtl8821ae that caused loss of signal was fixed.
That same problem has now been reported for rtl8723be. Accordingly,
the ASPM L1 latency has been increased from 0 to 7 to fix the instability.
Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net>
Cc: Stable <stable(a)vger.kernel.org>
---
Kalle,
This patch should be sent to 4.16.
Thanks,
Larry
---
drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index f9ccd13c79f9..e7bbbc95cdb1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
@@ -1125,7 +1125,8 @@ static void _rtl8723be_enable_aspm_back_door(struct ieee80211_hw *hw)
/* Configuration Space offset 0x70f BIT7 is used to control L0S */
tmp8 = _rtl8723be_dbi_read(rtlpriv, 0x70f);
- _rtl8723be_dbi_write(rtlpriv, 0x70f, tmp8 | BIT(7));
+ _rtl8723be_dbi_write(rtlpriv, 0x70f, tmp8 | BIT(7) |
+ ASPM_L1_LATENCY << 3);
/* Configuration Space offset 0x719 Bit3 is for L1
* BIT4 is for clock request
--
2.16.2
On Sat, Feb 24, 2018 at 11:41:01AM +0000, Harsh Shandilya wrote:
> On Sat 24 Feb, 2018, 12:01 AM Greg Kroah-Hartman, <
> gregkh(a)linuxfoundation.org> wrote:
>
> > This is the start of the stable review cycle for the 3.18.96 release.
> > There are 58 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun Feb 25 17:01:41 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >
> > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.96-rc…
> > or in the git tree and branch at:
> > git://
> > git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > linux-3.18.y
> > and the diffstat can be found below.
> >
>
> Clean merge into the msm-3.18 CAF tree, no regressions noticed on the
> OnePlus 3T. Thanks for the update :)
Great, thanks for testing and letting me know.
greg k-h
This is the start of the stable review cycle for the 3.18.96 release.
There are 58 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun Feb 25 17:01:41 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.96-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 3.18.96-rc1
Kamil Konieczny <k.konieczny(a)partner.samsung.com>
crypto: s5p-sss - Fix kernel Oops in AES-ECB mode
Wanpeng Li <wanpeng.li(a)hotmail.com>
KVM: async_pf: Fix #DF due to inject "Page not Present" and "Page Ready" exceptions simultaneously
Jia-Ju Bai <baijiaju1990(a)163.com>
hippi: Fix a Fix a possible sleep-in-atomic bug in rr_close
Jan Beulich <JBeulich(a)suse.com>
xen: XEN_ACPI_PROCESSOR is Dom0-only
Karol Herbst <kherbst(a)redhat.com>
x86/mm/kmmio: Fix mmiotrace for page unaligned addresses
Dave Young <dyoung(a)redhat.com>
mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep
Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
dmaengine: jz4740: disable/unprepare clk if probe fails
Steffen Klassert <steffen.klassert(a)secunet.com>
xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies.
Takuo Koguchi <takuo.koguchi(a)gmail.com>
spi: sun4i: disable clocks in the remove function
Eric Biggers <ebiggers3(a)gmail.com>
509: fix printing uninitialized stack memory when OID is empty
Nikolay Borisov <nborisov(a)suse.com>
btrfs: Fix possible off-by-one in btrfs_search_path_in_tree
Nogah Frankel <nogahf(a)mellanox.com>
net_sched: red: Avoid illegal values
Nogah Frankel <nogahf(a)mellanox.com>
net_sched: red: Avoid devision by zero
Zumeng Chen <zumeng.chen(a)gmail.com>
gianfar: fix a flooded alignment reports because of padding issue.
Stefan Haberland <sth(a)linux.vnet.ibm.com>
s390/dasd: prevent prefix I/O error
Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com>
powerpc/perf: Fix oops when grouping different pmu events
Greg Ungerer <gerg(a)linux-m68k.org>
m68k: add missing SOFTIRQENTRY_TEXT linker section
Will Deacon <will.deacon(a)arm.com>
scripts/kernel-doc: Don't fail with status != 0 if error encountered with -none
Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
media: s5k6aa: describe some function parameters
Satheesh Rajendran <sathnaga(a)linux.vnet.ibm.com>
perf bench numa: Fixup discontiguous/sparse numa nodes
Jiri Olsa <jolsa(a)kernel.org>
perf top: Fix window dimensions change handling
Peter Ujfalusi <peter.ujfalusi(a)ti.com>
ARM: dts: am4372: Correct the interrupts_properties of McASP
Keerthy <j-keerthy(a)ti.com>
ARM: AM33xx: PRM: Remove am33xx_pwrdm_read_prev_pwrst function
Randy Dunlap <rdunlap(a)infradead.org>
usb: build drivers/usb/common/ when USB_SUPPORT is set
Shuah Khan <shuahkh(a)osg.samsung.com>
usbip: keep usbip_device sockfd state in sync with tcp_socket
Paolo Abeni <pabeni(a)redhat.com>
dn_getsockoptdecnet: move nf_{get/set}sockopt outside sock lock
Arnd Bergmann <arnd(a)arndb.de>
video: fbdev/mmp: add MODULE_LICENSE
Arnd Bergmann <arnd(a)arndb.de>
ASoC: ux500: add MODULE_LICENSE tag
Paul Moore <paul(a)paul-moore.com>
selinux: ensure the context is NUL terminated in security_context_to_sid_core()
David Howells <dhowells(a)redhat.com>
Provide a function to create a NUL-terminated string from unterminated data
Willem de Bruijn <willemb(a)google.com>
net: avoid skb_warn_bad_offload on IS_ERR
Cong Wang <xiyou.wangcong(a)gmail.com>
netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
Paolo Abeni <pabeni(a)redhat.com>
netfilter: on sockopt() acquire sock lock only in the required scope
Dmitry Vyukov <dvyukov(a)google.com>
netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()
Eric Dumazet <edumazet(a)google.com>
netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
Dmitry Vyukov <dvyukov(a)google.com>
netfilter: x_tables: fix int overflow in xt_alloc_table_info()
Laura Abbott <labbott(a)redhat.com>
staging: android: ion: Add __GFP_NOWARN for system contig heap
Eric Biggers <ebiggers(a)google.com>
crypto: x86/twofish-3way - Fix %rbp usage
Paul Moore <paul(a)paul-moore.com>
selinux: skip bounded transition processing if the policy isn't loaded
Cong Wang <xiyou.wangcong(a)gmail.com>
xfrm: check id proto in validate_tmpl()
Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
mm,vmscan: Make unregister_shrinker() no-op if register_shrinker() failed.
Arnd Bergmann <arnd(a)arndb.de>
media: r820t: fix r820t_write_reg for KASAN
Arnd Bergmann <arnd(a)arndb.de>
ARM: dts: s5pv210: add interrupt-parent for ohci
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Fix racy pool initializations
Liu Bo <bo.li.liu(a)oracle.com>
Btrfs: fix crash due to not cleaning up tree log block's dirty bits
Liu Bo <bo.li.liu(a)oracle.com>
Btrfs: fix deadlock in run_delalloc_nocow
Nicolas Pitre <nicolas.pitre(a)linaro.org>
console/dummy: leave .con_font_get set to NULL
Johan Hovold <johan(a)kernel.org>
video: fbdev: atmel_lcdfb: fix display-timings lookup
Ernesto A. Fernández <ernesto.mnd.fernandez(a)gmail.com>
ext4: correct documentation for grpid mount option
Zhouyi Zhou <zhouzhouyi(a)gmail.com>
ext4: save error to disk in __ext4_grp_locked_error()
Julia Lawall <Julia.Lawall(a)lip6.fr>
drm/radeon: adjust tested variable
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Fix regression by incorrect ioctl_mutex usages
Viresh Kumar <viresh.kumar(a)linaro.org>
arm: spear13xx: Fix spics gpio controller's warning
Viresh Kumar <viresh.kumar(a)linaro.org>
arm: spear13xx: Fix dmas cells
Viresh Kumar <viresh.kumar(a)linaro.org>
arm: spear600: Add missing interrupt-parent of rtc
Eugene Syromiatnikov <esyr(a)redhat.com>
s390: fix handling of -1 in set{,fs}[gu]id16 syscalls
Bjorn Andersson <bjorn.andersson(a)linaro.org>
PM / devfreq: Propagate error from devfreq_add_device()
Jack Morgenstein <jackm(a)dev.mellanox.co.il>
IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports
-------------
Diffstat:
Documentation/devicetree/bindings/dma/snps-dma.txt | 2 +-
Documentation/filesystems/ext4.txt | 2 +-
Makefile | 4 +-
arch/arm/boot/dts/am4372.dtsi | 6 +-
arch/arm/boot/dts/s5pv210.dtsi | 1 +
arch/arm/boot/dts/spear1310-evb.dts | 2 +-
arch/arm/boot/dts/spear1340.dtsi | 4 +-
arch/arm/boot/dts/spear13xx.dtsi | 6 +-
arch/arm/boot/dts/spear600.dtsi | 1 +
arch/arm/mach-omap2/prm33xx.c | 12 ---
arch/m68k/kernel/vmlinux-nommu.lds | 2 +
arch/m68k/kernel/vmlinux-std.lds | 2 +
arch/m68k/kernel/vmlinux-sun3.lds | 2 +
arch/powerpc/perf/core-book3s.c | 4 +-
arch/s390/kernel/compat_linux.c | 8 +-
arch/x86/crypto/twofish-x86_64-asm_64-3way.S | 112 +++++++++++----------
arch/x86/kvm/x86.c | 34 +++++--
arch/x86/mm/ioremap.c | 4 +-
arch/x86/mm/kmmio.c | 12 ++-
drivers/Makefile | 1 +
drivers/crypto/s5p-sss.c | 13 ++-
drivers/devfreq/devfreq.c | 2 +-
drivers/dma/dma-jz4740.c | 4 +-
drivers/gpu/drm/radeon/radeon_uvd.c | 2 +-
drivers/infiniband/hw/mlx4/main.c | 13 +--
drivers/media/i2c/s5k6aa.c | 5 +
drivers/media/tuners/r820t.c | 13 ++-
drivers/net/ethernet/freescale/gianfar.c | 6 +-
drivers/net/ethernet/mellanox/mlx4/qp.c | 3 +
drivers/net/hippi/rrunner.c | 2 +-
drivers/s390/block/dasd_eckd.c | 16 +--
drivers/spi/spi-sun4i.c | 2 +-
drivers/staging/android/ion/ion_system_heap.c | 2 +-
drivers/usb/usbip/stub_dev.c | 3 +
drivers/usb/usbip/vhci_hcd.c | 2 +
drivers/video/console/dummycon.c | 1 -
drivers/video/fbdev/atmel_lcdfb.c | 8 +-
drivers/video/fbdev/mmp/core.c | 5 +
drivers/xen/Kconfig | 2 +-
fs/btrfs/inode.c | 5 +-
fs/btrfs/ioctl.c | 2 +-
fs/btrfs/tree-log.c | 9 ++
fs/ext4/super.c | 1 +
include/linux/string.h | 1 +
include/net/red.h | 13 ++-
lib/oid_registry.c | 8 +-
mm/early_ioremap.c | 2 +-
mm/util.c | 24 +++++
mm/vmscan.c | 3 +
net/core/dev.c | 2 +-
net/decnet/af_decnet.c | 62 ++++++------
net/ipv4/ip_sockglue.c | 14 +--
net/ipv4/netfilter/ipt_CLUSTERIP.c | 16 ++-
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 6 +-
net/ipv6/ipv6_sockglue.c | 17 +---
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c | 18 ++--
net/netfilter/x_tables.c | 10 +-
net/netfilter/xt_RATEEST.c | 22 +++-
net/sched/sch_choke.c | 3 +
net/sched/sch_gred.c | 3 +
net/sched/sch_red.c | 2 +
net/sched/sch_sfq.c | 3 +
net/xfrm/xfrm_user.c | 24 +++++
scripts/kernel-doc | 2 +-
security/selinux/ss/services.c | 21 ++--
sound/core/seq/seq_clientmgr.c | 23 +++--
sound/soc/ux500/mop500.c | 4 +
sound/soc/ux500/ux500_pcm.c | 5 +
tools/perf/bench/numa.c | 56 ++++++++++-
tools/perf/builtin-top.c | 15 ++-
70 files changed, 485 insertions(+), 236 deletions(-)
This is a note to let you know that I've just added the patch titled
net: dst_cache_per_cpu_dst_set() can be static
to the 4.4-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:
net-dst_cache_per_cpu_dst_set-can-be-static.patch
and it can be found in the queue-4.4 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 b73f96fcb49ec90c2f837719893e7b25fcdf08d8 Mon Sep 17 00:00:00 2001
From: Wu Fengguang <fengguang.wu(a)intel.com>
Date: Fri, 18 Mar 2016 23:27:28 +0800
Subject: net: dst_cache_per_cpu_dst_set() can be static
From: Wu Fengguang <fengguang.wu(a)intel.com>
commit b73f96fcb49ec90c2f837719893e7b25fcdf08d8 upstream.
Signed-off-by: Fengguang Wu <fengguang.wu(a)intel.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/dst_cache.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/net/core/dst_cache.c
+++ b/net/core/dst_cache.c
@@ -28,8 +28,8 @@ struct dst_cache_pcpu {
};
};
-void dst_cache_per_cpu_dst_set(struct dst_cache_pcpu *dst_cache,
- struct dst_entry *dst, u32 cookie)
+static void dst_cache_per_cpu_dst_set(struct dst_cache_pcpu *dst_cache,
+ struct dst_entry *dst, u32 cookie)
{
dst_release(dst_cache->dst);
if (dst)
@@ -39,8 +39,8 @@ void dst_cache_per_cpu_dst_set(struct ds
dst_cache->dst = dst;
}
-struct dst_entry *dst_cache_per_cpu_get(struct dst_cache *dst_cache,
- struct dst_cache_pcpu *idst)
+static struct dst_entry *dst_cache_per_cpu_get(struct dst_cache *dst_cache,
+ struct dst_cache_pcpu *idst)
{
struct dst_entry *dst;
Patches currently in stable-queue which might be from fengguang.wu(a)intel.com are
queue-4.4/net-dst_cache_per_cpu_dst_set-can-be-static.patch
queue-4.4/video-use-bool-instead-int-pointer-for-get_opt_bool-argument.patch
queue-4.4/staging-wilc1000-fix-kbuild-test-robot-error.patch
queue-4.4/serial-8250_mid-fix-broken-dma-dependency.patch
Guests on new hypersiors might set KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT
bit when enabling async_PF, but this bit is reserved on old hypervisors,
which results in a failure upon migration.
To avoid breaking different cases, we are checking for CPUID feature bit
before enabling the feature and nothing else.
Fixes: 52a5c155cf79 ("KVM: async_pf: Let guest support delivery of async_pf from guest mode")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
---
v2:
* added documentation [Paolo]
* retained compatibility recent kernels [Paolo]
---
Documentation/virtual/kvm/cpuid.txt | 4 ++++
Documentation/virtual/kvm/msr.txt | 3 ++-
arch/x86/include/uapi/asm/kvm_para.h | 1 +
arch/x86/kernel/kvm.c | 8 ++++----
arch/x86/kvm/cpuid.c | 3 ++-
5 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
index dcab6dc11e3b..87a7506f31c2 100644
--- a/Documentation/virtual/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.txt
@@ -58,6 +58,10 @@ KVM_FEATURE_PV_TLB_FLUSH || 9 || guest checks this feature bit
|| || before enabling paravirtualized
|| || tlb flush.
------------------------------------------------------------------------------
+KVM_FEATURE_ASYNC_PF_VMEXIT || 10 || paravirtualized async PF VM exit
+ || || can be enabled by setting bit 2
+ || || when writing to msr 0x4b564d02
+------------------------------------------------------------------------------
KVM_FEATURE_CLOCKSOURCE_STABLE_BIT || 24 || host will warn if no guest-side
|| || per-cpu warps are expected in
|| || kvmclock.
diff --git a/Documentation/virtual/kvm/msr.txt b/Documentation/virtual/kvm/msr.txt
index 1ebecc115dc6..f3f0d57ced8e 100644
--- a/Documentation/virtual/kvm/msr.txt
+++ b/Documentation/virtual/kvm/msr.txt
@@ -170,7 +170,8 @@ MSR_KVM_ASYNC_PF_EN: 0x4b564d02
when asynchronous page faults are enabled on the vcpu 0 when
disabled. Bit 1 is 1 if asynchronous page faults can be injected
when vcpu is in cpl == 0. Bit 2 is 1 if asynchronous page faults
- are delivered to L1 as #PF vmexits.
+ are delivered to L1 as #PF vmexits. Bit 2 can be set only if
+ KVM_FEATURE_ASYNC_PF_VMEXIT is present in CPUID.
First 4 byte of 64 byte memory location will be written to by
the hypervisor at the time of asynchronous page fault (APF)
diff --git a/arch/x86/include/uapi/asm/kvm_para.h b/arch/x86/include/uapi/asm/kvm_para.h
index 7a2ade4aa235..6cfa9c8cb7d6 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -26,6 +26,7 @@
#define KVM_FEATURE_PV_EOI 6
#define KVM_FEATURE_PV_UNHALT 7
#define KVM_FEATURE_PV_TLB_FLUSH 9
+#define KVM_FEATURE_ASYNC_PF_VMEXIT 10
/* The last 8 bits are used to indicate how to interpret the flags field
* in pvclock structure. If no bits are set, all flags are ignored.
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 4e37d1a851a6..971babe964d2 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -341,10 +341,10 @@ static void kvm_guest_cpu_init(void)
#endif
pa |= KVM_ASYNC_PF_ENABLED;
- /* Async page fault support for L1 hypervisor is optional */
- if (wrmsr_safe(MSR_KVM_ASYNC_PF_EN,
- (pa | KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT) & 0xffffffff, pa >> 32) < 0)
- wrmsrl(MSR_KVM_ASYNC_PF_EN, pa);
+ if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF_VMEXIT))
+ pa |= KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT;
+
+ wrmsrl(MSR_KVM_ASYNC_PF_EN, pa);
__this_cpu_write(apf_reason.enabled, 1);
printk(KERN_INFO"KVM setup async PF for cpu %d\n",
smp_processor_id());
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 20e491b94f44..7fc04a176c57 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -604,7 +604,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
(1 << KVM_FEATURE_PV_EOI) |
(1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
(1 << KVM_FEATURE_PV_UNHALT) |
- (1 << KVM_FEATURE_PV_TLB_FLUSH);
+ (1 << KVM_FEATURE_PV_TLB_FLUSH) |
+ (1 << KVM_FEATURE_ASYNC_PF_VMEXIT);
if (sched_info_on())
entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
--
2.15.1
On Feb 22, 2018, Bart Van Assche <Bart.VanAssche(a)wdc.com> wrote:
> Alexandre, can you try patch "[PATCH v2] Avoid that ATA error handling can
> trigger a kernel hang or oops"
> (https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg71189.html)?
Thanks. I confirm that applying it on top of 4.15.4 seems to make the
problem go away on all affected machines. I write 'seems' just because
I can't quite prove the oops won't happen any more, but I'm pretty sure
if it were to, it would have already ;-) Thanks, again!
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
From: Arnd Bergmann <arnd(a)arndb.de>
In banked-sr.c, we use a top-level '__asm__(".arch_extension virt")'
statement to allow compilation of a multi-CPU kernel for ARMv6
and older ARMv7-A that don't normally support access to the banked
registers.
This is considered to be a programming error by the gcc developers
and will no longer work in gcc-8, where we now get a build error:
/tmp/cc4Qy7GR.s:34: Error: Banked registers are not available with this architecture. -- `mrs r3,SP_usr'
/tmp/cc4Qy7GR.s:41: Error: Banked registers are not available with this architecture. -- `mrs r3,ELR_hyp'
/tmp/cc4Qy7GR.s:55: Error: Banked registers are not available with this architecture. -- `mrs r3,SP_svc'
/tmp/cc4Qy7GR.s:62: Error: Banked registers are not available with this architecture. -- `mrs r3,LR_svc'
/tmp/cc4Qy7GR.s:69: Error: Banked registers are not available with this architecture. -- `mrs r3,SPSR_svc'
/tmp/cc4Qy7GR.s:76: Error: Banked registers are not available with this architecture. -- `mrs r3,SP_abt'
Passign the '-march-armv7ve' flag to gcc works, and is ok here, because
we know the functions won't ever be called on pre-ARMv7VE machines.
Unfortunately, older compiler versions (4.8 and earlier) do not understand
that flag, so we still need to keep the asm around.
Backporting to stable kernels (4.6+) is needed to allow those to be built
with future compilers as well.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84129
Fixes: 33280b4cd1dc ("ARM: KVM: Add banked registers save/restore")
Cc: stable(a)vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
---
arch/arm/kvm/hyp/Makefile | 5 +++++
arch/arm/kvm/hyp/banked-sr.c | 4 ++++
2 files changed, 9 insertions(+)
diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
index 5638ce0c9524..63d6b404d88e 100644
--- a/arch/arm/kvm/hyp/Makefile
+++ b/arch/arm/kvm/hyp/Makefile
@@ -7,6 +7,8 @@ ccflags-y += -fno-stack-protector -DDISABLE_BRANCH_PROFILING
KVM=../../../../virt/kvm
+CFLAGS_ARMV7VE :=$(call cc-option, -march=armv7ve)
+
obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v2-sr.o
obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v3-sr.o
obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/timer-sr.o
@@ -15,7 +17,10 @@ obj-$(CONFIG_KVM_ARM_HOST) += tlb.o
obj-$(CONFIG_KVM_ARM_HOST) += cp15-sr.o
obj-$(CONFIG_KVM_ARM_HOST) += vfp.o
obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o
+CFLAGS_banked-sr.o += $(CFLAGS_ARMV7VE)
+
obj-$(CONFIG_KVM_ARM_HOST) += entry.o
obj-$(CONFIG_KVM_ARM_HOST) += hyp-entry.o
obj-$(CONFIG_KVM_ARM_HOST) += switch.o
+CFLAGS_switch.o += $(CFLAGS_ARMV7VE)
obj-$(CONFIG_KVM_ARM_HOST) += s2-setup.o
diff --git a/arch/arm/kvm/hyp/banked-sr.c b/arch/arm/kvm/hyp/banked-sr.c
index 111bda8cdebd..be4b8b0a40ad 100644
--- a/arch/arm/kvm/hyp/banked-sr.c
+++ b/arch/arm/kvm/hyp/banked-sr.c
@@ -20,6 +20,10 @@
#include <asm/kvm_hyp.h>
+/*
+ * gcc before 4.9 doesn't understand -march=armv7ve, so we have to
+ * trick the assembler.
+ */
__asm__(".arch_extension virt");
void __hyp_text __banked_save_state(struct kvm_cpu_context *ctxt)
--
2.14.2
When introducing support for irqchip in userspace we needed a way to
mask the timer signal to prevent the guest continuously exiting due to a
screaming timer.
We did this by disabling the corresponding percpu interrupt on the
host interrupt controller, because we cannot rely on the host system
having a GIC, and therefore cannot make any assumptions about having an
active state to hide the timer signal.
Unfortunately, when introducing this feature, it became entirely
possible that a VCPU which belongs to a VM that has a userspace irqchip
can disable the vtimer irq on the host on some physical CPU, and then go
away without ever enabling the vtimer irq on that physical CPU again.
This means that using irqchips in userspace on a system that also
supports running VMs with an in-kernel GIC can prevent forward progress
from in-kernel GIC VMs.
Later on, when we started taking virtual timer interrupts in the arch
timer code, we would also leave this timer state active for userspace
irqchip VMs, because we leave it up to a VGIC-enabled guest to
deactivate the hardware IRQ using the HW bit in the LR.
Both issues are solved by only using the enable/disable trick on systems
that do not have a host GIC which supports the active state, because all
VMs on such systems must use irqchips in userspace. Systems that have a
working GIC with support for an active state use the active state to
mask the timer signal for both userspace and in-kernel irqchips.
Cc: Alexander Graf <agraf(a)suse.de>
Reviewed-by: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: <stable(a)vger.kernel.org> # v4.12+
Fixes: d9e139778376 ("KVM: arm/arm64: Support arch timers with a userspace gic")
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
---
virt/kvm/arm/arch_timer.c | 116 +++++++++++++++++++++++++---------------------
1 file changed, 64 insertions(+), 52 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 70268c0bec79..70f4c30918eb 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -36,6 +36,8 @@ static struct timecounter *timecounter;
static unsigned int host_vtimer_irq;
static u32 host_vtimer_irq_flags;
+static DEFINE_STATIC_KEY_FALSE(has_gic_active_state);
+
static const struct kvm_irq_level default_ptimer_irq = {
.irq = 30,
.level = 1,
@@ -56,6 +58,12 @@ u64 kvm_phys_timer_read(void)
return timecounter->cc->read(timecounter->cc);
}
+static inline bool userspace_irqchip(struct kvm *kvm)
+{
+ return static_branch_unlikely(&userspace_irqchip_in_use) &&
+ unlikely(!irqchip_in_kernel(kvm));
+}
+
static void soft_timer_start(struct hrtimer *hrt, u64 ns)
{
hrtimer_start(hrt, ktime_add_ns(ktime_get(), ns),
@@ -69,25 +77,6 @@ static void soft_timer_cancel(struct hrtimer *hrt, struct work_struct *work)
cancel_work_sync(work);
}
-static void kvm_vtimer_update_mask_user(struct kvm_vcpu *vcpu)
-{
- struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
-
- /*
- * When using a userspace irqchip with the architected timers, we must
- * prevent continuously exiting from the guest, and therefore mask the
- * physical interrupt by disabling it on the host interrupt controller
- * when the virtual level is high, such that the guest can make
- * forward progress. Once we detect the output level being
- * de-asserted, we unmask the interrupt again so that we exit from the
- * guest when the timer fires.
- */
- if (vtimer->irq.level)
- disable_percpu_irq(host_vtimer_irq);
- else
- enable_percpu_irq(host_vtimer_irq, 0);
-}
-
static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
{
struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id;
@@ -106,9 +95,9 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
if (kvm_timer_should_fire(vtimer))
kvm_timer_update_irq(vcpu, true, vtimer);
- if (static_branch_unlikely(&userspace_irqchip_in_use) &&
- unlikely(!irqchip_in_kernel(vcpu->kvm)))
- kvm_vtimer_update_mask_user(vcpu);
+ if (userspace_irqchip(vcpu->kvm) &&
+ !static_branch_unlikely(&has_gic_active_state))
+ disable_percpu_irq(host_vtimer_irq);
return IRQ_HANDLED;
}
@@ -290,8 +279,7 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
trace_kvm_timer_update_irq(vcpu->vcpu_id, timer_ctx->irq.irq,
timer_ctx->irq.level);
- if (!static_branch_unlikely(&userspace_irqchip_in_use) ||
- likely(irqchip_in_kernel(vcpu->kvm))) {
+ if (!userspace_irqchip(vcpu->kvm)) {
ret = kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
timer_ctx->irq.irq,
timer_ctx->irq.level,
@@ -350,12 +338,6 @@ static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
phys_timer_emulate(vcpu);
}
-static void __timer_snapshot_state(struct arch_timer_context *timer)
-{
- timer->cnt_ctl = read_sysreg_el0(cntv_ctl);
- timer->cnt_cval = read_sysreg_el0(cntv_cval);
-}
-
static void vtimer_save_state(struct kvm_vcpu *vcpu)
{
struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
@@ -367,8 +349,10 @@ static void vtimer_save_state(struct kvm_vcpu *vcpu)
if (!vtimer->loaded)
goto out;
- if (timer->enabled)
- __timer_snapshot_state(vtimer);
+ if (timer->enabled) {
+ vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
+ vtimer->cnt_cval = read_sysreg_el0(cntv_cval);
+ }
/* Disable the virtual timer */
write_sysreg_el0(0, cntv_ctl);
@@ -460,23 +444,43 @@ static void set_cntvoff(u64 cntvoff)
kvm_call_hyp(__kvm_timer_set_cntvoff, low, high);
}
-static void kvm_timer_vcpu_load_vgic(struct kvm_vcpu *vcpu)
+static inline void set_vtimer_irq_phys_active(struct kvm_vcpu *vcpu, bool active)
+{
+ int r;
+ r = irq_set_irqchip_state(host_vtimer_irq, IRQCHIP_STATE_ACTIVE, active);
+ WARN_ON(r);
+}
+
+static void kvm_timer_vcpu_load_gic(struct kvm_vcpu *vcpu)
{
struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
bool phys_active;
- int ret;
- phys_active = kvm_vgic_map_is_active(vcpu, vtimer->irq.irq);
-
- ret = irq_set_irqchip_state(host_vtimer_irq,
- IRQCHIP_STATE_ACTIVE,
- phys_active);
- WARN_ON(ret);
+ if (irqchip_in_kernel(vcpu->kvm))
+ phys_active = kvm_vgic_map_is_active(vcpu, vtimer->irq.irq);
+ else
+ phys_active = vtimer->irq.level;
+ set_vtimer_irq_phys_active(vcpu, phys_active);
}
-static void kvm_timer_vcpu_load_user(struct kvm_vcpu *vcpu)
+static void kvm_timer_vcpu_load_nogic(struct kvm_vcpu *vcpu)
{
- kvm_vtimer_update_mask_user(vcpu);
+ struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
+
+ /*
+ * When using a userspace irqchip with the architected timers and a
+ * host interrupt controller that doesn't support an active state, we
+ * must still prevent continuously exiting from the guest, and
+ * therefore mask the physical interrupt by disabling it on the host
+ * interrupt controller when the virtual level is high, such that the
+ * guest can make forward progress. Once we detect the output level
+ * being de-asserted, we unmask the interrupt again so that we exit
+ * from the guest when the timer fires.
+ */
+ if (vtimer->irq.level)
+ disable_percpu_irq(host_vtimer_irq);
+ else
+ enable_percpu_irq(host_vtimer_irq, host_vtimer_irq_flags);
}
void kvm_timer_vcpu_load(struct kvm_vcpu *vcpu)
@@ -487,10 +491,10 @@ void kvm_timer_vcpu_load(struct kvm_vcpu *vcpu)
if (unlikely(!timer->enabled))
return;
- if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
- kvm_timer_vcpu_load_user(vcpu);
+ if (static_branch_likely(&has_gic_active_state))
+ kvm_timer_vcpu_load_gic(vcpu);
else
- kvm_timer_vcpu_load_vgic(vcpu);
+ kvm_timer_vcpu_load_nogic(vcpu);
set_cntvoff(vtimer->cntvoff);
@@ -555,18 +559,24 @@ static void unmask_vtimer_irq_user(struct kvm_vcpu *vcpu)
{
struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
- if (unlikely(!irqchip_in_kernel(vcpu->kvm))) {
- __timer_snapshot_state(vtimer);
- if (!kvm_timer_should_fire(vtimer)) {
- kvm_timer_update_irq(vcpu, false, vtimer);
- kvm_vtimer_update_mask_user(vcpu);
- }
+ if (!kvm_timer_should_fire(vtimer)) {
+ kvm_timer_update_irq(vcpu, false, vtimer);
+ if (static_branch_likely(&has_gic_active_state))
+ set_vtimer_irq_phys_active(vcpu, false);
+ else
+ enable_percpu_irq(host_vtimer_irq, host_vtimer_irq_flags);
}
}
void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
{
- unmask_vtimer_irq_user(vcpu);
+ struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
+
+ if (unlikely(!timer->enabled))
+ return;
+
+ if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
+ unmask_vtimer_irq_user(vcpu);
}
int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu)
@@ -753,6 +763,8 @@ int kvm_timer_hyp_init(bool has_gic)
kvm_err("kvm_arch_timer: error setting vcpu affinity\n");
goto out_free_irq;
}
+
+ static_branch_enable(&has_gic_active_state);
}
kvm_info("virtual timer IRQ%d\n", host_vtimer_irq);
--
2.14.2
Three tiny patches fixing bugs and optimizing the IBRS code. These
are all fairly obvious, but they escaped review. They should go in
through the x86/pti tree and should apply to both 4.9 and 4.14 trees.
Thanks!
Paolo
Paolo Bonzini (3):
KVM: x86: use native MSR ops for SPEC_CTRL
KVM: nVMX: fix wrong condition for SPEC_CTRL and PRED_CMD MSRs
KVM: VMX: mark RDMSR path as unlikely
arch/x86/kvm/svm.c | 9 +++++----
arch/x86/kvm/vmx.c | 15 ++++++++-------
2 files changed, 13 insertions(+), 11 deletions(-)
--
1.8.3.1
On some boards setting power_save to a non 0 value leads to clicking /
popping sounds when ever we enter/leave powersaving mode. Ideally we would
figure out how to avoid these sounds, but that is not always feasible.
This commit adds a blacklist for devices where powersaving is known to
cause problems and disables it on these devices.
Note I tried to put this blacklist in userspace first:
https://github.com/systemd/systemd/pull/8128
But the systemd maintainers rightfully pointed out that it would be
impossible to then later remove entries once we actually find a way to
make power-saving work on listed boards without issues. Having this list
in the kernel will allow removal of the blacklist entry in the same commit
which fixes the clicks / plops.
The blacklist only applies to the default power_save module-option value,
if a user explicitly sets the module-option then the blacklist is not
used.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1525104
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198611
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
Changes in RFC v2:
-Only use the blacklist if the power_save module-option is not explicitly
set by the user
Changes in RFC v2:
-Fix logic to work on boards with more then 1 HDA device
---
sound/pci/hda/hda_intel.c | 33 +++++++++++++++++++++++++++++++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index c71dcacea807..9d67b6b0ec95 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -181,7 +181,7 @@ static const struct kernel_param_ops param_ops_xint = {
};
#define param_check_xint param_check_int
-static int power_save = CONFIG_SND_HDA_POWER_SAVE_DEFAULT;
+static int power_save = -1;
module_param(power_save, xint, 0644);
MODULE_PARM_DESC(power_save, "Automatic power-saving timeout "
"(in second, 0 = disable).");
@@ -2186,6 +2186,22 @@ static int azx_probe(struct pci_dev *pci,
return err;
}
+/* On some boards setting power_save to a non 0 value leads to clicking /
+ * popping sounds when ever we enter/leave powersaving mode. Ideally we would
+ * figure out how to avoid these sounds, but that is not always feasible.
+ * So we keep a list of devices where we disable powersaving as its known
+ * to causes problems on these devices.
+ */
+static struct snd_pci_quirk power_save_blacklist[] = {
+ /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */
+ SND_PCI_QUIRK(0x1849, 0x0c0c, "Asrock B85M-ITX", 0),
+ /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */
+ SND_PCI_QUIRK(0x1043, 0x8733, "Asus Prime X370-Pro", 0),
+ /* https://bugzilla.kernel.org/show_bug.cgi?id=198611 */
+ SND_PCI_QUIRK(0x17aa, 0x2227, "Lenovo X1 Carbon 3rd Gen", 0),
+ {}
+};
+
/* number of codec slots for each chipset: 0 = default slots (i.e. 4) */
static unsigned int azx_max_codecs[AZX_NUM_DRIVERS] = {
[AZX_DRIVER_NVIDIA] = 8,
@@ -2197,7 +2213,9 @@ static int azx_probe_continue(struct azx *chip)
struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
struct hdac_bus *bus = azx_bus(chip);
struct pci_dev *pci = chip->pci;
+ const struct snd_pci_quirk *q;
int dev = chip->dev_index;
+ int val;
int err;
hda->probe_continued = 1;
@@ -2278,7 +2296,18 @@ static int azx_probe_continue(struct azx *chip)
chip->running = 1;
azx_add_card_list(chip);
- snd_hda_set_power_save(&chip->bus, power_save * 1000);
+
+ val = power_save;
+ if (val == -1) {
+ val = CONFIG_SND_HDA_POWER_SAVE_DEFAULT;
+ q = snd_pci_quirk_lookup(chip->pci, power_save_blacklist);
+ if (q && val) {
+ dev_info(chip->card->dev, "device %04x:%04x is on the power_save blacklist, forcing power_save to 0\n",
+ q->subvendor, q->subdevice);
+ val = 0;
+ }
+ }
+ snd_hda_set_power_save(&chip->bus, val * 1000);
if (azx_has_pm_runtime(chip) || hda->use_vga_switcheroo)
pm_runtime_put_autosuspend(&pci->dev);
--
2.14.3
This is a note to let you know that I've just added the patch titled
crypto: s5p-sss - Fix kernel Oops in AES-ECB mode
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:
crypto-s5p-sss-fix-kernel-oops-in-aes-ecb-mode.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 c927b080c67e3e97193c81fc1d27f4251bf4e036 Mon Sep 17 00:00:00 2001
From: Kamil Konieczny <k.konieczny(a)partner.samsung.com>
Date: Wed, 7 Feb 2018 16:52:09 +0100
Subject: crypto: s5p-sss - Fix kernel Oops in AES-ECB mode
From: Kamil Konieczny <k.konieczny(a)partner.samsung.com>
commit c927b080c67e3e97193c81fc1d27f4251bf4e036 upstream.
In AES-ECB mode crypt is done with key only, so any use of IV
can cause kernel Oops. Use IV only in AES-CBC and AES-CTR.
Signed-off-by: Kamil Konieczny <k.konieczny(a)partner.samsung.com>
Reported-by: Anand Moon <linux.amoon(a)gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Tested-by: Anand Moon <linux.amoon(a)gmail.com>
Cc: stable(a)vger.kernel.org # can be applied after commit 8f9702aad138
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/s5p-sss.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -542,15 +542,21 @@ static void s5p_aes_crypt_start(struct s
uint32_t aes_control;
unsigned long flags;
int err;
+ u8 *iv;
aes_control = SSS_AES_KEY_CHANGE_MODE;
if (mode & FLAGS_AES_DECRYPT)
aes_control |= SSS_AES_MODE_DECRYPT;
- if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CBC)
+ if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CBC) {
aes_control |= SSS_AES_CHAIN_MODE_CBC;
- else if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CTR)
+ iv = req->info;
+ } else if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CTR) {
aes_control |= SSS_AES_CHAIN_MODE_CTR;
+ iv = req->info;
+ } else {
+ iv = NULL; /* AES_ECB */
+ }
if (dev->ctx->keylen == AES_KEYSIZE_192)
aes_control |= SSS_AES_KEY_SIZE_192;
@@ -581,7 +587,7 @@ static void s5p_aes_crypt_start(struct s
goto outdata_error;
SSS_AES_WRITE(dev, AES_CONTROL, aes_control);
- s5p_set_aes(dev, dev->ctx->aes_key, req->info, dev->ctx->keylen);
+ s5p_set_aes(dev, dev->ctx->aes_key, iv, dev->ctx->keylen);
s5p_set_dma_indata(dev, dev->sg_src);
s5p_set_dma_outdata(dev, dev->sg_dst);
Patches currently in stable-queue which might be from k.konieczny(a)partner.samsung.com are
queue-4.9/crypto-s5p-sss-fix-kernel-oops-in-aes-ecb-mode.patch
This is a note to let you know that I've just added the patch titled
crypto: s5p-sss - Fix kernel Oops in AES-ECB mode
to the 4.4-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:
crypto-s5p-sss-fix-kernel-oops-in-aes-ecb-mode.patch
and it can be found in the queue-4.4 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 c927b080c67e3e97193c81fc1d27f4251bf4e036 Mon Sep 17 00:00:00 2001
From: Kamil Konieczny <k.konieczny(a)partner.samsung.com>
Date: Wed, 7 Feb 2018 16:52:09 +0100
Subject: crypto: s5p-sss - Fix kernel Oops in AES-ECB mode
From: Kamil Konieczny <k.konieczny(a)partner.samsung.com>
commit c927b080c67e3e97193c81fc1d27f4251bf4e036 upstream.
In AES-ECB mode crypt is done with key only, so any use of IV
can cause kernel Oops. Use IV only in AES-CBC and AES-CTR.
Signed-off-by: Kamil Konieczny <k.konieczny(a)partner.samsung.com>
Reported-by: Anand Moon <linux.amoon(a)gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Tested-by: Anand Moon <linux.amoon(a)gmail.com>
Cc: stable(a)vger.kernel.org # can be applied after commit 8f9702aad138
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/s5p-sss.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -401,16 +401,21 @@ static void s5p_aes_crypt_start(struct s
uint32_t aes_control;
int err;
unsigned long flags;
+ u8 *iv;
aes_control = SSS_AES_KEY_CHANGE_MODE;
if (mode & FLAGS_AES_DECRYPT)
aes_control |= SSS_AES_MODE_DECRYPT;
- if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CBC)
+ if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CBC) {
aes_control |= SSS_AES_CHAIN_MODE_CBC;
- else if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CTR)
+ iv = req->info;
+ } else if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CTR) {
aes_control |= SSS_AES_CHAIN_MODE_CTR;
-
+ iv = req->info;
+ } else {
+ iv = NULL; /* AES_ECB */
+ }
if (dev->ctx->keylen == AES_KEYSIZE_192)
aes_control |= SSS_AES_KEY_SIZE_192;
else if (dev->ctx->keylen == AES_KEYSIZE_256)
@@ -440,7 +445,7 @@ static void s5p_aes_crypt_start(struct s
goto outdata_error;
SSS_AES_WRITE(dev, AES_CONTROL, aes_control);
- s5p_set_aes(dev, dev->ctx->aes_key, req->info, dev->ctx->keylen);
+ s5p_set_aes(dev, dev->ctx->aes_key, iv, dev->ctx->keylen);
s5p_set_dma_indata(dev, req->src);
s5p_set_dma_outdata(dev, req->dst);
Patches currently in stable-queue which might be from k.konieczny(a)partner.samsung.com are
queue-4.4/crypto-s5p-sss-fix-kernel-oops-in-aes-ecb-mode.patch
This is a note to let you know that I've just added the patch titled
vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems
to the 4.15-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:
vmalloc-fix-__gfp_highmem-usage-for-vmalloc_32-on-32b-systems.patch
and it can be found in the queue-4.15 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 698d0831ba87b92ae10b15e8203cfd59f5a59a35 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko(a)suse.com>
Date: Wed, 21 Feb 2018 14:46:01 -0800
Subject: vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Michal Hocko <mhocko(a)suse.com>
commit 698d0831ba87b92ae10b15e8203cfd59f5a59a35 upstream.
Kai Heng Feng has noticed that BUG_ON(PageHighMem(pg)) triggers in
drivers/media/common/saa7146/saa7146_core.c since 19809c2da28a ("mm,
vmalloc: use __GFP_HIGHMEM implicitly").
saa7146_vmalloc_build_pgtable uses vmalloc_32 and it is reasonable to
expect that the resulting page is not in highmem. The above commit
aimed to add __GFP_HIGHMEM only for those requests which do not specify
any zone modifier gfp flag. vmalloc_32 relies on GFP_VMALLOC32 which
should do the right thing. Except it has been missed that GFP_VMALLOC32
is an alias for GFP_KERNEL on 32b architectures. Thanks to Matthew to
notice this.
Fix the problem by unconditionally setting GFP_DMA32 in GFP_VMALLOC32
for !64b arches (as a bailout). This should do the right thing and use
ZONE_NORMAL which should be always below 4G on 32b systems.
Debugged by Matthew Wilcox.
[akpm(a)linux-foundation.org: coding-style fixes]
Link: http://lkml.kernel.org/r/20180212095019.GX21609@dhcp22.suse.cz
Fixes: 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly”)
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Reported-by: Kai Heng Feng <kai.heng.feng(a)canonical.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Laura Abbott <labbott(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/vmalloc.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1943,11 +1943,15 @@ void *vmalloc_exec(unsigned long size)
}
#if defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA32)
-#define GFP_VMALLOC32 GFP_DMA32 | GFP_KERNEL
+#define GFP_VMALLOC32 (GFP_DMA32 | GFP_KERNEL)
#elif defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA)
-#define GFP_VMALLOC32 GFP_DMA | GFP_KERNEL
+#define GFP_VMALLOC32 (GFP_DMA | GFP_KERNEL)
#else
-#define GFP_VMALLOC32 GFP_KERNEL
+/*
+ * 64b systems should always have either DMA or DMA32 zones. For others
+ * GFP_DMA32 should do the right thing and use the normal zone.
+ */
+#define GFP_VMALLOC32 GFP_DMA32 | GFP_KERNEL
#endif
/**
Patches currently in stable-queue which might be from mhocko(a)suse.com are
queue-4.15/vmalloc-fix-__gfp_highmem-usage-for-vmalloc_32-on-32b-systems.patch
This is a note to let you know that I've just added the patch titled
mei: me: add cannon point device ids
to the 4.15-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:
mei-me-add-cannon-point-device-ids.patch
and it can be found in the queue-4.15 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 f8f4aa68a8ae98ed79c8fee3488c38a2f5d2de8c Mon Sep 17 00:00:00 2001
From: Alexander Usyskin <alexander.usyskin(a)intel.com>
Date: Sun, 18 Feb 2018 11:05:15 +0200
Subject: mei: me: add cannon point device ids
From: Alexander Usyskin <alexander.usyskin(a)intel.com>
commit f8f4aa68a8ae98ed79c8fee3488c38a2f5d2de8c upstream.
Add CNP LP and CNP H device ids for cannon lake
and coffee lake platforms.
Cc: <stable(a)vger.kernel.org> 4.14+
Signed-off-by: Alexander Usyskin <alexander.usyskin(a)intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/mei/hw-me-regs.h | 3 +++
drivers/misc/mei/pci-me.c | 3 +++
2 files changed, 6 insertions(+)
--- a/drivers/misc/mei/hw-me-regs.h
+++ b/drivers/misc/mei/hw-me-regs.h
@@ -132,6 +132,9 @@
#define MEI_DEV_ID_KBP 0xA2BA /* Kaby Point */
#define MEI_DEV_ID_KBP_2 0xA2BB /* Kaby Point 2 */
+#define MEI_DEV_ID_CNP_LP 0x9DE0 /* Cannon Point LP */
+#define MEI_DEV_ID_CNP_H 0xA360 /* Cannon Point H */
+
/*
* MEI HW Section
*/
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -98,6 +98,9 @@ static const struct pci_device_id mei_me
{MEI_PCI_DEVICE(MEI_DEV_ID_KBP, MEI_ME_PCH8_CFG)},
{MEI_PCI_DEVICE(MEI_DEV_ID_KBP_2, MEI_ME_PCH8_CFG)},
+ {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_LP, MEI_ME_PCH8_CFG)},
+ {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H, MEI_ME_PCH8_CFG)},
+
/* required last entry */
{0, }
};
Patches currently in stable-queue which might be from alexander.usyskin(a)intel.com are
queue-4.15/mei-me-add-cannon-point-device-ids.patch
This is a note to let you know that I've just added the patch titled
mei: me: add cannon point device ids for 4th device
to the 4.15-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:
mei-me-add-cannon-point-device-ids-for-4th-device.patch
and it can be found in the queue-4.15 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 2a4ac172c2f257d28c47b90c9e381bec31edcc44 Mon Sep 17 00:00:00 2001
From: Tomas Winkler <tomas.winkler(a)intel.com>
Date: Sun, 18 Feb 2018 11:05:16 +0200
Subject: mei: me: add cannon point device ids for 4th device
From: Tomas Winkler <tomas.winkler(a)intel.com>
commit 2a4ac172c2f257d28c47b90c9e381bec31edcc44 upstream.
Add cannon point device ids for 4th (itouch) device.
Cc: <stable(a)vger.kernel.org> 4.14+
Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/mei/hw-me-regs.h | 2 ++
drivers/misc/mei/pci-me.c | 2 ++
2 files changed, 4 insertions(+)
--- a/drivers/misc/mei/hw-me-regs.h
+++ b/drivers/misc/mei/hw-me-regs.h
@@ -133,7 +133,9 @@
#define MEI_DEV_ID_KBP_2 0xA2BB /* Kaby Point 2 */
#define MEI_DEV_ID_CNP_LP 0x9DE0 /* Cannon Point LP */
+#define MEI_DEV_ID_CNP_LP_4 0x9DE4 /* Cannon Point LP 4 (iTouch) */
#define MEI_DEV_ID_CNP_H 0xA360 /* Cannon Point H */
+#define MEI_DEV_ID_CNP_H_4 0xA364 /* Cannon Point H 4 (iTouch) */
/*
* MEI HW Section
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -99,7 +99,9 @@ static const struct pci_device_id mei_me
{MEI_PCI_DEVICE(MEI_DEV_ID_KBP_2, MEI_ME_PCH8_CFG)},
{MEI_PCI_DEVICE(MEI_DEV_ID_CNP_LP, MEI_ME_PCH8_CFG)},
+ {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_LP_4, MEI_ME_PCH8_CFG)},
{MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H, MEI_ME_PCH8_CFG)},
+ {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H_4, MEI_ME_PCH8_CFG)},
/* required last entry */
{0, }
Patches currently in stable-queue which might be from tomas.winkler(a)intel.com are
queue-4.15/mei-me-add-cannon-point-device-ids.patch
queue-4.15/mei-me-add-cannon-point-device-ids-for-4th-device.patch
This is a note to let you know that I've just added the patch titled
crypto: s5p-sss - Fix kernel Oops in AES-ECB mode
to the 4.15-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:
crypto-s5p-sss-fix-kernel-oops-in-aes-ecb-mode.patch
and it can be found in the queue-4.15 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 c927b080c67e3e97193c81fc1d27f4251bf4e036 Mon Sep 17 00:00:00 2001
From: Kamil Konieczny <k.konieczny(a)partner.samsung.com>
Date: Wed, 7 Feb 2018 16:52:09 +0100
Subject: crypto: s5p-sss - Fix kernel Oops in AES-ECB mode
From: Kamil Konieczny <k.konieczny(a)partner.samsung.com>
commit c927b080c67e3e97193c81fc1d27f4251bf4e036 upstream.
In AES-ECB mode crypt is done with key only, so any use of IV
can cause kernel Oops. Use IV only in AES-CBC and AES-CTR.
Signed-off-by: Kamil Konieczny <k.konieczny(a)partner.samsung.com>
Reported-by: Anand Moon <linux.amoon(a)gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Tested-by: Anand Moon <linux.amoon(a)gmail.com>
Cc: stable(a)vger.kernel.org # can be applied after commit 8f9702aad138
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/s5p-sss.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -1926,15 +1926,21 @@ static void s5p_aes_crypt_start(struct s
uint32_t aes_control;
unsigned long flags;
int err;
+ u8 *iv;
aes_control = SSS_AES_KEY_CHANGE_MODE;
if (mode & FLAGS_AES_DECRYPT)
aes_control |= SSS_AES_MODE_DECRYPT;
- if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CBC)
+ if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CBC) {
aes_control |= SSS_AES_CHAIN_MODE_CBC;
- else if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CTR)
+ iv = req->info;
+ } else if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CTR) {
aes_control |= SSS_AES_CHAIN_MODE_CTR;
+ iv = req->info;
+ } else {
+ iv = NULL; /* AES_ECB */
+ }
if (dev->ctx->keylen == AES_KEYSIZE_192)
aes_control |= SSS_AES_KEY_SIZE_192;
@@ -1965,7 +1971,7 @@ static void s5p_aes_crypt_start(struct s
goto outdata_error;
SSS_AES_WRITE(dev, AES_CONTROL, aes_control);
- s5p_set_aes(dev, dev->ctx->aes_key, req->info, dev->ctx->keylen);
+ s5p_set_aes(dev, dev->ctx->aes_key, iv, dev->ctx->keylen);
s5p_set_dma_indata(dev, dev->sg_src);
s5p_set_dma_outdata(dev, dev->sg_dst);
Patches currently in stable-queue which might be from k.konieczny(a)partner.samsung.com are
queue-4.15/crypto-s5p-sss-fix-kernel-oops-in-aes-ecb-mode.patch
This is a note to let you know that I've just added the patch titled
vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems
to the 4.14-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:
vmalloc-fix-__gfp_highmem-usage-for-vmalloc_32-on-32b-systems.patch
and it can be found in the queue-4.14 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 698d0831ba87b92ae10b15e8203cfd59f5a59a35 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko(a)suse.com>
Date: Wed, 21 Feb 2018 14:46:01 -0800
Subject: vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Michal Hocko <mhocko(a)suse.com>
commit 698d0831ba87b92ae10b15e8203cfd59f5a59a35 upstream.
Kai Heng Feng has noticed that BUG_ON(PageHighMem(pg)) triggers in
drivers/media/common/saa7146/saa7146_core.c since 19809c2da28a ("mm,
vmalloc: use __GFP_HIGHMEM implicitly").
saa7146_vmalloc_build_pgtable uses vmalloc_32 and it is reasonable to
expect that the resulting page is not in highmem. The above commit
aimed to add __GFP_HIGHMEM only for those requests which do not specify
any zone modifier gfp flag. vmalloc_32 relies on GFP_VMALLOC32 which
should do the right thing. Except it has been missed that GFP_VMALLOC32
is an alias for GFP_KERNEL on 32b architectures. Thanks to Matthew to
notice this.
Fix the problem by unconditionally setting GFP_DMA32 in GFP_VMALLOC32
for !64b arches (as a bailout). This should do the right thing and use
ZONE_NORMAL which should be always below 4G on 32b systems.
Debugged by Matthew Wilcox.
[akpm(a)linux-foundation.org: coding-style fixes]
Link: http://lkml.kernel.org/r/20180212095019.GX21609@dhcp22.suse.cz
Fixes: 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly”)
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Reported-by: Kai Heng Feng <kai.heng.feng(a)canonical.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Laura Abbott <labbott(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/vmalloc.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1943,11 +1943,15 @@ void *vmalloc_exec(unsigned long size)
}
#if defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA32)
-#define GFP_VMALLOC32 GFP_DMA32 | GFP_KERNEL
+#define GFP_VMALLOC32 (GFP_DMA32 | GFP_KERNEL)
#elif defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA)
-#define GFP_VMALLOC32 GFP_DMA | GFP_KERNEL
+#define GFP_VMALLOC32 (GFP_DMA | GFP_KERNEL)
#else
-#define GFP_VMALLOC32 GFP_KERNEL
+/*
+ * 64b systems should always have either DMA or DMA32 zones. For others
+ * GFP_DMA32 should do the right thing and use the normal zone.
+ */
+#define GFP_VMALLOC32 GFP_DMA32 | GFP_KERNEL
#endif
/**
Patches currently in stable-queue which might be from mhocko(a)suse.com are
queue-4.14/vmalloc-fix-__gfp_highmem-usage-for-vmalloc_32-on-32b-systems.patch
This is a note to let you know that I've just added the patch titled
mei: me: add cannon point device ids
to the 4.14-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:
mei-me-add-cannon-point-device-ids.patch
and it can be found in the queue-4.14 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 f8f4aa68a8ae98ed79c8fee3488c38a2f5d2de8c Mon Sep 17 00:00:00 2001
From: Alexander Usyskin <alexander.usyskin(a)intel.com>
Date: Sun, 18 Feb 2018 11:05:15 +0200
Subject: mei: me: add cannon point device ids
From: Alexander Usyskin <alexander.usyskin(a)intel.com>
commit f8f4aa68a8ae98ed79c8fee3488c38a2f5d2de8c upstream.
Add CNP LP and CNP H device ids for cannon lake
and coffee lake platforms.
Cc: <stable(a)vger.kernel.org> 4.14+
Signed-off-by: Alexander Usyskin <alexander.usyskin(a)intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/mei/hw-me-regs.h | 3 +++
drivers/misc/mei/pci-me.c | 3 +++
2 files changed, 6 insertions(+)
--- a/drivers/misc/mei/hw-me-regs.h
+++ b/drivers/misc/mei/hw-me-regs.h
@@ -132,6 +132,9 @@
#define MEI_DEV_ID_KBP 0xA2BA /* Kaby Point */
#define MEI_DEV_ID_KBP_2 0xA2BB /* Kaby Point 2 */
+#define MEI_DEV_ID_CNP_LP 0x9DE0 /* Cannon Point LP */
+#define MEI_DEV_ID_CNP_H 0xA360 /* Cannon Point H */
+
/*
* MEI HW Section
*/
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -98,6 +98,9 @@ static const struct pci_device_id mei_me
{MEI_PCI_DEVICE(MEI_DEV_ID_KBP, MEI_ME_PCH8_CFG)},
{MEI_PCI_DEVICE(MEI_DEV_ID_KBP_2, MEI_ME_PCH8_CFG)},
+ {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_LP, MEI_ME_PCH8_CFG)},
+ {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H, MEI_ME_PCH8_CFG)},
+
/* required last entry */
{0, }
};
Patches currently in stable-queue which might be from alexander.usyskin(a)intel.com are
queue-4.14/mei-me-add-cannon-point-device-ids.patch
This is a note to let you know that I've just added the patch titled
mei: me: add cannon point device ids for 4th device
to the 4.14-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:
mei-me-add-cannon-point-device-ids-for-4th-device.patch
and it can be found in the queue-4.14 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 2a4ac172c2f257d28c47b90c9e381bec31edcc44 Mon Sep 17 00:00:00 2001
From: Tomas Winkler <tomas.winkler(a)intel.com>
Date: Sun, 18 Feb 2018 11:05:16 +0200
Subject: mei: me: add cannon point device ids for 4th device
From: Tomas Winkler <tomas.winkler(a)intel.com>
commit 2a4ac172c2f257d28c47b90c9e381bec31edcc44 upstream.
Add cannon point device ids for 4th (itouch) device.
Cc: <stable(a)vger.kernel.org> 4.14+
Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/mei/hw-me-regs.h | 2 ++
drivers/misc/mei/pci-me.c | 2 ++
2 files changed, 4 insertions(+)
--- a/drivers/misc/mei/hw-me-regs.h
+++ b/drivers/misc/mei/hw-me-regs.h
@@ -133,7 +133,9 @@
#define MEI_DEV_ID_KBP_2 0xA2BB /* Kaby Point 2 */
#define MEI_DEV_ID_CNP_LP 0x9DE0 /* Cannon Point LP */
+#define MEI_DEV_ID_CNP_LP_4 0x9DE4 /* Cannon Point LP 4 (iTouch) */
#define MEI_DEV_ID_CNP_H 0xA360 /* Cannon Point H */
+#define MEI_DEV_ID_CNP_H_4 0xA364 /* Cannon Point H 4 (iTouch) */
/*
* MEI HW Section
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -99,7 +99,9 @@ static const struct pci_device_id mei_me
{MEI_PCI_DEVICE(MEI_DEV_ID_KBP_2, MEI_ME_PCH8_CFG)},
{MEI_PCI_DEVICE(MEI_DEV_ID_CNP_LP, MEI_ME_PCH8_CFG)},
+ {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_LP_4, MEI_ME_PCH8_CFG)},
{MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H, MEI_ME_PCH8_CFG)},
+ {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H_4, MEI_ME_PCH8_CFG)},
/* required last entry */
{0, }
Patches currently in stable-queue which might be from tomas.winkler(a)intel.com are
queue-4.14/mei-me-add-cannon-point-device-ids.patch
queue-4.14/mei-me-add-cannon-point-device-ids-for-4th-device.patch
This is a note to let you know that I've just added the patch titled
crypto: s5p-sss - Fix kernel Oops in AES-ECB mode
to the 4.14-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:
crypto-s5p-sss-fix-kernel-oops-in-aes-ecb-mode.patch
and it can be found in the queue-4.14 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 c927b080c67e3e97193c81fc1d27f4251bf4e036 Mon Sep 17 00:00:00 2001
From: Kamil Konieczny <k.konieczny(a)partner.samsung.com>
Date: Wed, 7 Feb 2018 16:52:09 +0100
Subject: crypto: s5p-sss - Fix kernel Oops in AES-ECB mode
From: Kamil Konieczny <k.konieczny(a)partner.samsung.com>
commit c927b080c67e3e97193c81fc1d27f4251bf4e036 upstream.
In AES-ECB mode crypt is done with key only, so any use of IV
can cause kernel Oops. Use IV only in AES-CBC and AES-CTR.
Signed-off-by: Kamil Konieczny <k.konieczny(a)partner.samsung.com>
Reported-by: Anand Moon <linux.amoon(a)gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Tested-by: Anand Moon <linux.amoon(a)gmail.com>
Cc: stable(a)vger.kernel.org # can be applied after commit 8f9702aad138
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/s5p-sss.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -601,15 +601,21 @@ static void s5p_aes_crypt_start(struct s
uint32_t aes_control;
unsigned long flags;
int err;
+ u8 *iv;
aes_control = SSS_AES_KEY_CHANGE_MODE;
if (mode & FLAGS_AES_DECRYPT)
aes_control |= SSS_AES_MODE_DECRYPT;
- if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CBC)
+ if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CBC) {
aes_control |= SSS_AES_CHAIN_MODE_CBC;
- else if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CTR)
+ iv = req->info;
+ } else if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CTR) {
aes_control |= SSS_AES_CHAIN_MODE_CTR;
+ iv = req->info;
+ } else {
+ iv = NULL; /* AES_ECB */
+ }
if (dev->ctx->keylen == AES_KEYSIZE_192)
aes_control |= SSS_AES_KEY_SIZE_192;
@@ -640,7 +646,7 @@ static void s5p_aes_crypt_start(struct s
goto outdata_error;
SSS_AES_WRITE(dev, AES_CONTROL, aes_control);
- s5p_set_aes(dev, dev->ctx->aes_key, req->info, dev->ctx->keylen);
+ s5p_set_aes(dev, dev->ctx->aes_key, iv, dev->ctx->keylen);
s5p_set_dma_indata(dev, dev->sg_src);
s5p_set_dma_outdata(dev, dev->sg_dst);
Patches currently in stable-queue which might be from k.konieczny(a)partner.samsung.com are
queue-4.14/crypto-s5p-sss-fix-kernel-oops-in-aes-ecb-mode.patch
This is a note to let you know that I've just added the patch titled
crypto: s5p-sss - Fix kernel Oops in AES-ECB mode
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:
crypto-s5p-sss-fix-kernel-oops-in-aes-ecb-mode.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 c927b080c67e3e97193c81fc1d27f4251bf4e036 Mon Sep 17 00:00:00 2001
From: Kamil Konieczny <k.konieczny(a)partner.samsung.com>
Date: Wed, 7 Feb 2018 16:52:09 +0100
Subject: crypto: s5p-sss - Fix kernel Oops in AES-ECB mode
From: Kamil Konieczny <k.konieczny(a)partner.samsung.com>
commit c927b080c67e3e97193c81fc1d27f4251bf4e036 upstream.
In AES-ECB mode crypt is done with key only, so any use of IV
can cause kernel Oops. Use IV only in AES-CBC and AES-CTR.
Signed-off-by: Kamil Konieczny <k.konieczny(a)partner.samsung.com>
Reported-by: Anand Moon <linux.amoon(a)gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Tested-by: Anand Moon <linux.amoon(a)gmail.com>
Cc: stable(a)vger.kernel.org # can be applied after commit 8f9702aad138
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/s5p-sss.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -419,16 +419,21 @@ static void s5p_aes_crypt_start(struct s
uint32_t aes_control;
int err;
unsigned long flags;
+ u8 *iv;
aes_control = SSS_AES_KEY_CHANGE_MODE;
if (mode & FLAGS_AES_DECRYPT)
aes_control |= SSS_AES_MODE_DECRYPT;
- if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CBC)
+ if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CBC) {
aes_control |= SSS_AES_CHAIN_MODE_CBC;
- else if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CTR)
+ iv = req->info;
+ } else if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CTR) {
aes_control |= SSS_AES_CHAIN_MODE_CTR;
-
+ iv = req->info;
+ } else {
+ iv = NULL; /* AES_ECB */
+ }
if (dev->ctx->keylen == AES_KEYSIZE_192)
aes_control |= SSS_AES_KEY_SIZE_192;
else if (dev->ctx->keylen == AES_KEYSIZE_256)
@@ -458,7 +463,7 @@ static void s5p_aes_crypt_start(struct s
goto outdata_error;
SSS_AES_WRITE(dev, AES_CONTROL, aes_control);
- s5p_set_aes(dev, dev->ctx->aes_key, req->info, dev->ctx->keylen);
+ s5p_set_aes(dev, dev->ctx->aes_key, iv, dev->ctx->keylen);
s5p_set_dma_indata(dev, req->src);
s5p_set_dma_outdata(dev, req->dst);
Patches currently in stable-queue which might be from k.konieczny(a)partner.samsung.com are
queue-3.18/crypto-s5p-sss-fix-kernel-oops-in-aes-ecb-mode.patch
This is a note to let you know that I've just added the patch titled
x86/ras/inject: Make it depend on X86_LOCAL_APIC=y
to the 4.4-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:
x86-ras-inject-make-it-depend-on-x86_local_apic-y.patch
and it can be found in the queue-4.4 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 d4b2ac63b0eae461fc10c9791084be24724ef57a Mon Sep 17 00:00:00 2001
From: Borislav Petkov <bp(a)suse.de>
Date: Mon, 23 Jan 2017 19:35:06 +0100
Subject: x86/ras/inject: Make it depend on X86_LOCAL_APIC=y
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Borislav Petkov <bp(a)suse.de>
commit d4b2ac63b0eae461fc10c9791084be24724ef57a upstream.
... and get rid of the annoying:
arch/x86/kernel/cpu/mcheck/mce-inject.c:97:13: warning: ‘mce_irq_ipi’ defined but not used [-Wunused-function]
when doing randconfig builds.
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Tony Luck <tony.luck(a)intel.com>
Cc: Yazen Ghannam <Yazen.Ghannam(a)amd.com>
Cc: linux-edac <linux-edac(a)vger.kernel.org>
Link: http://lkml.kernel.org/r/20170123183514.13356-2-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/Kconfig | 2 +-
arch/x86/kernel/cpu/mcheck/mce-inject.c | 5 +----
2 files changed, 2 insertions(+), 5 deletions(-)
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1009,7 +1009,7 @@ config X86_MCE_THRESHOLD
def_bool y
config X86_MCE_INJECT
- depends on X86_MCE
+ depends on X86_MCE && X86_LOCAL_APIC
tristate "Machine check injector support"
---help---
Provide support for injecting machine checks for testing purposes.
--- a/arch/x86/kernel/cpu/mcheck/mce-inject.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-inject.c
@@ -152,7 +152,6 @@ static void raise_mce(struct mce *m)
if (context == MCJ_CTX_RANDOM)
return;
-#ifdef CONFIG_X86_LOCAL_APIC
if (m->inject_flags & (MCJ_IRQ_BROADCAST | MCJ_NMI_BROADCAST)) {
unsigned long start;
int cpu;
@@ -193,9 +192,7 @@ static void raise_mce(struct mce *m)
raise_local();
put_cpu();
put_online_cpus();
- } else
-#endif
- {
+ } else {
preempt_disable();
raise_local();
preempt_enable();
Patches currently in stable-queue which might be from bp(a)suse.de are
queue-4.4/x86-nospec-fix-header-guards-names.patch
queue-4.4/x86-ras-inject-make-it-depend-on-x86_local_apic-y.patch
queue-4.4/mm-early_ioremap-fix-boot-hang-with-earlyprintk-efi-keep.patch
queue-4.4/platform-x86-intel_mid_thermal-fix-suspend-handlers-unused-warning.patch
queue-4.4/x86-microcode-amd-change-load_microcode_amd-s-param-to-bool-to-fix-preemptibility-bug.patch
queue-4.4/x86-spectre-fix-spelling-mistake-vunerable-vulnerable.patch
queue-4.4/amd-xgbe-fix-unused-suspend-handlers-build-warning.patch
queue-4.4/x86-platform-olpc-fix-resume-handler-build-warning.patch
queue-4.4/x86-bugs-drop-one-mitigation-from-dmesg.patch
This is a note to let you know that I've just added the patch titled
x86/platform/olpc: Fix resume handler build warning
to the 4.4-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:
x86-platform-olpc-fix-resume-handler-build-warning.patch
and it can be found in the queue-4.4 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 20ab6677716c7bbdcfd1cdb9aef296a0b3101f73 Mon Sep 17 00:00:00 2001
From: Borislav Petkov <bp(a)suse.de>
Date: Sat, 26 Nov 2016 15:27:06 +0100
Subject: x86/platform/olpc: Fix resume handler build warning
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Borislav Petkov <bp(a)suse.de>
commit 20ab6677716c7bbdcfd1cdb9aef296a0b3101f73 upstream.
Fix:
arch/x86/platform/olpc/olpc-xo15-sci.c:199:12: warning: ‘xo15_sci_resume’
defined but not used [-Wunused-function]
static int xo15_sci_resume(struct device *dev)
^
which I see in randconfig builds here.
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/20161126142706.13602-1-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/platform/olpc/olpc-xo15-sci.c | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/x86/platform/olpc/olpc-xo15-sci.c
+++ b/arch/x86/platform/olpc/olpc-xo15-sci.c
@@ -196,6 +196,7 @@ static int xo15_sci_remove(struct acpi_d
return 0;
}
+#ifdef CONFIG_PM_SLEEP
static int xo15_sci_resume(struct device *dev)
{
/* Enable all EC events */
@@ -207,6 +208,7 @@ static int xo15_sci_resume(struct device
return 0;
}
+#endif
static SIMPLE_DEV_PM_OPS(xo15_sci_pm, NULL, xo15_sci_resume);
Patches currently in stable-queue which might be from bp(a)suse.de are
queue-4.4/x86-nospec-fix-header-guards-names.patch
queue-4.4/x86-ras-inject-make-it-depend-on-x86_local_apic-y.patch
queue-4.4/mm-early_ioremap-fix-boot-hang-with-earlyprintk-efi-keep.patch
queue-4.4/platform-x86-intel_mid_thermal-fix-suspend-handlers-unused-warning.patch
queue-4.4/x86-microcode-amd-change-load_microcode_amd-s-param-to-bool-to-fix-preemptibility-bug.patch
queue-4.4/x86-spectre-fix-spelling-mistake-vunerable-vulnerable.patch
queue-4.4/amd-xgbe-fix-unused-suspend-handlers-build-warning.patch
queue-4.4/x86-platform-olpc-fix-resume-handler-build-warning.patch
queue-4.4/x86-bugs-drop-one-mitigation-from-dmesg.patch
This is a note to let you know that I've just added the patch titled
x86/platform: Add PCI dependency for PUNIT_ATOM_DEBUG
to the 4.4-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:
x86-platform-add-pci-dependency-for-punit_atom_debug.patch
and it can be found in the queue-4.4 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 d689c64d189e43d782fec5649fb0afe303c5b3f9 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 19 Jul 2017 14:53:05 +0200
Subject: x86/platform: Add PCI dependency for PUNIT_ATOM_DEBUG
From: Arnd Bergmann <arnd(a)arndb.de>
commit d689c64d189e43d782fec5649fb0afe303c5b3f9 upstream.
The IOSF_MBI option requires PCI support, without it we get a harmless
Kconfig warning when it gets selected by PUNIT_ATOM_DEBUG:
warning: (X86_INTEL_LPSS && SND_SST_IPC_ACPI && MMC_SDHCI_ACPI && PUNIT_ATOM_DEBUG) selects IOSF_MBI which has unmet direct dependencies (PCI)
This adds another dependency to avoid the warning.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/20170719125310.2487451-8-arnd@arndb.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -391,6 +391,7 @@ config X86_DEBUG_FPU
config PUNIT_ATOM_DEBUG
tristate "ATOM Punit debug driver"
+ depends on PCI
select DEBUG_FS
select IOSF_MBI
---help---
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/kasan-rework-kconfig-settings.patch
queue-4.4/hdpvr-hide-unused-variable.patch
queue-4.4/mtd-ichxrom-maybe-uninitialized-with-gcc-4.9.patch
queue-4.4/profile-hide-unused-functions-when-config_proc_fs.patch
queue-4.4/perf-x86-shut-up-false-positive-wmaybe-uninitialized-warning.patch
queue-4.4/hwrng-exynos-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-cdc_subset-only-build-when-one-driver-is-enabled.patch
queue-4.4/ipv4-ipconfig-avoid-unused-ic_proto_used-symbol.patch
queue-4.4/revert-power-bq27xxx_battery-remove-unneeded-dependency-in-kconfig.patch
queue-4.4/go7007-add-media_camera_support-dependency.patch
queue-4.4/scsi-advansys-fix-build-warning-for-pci-n.patch
queue-4.4/ssb-mark-ssb_bus_register-as-__maybe_unused.patch
queue-4.4/tty-cyclades-cyz_interrupt-is-only-used-for-pci.patch
queue-4.4/infiniband-cxgb4-use-pr-format-string-for-printing-resources.patch
queue-4.4/video-fbdev-via-remove-possibly-unused-variables.patch
queue-4.4/binfmt_elf-compat-avoid-unused-function-warning.patch
queue-4.4/drm-gma500-remove-helper-function.patch
queue-4.4/fbdev-s6e8ax0-avoid-unused-function-warnings.patch
queue-4.4/netfilter-ipvs-avoid-unused-variable-warnings.patch
queue-4.4/idle-i7300-add-pci-dependency.patch
queue-4.4/b2c2-flexcop-avoid-unused-function-warnings.patch
queue-4.4/fbdev-auo_k190x-avoid-unused-function-warnings.patch
queue-4.4/cw1200-fix-bogus-maybe-uninitialized-warning.patch
queue-4.4/x86-build-silence-the-build-with-make-s.patch
queue-4.4/gpio-xgene-mark-pm-functions-as-__maybe_unused.patch
queue-4.4/kvm-add-x86_local_apic-dependency.patch
queue-4.4/arm-tegra-select-usb_ulpi-from-ehci-rather-than-platform.patch
queue-4.4/asoc-mediatek-add-i2c-dependency.patch
queue-4.4/reiserfs-avoid-a-wmaybe-uninitialized-warning.patch
queue-4.4/scsi-advansys-fix-uninitialized-data-access.patch
queue-4.4/mtd-sh_flctl-pass-fifo-as-physical-address.patch
queue-4.4/driver-core-use-dev-argument-in-dev_dbg_ratelimited-stub.patch
queue-4.4/modsign-hide-openssl-output-in-silent-builds.patch
queue-4.4/net-hp100-remove-unnecessary-ifdefs.patch
queue-4.4/genirq-msi-add-stubs-for-get_cached_msi_msg-pci_write_msi_msg.patch
queue-4.4/asoc-intel-kconfig-fix-build-when-acpi-is-not-enabled.patch
queue-4.4/asoc-ux500-add-module_license-tag.patch
queue-4.4/wireless-cw1200-use-__maybe_unused-to-hide-pm-functions_.patch
queue-4.4/mptfusion-hide-unused-seq_mpt_print_ioc_summary-function.patch
queue-4.4/tlan-avoid-unused-label-with-pci-n.patch
queue-4.4/usb-musb-ux500-remove-duplicate-check-for-dma_is_compatible.patch
queue-4.4/mtd-cfi-enforce-valid-geometry-configuration.patch
queue-4.4/thermal-spear-use-__maybe_unused-for-pm-functions.patch
queue-4.4/x86-microcode-amd-change-load_microcode_amd-s-param-to-bool-to-fix-preemptibility-bug.patch
queue-4.4/video-fbdev-mmp-add-module_license.patch
queue-4.4/fbdev-sis-enforce-selection-of-at-least-one-backend.patch
queue-4.4/x86-boot-avoid-warning-for-zero-filling-.bss.patch
queue-4.4/power-bq27xxx_battery-mark-some-symbols-__maybe_unused.patch
queue-4.4/scsi-mvumi-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-phy-msm-add-regulator-dependency.patch
queue-4.4/isdn-icn-remove-a-warning.patch
queue-4.4/ncr5380-shut-up-gcc-indentation-warning.patch
queue-4.4/arm64-dts-add-cooling-cells-to-cpu-nodes.patch
queue-4.4/vmxnet3-prevent-building-with-64k-pages.patch
queue-4.4/genksyms-fix-segfault-with-invalid-declarations.patch
queue-4.4/x86-platform-add-pci-dependency-for-punit_atom_debug.patch
queue-4.4/target-user-fix-cast-from-pointer-to-phys_addr_t.patch
queue-4.4/rtlwifi-fix-gcc-6-indentation-warning.patch
queue-4.4/alsa-hda-ca0132-fix-possible-null-pointer-use.patch
queue-4.4/thermal-fix-intel_soc_dts_iosf_core-dependencies.patch
queue-4.4/arm64-define-bug-instruction-without-config_bug.patch
queue-4.4/v4l-remove-media_tuner-dependency-for-video_tuner.patch
queue-4.4/tc358743-fix-register-i2c_rd-wr-functions.patch
queue-4.4/scsi-fdomain-drop-fdomain_pci_tbl-when-built-in.patch
queue-4.4/scsi-initio-remove-duplicate-module-device-table.patch
queue-4.4/netlink-fix-nla_put_-u8-u16-u32-for-kasan.patch
queue-4.4/x86-fpu-math-emu-fix-possible-uninitialized-variable-use.patch
queue-4.4/asoc-rockchip-use-__maybe_unused-to-hide-st_irq_syscfg_resume.patch
queue-4.4/staging-ste_rmi4-avoid-unused-function-warnings.patch
queue-4.4/em28xx-only-use-mt9v011-if-camera-support-is-enabled.patch
queue-4.4/pwc-hide-unused-label.patch
queue-4.4/input-tca8418_keypad-hide-gcc-4.9-wmaybe-uninitialized-warning.patch
queue-4.4/fbdev-sm712fb-avoid-unused-function-warnings.patch
queue-4.4/isdn-sc-work-around-type-mismatch-warning.patch
queue-4.4/tty-hvc_xen-hide-xen_console_remove-when-unused.patch
queue-4.4/virtio_balloon-prevent-uninitialized-variable-use.patch
queue-4.4/drm-nouveau-hide-gcc-4.9-wmaybe-uninitialized.patch
queue-4.4/dell-wmi-dell-laptop-depends-dmi.patch
queue-4.4/x86-add-multiuser-dependency-for-kvm.patch
queue-4.4/md-avoid-warning-for-32-bit-sector_t.patch
queue-4.4/isdn-eicon-reduce-stack-size-of-sig_ind-function.patch
This is a note to let you know that I've just added the patch titled
x86/fpu/math-emu: Fix possible uninitialized variable use
to the 4.4-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:
x86-fpu-math-emu-fix-possible-uninitialized-variable-use.patch
and it can be found in the queue-4.4 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 75e2f0a6b16141cb347f442033ec907380d4d66e Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 19 Jul 2017 14:53:00 +0200
Subject: x86/fpu/math-emu: Fix possible uninitialized variable use
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Arnd Bergmann <arnd(a)arndb.de>
commit 75e2f0a6b16141cb347f442033ec907380d4d66e upstream.
When building the kernel with "make EXTRA_CFLAGS=...", this overrides
the "PARANOID" preprocessor macro defined in arch/x86/math-emu/Makefile,
and we run into a build warning:
arch/x86/math-emu/reg_compare.c: In function ‘compare_i_st_st’:
arch/x86/math-emu/reg_compare.c:254:6: error: ‘f’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
This fixes the implementation to work correctly even without the PARANOID
flag, and also fixes the Makefile to not use the EXTRA_CFLAGS variable
but instead use the ccflags-y variable in the Makefile that is meant
for this purpose.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Bill Metzenthen <billm(a)melbpc.org.au>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/20170719125310.2487451-3-arnd@arndb.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/math-emu/Makefile | 4 ++--
arch/x86/math-emu/reg_compare.c | 16 ++++++++--------
2 files changed, 10 insertions(+), 10 deletions(-)
--- a/arch/x86/math-emu/Makefile
+++ b/arch/x86/math-emu/Makefile
@@ -5,8 +5,8 @@
#DEBUG = -DDEBUGGING
DEBUG =
PARANOID = -DPARANOID
-EXTRA_CFLAGS := $(PARANOID) $(DEBUG) -fno-builtin $(MATH_EMULATION)
-EXTRA_AFLAGS := $(PARANOID)
+ccflags-y += $(PARANOID) $(DEBUG) -fno-builtin $(MATH_EMULATION)
+asflags-y += $(PARANOID)
# From 'C' language sources:
C_OBJS =fpu_entry.o errors.o \
--- a/arch/x86/math-emu/reg_compare.c
+++ b/arch/x86/math-emu/reg_compare.c
@@ -168,7 +168,7 @@ static int compare(FPU_REG const *b, int
/* This function requires that st(0) is not empty */
int FPU_compare_st_data(FPU_REG const *loaded_data, u_char loaded_tag)
{
- int f = 0, c;
+ int f, c;
c = compare(loaded_data, loaded_tag);
@@ -189,12 +189,12 @@ int FPU_compare_st_data(FPU_REG const *l
case COMP_No_Comp:
f = SW_C3 | SW_C2 | SW_C0;
break;
-#ifdef PARANOID
default:
+#ifdef PARANOID
EXCEPTION(EX_INTERNAL | 0x121);
+#endif /* PARANOID */
f = SW_C3 | SW_C2 | SW_C0;
break;
-#endif /* PARANOID */
}
setcc(f);
if (c & COMP_Denormal) {
@@ -205,7 +205,7 @@ int FPU_compare_st_data(FPU_REG const *l
static int compare_st_st(int nr)
{
- int f = 0, c;
+ int f, c;
FPU_REG *st_ptr;
if (!NOT_EMPTY(0) || !NOT_EMPTY(nr)) {
@@ -235,12 +235,12 @@ static int compare_st_st(int nr)
case COMP_No_Comp:
f = SW_C3 | SW_C2 | SW_C0;
break;
-#ifdef PARANOID
default:
+#ifdef PARANOID
EXCEPTION(EX_INTERNAL | 0x122);
+#endif /* PARANOID */
f = SW_C3 | SW_C2 | SW_C0;
break;
-#endif /* PARANOID */
}
setcc(f);
if (c & COMP_Denormal) {
@@ -283,12 +283,12 @@ static int compare_i_st_st(int nr)
case COMP_No_Comp:
f = X86_EFLAGS_ZF | X86_EFLAGS_PF | X86_EFLAGS_CF;
break;
-#ifdef PARANOID
default:
+#ifdef PARANOID
EXCEPTION(EX_INTERNAL | 0x122);
+#endif /* PARANOID */
f = 0;
break;
-#endif /* PARANOID */
}
FPU_EFLAGS = (FPU_EFLAGS & ~(X86_EFLAGS_ZF | X86_EFLAGS_PF | X86_EFLAGS_CF)) | f;
if (c & COMP_Denormal) {
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/kasan-rework-kconfig-settings.patch
queue-4.4/hdpvr-hide-unused-variable.patch
queue-4.4/mtd-ichxrom-maybe-uninitialized-with-gcc-4.9.patch
queue-4.4/profile-hide-unused-functions-when-config_proc_fs.patch
queue-4.4/perf-x86-shut-up-false-positive-wmaybe-uninitialized-warning.patch
queue-4.4/hwrng-exynos-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-cdc_subset-only-build-when-one-driver-is-enabled.patch
queue-4.4/ipv4-ipconfig-avoid-unused-ic_proto_used-symbol.patch
queue-4.4/revert-power-bq27xxx_battery-remove-unneeded-dependency-in-kconfig.patch
queue-4.4/go7007-add-media_camera_support-dependency.patch
queue-4.4/scsi-advansys-fix-build-warning-for-pci-n.patch
queue-4.4/ssb-mark-ssb_bus_register-as-__maybe_unused.patch
queue-4.4/tty-cyclades-cyz_interrupt-is-only-used-for-pci.patch
queue-4.4/infiniband-cxgb4-use-pr-format-string-for-printing-resources.patch
queue-4.4/video-fbdev-via-remove-possibly-unused-variables.patch
queue-4.4/binfmt_elf-compat-avoid-unused-function-warning.patch
queue-4.4/drm-gma500-remove-helper-function.patch
queue-4.4/fbdev-s6e8ax0-avoid-unused-function-warnings.patch
queue-4.4/netfilter-ipvs-avoid-unused-variable-warnings.patch
queue-4.4/idle-i7300-add-pci-dependency.patch
queue-4.4/b2c2-flexcop-avoid-unused-function-warnings.patch
queue-4.4/fbdev-auo_k190x-avoid-unused-function-warnings.patch
queue-4.4/cw1200-fix-bogus-maybe-uninitialized-warning.patch
queue-4.4/x86-build-silence-the-build-with-make-s.patch
queue-4.4/gpio-xgene-mark-pm-functions-as-__maybe_unused.patch
queue-4.4/kvm-add-x86_local_apic-dependency.patch
queue-4.4/arm-tegra-select-usb_ulpi-from-ehci-rather-than-platform.patch
queue-4.4/asoc-mediatek-add-i2c-dependency.patch
queue-4.4/reiserfs-avoid-a-wmaybe-uninitialized-warning.patch
queue-4.4/scsi-advansys-fix-uninitialized-data-access.patch
queue-4.4/mtd-sh_flctl-pass-fifo-as-physical-address.patch
queue-4.4/driver-core-use-dev-argument-in-dev_dbg_ratelimited-stub.patch
queue-4.4/modsign-hide-openssl-output-in-silent-builds.patch
queue-4.4/net-hp100-remove-unnecessary-ifdefs.patch
queue-4.4/genirq-msi-add-stubs-for-get_cached_msi_msg-pci_write_msi_msg.patch
queue-4.4/asoc-intel-kconfig-fix-build-when-acpi-is-not-enabled.patch
queue-4.4/asoc-ux500-add-module_license-tag.patch
queue-4.4/wireless-cw1200-use-__maybe_unused-to-hide-pm-functions_.patch
queue-4.4/mptfusion-hide-unused-seq_mpt_print_ioc_summary-function.patch
queue-4.4/tlan-avoid-unused-label-with-pci-n.patch
queue-4.4/usb-musb-ux500-remove-duplicate-check-for-dma_is_compatible.patch
queue-4.4/mtd-cfi-enforce-valid-geometry-configuration.patch
queue-4.4/thermal-spear-use-__maybe_unused-for-pm-functions.patch
queue-4.4/x86-microcode-amd-change-load_microcode_amd-s-param-to-bool-to-fix-preemptibility-bug.patch
queue-4.4/video-fbdev-mmp-add-module_license.patch
queue-4.4/fbdev-sis-enforce-selection-of-at-least-one-backend.patch
queue-4.4/x86-boot-avoid-warning-for-zero-filling-.bss.patch
queue-4.4/power-bq27xxx_battery-mark-some-symbols-__maybe_unused.patch
queue-4.4/scsi-mvumi-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-phy-msm-add-regulator-dependency.patch
queue-4.4/isdn-icn-remove-a-warning.patch
queue-4.4/ncr5380-shut-up-gcc-indentation-warning.patch
queue-4.4/arm64-dts-add-cooling-cells-to-cpu-nodes.patch
queue-4.4/vmxnet3-prevent-building-with-64k-pages.patch
queue-4.4/genksyms-fix-segfault-with-invalid-declarations.patch
queue-4.4/x86-platform-add-pci-dependency-for-punit_atom_debug.patch
queue-4.4/target-user-fix-cast-from-pointer-to-phys_addr_t.patch
queue-4.4/rtlwifi-fix-gcc-6-indentation-warning.patch
queue-4.4/alsa-hda-ca0132-fix-possible-null-pointer-use.patch
queue-4.4/thermal-fix-intel_soc_dts_iosf_core-dependencies.patch
queue-4.4/arm64-define-bug-instruction-without-config_bug.patch
queue-4.4/v4l-remove-media_tuner-dependency-for-video_tuner.patch
queue-4.4/tc358743-fix-register-i2c_rd-wr-functions.patch
queue-4.4/scsi-fdomain-drop-fdomain_pci_tbl-when-built-in.patch
queue-4.4/scsi-initio-remove-duplicate-module-device-table.patch
queue-4.4/netlink-fix-nla_put_-u8-u16-u32-for-kasan.patch
queue-4.4/x86-fpu-math-emu-fix-possible-uninitialized-variable-use.patch
queue-4.4/asoc-rockchip-use-__maybe_unused-to-hide-st_irq_syscfg_resume.patch
queue-4.4/staging-ste_rmi4-avoid-unused-function-warnings.patch
queue-4.4/em28xx-only-use-mt9v011-if-camera-support-is-enabled.patch
queue-4.4/pwc-hide-unused-label.patch
queue-4.4/input-tca8418_keypad-hide-gcc-4.9-wmaybe-uninitialized-warning.patch
queue-4.4/fbdev-sm712fb-avoid-unused-function-warnings.patch
queue-4.4/isdn-sc-work-around-type-mismatch-warning.patch
queue-4.4/tty-hvc_xen-hide-xen_console_remove-when-unused.patch
queue-4.4/virtio_balloon-prevent-uninitialized-variable-use.patch
queue-4.4/drm-nouveau-hide-gcc-4.9-wmaybe-uninitialized.patch
queue-4.4/dell-wmi-dell-laptop-depends-dmi.patch
queue-4.4/x86-add-multiuser-dependency-for-kvm.patch
queue-4.4/md-avoid-warning-for-32-bit-sector_t.patch
queue-4.4/isdn-eicon-reduce-stack-size-of-sig_ind-function.patch
This is a note to let you know that I've just added the patch titled
x86/build: Silence the build with "make -s"
to the 4.4-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:
x86-build-silence-the-build-with-make-s.patch
and it can be found in the queue-4.4 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 d460131dd50599e0e9405d5f4ae02c27d529a44a Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 19 Jul 2017 14:53:03 +0200
Subject: x86/build: Silence the build with "make -s"
From: Arnd Bergmann <arnd(a)arndb.de>
commit d460131dd50599e0e9405d5f4ae02c27d529a44a upstream.
Every kernel build on x86 will result in some output:
Setup is 13084 bytes (padded to 13312 bytes).
System is 4833 kB
CRC 6d35fa35
Kernel: arch/x86/boot/bzImage is ready (#2)
This shuts it up, so that 'make -s' is truely silent as long as
everything works. Building without '-s' should produce unchanged
output.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Matt Fleming <matt(a)codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/20170719125310.2487451-6-arnd@arndb.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/boot/Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -64,12 +64,13 @@ GCOV_PROFILE := n
$(obj)/bzImage: asflags-y := $(SVGA_MODE)
quiet_cmd_image = BUILD $@
+silent_redirect_image = >/dev/null
cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin \
- $(obj)/zoffset.h $@
+ $(obj)/zoffset.h $@ $($(quiet)redirect_image)
$(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin $(obj)/tools/build FORCE
$(call if_changed,image)
- @echo 'Kernel: $@ is ready' ' (#'`cat .version`')'
+ @$(kecho) 'Kernel: $@ is ready' ' (#'`cat .version`')'
OBJCOPYFLAGS_vmlinux.bin := -O binary -R .note -R .comment -S
$(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/kasan-rework-kconfig-settings.patch
queue-4.4/hdpvr-hide-unused-variable.patch
queue-4.4/mtd-ichxrom-maybe-uninitialized-with-gcc-4.9.patch
queue-4.4/profile-hide-unused-functions-when-config_proc_fs.patch
queue-4.4/perf-x86-shut-up-false-positive-wmaybe-uninitialized-warning.patch
queue-4.4/hwrng-exynos-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-cdc_subset-only-build-when-one-driver-is-enabled.patch
queue-4.4/ipv4-ipconfig-avoid-unused-ic_proto_used-symbol.patch
queue-4.4/revert-power-bq27xxx_battery-remove-unneeded-dependency-in-kconfig.patch
queue-4.4/go7007-add-media_camera_support-dependency.patch
queue-4.4/scsi-advansys-fix-build-warning-for-pci-n.patch
queue-4.4/ssb-mark-ssb_bus_register-as-__maybe_unused.patch
queue-4.4/tty-cyclades-cyz_interrupt-is-only-used-for-pci.patch
queue-4.4/infiniband-cxgb4-use-pr-format-string-for-printing-resources.patch
queue-4.4/video-fbdev-via-remove-possibly-unused-variables.patch
queue-4.4/binfmt_elf-compat-avoid-unused-function-warning.patch
queue-4.4/drm-gma500-remove-helper-function.patch
queue-4.4/fbdev-s6e8ax0-avoid-unused-function-warnings.patch
queue-4.4/netfilter-ipvs-avoid-unused-variable-warnings.patch
queue-4.4/idle-i7300-add-pci-dependency.patch
queue-4.4/b2c2-flexcop-avoid-unused-function-warnings.patch
queue-4.4/fbdev-auo_k190x-avoid-unused-function-warnings.patch
queue-4.4/cw1200-fix-bogus-maybe-uninitialized-warning.patch
queue-4.4/x86-build-silence-the-build-with-make-s.patch
queue-4.4/gpio-xgene-mark-pm-functions-as-__maybe_unused.patch
queue-4.4/kvm-add-x86_local_apic-dependency.patch
queue-4.4/arm-tegra-select-usb_ulpi-from-ehci-rather-than-platform.patch
queue-4.4/asoc-mediatek-add-i2c-dependency.patch
queue-4.4/reiserfs-avoid-a-wmaybe-uninitialized-warning.patch
queue-4.4/scsi-advansys-fix-uninitialized-data-access.patch
queue-4.4/mtd-sh_flctl-pass-fifo-as-physical-address.patch
queue-4.4/driver-core-use-dev-argument-in-dev_dbg_ratelimited-stub.patch
queue-4.4/modsign-hide-openssl-output-in-silent-builds.patch
queue-4.4/net-hp100-remove-unnecessary-ifdefs.patch
queue-4.4/genirq-msi-add-stubs-for-get_cached_msi_msg-pci_write_msi_msg.patch
queue-4.4/asoc-intel-kconfig-fix-build-when-acpi-is-not-enabled.patch
queue-4.4/asoc-ux500-add-module_license-tag.patch
queue-4.4/wireless-cw1200-use-__maybe_unused-to-hide-pm-functions_.patch
queue-4.4/mptfusion-hide-unused-seq_mpt_print_ioc_summary-function.patch
queue-4.4/tlan-avoid-unused-label-with-pci-n.patch
queue-4.4/usb-musb-ux500-remove-duplicate-check-for-dma_is_compatible.patch
queue-4.4/mtd-cfi-enforce-valid-geometry-configuration.patch
queue-4.4/thermal-spear-use-__maybe_unused-for-pm-functions.patch
queue-4.4/x86-microcode-amd-change-load_microcode_amd-s-param-to-bool-to-fix-preemptibility-bug.patch
queue-4.4/video-fbdev-mmp-add-module_license.patch
queue-4.4/fbdev-sis-enforce-selection-of-at-least-one-backend.patch
queue-4.4/x86-boot-avoid-warning-for-zero-filling-.bss.patch
queue-4.4/power-bq27xxx_battery-mark-some-symbols-__maybe_unused.patch
queue-4.4/scsi-mvumi-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-phy-msm-add-regulator-dependency.patch
queue-4.4/isdn-icn-remove-a-warning.patch
queue-4.4/ncr5380-shut-up-gcc-indentation-warning.patch
queue-4.4/arm64-dts-add-cooling-cells-to-cpu-nodes.patch
queue-4.4/vmxnet3-prevent-building-with-64k-pages.patch
queue-4.4/genksyms-fix-segfault-with-invalid-declarations.patch
queue-4.4/x86-platform-add-pci-dependency-for-punit_atom_debug.patch
queue-4.4/target-user-fix-cast-from-pointer-to-phys_addr_t.patch
queue-4.4/rtlwifi-fix-gcc-6-indentation-warning.patch
queue-4.4/alsa-hda-ca0132-fix-possible-null-pointer-use.patch
queue-4.4/thermal-fix-intel_soc_dts_iosf_core-dependencies.patch
queue-4.4/arm64-define-bug-instruction-without-config_bug.patch
queue-4.4/v4l-remove-media_tuner-dependency-for-video_tuner.patch
queue-4.4/tc358743-fix-register-i2c_rd-wr-functions.patch
queue-4.4/scsi-fdomain-drop-fdomain_pci_tbl-when-built-in.patch
queue-4.4/scsi-initio-remove-duplicate-module-device-table.patch
queue-4.4/netlink-fix-nla_put_-u8-u16-u32-for-kasan.patch
queue-4.4/x86-fpu-math-emu-fix-possible-uninitialized-variable-use.patch
queue-4.4/asoc-rockchip-use-__maybe_unused-to-hide-st_irq_syscfg_resume.patch
queue-4.4/staging-ste_rmi4-avoid-unused-function-warnings.patch
queue-4.4/em28xx-only-use-mt9v011-if-camera-support-is-enabled.patch
queue-4.4/pwc-hide-unused-label.patch
queue-4.4/input-tca8418_keypad-hide-gcc-4.9-wmaybe-uninitialized-warning.patch
queue-4.4/fbdev-sm712fb-avoid-unused-function-warnings.patch
queue-4.4/isdn-sc-work-around-type-mismatch-warning.patch
queue-4.4/tty-hvc_xen-hide-xen_console_remove-when-unused.patch
queue-4.4/virtio_balloon-prevent-uninitialized-variable-use.patch
queue-4.4/drm-nouveau-hide-gcc-4.9-wmaybe-uninitialized.patch
queue-4.4/dell-wmi-dell-laptop-depends-dmi.patch
queue-4.4/x86-add-multiuser-dependency-for-kvm.patch
queue-4.4/md-avoid-warning-for-32-bit-sector_t.patch
queue-4.4/isdn-eicon-reduce-stack-size-of-sig_ind-function.patch
This is a note to let you know that I've just added the patch titled
x86/boot: Avoid warning for zero-filling .bss
to the 4.4-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:
x86-boot-avoid-warning-for-zero-filling-.bss.patch
and it can be found in the queue-4.4 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 553bbc11aa6c1f9e0f529a06aeeca15fbe4a3985 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 16 Nov 2016 15:17:09 +0100
Subject: x86/boot: Avoid warning for zero-filling .bss
From: Arnd Bergmann <arnd(a)arndb.de>
commit 553bbc11aa6c1f9e0f529a06aeeca15fbe4a3985 upstream.
The latest binutils are warning about a .fill directive with an explicit
value in a .bss section:
arch/x86/kernel/head_32.S: Assembler messages:
arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
This comes from the 'ENTRY()' macro padding the space between the symbols
with 'nop' via:
.align 4,0x90
Open-coding the .globl directive without the padding avoids that warning,
as all the symbols are already page aligned.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Brian Gerst <brgerst(a)gmail.com>
Cc: Denys Vlasenko <dvlasenk(a)redhat.com>
Cc: H. Peter Anvin <hpa(a)zytor.com>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/20161116141726.2013389-1-arnd@arndb.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/head_32.S | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -669,14 +669,17 @@ __PAGE_ALIGNED_BSS
initial_pg_pmd:
.fill 1024*KPMDS,4,0
#else
-ENTRY(initial_page_table)
+.globl initial_page_table
+initial_page_table:
.fill 1024,4,0
#endif
initial_pg_fixmap:
.fill 1024,4,0
-ENTRY(empty_zero_page)
+.globl empty_zero_page
+empty_zero_page:
.fill 4096,1,0
-ENTRY(swapper_pg_dir)
+.globl swapper_pg_dir
+swapper_pg_dir:
.fill 1024,4,0
/*
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/kasan-rework-kconfig-settings.patch
queue-4.4/hdpvr-hide-unused-variable.patch
queue-4.4/mtd-ichxrom-maybe-uninitialized-with-gcc-4.9.patch
queue-4.4/profile-hide-unused-functions-when-config_proc_fs.patch
queue-4.4/perf-x86-shut-up-false-positive-wmaybe-uninitialized-warning.patch
queue-4.4/hwrng-exynos-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-cdc_subset-only-build-when-one-driver-is-enabled.patch
queue-4.4/ipv4-ipconfig-avoid-unused-ic_proto_used-symbol.patch
queue-4.4/revert-power-bq27xxx_battery-remove-unneeded-dependency-in-kconfig.patch
queue-4.4/go7007-add-media_camera_support-dependency.patch
queue-4.4/scsi-advansys-fix-build-warning-for-pci-n.patch
queue-4.4/ssb-mark-ssb_bus_register-as-__maybe_unused.patch
queue-4.4/tty-cyclades-cyz_interrupt-is-only-used-for-pci.patch
queue-4.4/infiniband-cxgb4-use-pr-format-string-for-printing-resources.patch
queue-4.4/video-fbdev-via-remove-possibly-unused-variables.patch
queue-4.4/binfmt_elf-compat-avoid-unused-function-warning.patch
queue-4.4/drm-gma500-remove-helper-function.patch
queue-4.4/fbdev-s6e8ax0-avoid-unused-function-warnings.patch
queue-4.4/netfilter-ipvs-avoid-unused-variable-warnings.patch
queue-4.4/idle-i7300-add-pci-dependency.patch
queue-4.4/b2c2-flexcop-avoid-unused-function-warnings.patch
queue-4.4/fbdev-auo_k190x-avoid-unused-function-warnings.patch
queue-4.4/cw1200-fix-bogus-maybe-uninitialized-warning.patch
queue-4.4/x86-build-silence-the-build-with-make-s.patch
queue-4.4/gpio-xgene-mark-pm-functions-as-__maybe_unused.patch
queue-4.4/kvm-add-x86_local_apic-dependency.patch
queue-4.4/arm-tegra-select-usb_ulpi-from-ehci-rather-than-platform.patch
queue-4.4/asoc-mediatek-add-i2c-dependency.patch
queue-4.4/reiserfs-avoid-a-wmaybe-uninitialized-warning.patch
queue-4.4/scsi-advansys-fix-uninitialized-data-access.patch
queue-4.4/mtd-sh_flctl-pass-fifo-as-physical-address.patch
queue-4.4/driver-core-use-dev-argument-in-dev_dbg_ratelimited-stub.patch
queue-4.4/modsign-hide-openssl-output-in-silent-builds.patch
queue-4.4/net-hp100-remove-unnecessary-ifdefs.patch
queue-4.4/genirq-msi-add-stubs-for-get_cached_msi_msg-pci_write_msi_msg.patch
queue-4.4/asoc-intel-kconfig-fix-build-when-acpi-is-not-enabled.patch
queue-4.4/asoc-ux500-add-module_license-tag.patch
queue-4.4/wireless-cw1200-use-__maybe_unused-to-hide-pm-functions_.patch
queue-4.4/mptfusion-hide-unused-seq_mpt_print_ioc_summary-function.patch
queue-4.4/tlan-avoid-unused-label-with-pci-n.patch
queue-4.4/usb-musb-ux500-remove-duplicate-check-for-dma_is_compatible.patch
queue-4.4/mtd-cfi-enforce-valid-geometry-configuration.patch
queue-4.4/thermal-spear-use-__maybe_unused-for-pm-functions.patch
queue-4.4/x86-microcode-amd-change-load_microcode_amd-s-param-to-bool-to-fix-preemptibility-bug.patch
queue-4.4/video-fbdev-mmp-add-module_license.patch
queue-4.4/fbdev-sis-enforce-selection-of-at-least-one-backend.patch
queue-4.4/x86-boot-avoid-warning-for-zero-filling-.bss.patch
queue-4.4/power-bq27xxx_battery-mark-some-symbols-__maybe_unused.patch
queue-4.4/scsi-mvumi-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-phy-msm-add-regulator-dependency.patch
queue-4.4/isdn-icn-remove-a-warning.patch
queue-4.4/ncr5380-shut-up-gcc-indentation-warning.patch
queue-4.4/arm64-dts-add-cooling-cells-to-cpu-nodes.patch
queue-4.4/vmxnet3-prevent-building-with-64k-pages.patch
queue-4.4/genksyms-fix-segfault-with-invalid-declarations.patch
queue-4.4/x86-platform-add-pci-dependency-for-punit_atom_debug.patch
queue-4.4/target-user-fix-cast-from-pointer-to-phys_addr_t.patch
queue-4.4/rtlwifi-fix-gcc-6-indentation-warning.patch
queue-4.4/alsa-hda-ca0132-fix-possible-null-pointer-use.patch
queue-4.4/thermal-fix-intel_soc_dts_iosf_core-dependencies.patch
queue-4.4/arm64-define-bug-instruction-without-config_bug.patch
queue-4.4/v4l-remove-media_tuner-dependency-for-video_tuner.patch
queue-4.4/tc358743-fix-register-i2c_rd-wr-functions.patch
queue-4.4/scsi-fdomain-drop-fdomain_pci_tbl-when-built-in.patch
queue-4.4/scsi-initio-remove-duplicate-module-device-table.patch
queue-4.4/netlink-fix-nla_put_-u8-u16-u32-for-kasan.patch
queue-4.4/x86-fpu-math-emu-fix-possible-uninitialized-variable-use.patch
queue-4.4/asoc-rockchip-use-__maybe_unused-to-hide-st_irq_syscfg_resume.patch
queue-4.4/staging-ste_rmi4-avoid-unused-function-warnings.patch
queue-4.4/em28xx-only-use-mt9v011-if-camera-support-is-enabled.patch
queue-4.4/pwc-hide-unused-label.patch
queue-4.4/input-tca8418_keypad-hide-gcc-4.9-wmaybe-uninitialized-warning.patch
queue-4.4/fbdev-sm712fb-avoid-unused-function-warnings.patch
queue-4.4/isdn-sc-work-around-type-mismatch-warning.patch
queue-4.4/tty-hvc_xen-hide-xen_console_remove-when-unused.patch
queue-4.4/virtio_balloon-prevent-uninitialized-variable-use.patch
queue-4.4/drm-nouveau-hide-gcc-4.9-wmaybe-uninitialized.patch
queue-4.4/dell-wmi-dell-laptop-depends-dmi.patch
queue-4.4/x86-add-multiuser-dependency-for-kvm.patch
queue-4.4/md-avoid-warning-for-32-bit-sector_t.patch
queue-4.4/isdn-eicon-reduce-stack-size-of-sig_ind-function.patch
This is a note to let you know that I've just added the patch titled
x86: add MULTIUSER dependency for KVM
to the 4.4-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:
x86-add-multiuser-dependency-for-kvm.patch
and it can be found in the queue-4.4 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 c2ce3f5d89d57301e2756ac325fe2ebc33bfec30 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 19 Jul 2017 14:53:04 +0200
Subject: x86: add MULTIUSER dependency for KVM
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Arnd Bergmann <arnd(a)arndb.de>
commit c2ce3f5d89d57301e2756ac325fe2ebc33bfec30 upstream.
KVM tries to select 'TASKSTATS', which had additional dependencies:
warning: (KVM) selects TASKSTATS which has unmet direct dependencies (NET && MULTIUSER)
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -22,7 +22,7 @@ config KVM
depends on HAVE_KVM
depends on HIGH_RES_TIMERS
# for TASKSTATS/TASK_DELAY_ACCT:
- depends on NET
+ depends on NET && MULTIUSER
select PREEMPT_NOTIFIERS
select MMU_NOTIFIER
select ANON_INODES
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/kasan-rework-kconfig-settings.patch
queue-4.4/hdpvr-hide-unused-variable.patch
queue-4.4/mtd-ichxrom-maybe-uninitialized-with-gcc-4.9.patch
queue-4.4/profile-hide-unused-functions-when-config_proc_fs.patch
queue-4.4/perf-x86-shut-up-false-positive-wmaybe-uninitialized-warning.patch
queue-4.4/hwrng-exynos-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-cdc_subset-only-build-when-one-driver-is-enabled.patch
queue-4.4/ipv4-ipconfig-avoid-unused-ic_proto_used-symbol.patch
queue-4.4/revert-power-bq27xxx_battery-remove-unneeded-dependency-in-kconfig.patch
queue-4.4/go7007-add-media_camera_support-dependency.patch
queue-4.4/scsi-advansys-fix-build-warning-for-pci-n.patch
queue-4.4/ssb-mark-ssb_bus_register-as-__maybe_unused.patch
queue-4.4/tty-cyclades-cyz_interrupt-is-only-used-for-pci.patch
queue-4.4/infiniband-cxgb4-use-pr-format-string-for-printing-resources.patch
queue-4.4/video-fbdev-via-remove-possibly-unused-variables.patch
queue-4.4/binfmt_elf-compat-avoid-unused-function-warning.patch
queue-4.4/drm-gma500-remove-helper-function.patch
queue-4.4/fbdev-s6e8ax0-avoid-unused-function-warnings.patch
queue-4.4/netfilter-ipvs-avoid-unused-variable-warnings.patch
queue-4.4/idle-i7300-add-pci-dependency.patch
queue-4.4/b2c2-flexcop-avoid-unused-function-warnings.patch
queue-4.4/fbdev-auo_k190x-avoid-unused-function-warnings.patch
queue-4.4/cw1200-fix-bogus-maybe-uninitialized-warning.patch
queue-4.4/x86-build-silence-the-build-with-make-s.patch
queue-4.4/gpio-xgene-mark-pm-functions-as-__maybe_unused.patch
queue-4.4/kvm-add-x86_local_apic-dependency.patch
queue-4.4/arm-tegra-select-usb_ulpi-from-ehci-rather-than-platform.patch
queue-4.4/asoc-mediatek-add-i2c-dependency.patch
queue-4.4/reiserfs-avoid-a-wmaybe-uninitialized-warning.patch
queue-4.4/scsi-advansys-fix-uninitialized-data-access.patch
queue-4.4/mtd-sh_flctl-pass-fifo-as-physical-address.patch
queue-4.4/driver-core-use-dev-argument-in-dev_dbg_ratelimited-stub.patch
queue-4.4/modsign-hide-openssl-output-in-silent-builds.patch
queue-4.4/net-hp100-remove-unnecessary-ifdefs.patch
queue-4.4/genirq-msi-add-stubs-for-get_cached_msi_msg-pci_write_msi_msg.patch
queue-4.4/asoc-intel-kconfig-fix-build-when-acpi-is-not-enabled.patch
queue-4.4/asoc-ux500-add-module_license-tag.patch
queue-4.4/wireless-cw1200-use-__maybe_unused-to-hide-pm-functions_.patch
queue-4.4/mptfusion-hide-unused-seq_mpt_print_ioc_summary-function.patch
queue-4.4/tlan-avoid-unused-label-with-pci-n.patch
queue-4.4/usb-musb-ux500-remove-duplicate-check-for-dma_is_compatible.patch
queue-4.4/mtd-cfi-enforce-valid-geometry-configuration.patch
queue-4.4/thermal-spear-use-__maybe_unused-for-pm-functions.patch
queue-4.4/x86-microcode-amd-change-load_microcode_amd-s-param-to-bool-to-fix-preemptibility-bug.patch
queue-4.4/video-fbdev-mmp-add-module_license.patch
queue-4.4/fbdev-sis-enforce-selection-of-at-least-one-backend.patch
queue-4.4/x86-boot-avoid-warning-for-zero-filling-.bss.patch
queue-4.4/power-bq27xxx_battery-mark-some-symbols-__maybe_unused.patch
queue-4.4/scsi-mvumi-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-phy-msm-add-regulator-dependency.patch
queue-4.4/isdn-icn-remove-a-warning.patch
queue-4.4/ncr5380-shut-up-gcc-indentation-warning.patch
queue-4.4/arm64-dts-add-cooling-cells-to-cpu-nodes.patch
queue-4.4/vmxnet3-prevent-building-with-64k-pages.patch
queue-4.4/genksyms-fix-segfault-with-invalid-declarations.patch
queue-4.4/x86-platform-add-pci-dependency-for-punit_atom_debug.patch
queue-4.4/target-user-fix-cast-from-pointer-to-phys_addr_t.patch
queue-4.4/rtlwifi-fix-gcc-6-indentation-warning.patch
queue-4.4/alsa-hda-ca0132-fix-possible-null-pointer-use.patch
queue-4.4/thermal-fix-intel_soc_dts_iosf_core-dependencies.patch
queue-4.4/arm64-define-bug-instruction-without-config_bug.patch
queue-4.4/v4l-remove-media_tuner-dependency-for-video_tuner.patch
queue-4.4/tc358743-fix-register-i2c_rd-wr-functions.patch
queue-4.4/scsi-fdomain-drop-fdomain_pci_tbl-when-built-in.patch
queue-4.4/scsi-initio-remove-duplicate-module-device-table.patch
queue-4.4/netlink-fix-nla_put_-u8-u16-u32-for-kasan.patch
queue-4.4/x86-fpu-math-emu-fix-possible-uninitialized-variable-use.patch
queue-4.4/asoc-rockchip-use-__maybe_unused-to-hide-st_irq_syscfg_resume.patch
queue-4.4/staging-ste_rmi4-avoid-unused-function-warnings.patch
queue-4.4/em28xx-only-use-mt9v011-if-camera-support-is-enabled.patch
queue-4.4/pwc-hide-unused-label.patch
queue-4.4/input-tca8418_keypad-hide-gcc-4.9-wmaybe-uninitialized-warning.patch
queue-4.4/fbdev-sm712fb-avoid-unused-function-warnings.patch
queue-4.4/isdn-sc-work-around-type-mismatch-warning.patch
queue-4.4/tty-hvc_xen-hide-xen_console_remove-when-unused.patch
queue-4.4/virtio_balloon-prevent-uninitialized-variable-use.patch
queue-4.4/drm-nouveau-hide-gcc-4.9-wmaybe-uninitialized.patch
queue-4.4/dell-wmi-dell-laptop-depends-dmi.patch
queue-4.4/x86-add-multiuser-dependency-for-kvm.patch
queue-4.4/md-avoid-warning-for-32-bit-sector_t.patch
queue-4.4/isdn-eicon-reduce-stack-size-of-sig_ind-function.patch
This is a note to let you know that I've just added the patch titled
wireless: cw1200: use __maybe_unused to hide pm functions_
to the 4.4-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:
wireless-cw1200-use-__maybe_unused-to-hide-pm-functions_.patch
and it can be found in the queue-4.4 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 836856e3bd61d0644e5178a2c1b51d90459e2788 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 2 Mar 2016 16:59:02 +0100
Subject: wireless: cw1200: use __maybe_unused to hide pm functions_
From: Arnd Bergmann <arnd(a)arndb.de>
commit 836856e3bd61d0644e5178a2c1b51d90459e2788 upstream.
The cw1200 uses #ifdef to check for CONFIG_PM, but then
uses SIMPLE_DEV_PM_OPS, which leaves the references out when
CONFIG_PM_SLEEP is not defined, so we get a warning with
PM=y && PM_SLEEP=n:
drivers/net/wireless/st/cw1200/cw1200_spi.c:450:12: error: 'cw1200_spi_suspend' defined but not used [-Werror=unused-function]
This removes the incorrect #ifdef and instead uses a __maybe_unused
annotation to let the compiler know it can silently drop
the function definition.
For the DEV_PM_OPS definition, we can use an IS_ENABLED() check
to avoid defining the structure when CONFIG_PM is not set without
the #ifdef.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/cw1200/cw1200_spi.c | 9 ++-------
drivers/net/wireless/cw1200/pm.h | 9 +++++++--
2 files changed, 9 insertions(+), 9 deletions(-)
--- a/drivers/net/wireless/cw1200/cw1200_spi.c
+++ b/drivers/net/wireless/cw1200/cw1200_spi.c
@@ -446,8 +446,7 @@ static int cw1200_spi_disconnect(struct
return 0;
}
-#ifdef CONFIG_PM
-static int cw1200_spi_suspend(struct device *dev)
+static int __maybe_unused cw1200_spi_suspend(struct device *dev)
{
struct hwbus_priv *self = spi_get_drvdata(to_spi_device(dev));
@@ -460,16 +459,12 @@ static int cw1200_spi_suspend(struct dev
static SIMPLE_DEV_PM_OPS(cw1200_pm_ops, cw1200_spi_suspend, NULL);
-#endif
-
static struct spi_driver spi_driver = {
.probe = cw1200_spi_probe,
.remove = cw1200_spi_disconnect,
.driver = {
.name = "cw1200_wlan_spi",
-#ifdef CONFIG_PM
- .pm = &cw1200_pm_ops,
-#endif
+ .pm = IS_ENABLED(CONFIG_PM) ? &cw1200_pm_ops : NULL,
},
};
--- a/drivers/net/wireless/cw1200/pm.h
+++ b/drivers/net/wireless/cw1200/pm.h
@@ -31,13 +31,18 @@ int cw1200_pm_init(struct cw1200_pm_stat
void cw1200_pm_deinit(struct cw1200_pm_state *pm);
int cw1200_wow_suspend(struct ieee80211_hw *hw,
struct cfg80211_wowlan *wowlan);
-int cw1200_wow_resume(struct ieee80211_hw *hw);
int cw1200_can_suspend(struct cw1200_common *priv);
+int cw1200_wow_resume(struct ieee80211_hw *hw);
void cw1200_pm_stay_awake(struct cw1200_pm_state *pm,
unsigned long tmo);
#else
static inline void cw1200_pm_stay_awake(struct cw1200_pm_state *pm,
- unsigned long tmo) {
+ unsigned long tmo)
+{
+}
+static inline int cw1200_can_suspend(struct cw1200_common *priv)
+{
+ return 0;
}
#endif
#endif
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/kasan-rework-kconfig-settings.patch
queue-4.4/hdpvr-hide-unused-variable.patch
queue-4.4/mtd-ichxrom-maybe-uninitialized-with-gcc-4.9.patch
queue-4.4/profile-hide-unused-functions-when-config_proc_fs.patch
queue-4.4/perf-x86-shut-up-false-positive-wmaybe-uninitialized-warning.patch
queue-4.4/hwrng-exynos-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-cdc_subset-only-build-when-one-driver-is-enabled.patch
queue-4.4/ipv4-ipconfig-avoid-unused-ic_proto_used-symbol.patch
queue-4.4/revert-power-bq27xxx_battery-remove-unneeded-dependency-in-kconfig.patch
queue-4.4/go7007-add-media_camera_support-dependency.patch
queue-4.4/scsi-advansys-fix-build-warning-for-pci-n.patch
queue-4.4/ssb-mark-ssb_bus_register-as-__maybe_unused.patch
queue-4.4/tty-cyclades-cyz_interrupt-is-only-used-for-pci.patch
queue-4.4/infiniband-cxgb4-use-pr-format-string-for-printing-resources.patch
queue-4.4/video-fbdev-via-remove-possibly-unused-variables.patch
queue-4.4/binfmt_elf-compat-avoid-unused-function-warning.patch
queue-4.4/drm-gma500-remove-helper-function.patch
queue-4.4/fbdev-s6e8ax0-avoid-unused-function-warnings.patch
queue-4.4/netfilter-ipvs-avoid-unused-variable-warnings.patch
queue-4.4/idle-i7300-add-pci-dependency.patch
queue-4.4/b2c2-flexcop-avoid-unused-function-warnings.patch
queue-4.4/fbdev-auo_k190x-avoid-unused-function-warnings.patch
queue-4.4/cw1200-fix-bogus-maybe-uninitialized-warning.patch
queue-4.4/x86-build-silence-the-build-with-make-s.patch
queue-4.4/gpio-xgene-mark-pm-functions-as-__maybe_unused.patch
queue-4.4/kvm-add-x86_local_apic-dependency.patch
queue-4.4/arm-tegra-select-usb_ulpi-from-ehci-rather-than-platform.patch
queue-4.4/asoc-mediatek-add-i2c-dependency.patch
queue-4.4/reiserfs-avoid-a-wmaybe-uninitialized-warning.patch
queue-4.4/scsi-advansys-fix-uninitialized-data-access.patch
queue-4.4/mtd-sh_flctl-pass-fifo-as-physical-address.patch
queue-4.4/driver-core-use-dev-argument-in-dev_dbg_ratelimited-stub.patch
queue-4.4/modsign-hide-openssl-output-in-silent-builds.patch
queue-4.4/net-hp100-remove-unnecessary-ifdefs.patch
queue-4.4/genirq-msi-add-stubs-for-get_cached_msi_msg-pci_write_msi_msg.patch
queue-4.4/asoc-intel-kconfig-fix-build-when-acpi-is-not-enabled.patch
queue-4.4/asoc-ux500-add-module_license-tag.patch
queue-4.4/wireless-cw1200-use-__maybe_unused-to-hide-pm-functions_.patch
queue-4.4/mptfusion-hide-unused-seq_mpt_print_ioc_summary-function.patch
queue-4.4/tlan-avoid-unused-label-with-pci-n.patch
queue-4.4/usb-musb-ux500-remove-duplicate-check-for-dma_is_compatible.patch
queue-4.4/mtd-cfi-enforce-valid-geometry-configuration.patch
queue-4.4/thermal-spear-use-__maybe_unused-for-pm-functions.patch
queue-4.4/x86-microcode-amd-change-load_microcode_amd-s-param-to-bool-to-fix-preemptibility-bug.patch
queue-4.4/video-fbdev-mmp-add-module_license.patch
queue-4.4/fbdev-sis-enforce-selection-of-at-least-one-backend.patch
queue-4.4/x86-boot-avoid-warning-for-zero-filling-.bss.patch
queue-4.4/power-bq27xxx_battery-mark-some-symbols-__maybe_unused.patch
queue-4.4/scsi-mvumi-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-phy-msm-add-regulator-dependency.patch
queue-4.4/isdn-icn-remove-a-warning.patch
queue-4.4/ncr5380-shut-up-gcc-indentation-warning.patch
queue-4.4/arm64-dts-add-cooling-cells-to-cpu-nodes.patch
queue-4.4/vmxnet3-prevent-building-with-64k-pages.patch
queue-4.4/genksyms-fix-segfault-with-invalid-declarations.patch
queue-4.4/x86-platform-add-pci-dependency-for-punit_atom_debug.patch
queue-4.4/target-user-fix-cast-from-pointer-to-phys_addr_t.patch
queue-4.4/rtlwifi-fix-gcc-6-indentation-warning.patch
queue-4.4/alsa-hda-ca0132-fix-possible-null-pointer-use.patch
queue-4.4/thermal-fix-intel_soc_dts_iosf_core-dependencies.patch
queue-4.4/arm64-define-bug-instruction-without-config_bug.patch
queue-4.4/v4l-remove-media_tuner-dependency-for-video_tuner.patch
queue-4.4/tc358743-fix-register-i2c_rd-wr-functions.patch
queue-4.4/scsi-fdomain-drop-fdomain_pci_tbl-when-built-in.patch
queue-4.4/scsi-initio-remove-duplicate-module-device-table.patch
queue-4.4/netlink-fix-nla_put_-u8-u16-u32-for-kasan.patch
queue-4.4/x86-fpu-math-emu-fix-possible-uninitialized-variable-use.patch
queue-4.4/asoc-rockchip-use-__maybe_unused-to-hide-st_irq_syscfg_resume.patch
queue-4.4/staging-ste_rmi4-avoid-unused-function-warnings.patch
queue-4.4/em28xx-only-use-mt9v011-if-camera-support-is-enabled.patch
queue-4.4/pwc-hide-unused-label.patch
queue-4.4/input-tca8418_keypad-hide-gcc-4.9-wmaybe-uninitialized-warning.patch
queue-4.4/fbdev-sm712fb-avoid-unused-function-warnings.patch
queue-4.4/isdn-sc-work-around-type-mismatch-warning.patch
queue-4.4/tty-hvc_xen-hide-xen_console_remove-when-unused.patch
queue-4.4/virtio_balloon-prevent-uninitialized-variable-use.patch
queue-4.4/drm-nouveau-hide-gcc-4.9-wmaybe-uninitialized.patch
queue-4.4/dell-wmi-dell-laptop-depends-dmi.patch
queue-4.4/x86-add-multiuser-dependency-for-kvm.patch
queue-4.4/md-avoid-warning-for-32-bit-sector_t.patch
queue-4.4/isdn-eicon-reduce-stack-size-of-sig_ind-function.patch
This is a note to let you know that I've just added the patch titled
vmxnet3: prevent building with 64K pages
to the 4.4-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:
vmxnet3-prevent-building-with-64k-pages.patch
and it can be found in the queue-4.4 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 fbdf0e28d061708cf18ba0f8e0db5360dc9a15b9 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Fri, 17 Feb 2017 16:08:30 +0100
Subject: vmxnet3: prevent building with 64K pages
From: Arnd Bergmann <arnd(a)arndb.de>
commit fbdf0e28d061708cf18ba0f8e0db5360dc9a15b9 upstream.
I got a warning about broken code on ARM64 with 64K pages:
drivers/net/vmxnet3/vmxnet3_drv.c: In function 'vmxnet3_rq_init':
drivers/net/vmxnet3/vmxnet3_drv.c:1679:29: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
rq->buf_info[0][i].len = PAGE_SIZE;
'len' here is a 16-bit integer, so this clearly won't work. I don't think
this driver is used much on anything other than x86, so there is no need
to fix this properly and we can work around it with a Kconfig dependency
to forbid known-broken configurations. qemu in theory supports it on
other architectures too, but presumably only for compatibility with x86
guests that also run on vmware.
CONFIG_PAGE_SIZE_64KB is used on hexagon, mips, sh and tile, the other
symbols are architecture-specific names for the same thing.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/Kconfig | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -411,6 +411,9 @@ config XEN_NETDEV_BACKEND
config VMXNET3
tristate "VMware VMXNET3 ethernet driver"
depends on PCI && INET
+ depends on !(PAGE_SIZE_64KB || ARM64_64K_PAGES || \
+ IA64_PAGE_SIZE_64KB || MICROBLAZE_64K_PAGES || \
+ PARISC_PAGE_SIZE_64KB || PPC_64K_PAGES)
help
This driver supports VMware's vmxnet3 virtual ethernet NIC.
To compile this driver as a module, choose M here: the
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/kasan-rework-kconfig-settings.patch
queue-4.4/hdpvr-hide-unused-variable.patch
queue-4.4/mtd-ichxrom-maybe-uninitialized-with-gcc-4.9.patch
queue-4.4/profile-hide-unused-functions-when-config_proc_fs.patch
queue-4.4/perf-x86-shut-up-false-positive-wmaybe-uninitialized-warning.patch
queue-4.4/hwrng-exynos-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-cdc_subset-only-build-when-one-driver-is-enabled.patch
queue-4.4/ipv4-ipconfig-avoid-unused-ic_proto_used-symbol.patch
queue-4.4/revert-power-bq27xxx_battery-remove-unneeded-dependency-in-kconfig.patch
queue-4.4/go7007-add-media_camera_support-dependency.patch
queue-4.4/scsi-advansys-fix-build-warning-for-pci-n.patch
queue-4.4/ssb-mark-ssb_bus_register-as-__maybe_unused.patch
queue-4.4/tty-cyclades-cyz_interrupt-is-only-used-for-pci.patch
queue-4.4/infiniband-cxgb4-use-pr-format-string-for-printing-resources.patch
queue-4.4/video-fbdev-via-remove-possibly-unused-variables.patch
queue-4.4/binfmt_elf-compat-avoid-unused-function-warning.patch
queue-4.4/drm-gma500-remove-helper-function.patch
queue-4.4/fbdev-s6e8ax0-avoid-unused-function-warnings.patch
queue-4.4/netfilter-ipvs-avoid-unused-variable-warnings.patch
queue-4.4/idle-i7300-add-pci-dependency.patch
queue-4.4/b2c2-flexcop-avoid-unused-function-warnings.patch
queue-4.4/fbdev-auo_k190x-avoid-unused-function-warnings.patch
queue-4.4/cw1200-fix-bogus-maybe-uninitialized-warning.patch
queue-4.4/x86-build-silence-the-build-with-make-s.patch
queue-4.4/gpio-xgene-mark-pm-functions-as-__maybe_unused.patch
queue-4.4/kvm-add-x86_local_apic-dependency.patch
queue-4.4/arm-tegra-select-usb_ulpi-from-ehci-rather-than-platform.patch
queue-4.4/asoc-mediatek-add-i2c-dependency.patch
queue-4.4/reiserfs-avoid-a-wmaybe-uninitialized-warning.patch
queue-4.4/scsi-advansys-fix-uninitialized-data-access.patch
queue-4.4/mtd-sh_flctl-pass-fifo-as-physical-address.patch
queue-4.4/driver-core-use-dev-argument-in-dev_dbg_ratelimited-stub.patch
queue-4.4/modsign-hide-openssl-output-in-silent-builds.patch
queue-4.4/net-hp100-remove-unnecessary-ifdefs.patch
queue-4.4/genirq-msi-add-stubs-for-get_cached_msi_msg-pci_write_msi_msg.patch
queue-4.4/asoc-intel-kconfig-fix-build-when-acpi-is-not-enabled.patch
queue-4.4/asoc-ux500-add-module_license-tag.patch
queue-4.4/wireless-cw1200-use-__maybe_unused-to-hide-pm-functions_.patch
queue-4.4/mptfusion-hide-unused-seq_mpt_print_ioc_summary-function.patch
queue-4.4/tlan-avoid-unused-label-with-pci-n.patch
queue-4.4/usb-musb-ux500-remove-duplicate-check-for-dma_is_compatible.patch
queue-4.4/mtd-cfi-enforce-valid-geometry-configuration.patch
queue-4.4/thermal-spear-use-__maybe_unused-for-pm-functions.patch
queue-4.4/x86-microcode-amd-change-load_microcode_amd-s-param-to-bool-to-fix-preemptibility-bug.patch
queue-4.4/video-fbdev-mmp-add-module_license.patch
queue-4.4/fbdev-sis-enforce-selection-of-at-least-one-backend.patch
queue-4.4/x86-boot-avoid-warning-for-zero-filling-.bss.patch
queue-4.4/power-bq27xxx_battery-mark-some-symbols-__maybe_unused.patch
queue-4.4/scsi-mvumi-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-phy-msm-add-regulator-dependency.patch
queue-4.4/isdn-icn-remove-a-warning.patch
queue-4.4/ncr5380-shut-up-gcc-indentation-warning.patch
queue-4.4/arm64-dts-add-cooling-cells-to-cpu-nodes.patch
queue-4.4/vmxnet3-prevent-building-with-64k-pages.patch
queue-4.4/genksyms-fix-segfault-with-invalid-declarations.patch
queue-4.4/x86-platform-add-pci-dependency-for-punit_atom_debug.patch
queue-4.4/target-user-fix-cast-from-pointer-to-phys_addr_t.patch
queue-4.4/rtlwifi-fix-gcc-6-indentation-warning.patch
queue-4.4/alsa-hda-ca0132-fix-possible-null-pointer-use.patch
queue-4.4/thermal-fix-intel_soc_dts_iosf_core-dependencies.patch
queue-4.4/arm64-define-bug-instruction-without-config_bug.patch
queue-4.4/v4l-remove-media_tuner-dependency-for-video_tuner.patch
queue-4.4/tc358743-fix-register-i2c_rd-wr-functions.patch
queue-4.4/scsi-fdomain-drop-fdomain_pci_tbl-when-built-in.patch
queue-4.4/scsi-initio-remove-duplicate-module-device-table.patch
queue-4.4/netlink-fix-nla_put_-u8-u16-u32-for-kasan.patch
queue-4.4/x86-fpu-math-emu-fix-possible-uninitialized-variable-use.patch
queue-4.4/asoc-rockchip-use-__maybe_unused-to-hide-st_irq_syscfg_resume.patch
queue-4.4/staging-ste_rmi4-avoid-unused-function-warnings.patch
queue-4.4/em28xx-only-use-mt9v011-if-camera-support-is-enabled.patch
queue-4.4/pwc-hide-unused-label.patch
queue-4.4/input-tca8418_keypad-hide-gcc-4.9-wmaybe-uninitialized-warning.patch
queue-4.4/fbdev-sm712fb-avoid-unused-function-warnings.patch
queue-4.4/isdn-sc-work-around-type-mismatch-warning.patch
queue-4.4/tty-hvc_xen-hide-xen_console_remove-when-unused.patch
queue-4.4/virtio_balloon-prevent-uninitialized-variable-use.patch
queue-4.4/drm-nouveau-hide-gcc-4.9-wmaybe-uninitialized.patch
queue-4.4/dell-wmi-dell-laptop-depends-dmi.patch
queue-4.4/x86-add-multiuser-dependency-for-kvm.patch
queue-4.4/md-avoid-warning-for-32-bit-sector_t.patch
queue-4.4/isdn-eicon-reduce-stack-size-of-sig_ind-function.patch
This is a note to let you know that I've just added the patch titled
virtio_balloon: prevent uninitialized variable use
to the 4.4-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:
virtio_balloon-prevent-uninitialized-variable-use.patch
and it can be found in the queue-4.4 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 f0bb2d50dfcc519f06f901aac88502be6ff1df2c Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 28 Mar 2017 18:46:59 +0200
Subject: virtio_balloon: prevent uninitialized variable use
From: Arnd Bergmann <arnd(a)arndb.de>
commit f0bb2d50dfcc519f06f901aac88502be6ff1df2c upstream.
The latest gcc-7.0.1 snapshot reports a new warning:
virtio/virtio_balloon.c: In function 'update_balloon_stats':
virtio/virtio_balloon.c:258:26: error: 'events[2]' is used uninitialized in this function [-Werror=uninitialized]
virtio/virtio_balloon.c:260:26: error: 'events[3]' is used uninitialized in this function [-Werror=uninitialized]
virtio/virtio_balloon.c:261:56: error: 'events[18]' is used uninitialized in this function [-Werror=uninitialized]
virtio/virtio_balloon.c:262:56: error: 'events[17]' is used uninitialized in this function [-Werror=uninitialized]
This seems absolutely right, so we should add an extra check to
prevent copying uninitialized stack data into the statistics.
>From all I can tell, this has been broken since the statistics code
was originally added in 2.6.34.
Fixes: 9564e138b1f6 ("virtio: Add memory statistics reporting to the balloon driver (V4)")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Ladi Prosek <lprosek(a)redhat.com>
Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/virtio/virtio_balloon.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -239,12 +239,14 @@ static void update_balloon_stats(struct
all_vm_events(events);
si_meminfo(&i);
+#ifdef CONFIG_VM_EVENT_COUNTERS
update_stat(vb, idx++, VIRTIO_BALLOON_S_SWAP_IN,
pages_to_bytes(events[PSWPIN]));
update_stat(vb, idx++, VIRTIO_BALLOON_S_SWAP_OUT,
pages_to_bytes(events[PSWPOUT]));
update_stat(vb, idx++, VIRTIO_BALLOON_S_MAJFLT, events[PGMAJFAULT]);
update_stat(vb, idx++, VIRTIO_BALLOON_S_MINFLT, events[PGFAULT]);
+#endif
update_stat(vb, idx++, VIRTIO_BALLOON_S_MEMFREE,
pages_to_bytes(i.freeram));
update_stat(vb, idx++, VIRTIO_BALLOON_S_MEMTOT,
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/kasan-rework-kconfig-settings.patch
queue-4.4/hdpvr-hide-unused-variable.patch
queue-4.4/mtd-ichxrom-maybe-uninitialized-with-gcc-4.9.patch
queue-4.4/profile-hide-unused-functions-when-config_proc_fs.patch
queue-4.4/perf-x86-shut-up-false-positive-wmaybe-uninitialized-warning.patch
queue-4.4/hwrng-exynos-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-cdc_subset-only-build-when-one-driver-is-enabled.patch
queue-4.4/ipv4-ipconfig-avoid-unused-ic_proto_used-symbol.patch
queue-4.4/revert-power-bq27xxx_battery-remove-unneeded-dependency-in-kconfig.patch
queue-4.4/go7007-add-media_camera_support-dependency.patch
queue-4.4/scsi-advansys-fix-build-warning-for-pci-n.patch
queue-4.4/ssb-mark-ssb_bus_register-as-__maybe_unused.patch
queue-4.4/tty-cyclades-cyz_interrupt-is-only-used-for-pci.patch
queue-4.4/infiniband-cxgb4-use-pr-format-string-for-printing-resources.patch
queue-4.4/video-fbdev-via-remove-possibly-unused-variables.patch
queue-4.4/binfmt_elf-compat-avoid-unused-function-warning.patch
queue-4.4/drm-gma500-remove-helper-function.patch
queue-4.4/fbdev-s6e8ax0-avoid-unused-function-warnings.patch
queue-4.4/netfilter-ipvs-avoid-unused-variable-warnings.patch
queue-4.4/idle-i7300-add-pci-dependency.patch
queue-4.4/b2c2-flexcop-avoid-unused-function-warnings.patch
queue-4.4/fbdev-auo_k190x-avoid-unused-function-warnings.patch
queue-4.4/cw1200-fix-bogus-maybe-uninitialized-warning.patch
queue-4.4/x86-build-silence-the-build-with-make-s.patch
queue-4.4/gpio-xgene-mark-pm-functions-as-__maybe_unused.patch
queue-4.4/kvm-add-x86_local_apic-dependency.patch
queue-4.4/arm-tegra-select-usb_ulpi-from-ehci-rather-than-platform.patch
queue-4.4/asoc-mediatek-add-i2c-dependency.patch
queue-4.4/reiserfs-avoid-a-wmaybe-uninitialized-warning.patch
queue-4.4/scsi-advansys-fix-uninitialized-data-access.patch
queue-4.4/mtd-sh_flctl-pass-fifo-as-physical-address.patch
queue-4.4/driver-core-use-dev-argument-in-dev_dbg_ratelimited-stub.patch
queue-4.4/modsign-hide-openssl-output-in-silent-builds.patch
queue-4.4/net-hp100-remove-unnecessary-ifdefs.patch
queue-4.4/genirq-msi-add-stubs-for-get_cached_msi_msg-pci_write_msi_msg.patch
queue-4.4/asoc-intel-kconfig-fix-build-when-acpi-is-not-enabled.patch
queue-4.4/asoc-ux500-add-module_license-tag.patch
queue-4.4/wireless-cw1200-use-__maybe_unused-to-hide-pm-functions_.patch
queue-4.4/mptfusion-hide-unused-seq_mpt_print_ioc_summary-function.patch
queue-4.4/tlan-avoid-unused-label-with-pci-n.patch
queue-4.4/usb-musb-ux500-remove-duplicate-check-for-dma_is_compatible.patch
queue-4.4/mtd-cfi-enforce-valid-geometry-configuration.patch
queue-4.4/thermal-spear-use-__maybe_unused-for-pm-functions.patch
queue-4.4/x86-microcode-amd-change-load_microcode_amd-s-param-to-bool-to-fix-preemptibility-bug.patch
queue-4.4/video-fbdev-mmp-add-module_license.patch
queue-4.4/fbdev-sis-enforce-selection-of-at-least-one-backend.patch
queue-4.4/x86-boot-avoid-warning-for-zero-filling-.bss.patch
queue-4.4/power-bq27xxx_battery-mark-some-symbols-__maybe_unused.patch
queue-4.4/scsi-mvumi-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-phy-msm-add-regulator-dependency.patch
queue-4.4/isdn-icn-remove-a-warning.patch
queue-4.4/ncr5380-shut-up-gcc-indentation-warning.patch
queue-4.4/arm64-dts-add-cooling-cells-to-cpu-nodes.patch
queue-4.4/vmxnet3-prevent-building-with-64k-pages.patch
queue-4.4/genksyms-fix-segfault-with-invalid-declarations.patch
queue-4.4/x86-platform-add-pci-dependency-for-punit_atom_debug.patch
queue-4.4/target-user-fix-cast-from-pointer-to-phys_addr_t.patch
queue-4.4/rtlwifi-fix-gcc-6-indentation-warning.patch
queue-4.4/alsa-hda-ca0132-fix-possible-null-pointer-use.patch
queue-4.4/thermal-fix-intel_soc_dts_iosf_core-dependencies.patch
queue-4.4/arm64-define-bug-instruction-without-config_bug.patch
queue-4.4/v4l-remove-media_tuner-dependency-for-video_tuner.patch
queue-4.4/tc358743-fix-register-i2c_rd-wr-functions.patch
queue-4.4/scsi-fdomain-drop-fdomain_pci_tbl-when-built-in.patch
queue-4.4/scsi-initio-remove-duplicate-module-device-table.patch
queue-4.4/netlink-fix-nla_put_-u8-u16-u32-for-kasan.patch
queue-4.4/x86-fpu-math-emu-fix-possible-uninitialized-variable-use.patch
queue-4.4/asoc-rockchip-use-__maybe_unused-to-hide-st_irq_syscfg_resume.patch
queue-4.4/staging-ste_rmi4-avoid-unused-function-warnings.patch
queue-4.4/em28xx-only-use-mt9v011-if-camera-support-is-enabled.patch
queue-4.4/pwc-hide-unused-label.patch
queue-4.4/input-tca8418_keypad-hide-gcc-4.9-wmaybe-uninitialized-warning.patch
queue-4.4/fbdev-sm712fb-avoid-unused-function-warnings.patch
queue-4.4/isdn-sc-work-around-type-mismatch-warning.patch
queue-4.4/tty-hvc_xen-hide-xen_console_remove-when-unused.patch
queue-4.4/virtio_balloon-prevent-uninitialized-variable-use.patch
queue-4.4/drm-nouveau-hide-gcc-4.9-wmaybe-uninitialized.patch
queue-4.4/dell-wmi-dell-laptop-depends-dmi.patch
queue-4.4/x86-add-multiuser-dependency-for-kvm.patch
queue-4.4/md-avoid-warning-for-32-bit-sector_t.patch
queue-4.4/isdn-eicon-reduce-stack-size-of-sig_ind-function.patch
This is a note to let you know that I've just added the patch titled
video: Use bool instead int pointer for get_opt_bool() argument
to the 4.4-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:
video-use-bool-instead-int-pointer-for-get_opt_bool-argument.patch
and it can be found in the queue-4.4 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 206fc20598157ce15597822cf01b94377e30075b Mon Sep 17 00:00:00 2001
From: Daniel Wagner <daniel.wagner(a)bmw-carit.de>
Date: Tue, 9 Feb 2016 10:18:32 +0100
Subject: video: Use bool instead int pointer for get_opt_bool() argument
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Daniel Wagner <daniel.wagner(a)bmw-carit.de>
commit 206fc20598157ce15597822cf01b94377e30075b upstream.
As the function name already indicates that get_opt_bool() parses
for a bool. It is not a surprise that compiler is complaining
about it when -Werror=incompatible-pointer-types is used:
drivers/video/fbdev/intelfb/intelfbdrv.c: In function ‘intelfb_setup’:
drivers/video/fbdev/intelfb/intelfbdrv.c:353:39: error: passing argument 3 of ‘get_opt_bool’ from incompatible pointer type [-Werror=incompatible-pointer-types]
if (get_opt_bool(this_opt, "accel", &accel))
Signed-off-by: Daniel Wagner <daniel.wagner(a)bmw-carit.de>
Reported-by: Fengguang Wu <fengguang.wu(a)intel.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/fbdev/intelfb/intelfbdrv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/video/fbdev/intelfb/intelfbdrv.c
+++ b/drivers/video/fbdev/intelfb/intelfbdrv.c
@@ -302,7 +302,7 @@ static __inline__ int get_opt_int(const
}
static __inline__ int get_opt_bool(const char *this_opt, const char *name,
- int *ret)
+ bool *ret)
{
if (!ret)
return 0;
Patches currently in stable-queue which might be from daniel.wagner(a)bmw-carit.de are
queue-4.4/video-use-bool-instead-int-pointer-for-get_opt_bool-argument.patch
This is a note to let you know that I've just added the patch titled
video: fbdev: sis: remove unused variable
to the 4.4-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:
video-fbdev-sis-remove-unused-variable.patch
and it can be found in the queue-4.4 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 32ad61951574d011d363694d6037592e99da9421 Mon Sep 17 00:00:00 2001
From: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com>
Date: Mon, 29 Feb 2016 23:32:29 +0530
Subject: video: fbdev: sis: remove unused variable
From: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com>
commit 32ad61951574d011d363694d6037592e99da9421 upstream.
The variables modeflag and resinfo were only assigned some value but
were never used.
Signed-off-by: Sudip Mukherjee <sudip.mukherjee(a)codethink.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/fbdev/sis/init301.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
--- a/drivers/video/fbdev/sis/init301.c
+++ b/drivers/video/fbdev/sis/init301.c
@@ -2151,17 +2151,15 @@ SiS_GetVCLK2Ptr(struct SiS_Private *SiS_
unsigned short RefreshRateTableIndex)
{
unsigned short CRT2Index, VCLKIndex = 0, VCLKIndexGEN = 0, VCLKIndexGENCRT = 0;
- unsigned short modeflag, resinfo, tempbx;
+ unsigned short resinfo, tempbx;
const unsigned char *CHTVVCLKPtr = NULL;
if(ModeNo <= 0x13) {
- modeflag = SiS_Pr->SiS_SModeIDTable[ModeIdIndex].St_ModeFlag;
resinfo = SiS_Pr->SiS_SModeIDTable[ModeIdIndex].St_ResInfo;
CRT2Index = SiS_Pr->SiS_SModeIDTable[ModeIdIndex].St_CRT2CRTC;
VCLKIndexGEN = (SiS_GetRegByte((SiS_Pr->SiS_P3ca+0x02)) >> 2) & 0x03;
VCLKIndexGENCRT = VCLKIndexGEN;
} else {
- modeflag = SiS_Pr->SiS_EModeIDTable[ModeIdIndex].Ext_ModeFlag;
resinfo = SiS_Pr->SiS_EModeIDTable[ModeIdIndex].Ext_RESINFO;
CRT2Index = SiS_Pr->SiS_RefIndex[RefreshRateTableIndex].Ext_CRT2CRTC;
VCLKIndexGEN = SiS_Pr->SiS_RefIndex[RefreshRateTableIndex].Ext_CRTVCLK;
@@ -7270,7 +7268,7 @@ SiS_ShiftXPos(struct SiS_Private *SiS_Pr
static void
SiS_SetGroup4_C_ELV(struct SiS_Private *SiS_Pr, unsigned short ModeNo, unsigned short ModeIdIndex)
{
- unsigned short temp, temp1, resinfo = 0;
+ unsigned short temp, temp1;
unsigned char *ROMAddr = SiS_Pr->VirtualRomBase;
if(!(SiS_Pr->SiS_VBType & VB_SIS30xCLV)) return;
@@ -7282,10 +7280,6 @@ SiS_SetGroup4_C_ELV(struct SiS_Private *
if(!(ROMAddr[0x61] & 0x04)) return;
}
- if(ModeNo > 0x13) {
- resinfo = SiS_Pr->SiS_EModeIDTable[ModeIdIndex].Ext_RESINFO;
- }
-
SiS_SetRegOR(SiS_Pr->SiS_Part4Port,0x3a,0x08);
temp = SiS_GetReg(SiS_Pr->SiS_Part4Port,0x3a);
if(!(temp & 0x01)) {
Patches currently in stable-queue which might be from sudipm.mukherjee(a)gmail.com are
queue-4.4/kasan-rework-kconfig-settings.patch
queue-4.4/drivers-hv-vmbus-fix-build-warning.patch
queue-4.4/video-fbdev-sis-remove-unused-variable.patch
queue-4.4/drm-gma500-remove-helper-function.patch
queue-4.4/dpt_i2o-fix-build-warning.patch
queue-4.4/scsi-sim710-fix-build-warning.patch
This is a note to let you know that I've just added the patch titled
[media] v4l: remove MEDIA_TUNER dependency for VIDEO_TUNER
to the 4.4-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-remove-media_tuner-dependency-for-video_tuner.patch
and it can be found in the queue-4.4 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 7c8fe516bd81d991feb73ccd969ec29850af3013 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 26 Jan 2016 19:46:02 -0200
Subject: [media] v4l: remove MEDIA_TUNER dependency for VIDEO_TUNER
From: Arnd Bergmann <arnd(a)arndb.de>
commit 7c8fe516bd81d991feb73ccd969ec29850af3013 upstream.
em28xx selects VIDEO_TUNER, which has a dependency on MEDIA_TUNER,
so we get a Kconfig warning if that is disabled:
warning: (VIDEO_PVRUSB2 && VIDEO_USBVISION && VIDEO_GO7007 && VIDEO_AU0828_V4L2 && VIDEO_CX231XX && VIDEO_TM6000 && VIDEO_EM28XX && VIDEO_IVTV && VIDEO_MXB && VIDEO_CX18 && VIDEO_CX23885 && VIDEO_CX88 && VIDEO_BT848 && VIDEO_SAA7134 && VIDEO_SAA7164) selects VIDEO_TUNER which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_TUNER)
VIDEO_TUNER does not actually depend on MEDIA_TUNER, and the
dependency does nothing except cause the above warning, so let's
remove it.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/v4l2-core/Kconfig | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -37,7 +37,6 @@ config VIDEO_PCI_SKELETON
# Used by drivers that need tuner.ko
config VIDEO_TUNER
tristate
- depends on MEDIA_TUNER
# Used by drivers that need v4l2-mem2mem.ko
config V4L2_MEM2MEM_DEV
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/kasan-rework-kconfig-settings.patch
queue-4.4/hdpvr-hide-unused-variable.patch
queue-4.4/mtd-ichxrom-maybe-uninitialized-with-gcc-4.9.patch
queue-4.4/profile-hide-unused-functions-when-config_proc_fs.patch
queue-4.4/perf-x86-shut-up-false-positive-wmaybe-uninitialized-warning.patch
queue-4.4/hwrng-exynos-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-cdc_subset-only-build-when-one-driver-is-enabled.patch
queue-4.4/ipv4-ipconfig-avoid-unused-ic_proto_used-symbol.patch
queue-4.4/revert-power-bq27xxx_battery-remove-unneeded-dependency-in-kconfig.patch
queue-4.4/go7007-add-media_camera_support-dependency.patch
queue-4.4/scsi-advansys-fix-build-warning-for-pci-n.patch
queue-4.4/ssb-mark-ssb_bus_register-as-__maybe_unused.patch
queue-4.4/tty-cyclades-cyz_interrupt-is-only-used-for-pci.patch
queue-4.4/infiniband-cxgb4-use-pr-format-string-for-printing-resources.patch
queue-4.4/video-fbdev-via-remove-possibly-unused-variables.patch
queue-4.4/binfmt_elf-compat-avoid-unused-function-warning.patch
queue-4.4/drm-gma500-remove-helper-function.patch
queue-4.4/fbdev-s6e8ax0-avoid-unused-function-warnings.patch
queue-4.4/netfilter-ipvs-avoid-unused-variable-warnings.patch
queue-4.4/idle-i7300-add-pci-dependency.patch
queue-4.4/b2c2-flexcop-avoid-unused-function-warnings.patch
queue-4.4/fbdev-auo_k190x-avoid-unused-function-warnings.patch
queue-4.4/cw1200-fix-bogus-maybe-uninitialized-warning.patch
queue-4.4/x86-build-silence-the-build-with-make-s.patch
queue-4.4/gpio-xgene-mark-pm-functions-as-__maybe_unused.patch
queue-4.4/kvm-add-x86_local_apic-dependency.patch
queue-4.4/arm-tegra-select-usb_ulpi-from-ehci-rather-than-platform.patch
queue-4.4/asoc-mediatek-add-i2c-dependency.patch
queue-4.4/reiserfs-avoid-a-wmaybe-uninitialized-warning.patch
queue-4.4/scsi-advansys-fix-uninitialized-data-access.patch
queue-4.4/mtd-sh_flctl-pass-fifo-as-physical-address.patch
queue-4.4/driver-core-use-dev-argument-in-dev_dbg_ratelimited-stub.patch
queue-4.4/modsign-hide-openssl-output-in-silent-builds.patch
queue-4.4/net-hp100-remove-unnecessary-ifdefs.patch
queue-4.4/genirq-msi-add-stubs-for-get_cached_msi_msg-pci_write_msi_msg.patch
queue-4.4/asoc-intel-kconfig-fix-build-when-acpi-is-not-enabled.patch
queue-4.4/asoc-ux500-add-module_license-tag.patch
queue-4.4/wireless-cw1200-use-__maybe_unused-to-hide-pm-functions_.patch
queue-4.4/mptfusion-hide-unused-seq_mpt_print_ioc_summary-function.patch
queue-4.4/tlan-avoid-unused-label-with-pci-n.patch
queue-4.4/usb-musb-ux500-remove-duplicate-check-for-dma_is_compatible.patch
queue-4.4/mtd-cfi-enforce-valid-geometry-configuration.patch
queue-4.4/thermal-spear-use-__maybe_unused-for-pm-functions.patch
queue-4.4/x86-microcode-amd-change-load_microcode_amd-s-param-to-bool-to-fix-preemptibility-bug.patch
queue-4.4/video-fbdev-mmp-add-module_license.patch
queue-4.4/fbdev-sis-enforce-selection-of-at-least-one-backend.patch
queue-4.4/x86-boot-avoid-warning-for-zero-filling-.bss.patch
queue-4.4/power-bq27xxx_battery-mark-some-symbols-__maybe_unused.patch
queue-4.4/scsi-mvumi-use-__maybe_unused-to-hide-pm-functions.patch
queue-4.4/usb-phy-msm-add-regulator-dependency.patch
queue-4.4/isdn-icn-remove-a-warning.patch
queue-4.4/ncr5380-shut-up-gcc-indentation-warning.patch
queue-4.4/arm64-dts-add-cooling-cells-to-cpu-nodes.patch
queue-4.4/vmxnet3-prevent-building-with-64k-pages.patch
queue-4.4/genksyms-fix-segfault-with-invalid-declarations.patch
queue-4.4/x86-platform-add-pci-dependency-for-punit_atom_debug.patch
queue-4.4/target-user-fix-cast-from-pointer-to-phys_addr_t.patch
queue-4.4/rtlwifi-fix-gcc-6-indentation-warning.patch
queue-4.4/alsa-hda-ca0132-fix-possible-null-pointer-use.patch
queue-4.4/thermal-fix-intel_soc_dts_iosf_core-dependencies.patch
queue-4.4/arm64-define-bug-instruction-without-config_bug.patch
queue-4.4/v4l-remove-media_tuner-dependency-for-video_tuner.patch
queue-4.4/tc358743-fix-register-i2c_rd-wr-functions.patch
queue-4.4/scsi-fdomain-drop-fdomain_pci_tbl-when-built-in.patch
queue-4.4/scsi-initio-remove-duplicate-module-device-table.patch
queue-4.4/netlink-fix-nla_put_-u8-u16-u32-for-kasan.patch
queue-4.4/x86-fpu-math-emu-fix-possible-uninitialized-variable-use.patch
queue-4.4/asoc-rockchip-use-__maybe_unused-to-hide-st_irq_syscfg_resume.patch
queue-4.4/staging-ste_rmi4-avoid-unused-function-warnings.patch
queue-4.4/em28xx-only-use-mt9v011-if-camera-support-is-enabled.patch
queue-4.4/pwc-hide-unused-label.patch
queue-4.4/input-tca8418_keypad-hide-gcc-4.9-wmaybe-uninitialized-warning.patch
queue-4.4/fbdev-sm712fb-avoid-unused-function-warnings.patch
queue-4.4/isdn-sc-work-around-type-mismatch-warning.patch
queue-4.4/tty-hvc_xen-hide-xen_console_remove-when-unused.patch
queue-4.4/virtio_balloon-prevent-uninitialized-variable-use.patch
queue-4.4/drm-nouveau-hide-gcc-4.9-wmaybe-uninitialized.patch
queue-4.4/dell-wmi-dell-laptop-depends-dmi.patch
queue-4.4/x86-add-multiuser-dependency-for-kvm.patch
queue-4.4/md-avoid-warning-for-32-bit-sector_t.patch
queue-4.4/isdn-eicon-reduce-stack-size-of-sig_ind-function.patch