- 06 Feb, 2013 31 commits
-
-
Jerome Glisse authored
commit 51861d4e upstream. Those rn50 chip are often connected to console remoting hw and load detection often fails with those. Just don't try to load detect and report connect. Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Axel Lin authored
commit 81d0a6ae upstream. Use DIV_ROUND_UP to prevent truncation by integer division issue. This ensures we return enough delay time. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> [bwh: Backported to 3.2: delay is done by driver, not returned to the caller] Signed-off-by:
-
David Henningsson authored
commit 7ed4165e upstream. This reverts commit 697c373e. The original patch was meant to remove clicking, but in fact caused even more clicking instead. Thanks to c4pp4 for doing most of the work with this bug. BugLink: https://bugs.launchpad.net/bugs/886975Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Hannes Reinecke authored
commit 18a9df42 upstream. The ASC/ASCQ code for 'Logical Unit Communication failure' is 0x08/0x00; 0x80/0x00 is vendor specific. Signed-off-by:
Hannes Reinecke <hare@suse.de> Cc: Nicholas Bellinger <nab@risingtidesystems.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> [bwh: Backported to 3.2: add offset to buffer index] Signed-off-by:
-
Trond Myklebust authored
commit 87ed5003 upstream. If the rpc_task exits while holding the socket write lock before it has allocated an rpc slot, then the usual mechanism for releasing the write lock in xprt_release() is defeated. The problem occurs if the call to xprt_lock_write() initially fails, so that the rpc_task is put on the xprt->sending wait queue. If the task exits after being assigned the lock by __xprt_lock_write_func, but before it has retried the call to xprt_lock_and_alloc_slot(), then it calls xprt_release() while holding the write lock, but will immediately exit due to the test for task->tk_rqstp != NULL. Reported-by:
Chris Perl <chris.perl@gmail.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Mike Dunn authored
commit 3b4bc7bc upstream. This patch fixes some code that implements a work-around to a hardware bug in the ac97 controller on the pxa27x. A bug in the controller's warm reset functionality requires that the mfp used by the controller as the AC97_nRESET line be temporarily reconfigured as a generic output gpio (AF0) and manually held high for the duration of the warm reset cycle. This is what was done in the original code, but it was broken long ago by commit fb1bf8cd ([ARM] pxa: introduce processor specific pxa27x_assert_ac97reset()) which changed the mfp to a GPIO input instead of a high output. The fix requires the ac97 controller to obtain the gpio via gpio_request_one(), with arguments that configure the gpio as an output initially driven high. Tested on a palm treo 680 machine. Reportedly, this broken code only prevents a warm reset on hardware that lacks a pull-up on the line, which appears to be the case for me. Signed-off-by:
Mike Dunn <mikedunn@newsguy.com> Signed-off-by:
Igor Grinberg <grinberg@compulab.co.il> Signed-off-by:
-
Mike Dunn authored
commit 41b645c8 upstream. Cold reset on the pxa27x currently fails and pxa2xx_ac97_try_cold_reset: cold reset timeout (GSR=0x44) appears in the kernel log. Through trial-and-error (the pxa270 developer's manual is mostly incoherent on the topic of ac97 reset), I got cold reset to complete by setting the WARM_RST bit in the GCR register (and later noticed that pxa3xx does this for cold reset as well). Also, a timeout loop is needed to wait for the reset to complete. Tested on a palm treo 680 machine. Signed-off-by:
-
Axel Lin authored
commit bc3b7756 upstream. Current code does integer division (min_vol = min_uV / 1000) before pass min_vol to max8997_get_voltage_proper_val(). So it is possible min_vol is truncated to a smaller value. For example, if the request min_uV is 800900 for ldo. min_vol = 800900 / 1000 = 800 (mV) Then max8997_get_voltage_proper_val returns 800 mV for this case which is lower than the requested voltage. Use uV rather than mV in voltage_map_desc to prevent truncation by integer division. Signed-off-by:
-
Ian Abbott authored
commit c0729eee upstream. Éric Piel reported a kernel oops in the "comedi_test" module. It was a NULL pointer dereference within `waveform_ai_interrupt()` (actually a timer function) that sometimes occurred when a running asynchronous command is cancelled (either by the `COMEDI_CANCEL` ioctl or by closing the device file). This seems to be a race between the caller of `waveform_ai_cancel()` which on return from that function goes and tears down the running command, and the timer function which uses the command. In particular, `async->cmd.chanlist` gets freed (and the pointer set to NULL) by `do_become_nonbusy()` in "comedi_fops.c" but a previously scheduled `waveform_ai_interrupt()` timer function will dereference that pointer regardless, leading to the oops. Fix it by replacing the `del_timer()` call in `waveform_ai_cancel()` with `del_timer_sync()`. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Reported-by:
Éric Piel <piel@delmic.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Éric Piel authored
commit 34b55d8c upstream. The minimum period was set to 357 ns, while the divider for these boards is 50 ns. This prevented to output at maximum speed as ni_ao_cmdtest() would return 357 but would not accept it. Not sure why it was set to 357 ns (this was done before the git history, which starts 5 years ago). My guess is that it comes from reading the specification stating a 2.8 MHz rate (~ 357 ns). The latest specification states a 2.86 MHz rate (~ 350 ns), which makes a lot more sense. Tested on a pci-6251. Signed-off-by:
-
Samuel Thibault authored
commit 6102c48b upstream. Check that array index is in-bounds before accessing the synths[] array. Signed-off-by:
Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: Nickolai Zeldovich <nickolai@csail.mit.edu> Signed-off-by:
-
Nickolai Zeldovich authored
commit ae428655 upstream. Check that array index is in-bounds before accessing the synths[] array. Signed-off-by:
Nickolai Zeldovich <nickolai@csail.mit.edu> Cc: Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by:
-
Larry Finger authored
commit da849a92 upstream. The ISY IWL 1000 USB WLAN stick with USB ID 050d:11f1 is a clone of the Belkin F7D1101 V1 device. Reported-by:
Thomas Hartmann <hartmann@ict.tuwien.ac.at> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Thomas Hartmann <hartmann@ict.tuwien.ac.at> Signed-off-by:
-
Chris Wilson authored
commit 93be8788 upstream. As along the error path we do not correct the user pin-count for the failure, we may end up with userspace believing that it has a pinned object at offset 0 (when interrupted by a signal for example). Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Shuah Khan authored
commit ac498987 upstream. ioat does DMA memory sync with DMA_TO_DEVICE direction on a buffer allocated for DMA_FROM_DEVICE dma, resulting in the following warning from dma debug. Fixed the dma_sync_single_for_device() call to use the correct direction. [ 226.288947] WARNING: at lib/dma-debug.c:990 check_sync+0x132/0x550() [ 226.288948] Hardware name: ProLiant DL380p Gen8 [ 226.288951] ioatdma 0000:00:04.0: DMA-API: device driver syncs DMA memory with different direction [device address=0x00000000ffff7000] [size=4096 bytes] [mapped with DMA_FROM_DEVICE] [synced with DMA_TO_DEVICE] [ 226.288953] Modules linked in: iTCO_wdt(+) sb_edac(+) ioatdma(+) microcode serio_raw pcspkr edac_core hpwdt(+) iTCO_vendor_support hpilo(+) dca acpi_power_meter ata_generic pata_acpi sd_mod crc_t10dif ata_piix libata hpsa tg3 netxen_nic(+) sunrpc dm_mirror dm_region_hash dm_log dm_mod [ 226.288967] Pid: 1055, comm: work_for_cpu Tainted: G W 3.3.0-0.20.el7.x86_64 #1 [ 226.288968] Call Trace: [ 226.288974] [<ffffffff810644cf>] warn_slowpath_common+0x7f/0xc0 [ 226.288977] [<ffffffff810645c6>] warn_slowpath_fmt+0x46/0x50 [ 226.288980] [<ffffffff81345502>] check_sync+0x132/0x550 [ 226.288983] [<ffffffff81345c9f>] debug_dma_sync_single_for_device+0x3f/0x50 [ 226.288988] [<ffffffff81661002>] ? wait_for_common+0x72/0x180 [ 226.288995] [<ffffffffa019590f>] ioat_xor_val_self_test+0x3e5/0x832 [ioatdma] [ 226.288999] [<ffffffff811a5739>] ? kfree+0x259/0x270 [ 226.289004] [<ffffffffa0195d77>] ioat3_dma_self_test+0x1b/0x20 [ioatdma] [ 226.289008] [<ffffffffa01952c3>] ioat_probe+0x2f8/0x348 [ioatdma] [ 226.289011] [<ffffffffa0195f51>] ioat3_dma_probe+0x1d5/0x2aa [ioatdma] [ 226.289016] [<ffffffffa0194d12>] ioat_pci_probe+0x139/0x17c [ioatdma] [ 226.289020] [<ffffffff81354b8c>] local_pci_probe+0x5c/0xd0 [ 226.289023] [<ffffffff81083e50>] ? destroy_work_on_stack+0x20/0x20 [ 226.289025] [<ffffffff81083e68>] do_work_for_cpu+0x18/0x30 [ 226.289029] [<ffffffff8108d997>] kthread+0xb7/0xc0 [ 226.289033] [<ffffffff8166cef4>] kernel_thread_helper+0x4/0x10 [ 226.289036] [<ffffffff81662d20>] ? _raw_spin_unlock_irq+0x30/0x50 [ 226.289038] [<ffffffff81663234>] ? retint_restore_args+0x13/0x13 [ 226.289041] [<ffffffff8108d8e0>] ? kthread_worker_fn+0x1a0/0x1a0 [ 226.289044] [<ffffffff8166cef0>] ? gs_change+0x13/0x13 [ 226.289045] ---[ end trace e1618afc7a606089 ]--- [ 226.289047] Mapped at: [ 226.289048] [<ffffffff81345307>] debug_dma_map_page+0x87/0x150 [ 226.289050] [<ffffffffa019653c>] dma_map_page.constprop.18+0x70/0xb34 [ioatdma] [ 226.289054] [<ffffffffa0195702>] ioat_xor_val_self_test+0x1d8/0x832 [ioatdma] [ 226.289058] [<ffffffffa0195d77>] ioat3_dma_self_test+0x1b/0x20 [ioatdma] [ 226.289061] [<ffffffffa01952c3>] ioat_probe+0x2f8/0x348 [ioatdma] Signed-off-by:
Shuah Khan <shuah.khan@hp.com> Signed-off-by:
Vinod Koul <vinod.koul@linux.intel.com> Signed-off-by:
-
Mark Brown authored
commit 267f8fa2 upstream. Signed-off-by:
-
Bing Zhao authored
commit 9c969d8c upstream. wait_event_interruptible function returns -ERESTARTSYS if it's interrupted by a signal. Driver should check the return value and handle this case properly. In mwifiex_wait_queue_complete() routine, as we are now checking wait_event_interruptible return value, the condition check is not required. Also, we have removed mwifiex_cancel_pending_ioctl() call to avoid a chance of sending second command to FW by other path as soon as we clear current command node. FW can not handle two commands simultaneously. Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Amitkumar Karwar authored
commit b7097eb7 upstream. Currently even if association is failed "iw link" shows some information about connected BSS and "Tx timeout" error is seen in dmesg log. This patch fixes below issues in the code to handle assoc failure case correctly. 1) "status" variable in mwifiex_wait_queue_complete() is not correctly updated. Hence driver doesn't inform cfg80211 stack about association failure. 2) During association network queues are stopped but carrier is not cleared, which gives Tx timeout error in failure case Signed-off-by:
-
Mark Brown authored
commit 5f960294 upstream. These are not supported Signed-off-by:
-
Sarah Sharp authored
commit c52804a4 upstream. The USB core hub thread (khubd) is designed with external USB hubs in mind. It expects that if a port status change bit is set, the hub will continue to send a notification through the hub status data transfer. Basically, it expects hub notifications to be level-triggered. The xHCI host controller is designed to be edge-triggered on the logical 'OR' of all the port status change bits. When all port status change bits are clear, and a new change bit is set, the xHC will generate a Port Status Change Event. If another change bit is set in the same port status register before the first bit is cleared, it will not send another event. This means that the hub code may lose port status changes because of race conditions between clearing change bits. The user sees this as a "dead port" that doesn't react to device connects. The fix is to turn on port polling whenever a new change bit is set. Once the USB core issues a hub status request that shows that no change bits are set in any USB ports, turn off port polling. We can't allow the USB core to poll the roothub for port events during host suspend because if the PCI host is in D3cold, the port registers will be all f's. Instead, stop the port polling timer, and unconditionally restart it when the host resumes. If there are no port change bits set after the resume, the first call to hub_status_data will disable polling. This patch should be backported to stable kernels with the first xHCI support, 2.6.31 and newer, that include the commit 0f2a7930 "USB: xhci: Root hub support." There will be merge conflicts because the check for HC_STATE_SUSPENDED was moved into xhci_suspend in 3.8. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Sarah Sharp authored
commit 65bdac5e upstream. An empty port can transition to either Inactive or Compliance Mode if a newly connected USB 3.0 device fails to link train. In that case, we issue a warm reset. Some devices, such as John's Roseweil eusb3 enclosure, slip back into Compliance Mode after the warm reset. The current warm reset code does not check for device connect status on warm reset completion, and it incorrectly reports the warm reset succeeded. This causes the USB core to attempt to send a Set Address control transfer to a port in Compliance Mode, which will always fail. Make hub_port_wait_reset check the current connect status and link state after the warm reset completes. Return a failure status if the device is disconnected or the link state is Compliance Mode or SS.Inactive. Make hub_events disable the port if warm reset fails. This will disable the port, and then bring it back into the RxDetect state. Make the USB core ignore the connect change until the device reconnects. Note that this patch does NOT handle connected devices slipping into the Inactive state very well. This is a concern, because devices can go into the Inactive state on U1/U2 exit failure. However, the fix for that case is too large for stable, so it will be submitted in a separate patch. This patch should be backported to kernels as old as 3.2, contain the commit ID 75d7cf72 "usbcore: refine warm reset logic" Signed-off-by:
John Covici <covici@ccs.covici.com> Signed-off-by:
-
Sarah Sharp authored
commit 4f43447e upstream. The port reset code bails out early if the current connect status is cleared (device disconnected). If we're issuing a hot reset, it may also look at the link state before the reset is finished. Section 10.14.2.6 of the USB 3.0 spec says that when a port enters the Error state or Resetting state, the port connection bit retains the value from the previous state. Therefore we can't trust it until the reset finishes. Also, the xHCI spec section 4.19.1.2.5 says software shall ignore the link state while the port is resetting, as it can be in an unknown state. The port state during reset is also unknown for USB 2.0 hubs. The hub sends a reset signal by driving the bus into an SE0 state. This overwhelms the "connect" signal from the device, so the port can't tell whether anything is connected or not. Fix the port reset code to ignore the port link state and current connect bit until the reset finishes, and USB_PORT_STAT_RESET is cleared. Remove the check for USB_PORT_STAT_C_BH_RESET in the warm reset case, because it's redundant. When the warm reset finishes, the port reset bit will be cleared at the same time USB_PORT_STAT_C_BH_RESET is set. Remove the now-redundant check for a cleared USB_PORT_STAT_RESET bit in the code to deal with the finished reset. This patch should be backported to all stable kernels. Signed-off-by:
-
Sarah Sharp authored
commit 77c7f072 upstream. John's NEC 0.96 xHCI host controller needs a longer timeout for a warm reset to complete. The logs show it takes 650ms to complete the warm reset, so extend the hub reset timeout to 800ms to be on the safe side. This commit should be backported to kernels as old as 3.2, that contain the commit 75d7cf72 "usbcore: refine warm reset logic". Signed-off-by:
-
Sarah Sharp authored
commit 41e7e056 upstream. If hot and warm reset fails, or a port remains in the Compliance Mode, the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0 ports, once the port is placed into the Disabled link state, it will not report any new device connects. To get device connect notifications, we need to put the link into the Disabled state, and then the RxDetect state. The xHCI driver needs to atomically clear all change bits on USB 3.0 port disable, so that we get Port Status Change Events for future port changes. We could technically do this in the USB core instead of in the xHCI roothub code, since the port state machine can't advance out of the disabled state until we set the link state to RxDetect. However, external USB 3.0 hubs don't need this code. They are level-triggered, not edge-triggered like xHCI, so they will continue to send interrupt events when any change bit is set. Therefore it doesn't make sense to put this code in the USB core. This patch is part of a series to fix several reports of infinite loops on device enumeration failure. This includes John, when he boots with a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96 host controller. The fix requires warm reset support, so it does not make sense to backport this patch to stable kernels without warm reset support. This patch should be backported to kernels as old as 3.2, contain the commit ID 75d7cf72 "usbcore: refine warm reset logic" Signed-off-by:
-
Sarah Sharp authored
commit 8b8132bc upstream. When the USB core finishes reseting a USB device, the xHCI driver sends a Reset Device command to the host. The xHC then updates its internal representation of the USB device to the 'Default' device state. If the device was already in the Default state, the xHC will complete the command with an error status. If a device needs to be reset several times during enumeration, the second reset will always fail because of the xHCI Reset Device command. This can cause issues during enumeration. For example, usb_reset_and_verify_device calls into hub_port_init in a loop. Say that on the first call into hub_port_init, the device is successfully reset, but doesn't respond to several set address control transfers. Then the port will be disabled, but the udev will remain in tact. usb_reset_and_verify_device will call into hub_port_init again. On the second call into hub_port_init, the device will be reset, and the xHCI driver will issue a Reset Device command. This command will fail (because the device is already in the Default state), and usb_reset_and_verify_device will fail. The port will be disabled, and the device won't be able to enumerate. Fix this by ignoring the return value of the HCD reset_device callback. This commit should be backported to kernels as old as 3.2, that contain the commit 75d7cf72 "usbcore: refine warm reset logic". Signed-off-by:
-
Sarah Sharp authored
commit 1c7439c6 upstream. USB 3.0 hubs and roothubs will automatically transition a failed hot reset to a warm (BH) reset. In that case, the warm reset change bit will be set, and the link state change bit may also be set. Change hub_port_finish_reset to unconditionally clear those change bits for USB 3.0 hubs. If these bits are not cleared, we may lose port change events from the roothub. This commit should be backported to kernels as old as 3.2, that contain the commit 75d7cf72 "usbcore: refine warm reset logic". Signed-off-by:
-
Sarah Sharp authored
commit 55c1945e upstream. A high speed control or bulk endpoint may have bInterval set to zero, which means it does not NAK. If bInterval is non-zero, it means the endpoint NAKs at a rate of 2^(bInterval - 1). The xHCI code to compute the NAK interval does not handle the special case of zero properly. The current code unconditionally subtracts one from bInterval and uses it as an exponent. This causes a very large bInterval to be used, and warning messages like these will be printed: usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes This may cause the xHCI host hardware to reject the Configure Endpoint command, which means the HS device will be unusable under xHCI ports. This patch should be backported to kernels as old as 2.6.31, that contain commit dfa49c4a "USB: xhci - fix math in xhci_get_endpoint_interval()". Reported-by:
Vincent Pelletier <plr.vincent@gmail.com> Suggested-by:
-
Johannes Berg authored
commit a56f992c upstream. This is a very old bug, but there's nothing that prevents the timer from running while the module is being removed when we only do del_timer() instead of del_timer_sync(). The timer should normally not be running at this point, but it's not clearly impossible (or we could just remove this.) Tested-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Alexander Graf authored
commit f4953fe6 upstream. When a file system is mounted on a virtio-blk disk, we then remove it and then reattach it, the reattached disk gets the same disk name and ids as the hot removed one. This leads to very nasty effects - mostly rendering the newly attached device completely unusable. Trying what happens when I do the same thing with a USB device, I saw that the sd node simply doesn't get free'd when a device gets forcefully removed. Imitate the same behavior for vd devices. This way broken vd devices simply are never free'd and newly attached ones keep working just fine. Signed-off-by:
Alexander Graf <agraf@suse.de> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Sergei Shtylyov authored
commit 2ac788f7 upstream. Commit 5c8a86e1 (usb: musb: drop unneeded musb_debug trickery) erroneously removed '\n' from the driver's banner. Concatenate all the banner substrings while adding it back... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit 1d16638e upstream. If we do have endpoints named like "ep-a" then bEndpointAddress is counted internally by the gadget framework. If we do have endpoints named like "ep-1" then bEndpointAddress is assigned from the digit after "ep-". If we do have both, then it is likely that after we used up the "generic" endpoints we will use the digits and thus assign one bEndpointAddress to multiple endpoints. This theory can be proofed by using the completely enabled g_multi. Without this patch, the mass storage won't enumerate and times out because it shares endpoints with RNDIS. This patch also adds fills up the endpoints list so we have in total endpoints 1 to 15 in + out available while some of them are restricted to certain types like BULK or ISO. Without this change the nokia gadget won't load because the system does not provide enough (BULK) endpoints but it did before ep-a - ep-f were removed. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by:
-
- 16 Jan, 2013 9 commits
-
-
Ben Hutchings authored
-
Ed Cashin authored
commit 0a41409c upstream. blk_alloc_queue has already done a bdi_init, so do not bdi_init again in aoeblk_gdalloc. The extra call causes list corruption in the per-CPU backing dev info stats lists. Affected users see console WARNINGs about list_del corruption on percpu_counter_destroy when doing "rmmod aoe" or "aoeflush -a" when AoE targets have been detected and initialized by the system. The patch below applies to v3.6.11, with its v47 aoe driver. It is expected to apply to all currently maintained stable kernels except 3.7.y. A related but different fix has been posted for 3.7.y. References: RedHat bugzilla ticket with original report https://bugzilla.redhat.com/show_bug.cgi?id=853064 LKML discussion of bug and fix http://thread.gmane.org/gmane.linux.kernel/1416336/focus=1416497Reported-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
Ed Cashin <ecashin@coraid.com> Signed-off-by:
-
Zhang Rui authored
commit b7e38304 upstream. When system enters power off, the _PSW of Lid device is enabled. But this may cause the system to reboot instead of power off. A proper way to fix this is to always disable lid wakeup capability for S5. References: https://bugzilla.kernel.org/show_bug.cgi?id=35262Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Tatyana Nikolova authored
commit 7bfcfa51 upstream. The terminate timer needs to be initialized just once. Signed-off-by:
Tatyana Nikolova <Tatyana.E.Nikolova@intel.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Tatyana Nikolova authored
commit 7d9c199a upstream. Signed-off-by:
-
Jianpeng Ma authored
commit 95ab0003 upstream. Kernel message follows: [ 511.712011] sd 11:0:0:0: [sdf] command ffff8800a4e81400 timed out [ 511.712022] sas: Enter sas_scsi_recover_host busy: 1 failed: 1 [ 511.712024] sas: trying to find task 0xffff8800a4d24c80 [ 511.712026] sas: sas_scsi_find_task: aborting task 0xffff8800a4d24c80 [ 511.712029] drivers/scsi/mvsas/mv_sas.c 1631:mvs_abort_task() mvi=ffff8800b5300000 task=ffff8800a4d24c80 slot=ffff8800b5325038 slot_idx=x0 [ 511.712035] BUG: unable to handle kernel NULL pointer dereference at 0000000000000058 [ 511.712040] IP: [<ffffffff815f8c0c>] _raw_spin_lock_irqsave+0xc/0x30 [ 511.712047] PGD 0 [ 511.712049] Oops: 0002 [#1] SMP [ 511.712052] Modules linked in: mvsas libsas scsi_transport_sas raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq async_tx [last unloaded: mvsas] [ 511.712062] CPU 3 [ 511.712066] Pid: 7322, comm: scsi_eh_11 Not tainted 3.5.0+ #106 To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M. [ 511.712068] RIP: 0010:[<ffffffff815f8c0c>] [<ffffffff815f8c0c>] _raw_spin_lock_irqsave+0xc/0x30 [ 511.712073] RSP: 0018:ffff880098d3bcb0 EFLAGS: 00010086 [ 511.712074] RAX: 0000000000000286 RBX: 0000000000000058 RCX: 00000000000000c3 [ 511.712076] RDX: 0000000000000100 RSI: 0000000000000046 RDI: 0000000000000058 [ 511.712078] RBP: ffff880098d3bcb0 R08: 000000000000000a R09: 0000000000000000 [ 511.712080] R10: 00000000000004e8 R11: 00000000000004e7 R12: ffff8800a4d24c80 [ 511.712082] R13: 0000000000000050 R14: ffff8800b5325038 R15: ffff8800a4eafe00 [ 511.712084] FS: 0000000000000000(0000) GS:ffff8800bdb80000(0000) knlGS:0000000000000000 [ 511.712086] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 511.712088] CR2: 0000000000000058 CR3: 00000000a4ce6000 CR4: 00000000000407e0 [ 511.712090] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 511.712091] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 511.712093] Process scsi_eh_11 (pid: 7322, threadinfo ffff880098d3a000, task ffff8800a61dde40) [ 511.712095] Stack: [ 511.712096] ffff880098d3bce0 ffffffff81060683 ffff880000000000 0000000000000000 [ 511.712099] ffff8800a4d24c80 ffff8800b5300000 ffff880098d3bcf0 ffffffffa0076a88 [ 511.712102] ffff880098d3bd50 ffffffffa0079bb5 ffff880000000000 ffff880000000018 [ 511.712106] Call Trace: [ 511.712110] [<ffffffff81060683>] complete+0x23/0x60 [ 511.712115] [<ffffffffa0076a88>] mvs_tmf_timedout+0x18/0x20 [mvsas] [ 511.712119] [<ffffffffa0079bb5>] mvs_slot_complete+0x765/0x7d0 [mvsas] [ 511.712125] [<ffffffffa005a17d>] sas_scsi_recover_host+0x55d/0xdb0 [libsas] [ 511.712128] [<ffffffff8106d600>] ? idle_balance+0xe0/0x130 [ 511.712133] [<ffffffff813b150c>] scsi_error_handler+0xcc/0x470 [ 511.712136] [<ffffffff815f7ad0>] ? __schedule+0x370/0x730 [ 511.712139] [<ffffffff8105f728>] ? __wake_up_common+0x58/0x90 [ 511.712142] [<ffffffff813b1440>] ? scsi_eh_get_sense+0x110/0x110 [ 511.712146] [<ffffffff810571be>] kthread+0x8e/0xa0 [ 511.712150] [<ffffffff816015f4>] kernel_thread_helper+0x4/0x10 [ 511.712153] [<ffffffff81057130>] ? flush_kthread_work+0x120/0x120 [ 511.712156] [<ffffffff816015f0>] ? gs_change+0xb/0xb [ 511.712157] Code: 8a 00 01 00 00 89 d0 f0 66 0f b1 0f 66 39 d0 0f 94 c0 0f b6 c0 5d c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 9c 58 fa ba 00 01 00 00 <f0> 66 0f c1 17 0f b6 ce 38 d1 74 11 0f 1f 84 00 00 00 00 00 f3 [ 511.712191] RIP [<ffffffff815f8c0c>] _raw_spin_lock_irqsave+0xc/0x30 [ 511.712194] RSP <ffff880098d3bcb0> [ 511.712196] CR2: 0000000000000058 [ 511.712198] ---[ end trace a781c7b1e65db92c ]--- Signed-off-by:
Jianpeng Ma <majianpeng@gmail.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 354e4aa3 ] RFC 5961 5.2 [Blind Data Injection Attack].[Mitigation] All TCP stacks MAY implement the following mitigation. TCP stacks that implement this mitigation MUST add an additional input check to any incoming segment. The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. Move tcp_send_challenge_ack() before tcp_ack() to avoid a forward declaration. Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Neal Cardwell <ncardwell@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Jerry Chu <hkchu@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit bd090dfc ] We added support for RFC 5961 in latest kernels but TCP fails to perform exhaustive check of ACK sequence. We can update our view of peer tsval from a frame that is later discarded by tcp_ack() This makes timestamps enabled sessions vulnerable to injection of a high tsval : peers start an ACK storm, since the victim sends a dupack each time it receives an ACK from the other peer. As tcp_validate_incoming() is called before tcp_ack(), we should not peform tcp_replace_ts_recent() from it, and let callers do it at the right time. Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit e3715899 ] Followup of commit 0c24604b (tcp: implement RFC 5961 4.2) As reported by Vijay Subramanian, we should send a challenge ACK instead of a dup ack if a SYN flag is set on a packet received out of window. This permits the ratelimiting to work as intended, and to increase correct SNMP counters. Suggested-by:
Vijay Subramanian <subramanian.vijay@gmail.com> Signed-off-by:
-
