- 17 May, 2017 22 commits
-
-
Johan Hovold authored
[ Upstream commit a6bb1e17 ] FTDI devices use a receive latency timer to periodically empty the receive buffer and report modem and line status (also when the buffer is empty). When a break or error condition is detected the corresponding status flags will be set on a packet with nonzero data payload and the flags are not updated until the break is over or further characters are received. In order to avoid over-reporting break and error conditions, these flags must therefore only be processed for packets with payload. This specifically fixes the case where after an overrun, the error condition is continuously reported and NULL-characters inserted until further data is received. Reported-by:
Michael Walle <michael@walle.cc> Fixes: 72fda3ca ("USB: serial: ftd_sio: implement sysrq handling on break") Fixes: 166ceb69 ("USB: ftdi_sio: clean up line-status handling") Cc: stable <stable@vger.kernel.org> # v2.6.35 Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com>
-
Janosch Frank authored
[ Upstream commit e1e8a962 ] User controlled KVM guests do not support the dirty log, as they have no single gmap that we can check for changes. As they have no single gmap, kvm->arch.gmap is NULL and all further referencing to it for dirty checking will result in a NULL dereference. Let's return -EINVAL if a caller tries to sync dirty logs for a UCONTROL guest. Fixes: 15f36ebd ("KVM: s390: Add proper dirty bitmap support to S390 kvm.") Cc: <stable@vger.kernel.org> # 3.16+ Signed-off-by:
Janosch Frank <frankja@linux.vnet.ibm.com> Reported-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Reviewed-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
-
Ken Lin authored
[ Upstream commit 9a593656 ] Add new USB IDs for cp2104/5 devices on Bx50v3 boards due to the design change. Signed-off-by:
Ken Lin <yungching0725@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Ian Abbott authored
[ Upstream commit 1c9c858e ] The MKS Instruments SCOM-0800 and SCOM-0801 cards (originally by Tenta Technologies) are 3U CompactPCI serial cards with 4 and 8 serial ports, respectively. The first 4 ports are implemented by an OX16PCI954 chip, and the second 4 ports are implemented by an OX16C954 chip on a local bus, bridged by the second PCI function of the OX16PCI954. The ports are jumper-selectable as RS-232 and RS-422/485, and the UARTs use a non-standard oscillator frequency of 20 MHz (base_baud = 1250000). Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Theodore Ts'o authored
[ Upstream commit e112666b ] If the journal has been aborted, we shouldn't mark the underlying buffer head as dirty, since that will cause the metadata block to get modified. And if the journal has been aborted, we shouldn't allow this since it will almost certainly lead to a corrupted file system. Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org Signed-off-by:
-
Julian Wiedmann authored
[ Upstream commit 1e4a382f ] For devices with multiple input queues, tiqdio_call_inq_handlers() iterates over all input queues and clears the device's DSCI during each iteration. If the DSCI is re-armed during one of the later iterations, we therefore do not scan the previous queues again. The re-arming also raises a new adapter interrupt. But its handler does not trigger a rescan for the device, as the DSCI has already been erroneously cleared. This can result in queue stalls on devices with multiple input queues. Fix it by clearing the DSCI just once, prior to scanning the queues. As the code is moved in front of the loop, we also need to access the DSCI directly (ie irq->dsci) instead of going via each queue's parent pointer to the same irq. This is not a functional change, and a follow-up patch will clean up the other users. In practice, this bug only affects CQ-enabled HiperSockets devices, ie. devices with sysfs-attribute "hsuid" set. Setting a hsuid is needed for AF_IUCV socket applications that use HiperSockets communication. Fixes: 104ea556 ("qdio: support asynchronous delivery of storage blocks") Cc: <stable@vger.kernel.org> # v3.2+ Reviewed-by:
Ursula Braun <ubraun@linux.vnet.ibm.com> Signed-off-by:
Julian Wiedmann <jwi@linux.vnet.ibm.com> Signed-off-by:
-
Gerald Schaefer authored
[ Upstream commit a63f53e3 ] Since commit dd22f551 "block: Change direct_access calling convention", the device size calculation in dcssblk_direct_access() is off-by-one. This results in bdev_direct_access() always returning -ENXIO because the returned value is not page aligned. Fix this by adding 1 to the dev_sz calculation. Fixes: dd22f551 ("block: Change direct_access calling convention") Cc: <stable@vger.kernel.org> # 4.0+ Signed-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
-
Eric W. Biederman authored
[ Upstream commit 1064f874 ] Ever since mount propagation was introduced in cases where a mount in propagated to parent mount mountpoint pair that is already in use the code has placed the new mount behind the old mount in the mount hash table. This implementation detail is problematic as it allows creating arbitrary length mount hash chains. Furthermore it invalidates the constraint maintained elsewhere in the mount code that a parent mount and a mountpoint pair will have exactly one mount upon them. Making it hard to deal with and to talk about this special case in the mount code. Modify mount propagation to notice when there is already a mount at the parent mount and mountpoint where a new mount is propagating to and place that preexisting mount on top of the new mount. Modify unmount propagation to notice when a mount that is being unmounted has another mount on top of it (and no other children), and to replace the unmounted mount with the mount on top of it. Move the MNT_UMUONT test from __lookup_mnt_last into __propagate_umount as that is the only call of __lookup_mnt_last where MNT_UMOUNT may be set on any mount visible in the mount hash table. These modifications allow: - __lookup_mnt_last to be removed. - attach_shadows to be renamed __attach_mnt and its shadow handling to be removed. - commit_tree to be simplified - copy_tree to be simplified The result is an easier to understand tree of mounts that does not allow creation of arbitrary length hash chains in the mount hash table. The result is also a very slight userspace visible difference in semantics. The following two cases now behave identically, where before order mattered: case 1: (explicit user action) B is a slave of A mount something on A/a , it will propagate to B/a and than mount something on B/a case 2: (tucked mount) B is a slave of A mount something on B/a and than mount something on A/a Histroically umount A/a would fail in case 1 and succeed in case 2. Now umount A/a succeeds in both configurations. This very small change in semantics appears if anything to be a bug fix to me and my survey of userspace leads me to believe that no programs will notice or care of this subtle semantic change. v2: Updated to mnt_change_mountpoint to not call dput or mntput and instead to decrement the counts directly. It is guaranteed that there will be other references when mnt_change_mountpoint is called so this is safe. v3: Moved put_mountpoint under mount_lock in attach_recursive_mnt As the locking in fs/namespace.c changed between v2 and v3. v4: Reworked the logic in propagate_mount_busy and __propagate_umount that detects when a mount completely covers another mount. v5: Removed unnecessary tests whose result is alwasy true in find_topper and attach_recursive_mnt. v6: Document the user space visible semantic difference. Cc: stable@vger.kernel.org Fixes: b90fa9ae ("[PATCH] shared mount handling: bind and rbind") Tested-by:
Andrei Vagin <avagin@virtuozzo.com> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Maxime Ripard authored
[ Upstream commit fb61bb82 ] The RTC is clocked from either an internal, imprecise, oscillator or an external one, which is usually much more accurate. The difference perceived between the time elapsed and the time reported by the RTC is in a 10% scale, which prevents the RTC from being useful at all. Fortunately, the external oscillator is reported to be mandatory in the Allwinner datasheet, so we can just switch to it. Cc: stable@vger.kernel.org Fixes: 9765d2d9 ("rtc: sun6i: Add sun6i RTC driver") Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Maxime Ripard authored
[ Upstream commit a9422a19 ] Some registers have a read-modify-write access pattern that are not atomic. Add some locking to prevent from concurrent accesses. Cc: stable@vger.kernel.org Acked-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Johan Hovold authored
[ Upstream commit 2d380889 ] Make sure to check for short transfers to avoid underflow in a loop condition when parsing the receive buffer. Also fix an off-by-one error in the incomplete sanity check which could lead to invalid data being parsed. Fixes: 8c209e67 ("USB: make actual_length in struct urb field u32") Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> # v2.6.30 Reviewed-by:
-
Randy Dunlap authored
[ Upstream commit e3bb3cdd ] Fix dm1105 build error when CONFIG_I2C_ALGOBIT=m and CONFIG_DVB_DM1105=y. drivers/built-in.o: In function `dm1105_probe': dm1105.c:(.text+0x2836e7): undefined reference to `i2c_bit_add_bus' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Cc: Javier Martinez Canillas <javier@osg.samsung.com> Cc: stable@vger.kernel.org # applies to 4.0 (maybe even 3.x) Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Rafał Miłecki authored
[ Upstream commit a971df0b ] This allows tracking device state and e.g. makes devm work as expected. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Cc: Stable <stable@vger.kernel.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Nicolas Iooss authored
[ Upstream commit 6ebf7577 ] In vpfe_s_fmt(), when the sensor format and the requested format were the same, bpp was assigned to vpfe->bpp without being initialized first. Grab the bpp value that is currently used by using __vpfe_get_format() instead of its wrapper, vpfe_try_fmt(). This use of uninitialized variable has been found by compiling the kernel with clang. Fixes: 417d2e50 ("[media] media: platform: add VPFE capture driver support for AM437X") Cc: stable@vger.kernel.org Signed-off-by:
Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by:
-
Marc Zyngier authored
[ Upstream commit 8f36ebaf ] When we fault in a page, we flush it to the PoC (Point of Coherency) if the faulting vcpu has its own caches off, so that it can observe the page we just brought it. But if the vcpu has its caches on, we skip that step. Bad things happen when *another* vcpu tries to access that page with its own caches disabled. At that point, there is no garantee that the data has made it to the PoC, and we access stale data. The obvious fix is to always flush to PoC when a page is faulted in, no matter what the state of the vcpu is. Cc: stable@vger.kernel.org Fixes: 2d58b733 ("arm64: KVM: force cache clean on page fault when caches are off") Reviewed-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Jan Kara authored
[ Upstream commit cd648b8a ] If filesystem groups are artifically small (using parameter -g to mkfs.ext4), ext4_mb_normalize_request() can result in a request that is larger than a block group. Trim the request size to not confuse allocation code. Reported-by:
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Alex Deucher authored
[ Upstream commit a882f5de ] The vfct table can contain multiple vbios images if the platform contains multiple GPUs. Noticed by netkas on phoronix forums. This patch fixes those platforms. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Michel Dänzer authored
[ Upstream commit 239ac65f ] The current caching state may not be tt_cached, even though the placement contains TTM_PL_FLAG_CACHED, because placement can contain multiple caching flags. Trying to swap out such a BO would trip up the BUG_ON(ttm->caching_state != tt_cached); in ttm_tt_swapout. Cc: stable@vger.kernel.org Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com>. Reviewed-by:
Sinclair Yeh <syeh@vmware.com> Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Magnus Lilja authored
[ Upstream commit 5528954a ] Commit 304f7e5e ("usb: gadget: Refactor request completion") removed check if req->req.complete is non-NULL, resulting in a NULL pointer derefence and a kernel panic. This patch adds an empty complete function instead of re-introducing the req->req.complete check. Fixes: 304f7e5e ("usb: gadget: Refactor request completion") Signed-off-by:
Magnus Lilja <lilja.magnus@gmail.com> Cc: <stable@vger.kernel.org> # 3.18+ Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Johan Hovold authored
[ Upstream commit c6dce262 ] Since commit 557aaa7f ("ft232: support the ASYNC_LOW_LATENCY flag") the FTDI driver has been using a receive latency-timer value of 1 ms instead of the device default of 16 ms. The latency timer is used to periodically empty a non-full receive buffer, but a status header is always sent when the timer expires including when the buffer is empty. This means that a two-byte bulk message is received every millisecond also for an otherwise idle port as long as it is open. Let's restore the pre-2009 behaviour which reduces the rate of the status messages to 1/16th (e.g. interrupt frequency drops from 1 kHz to 62.5 Hz) by not setting ASYNC_LOW_LATENCY by default. Anyone willing to pay the price for the minimum-latency behaviour should set the flag explicitly instead using the TIOCSSERIAL ioctl or a tool such as setserial (e.g. setserial /dev/ttyUSB0 low_latency). Note that since commit 0cbd81a9 ("USB: ftdi_sio: remove tty->low_latency") the ASYNC_LOW_LATENCY flag has no other effects but to set a minimal latency timer. Reported-by:
Antoine Aubert <a.aubert@overkiz.com> Fixes: 557aaa7f ("ft232: support the ASYNC_LOW_LATENCY flag") Cc: stable@vger.kernel.org # v2.6.31: e3e574adSigned-off-by:
-
Maciej S. Szmigiero authored
[ Upstream commit d2ce4ea1 ] Near the beginning of w1_attach_slave_device() we increment a w1 master reference count. Later, when we are going to exit this function without actually attaching a slave device (due to failure of __w1_attach_slave_device()) we need to decrement this reference count back. Signed-off-by:
Maciej S. Szmigiero <mail@maciej.szmigiero.name> Cc: stable@vger.kernel.org Fixes: 9fcbbac5 ("w1: process w1 netlink commands in w1_process thread") Cc: Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by:
-
Maciej S. Szmigiero authored
[ Upstream commit 61cd1b4c ] ds2490 driver was doing USB transfers from / to buffers on a stack. This is not permitted and made the driver non-working with vmapped stacks. Since all these transfers are done under the same bus_mutex lock we can simply use shared buffers in a device private structure for two most common of them. While we are at it, let's also fix a comparison between int and size_t in ds9490r_search() which made the driver spin in this function if state register get requests were failing. Signed-off-by:
Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by:
-
- 16 May, 2017 18 commits
-
-
Alexandre Belloni authored
[ Upstream commit ef8d02d4 ] Enable DMA on usart3 to get a more reliable console. This is especially useful for automation and kernelci were a kernel with PROVE_LOCKING enabled is quite susceptible to character loss, resulting in tests failure. Cc: stable <stable@vger.kernel.org> #v4.1+ Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 6e017006 ] gcc-7 detects that wlanhdr_to_ethhdr() in two drivers calls memcpy() with a destination argument that an earlier function call may have set to NULL: staging/rtl8188eu/core/rtw_recv.c: In function 'wlanhdr_to_ethhdr': staging/rtl8188eu/core/rtw_recv.c:1318:2: warning: argument 1 null where non-null expected [-Wnonnull] staging/rtl8712/rtl871x_recv.c: In function 'r8712_wlanhdr_to_ethhdr': staging/rtl8712/rtl871x_recv.c:649:2: warning: argument 1 null where non-null expected [-Wnonnull] I'm fixing this by adding a NULL pointer check and returning failure from the function, which is hopefully already handled properly. This seems to date back to when the drivers were originally added, so backporting the fix to stable seems appropriate. There are other related realtek drivers in the kernel, but none of them contain a function with a similar name or produce this warning. Cc: stable@vger.kernel.org Fixes: 1cc18a22 ("staging: r8188eu: Add files for new driver - part 5") Fixes: 2865d42c ("staging: r8712u: Add the new driver to the mainline kernel") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Johan Hovold authored
[ Upstream commit 2eee0502 ] The opticon driver used a control request at open to trigger a CTS status notification to be sent over the bulk-in pipe. When the driver was converted to using the generic read implementation, an inverted test prevented this request from being sent, something which could lead to TIOCMGET reporting an incorrect CTS state. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: 7a6ee2b0 ("USB: opticon: switch to generic read implementation") Cc: stable <stable@vger.kernel.org> Reviewed-by:
-
Johan Hovold authored
[ Upstream commit 5ed8d410 ] Make sure to detect short control transfers and return zero on success when retrieving the modem status. This fixes the TIOCMGET implementation which since e1ed212d ("USB: spcp8x5: add proper modem-status support") has returned TIOCM_LE on successful retrieval, and avoids leaking bits from the stack on short transfers. This also fixes the carrier-detect implementation which since the above mentioned commit unconditionally has returned true. Fixes: e1ed212d ("USB: spcp8x5: add proper modem-status support") Cc: stable <stable@vger.kernel.org> Reviewed-by:
-
Johan Hovold authored
[ Upstream commit 427c3a95 ] Make sure to detect short responses when fetching the modem status in order to avoid parsing uninitialised buffer data and having bits of it leak to user space. Note that we still allow for short 1-byte responses. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Reviewed-by:
-
Johan Hovold authored
[ Upstream commit 9fef37d7 ] The current implementation failed to detect short transfers, something which could lead to bits of the uninitialised heap transfer buffer leaking to user space. Fixes: 149fc791 ("USB: ark3116: Setup some basic infrastructure for new ark3116 driver.") Fixes: f4c1e8d5 ("USB: ark3116: Make existing functions 16450-aware and add close and release functions.") Cc: stable <stable@vger.kernel.org> Reviewed-by:
-
Feras Daoud authored
[ Upstream commit 0a0007f2 ] When calling set_mode from sys/fs, the call flow locks the sys/fs lock first and then tries to lock rtnl_lock (when calling ipoib_set_mod). On the other hand, the rmmod call flow takes the rtnl_lock first (when calling unregister_netdev) and then tries to take the sys/fs lock. Deadlock a->b, b->a. The problem starts when ipoib_set_mod frees it's rtnl_lck and tries to get it after that. set_mod: [<ffffffff8104f2bd>] ? check_preempt_curr+0x6d/0x90 [<ffffffff814fee8e>] __mutex_lock_slowpath+0x13e/0x180 [<ffffffff81448655>] ? __rtnl_unlock+0x15/0x20 [<ffffffff814fed2b>] mutex_lock+0x2b/0x50 [<ffffffff81448675>] rtnl_lock+0x15/0x20 [<ffffffffa02ad807>] ipoib_set_mode+0x97/0x160 [ib_ipoib] [<ffffffffa02b5f5b>] set_mode+0x3b/0x80 [ib_ipoib] [<ffffffff8134b840>] dev_attr_store+0x20/0x30 [<ffffffff811f0fe5>] sysfs_write_file+0xe5/0x170 [<ffffffff8117b068>] vfs_write+0xb8/0x1a0 [<ffffffff8117ba81>] sys_write+0x51/0x90 [<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b rmmod: [<ffffffff81279ffc>] ? put_dec+0x10c/0x110 [<ffffffff8127a2ee>] ? number+0x2ee/0x320 [<ffffffff814fe6a5>] schedule_timeout+0x215/0x2e0 [<ffffffff8127cc04>] ? vsnprintf+0x484/0x5f0 [<ffffffff8127b550>] ? string+0x40/0x100 [<ffffffff814fe323>] wait_for_common+0x123/0x180 [<ffffffff81060250>] ? default_wake_function+0x0/0x20 [<ffffffff8119661e>] ? ifind_fast+0x5e/0xb0 [<ffffffff814fe43d>] wait_for_completion+0x1d/0x20 [<ffffffff811f2e68>] sysfs_addrm_finish+0x228/0x270 [<ffffffff811f2fb3>] sysfs_remove_dir+0xa3/0xf0 [<ffffffff81273f66>] kobject_del+0x16/0x40 [<ffffffff8134cd14>] device_del+0x184/0x1e0 [<ffffffff8144e59b>] netdev_unregister_kobject+0xab/0xc0 [<ffffffff8143c05e>] rollback_registered+0xae/0x130 [<ffffffff8143c102>] unregister_netdevice+0x22/0x70 [<ffffffff8143c16e>] unregister_netdev+0x1e/0x30 [<ffffffffa02a91b0>] ipoib_remove_one+0xe0/0x120 [ib_ipoib] [<ffffffffa01ed95f>] ib_unregister_device+0x4f/0x100 [ib_core] [<ffffffffa021f5e1>] mlx4_ib_remove+0x41/0x180 [mlx4_ib] [<ffffffffa01ab771>] mlx4_remove_device+0x71/0x90 [mlx4_core] Fixes: 862096a8 ("IB/ipoib: Add more rtnl_link_ops callbacks") Cc: <stable@vger.kernel.org> # v3.6+ Cc: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
Feras Daoud <ferasda@mellanox.com> Signed-off-by:
Erez Shitrit <erezsh@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Jason Gunthorpe authored
[ Upstream commit 55efcfcd ] The RDMA core uses ib_pack() to convert from unpacked CPU structs to on-the-wire bitpacked structs. This process requires that 1 bit fields are declared as u8 in the unpacked struct, otherwise the packing process does not read the value properly and the packed result is wired to 0. Several places wrongly used int. Crucially this means the kernel has never, set reversible correctly in the path record request. It has always asked for irreversible paths even if the ULP requests otherwise. When the kernel is used with a SM that supports this feature, it completely breaks communication management if reversible paths are not properly requested. The only reason this ever worked is because opensm ignores the reversible bit. Cc: stable@vger.kernel.org Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
-
Felix Fietkau authored
[ Upstream commit a70e1d6f ] Simply return -EOPNOTSUPP instead. Cc: stable@vger.kernel.org Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Javier Martinez Canillas authored
[ Upstream commit abe81f3b ] If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo drivers/tty/serial/msm_serial.ko | grep alias $ After this patch: $ modinfo drivers/tty/serial/msm_serial.ko | grep alias alias: of:N*T*Cqcom,msm-uartdmC* alias: of:N*T*Cqcom,msm-uartdm alias: of:N*T*Cqcom,msm-uartC* alias: of:N*T*Cqcom,msm-uart Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Acked-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Vitaly Kuznetsov authored
[ Upstream commit 3c7630d3 ] Initializing hv_context.percpu_list in hv_synic_alloc() helps to prevent a crash in percpu_channel_enq() when not all CPUs were online during initialization and it naturally belongs there. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Mathias Svensson authored
[ Upstream commit 916cafdc ] There were some bugs in the JNE64 and JLT64 comparision macros. This fixes them, improves comments, and cleans up the file while we are at it. Reported-by:
Stephen Röttger <sroettger@google.com> Signed-off-by:
Mathias Svensson <idolf@google.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Signed-off-by:
James Morris <james.l.morris@oracle.com> Signed-off-by:
-
Long Li authored
[ Upstream commit bba5dc33 ] When sense message is present on error, we should pass along to the upper layer to decide how to deal with the error. This patch fixes connectivity issues with Fiber Channel devices. Signed-off-by:
Long Li <longli@microsoft.com> Reviewed-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Long Li authored
[ Upstream commit 3cd6d3d9 ] Properly set SRB flags when hosting device supports tagged queuing. This patch improves the performance on Fiber Channel disks. Signed-off-by:
-
Paul Burton authored
[ Upstream commit 096a0de4 ] is_jump_ins() checks for plain jump ("j") instructions since commit e7438c4b ("MIPS: Fix sibling call handling in get_frame_info") but that commit didn't make the same change to the microMIPS code, leaving it inconsistent with the MIPS32/MIPS64 code. Handle the microMIPS encoding of the jump instruction too such that it behaves consistently. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Fixes: e7438c4b ("MIPS: Fix sibling call handling in get_frame_info") Cc: Tony Wu <tung7970@gmail.com> Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # v3.10+ Patchwork: https://patchwork.linux-mips.org/patch/14533/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Paul Burton authored
[ Upstream commit bb9bc468 ] get_frame_info() calculates the offset of the return address within a stack frame simply by dividing a the bottom 16 bits of the instruction, treated as a signed integer, by the size of a long. Whilst this works for MIPS32 & MIPS64 ISAs where the sw or sd instructions are used, it's incorrect for microMIPS where encodings differ. The result is that we typically completely fail to unwind the stack on microMIPS. Fix this by adjusting is_ra_save_ins() to calculate the return address offset, and take into account the various different encodings there in the same place as we consider whether an instruction is storing the ra/$31 register. With this we are now able to unwind the stack for kernels targetting the microMIPS ISA, for example we can produce: Call Trace: [<80109e1f>] show_stack+0x63/0x7c [<8011ea17>] __warn+0x9b/0xac [<8011ea45>] warn_slowpath_fmt+0x1d/0x20 [<8013fe53>] register_console+0x43/0x314 [<8067c58d>] of_setup_earlycon+0x1dd/0x1ec [<8067f63f>] early_init_dt_scan_chosen_stdout+0xe7/0xf8 [<8066c115>] do_early_param+0x75/0xac [<801302f9>] parse_args+0x1dd/0x308 [<8066c459>] parse_early_options+0x25/0x28 [<8066c48b>] parse_early_param+0x2f/0x38 [<8066e8cf>] setup_arch+0x113/0x488 [<8066c4f3>] start_kernel+0x57/0x328 ---[ end trace 0000000000000000 ]--- Whereas previously we only produced: Call Trace: [<80109e1f>] show_stack+0x63/0x7c ---[ end trace 0000000000000000 ]--- Signed-off-by:
-
Paul Burton authored
[ Upstream commit 67c75057 ] is_jump_ins() checks 16b instruction fields without verifying that the instruction is indeed 16b, as is done by is_ra_save_ins() & is_sp_move_ins(). Add the appropriate check. Signed-off-by:
-
Paul Burton authored
[ Upstream commit b6c7a324 ] get_frame_info() is meant to iterate over up to the first 128 instructions within a function, but for microMIPS kernels it will not reach that many instructions unless the function is 512 bytes long since we calculate the maximum number of instructions to check by dividing the function length by the 4 byte size of a union mips_instruction. In microMIPS kernels this won't do since instructions are variable length. Fix this by instead checking whether the pointer to the current instruction has reached the end of the function, and use max_insns as a simple constant to check the number of iterations against. Signed-off-by:
-
