| Age | Commit message (Collapse) | Author |
|---|
|
commit a36aa80f3cb2540fb1dbad6240852de4365a2e82 upstream.
Driver initialization tries to request a hub (GTH) driver module from
its probe callback, resulting in a deadlock.
This patch solves the problem by adding a deferred work for requesting
the hub module.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7a1a47ce35821b40f5b2ce46379ba14393bc3873 upstream.
This adds Intel(R) Trace Hub PCI ID for Kaby Lake PCH-H.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 06708f81528725148473c0869d6af5f809c6824b upstream.
Commit aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") intended to
set coalescing threshold to a value guaranteeing interrupt generation
per each sent packet, so that buffers can be released with no delay.
In fact setting threshold to '1' was wrong, because it causes interrupt
every two packets. According to the documentation a reason behind it is
following - interrupt occurs once sent buffers counter reaches a value,
which is higher than one specified in MVNETA_TXQ_SIZE_REG(q). This
behavior was confirmed during tests. Also when testing the SoC working
as a NAS device, better performance was observed with int-per-packet,
as it strongly depends on the fact that all transmitted packets are
released immediately.
This commit enables NETA controller work in interrupt per sent packet mode
by setting coalescing threshold to 0.
Signed-off-by: Dmitri Epshtein <dima@marvell.com>
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Fixes aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay")
Acked-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1488a1e3828d60d74c9b802a05e24c0487babe4e upstream.
Since 34b48db66e08 ("block: remove artifical max_hw_sectors cap"),
max_sectors is no longer limited to BLK_DEF_MAX_SECTORS and LITE-ON
CX1-JB256-HP keeps timing out with higher max_sectors. Revert it to
the previous value.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: dgerasimov@gmail.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=121671
Fixes: 34b48db66e08 ("block: remove artifical max_hw_sectors cap")
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 22ebf00eb56fe77922de8138aa9af9996582c2b3 upstream.
of_address_to_resource return 0 on successful call but
devm_ioremap_resource is called only if it returns non-zero value
Signed-off-by: Lukasz Gemborowski <lukasz.gemborowski@nokia.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d4f56c7773483b8829e89cfc739b7a5a071f6da0 upstream.
index gets incremented during check to determine if the
messages can be transferred with dma. But not reset after
that, resulting in wrong start value in subsequent loop,
causing failure. Fix it.
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6519c3d7b8621c9f4333c98ed4b703029b51ba79 upstream.
The dv_timings_cap() and enum_dv_timings() pad operations take a pad
number as an input argument and return the DV timings capabilities and
list of supported DV timings for that pad.
Commit bd3e275f3ec0 ("[media] media: i2c: adv7604: Use v4l2-dv-timings
helpers") broke this as it started ignoring the pad number, always
returning the information associated with the currently selected input.
Fix it.
Fixes: bd3e275f3ec0 ("[media] media: i2c: adv7604: Use v4l2-dv-timings helpers")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit aa93d1fee85c890a34f2510a310e55ee76a27848 upstream.
Fix a memory leak on probe error of the airspy usb device driver.
The problem is triggered when more than 64 usb devices register with
v4l2 of type VFL_TYPE_SDR or VFL_TYPE_SUBDEV.
The memory leak is caused by the probe function of the airspy driver
mishandeling errors and not freeing the corresponding control structures
when an error occours registering the device to v4l2 core.
A badusb device can emulate 64 of these devices, and then through
continual emulated connect/disconnect of the 65th device, cause the
kernel to run out of RAM and crash the kernel, thus causing a local DOS
vulnerability.
Fixes CVE-2016-5400
Signed-off-by: James Patrick-Evans <james@jmp-e.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 54e430bbd490e18ab116afa4cd90dcc45787b3df upstream.
If we fall back to using LSI on the Croc or Crocodile chip we need to
clear the interrupt so we don't hang the system.
Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5e7ff2ca7f2da55fe777167849d0c93403bd0dc8 upstream.
Commit b704f70ce200 ("SCSI: fix bug in scsi_dev_info_list matching")
changed the way vendor- and model-string matching was carried out in the
routine that looks up entries in a SCSI devinfo list. The new matching
code failed to take into account the case of a maximum-length string; in
such cases it could end up testing for a terminating '\0' byte beyond
the end of the memory allocated to the string. This out-of-bounds bug
was detected by UBSAN.
I don't know if anybody has actually encountered this bug. The symptom
would be that a device entry in the blacklist might not be matched
properly if it contained an 8-character vendor name or a 16-character
model name. Such entries certainly exist in scsi_static_device_list.
This patch fixes the problem by adding a check for a maximum-length
string before the '\0' test.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Fixes: b704f70ce200 ("SCSI: fix bug in scsi_dev_info_list matching")
Tested-by: Wilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 262e2bfd7d1e1f1ee48b870e5dfabb87c06b975e upstream.
In qla24xx_process_response_queue() rsp->msix->cpuid may trigger NULL
pointer dereference when rsp->msix is NULL:
[ 5.622457] NULL pointer dereference at 0000000000000050
[ 5.622457] IP: [<ffffffff8155e614>] qla24xx_process_response_queue+0x44/0x4b0
[ 5.622457] PGD 0
[ 5.622457] Oops: 0000 [#1] SMP
[ 5.622457] Modules linked in:
[ 5.622457] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.6.3-x86_64 #1
[ 5.622457] Hardware name: HP ProLiant DL360 G5, BIOS P58 05/02/2011
[ 5.622457] task: ffff8801a88f3740 ti: ffff8801a8954000 task.ti: ffff8801a8954000
[ 5.622457] RIP: 0010:[<ffffffff8155e614>] [<ffffffff8155e614>] qla24xx_process_response_queue+0x44/0x4b0
[ 5.622457] RSP: 0000:ffff8801afb03de8 EFLAGS: 00010002
[ 5.622457] RAX: 0000000000000000 RBX: 0000000000000032 RCX: 00000000ffffffff
[ 5.622457] RDX: 0000000000000002 RSI: ffff8801a79bf8c8 RDI: ffff8800c8f7e7c0
[ 5.622457] RBP: ffff8801afb03e68 R08: 0000000000000000 R09: 0000000000000000
[ 5.622457] R10: 00000000ffff8c47 R11: 0000000000000002 R12: ffff8801a79bf8c8
[ 5.622457] R13: ffff8800c8f7e7c0 R14: ffff8800c8f60000 R15: 0000000000018013
[ 5.622457] FS: 0000000000000000(0000) GS:ffff8801afb00000(0000) knlGS:0000000000000000
[ 5.622457] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 5.622457] CR2: 0000000000000050 CR3: 0000000001e07000 CR4: 00000000000006e0
[ 5.622457] Stack:
[ 5.622457] ffff8801afb03e30 ffffffff810c0f2d 0000000000000086 0000000000000002
[ 5.622457] ffff8801afb03e28 ffffffff816570e1 ffff8800c8994628 0000000000000002
[ 5.622457] ffff8801afb03e60 ffffffff816772d4 b47c472ad6955e68 0000000000000032
[ 5.622457] Call Trace:
[ 5.622457] <IRQ>
[ 5.622457] [<ffffffff810c0f2d>] ? __wake_up_common+0x4d/0x80
[ 5.622457] [<ffffffff816570e1>] ? usb_hcd_resume_root_hub+0x51/0x60
[ 5.622457] [<ffffffff816772d4>] ? uhci_hub_status_data+0x64/0x240
[ 5.622457] [<ffffffff81560d00>] qla24xx_intr_handler+0xf0/0x2e0
[ 5.622457] [<ffffffff810d569e>] ? get_next_timer_interrupt+0xce/0x200
[ 5.622457] [<ffffffff810c89b4>] handle_irq_event_percpu+0x64/0x100
[ 5.622457] [<ffffffff810c8a77>] handle_irq_event+0x27/0x50
[ 5.622457] [<ffffffff810cb965>] handle_edge_irq+0x65/0x140
[ 5.622457] [<ffffffff8101a498>] handle_irq+0x18/0x30
[ 5.622457] [<ffffffff8101a276>] do_IRQ+0x46/0xd0
[ 5.622457] [<ffffffff817f8fff>] common_interrupt+0x7f/0x7f
[ 5.622457] <EOI>
[ 5.622457] [<ffffffff81020d38>] ? mwait_idle+0x68/0x80
[ 5.622457] [<ffffffff8102114a>] arch_cpu_idle+0xa/0x10
[ 5.622457] [<ffffffff810c1b97>] default_idle_call+0x27/0x30
[ 5.622457] [<ffffffff810c1d3b>] cpu_startup_entry+0x19b/0x230
[ 5.622457] [<ffffffff810324c6>] start_secondary+0x136/0x140
[ 5.622457] Code: 00 00 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 48 8b 47 58 a8 02 0f 84 c5 00 00 00 48 8b 46 50 49 89 f4 65 8b 15 34 bb aa 7e <39> 50 50 74 11 89 50 50 48 8b 46 50 8b 40 50 41 89 86 60 8b 00
[ 5.622457] RIP [<ffffffff8155e614>] qla24xx_process_response_queue+0x44/0x4b0
[ 5.622457] RSP <ffff8801afb03de8>
[ 5.622457] CR2: 0000000000000050
[ 5.622457] ---[ end trace fa2b19c25106d42b ]---
[ 5.622457] Kernel panic - not syncing: Fatal exception in interrupt
The affected code was introduced by commit cdb898c52d1dfad4b4800b83a58b3fe5d352edde
(qla2xxx: Add irq affinity notification).
Only dereference rsp->msix when it has been set so the machine can boot
fine. Possibly rsp->msix is unset because:
[ 3.479679] qla2xxx [0000:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 8.07.00.33-k.
[ 3.481839] qla2xxx [0000:13:00.0]-001d: : Found an ISP2432 irq 17 iobase 0xffffc90000038000.
[ 3.484081] qla2xxx [0000:13:00.0]-0035:0: MSI-X; Unsupported ISP2432 (0x2, 0x3).
[ 3.485804] qla2xxx [0000:13:00.0]-0037:0: Falling back-to MSI mode -258.
[ 3.890145] scsi host0: qla2xxx
[ 3.891956] qla2xxx [0000:13:00.0]-00fb:0: QLogic QLE2460 - PCI-Express Single Channel 4Gb Fibre Channel HBA.
[ 3.894207] qla2xxx [0000:13:00.0]-00fc:0: ISP2432: PCIe (2.5GT/s x4) @ 0000:13:00.0 hdma+ host#=0 fw=7.03.00 (9496).
[ 5.714774] qla2xxx [0000:13:00.0]-500a:0: LOOP UP detected (4 Gbps).
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
Acked-by: Quinn Tran <quinn.tran@qlogic.com>
Fixes: cdb898c52d1dfad4b4800b83a58b3fe5d352edde
Signed-off-by: James Bottomley <jejb@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 547aefc4db877e65245c3d95fcce703701bf3a0c upstream.
Commit fbde2d7d8290 ("MIPS: Add generic SMP IPI support") introduced
code which calls irq_find_matching_host with a NULL node parameter in
order to discover IPI IRQ domains which are not associated with the DT
root node's interrupt parent. This suggests that implementations of IPI
IRQ domains should effectively ignore the node parameter if it is NULL
and search purely based upon the bus token. Commit 2af70a962070
("irqchip/mips-gic: Add a IPI hierarchy domain") did not do this when
implementing the GIC IPI IRQ domain, and on MIPS Boston boards this
leads to no IPI domain being discovered and a NULL pointer dereference
when attempting to send an IPI:
CPU 0 Unable to handle kernel paging request at virtual address 0000000000000040, epc == ffffffff8016e70c, ra == ffffffff8010ff5c
Oops[#1]:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc6-00223-gad0d1b6 #945
task: a8000000ff066fc0 ti: a8000000ff068000 task.ti: a8000000ff068000
$ 0 : 0000000000000000 0000000000000001 ffffffff80730000 0000000000000003
$ 4 : 0000000000000000 ffffffff8057e5b0 a800000001e3ee00 0000000000000000
$ 8 : 0000000000000000 0000000000000023 0000000000000001 0000000000000001
$12 : 0000000000000000 ffffffff803323d0 0000000000000000 0000000000000000
$16 : 0000000000000000 0000000000000000 0000000000000001 ffffffff801108fc
$20 : 0000000000000000 ffffffff8057e5b0 0000000000000001 0000000000000000
$24 : 0000000000000000 ffffffff8012de28
$28 : a8000000ff068000 a8000000ff06fbc0 0000000000000000 ffffffff8010ff5c
Hi : ffffffff8014c174
Lo : a800000001e1e140
epc : ffffffff8016e70c __ipi_send_mask+0x24/0x11c
ra : ffffffff8010ff5c mips_smp_send_ipi_mask+0x68/0x178
Status: 140084e2 KX SX UX KERNEL EXL
Cause : 00800008 (ExcCode 02)
BadVA : 0000000000000040
PrId : 0001a920 (MIPS I6400)
Process swapper/0 (pid: 1, threadinfo=a8000000ff068000, task=a8000000ff066fc0, tls=0000000000000000)
Stack : 0000000000000000 0000000000000000 0000000000000001 ffffffff801108fc
0000000000000000 ffffffff8057e5b0 0000000000000001 ffffffff8010ff5c
0000000000000001 0000000000000020 0000000000000000 0000000000000000
0000000000000000 ffffffff801108fc 0000000000000000 0000000000000001
0000000000000001 0000000000000000 0000000000000000 ffffffff801865e8
a8000000ff0c7500 a8000000ff06fc90 0000000000000001 0000000000000002
ffffffff801108fc ffffffff801868b8 0000000000000000 ffffffff801108fc
0000000000000000 0000000000000003 ffffffff8068c700 0000000000000001
ffffffff80730000 0000000000000001 a8000000ff00a290 ffffffff80110c50
0000000000000003 a800000001e48308 0000000000000003 0000000000000008
...
Call Trace:
[<ffffffff8016e70c>] __ipi_send_mask+0x24/0x11c
[<ffffffff8010ff5c>] mips_smp_send_ipi_mask+0x68/0x178
[<ffffffff801865e8>] generic_exec_single+0x150/0x170
[<ffffffff801868b8>] smp_call_function_single+0x108/0x160
[<ffffffff80110c50>] cps_boot_secondary+0x328/0x394
[<ffffffff80110534>] __cpu_up+0x38/0x90
[<ffffffff8012de4c>] bringup_cpu+0x24/0xac
[<ffffffff8012df40>] cpuhp_up_callbacks+0x58/0xdc
[<ffffffff8012e648>] cpu_up+0x118/0x18c
[<ffffffff806dc158>] smp_init+0xbc/0xe8
[<ffffffff806d4c18>] kernel_init_freeable+0xa0/0x228
[<ffffffff8056c908>] kernel_init+0x10/0xf0
[<ffffffff80105098>] ret_from_kernel_thread+0x14/0x1c
Fix this by allowing the GIC IPI IRQ domain to match purely based upon
the bus token if the node provided is NULL.
Fixes: 2af70a962070 ("irqchip/mips-gic: Add a IPI hierarchy domain")
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Qais Yousef <qsyousef@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Link: http://lkml.kernel.org/r/20160705132600.27730-2-paul.burton@imgtec.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 99ec8a3608330d202448085185cf28389b789b7b upstream.
When mapping an interrupt to a VP(E) we must use the identifier for the
VP that the hardware expects, and this does not always match up with the
Linux CPU number. Commit d46812bb0bef ("irqchip: mips-gic: Use HW IDs
for VPE_OTHER_ADDR") corrected this for the cases that existed at the
time it was written, but commit 2af70a962070 ("irqchip/mips-gic: Add a
IPI hierarchy domain") added another case before the former patch was
merged. This leads to incorrectly using Linux CPU numbers when mapping
interrupts to VPs, which breaks on certain systems such as those with
multi-core I6400 CPUs. Fix by adding the appropriate call to
mips_cm_vp_id() to retrieve the expected VP identifier.
Fixes: d46812bb0bef ("irqchip: mips-gic: Use HW IDs for VPE_OTHER_ADDR")
Fixes: 2af70a962070 ("irqchip/mips-gic: Add a IPI hierarchy domain")
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Qais Yousef <qsyousef@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Link: http://lkml.kernel.org/r/20160705132600.27730-1-paul.burton@imgtec.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 25e1ed6e64f52a692ba3191c4fde650aab3ecc07 upstream.
For 'real' hardware CAN devices the netlink interface is used to set CAN
specific communication parameters. Real CAN hardware can not be created nor
removed with the ip tool ...
This patch adds a private dellink function for the CAN device driver interface
that does just nothing.
It's a follow up to commit 993e6f2fd ("can: fix oops caused by wrong rtnl
newlink usage") but for dellink.
Reported-by: ajneu <ajneu1@gmail.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit bce271f255dae8335dc4d2ee2c4531e09cc67f5a upstream.
With upstream commit bb208f144cf3f59 (can: fix handling of unmodifiable
configuration options) a new can_validate() function was introduced.
When invoking 'ip link set can0 type can' without any configuration data
can_validate() tries to validate the content without taking into account that
there's totally no content. This patch adds a check for missing content.
Reported-by: ajneu <ajneu1@gmail.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
access
commit 427460c83cdf55069eee49799a0caef7dde8df69 upstream.
When testing CAN write floods on Altera's CycloneV, the first 2 bytes
are sometimes 0x00, 0x00 or corrupted instead of the values sent. Also
observed bytes 4 & 5 were corrupted in some cases.
The D_CAN Data registers are 32 bits and changing from 16 bit writes to
32 bit writes fixes the problem.
Testing performed on Altera CycloneV (D_CAN). Requesting tests on other
C_CAN & D_CAN platforms.
Reported-by: Richard Andrysek <richard.andrysek@gomtec.de>
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 43200a4480cbbe660309621817f54cbb93907108 upstream.
At high bus load it could happen that "at91_poll()" enters with all RX
message boxes filled up. If then at the end the "quota" is exceeded as
well, "rx_next" will not be reset to the first RX mailbox and hence the
interrupts remain disabled.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Tested-by: Amr Bekhit <amrbekhit@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f68381a70bb2b26c31b13fdaf67c778f92fd32b4 upstream.
The code that fills packed command header assumes that CPU runs in
little-endian mode. Hence the header is malformed in big-endian mode
and causes MMC data transfer errors:
[ 563.200828] mmcblk0: error -110 transferring data, sector 2048, nr 8, cmd response 0x900, card status 0xc40
[ 563.219647] mmcblk0: packed cmd failed, nr 2, sectors 16, failure index: -1
Convert header data to LE.
Signed-off-by: Taras Kondratiuk <takondra@cisco.com>
Fixes: ce39f9d17c14 ("mmc: support packed write command for eMMC4.5 devices")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit bfe5b1b1e013f7b1c0fd2ac3b3c8c380114b3fb9 upstream.
Set 'idata->buf' to NULL so that it never gets returned without
initialization. This fixes a bug where mmc_blk_ioctl_cmd() would
free both 'idata' and 'idata->buf' but 'idata->buf' was returned
uninitialized.
Fixes: 1ff8950c0433 ("mmc: block: change to use kmalloc when copy data from userspace")
Signed-off-by: Ville Viinikka <ville@tuxera.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7831b4ff0d926e0deeaabef9db8800ed069a2757 upstream.
A qeth_card contains a napi_struct linked to the net_device during
device probing. This struct must be deleted when removing the qeth
device, otherwise Panic on oops can occur when qeth devices are
repeatedly removed and added.
Fixes: a1c3ed4c9ca ("qeth: NAPI support for l2 and l3 discipline")
Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
Tested-by: Alexander Klein <ALKL@de.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 096cdc6f52225835ff503f987a0d68ef770bb78e upstream.
We verify "u_cmd.outsize" and "u_cmd.insize" but we need to make sure
that those values have not changed between the two copy_from_user()
calls. Otherwise it could lead to a buffer overflow.
Additionally, cros_ec_cmd_xfer() can set s_cmd->insize to a lower value.
We should use the new smaller value so we don't copy too much data to
the user.
Reported-by: Pengfei Wang <wpengfeinudt@gmail.com>
Fixes: a841178445bb ('mfd: cros_ec: Use a zero-length array for command data')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f96423f483b1a7854270335b319e8d1cdd6f3585 upstream.
Since commit 1bdf02326b71e ("clk: at91: make use of syscon/regmap
internally"), clk_programmable_set_parent() is always selecting the
first parent (AKA slow_clk), no matter what's passed in the 'index'
parameter.
Fix that by initializing the pckr variable to the index value.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Hans Verkuil <hans.verkuil@cisco.com>
Fixes: 1bdf02326b71e ("clk: at91: make use of syscon/regmap internally")
Signed-off-by: Michael Turquette <mturquette@baylibre.com>
Link: lkml.kernel.org/r/1468828152-18389-1-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 595144c1141c951a3c6bb9004ae6a2bc29aad66f upstream.
The flags element of clk_init_data was never initialized for mmc-
phase-clocks resulting in the element containing a random value
and thus possibly enabling unwanted clock flags.
Fixes: 89bf26cbc1a0 ("clk: rockchip: Add support for the mmc clock phases using the framework")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6d9fe44bd73d567d04d3a68a2d2fa521ab9532f2 upstream.
When testing SPI without DMA I noticed that filling the FIFO on the
spi controller causes timeout.
Always leave room for one byte in the FIFO.
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 719bd6542044efd9b338a53dba1bef45f40ca169 upstream.
The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over
1MHz SPI bus takes way longer than that. Calculate the timeout from the
actual time the transfer is supposed to take and multiply by 2 for good
measure.
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4dc0dd83603f05dc3ae152af33ecb15104c313f3 upstream.
When using DMA, the transfer_one callback should return 1 because the
transfer hasn't finished yet.
A previous commit changed the function to return 0 when the DMA channels
were correctly prepared.
This manifested in Veyron boards with this message:
[ 1.983605] cros-ec-spi spi0.0: EC failed to respond in time
Fixes: ea9849113343 ("spi: rockchip: check return value of dmaengine_prep_slave_sg")
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5353ed8deedee9e5acb9f896e9032158f5d998de upstream.
An ENOMEM when creating a pair tty in tty_ldisc_setup causes a null
pointer dereference in devpts_kill_index because tty->link->driver_data
is NULL. The oops was triggered with the pty stressor in stress-ng when
in a low memory condition.
tty_init_dev tries to clean up a tty_ldisc_setup ENOMEM error by calling
release_tty, however, this ultimately tries to clean up the NULL pair'd
tty in pty_unix98_remove, triggering the Oops.
Add check to pty_unix98_remove to only clean up fsi if it is not NULL.
Ooops:
[ 23.020961] Oops: 0000 [#1] SMP
[ 23.020976] Modules linked in: ppdev snd_hda_codec_generic snd_hda_intel snd_hda_codec parport_pc snd_hda_core snd_hwdep parport snd_pcm input_leds joydev snd_timer serio_raw snd soundcore i2c_piix4 mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel qxl aes_x86_64 ttm lrw gf128mul glue_helper ablk_helper drm_kms_helper cryptd syscopyarea sysfillrect psmouse sysimgblt floppy fb_sys_fops drm pata_acpi jitterentropy_rng drbg ansi_cprng
[ 23.020978] CPU: 0 PID: 1452 Comm: stress-ng-pty Not tainted 4.7.0-rc4+ #2
[ 23.020978] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 23.020979] task: ffff88007ba30000 ti: ffff880078ea8000 task.ti: ffff880078ea8000
[ 23.020981] RIP: 0010:[<ffffffff813f11ff>] [<ffffffff813f11ff>] ida_remove+0x1f/0x120
[ 23.020981] RSP: 0018:ffff880078eabb60 EFLAGS: 00010a03
[ 23.020982] RAX: 4444444444444567 RBX: 0000000000000000 RCX: 000000000000001f
[ 23.020982] RDX: 000000000000014c RSI: 000000000000026f RDI: 0000000000000000
[ 23.020982] RBP: ffff880078eabb70 R08: 0000000000000004 R09: 0000000000000036
[ 23.020983] R10: 000000000000026f R11: 0000000000000000 R12: 000000000000026f
[ 23.020983] R13: 000000000000026f R14: ffff88007c944b40 R15: 000000000000026f
[ 23.020984] FS: 00007f9a2f3cc700(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
[ 23.020984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 23.020985] CR2: 0000000000000010 CR3: 000000006c81b000 CR4: 00000000001406f0
[ 23.020988] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 23.020988] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 23.020988] Stack:
[ 23.020989] 0000000000000000 000000000000026f ffff880078eabb90 ffffffff812a5a99
[ 23.020990] 0000000000000000 00000000fffffff4 ffff880078eabba8 ffffffff814f9cbe
[ 23.020991] ffff88007965c800 ffff880078eabbc8 ffffffff814eef43 fffffffffffffff4
[ 23.020991] Call Trace:
[ 23.021000] [<ffffffff812a5a99>] devpts_kill_index+0x29/0x50
[ 23.021002] [<ffffffff814f9cbe>] pty_unix98_remove+0x2e/0x50
[ 23.021006] [<ffffffff814eef43>] release_tty+0xb3/0x1b0
[ 23.021007] [<ffffffff814f18d4>] tty_init_dev+0xd4/0x1c0
[ 23.021011] [<ffffffff814f9fae>] ptmx_open+0xae/0x190
[ 23.021013] [<ffffffff812254ef>] chrdev_open+0xbf/0x1b0
[ 23.021015] [<ffffffff8121d973>] do_dentry_open+0x203/0x310
[ 23.021016] [<ffffffff81225430>] ? cdev_put+0x30/0x30
[ 23.021017] [<ffffffff8121ee44>] vfs_open+0x54/0x80
[ 23.021018] [<ffffffff8122b8fc>] ? may_open+0x8c/0x100
[ 23.021019] [<ffffffff8122f26b>] path_openat+0x2eb/0x1440
[ 23.021020] [<ffffffff81230534>] ? putname+0x54/0x60
[ 23.021022] [<ffffffff814f6f97>] ? n_tty_ioctl_helper+0x27/0x100
[ 23.021023] [<ffffffff81231651>] do_filp_open+0x91/0x100
[ 23.021024] [<ffffffff81230596>] ? getname_flags+0x56/0x1f0
[ 23.021026] [<ffffffff8123fc66>] ? __alloc_fd+0x46/0x190
[ 23.021027] [<ffffffff8121f1e4>] do_sys_open+0x124/0x210
[ 23.021028] [<ffffffff8121f2ee>] SyS_open+0x1e/0x20
[ 23.021035] [<ffffffff81845576>] entry_SYSCALL_64_fastpath+0x1e/0xa8
[ 23.021044] Code: 63 28 45 31 e4 eb dd 0f 1f 44 00 00 55 4c 63 d6 48 ba 89 88 88 88 88 88 88 88 4c 89 d0 b9 1f 00 00 00 48 f7 e2 48 89 e5 41 54 53 <8b> 47 10 48 89 fb 8d 3c c5 00 00 00 00 48 c1 ea 09 b8 01 00 00
[ 23.021045] RIP [<ffffffff813f11ff>] ida_remove+0x1f/0x120
[ 23.021045] RSP <ffff880078eabb60>
[ 23.021046] CR2: 0000000000000010
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 742c87bf27d3b715820da6f8a81d6357adbf18f8 upstream.
CPU notifications from the firmware coming in when cpufreq is
suspended cause cpufreq_update_current_freq() to return 0 which
triggers the WARN_ON() in cpufreq_update_policy() for no reason.
Avoid that by checking cpufreq_suspended before calling
cpufreq_update_current_freq().
Fixes: c9d9c929e674 (cpufreq: Abort cpufreq_update_current_freq() for cpufreq_suspended set)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5bc28b93a36e3cb3acc2870fb75cb6ffb182fece upstream.
Change power_supply_read_temp() to use power_supply_get_property()
so that it will check the use_cnt and ensure it is > 0. The use_cnt
will be incremented at the end of __power_supply_register, so this
will block to case where get_property can be called before the supply
is fully registered. This fixes the issue show in the stack below:
[ 1.452598] power_supply_read_temp+0x78/0x80
[ 1.458680] thermal_zone_get_temp+0x5c/0x11c
[ 1.464765] thermal_zone_device_update+0x34/0xb4
[ 1.471195] thermal_zone_device_register+0x87c/0x8cc
[ 1.477974] __power_supply_register+0x364/0x424
[ 1.484317] power_supply_register_no_ws+0x10/0x18
[ 1.490833] bq27xxx_battery_setup+0x10c/0x164
[ 1.497003] bq27xxx_battery_i2c_probe+0xd0/0x1b0
[ 1.503435] i2c_device_probe+0x174/0x240
[ 1.509172] driver_probe_device+0x1fc/0x29c
[ 1.515167] __driver_attach+0xa4/0xa8
[ 1.520643] bus_for_each_dev+0x58/0x98
[ 1.526204] driver_attach+0x20/0x28
[ 1.531505] bus_add_driver+0x1c8/0x22c
[ 1.537067] driver_register+0x68/0x108
[ 1.542630] i2c_register_driver+0x38/0x7c
[ 1.548457] bq27xxx_battery_i2c_driver_init+0x18/0x20
[ 1.555321] do_one_initcall+0x38/0x12c
[ 1.560886] kernel_init_freeable+0x148/0x1ec
[ 1.566972] kernel_init+0x10/0xfc
[ 1.572101] ret_from_fork+0x10/0x40
Also make the same change to ps_get_max_charge_cntl_limit() and
ps_get_cur_chrage_cntl_limit() to be safe. Lastly, change the return
value of power_supply_get_property() to -EAGAIN from -ENODEV if
use_cnt <= 0.
Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core")
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ba562d5e54fd3136bfea0457add3675850247774 upstream.
Some PINs do not have a MUX register, it is not an error.
It is necessary to allow the continuation of the PINs configuration,
otherwise the whole PIN-group will be configured incorrectly.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0ac3c0a4025f41748a083bdd4970cb3ede802b15 upstream.
With many repeated suspend resume cycles, the pin specific wakeirq
may not always work on omaps. This is because the write to enable the
pin interrupt may not have reached the device over the interconnect
before suspend happens.
Let's fix the issue with a flush of posted write with a readback.
Reported-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e9003c9cfaa17d26991688268b04244adb67ee2b upstream.
Passes input_id struct to the common probe function for the tsc200x drivers
instead of just the bustype.
This allows for the use of the product variable to set the input_dev->name
variable according to the type of touchscreen used. Note that when we
introduced support for TSC2004 we started calling everything TSC200X, so
let's keep this quirk.
Signed-off-by: Michael Welling <mwelling@ieee.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e4add7b6beaff4061693d0632bc1dcb306edba10 upstream.
According to the RMI4 spec the maximum size of F12 control register 8 is
15 bytes. The current code incorrectly reports an error if control 8 is
greater then 14. Making sensors with a control register 8 with 15 bytes
unusable.
Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Reported-by: Chris Healy <cphealy@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3e9161bfe0482f26efeaf584d5fd69398c69313c upstream.
This reverts commit 5f7e5445a2de848c66d2d80ba5479197e8287c33 because
removal of input_mt_report_slot_state() means we no longer generate
tracking IDs for the reported contacts.
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pinglinux@gmail.com>
|
|
commit caca925fca4fb30c67be88cacbe908eec6721e43 upstream.
This prevents a malicious USB device from causing an oops.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9e72ac7492149a229ce9039c680849cb682d7092 upstream.
ThinkPad X60 Tablet PC (pen only device) sometime posts
packets that are larger than W8001_PKTLEN_TPCPEN.
Reported-by: Chris J Arges <christopherarges@gmail.com>
Tested-by: Chris J Arges <christopherarges@gmail.com>
Signed-off-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 12afb34400eb2b301f06b2aa3535497d14faee59 upstream.
Somehow the patch that added two-finger touch support forgot to update
W8001_MAX_LENGTH from 11 to 13.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c7f1429389ec1aa25e042bb13451385fbb596f8c upstream.
Xbox One controllers have multiple interfaces which all have the
same class, subclass, and protocol. One of the these interfaces
has only a single endpoint. When Xpad attempts to bind to this
interface, it causes an oops when trying initialize the output URB
by trying to access the second endpoint's descriptor.
This situation was avoided for known Xbox One devices by checking
the XTYPE constant associated with the VID and PID tuple. However,
this breaks when new or previously unknown Xbox One controllers
are attached to the system.
This change addresses the problem by deriving the XTYPE for Xbox
One controllers based on the interface protocol before checking
the interface number.
Fixes: 1a48ff81b391 ("Input: xpad - add support for Xbox One controllers")
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 226ba707744a51acb4244724e09caacb1d96aed9 upstream.
The touchpad in HP Pavilion 14-ab057ca reports it's version as 12 and
according to Elan both 11 and 12 are valid IC types and should be
identified as hw_version 4.
Reported-by: Patrick Lessard <Patrick.Lessard@cogeco.com>
Tested-by: Patrick Lessard <Patrick.Lessard@cogeco.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 60842ef8128e7bf58c024814cd0dc14319232b6c upstream.
The VMWare EFI BIOS will expose port 0x5658 as an ACPI resource. This
causes the port to be reserved by the APCI module as the system comes up,
making it unavailable to be reserved again by other drivers, thus
preserving this VMWare port for special use in a VMWare guest.
This port is designed to be shared among multiple VMWare services, such as
the VMMOUSE. Because of this, VMMOUSE should not try to reserve this port
on its own.
The VMWare non-EFI BIOS does not do this to preserve compatibility with
existing/legacy VMs. It is known that there is small chance a VM may be
configured such that these ports get reserved by other non-VMWare devices,
and if this ever happens, the result is undefined.
Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit efd1535270c1deb0487527bf0c3c827301a69c93 upstream.
Sometimes blkfront may twice receive blkback_changed() notification
(XenbusStateConnected) after migration, which will cause
talk_to_blkback() to be called twice too and confuse xen-blkback.
The flow is as follow:
blkfront blkback
blkfront_resume()
> talk_to_blkback()
> Set blkfront to XenbusStateInitialised
front changed()
> Connect()
> Set blkback to XenbusStateConnected
blkback_changed()
> Skip talk_to_blkback()
because frontstate == XenbusStateInitialised
> blkfront_connect()
> Set blkfront to XenbusStateConnected
-----
And here we get another XenbusStateConnected notification leading
to:
-----
blkback_changed()
> because now frontstate != XenbusStateInitialised
talk_to_blkback() is also called again
> blkfront state changed from
XenbusStateConnected to XenbusStateInitialised
(Which is not correct!)
front_changed():
> Do nothing because blkback
already in XenbusStateConnected
Now blkback is in XenbusStateConnected but blkfront is still
in XenbusStateInitialised - leading to no disks.
Poking of the XenbusStateConnected state is allowed (to deal with
block disk change) and has to be dealt with. The most likely
cause of this bug are custom udev scripts hooking up the disks
and then validating the size.
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2a6f71ad99cabe436e70c3f5fcf58072cb3bc07f upstream.
After a migrate to another host (which may not have multiqueue
support), the number of rings (block hardware queues)
may be changed and the ring info structure will also be reallocated.
This patch fixes two related bugs:
* call blk_mq_update_nr_hw_queues() to make blk-core know the number
of hardware queues have been changed.
* Don't store rinfo pointer to hctx->driver_data, because rinfo may be
reallocated so use hctx->queue_num to get the rinfo structure instead.
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7469be95a487319514adce2304ad2af3553d2fc9 upstream.
xenbus_dev_request_and_reply() needs to track whether a transaction is
open. For XS_TRANSACTION_START messages it calls transaction_start()
and for XS_TRANSACTION_END messages it calls transaction_end().
If sending an XS_TRANSACTION_START message fails or responds with an
an error, the transaction is not open and transaction_end() must be
called.
If sending an XS_TRANSACTION_END message fails, the transaction is
still open, but if an error response is returned the transaction is
closed.
Commit 027bd7e89906 ("xen/xenbus: Avoid synchronous wait on XenBus
stalling shutdown/restart") introduced a regression where failed
XS_TRANSACTION_START messages were leaving the transaction open. This
can cause problems with suspend (and migration) as all transactions
must be closed before suspending.
It appears that the problematic change was added accidentally, so just
remove it.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0beef634b86a1350c31da5fcc2992f0d7c8a622b upstream.
Inability to locate a user mode specified transaction ID should not
lead to a kernel crash. For other than XS_TRANSACTION_START also
don't issue anything to xenbus if the specified ID doesn't match that
of any active transaction.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7b427a59538a98161321aa46c13f4ea81b43f4eb upstream.
Uncompleted reqs used to be 'saved and resubmitted' in blkfront_recover() during
migration, but that's too late after multi-queue was introduced.
After a migrate to another host (which may not have multiqueue support), the
number of rings (block hardware queues) may be changed and the ring and shadow
structure will also be reallocated.
The blkfront_recover() then can't 'save and resubmit' the real
uncompleted reqs because shadow structure have been reallocated.
This patch fixes this issue by moving the 'save' logic out of
blkfront_recover() to earlier place in blkfront_resume().
The 'resubmit' is not changed and still in blkfront_recover().
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 02ef871ecac290919ea0c783d05da7eedeffc10e upstream.
Current overlap check is evaluating to false a case where a filter
field is fully contained (proper subset) of a r/w request. This
change applies classical overlap check instead to include all the
scenarios.
More specifically, for (Hilscher GmbH CIFX 50E-DP(M/S)) device driver
the logic is such that the entire confspace is read and written in 4
byte chunks. In this case as an example, CACHE_LINE_SIZE,
LATENCY_TIMER and PCI_BIST are arriving together in one call to
xen_pcibk_config_write() with offset == 0xc and size == 4. With the
exsisting overlap check the LATENCY_TIMER field (offset == 0xd, length
== 1) is fully contained in the write request and hence is excluded
from write, which is incorrect.
Signed-off-by: Andrey Grodzovsky <andrey2805@gmail.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 368301f2fe4b07e5fb71dba3cc566bc59eb6705f upstream.
With this command sequence:
modprobe plip
modprobe pps_parport
rmmod pps_parport
the partport_pps modules causes this crash:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: parport_detach+0x1d/0x60 [pps_parport]
Oops: 0000 [#1] SMP
...
Call Trace:
parport_unregister_driver+0x65/0xc0 [parport]
SyS_delete_module+0x187/0x210
The sequence that builds up to this is:
1) plip is loaded and takes the parport device for exclusive use:
plip0: Parallel port at 0x378, using IRQ 7.
2) pps_parport then fails to grab the device:
pps_parport: parallel port PPS client
parport0: cannot grant exclusive access for device pps_parport
pps_parport: couldn't register with parport0
3) rmmod of pps_parport is then killed because it tries to access
pardev->name, but pardev (taken from port->cad) is NULL.
So add a check for NULL in the test there too.
Link: http://lkml.kernel.org/r/20160714115245.12651-1-jslaby@suse.cz
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
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>
|
|
commit 9295c41d77ca93aac79cfca6fa09fa1ca5cab66f upstream.
Due to the way CUBC register is updated, a double flush is needed to
compute an accurate residue. First flush aim is to get data from the DMA
FIFO and second one ensures that we won't report data which are not in
memory.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
eXtended DMA Controller driver")
Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 53398f488821c2b5b15291e3debec6ad33f75d3d upstream.
An unexpected value of CUBC can lead to a corrupted residue. A more
complex sequence is needed to detect an inaccurate value for NCA or CUBC.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
eXtended DMA Controller driver")
Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4a9723e8df68cfce4048517ee32e37f78854b6fb upstream.
Having descriptors aligned on 64 bits allows update CNDA and CUBC in an
atomic way.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
eXtended DMA Controller driver")
Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
Alexander Shishkin
Dmitri Epshtein
Tejun Heo
Lukasz Gemborowski
Sricharan R
Laurent Pinchart
James Patrick-Evans
Brian King
Alan Stern
Bruno Prémont
Paul Burton
Oliver Hartkopp
Thor Thayer
Wolfgang Grandegger
Taras Kondratiuk
Ville Viinikka
Ursula Braun
Dan Carpenter
Boris Brezillon
Heiko Stuebner
Michal Suchanek
Tomeu Vizoso
Colin Ian King
Rafael J. Wysocki
Rhyland Klein
Alexander Shiyan
Tony Lindgren
Michael Welling
Andrew Duggan
Dmitry Torokhov
Cameron Gutman
Ping Cheng
Sinclair Yeh
Bob Liu
Jan Beulich
Andrey Grodzovsky
Jiri Slaby
Ludovic Desroches