- 04 Jul, 2015 35 commits
-
-
Dmitry Tunin authored
[ Upstream commit 4fa9dabc ] Lenovo G30-50 does not have a hardware wireless switch and wireless is always blocked. BugLink: https://bugs.launchpad.net/bugs/1397021Signed-off-by:
Dmitry Tunin <hanipouspilot@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Philippe Coval <philippe.coval@open.eurogiciel.org> [dvhart@linux.intel.com: Reordered dmi id per Phillippe's later version] Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
Olga Kornievskaia authored
[ Upstream commit e8d975e7 ] Problem: When an operation like WRITE receives a BAD_STATEID, even though recovery code clears the RECLAIM_NOGRACE recovery flag before recovering the open state, because of clearing delegation state for the associated inode, nfs_inode_find_state_and_recover() gets called and it makes the same state with RECLAIM_NOGRACE flag again. As a results, when we restart looking over the open states, we end up in the infinite loop instead of breaking out in the next test of state flags. Solution: unset the RECLAIM_NOGRACE set because of calling of nfs_inode_find_state_and_recover() after returning from calling recover_open() function. Signed-off-by:
Olga Kornievskaia <kolga@netapp.com> Cc: stable@vger.kernel.org Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Malcolm Priestley authored
[ Upstream commit b5eeed8c ] There is a small chance that pRD->pRDInfo->skb could go NULL while the interrupt is processing. Put NULL check on loop to break out. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Robert Schlabbach authored
[ Upstream commit fb6d1f7d ] Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset. Dissolve the function hub_port_finish_reset() completely and divide the actions to be taken into those which need to be done after each reset attempt and those which need to be done after the full procedure is complete, and place them in the appropriate places in hub_port_reset(). Also, remove an unneeded forward declaration of hub_port_reset(). Verbose Problem Description: USB 3.0 devices may be "lost for good" during a hub port reset. This makes Linux unable to boot from USB 3.0 devices in certain constellations of host controllers and devices, because the USB device is lost during initialization, preventing the rootfs from being mounted. The underlying problem is that in the affected constellations, during the processing inside hub_port_reset(), the hub link state goes from 0 to SS.inactive after the initial reset, and back to 0 again only after the following "warm" reset. However, hub_port_finish_reset() is called after each reset attempt and sets the state the connected USB device based on the "preliminary" status of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when the following warm reset is complete and hub_port_finish_reset() is called again, its call to set the device to USB_STATE_DEFAULT is blocked by usb_set_device_state() which does not allow taking USB devices out of USB_STATE_NOTATTACHED state. Thanks to Alan Stern for guiding me to the proper solution and how to submit it. Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27Signed-off-by:
Robert Schlabbach <robert_s@gmx.net> Cc: stable <stable@vger.kernel.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Haggai Eran authored
[ Upstream commit cab46214 ] With an RTL8191SU USB adaptor, sometimes the hints for a fragmented packet are set, but the packet length is too large. Allocate enough space to prevent memory corruption and a resulting kernel panic [1]. [1] http://www.spinics.net/lists/linux-wireless/msg136546.html Cc: <stable@vger.kernel.org> Signed-off-by:
Haggai Eran <haggai.eran@gmail.com> ACKed-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit e18b7975 ] In case of non-Isochronous transfers, we don't want to clear DWC3_EP_BUSY flag until XferComplete event. That's because XferInProgress was only enabled so we can recycle TRBs and usb_requests quicker, but there are still other pending requests being transferred. In order to make sure we don't allow for another StartTransfer command while the HW is still processing other transfers, we must keep DWC3_EP_BUSY flag set and this what this patch does. Fixes: f3af3651 (usb: dwc3: gadget: always enable IOC on bulk/interrupt transfers) Cc: <stable@vger.kernel.org> # v3.15+ Reported-by:
sundeep subbaraya <sundeep.lkml@gmail.com> Tested-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Richard Fitzgerald authored
[ Upstream commit 15575ed5 ] The Arizona codec drivers had an incorrect dB scaling for the noise generator gain that started at 0dB and went upwards. Actually the highest setting is 0dB. Signed-off-by:
Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Paul E. McKenney authored
[ Upstream commit 6e91f8cb ] If, at the time __rcu_process_callbacks() is invoked, there are callbacks in Tiny RCU's callback list, but none of them are ready to be invoked, the current list-management code will knit the non-ready callbacks out of the list. This can result in hangs and possibly worse. This commit therefore inserts a check for there being no callbacks that can be invoked immediately. This bug is unlikely to occur -- you have to get a new callback between the time rcu_sched_qs() or rcu_bh_qs() was called, but before we get to __rcu_process_callbacks(). It was detected by the addition of RCU-bh testing to rcutorture, which in turn was instigated by Iftekhar Ahmed's mutation testing. Although this bug was made much more likely by 915e8a4f (rcu: Remove fastpath from __rcu_process_callbacks()), this did not cause the bug, but rather made it much more probable. That said, it takes more than 40 hours of rcutorture testing, on average, for this bug to appear, so this fix cannot be considered an emergency. Signed-off-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: <stable@vger.kernel.org> Reviewed-by:
Josh Triplett <josh@joshtriplett.org> Signed-off-by:
-
Subbaraya Sundeep Bhatta authored
[ Upstream commit 76e838c9 ] We need to return error to caller if command is not sent to controller succesfully. Signed-off-by:
Subbaraya Sundeep Bhatta <sbhatta@xilinx.com> Fixes: 72246da4 (usb: Introduce DesignWare USB3 DRD Driver) Cc: <stable@vger.kernel.org> Signed-off-by:
-
Subbaraya Sundeep Bhatta authored
[ Upstream commit 891b1dc0 ] We need to return error to caller if command is not sent to controller succesfully. Signed-off-by:
-
Alex Deucher authored
[ Upstream commit 39fa10f7 ] Since we are messing with state in the worker. v2: drop the changes in the mst worker Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Vincent Fann authored
[ Upstream commit 1277fa2a ] Several of these drivers have there TX randomly blocked for 3~5 seconds while measuring tx throughput (iperf). The root couse happens in rtl_pci_flush(). The function uses a while-loop to wait for TX queue length to decrease to 0. The TX queue length counts the number of packets that are queued in the driver. The driver relys on the TX OK interrupt to return skb and reduce TX queue length. The interrupt subroutine disables interupts, reads the interrupt registers, and then clears the registers in the beginning of _rtl_pci_interrupt(). After all interupts process are finished, the driver invokes enable_interrupt() to enable interupts. This behavior is normal for an interrupt subroutine. But enable_interrupt() invokes clear_interrupt() again. This unexpected interrupt clearing may cleari me fresh TX OK interrupts. These missing interrupts cause TX queue length to never reduce to 0i, which causes rtl_pci_flush() to be stuck in unterminated while-loop. This patch removes clear_interrupt() in enable_interrupt() to avoid this behavior. Signed-off-by:
Vincent Fann <vincent_fann@realtek.com> Signed-off-by:
Shao Fu <shaofu@realtek.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Gregory CLEMENT authored
[ Upstream commit ce2f6ea1 ] The commit df59fa7f "spi: orion: support armada extended baud rates" was too optimistic for the maximum baud rate that the Armada SoCs can support. According to the hardware datasheet the maximum frequency supported by the Armada 370 SoC is tclk/4. But for the Armada XP, Armada 38x and Armada 39x SoCs the limitation is 50MHz and for the Armada 375 it is tclk/15. Currently the armada-370-spi compatible is only used by the Armada 370 and the Armada XP device tree. On Armada 370, tclk cannot be higher than 200MHz. In order to be able to handle both SoCs, we can take the minimum of 50MHz and tclk/4. A proper solution is adding a compatible string for each SoC, but it can't be done as a fix for compatibility reason (we can't modify device tree that have been already released) and it will be part of a separate patch. Fixes: df59fa7f (spi: orion: support armada extended baud rates) Reported-by:
Kostya Porotchkin <kostap@marvell.com> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
David Fries authored
[ Upstream commit f7134eea ] A temperature conversion can take 750 ms and when possible the w1_therm slave driver drops the bus_mutex to allow other bus operations, but that includes operations such as a periodic slave search, which can remove this slave when it is no longer detected. If that happens the sl->family_data will be freed and set to NULL causing w1_slave_show to crash when it wakes up. Signed-off-by:
David Fries <David@Fries.net> Reported-By:
Thorsten Bschorr <thorsten@bschorr.de> Tested-by:
Evgeniy Polyakov <zbr@ioremap.net> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Tomas Winkler authored
[ Upstream commit fe292283 ] HW has to be in known state before the initialisation sequence is started. The polling step for settling aliveness was set to 200ms while in practise this can be done in up to 30msecs. Cc: <stable@vger.kernel.org> #3.18+ Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
Barak Yoresh <barak.yoresh@intel.com> Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit 08249651 ] Refine the mechanism introduced by commit f244d8b6 ("ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug") to propagate the ignore_hotplug setting of the device to its parent bridge in case hotplug notifications related to the graphics adapter switching are given for the bridge rather than for the device itself (they need to be ignored in both cases). Link: https://bugzilla.kernel.org/show_bug.cgi?id=61891 Link: https://bugs.freedesktop.org/show_bug.cgi?id=88927 Fixes: b440bde7 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device") Reported-and-tested-by:
tiagdtd-lava <tiagdtd-lava@yahoo.de> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.17+ Signed-off-by:
-
Christoffer Dall authored
[ Upstream commit bde1b294 ] Clearly specify that "Cc: stable@vger.kernel.org" is strongly preferred so that developers understand that the other options should only be used when absolutely required. Also specify how upstream commit ids should be referenced in patches submitted directly to stable (I gathered this from looking at the stable archives), and specify that any modified patches for stable should be clearly documented in the patch description. Signed-off-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Mimi Zohar authored
[ Upstream commit f2b3dee4 ] The call to asymmetric_key_hex_to_key_id() from ca_keys_setup() silently fails with -ENOMEM. Instead of dynamically allocating memory from a __setup function, this patch defines a variable and calls __asymmetric_key_hex_to_key_id(), a new helper function, directly. This bug was introduced by 'commit 46963b77 ("KEYS: Overhaul key identification when searching for asymmetric keys")'. Changelog: - for clarification, rename hexlen to asciihexlen in asymmetric_key_hex_to_key_id() - add size argument to __asymmetric_key_hex_to_key_id() - David Howells - inline __asymmetric_key_hex_to_key_id() - David Howells - remove duplicate strlen() calls Acked-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Cc: stable@vger.kernel.org # 3.18 Signed-off-by:
-
Paolo Bonzini authored
[ Upstream commit 69a12200 ] The argument to KVM_GET_DIRTY_LOG is a memslot id; it may not match the position in the memslots array, which is sorted by gfn. Cc: stable@vger.kernel.org Reviewed-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit be34c62d ] Introduce the helper function srp_wait_for_queuecommand(). Move the definition of scsi_request_fn_active(). Add a comment above srp_wait_for_queuecommand() that support for scsi-mq needs to be added. This patch does not change any functionality. A second call to srp_wait_for_queuecommand() will be introduced in the next patch. Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Cc: James Bottomley <JBottomley@Odin.com> Cc: Sagi Grimberg <sagig@mellanox.com> Cc: Sebastian Parschauer <sebastian.riemer@profitbricks.com> Cc: <stable@vger.kernel.org> #v3.13 Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Zhichang Yuan authored
[ Upstream commit 5dbb4c61 ] 41f8bba7 ("of/pci: Add pci_register_io_range() and pci_pio_to_address()") added support for systems with several I/O ranges described by OF bindings. It modified pci_address_to_pio() look up the io_range for a given CPU physical address, but the conversion was wrong. Fix the conversion of address to I/O port. [bhelgaas: changelog] Fixes: 41f8bba7 ("of/pci: Add pci_register_io_range() and pci_pio_to_address()") Signed-off-by:
Zhichang Yuan <yuanzhichang@hisilicon.com> Signed-off-by:
Liviu Dudau <Liviu.Dudau@arm.com> CC: stable@vger.kernel.org # v3.18+ Signed-off-by:
-
Axel Lin authored
[ Upstream commit 12c35005 ] WM8955_K_8_0_MASK bits is controlled by WM8955_PLL_CONTROL_3 rather than WM8955_PLL_CONTROL_2. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Acked-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
-
Thomas Reitmayr authored
[ Upstream commit e989a73e ] Fix an oops during device initialization by correctly setting size_of_priv instead of leaving it 0. The regression was introduced by 8abe4a0a ("[media] dib7000: export just one symbol") and only fixed for one type of dib0700 based devices in 9e334c75 ("[media] Fix regression in some dib0700 based devices"). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=92301 Fixes: 8abe4a0a ("[media] dib7000: export just one symbol") Cc: stable@vger.kernel.org # for version 3.17+ Signed-off-by:
Thomas Reitmayr <treitmayr@devbase.at> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Axel Lin authored
[ Upstream commit ebb6ad73 ] VMID Control 0 BIT[2:1] is VMID Divider Enable and Select 00 = VMID disabled (for OFF mode) 01 = 2 x 50kΩ divider (for normal operation) 10 = 2 x 250kΩ divider (for low power standby) 11 = 2 x 5kΩ divider (for fast start-up) So WM8903_VMID_RES_250K should be 2 << 1, which is 4. Signed-off-by:
-
Axel Lin authored
[ Upstream commit 14ba3ec1 ] According to the datasheet: R10 (0Ah) VMID Impedance Control BIT 3:2 VMIDSEL DEFAULT 00 DESCRIPTION: VMID impedance selection control 00: 75kΩ output 01: 300kΩ output 10: 2.5kΩ output WM8737_VMIDSEL_MASK is 0xC (VMIDSEL - [3:2]), so it needs to left shift WM8737_VMIDSEL_SHIFT bits for setting these bits. Signed-off-by:
-
Axel Lin authored
[ Upstream commit 63781394 ] request_any_context_irq() returns a negative value on failure. It returns either IRQC_IS_HARDIRQ or IRQC_IS_NESTED on success. So fix testing return value of request_any_context_irq(). Also fixup the return value of devm_request_any_context_irq() to make it consistent with request_any_context_irq(). Fixes: 0668d306 ("genirq: Add devm_request_any_context_irq()") Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1431334978.17783.4.camel@ingics.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Horia Geant? authored
[ Upstream commit 69d9cd8c ] This reverts commit 7291a932. The conversion to be16_add_cpu() is incorrect in case cryptlen is negative due to premature (i.e. before addition / subtraction) implicit conversion of cryptlen (int -> u16) leading to sign loss. Cc: <stable@vger.kernel.org> # 3.10+ Cc: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
Horia Geanta <horia.geanta@freescale.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Horia Geant? authored
[ Upstream commit 5fa7dadc ] Cc: <stable@vger.kernel.org> # 3.2+ Fixes: 1d11911a ("crypto: talitos - fix warning: 'alg' may be used uninitialized in this function") Signed-off-by:
-
Grygorii Strashko authored
[ Upstream commit 084609bf ] Setting a dev_pm_ops suspend/resume pair of callbacks but not a set of hibernation callbacks means those pm functions will not be called upon hibernation - that leads to system crash on ARM during freezing if gpio-led is used in combination with CPU led trigger. It may happen after freeze_noirq stage (GPIO is suspended) and before syscore_suspend stage (CPU led trigger is suspended) - usually when disable_nonboot_cpus() is called. Log: PM: noirq freeze of devices complete after 1.425 msecs Disabling non-boot CPUs ... ^ system may crash or stuck here with message (TI AM572x) WARNING: CPU: 0 PID: 3100 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x22c/0x370() 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access CPU1: shutdown ^ or here Fix this by using SIMPLE_DEV_PM_OPS, which appropriately assigns the suspend and hibernation callbacks and move led_suspend/led_resume under CONFIG_PM_SLEEP to avoid build warnings. Fixes: 73e1ab41 (leds: Convert led class driver from legacy pm ops to dev_pm_ops) Signed-off-by:
Grygorii Strashko <Grygorii.Strashko@linaro.org> Acked-by:
Jacek Anaszewski <j.anaszewski@samsung.com> Cc: 3.11+ <stable@vger.kernel.org> # 3.11+ Signed-off-by:
-
Joe Konno authored
[ Upstream commit 0dd23f94 ] Commit 007bea09 (intel_pstate: Add setting voltage value for baytrail P states.) introduced byt_set_pstate() with the assumption that it would always be run by the CPU whose MSR is to be written by it. It turns out, however, that is not always the case in practice, so modify byt_set_pstate() to enforce the MSR write done by it to always happen on the right CPU. Fixes: 007bea09 (intel_pstate: Add setting voltage value for baytrail P states.) Signed-off-by:
Joe Konno <joe.konno@intel.com> Acked-by:
Kristen Carlson Accardi <kristen@linux.intel.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by:
-
David Härdeman authored
[ Upstream commit 4d298b85 ] commit af3a4a9b ("[media] dib0700: NEC scancode cleanup") cleaned up the NEC scancode logic but overlooked the RC5 case. This patch brings the RC5 case in line with the NEC code and makes the struct self-documenting. Signed-off-by:
David Härdeman <david@hardeman.nu> Reported-by:
David Cimbůrek <david.cimburek@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Brian Norris authored
[ Upstream commit 073db4a5 ] On A MIPS 32-cores machine a BUG_ON was triggered because some acesses to mtd->usecount were done without taking mtd_table_mutex. kernel: Call Trace: kernel: [<ffffffff80401818>] __put_mtd_device+0x20/0x50 kernel: [<ffffffff804086f4>] blktrans_release+0x8c/0xd8 kernel: [<ffffffff802577e0>] __blkdev_put+0x1a8/0x200 kernel: [<ffffffff802579a4>] blkdev_close+0x1c/0x30 kernel: [<ffffffff8022006c>] __fput+0xac/0x250 kernel: [<ffffffff80171208>] task_work_run+0xd8/0x120 kernel: [<ffffffff8012c23c>] work_notifysig+0x10/0x18 kernel: kernel: Code: 2442ffff ac8202d8 000217fe <00020336> dc820128 10400003 00000000 0040f809 00000000 kernel: ---[ end trace 080fbb4579b47a73 ]--- Fixed by taking the mutex in blktrans_open and blktrans_release. Note that this locking is already suggested in include/linux/mtd/blktrans.h: struct mtd_blktrans_ops { ... /* Called with mtd_table_mutex held; no race with add/remove */ int (*open)(struct mtd_blktrans_dev *dev); void (*release)(struct mtd_blktrans_dev *dev); ... }; But we weren't following it. Originally reported by (and patched by) Zhang and Giuseppe, independently. Improved and rewritten. Cc: stable@vger.kernel.org Reported-by:
Zhang Xingcai <zhangxingcai@huawei.com> Reported-by:
Giuseppe Cantavenera <giuseppe.cantavenera.ext@nokia.com> Tested-by:
Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
Martin Sperl authored
[ Upstream commit 8e76ef88 ] Fix a race (with some kernel configurations) where a queued master->pump_messages runs and frees dummy_tx/rx before spi_unmap_msg is running (or is finished). This results in the following messages: BUG: Bad page state in process page:db7ba030 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x200(arch_1) page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set ... Reported-by:
Noralf Trønnes <noralf@tronnes.org> Suggested-by:
Martin Sperl <kernel@martin.sperl.org> Signed-off-by:
-
Dmitry Osipenko authored
[ Upstream commit 4d48edb3 ] Commit 7232398a ("ARM: tegra: Convert PMC to a driver") changed tegra_resume() location storing from late to early and, as a result, broke suspend on Tegra20. PMC scratch register 41 is used by tegra LP1 resume code for retrieving stored physical memory address of common resume function and in the same time used by tegra20_cpu_shutdown() (shared by Tegra20 cpuidle driver and platform SMP code), which is storing CPU1 "resettable" status. It implies strict order of scratch register usage, otherwise resume function address is lost on Tegra20 after disabling non-boot CPU's on suspend. Fix it by storing "resettable" status in IRAM instead of PMC scratch register. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Fixes: 7232398a (ARM: tegra: Convert PMC to a driver) Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Pawel Moll authored
[ Upstream commit a18f8e97 ] Events defined as watchpoints on nodes must have their config values converted so that they apply to the respective node's XP. The function setting new values was using wrong mask for the "port" field, resulting in corrupted value. Fixed now. Cc: stable@vger.kernel.org # 3.17+ Signed-off-by:
Pawel Moll <pawel.moll@arm.com> Signed-off-by:
-
- 03 Jul, 2015 5 commits
-
-
Mauro Carvalho Chehab authored
[ Upstream commit 82e3b88b ] The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up much more values: drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg() error: buffer overflow 'd->msg' 6 <= 23 Cc: stable@vger.kernel.org Signed-off-by:
-
Mauro Carvalho Chehab authored
[ Upstream commit d7b76c91 ] If userspace sends an invalid bandwidth, it should either return EINVAL or switch to auto mode. This driver will go past an array and program the hardware on a wrong way if this happens. Cc: stable@vger.kernel.org Signed-off-by:
-
Mauro Carvalho Chehab authored
[ Upstream commit 1fa2337a ] The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up much more values: drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg() error: buffer overflow 'd->msg' 6 <= 23 Cc: stable@vger.kernel.org Signed-off-by:
-
Mauro Carvalho Chehab authored
[ Upstream commit 12f4543f ] The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up to 7 values: drivers/media/dvb-frontends/s5h1420.c:193 s5h1420_send_master_cmd() error: buffer overflow 'cmd->msg' 6 <= 7 Cc: stable@vger.kernel.org Signed-off-by:
-
Sagi Grimberg authored
[ Upstream commit 2f1b6b7d ] When receiving a new iser connect request we serialize the pending requests by adding the newly created iser connection to the np accept list and let the login thread process the connect request one by one (np_accept_wait). In case we received a disconnect request before the iser_conn has begun processing (still linked in np_accept_list) we should detach it from the list and clean it up and not have the login thread process a stale connection. We do it only when the connection state is not already terminating (initiator driven disconnect) as this might lead us to access np_accept_mutex after the np was released in live shutdown scenarios. Signed-off-by:
Sagi Grimberg <sagig@mellanox.com> Signed-off-by:
Jenny Falkovich <jennyf@mellanox.com> Cc: stable@vger.kernel.org # 3.10+ Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
