* [ 01/16] x86/reboot: Add quirk to make Dell C6100 use reboot=pci automatically
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
@ 2013-10-03 4:05 ` Greg Kroah-Hartman
2013-10-03 4:05 ` [ 02/16] x86, efi: Dont map Boot Services on i386 Greg Kroah-Hartman
` (17 subsequent siblings)
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 4:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Masoud Sharbiani, Vinson Lee,
Robin Holt, Russell King, Guan Xuetao, Ingo Molnar
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Masoud Sharbiani <msharbiani@twitter.com>
commit 4f0acd31c31f03ba42494c8baf6c0465150e2621 upstream.
Dell PowerEdge C6100 machines fail to completely reboot about 20% of the time.
Signed-off-by: Masoud Sharbiani <msharbiani@twitter.com>
Signed-off-by: Vinson Lee <vlee@twitter.com>
Cc: Robin Holt <holt@sgi.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
Link: http://lkml.kernel.org/r/1379717947-18042-1-git-send-email-vlee@freedesktop.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/reboot.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -479,6 +479,22 @@ static struct dmi_system_id __initdata p
DMI_MATCH(DMI_PRODUCT_NAME, "Precision M6600"),
},
},
+ { /* Handle problems with rebooting on the Dell PowerEdge C6100. */
+ .callback = set_pci_reboot,
+ .ident = "Dell PowerEdge C6100",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "C6100"),
+ },
+ },
+ { /* Some C6100 machines were shipped with vendor being 'Dell'. */
+ .callback = set_pci_reboot,
+ .ident = "Dell PowerEdge C6100",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "C6100"),
+ },
+ },
{ }
};
^ permalink raw reply [flat|nested] 23+ messages in thread* [ 02/16] x86, efi: Dont map Boot Services on i386
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
2013-10-03 4:05 ` [ 01/16] x86/reboot: Add quirk to make Dell C6100 use reboot=pci automatically Greg Kroah-Hartman
@ 2013-10-03 4:05 ` Greg Kroah-Hartman
2013-10-03 4:05 ` [ 03/16] staging: vt6656: [BUG] main_usb.c oops on device_close move flag earlier Greg Kroah-Hartman
` (16 subsequent siblings)
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 4:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bryan ODonoghue, Tom Zanussi,
Darren Hart, Josh Triplett, Matthew Garrett, H. Peter Anvin,
Ingo Molnar, Thomas Gleixner, Josh Boyer, Matt Fleming
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josh Boyer <jwboyer@redhat.com>
commit 700870119f49084da004ab588ea2b799689efaf7 upstream.
Add patch to fix 32bit EFI service mapping (rhbz 726701)
Multiple people are reporting hitting the following WARNING on i386,
WARNING: at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x3d3/0x440()
Modules linked in:
Pid: 0, comm: swapper Not tainted 3.9.0-rc7+ #95
Call Trace:
[<c102b6af>] warn_slowpath_common+0x5f/0x80
[<c1023fb3>] ? __ioremap_caller+0x3d3/0x440
[<c1023fb3>] ? __ioremap_caller+0x3d3/0x440
[<c102b6ed>] warn_slowpath_null+0x1d/0x20
[<c1023fb3>] __ioremap_caller+0x3d3/0x440
[<c106007b>] ? get_usage_chars+0xfb/0x110
[<c102d937>] ? vprintk_emit+0x147/0x480
[<c1418593>] ? efi_enter_virtual_mode+0x1e4/0x3de
[<c102406a>] ioremap_cache+0x1a/0x20
[<c1418593>] ? efi_enter_virtual_mode+0x1e4/0x3de
[<c1418593>] efi_enter_virtual_mode+0x1e4/0x3de
[<c1407984>] start_kernel+0x286/0x2f4
[<c1407535>] ? repair_env_string+0x51/0x51
[<c1407362>] i386_start_kernel+0x12c/0x12f
Due to the workaround described in commit 916f676f8 ("x86, efi: Retain
boot service code until after switching to virtual mode") EFI Boot
Service regions are mapped for a period during boot. Unfortunately, with
the limited size of the i386 direct kernel map it's possible that some
of the Boot Service regions will not be directly accessible, which
causes them to be ioremap()'d, triggering the above warning as the
regions are marked as E820_RAM in the e820 memmap.
There are currently only two situations where we need to map EFI Boot
Service regions,
1. To workaround the firmware bug described in 916f676f8
2. To access the ACPI BGRT image
but since we haven't seen an i386 implementation that requires either,
this simple fix should suffice for now.
[ Added to changelog - Matt ]
Reported-by: Bryan O'Donoghue <bryan.odonoghue.lkml@nexus-software.ie>
Acked-by: Tom Zanussi <tom.zanussi@intel.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/platform/efi/efi.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -845,10 +845,13 @@ void __init efi_enter_virtual_mode(void)
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
- if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
- md->type != EFI_BOOT_SERVICES_CODE &&
- md->type != EFI_BOOT_SERVICES_DATA)
- continue;
+ if (!(md->attribute & EFI_MEMORY_RUNTIME)) {
+#ifdef CONFIG_X86_64
+ if (md->type != EFI_BOOT_SERVICES_CODE &&
+ md->type != EFI_BOOT_SERVICES_DATA)
+#endif
+ continue;
+ }
size = md->num_pages << EFI_PAGE_SHIFT;
end = md->phys_addr + size;
^ permalink raw reply [flat|nested] 23+ messages in thread* [ 03/16] staging: vt6656: [BUG] main_usb.c oops on device_close move flag earlier.
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
2013-10-03 4:05 ` [ 01/16] x86/reboot: Add quirk to make Dell C6100 use reboot=pci automatically Greg Kroah-Hartman
2013-10-03 4:05 ` [ 02/16] x86, efi: Dont map Boot Services on i386 Greg Kroah-Hartman
@ 2013-10-03 4:05 ` Greg Kroah-Hartman
2013-10-03 4:05 ` [ 04/16] xhci: Ensure a command structure points to the correct trb on the command ring Greg Kroah-Hartman
` (15 subsequent siblings)
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 4:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Malcolm Priestley
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Malcolm Priestley <tvboxspy@gmail.com>
commit e3eb270fab7734427dd8171a93e4946fe28674bc upstream.
The vt6656 is prone to resetting on the usb bus.
It seems there is a race condition and wpa supplicant is
trying to open the device via iw_handlers before its actually
closed at a stage that the buffers are being removed.
The device is longer considered open when the
buffers are being removed. So move ~DEVICE_FLAGS_OPENED
flag to before freeing the device buffers.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/vt6656/main_usb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -1220,6 +1220,8 @@ device_release_WPADEV(pDevice);
memset(pMgmt->abyCurrBSSID, 0, 6);
pMgmt->eCurrState = WMAC_STATE_IDLE;
+ pDevice->flags &= ~DEVICE_FLAGS_OPENED;
+
device_free_tx_bufs(pDevice);
device_free_rx_bufs(pDevice);
device_free_int_bufs(pDevice);
@@ -1231,7 +1233,6 @@ device_release_WPADEV(pDevice);
usb_free_urb(pDevice->pInterruptURB);
BSSvClearNodeDBTable(pDevice, 0);
- pDevice->flags &=(~DEVICE_FLAGS_OPENED);
DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO "device_close2 \n");
^ permalink raw reply [flat|nested] 23+ messages in thread* [ 04/16] xhci: Ensure a command structure points to the correct trb on the command ring
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2013-10-03 4:05 ` [ 03/16] staging: vt6656: [BUG] main_usb.c oops on device_close move flag earlier Greg Kroah-Hartman
@ 2013-10-03 4:05 ` Greg Kroah-Hartman
2013-10-03 4:05 ` [ 05/16] xhci: Fix oops happening after address device timeout Greg Kroah-Hartman
` (14 subsequent siblings)
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 4:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mathias Nyman, Sarah Sharp
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <mathias.nyman@linux.intel.com>
commit ec7e43e2d98173483866fe2e4e690143626b659c upstream.
If a command on the command ring needs to be cancelled before it is handled
it can be turned to a no-op operation when the ring is stopped.
We want to store the command ring enqueue pointer in the command structure
when the command in enqueued for the cancellation case.
Some commands used to store the command ring dequeue pointers instead of enqueue
(these often worked because enqueue happends to equal dequeue quite often)
Other commands correctly used the enqueue pointer but did not check if it pointed
to a valid trb or a link trb, this caused for example stop endpoint command to timeout in
xhci_stop_device() in about 2% of suspend/resume cases.
This should also solve some weird behavior happening in command cancellation cases.
This patch is based on a patch submitted by Sarah Sharp to linux-usb, but
then forgotten:
http://marc.info/?l=linux-usb&m=136269803207465&w=2
This patch should be backported to kernels as old as 3.7, that contain
the commit b92cc66c047ff7cf587b318fe377061a353c120f "xHCI: add aborting
command ring function"
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-hub.c | 2 +-
drivers/usb/host/xhci-ring.c | 10 ++++++++++
drivers/usb/host/xhci.c | 25 +++++--------------------
drivers/usb/host/xhci.h | 1 +
4 files changed, 17 insertions(+), 21 deletions(-)
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -287,7 +287,7 @@ static int xhci_stop_device(struct xhci_
if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)
xhci_queue_stop_endpoint(xhci, slot_id, i, suspend);
}
- cmd->command_trb = xhci->cmd_ring->enqueue;
+ cmd->command_trb = xhci_find_next_enqueue(xhci->cmd_ring);
list_add_tail(&cmd->cmd_list, &virt_dev->cmd_list);
xhci_queue_stop_endpoint(xhci, slot_id, 0, suspend);
xhci_ring_cmd_db(xhci);
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -122,6 +122,16 @@ static int enqueue_is_link_trb(struct xh
return TRB_TYPE_LINK_LE32(link->control);
}
+union xhci_trb *xhci_find_next_enqueue(struct xhci_ring *ring)
+{
+ /* Enqueue pointer can be left pointing to the link TRB,
+ * we must handle that
+ */
+ if (TRB_TYPE_LINK_LE32(ring->enqueue->link.control))
+ return ring->enq_seg->next->trbs;
+ return ring->enqueue;
+}
+
/* Updates trb to point to the next TRB in the ring, and updates seg if the next
* TRB is in a new segment. This does not skip over link TRBs, and it does not
* effect the ring dequeue or enqueue pointers.
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2582,15 +2582,7 @@ static int xhci_configure_endpoint(struc
if (command) {
cmd_completion = command->completion;
cmd_status = &command->status;
- command->command_trb = xhci->cmd_ring->enqueue;
-
- /* Enqueue pointer can be left pointing to the link TRB,
- * we must handle that
- */
- if (TRB_TYPE_LINK_LE32(command->command_trb->link.control))
- command->command_trb =
- xhci->cmd_ring->enq_seg->next->trbs;
-
+ command->command_trb = xhci_find_next_enqueue(xhci->cmd_ring);
list_add_tail(&command->cmd_list, &virt_dev->cmd_list);
} else {
cmd_completion = &virt_dev->cmd_completion;
@@ -2598,7 +2590,7 @@ static int xhci_configure_endpoint(struc
}
init_completion(cmd_completion);
- cmd_trb = xhci->cmd_ring->dequeue;
+ cmd_trb = xhci_find_next_enqueue(xhci->cmd_ring);
if (!ctx_change)
ret = xhci_queue_configure_endpoint(xhci, in_ctx->dma,
udev->slot_id, must_succeed);
@@ -3383,14 +3375,7 @@ int xhci_discover_or_reset_device(struct
/* Attempt to submit the Reset Device command to the command ring */
spin_lock_irqsave(&xhci->lock, flags);
- reset_device_cmd->command_trb = xhci->cmd_ring->enqueue;
-
- /* Enqueue pointer can be left pointing to the link TRB,
- * we must handle that
- */
- if (TRB_TYPE_LINK_LE32(reset_device_cmd->command_trb->link.control))
- reset_device_cmd->command_trb =
- xhci->cmd_ring->enq_seg->next->trbs;
+ reset_device_cmd->command_trb = xhci_find_next_enqueue(xhci->cmd_ring);
list_add_tail(&reset_device_cmd->cmd_list, &virt_dev->cmd_list);
ret = xhci_queue_reset_device(xhci, slot_id);
@@ -3594,7 +3579,7 @@ int xhci_alloc_dev(struct usb_hcd *hcd,
union xhci_trb *cmd_trb;
spin_lock_irqsave(&xhci->lock, flags);
- cmd_trb = xhci->cmd_ring->dequeue;
+ cmd_trb = xhci_find_next_enqueue(xhci->cmd_ring);
ret = xhci_queue_slot_control(xhci, TRB_ENABLE_SLOT, 0);
if (ret) {
spin_unlock_irqrestore(&xhci->lock, flags);
@@ -3721,7 +3706,7 @@ int xhci_address_device(struct usb_hcd *
xhci_dbg_ctx(xhci, virt_dev->in_ctx, 2);
spin_lock_irqsave(&xhci->lock, flags);
- cmd_trb = xhci->cmd_ring->dequeue;
+ cmd_trb = xhci_find_next_enqueue(xhci->cmd_ring);
ret = xhci_queue_address_device(xhci, virt_dev->in_ctx->dma,
udev->slot_id);
if (ret) {
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1811,6 +1811,7 @@ int xhci_cancel_cmd(struct xhci_hcd *xhc
union xhci_trb *cmd_trb);
void xhci_ring_ep_doorbell(struct xhci_hcd *xhci, unsigned int slot_id,
unsigned int ep_index, unsigned int stream_id);
+union xhci_trb *xhci_find_next_enqueue(struct xhci_ring *ring);
/* xHCI roothub code */
void xhci_set_link_state(struct xhci_hcd *xhci, __le32 __iomem **port_array,
^ permalink raw reply [flat|nested] 23+ messages in thread* [ 05/16] xhci: Fix oops happening after address device timeout
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2013-10-03 4:05 ` [ 04/16] xhci: Ensure a command structure points to the correct trb on the command ring Greg Kroah-Hartman
@ 2013-10-03 4:05 ` Greg Kroah-Hartman
2013-10-03 4:05 ` [ 06/16] xhci: Fix race between ep halt and URB cancellation Greg Kroah-Hartman
` (13 subsequent siblings)
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 4:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mathias Nyman, Giovanni, Sarah Sharp
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <mathias.nyman@linux.intel.com>
commit 284d20552461466b04d6bfeafeb1c47a8891b591 upstream.
When a command times out, the command ring is first aborted,
and then stopped. If the command ring is empty when it is stopped
the stop event will point to next command which is not yet set.
xHCI tries to handle this next event often causing an oops.
Don't handle command completion events on stopped cmd ring if ring is
empty.
This patch should be backported to kernels as old as 3.7, that contain
the commit b92cc66c047ff7cf587b318fe377061a353c120f "xHCI: add aborting
command ring function"
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Reported-by: Giovanni <giovanni.nervi@yahoo.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-ring.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1400,6 +1400,12 @@ static void handle_cmd_completion(struct
inc_deq(xhci, xhci->cmd_ring);
return;
}
+ /* There is no command to handle if we get a stop event when the
+ * command ring is empty, event->cmd_trb points to the next
+ * unset command
+ */
+ if (xhci->cmd_ring->dequeue == xhci->cmd_ring->enqueue)
+ return;
}
switch (le32_to_cpu(xhci->cmd_ring->dequeue->generic.field[3])
^ permalink raw reply [flat|nested] 23+ messages in thread* [ 06/16] xhci: Fix race between ep halt and URB cancellation
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2013-10-03 4:05 ` [ 05/16] xhci: Fix oops happening after address device timeout Greg Kroah-Hartman
@ 2013-10-03 4:05 ` Greg Kroah-Hartman
2013-10-03 4:05 ` [ 07/16] usb/core/devio.c: Dont reject control message to endpoint with wrong direction bit Greg Kroah-Hartman
` (12 subsequent siblings)
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 4:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Florian Wolter, Sarah Sharp,
Jonghwan Choi
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Wolter <wolly84@web.de>
commit 526867c3ca0caa2e3e846cb993b0f961c33c2abb upstream.
The halted state of a endpoint cannot be cleared over CLEAR_HALT from a
user process, because the stopped_td variable was overwritten in the
handle_stopped_endpoint() function. So the xhci_endpoint_reset() function will
refuse the reset and communication with device can not run over this endpoint.
https://bugzilla.kernel.org/show_bug.cgi?id=60699
Signed-off-by: Florian Wolter <wolly84@web.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-ring.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -857,8 +857,12 @@ remove_finished_td:
/* Otherwise ring the doorbell(s) to restart queued transfers */
ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
}
- ep->stopped_td = NULL;
- ep->stopped_trb = NULL;
+
+ /* Clear stopped_td and stopped_trb if endpoint is not halted */
+ if (!(ep->ep_state & EP_HALTED)) {
+ ep->stopped_td = NULL;
+ ep->stopped_trb = NULL;
+ }
/*
* Drop the lock and complete the URBs in the cancelled TD list.
^ permalink raw reply [flat|nested] 23+ messages in thread* [ 07/16] usb/core/devio.c: Dont reject control message to endpoint with wrong direction bit
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2013-10-03 4:05 ` [ 06/16] xhci: Fix race between ep halt and URB cancellation Greg Kroah-Hartman
@ 2013-10-03 4:05 ` Greg Kroah-Hartman
2013-10-03 4:05 ` [ 08/16] dm snapshot: workaround for a false positive lockdep warning Greg Kroah-Hartman
` (11 subsequent siblings)
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 4:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Kurt Garloff, Alan Stern
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kurt Garloff <kurt@garloff.de>
commit 831abf76643555a99b80a3b54adfa7e4fa0a3259 upstream.
Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101)
[1] with the Windows App (EasyNote) works natively but fails when
Windows is running under KVM (and the USB device handed to KVM).
The reason is a USB control message
usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008
This goes to endpoint address 0x01 (wIndex); however, endpoint address
0x01 does not exist. There is an endpoint 0x81 though (same number,
but other direction); the app may have meant that endpoint instead.
The kernel thus rejects the IO and thus we see the failure.
Apparently, Linux is more strict here than Windows ... we can't change
the Win app easily, so that's a problem.
It seems that the Win app/driver is buggy here and the driver does not
behave fully according to the USB HID class spec that it claims to
belong to. The device seems to happily deal with that though (and
seems to not really care about this value much).
So the question is whether the Linux kernel should filter here.
Rejecting has the risk that somewhat non-compliant userspace apps/
drivers (most likely in a virtual machine) are prevented from working.
Not rejecting has the risk of confusing an overly sensitive device with
such a transfer. Given the fact that Windows does not filter it makes
this risk rather small though.
The patch makes the kernel more tolerant: If the endpoint address in
wIndex does not exist, but an endpoint with toggled direction bit does,
it will let the transfer through. (It does NOT change the message.)
With attached patch, the app in Windows in KVM works.
usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but needs 81
I suspect this will mostly affect apps in virtual environments; as on
Linux the apps would have been adapted to the stricter handling of the
kernel. I have done that for mine[2].
[1] http://www.pegatech.com/
[2] https://sourceforge.net/projects/notetakerpen/
Signed-off-by: Kurt Garloff <kurt@garloff.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/devio.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -684,6 +684,22 @@ static int check_ctrlrecip(struct dev_st
if ((index & ~USB_DIR_IN) == 0)
return 0;
ret = findintfep(ps->dev, index);
+ if (ret < 0) {
+ /*
+ * Some not fully compliant Win apps seem to get
+ * index wrong and have the endpoint number here
+ * rather than the endpoint address (with the
+ * correct direction). Win does let this through,
+ * so we'll not reject it here but leave it to
+ * the device to not break KVM. But we warn.
+ */
+ ret = findintfep(ps->dev, index ^ 0x80);
+ if (ret >= 0)
+ dev_info(&ps->dev->dev,
+ "%s: process %i (%s) requesting ep %02x but needs %02x\n",
+ __func__, task_pid_nr(current),
+ current->comm, index, index ^ 0x80);
+ }
if (ret >= 0)
ret = checkintf(ps, ret);
break;
^ permalink raw reply [flat|nested] 23+ messages in thread* [ 08/16] dm snapshot: workaround for a false positive lockdep warning
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2013-10-03 4:05 ` [ 07/16] usb/core/devio.c: Dont reject control message to endpoint with wrong direction bit Greg Kroah-Hartman
@ 2013-10-03 4:05 ` Greg Kroah-Hartman
2013-10-03 4:05 ` [ 09/16] dm-snapshot: fix performance degradation due to small hash size Greg Kroah-Hartman
` (10 subsequent siblings)
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 4:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Alasdair G Kergon,
Mike Snitzer
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <mpatocka@redhat.com>
commit 5ea330a75bd86b2b2a01d7b85c516983238306fb upstream.
The kernel reports a lockdep warning if a snapshot is invalidated because
it runs out of space.
The lockdep warning was triggered by commit 0976dfc1d0cd80a4e9dfaf87bd87
("workqueue: Catch more locking problems with flush_work()") in v3.5.
The warning is false positive. The real cause for the warning is that
the lockdep engine treats different instances of md->lock as a single
lock.
This patch is a workaround - we use flush_workqueue instead of flush_work.
This code path is not performance sensitive (it is called only on
initialization or invalidation), thus it doesn't matter that we flush the
whole workqueue.
The real fix for the problem would be to teach the lockdep engine to treat
different instances of md->lock as separate locks.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Acked-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-snap-persistent.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/md/dm-snap-persistent.c
+++ b/drivers/md/dm-snap-persistent.c
@@ -256,7 +256,7 @@ static int chunk_io(struct pstore *ps, v
*/
INIT_WORK_ONSTACK(&req.work, do_metadata);
queue_work(ps->metadata_wq, &req.work);
- flush_work(&req.work);
+ flush_workqueue(ps->metadata_wq);
return req.result;
}
^ permalink raw reply [flat|nested] 23+ messages in thread* [ 09/16] dm-snapshot: fix performance degradation due to small hash size
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2013-10-03 4:05 ` [ 08/16] dm snapshot: workaround for a false positive lockdep warning Greg Kroah-Hartman
@ 2013-10-03 4:05 ` Greg Kroah-Hartman
2013-10-03 4:05 ` [ 10/16] drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER Greg Kroah-Hartman
` (9 subsequent siblings)
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 4:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Mike Snitzer
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <mpatocka@redhat.com>
commit 60e356f381954d79088d0455e357db48cfdd6857 upstream.
LVM2, since version 2.02.96, creates origin with zero size, then loads
the snapshot driver and then loads the origin. Consequently, the
snapshot driver sees the origin size zero and sets the hash size to the
lower bound 64. Such small hash table causes performance degradation.
This patch changes it so that the hash size is determined by the size of
snapshot volume, not minimum of origin and snapshot size. It doesn't
make sense to set the snapshot size significantly larger than the origin
size, so we do not need to take origin size into account when
calculating the hash size.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-snap.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -721,17 +721,16 @@ static int calc_max_buckets(void)
*/
static int init_hash_tables(struct dm_snapshot *s)
{
- sector_t hash_size, cow_dev_size, origin_dev_size, max_buckets;
+ sector_t hash_size, cow_dev_size, max_buckets;
/*
* Calculate based on the size of the original volume or
* the COW volume...
*/
cow_dev_size = get_dev_size(s->cow->bdev);
- origin_dev_size = get_dev_size(s->origin->bdev);
max_buckets = calc_max_buckets();
- hash_size = min(origin_dev_size, cow_dev_size) >> s->store->chunk_shift;
+ hash_size = cow_dev_size >> s->store->chunk_shift;
hash_size = min(hash_size, max_buckets);
if (hash_size < 64)
^ permalink raw reply [flat|nested] 23+ messages in thread* [ 10/16] drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2013-10-03 4:05 ` [ 09/16] dm-snapshot: fix performance degradation due to small hash size Greg Kroah-Hartman
@ 2013-10-03 4:05 ` Greg Kroah-Hartman
2013-10-03 4:05 ` [ 11/16] drm/radeon: disable tests/benchmarks if accel is disabled Greg Kroah-Hartman
` (8 subsequent siblings)
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 4:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jani Nikula, Nicolas Suzor,
Todd Previte, Daniel Vetter
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jani Nikula <jani.nikula@intel.com>
commit 8d16f258217f2f583af1fd57c5144aa4bbe73e48 upstream.
There is no clear cut rules or specs for the retry interval, as there
are many factors that affect overall response time. Increase the
interval, and even more so on branch devices which may have limited i2c
bit rates.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=60263
Tested-by: Nicolas Suzor <nic@suzor.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_dp.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -625,7 +625,18 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *
DRM_DEBUG_KMS("aux_ch native nack\n");
return -EREMOTEIO;
case AUX_NATIVE_REPLY_DEFER:
- udelay(100);
+ /*
+ * For now, just give more slack to branch devices. We
+ * could check the DPCD for I2C bit rate capabilities,
+ * and if available, adjust the interval. We could also
+ * be more careful with DP-to-Legacy adapters where a
+ * long legacy cable may force very low I2C bit rates.
+ */
+ if (intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+ DP_DWN_STRM_PORT_PRESENT)
+ usleep_range(500, 600);
+ else
+ usleep_range(300, 400);
continue;
default:
DRM_ERROR("aux_ch invalid native reply 0x%02x\n",
^ permalink raw reply [flat|nested] 23+ messages in thread* [ 11/16] drm/radeon: disable tests/benchmarks if accel is disabled
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2013-10-03 4:05 ` [ 10/16] drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER Greg Kroah-Hartman
@ 2013-10-03 4:05 ` Greg Kroah-Hartman
2013-10-03 4:05 ` [ 12/16] hwmon: (applesmc) Check key count before proceeding Greg Kroah-Hartman
` (7 subsequent siblings)
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 4:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alex Deucher
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
commit 4a1132a023eb48cf10522d84c5908d43b612c041 upstream.
The tests are only usable if the acceleration engines have
been successfully initialized.
Based on an initial patch from: Alex Ivanov <gnidorah@p0n4ik.tk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/radeon_device.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -835,13 +835,22 @@ int radeon_device_init(struct radeon_dev
return r;
}
if ((radeon_testing & 1)) {
- radeon_test_moves(rdev);
+ if (rdev->accel_working)
+ radeon_test_moves(rdev);
+ else
+ DRM_INFO("radeon: acceleration disabled, skipping move tests\n");
}
if ((radeon_testing & 2)) {
- radeon_test_syncing(rdev);
+ if (rdev->accel_working)
+ radeon_test_syncing(rdev);
+ else
+ DRM_INFO("radeon: acceleration disabled, skipping sync tests\n");
}
if (radeon_benchmarking) {
- radeon_benchmark(rdev, radeon_benchmarking);
+ if (rdev->accel_working)
+ radeon_benchmark(rdev, radeon_benchmarking);
+ else
+ DRM_INFO("radeon: acceleration disabled, skipping benchmarks\n");
}
return 0;
}
^ permalink raw reply [flat|nested] 23+ messages in thread* [ 12/16] hwmon: (applesmc) Check key count before proceeding
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2013-10-03 4:05 ` [ 11/16] drm/radeon: disable tests/benchmarks if accel is disabled Greg Kroah-Hartman
@ 2013-10-03 4:05 ` Greg Kroah-Hartman
2013-10-03 4:05 ` [ 13/16] ALSA: compress: Fix compress device unregister Greg Kroah-Hartman
` (6 subsequent siblings)
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 4:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, jwboyer, Guenter Roeck,
Henrik Rydberg
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Henrik Rydberg <rydberg@euromail.se>
commit 5f4513864304672e6ea9eac60583eeac32e679f2 upstream.
After reports from Chris and Josh Boyer of a rare crash in applesmc,
Guenter pointed at the initialization problem fixed below. The patch
has not been verified to fix the crash, but should be applied
regardless.
Reported-by: <jwboyer@fedoraproject.org>
Suggested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hwmon/applesmc.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -489,16 +489,25 @@ static int applesmc_init_smcreg_try(void
{
struct applesmc_registers *s = &smcreg;
bool left_light_sensor, right_light_sensor;
+ unsigned int count;
u8 tmp[1];
int ret;
if (s->init_complete)
return 0;
- ret = read_register_count(&s->key_count);
+ ret = read_register_count(&count);
if (ret)
return ret;
+ if (s->cache && s->key_count != count) {
+ pr_warn("key count changed from %d to %d\n",
+ s->key_count, count);
+ kfree(s->cache);
+ s->cache = NULL;
+ }
+ s->key_count = count;
+
if (!s->cache)
s->cache = kcalloc(s->key_count, sizeof(*s->cache), GFP_KERNEL);
if (!s->cache)
^ permalink raw reply [flat|nested] 23+ messages in thread* [ 13/16] ALSA: compress: Fix compress device unregister.
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2013-10-03 4:05 ` [ 12/16] hwmon: (applesmc) Check key count before proceeding Greg Kroah-Hartman
@ 2013-10-03 4:05 ` Greg Kroah-Hartman
2013-10-03 4:05 ` [ 14/16] mm, memcg: give exiting processes access to memory reserves Greg Kroah-Hartman
` (5 subsequent siblings)
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 4:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Liam Girdwood, Vinod Koul,
Takashi Iwai
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liam Girdwood <liam.r.girdwood@linux.intel.com>
commit 4028b6c4c03f213260e9290ff3a6b5439aad07ce upstream.
snd_unregister_device() should return the device type and not stream
direction.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Tested-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/compress_offload.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/sound/core/compress_offload.c
+++ b/sound/core/compress_offload.c
@@ -663,7 +663,8 @@ static int snd_compress_dev_disconnect(s
struct snd_compr *compr;
compr = device->device_data;
- snd_unregister_device(compr->direction, compr->card, compr->device);
+ snd_unregister_device(SNDRV_DEVICE_TYPE_COMPRESS, compr->card,
+ compr->device);
return 0;
}
^ permalink raw reply [flat|nested] 23+ messages in thread* [ 14/16] mm, memcg: give exiting processes access to memory reserves
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2013-10-03 4:05 ` [ 13/16] ALSA: compress: Fix compress device unregister Greg Kroah-Hartman
@ 2013-10-03 4:05 ` Greg Kroah-Hartman
2013-10-03 4:05 ` [ 15/16] mm: fix aio performance regression for database caused by THP Greg Kroah-Hartman
` (4 subsequent siblings)
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 4:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David Rientjes, Michal Hocko,
KAMEZAWA Hiroyuki, Johannes Weiner, Andrew Morton, Linus Torvalds,
Qiang Huang
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Rientjes <rientjes@google.com>
commit 465adcf1ea7b2e49b2e0899366624f5532b64012
A memcg may livelock when oom if the process that grabs the hierarchy's
oom lock is never the first process with PF_EXITING set in the memcg's
task iteration.
The oom killer, both global and memcg, will defer if it finds an
eligible process that is in the process of exiting and it is not being
ptraced. The idea is to allow it to exit without using memory reserves
before needlessly killing another process.
This normally works fine except in the memcg case with a large number of
threads attached to the oom memcg. In this case, the memcg oom killer
only gets called for the process that grabs the hierarchy's oom lock;
all others end up blocked on the memcg's oom waitqueue. Thus, if the
process that grabs the hierarchy's oom lock is never the first
PF_EXITING process in the memcg's task iteration, the oom killer is
constantly deferred without anything making progress.
The fix is to give PF_EXITING processes access to memory reserves so
that we've marked them as oom killed without any iteration. This allows
__mem_cgroup_try_charge() to succeed so that the process may exit. This
makes the memcg oom killer exemption for TIF_MEMDIE tasks, now
immediately granted for processes with pending SIGKILLs and those in the
exit path, to be equivalent to what is done for the global oom killer.
Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Michal Hocko <mhocko@suse.cz>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Qiang: backported to 3.4:
- move the changes from memcontrol.c to oom_kill.c]
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/oom_kill.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -562,11 +562,11 @@ void mem_cgroup_out_of_memory(struct mem
struct task_struct *p;
/*
- * If current has a pending SIGKILL, then automatically select it. The
- * goal is to allow it to allocate so that it may quickly exit and free
- * its memory.
+ * If current has a pending SIGKILL or is exiting, then automatically
+ * select it. The goal is to allow it to allocate so that it may
+ * quickly exit and free its memory.
*/
- if (fatal_signal_pending(current)) {
+ if (fatal_signal_pending(current) || current->flags & PF_EXITING) {
set_thread_flag(TIF_MEMDIE);
return;
}
^ permalink raw reply [flat|nested] 23+ messages in thread* [ 15/16] mm: fix aio performance regression for database caused by THP
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2013-10-03 4:05 ` [ 14/16] mm, memcg: give exiting processes access to memory reserves Greg Kroah-Hartman
@ 2013-10-03 4:05 ` Greg Kroah-Hartman
2013-10-03 4:05 ` [ 16/16] HID: LG: validate HID output report details Greg Kroah-Hartman
` (3 subsequent siblings)
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 4:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Khalid Aziz, Pravin B Shelar,
Christoph Lameter, Andrea Arcangeli, Johannes Weiner, Mel Gorman,
Rik van Riel, Minchan Kim, Andi Kleen, Andrew Morton,
Linus Torvalds
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Khalid Aziz <khalid.aziz@oracle.com>
commit 7cb2ef56e6a8b7b368b2e883a0a47d02fed66911 upstream.
This patch needed to be backported due to changes to mm/swap.c some time
after 3.6 kernel.
I am working with a tool that simulates oracle database I/O workload.
This tool (orion to be specific -
<http://docs.oracle.com/cd/E11882_01/server.112/e16638/iodesign.htm#autoId24>)
allocates hugetlbfs pages using shmget() with SHM_HUGETLB flag. It then
does aio into these pages from flash disks using various common block
sizes used by database. I am looking at performance with two of the most
common block sizes - 1M and 64K. aio performance with these two block
sizes plunged after Transparent HugePages was introduced in the kernel.
Here are performance numbers:
pre-THP 2.6.39 3.11-rc5
1M read 8384 MB/s 5629 MB/s 6501 MB/s
64K read 7867 MB/s 4576 MB/s 4251 MB/s
I have narrowed the performance impact down to the overheads introduced by
THP in __get_page_tail() and put_compound_page() routines. perf top shows
>40% of cycles being spent in these two routines. Every time direct I/O
to hugetlbfs pages starts, kernel calls get_page() to grab a reference to
the pages and calls put_page() when I/O completes to put the reference
away. THP introduced significant amount of locking overhead to get_page()
and put_page() when dealing with compound pages because hugepages can be
split underneath get_page() and put_page(). It added this overhead
irrespective of whether it is dealing with hugetlbfs pages or transparent
hugepages. This resulted in 20%-45% drop in aio performance when using
hugetlbfs pages.
Since hugetlbfs pages can not be split, there is no reason to go through
all the locking overhead for these pages from what I can see. I added
code to __get_page_tail() and put_compound_page() to bypass all the
locking code when working with hugetlbfs pages. This improved performance
significantly. Performance numbers with this patch:
pre-THP 3.11-rc5 3.11-rc5 + Patch
1M read 8384 MB/s 6501 MB/s 8371 MB/s
64K read 7867 MB/s 4251 MB/s 6510 MB/s
Performance with 64K read is still lower than what it was before THP, but
still a 53% improvement. It does mean there is more work to be done but I
will take a 53% improvement for now.
Please take a look at the following patch and let me know if it looks
reasonable.
[akpm@linux-foundation.org: tweak comments]
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
Cc: Pravin B Shelar <pshelar@nicira.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Rik van Riel <riel@redhat.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/swap.c | 65 ++++++++++++++++++++++++++++++++++++++++++++------------------
1 file changed, 47 insertions(+), 18 deletions(-)
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -40,6 +40,8 @@ static DEFINE_PER_CPU(struct pagevec[NR_
static DEFINE_PER_CPU(struct pagevec, lru_rotate_pvecs);
static DEFINE_PER_CPU(struct pagevec, lru_deactivate_pvecs);
+int PageHuge(struct page *page);
+
/*
* This path almost never happens for VM activity - pages are normally
* freed via pagevecs. But it gets used by networking.
@@ -68,13 +70,26 @@ static void __put_compound_page(struct p
{
compound_page_dtor *dtor;
- __page_cache_release(page);
+ if (!PageHuge(page))
+ __page_cache_release(page);
dtor = get_compound_page_dtor(page);
(*dtor)(page);
}
static void put_compound_page(struct page *page)
{
+ /*
+ * hugetlbfs pages can not be split from under us. So if this
+ * is a hugetlbfs page, check refcount on head page and release
+ * the page if refcount is zero.
+ */
+ if (PageHuge(page)) {
+ page = compound_head(page);
+ if (put_page_testzero(page))
+ __put_compound_page(page);
+ return;
+ }
+
if (unlikely(PageTail(page))) {
/* __split_huge_page_refcount can run under us */
struct page *page_head = compound_trans_head(page);
@@ -157,26 +172,40 @@ bool __get_page_tail(struct page *page)
* proper PT lock that already serializes against
* split_huge_page().
*/
- unsigned long flags;
bool got = false;
- struct page *page_head = compound_trans_head(page);
- if (likely(page != page_head && get_page_unless_zero(page_head))) {
- /*
- * page_head wasn't a dangling pointer but it
- * may not be a head page anymore by the time
- * we obtain the lock. That is ok as long as it
- * can't be freed from under us.
- */
- flags = compound_lock_irqsave(page_head);
- /* here __split_huge_page_refcount won't run anymore */
- if (likely(PageTail(page))) {
- __get_page_tail_foll(page, false);
- got = true;
+ /*
+ * If this is a hugetlbfs page, it can not be split under
+ * us. Simply increment counts for tail page and its head page
+ */
+ if (PageHuge(page)) {
+ struct page *page_head;
+
+ page_head = compound_head(page);
+ atomic_inc(&page_head->_count);
+ got = true;
+ } else {
+ struct page *page_head = compound_trans_head(page);
+ unsigned long flags;
+
+ if (likely(page != page_head &&
+ get_page_unless_zero(page_head))) {
+ /*
+ * page_head wasn't a dangling pointer but it
+ * may not be a head page anymore by the time
+ * we obtain the lock. That is ok as long as it
+ * can't be freed from under us.
+ */
+ flags = compound_lock_irqsave(page_head);
+ /* here __split_huge_page_refcount won't run anymore */
+ if (likely(PageTail(page))) {
+ __get_page_tail_foll(page, false);
+ got = true;
+ }
+ compound_unlock_irqrestore(page_head, flags);
+ if (unlikely(!got))
+ put_page(page_head);
}
- compound_unlock_irqrestore(page_head, flags);
- if (unlikely(!got))
- put_page(page_head);
}
return got;
}
^ permalink raw reply [flat|nested] 23+ messages in thread* [ 16/16] HID: LG: validate HID output report details
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2013-10-03 4:05 ` [ 15/16] mm: fix aio performance regression for database caused by THP Greg Kroah-Hartman
@ 2013-10-03 4:05 ` Greg Kroah-Hartman
2013-10-03 13:30 ` [ 00/16] 3.4.65-stable review Guenter Roeck
` (2 subsequent siblings)
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 4:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kees Cook, Benjamin Tissoires,
Jiri Kosina
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <keescook@chromium.org>
commit 0fb6bd06e06792469acc15bbe427361b56ada528 upstream.
A HID device could send a malicious output report that would cause the
lg, lg3, and lg4 HID drivers to write beyond the output report allocation
during an event, causing a heap overflow:
[ 325.245240] usb 1-1: New USB device found, idVendor=046d, idProduct=c287
...
[ 414.518960] BUG kmalloc-4096 (Not tainted): Redzone overwritten
Additionally, while lg2 did correctly validate the report details, it was
cleaned up and shortened.
CVE-2013-2893
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-lg2ff.c | 19 +++----------------
drivers/hid/hid-lg3ff.c | 29 ++++++-----------------------
drivers/hid/hid-lg4ff.c | 20 +-------------------
drivers/hid/hid-lgff.c | 17 ++---------------
4 files changed, 12 insertions(+), 73 deletions(-)
--- a/drivers/hid/hid-lg2ff.c
+++ b/drivers/hid/hid-lg2ff.c
@@ -66,26 +66,13 @@ int lg2ff_init(struct hid_device *hid)
struct hid_report *report;
struct hid_input *hidinput = list_entry(hid->inputs.next,
struct hid_input, list);
- struct list_head *report_list =
- &hid->report_enum[HID_OUTPUT_REPORT].report_list;
struct input_dev *dev = hidinput->input;
int error;
- if (list_empty(report_list)) {
- hid_err(hid, "no output report found\n");
+ /* Check that the report looks ok */
+ report = hid_validate_values(hid, HID_OUTPUT_REPORT, 0, 0, 7);
+ if (!report)
return -ENODEV;
- }
-
- report = list_entry(report_list->next, struct hid_report, list);
-
- if (report->maxfield < 1) {
- hid_err(hid, "output report is empty\n");
- return -ENODEV;
- }
- if (report->field[0]->report_count < 7) {
- hid_err(hid, "not enough values in the field\n");
- return -ENODEV;
- }
lg2ff = kmalloc(sizeof(struct lg2ff_device), GFP_KERNEL);
if (!lg2ff)
--- a/drivers/hid/hid-lg3ff.c
+++ b/drivers/hid/hid-lg3ff.c
@@ -68,10 +68,11 @@ static int hid_lg3ff_play(struct input_d
int x, y;
/*
- * Maxusage should always be 63 (maximum fields)
- * likely a better way to ensure this data is clean
+ * Available values in the field should always be 63, but we only use up to
+ * 35. Instead, clear the entire area, however big it is.
*/
- memset(report->field[0]->value, 0, sizeof(__s32)*report->field[0]->maxusage);
+ memset(report->field[0]->value, 0,
+ sizeof(__s32) * report->field[0]->report_count);
switch (effect->type) {
case FF_CONSTANT:
@@ -131,32 +132,14 @@ static const signed short ff3_joystick_a
int lg3ff_init(struct hid_device *hid)
{
struct hid_input *hidinput = list_entry(hid->inputs.next, struct hid_input, list);
- struct list_head *report_list = &hid->report_enum[HID_OUTPUT_REPORT].report_list;
struct input_dev *dev = hidinput->input;
- struct hid_report *report;
- struct hid_field *field;
const signed short *ff_bits = ff3_joystick_ac;
int error;
int i;
- /* Find the report to use */
- if (list_empty(report_list)) {
- hid_err(hid, "No output report found\n");
- return -1;
- }
-
/* Check that the report looks ok */
- report = list_entry(report_list->next, struct hid_report, list);
- if (!report) {
- hid_err(hid, "NULL output report\n");
- return -1;
- }
-
- field = report->field[0];
- if (!field) {
- hid_err(hid, "NULL field\n");
- return -1;
- }
+ if (!hid_validate_values(hid, HID_OUTPUT_REPORT, 0, 0, 35))
+ return -ENODEV;
/* Assume single fixed device G940 */
for (i = 0; ff_bits[i] >= 0; i++)
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -339,33 +339,15 @@ static ssize_t lg4ff_range_store(struct
int lg4ff_init(struct hid_device *hid)
{
struct hid_input *hidinput = list_entry(hid->inputs.next, struct hid_input, list);
- struct list_head *report_list = &hid->report_enum[HID_OUTPUT_REPORT].report_list;
struct input_dev *dev = hidinput->input;
- struct hid_report *report;
- struct hid_field *field;
struct lg4ff_device_entry *entry;
struct usb_device_descriptor *udesc;
int error, i, j;
__u16 bcdDevice, rev_maj, rev_min;
- /* Find the report to use */
- if (list_empty(report_list)) {
- hid_err(hid, "No output report found\n");
- return -1;
- }
-
/* Check that the report looks ok */
- report = list_entry(report_list->next, struct hid_report, list);
- if (!report) {
- hid_err(hid, "NULL output report\n");
- return -1;
- }
-
- field = report->field[0];
- if (!field) {
- hid_err(hid, "NULL field\n");
+ if (!hid_validate_values(hid, HID_OUTPUT_REPORT, 0, 0, 7))
return -1;
- }
/* Check what wheel has been connected */
for (i = 0; i < ARRAY_SIZE(lg4ff_devices); i++) {
--- a/drivers/hid/hid-lgff.c
+++ b/drivers/hid/hid-lgff.c
@@ -130,27 +130,14 @@ static void hid_lgff_set_autocenter(stru
int lgff_init(struct hid_device* hid)
{
struct hid_input *hidinput = list_entry(hid->inputs.next, struct hid_input, list);
- struct list_head *report_list = &hid->report_enum[HID_OUTPUT_REPORT].report_list;
struct input_dev *dev = hidinput->input;
- struct hid_report *report;
- struct hid_field *field;
const signed short *ff_bits = ff_joystick;
int error;
int i;
- /* Find the report to use */
- if (list_empty(report_list)) {
- hid_err(hid, "No output report found\n");
- return -1;
- }
-
/* Check that the report looks ok */
- report = list_entry(report_list->next, struct hid_report, list);
- field = report->field[0];
- if (!field) {
- hid_err(hid, "NULL field\n");
- return -1;
- }
+ if (!hid_validate_values(hid, HID_OUTPUT_REPORT, 0, 0, 7))
+ return -ENODEV;
for (i = 0; i < ARRAY_SIZE(devices); i++) {
if (dev->id.vendor == devices[i].idVendor &&
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [ 00/16] 3.4.65-stable review
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2013-10-03 4:05 ` [ 16/16] HID: LG: validate HID output report details Greg Kroah-Hartman
@ 2013-10-03 13:30 ` Guenter Roeck
2013-10-03 18:40 ` Greg Kroah-Hartman
2013-10-03 18:39 ` Greg Kroah-Hartman
2013-10-04 0:24 ` Shuah Khan
18 siblings, 1 reply; 23+ messages in thread
From: Guenter Roeck @ 2013-10-03 13:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel; +Cc: torvalds, akpm, stable
On 10/02/2013 09:05 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.4.65 release.
> There are 16 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 Sat Oct 5 04:04:34 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.65-rc1.gz
> and the diffstat can be found below.
>
Build results:
total: 103 pass: 17 skipped: 10 fail: 76
Apparently due to:
mm: fix aio performance regression for database caused by THP
All qemu images failed to build.
Guenter
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [ 00/16] 3.4.65-stable review
2013-10-03 13:30 ` [ 00/16] 3.4.65-stable review Guenter Roeck
@ 2013-10-03 18:40 ` Greg Kroah-Hartman
2013-10-03 21:19 ` Guenter Roeck
0 siblings, 1 reply; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 18:40 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linux-kernel, torvalds, akpm, stable
On Thu, Oct 03, 2013 at 06:30:15AM -0700, Guenter Roeck wrote:
> On 10/02/2013 09:05 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.4.65 release.
> > There are 16 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 Sat Oct 5 04:04:34 UTC 2013.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.65-rc1.gz
> > and the diffstat can be found below.
> >
>
> Build results:
> total: 103 pass: 17 skipped: 10 fail: 76
>
> Apparently due to:
> mm: fix aio performance regression for database caused by THP
These build issues should be fixed with -rc2, if not, please let me
know.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ 00/16] 3.4.65-stable review
2013-10-03 18:40 ` Greg Kroah-Hartman
@ 2013-10-03 21:19 ` Guenter Roeck
0 siblings, 0 replies; 23+ messages in thread
From: Guenter Roeck @ 2013-10-03 21:19 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, torvalds, akpm, stable
On Thu, Oct 03, 2013 at 11:40:23AM -0700, Greg Kroah-Hartman wrote:
> On Thu, Oct 03, 2013 at 06:30:15AM -0700, Guenter Roeck wrote:
> > On 10/02/2013 09:05 PM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 3.4.65 release.
> > > There are 16 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 Sat Oct 5 04:04:34 UTC 2013.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.65-rc1.gz
> > > and the diffstat can be found below.
> > >
> >
> > Build results:
> > total: 103 pass: 17 skipped: 10 fail: 76
> >
> > Apparently due to:
> > mm: fix aio performance regression for database caused by THP
>
> These build issues should be fixed with -rc2, if not, please let me
> know.
>
Updated build results:
total: 103 pass: 89 skipped: 10 fail: 4
qemu tests all pass.
This matches the results from 3.4.64.
Thanks,
Guenter
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ 00/16] 3.4.65-stable review
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2013-10-03 13:30 ` [ 00/16] 3.4.65-stable review Guenter Roeck
@ 2013-10-03 18:39 ` Greg Kroah-Hartman
2013-10-04 0:24 ` Shuah Khan
18 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-03 18:39 UTC (permalink / raw)
To: linux-kernel; +Cc: torvalds, akpm, stable
On Wed, Oct 02, 2013 at 09:05:24PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.4.65 release.
> There are 16 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 Sat Oct 5 04:04:34 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.65-rc1.gz
> and the diffstat can be found below.
Due to reported build issues with -rc1, I've dropped the offending patch
and released -rc2:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.65-rc2.gz
thanks,
greg k-h
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [ 00/16] 3.4.65-stable review
2013-10-03 4:05 [ 00/16] 3.4.65-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2013-10-03 18:39 ` Greg Kroah-Hartman
@ 2013-10-04 0:24 ` Shuah Khan
2013-10-04 2:38 ` Greg Kroah-Hartman
18 siblings, 1 reply; 23+ messages in thread
From: Shuah Khan @ 2013-10-04 0:24 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, stable, Shuah Khan,
shuahkhan@gmail.com
On 10/02/2013 10:05 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.4.65 release.
> There are 16 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 Sat Oct 5 04:04:34 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.65-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Patch testing: 3.4.65-rc1-rc1 patch applied with white-space warnings
and 3.4.65-rc2 applied cleanly.
Tested 3.4.65-rc1 and 3.4.65-rc2.
Compile testing: 3.4.65-rc1 and 3.4.65-rc2. Passed
Boot testing: 3.4.65-rc1 and 3.4.65-rc2. Passed
dmesg regression testing: passed. dmesgs look good. No regressions
compared to the previous dmesgs for this release. dmesg emerg, crit,
alert, err are clean. No regressions in warn.
Test systems
Samsung Series 9 900X4C Intel Corei5 (3.4 and later)
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2 (cross-compile
testing)
Cross-compile tests results
alpha defconfig Passed
arm defconfig Passed
arm64 defconfig Not applicable
blackfin defconfig Passed
c6x dsk6455_defconfig Passed
mips defconfig Passed
mipsel defconfig Passed
powerpc wii_defconfig Passed
sh defconfig Passed
sparc defconfig Passed
tile tilegx_defconfig Passed
-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [ 00/16] 3.4.65-stable review
2013-10-04 0:24 ` Shuah Khan
@ 2013-10-04 2:38 ` Greg Kroah-Hartman
0 siblings, 0 replies; 23+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-04 2:38 UTC (permalink / raw)
To: Shuah Khan; +Cc: linux-kernel, torvalds, akpm, stable, shuahkhan@gmail.com
On Thu, Oct 03, 2013 at 06:24:05PM -0600, Shuah Khan wrote:
> On 10/02/2013 10:05 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.4.65 release.
> >There are 16 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 Sat Oct 5 04:04:34 UTC 2013.
> >Anything received after that time might be too late.
> >
> >The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.65-rc1.gz
> >and the diffstat can be found below.
> >
> >thanks,
> >
> >greg k-h
> >
>
> Patch testing: 3.4.65-rc1-rc1 patch applied with white-space
> warnings and 3.4.65-rc2 applied cleanly.
>
> Tested 3.4.65-rc1 and 3.4.65-rc2.
> Compile testing: 3.4.65-rc1 and 3.4.65-rc2. Passed
> Boot testing: 3.4.65-rc1 and 3.4.65-rc2. Passed
> dmesg regression testing: passed. dmesgs look good. No regressions
> compared to the previous dmesgs for this release. dmesg emerg, crit,
> alert, err are clean. No regressions in warn.
Thanks for testing both of these.
greg k-h
^ permalink raw reply [flat|nested] 23+ messages in thread