- 23 Mar, 2019 34 commits
-
-
Vineet Gupta authored
[ Upstream commit d5e3c55e ] Newer ARC gcc handles lp_start, lp_end in a different way and doesn't like them in the clobber list. Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Eugeniy Paltsev authored
[ Upstream commit f8a15f97 ] ARCv2 optimized memcpy uses PREFETCHW instruction for prefetching the next cache line but doesn't ensure that the line is not past the end of the buffer. PRETECHW changes the line ownership and marks it dirty, which can cause data corruption if this area is used for DMA IO. Fix the issue by avoiding the PREFETCHW. This leads to performance degradation but it is OK as we'll introduce new memcpy implementation optimized for unaligned memory access using. We also cut off all PREFETCH instructions at they are quite useless here: * we call PREFETCH right before LOAD instruction call. * we copy 16 or 32 bytes of data (depending on CONFIG_ARC_HAS_LL64) in a main logical loop. so we call PREFETCH 4 times (or 2 times) for each L1 cache line (in case of 64B L1 cache Line which is default case). Obviously this is not optimal. Signed-off-by:
Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Signed-off-by:
-
Darrick J. Wong authored
[ Upstream commit 1062af92 ] tmpfs has a peculiarity of accounting hard links as if they were separate inodes: so that when the number of inodes is limited, as it is by default, a user cannot soak up an unlimited amount of unreclaimable dcache memory just by repeatedly linking a file. But when v3.11 added O_TMPFILE, and the ability to use linkat() on the fd, we missed accommodating this new case in tmpfs: "df -i" shows that an extra "inode" remains accounted after the file is unlinked and the fd closed and the actual inode evicted. If a user repeatedly links tmpfiles into a tmpfs, the limit will be hit (ENOSPC) even after they are deleted. Just skip the extra reservation from shmem_link() in this case: there's a sense in which this first link of a tmpfile is then cheaper than a hard link of another file, but the accounting works out, and there's still good limiting, so no need to do anything more complicated. Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1902182134370.7035@eggly.anvils Fixes: f4e0c30c ("allow the temp files created by open() to be linked to") Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by:
Hugh Dickins <hughd@google.com> Reported-by:
Matej Kupljen <matej.kupljen@gmail.com> Acked-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Russell King authored
[ Upstream commit a8fef9ba ] Booting 4.20 on SolidRun Clearfog issues this warning with DMA API debug enabled: WARNING: CPU: 0 PID: 555 at kernel/dma/debug.c:1230 check_sync+0x514/0x5bc mvneta f1070000.ethernet: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x000000002dd7dc00] [size=240 bytes] Modules linked in: ahci mv88e6xxx dsa_core xhci_plat_hcd xhci_hcd devlink armada_thermal marvell_cesa des_generic ehci_orion phy_armada38x_comphy mcp3021 spi_orion evbug sfp mdio_i2c ip_tables x_tables CPU: 0 PID: 555 Comm: bridge-network- Not tainted 4.20.0+ #291 Hardware name: Marvell Armada 380/385 (Device Tree) [<c0019638>] (unwind_backtrace) from [<c0014888>] (show_stack+0x10/0x14) [<c0014888>] (show_stack) from [<c07f54e0>] (dump_stack+0x9c/0xd4) [<c07f54e0>] (dump_stack) from [<c00312bc>] (__warn+0xf8/0x124) [<c00312bc>] (__warn) from [<c00313b0>] (warn_slowpath_fmt+0x38/0x48) [<c00313b0>] (warn_slowpath_fmt) from [<c00b0370>] (check_sync+0x514/0x5bc) [<c00b0370>] (check_sync) from [<c00b04f8>] (debug_dma_sync_single_range_for_cpu+0x6c/0x74) [<c00b04f8>] (debug_dma_sync_single_range_for_cpu) from [<c051bd14>] (mvneta_poll+0x298/0xf58) [<c051bd14>] (mvneta_poll) from [<c0656194>] (net_rx_action+0x128/0x424) [<c0656194>] (net_rx_action) from [<c000a230>] (__do_softirq+0xf0/0x540) [<c000a230>] (__do_softirq) from [<c00386e0>] (irq_exit+0x124/0x144) [<c00386e0>] (irq_exit) from [<c009b5e0>] (__handle_domain_irq+0x58/0xb0) [<c009b5e0>] (__handle_domain_irq) from [<c03a63c4>] (gic_handle_irq+0x48/0x98) [<c03a63c4>] (gic_handle_irq) from [<c0009a10>] (__irq_svc+0x70/0x98) ... This appears to be caused by mvneta_rx_hwbm() calling dma_sync_single_range_for_cpu() with the wrong struct device pointer, as the buffer manager device pointer is used to map and unmap the buffer. Fix this. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Vladimir Murzin authored
[ Upstream commit 74698f69 ] Updates to the GIC architecture allow ID_AA64PFR0_EL1.GIC to have values other than 0 or 1. At the moment, Linux is quite strict in the way it handles this field at early boot stage (cpufeature is fine) and will refuse to use the system register CPU interface if it doesn't find the value 1. Fixes: 021f6537 ("irqchip: gic-v3: Initial support for GICv3") Reported-by:
Chase Conklin <Chase.Conklin@arm.com> Reviewed-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Bard liao authored
[ Upstream commit 304017d3 ] Topology resources are no longer needed if any element failed to load. Signed-off-by:
Bard liao <yung-chuan.liao@linux.intel.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Alexey Khoroshilov authored
[ Upstream commit e928b5d6 ] If mv643xx_eth_shared_of_probe() fails, mv643xx_eth_shared_probe() leaves clk enabled. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
-
Beniamino Galvani authored
[ Upstream commit 97dc47a1 ] The 1199:68C0 USB ID is reused by Sierra WP7607 which requires the DTR quirk to be detected. Apply QMI_QUIRK_SET_DTR unconditionally as already done for other IDs shared between different devices. Signed-off-by:
Beniamino Galvani <bgalvani@redhat.com> Acked-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Martin Blumenstingl authored
[ Upstream commit c17abcfa ] Fix the mismatch between the "sdxc_d13_1_a" pin group definition from meson8b_cbus_groups and the entry in sdxc_a_groups ("sdxc_d0_13_1_a"). This makes it possible to use "sdxc_d13_1_a" in device-tree files to route the MMC data 1..3 pins to GPIOX_1..3. Fixes: 0fefcb68 ("pinctrl: Add support for Meson8b") Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit a40061ea ] SYSTEMPORT has its RXCHK parser block that attempts to validate the packet structures, unfortunately setting the L2 header check bit will cause Bridge PDUs (BPDUs) to be incorrectly rejected because they look like LLC/SNAP packets with a non-IPv4 or non-IPv6 Ethernet Type. Fixes: 4e8aedfe78c7 ("net: systemport: Turn on offloads by default") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Anoob Soman authored
[ Upstream commit 79edd00d ] When a target sends Check Condition, whilst initiator is busy xmiting re-queued data, could lead to race between iscsi_complete_task() and iscsi_xmit_task() and eventually crashing with the following kernel backtrace. [3326150.987523] ALERT: BUG: unable to handle kernel NULL pointer dereference at 0000000000000078 [3326150.987549] ALERT: IP: [<ffffffffa05ce70d>] iscsi_xmit_task+0x2d/0xc0 [libiscsi] [3326150.987571] WARN: PGD 569c8067 PUD 569c9067 PMD 0 [3326150.987582] WARN: Oops: 0002 [#1] SMP [3326150.987593] WARN: Modules linked in: tun nfsv3 nfs fscache dm_round_robin [3326150.987762] WARN: CPU: 2 PID: 8399 Comm: kworker/u32:1 Tainted: G O 4.4.0+2 #1 [3326150.987774] WARN: Hardware name: Dell Inc. PowerEdge R720/0W7JN5, BIOS 2.5.4 01/22/2016 [3326150.987790] WARN: Workqueue: iscsi_q_13 iscsi_xmitworker [libiscsi] [3326150.987799] WARN: task: ffff8801d50f3800 ti: ffff8801f5458000 task.ti: ffff8801f5458000 [3326150.987810] WARN: RIP: e030:[<ffffffffa05ce70d>] [<ffffffffa05ce70d>] iscsi_xmit_task+0x2d/0xc0 [libiscsi] [3326150.987825] WARN: RSP: e02b:ffff8801f545bdb0 EFLAGS: 00010246 [3326150.987831] WARN: RAX: 00000000ffffffc3 RBX: ffff880282d2ab20 RCX: ffff88026b6ac480 [3326150.987842] WARN: RDX: 0000000000000000 RSI: 00000000fffffe01 RDI: ffff880282d2ab20 [3326150.987852] WARN: RBP: ffff8801f545bdc8 R08: 0000000000000000 R09: 0000000000000008 [3326150.987862] WARN: R10: 0000000000000000 R11: 000000000000fe88 R12: 0000000000000000 [3326150.987872] WARN: R13: ffff880282d2abe8 R14: ffff880282d2abd8 R15: ffff880282d2ac08 [3326150.987890] WARN: FS: 00007f5a866b4840(0000) GS:ffff88028a640000(0000) knlGS:0000000000000000 [3326150.987900] WARN: CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [3326150.987907] WARN: CR2: 0000000000000078 CR3: 0000000070244000 CR4: 0000000000042660 [3326150.987918] WARN: Stack: [3326150.987924] WARN: ffff880282d2ad58 ffff880282d2ab20 ffff880282d2abe8 ffff8801f545be18 [3326150.987938] WARN: ffffffffa05cea90 ffff880282d2abf8 ffff88026b59cc80 ffff88026b59cc00 [3326150.987951] WARN: ffff88022acf32c0 ffff880289491800 ffff880255a80800 0000000000000400 [3326150.987964] WARN: Call Trace: [3326150.987975] WARN: [<ffffffffa05cea90>] iscsi_xmitworker+0x2f0/0x360 [libiscsi] [3326150.987988] WARN: [<ffffffff8108862c>] process_one_work+0x1fc/0x3b0 [3326150.987997] WARN: [<ffffffff81088f95>] worker_thread+0x2a5/0x470 [3326150.988006] WARN: [<ffffffff8159cad8>] ? __schedule+0x648/0x870 [3326150.988015] WARN: [<ffffffff81088cf0>] ? rescuer_thread+0x300/0x300 [3326150.988023] WARN: [<ffffffff8108ddf5>] kthread+0xd5/0xe0 [3326150.988031] WARN: [<ffffffff8108dd20>] ? kthread_stop+0x110/0x110 [3326150.988040] WARN: [<ffffffff815a0bcf>] ret_from_fork+0x3f/0x70 [3326150.988048] WARN: [<ffffffff8108dd20>] ? kthread_stop+0x110/0x110 [3326150.988127] ALERT: RIP [<ffffffffa05ce70d>] iscsi_xmit_task+0x2d/0xc0 [libiscsi] [3326150.988138] WARN: RSP <ffff8801f545bdb0> [3326150.988144] WARN: CR2: 0000000000000078 [3326151.020366] WARN: ---[ end trace 1c60974d4678d81b ]--- Commit 6f8830f5 ("scsi: libiscsi: add lock around task lists to fix list corruption regression") introduced "taskqueuelock" to fix list corruption during the race, but this wasn't enough. Re-setting of conn->task to NULL, could race with iscsi_xmit_task(). iscsi_complete_task() { .... if (conn->task == task) conn->task = NULL; } conn->task in iscsi_xmit_task() could be NULL and so will be task. __iscsi_get_task(task) will crash (NullPtr de-ref), trying to access refcount. iscsi_xmit_task() { struct iscsi_task *task = conn->task; __iscsi_get_task(task); } This commit will take extra conn->session->back_lock in iscsi_xmit_task() to ensure iscsi_xmit_task() waits for iscsi_complete_task(), if iscsi_complete_task() wins the race. If iscsi_xmit_task() wins the race, iscsi_xmit_task() increments task->refcount (__iscsi_get_task) ensuring iscsi_complete_task() will not iscsi_free_task(). Signed-off-by:
Anoob Soman <anoob.soman@citrix.com> Signed-off-by:
Bob Liu <bob.liu@oracle.com> Acked-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
David Howells authored
[ Upstream commit bb2ba2d7 ] Fix the creation of shortcuts for which the length of the index key value is an exact multiple of the machine word size. The problem is that the code that blanks off the unused bits of the shortcut value malfunctions if the number of bits in the last word equals machine word size. This is due to the "<<" operator being given a shift of zero in this case, and so the mask that should be all zeros is all ones instead. This causes the subsequent masking operation to clear everything rather than clearing nothing. Ordinarily, the presence of the hash at the beginning of the tree index key makes the issue very hard to test for, but in this case, it was encountered due to a development mistake that caused the hash output to be either 0 (keyring) or 1 (non-keyring) only. This made it susceptible to the keyctl/unlink/valid test in the keyutils package. The fix is simply to skip the blanking if the shift would be 0. For example, an index key that is 64 bits long would produce a 0 shift and thus a 'blank' of all 1s. This would then be inverted and AND'd onto the index_key, incorrectly clearing the entire last word. Fixes: 3cb98950 ("Add a generic associative array implementation.") Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
James Morris <james.morris@microsoft.com> Signed-off-by:
-
Dietmar Eggemann authored
[ Upstream commit 1b5ba350 ] Arm TC2 fails cpu hotplug stress test. This issue was tracked down to a missing copy of the new affinity cpumask for the vexpress-spc interrupt into struct irq_common_data.affinity when the interrupt is migrated in migrate_one_irq(). Fix it by replacing the arm specific hotplug cpu migration with the generic irq code. This is the counterpart implementation to commit 217d453d ("arm64: fix a migrating irq bug when hotplug cpu"). Tested with cpu hotplug stress test on Arm TC2 (multi_v7_defconfig plus CONFIG_ARM_BIG_LITTLE_CPUFREQ=y and CONFIG_ARM_VEXPRESS_SPC_CPUFREQ=y). The vexpress-spc interrupt (irq=22) on this board is affine to CPU0. Its affinity cpumask now changes correctly e.g. from 0 to 1-4 when CPU0 is hotplugged out. Suggested-by:
Dietmar Eggemann <dietmar.eggemann@arm.com> Acked-by:
-
Andre Przywara authored
[ Upstream commit ee0b27a3 ] According to the manual the gate clock for MMC3 is at bit 11, and NAND1 is controlled by bit 12. Fix the gate bit definitions in the clock driver. Fixes: c6e6c96d ("clk: sunxi-ng: Add A31/A31s clocks") Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
-
Gabriel Fernandez authored
[ Upstream commit 2439d37e ] This patch fixes the following static checker warning: drivers/input/keyboard/st-keyscan.c:156 keyscan_probe() error: potential zalloc NULL dereference: 'keypad_data->input_dev' Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Gabriel Fernandez <gabriel.fernandez@st.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Shubhrajyoti Datta authored
[ Upstream commit d358def7 ] In case the hold bit is not needed we are carrying the old values. Fix the same by resetting the bit when not needed. Fixes the sporadic i2c bus lockups on National Instruments Zynq-based devices. Fixes: df8eb569 ("i2c: Add driver for Cadence I2C controller") Reported-by:
Kyle Roeschley <kyle.roeschley@ni.com> Acked-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Tested-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Huang Zijiang authored
[ Upstream commit c969c6e7 ] The of_find_device_by_node() takes a reference to the underlying device structure, we should release that reference. Signed-off-by:
Huang Zijiang <huang.zijiang@zte.com.cn> Signed-off-by:
-
Jann Horn authored
[ Upstream commit 2c2ade81 ] The basic idea behind ->pagecnt_bias is: If we pre-allocate the maximum number of references that we might need to create in the fastpath later, the bump-allocation fastpath only has to modify the non-atomic bias value that tracks the number of extra references we hold instead of the atomic refcount. The maximum number of allocations we can serve (under the assumption that no allocation is made with size 0) is nc->size, so that's the bias used. However, even when all memory in the allocation has been given away, a reference to the page is still held; and in the `offset < 0` slowpath, the page may be reused if everyone else has dropped their references. This means that the necessary number of references is actually `nc->size+1`. Luckily, from a quick grep, it looks like the only path that can call page_frag_alloc(fragsz=1) is TAP with the IFF_NAPI_FRAGS flag, which requires CAP_NET_ADMIN in the init namespace and is only intended to be used for kernel testing and fuzzing. To test for this issue, put a `WARN_ON(page_ref_count(page) == 0)` in the `offset < 0` path, below the virt_to_page() call, and then repeatedly call writev() on a TAP device with IFF_TAP|IFF_NO_PI|IFF_NAPI_FRAGS|IFF_NAPI, with a vector consisting of 15 elements containing 1 byte each. Signed-off-by:
Jann Horn <jannh@google.com> Signed-off-by:
-
Yu Zhao authored
[ Upstream commit 414fd080 ] For dax pmd, pmd_trans_huge() returns false but pmd_huge() returns true on x86. So the function works as long as hugetlb is configured. However, dax doesn't depend on hugetlb. Link: http://lkml.kernel.org/r/20190111034033.601-1-yuzhao@google.comSigned-off-by:
Yu Zhao <yuzhao@google.com> Reviewed-by:
Jan Kara <jack@suse.cz> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Keith Busch <keith.busch@intel.com> Cc: "Michael S . Tsirkin" <mst@redhat.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Wei Yang <richard.weiyang@gmail.com> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com> Signed-off-by:
-
Yufen Yu authored
[ Upstream commit 96d7cb93 ] floppy_check_events() is supposed to return bit flags to say which events occured. We should return zero to say that no event flags are set. Only BIT(0) and BIT(1) are used in the caller. And .check_events interface also expect to return an unsigned int value. However, after commit a0c80efe, it may return -EINTR (-4u). Here, both BIT(0) and BIT(1) are cleared. So this patch shouldn't affect runtime, but it obviously is still worth fixing. Reviewed-by:
Yufen Yu <yuyufen@huawei.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Dmitry Torokhov authored
[ Upstream commit a342083a ] We should be using flush_delayed_work() instead of flush_work() in matrix_keypad_stop() to ensure that we are not missing work that is scheduled but not yet put in the workqueue (i.e. its delay timer has not expired yet). Signed-off-by:
-
Dmitry Torokhov authored
[ Upstream commit 62844288 ] Updating LED state requires access to regmap and therefore we may sleep, so we could not do that directly form set_brightness() method. Historically we used private work to adjust the brightness, but with the introduction of set_brightness_blocking() we no longer need it. As a bonus, not having our own work item means we do not have use-after-free issue as we neglected to cancel outstanding work on driver unbind. Reported-by:
Sven Van Asbroeck <thesven73@gmail.com> Reviewed-by:
Sven Van Asbroeck <TheSven73@googlemail.com> Acked-by:
Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by:
-
Yizhuo authored
[ Upstream commit dc30e703 ] In function omap4_dsi_mux_pads(), local variable "reg" could be uninitialized if function regmap_read() returns -EINVAL. However, it will be used directly in the later context, which is potentially unsafe. Signed-off-by:
Yizhuo <yzhai003@ucr.edu> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Stefan Haberland authored
[ Upstream commit 4a8ef699 ] Dan Carpenter reported the following: The patch 52898025: "[S390] dasd: security and PSF update patch for EMC CKD ioctl" from Mar 8, 2010, leads to the following static checker warning: drivers/s390/block/dasd_eckd.c:4486 dasd_symm_io() error: using offset into zero size array 'psf_data[]' drivers/s390/block/dasd_eckd.c 4458 /* Copy parms from caller */ 4459 rc = -EFAULT; 4460 if (copy_from_user(&usrparm, argp, sizeof(usrparm))) ^^^^^^^ The user can specify any "usrparm.psf_data_len". They choose zero by mistake. 4461 goto out; 4462 if (is_compat_task()) { 4463 /* Make sure pointers are sane even on 31 bit. */ 4464 rc = -EINVAL; 4465 if ((usrparm.psf_data >> 32) != 0) 4466 goto out; 4467 if ((usrparm.rssd_result >> 32) != 0) 4468 goto out; 4469 usrparm.psf_data &= 0x7fffffffULL; 4470 usrparm.rssd_result &= 0x7fffffffULL; 4471 } 4472 /* alloc I/O data area */ 4473 psf_data = kzalloc(usrparm.psf_data_len, GFP_KERNEL | GFP_DMA); 4474 rssd_result = kzalloc(usrparm.rssd_result_len, GFP_KERNEL | GFP_DMA); 4475 if (!psf_data || !rssd_result) { kzalloc() returns a ZERO_SIZE_PTR (0x16). 4476 rc = -ENOMEM; 4477 goto out_free; 4478 } 4479 4480 /* get syscall header from user space */ 4481 rc = -EFAULT; 4482 if (copy_from_user(psf_data, 4483 (void __user *)(unsigned long) usrparm.psf_data, 4484 usrparm.psf_data_len)) That all works great. 4485 goto out_free; 4486 psf0 = psf_data[0]; 4487 psf1 = psf_data[1]; But now we're assuming that "->psf_data_len" was at least 2 bytes. Fix this by checking the user specified length psf_data_len. Fixes: 52898025 ("[S390] dasd: security and PSF update patch for EMC CKD ioctl") Reported-by:
Stefan Haberland <sth@linux.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Steve Longerbeam authored
[ Upstream commit bb867d21 ] The CSI offsets are wrong for both CSI0 and CSI1. They are at physical address 0x1e030000 and 0x1e038000 respectively. Fixes: 2ffd48f2 ("gpu: ipu-v3: Add Camera Sensor Interface unit") Signed-off-by:
Steve Longerbeam <slongerbeam@gmail.com> Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Alexander Shiyan authored
[ Upstream commit 2c0408dd ] The CSI0/CSI1 registers offset is at +0xe030000/+0xe038000 relative to the control module registers on IPUv3EX. This patch fixes wrong values for i.MX51 CSI0/CSI1. Fixes: 2ffd48f2 ("gpu: ipu-v3: Add Camera Sensor Interface unit") Signed-off-by:
Alexander Shiyan <shc_work@mail.ru> Signed-off-by:
-
Eric Biggers authored
commit 77568e53 upstream. Hash algorithms with an alignmask set, e.g. "xcbc(aes-aesni)" and "michael_mic", fail the improved hash tests because they sometimes produce the wrong digest. The bug is that in the case where a scatterlist element crosses pages, not all the data is actually hashed because the scatterlist walk terminates too early. This happens because the 'nbytes' variable in crypto_hash_walk_done() is assigned the number of bytes remaining in the page, then later interpreted as the number of bytes remaining in the scatterlist element. Fix it. Fixes: 900a081f ("crypto: ahash - Fix early termination in hash walk") Cc: stable@vger.kernel.org Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Pankaj Gupta authored
commit 42e95d1f upstream. when the source sg contains more than 1 fragment and destination sg contains 1 fragment, the caam driver mishandle the buffers to be sent to caam. Fixes: f2147b88 ("crypto: caam - Convert GCM to new AEAD interface") Cc: <stable@vger.kernel.org> # 4.2+ Signed-off-by:
Pankaj Gupta <pankaj.gupta@nxp.com> Signed-off-by:
Arun Pathak <arun.pathak@nxp.com> Reviewed-by:
Horia Geanta <horia.geanta@nxp.com> Signed-off-by:
-
Zhi Jin authored
commit a1d75dad upstream. There is a bug in the channel allocation logic that leads to an endless loop when looking for a contiguous range of channels in a range with a mixture of free and occupied channels. For example, opening three consequtive channels, closing the first two and requesting 4 channels in a row will trigger this soft lockup. The bug is that the search loop forgets to skip over the range once it detects that one channel in that range is occupied. Restore the original intent to the logic by fixing the omission. Signed-off-by:
Zhi Jin <zhi.jin@intel.com> Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Fixes: 7bd1d409 ("stm class: Introduce an abstraction for System Trace Module devices") CC: stable@vger.kernel.org # v4.4+ Signed-off-by:
-
Krzysztof Kozlowski authored
commit 2ea8bab4 upstream. Fix NULL pointer exception on device unbind when device tree does not contain "has-touchscreen" property. In such case the input device is not registered so it should not be unregistered. $ echo "12d10000.adc" > /sys/bus/platform/drivers/exynos-adc/unbind Unable to handle kernel NULL pointer dereference at virtual address 00000474 ... (input_unregister_device) from [<c0772060>] (exynos_adc_remove+0x20/0x80) (exynos_adc_remove) from [<c0587d5c>] (platform_drv_remove+0x20/0x40) (platform_drv_remove) from [<c05860f0>] (device_release_driver_internal+0xdc/0x1ac) (device_release_driver_internal) from [<c0583ecc>] (unbind_store+0x60/0xd4) (unbind_store) from [<c031b89c>] (kernfs_fop_write+0x100/0x1e0) (kernfs_fop_write) from [<c029709c>] (__vfs_write+0x2c/0x17c) (__vfs_write) from [<c0297374>] (vfs_write+0xa4/0x184) (vfs_write) from [<c0297594>] (ksys_write+0x4c/0xac) (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28) Fixes: 2bb8ad9b ("iio: exynos-adc: add experimental touchscreen support") Cc: <stable@vger.kernel.org> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
S.j. Wang authored
commit cc29ea00 upstream. The ESAI_xCR_xWA is xCR's bit, not the xCCR's bit, driver set it to wrong register, correct it. Fixes 43d24e76 ("ASoC: fsl_esai: Add ESAI CPU DAI driver") Cc: <stable@vger.kernel.org> Signed-off-by:
Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Ackedy-by:
Nicolin Chen <nicoleotsuka@gmail.com> Signed-off-by:
-
zhengbin authored
commit bb06c388 upstream. If msize is less than 4096, we should close and put trans, destroy tagpool, not just free client. This patch fixes that. Link: http://lkml.kernel.org/m/1552464097-142659-1-git-send-email-zhengbin13@huawei.com Cc: stable@vger.kernel.org Fixes: 574d356b ("9p/net: put a lower bound on msize") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
zhengbin <zhengbin13@huawei.com> Signed-off-by:
Dominique Martinet <dominique.martinet@cea.fr> Signed-off-by:
-
Hou Tao authored
commit 5e3cc1ee upstream. Use inode->i_lock to protect i_size_write(), else i_size_read() in generic_fillattr() may loop infinitely in read_seqcount_begin() when multiple processes invoke v9fs_vfs_getattr() or v9fs_vfs_getattr_dotl() simultaneously under 32-bit SMP environment, and a soft lockup will be triggered as show below: watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [stat:2217] Modules linked in: CPU: 5 PID: 2217 Comm: stat Not tainted 5.0.0-rc1-00005-g7f702faf5a9e #4 Hardware name: Generic DT based system PC is at generic_fillattr+0x104/0x108 LR is at 0xec497f00 pc : [<802b8898>] lr : [<ec497f00>] psr: 200c0013 sp : ec497e20 ip : ed608030 fp : ec497e3c r10: 00000000 r9 : ec497f00 r8 : ed608030 r7 : ec497ebc r6 : ec497f00 r5 : ee5c1550 r4 : ee005780 r3 : 0000052d r2 : 00000000 r1 : ec497f00 r0 : ed608030 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: ac48006a DAC: 00000051 CPU: 5 PID: 2217 Comm: stat Not tainted 5.0.0-rc1-00005-g7f702faf5a9e #4 Hardware name: Generic DT based system Backtrace: [<8010d974>] (dump_backtrace) from [<8010dc88>] (show_stack+0x20/0x24) [<8010dc68>] (show_stack) from [<80a1d194>] (dump_stack+0xb0/0xdc) [<80a1d0e4>] (dump_stack) from [<80109f34>] (show_regs+0x1c/0x20) [<80109f18>] (show_regs) from [<801d0a80>] (watchdog_timer_fn+0x280/0x2f8) [<801d0800>] (watchdog_timer_fn) from [<80198658>] (__hrtimer_run_queues+0x18c/0x380) [<801984cc>] (__hrtimer_run_queues) from [<80198e60>] (hrtimer_run_queues+0xb8/0xf0) [<80198da8>] (hrtimer_run_queues) from [<801973e8>] (run_local_timers+0x28/0x64) [<801973c0>] (run_local_timers) from [<80197460>] (update_process_times+0x3c/0x6c) [<80197424>] (update_process_times) from [<801ab2b8>] (tick_nohz_handler+0xe0/0x1bc) [<801ab1d8>] (tick_nohz_handler) from [<80843050>] (arch_timer_handler_virt+0x38/0x48) [<80843018>] (arch_timer_handler_virt) from [<80180a64>] (handle_percpu_devid_irq+0x8c/0x240) [<801809d8>] (handle_percpu_devid_irq) from [<8017ac20>] (generic_handle_irq+0x34/0x44) [<8017abec>] (generic_handle_irq) from [<8017b344>] (__handle_domain_irq+0x6c/0xc4) [<8017b2d8>] (__handle_domain_irq) from [<801022e0>] (gic_handle_irq+0x4c/0x88) [<80102294>] (gic_handle_irq) from [<80101a30>] (__irq_svc+0x70/0x98) [<802b8794>] (generic_fillattr) from [<8056b284>] (v9fs_vfs_getattr_dotl+0x74/0xa4) [<8056b210>] (v9fs_vfs_getattr_dotl) from [<802b8904>] (vfs_getattr_nosec+0x68/0x7c) [<802b889c>] (vfs_getattr_nosec) from [<802b895c>] (vfs_getattr+0x44/0x48) [<802b8918>] (vfs_getattr) from [<802b8a74>] (vfs_statx+0x9c/0xec) [<802b89d8>] (vfs_statx) from [<802b9428>] (sys_lstat64+0x48/0x78) [<802b93e0>] (sys_lstat64) from [<80101000>] (ret_fast_syscall+0x0/0x28) [dominique.martinet@cea.fr: updated comment to not refer to a function in another subsystem] Link: http://lkml.kernel.org/r/20190124063514.8571-2-houtao1@huawei.com Cc: stable@vger.kernel.org Fixes: 7549ae3e ("9p: Use the i_size_[read, write]() macros instead of using inode->i_size directly.") Reported-by:
Xing Gaopeng <xingaopeng@huawei.com> Signed-off-by:
Hou Tao <houtao1@huawei.com> Signed-off-by:
-
Hans Verkuil authored
commit 5e99456c upstream. Userspace shouldn't set bytesused to 0 for output buffers. vb2_warn_zero_bytesused() warns about this (only once!), but it also calls WARN_ON(1), which is confusing since it is not immediately clear that it warns about a 0 value for bytesused. Just drop the WARN_ON as it serves no purpose. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Cc: Matthias Maennich <maennich@google.com> Signed-off-by:
-
- 19 Mar, 2019 6 commits
-
-
Greg Kroah-Hartman authored
-
Zha Bin authored
commit 7fbe078c upstream. The vsock core only supports 32bit CID, but the Virtio-vsock spec define CID (dst_cid and src_cid) as u64 and the upper 32bits is reserved as zero. This inconsistency causes one bug in vhost vsock driver. The scenarios is: 0. A hash table (vhost_vsock_hash) is used to map an CID to a vsock object. And hash_min() is used to compute the hash key. hash_min() is defined as: (sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits)). That means the hash algorithm has dependency on the size of macro argument 'val'. 0. In function vhost_vsock_set_cid(), a 64bit CID is passed to hash_min() to compute the hash key when inserting a vsock object into the hash table. 0. In function vhost_vsock_get(), a 32bit CID is passed to hash_min() to compute the hash key when looking up a vsock for an CID. Because the different size of the CID, hash_min() returns different hash key, thus fails to look up the vsock object for an CID. To fix this bug, we keep CID as u64 in the IOCTLs and virtio message headers, but explicitly convert u64 to u32 when deal with the hash table and vsock core. Fixes: 834e772c ("vhost/vsock: fix use-after-free in network stack callers") Link: https://github.com/stefanha/virtio/blob/vsock/trunk/content.texSigned-off-by:
Zha Bin <zhabin@linux.alibaba.com> Reviewed-by:
Liu Jiang <gerry@linux.alibaba.com> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com> Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
Shengjing Zhu <i@zhsj.me> Signed-off-by:
-
Sakari Ailus authored
commit d20dc149 upstream. Turn to_of_node() into a macro in order to support both const and non-const use. Additionally make the fwnode argument to is_of_node() const as well. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
Rob Herring <robh@kernel.org> Cc: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Sergei Shtylyov authored
commit 5c27ff5d upstream. I have encountered an interrupt storm during the eMMC chip probing (and the chip finally didn't get detected). It turned out that U-Boot left the DMAC interrupts enabled while the Linux driver didn't use those. The SDHI driver's interrupt handler somehow assumes that, even if an SDIO interrupt didn't happen, it should return IRQ_HANDLED. I think that if none of the enabled interrupts happened and got handled, we should return IRQ_NONE -- that way the kernel IRQ code recoginizes a spurious interrupt and masks it off pretty quickly... Fixes: 7729c7a2 ("mmc: tmio: Provide separate interrupt handlers") Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by:
Simon Horman <horms+renesas@verge.net.au> Cc: stable@vger.kernel.org Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Xiao Ni authored
commit b761dcf1 upstream. In reshape_request it already adds len to sector_nr already. It's wrong to add len to sector_nr again after adding pages to bio. If there is bad block it can't copy one chunk at a time, it needs to goto read_more. Now the sector_nr is wrong. It can cause data corruption. Cc: stable@vger.kernel.org # v3.16+ Signed-off-by:
Xiao Ni <xni@redhat.com> Signed-off-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
-
Takashi Sakamoto authored
commit 7dc661bd upstream. ALSA bebob driver has an entry for Focusrite Saffire Pro 10 I/O. The entry matches vendor_id in root directory and model_id in unit directory of configuration ROM for IEEE 1394 bus. On the other hand, configuration ROM of Focusrite Liquid Saffire 56 has the same vendor_id and model_id. This device is an application of TCAT Dice (TCD2220 a.k.a Dice Jr.) however ALSA bebob driver can be bound to it randomly instead of ALSA dice driver. At present, drivers in ALSA firewire stack can not handle this situation appropriately. This commit uses more identical mod_alias for Focusrite Saffire Pro 10 I/O in ALSA bebob driver. $ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 400 042a829d bus_info_length 4, crc_length 42, crc 33437 404 31333934 bus_name "1394" 408 f0649222 irmc 1, cmc 1, isc 1, bmc 1, pmc 0, cyc_clk_acc 100, max_rec 9 (1024), max_rom 2, gen 2, spd 2 (S400) 40c 00130e01 company_id 00130e | 410 000606e0 device_id 01000606e0 | EUI-64 00130e01000606e0 root directory ----------------------------------------------------------------- 414 0009d31c directory_length 9, crc 54044 418 04000014 hardware version 41c 0c0083c0 node capabilities per IEEE 1394 420 0300130e vendor 424 81000012 --> descriptor leaf at 46c 428 17000006 model 42c 81000016 --> descriptor leaf at 484 430 130120c2 version 434 d1000002 --> unit directory at 43c 438 d4000006 --> dependent info directory at 450 unit directory at 43c ----------------------------------------------------------------- 43c 0004707c directory_length 4, crc 28796 440 1200a02d specifier id: 1394 TA 444 13010001 version: AV/C 448 17000006 model 44c 81000013 --> descriptor leaf at 498 dependent info directory at 450 ----------------------------------------------------------------- 450 000637c7 directory_length 6, crc 14279 454 120007f5 specifier id 458 13000001 version 45c 3affffc7 (immediate value) 460 3b100000 (immediate value) 464 3cffffc7 (immediate value) 468 3d600000 (immediate value) descriptor leaf at 46c ----------------------------------------------------------------- 46c 00056f3b leaf_length 5, crc 28475 470 00000000 textual descriptor 474 00000000 minimal ASCII 478 466f6375 "Focu" 47c 73726974 "srit" 480 65000000 "e" descriptor leaf at 484 ----------------------------------------------------------------- 484 0004a165 leaf_length 4, crc 41317 488 00000000 textual descriptor 48c 00000000 minimal ASCII 490 50726f31 "Pro1" 494 30494f00 "0IO" descriptor leaf at 498 ----------------------------------------------------------------- 498 0004a165 leaf_length 4, crc 41317 49c 00000000 textual descriptor 4a0 00000000 minimal ASCII 4a4 50726f31 "Pro1" 4a8 30494f00 "0IO" $ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 400 040442e4 bus_info_length 4, crc_length 4, crc 17124 404 31333934 bus_name "1394" 408 e0ff8112 irmc 1, cmc 1, isc 1, bmc 0, pmc 0, cyc_clk_acc 255, max_rec 8 (512), max_rom 1, gen 1, spd 2 (S400) 40c 00130e04 company_id 00130e | 410 018001e9 device_id 04018001e9 | EUI-64 00130e04018001e9 root directory ----------------------------------------------------------------- 414 00065612 directory_length 6, crc 22034 418 0300130e vendor 41c 8100000a --> descriptor leaf at 444 420 17000006 model 424 8100000e --> descriptor leaf at 45c 428 0c0087c0 node capabilities per IEEE 1394 42c d1000001 --> unit directory at 430 unit directory at 430 ----------------------------------------------------------------- 430 000418a0 directory_length 4, crc 6304 434 1200130e specifier id 438 13000001 version 43c 17000006 model 440 8100000f --> descriptor leaf at 47c descriptor leaf at 444 ----------------------------------------------------------------- 444 00056f3b leaf_length 5, crc 28475 448 00000000 textual descriptor 44c 00000000 minimal ASCII 450 466f6375 "Focu" 454 73726974 "srit" 458 65000000 "e" descriptor leaf at 45c ----------------------------------------------------------------- 45c 000762c6 leaf_length 7, crc 25286 460 00000000 textual descriptor 464 00000000 minimal ASCII 468 4c495155 "LIQU" 46c 49445f53 "ID_S" 470 41464649 "AFFI" 474 52455f35 "RE_5" 478 36000000 "6" descriptor leaf at 47c ----------------------------------------------------------------- 47c 000762c6 leaf_length 7, crc 25286 480 00000000 textual descriptor 484 00000000 minimal ASCII 488 4c495155 "LIQU" 48c 49445f53 "ID_S" 490 41464649 "AFFI" 494 52455f35 "RE_5" 498 36000000 "6" Cc: <stable@vger.kernel.org> # v3.16+ Fixes: 25784ec2 ("ALSA: bebob: Add support for Focusrite Saffire/SaffirePro series") Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
