- 25 Jun, 2020 40 commits
-
-
Lyude Paul authored
[ Upstream commit 873a95e0 ] Currently we only poll for an ACT up to 30 times, with a busy-wait delay of 100µs between each attempt - giving us a timeout of 2900µs. While this might seem sensible, it would appear that in certain scenarios it can take dramatically longer then that for us to receive an ACT. On one of the EVGA MST hubs that I have available, I observed said hub sometimes taking longer then a second before signalling the ACT. These delays mostly seem to occur when previous sideband messages we've sent are NAKd by the hub, however it wouldn't be particularly surprising if it's possible to reproduce times like this simply by introducing branch devices with large LCTs since payload allocations have to take effect on every downstream device up to the payload's target. So, instead of just retrying 30 times we poll for the ACT for up to 3ms, and additionally use usleep_range() to avoid a very long and rude busy-wait. Note that the previous retry count of 30 appears to have been arbitrarily chosen, as I can't find any mention of a recommended timeout or retry count for ACTs in the DisplayPort 2.0 specification. This also goes for the range we were previously using for udelay(), although I suspect that was just copied from the recommended delay for link training on SST devices. Changes since v1: * Use readx_poll_timeout() instead of open-coding timeout loop - Sean Paul Changes since v2: * Increase poll interval to 200us - Sean Paul * Print status in hex when we timeout waiting for ACT - Sean Paul Signed-off-by:
Lyude Paul <lyude@redhat.com> Fixes: ad7f8a1f ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Sean Paul <sean@poorly.run> Cc: <stable@vger.kernel.org> # v3.17+ Reviewed-by:
Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200406221253.1307209-4-lyude@redhat.comSigned-off-by:
Sasha Levin <sashal@kernel.org>
-
Theodore Ts'o authored
[ Upstream commit 829b37b8 ] Trying to change dax mount options when remounting could allow mount options to be enabled for a small amount of time, and then the mount option change would be reverted. In the case of "mount -o remount,dax", this can cause a race where files would temporarily treated as DAX --- and then not. Cc: stable@kernel.org Reported-by: syzbot+bca9799bf129256190da@syzkaller.appspotmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Sasha Levin authored
[ Upstream commit cfb3c85a ] Fix the bug when calculating the physical block number of the first block in the split extent. This bug will cause xfstests shared/298 failure on ext4 with bigalloc enabled occasionally. Ext4 error messages indicate that previously freed blocks are being freed again, and the following fsck will fail due to the inconsistency of block bitmap and bg descriptor. The following is an example case: 1. First, Initialize a ext4 filesystem with cluster size '16K', block size '4K', in which case, one cluster contains four blocks. 2. Create one file (e.g., xxx.img) on this ext4 filesystem. Now the extent tree of this file is like: ... 36864:[0]4:220160 36868:[0]14332:145408 51200:[0]2:231424 ... 3. Then execute PUNCH_HOLE fallocate on this file. The hole range is like: .. ext4_ext_remove_space: dev 254,16 ino 12 since 49506 end 49506 depth 1 ext4_ext_remove_space: dev 254,16 ino 12 since 49544 end 49546 depth 1 ext4_ext_remove_space: dev 254,16 ino 12 since 49605 end 49607 depth 1 ... 4. Then the extent tree of this file after punching is like ... 49507:[0]37:158047 49547:[0]58:158087 ... 5. Detailed procedure of punching hole [49544, 49546] 5.1. The block address space: ``` lblk ~49505 49506 49507~49543 49544~49546 49547~ ---------+------+-------------+----------------+-------- extent | hole | extent | hole | extent ---------+------+-------------+----------------+-------- pblk ~158045 158046 158047~158083 158084~158086 158087~ ``` 5.2. The detailed layout of cluster 39521: ``` cluster 39521 <-------------------------------> hole extent <----------------------><-------- lblk 49544 49545 49546 49547 +-------+-------+-------+-------+ | | | | | +-------+-------+-------+-------+ pblk 158084 1580845 158086 158087 ``` 5.3. The ftrace output when punching hole [49544, 49546]: - ext4_ext_remove_space (start 49544, end 49546) - ext4_ext_rm_leaf (start 49544, end 49546, last_extent [49507(158047), 40], partial [pclu 39522 lblk 0 state 2]) - ext4_remove_blocks (extent [49507(158047), 40], from 49544 to 49546, partial [pclu 39522 lblk 0 state 2] - ext4_free_blocks: (block 158084 count 4) - ext4_mballoc_free (extent 1/6753/1) 5.4. Ext4 error message in dmesg: EXT4-fs error (device vdb): mb_free_blocks:1457: group 1, block 158084:freeing already freed block (bit 6753); block bitmap corrupt. EXT4-fs error (device vdb): ext4_mb_generate_buddy:747: group 1, block bitmap and bg descriptor inconsistent: 19550 vs 19551 free clusters In this case, the whole cluster 39521 is freed mistakenly when freeing pblock 158084~158086 (i.e., the first three blocks of this cluster), although pblock 158087 (the last remaining block of this cluster) has not been freed yet. The root cause of this isuue is that, the pclu of the partial cluster is calculated mistakenly in ext4_ext_remove_space(). The correct partial_cluster.pclu (i.e., the cluster number of the first block in the next extent, that is, lblock 49597 (pblock 158086)) should be 39521 rather than 39522. Fixes: f4226d9e ("ext4: fix partial cluster initialization") Signed-off-by:
Jeffle Xu <jefflexu@linux.alibaba.com> Reviewed-by:
Eric Whitney <enwlinux@gmail.com> Cc: stable@kernel.org # v3.19+ Link: https://lore.kernel.org/r/1590121124-37096-1-git-send-email-jefflexu@linux.alibaba.comSigned-off-by:
-
Tom Rix authored
commit 65de5096 upstream. Clang's static analysis tool reports these double free memory errors. security/selinux/ss/services.c:2987:4: warning: Attempt to free released memory [unix.Malloc] kfree(bnames[i]); ^~~~~~~~~~~~~~~~ security/selinux/ss/services.c:2990:2: warning: Attempt to free released memory [unix.Malloc] kfree(bvalues); ^~~~~~~~~~~~~~ So improve the security_get_bools error handling by freeing these variables and setting their return pointers to NULL and the return len to 0 Cc: stable@vger.kernel.org Signed-off-by:
Tom Rix <trix@redhat.com> Acked-by:
Stephen Smalley <stephen.smalley.work@gmail.com> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sandeep Raghuraman authored
commit 790243d3 upstream. Initializes Powertune data for a specific Hawaii card by fixing what looks like a typo in the code. The device ID 66B1 is not a supported device ID for this driver, and is not mentioned elsewhere. 67B1 is a valid device ID, and is a Hawaii Pro GPU. I have tested on my R9 390 which has device ID 67B1, and it works fine without problems. Signed-off-by:
Sandeep Raghuraman <sandy.8925@gmail.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Huacai Chen authored
commit 80e5f89d upstream. The command ring and cursor ring use different notify port addresses definition: QXL_IO_NOTIFY_CMD and QXL_IO_NOTIFY_CURSOR. However, in qxl_device_init() we use QXL_IO_NOTIFY_CMD to create both command ring and cursor ring. This doesn't cause any problems now, because QEMU's behaviors on QXL_IO_NOTIFY_CMD and QXL_IO_NOTIFY_CURSOR are the same. However, QEMU's behavior may be change in future, so let's fix it. P.S.: In the X.org QXL driver, the notify port address of cursor ring is correct. Signed-off-by:
Huacai Chen <chenhc@lemote.com> Cc: <stable@vger.kernel.org> Link: http://patchwork.freedesktop.org/patch/msgid/1585635488-17507-1-git-send-email-chenhc@lemote.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Lyude Paul authored
commit a5cb5fa6 upstream. Just add a bit more line wrapping, get rid of some extraneous whitespace, remove an unneeded goto label, and move around some variable declarations. No functional changes here. Signed-off-by:
-
Wolfram Sang authored
[ Upstream commit f78d4032 ] module_put() balances try_module_get(), not request_module(). Fix the error path to match that. Fixes: 2066facc ("drm/kms: slave encoder interface.") Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
-
Kai-Heng Feng authored
[ Upstream commit b5292111 ] Commit 130f4caf ("libata: Ensure ata_port probe has completed before detach") may cause system freeze during suspend. Using async_synchronize_full() in PM callbacks is wrong, since async callbacks that are already scheduled may wait for not-yet-scheduled callbacks, causes a circular dependency. Instead of using big hammer like async_synchronize_full(), use async cookie to make sure port probe are synced, without affecting other scheduled PM callbacks. Fixes: 130f4caf ("libata: Ensure ata_port probe has completed before detach") Suggested-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Will Deacon authored
[ Upstream commit 24ebec25 ] Unprivileged memory accesses generated by the so-called "translated" instructions (e.g. STTR) at EL1 can cause EL0 watchpoints to fire unexpectedly if kernel debugging is enabled. In such cases, the hw_breakpoint logic will invoke the user overflow handler which will typically raise a SIGTRAP back to the current task. This is futile when returning back to the kernel because (a) the signal won't have been delivered and (b) userspace can't handle the thing anyway. Avoid invoking the user overflow handler for watchpoints triggered by kernel uaccess routines, and instead single-step over the faulting instruction as we would if no overflow handler had been installed. (Fixes tag identifies the introduction of unprivileged memory accesses, which exposed this latent bug in the hw_breakpoint code) Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morse <james.morse@arm.com> Fixes: 57f4959b ("arm64: kernel: Add support for User Access Override") Reported-by:
Luis Machado <luis.machado@linaro.org> Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Jason Yan authored
[ Upstream commit 2d3a8e2d ] In blkdev_get() we call __blkdev_get() to do some internal jobs and if there is some errors in __blkdev_get(), the bdput() is called which means we have released the refcount of the bdev (actually the refcount of the bdev inode). This means we cannot access bdev after that point. But acctually bdev is still accessed in blkdev_get() after calling __blkdev_get(). This results in use-after-free if the refcount is the last one we released in __blkdev_get(). Let's take a look at the following scenerio: CPU0 CPU1 CPU2 blkdev_open blkdev_open Remove disk bd_acquire blkdev_get __blkdev_get del_gendisk bdev_unhash_inode bd_acquire bdev_get_gendisk bd_forget failed because of unhashed bdput bdput (the last one) bdev_evict_inode access bdev => use after free [ 459.350216] BUG: KASAN: use-after-free in __lock_acquire+0x24c1/0x31b0 [ 459.351190] Read of size 8 at addr ffff88806c815a80 by task syz-executor.0/20132 [ 459.352347] [ 459.352594] CPU: 0 PID: 20132 Comm: syz-executor.0 Not tainted 4.19.90 #2 [ 459.353628] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 459.354947] Call Trace: [ 459.355337] dump_stack+0x111/0x19e [ 459.355879] ? __lock_acquire+0x24c1/0x31b0 [ 459.356523] print_address_description+0x60/0x223 [ 459.357248] ? __lock_acquire+0x24c1/0x31b0 [ 459.357887] kasan_report.cold+0xae/0x2d8 [ 459.358503] __lock_acquire+0x24c1/0x31b0 [ 459.359120] ? _raw_spin_unlock_irq+0x24/0x40 [ 459.359784] ? lockdep_hardirqs_on+0x37b/0x580 [ 459.360465] ? _raw_spin_unlock_irq+0x24/0x40 [ 459.361123] ? finish_task_switch+0x125/0x600 [ 459.361812] ? finish_task_switch+0xee/0x600 [ 459.362471] ? mark_held_locks+0xf0/0xf0 [ 459.363108] ? __schedule+0x96f/0x21d0 [ 459.363716] lock_acquire+0x111/0x320 [ 459.364285] ? blkdev_get+0xce/0xbe0 [ 459.364846] ? blkdev_get+0xce/0xbe0 [ 459.365390] __mutex_lock+0xf9/0x12a0 [ 459.365948] ? blkdev_get+0xce/0xbe0 [ 459.366493] ? bdev_evict_inode+0x1f0/0x1f0 [ 459.367130] ? blkdev_get+0xce/0xbe0 [ 459.367678] ? destroy_inode+0xbc/0x110 [ 459.368261] ? mutex_trylock+0x1a0/0x1a0 [ 459.368867] ? __blkdev_get+0x3e6/0x1280 [ 459.369463] ? bdev_disk_changed+0x1d0/0x1d0 [ 459.370114] ? blkdev_get+0xce/0xbe0 [ 459.370656] blkdev_get+0xce/0xbe0 [ 459.371178] ? find_held_lock+0x2c/0x110 [ 459.371774] ? __blkdev_get+0x1280/0x1280 [ 459.372383] ? lock_downgrade+0x680/0x680 [ 459.373002] ? lock_acquire+0x111/0x320 [ 459.373587] ? bd_acquire+0x21/0x2c0 [ 459.374134] ? do_raw_spin_unlock+0x4f/0x250 [ 459.374780] blkdev_open+0x202/0x290 [ 459.375325] do_dentry_open+0x49e/0x1050 [ 459.375924] ? blkdev_get_by_dev+0x70/0x70 [ 459.376543] ? __x64_sys_fchdir+0x1f0/0x1f0 [ 459.377192] ? inode_permission+0xbe/0x3a0 [ 459.377818] path_openat+0x148c/0x3f50 [ 459.378392] ? kmem_cache_alloc+0xd5/0x280 [ 459.379016] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 459.379802] ? path_lookupat.isra.0+0x900/0x900 [ 459.380489] ? __lock_is_held+0xad/0x140 [ 459.381093] do_filp_open+0x1a1/0x280 [ 459.381654] ? may_open_dev+0xf0/0xf0 [ 459.382214] ? find_held_lock+0x2c/0x110 [ 459.382816] ? lock_downgrade+0x680/0x680 [ 459.383425] ? __lock_is_held+0xad/0x140 [ 459.384024] ? do_raw_spin_unlock+0x4f/0x250 [ 459.384668] ? _raw_spin_unlock+0x1f/0x30 [ 459.385280] ? __alloc_fd+0x448/0x560 [ 459.385841] do_sys_open+0x3c3/0x500 [ 459.386386] ? filp_open+0x70/0x70 [ 459.386911] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 459.387610] ? trace_hardirqs_off_caller+0x55/0x1c0 [ 459.388342] ? do_syscall_64+0x1a/0x520 [ 459.388930] do_syscall_64+0xc3/0x520 [ 459.389490] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 459.390248] RIP: 0033:0x416211 [ 459.390720] Code: 75 14 b8 02 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 19 00 00 c3 48 83 ec 08 e8 0a fa ff ff 48 89 04 24 b8 02 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 53 fa ff ff 48 89 d0 48 83 c4 08 48 3d 01 [ 459.393483] RSP: 002b:00007fe45dfe9a60 EFLAGS: 00000293 ORIG_RAX: 0000000000000002 [ 459.394610] RAX: ffffffffffffffda RBX: 00007fe45dfea6d4 RCX: 0000000000416211 [ 459.395678] RDX: 00007fe45dfe9b0a RSI: 0000000000000002 RDI: 00007fe45dfe9b00 [ 459.396758] RBP: 000000000076bf20 R08: 0000000000000000 R09: 000000000000000a [ 459.397930] R10: 0000000000000075 R11: 0000000000000293 R12: 00000000ffffffff [ 459.399022] R13: 0000000000000bd9 R14: 00000000004cdb80 R15: 000000000076bf2c [ 459.400168] [ 459.400430] Allocated by task 20132: [ 459.401038] kasan_kmalloc+0xbf/0xe0 [ 459.401652] kmem_cache_alloc+0xd5/0x280 [ 459.402330] bdev_alloc_inode+0x18/0x40 [ 459.402970] alloc_inode+0x5f/0x180 [ 459.403510] iget5_locked+0x57/0xd0 [ 459.404095] bdget+0x94/0x4e0 [ 459.404607] bd_acquire+0xfa/0x2c0 [ 459.405113] blkdev_open+0x110/0x290 [ 459.405702] do_dentry_open+0x49e/0x1050 [ 459.406340] path_openat+0x148c/0x3f50 [ 459.406926] do_filp_open+0x1a1/0x280 [ 459.407471] do_sys_open+0x3c3/0x500 [ 459.408010] do_syscall_64+0xc3/0x520 [ 459.408572] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 459.409415] [ 459.409679] Freed by task 1262: [ 459.410212] __kasan_slab_free+0x129/0x170 [ 459.410919] kmem_cache_free+0xb2/0x2a0 [ 459.411564] rcu_process_callbacks+0xbb2/0x2320 [ 459.412318] __do_softirq+0x225/0x8ac Fix this by delaying bdput() to the end of blkdev_get() which means we have finished accessing bdev. Fixes: 77ea887e ("implement in-kernel gendisk events handling") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Jason Yan <yanaijie@huawei.com> Tested-by:
Sedat Dilek <sedat.dilek@gmail.com> Reviewed-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Jens Axboe <axboe@kernel.dk> Cc: Ming Lei <ming.lei@redhat.com> Cc: Jan Kara <jack@suse.cz> Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
David Howells authored
[ Upstream commit 1f32ef79 ] Fix afs_write_end() to change i_size under vnode->cb_lock rather than ->wb_lock so that it doesn't race with afs_vnode_commit_status() and afs_getattr(). The ->wb_lock is only meant to guard access to ->wb_keys which isn't accessed by that piece of code. Fixes: 4343d008 ("afs: Get rid of the afs_writeback record") Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
David Howells authored
[ Upstream commit bb413489 ] The mtime on an inode needs to be updated when a write is made into an mmap'ed section. There are three ways in which this could be done: update it when page_mkwrite is called, update it when a page is changed from dirty to writeback or leave it to the server and fix the mtime up from the reply to the StoreData RPC. Found with the generic/215 xfstest. Fixes: 1cf7a151 ("afs: Implement shared-writeable mmap") Signed-off-by:
-
Zhiqiang Liu authored
[ Upstream commit be23e837 ] coccicheck reports: drivers/md//bcache/btree.c:1538:1-7: preceding lock on line 1417 In btree_gc_coalesce func, if the coalescing process fails, we will goto to out_nocoalesce tag directly without releasing new_nodes[i]->write_lock. Then, it will cause a deadlock when trying to acquire new_nodes[i]-> write_lock for freeing new_nodes[i] before return. btree_gc_coalesce func details as follows: if alloc new_nodes[i] fails: goto out_nocoalesce; // obtain new_nodes[i]->write_lock mutex_lock(&new_nodes[i]->write_lock) // main coalescing process for (i = nodes - 1; i > 0; --i) [snipped] if coalescing process fails: // Here, directly goto out_nocoalesce // tag will cause a deadlock goto out_nocoalesce; [snipped] // release new_nodes[i]->write_lock mutex_unlock(&new_nodes[i]->write_lock) // coalesing succ, return return; out_nocoalesce: btree_node_free(new_nodes[i]) // free new_nodes[i] // obtain new_nodes[i]->write_lock mutex_lock(&new_nodes[i]->write_lock); // set flag for reuse clear_bit(BTREE_NODE_dirty, &ew_nodes[i]->flags); // release new_nodes[i]->write_lock mutex_unlock(&new_nodes[i]->write_lock); To fix the problem, we add a new tag 'out_unlock_nocoalesce' for releasing new_nodes[i]->write_lock before out_nocoalesce tag. If coalescing process fails, we will go to out_unlock_nocoalesce tag for releasing new_nodes[i]->write_lock before free new_nodes[i] in out_nocoalesce tag. (Coly Li helps to clean up commit log format.) Fixes: 2a285686 ("bcache: btree locking rework") Signed-off-by:
Zhiqiang Liu <liuzhiqiang26@huawei.com> Signed-off-by:
Coly Li <colyli@suse.de> Signed-off-by:
-
yangerkun authored
[ Upstream commit 5adaccac ] Now the errcode from ext4_commit_super will overwrite EROFS exists in ext4_setup_super. Actually, no need to call ext4_commit_super since we will return EROFS. Fix it by goto done directly. Fixes: c89128a0 ("ext4: handle errors on ext4_commit_super") Signed-off-by:
yangerkun <yangerkun@huawei.com> Reviewed-by:
-
Gaurav Singh authored
[ Upstream commit 11b6e548 ] The 'evname' variable can be NULL, as it is checked a few lines back, check it before using. Fixes: 9e207ddf ("perf report: Show call graph from reference events") Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@intel.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/Signed-off-by:
Gaurav Singh <gaurav1086@gmail.com> Signed-off-by:
-
Qais Yousef authored
[ Upstream commit 16bdc04c ] Follow suit of ohci-platform.c and perform pm_runtime_set_active() on resume. ohci-platform.c had a warning reported due to the missing pm_runtime_set_active() [1]. [1] https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Qais Yousef <qais.yousef@arm.com> CC: Tony Prisk <linux@prisktech.co.nz> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CC: Mathias Nyman <mathias.nyman@intel.com> CC: Oliver Neukum <oneukum@suse.de> CC: linux-arm-kernel@lists.infradead.org CC: linux-usb@vger.kernel.org CC: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20200518154931.6144-3-qais.yousef@arm.comSigned-off-by:
-
Yoshihiro Shimoda authored
[ Upstream commit cc7eac1e ] Since EHCI/OHCI controllers on R-Car Gen3 SoCs are possible to be getting stuck very rarely after a full/low usb device was disconnected. To detect/recover from such a situation, the controllers require a special way which poll the EHCI PORTSC register and changes the OHCI functional state. So, this patch adds a polling timer into the ehci-platform driver, and if the ehci driver detects the issue by the EHCI PORTSC register, the ehci driver removes a companion device (= the OHCI controller) to change the OHCI functional state to USB Reset once. And then, the ehci driver adds the companion device again. Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Acked-by:
-
Qais Yousef authored
[ Upstream commit 79112cc3 ] Follow suit of ohci-platform.c and perform pm_runtime_set_active() on resume. ohci-platform.c had a warning reported due to the missing pm_runtime_set_active() [1]. [1] https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/Signed-off-by:
-
Li RongQing authored
[ Upstream commit aa2cad06 ] Propagate sock_alloc_send_skb error code, not set it to EAGAIN unconditionally, when fail to allocate skb, which might cause that user space unnecessary loops. Fixes: 35fcde7f ("xsk: support for Tx") Signed-off-by:
Li RongQing <lirongqing@baidu.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Björn Töpel <bjorn.topel@intel.com> Link: https://lore.kernel.org/bpf/1591852266-24017-1-git-send-email-lirongqing@baidu.comSigned-off-by:
-
YiFei Zhu authored
[ Upstream commit 0f5d82f1 ] Added a check in the switch case on start_header that checks for the existence of the header, and in the case that MAC is not set and the caller requests for MAC, -EFAULT. If the caller requests for NET then MAC's existence is completely ignored. There is no function to check NET header's existence and as far as cgroup_skb/egress is concerned it should always be set. Removed for ptr >= the start of header, considering offset is bounded unsigned and should always be true. len <= end - mac is redundant to ptr + len <= end. Fixes: 3eee1f75 ("bpf: fix bpf_skb_load_bytes_relative pkt length check") Signed-off-by:
YiFei Zhu <zhuyifei@google.com> Signed-off-by:
Stanislav Fomichev <sdf@google.com> Link: https://lore.kernel.org/bpf/76bb820ddb6a95f59a772ecbd8c8a336f646b362.1591812755.git.zhuyifei@google.comSigned-off-by:
-
Vitaly Kuznetsov authored
[ Upstream commit 1f1fbc70 ] With commit dc20b2d5 ("x86/idt: Move interrupt gate initialization to IDT code") non assigned system vectors are also marked as used in 'used_vectors' (now 'system_vectors') bitmap. This makes checks in arch_show_interrupts() whether a particular system vector is allocated to always pass and e.g. 'Hyper-V reenlightenment interrupts' entry always shows up in /proc/interrupts. Another side effect of having all unassigned system vectors marked as used is that irq_matrix_debug_show() will wrongly count them among 'System' vectors. As it is now ensured that alloc_intr_gate() is not called after init, it is possible to leave unused entries in 'system_vectors' unset to fix these issues. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/20200428093824.1451532-4-vkuznets@redhat.comSigned-off-by:
-
Christophe JAILLET authored
[ Upstream commit 42c76c98 ] 'ret' is known to be 0 at this point. Explicitly return -ENOMEM if one of the 'ecardm_iomap()' calls fail. Link: https://lore.kernel.org/r/20200530081622.577888-1-christophe.jaillet@wanadoo.fr Fixes: e95a1b65 ("[ARM] rpc: acornscsi: update to new style ecard driver") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Jernej Skrabec authored
[ Upstream commit 54e1e06b ] m divider in DDC clock register is 4 bits wide. Fix that. Fixes: 9c568101 ("drm/sun4i: Add HDMI support") Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200413095457.1176754-1-jernej.skrabec@siol.netSigned-off-by:
-
Hans de Goede authored
[ Upstream commit 79d4f823 ] The Asus T101HA uses the default jack-detect mode 3, but instead of using an analog microphone it is using a DMIC on dmic-data-pin 1, like the Asus T100HA. Note unlike the T100HA its jack-detect is not inverted. Add a DMI quirk with the correct settings for this model. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200608204634.93407-2-hdegoede@redhat.comSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 199a5e8f ] The Toshiba Encore WT10-A tablet almost fully works with the default settings for Bay Trail CR devices. The only issue is that it uses a digital mic. connected the the DMIC1 input instead of an analog mic. Add a quirk for this model using the default settings with the input-map replaced with BYT_RT5640_DMIC1_MAP. Signed-off-by:
-
Bard Liao authored
[ Upstream commit 607fa205 ] Additional checks for valid DAIs expose a corner case, where existing BE dailinks get modified, e.g. HDMI links are tagged with dpcm_capture=1 even if the DAIs are for playback. This patch makes those changes conditional and flags configuration issues when a BE dailink is has no_pcm=0 but dpcm_playback or dpcm_capture=1 (which makes no sense). As discussed on the alsa-devel mailing list, there are redundant flags for dpcm_playback, dpcm_capture, playback_only, capture_only. This will have to be cleaned-up in a future update. For now only correct and flag problematic configurations. Fixes: 218fe9b7 ("ASoC: soc-core: Set dpcm_playback / dpcm_capture") Suggested-by:
Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by:
Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by:
Daniel Baluta <daniel.baluta@gmail.com> Reviewed-by:
-
Zhihao Cheng authored
[ Upstream commit 2ca068be ] Fix afs_put_sysnames() to actually free the specified afs_sysnames object after its reference count has been decreased to zero and its contents have been released. Fixes: 6f8880d8 ("afs: Implement @sys substitution handling") Signed-off-by:
Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by:
-
tannerlove authored
[ Upstream commit 8027bc03 ] If user passed an interface option longer than 15 characters, then device.ifr_name and hwtstamp.ifr_name became non-null-terminated strings. The compiler warned about this: timestamping.c:353:2: warning: ‘strncpy’ specified bound 16 equals \ destination size [-Wstringop-truncation] 353 | strncpy(device.ifr_name, interface, sizeof(device.ifr_name)); Fixes: cb9eff09 ("net: new user space API for time stamping of incoming and outgoing packets") Signed-off-by:
Tanner Love <tannerlove@google.com> Acked-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Shaokun Zhang authored
[ Upstream commit 961abd78 ] In L3C uncore PMU drivers, bit16 is used to control all counters enable & disable. Wrong value is given in the driver and its default value is 1'b1, it can work because each PMU counter has its own control bits too. Let's fix the wrong value. Fixes: 2940bc43 ("perf: hisi: Add support for HiSilicon SoC L3C PMU driver") Signed-off-by:
Shaokun Zhang <zhangshaokun@hisilicon.com> Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/1591350221-32275-1-git-send-email-zhangshaokun@hisilicon.comSigned-off-by:
-
Logan Gunthorpe authored
[ Upstream commit 2130c0ba ] When remote files are counted in get_files_count, without using SSH, the code returns 0 because there is a colon prepended to $LOC. $VPATH should have been used instead of $LOC. Fixes: 06bd0407 ("NTB: ntb_test: Update ntb_tool Scratchpad tests") Signed-off-by:
Logan Gunthorpe <logang@deltatee.com> Acked-by:
Allen Hubbe <allenbh@gmail.com> Tested-by:
Alexander Fomichev <fomichev.ru@gmail.com> Signed-off-by:
Jon Mason <jdmason@kudzu.us> Signed-off-by:
-
Logan Gunthorpe authored
[ Upstream commit 34d8673a ] When running ntb_test, the script tries to run the ntb_perf test immediately after probing the modules. Since adding multi-port support, this fails seeing the new initialization procedure in ntb_perf can not complete instantly. To fix this we add a completion which is waited on when a test is started. In this way, run can be written any time after the module is loaded and it will wait for the initialization to complete instead of sending an error. Fixes: 5648e56d ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by:
-
Logan Gunthorpe authored
[ Upstream commit b54369a2 ] Legacy drivers do not have port numbers (but is reliably only two ports) and was broken by the recent commit that added mult-port support to ntb_perf. This is especially important to support the cross link topology which is perfectly symmetric and cannot assign unique port numbers easily. Hardware that returns zero for both the local port and the peer should just always use gidx=0 for the only peer. Fixes: 5648e56d ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by:
-
Logan Gunthorpe authored
[ Upstream commit a9c4211a ] ntb_perf should not require more than one memory window per peer. This was probably an off-by-one error. Fixes: 5648e56d ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by:
-
Logan Gunthorpe authored
[ Upstream commit 40da7d9a ] Commit 417cf39c ("NTB: Set dma mask and dma coherent mask to NTB devices") started using the NTB device for DMA allocations which was turns out was wrong. If the IOMMU is enabled, such alloctanions will always fail with messages such as: DMAR: Allocating domain for 0000:02:00.1 failed This is because the IOMMU has not setup the device for such use. Change the tools back to using the PCI device for allocations seeing it doesn't make sense to add an IOMMU group for the non-physical NTB device. Also remove the code that sets the DMA mask as it no longer makes sense to do this. Fixes: 7f46c8b3 ("NTB: ntb_tool: Add full multi-port NTB API support") Signed-off-by:
-
Logan Gunthorpe authored
[ Upstream commit 912e1281 ] When running ntb_test this warning is issued: ./ntb_test.sh: line 200: warning: command substitution: ignored null byte in input This is caused by the kernel returning one more byte than is necessary when reading the link file. Reduce the number of bytes read back to 2 as it was before the commit that regressed this. Fixes: 7f46c8b3 ("NTB: ntb_tool: Add full multi-port NTB API support") Signed-off-by:
-
Sanjay R Mehta authored
[ Upstream commit 433efe72 ] Currently, ntb->dev is passed to dma_alloc_coherent and dma_free_coherent calls. The returned dma_addr_t is the CPU physical address. This works fine as long as IOMMU is disabled. But when IOMMU is enabled, we need to make sure that IOVA is returned for dma_addr_t. So the correct way to achieve this is by changing the first parameter of dma_alloc_coherent() as ntb->pdev->dev instead. Fixes: 5648e56d ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by:
Sanjay R Mehta <sanju.mehta@amd.com> Signed-off-by:
Arindam Nath <arindam.nath@amd.com> Signed-off-by:
-
Sanjay R Mehta authored
[ Upstream commit 98f4e140 ] Currently, ntb->dev is passed to dma_alloc_coherent and dma_free_coherent calls. The returned dma_addr_t is the CPU physical address. This works fine as long as IOMMU is disabled. But when IOMMU is enabled, we need to make sure that IOVA is returned for dma_addr_t. So the correct way to achieve this is by changing the first parameter of dma_alloc_coherent() as ntb->pdev->dev instead. Fixes: 5648e56d ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by:
-
Bob Peterson authored
[ Upstream commit 83d060ca ] Before this patch, transactions could be merged into the system transaction by function gfs2_merge_trans(), but the transaction ail lists were never merged. Because the ail flushing mechanism can run separately, bd elements can be attached to the transaction's buffer list during the transaction (trans_add_meta, etc) but quickly moved to its ail lists. Later, in function gfs2_trans_end, the transaction can be freed (by gfs2_trans_end) while it still has bd elements queued to its ail lists, which can cause it to either lose track of the bd elements altogether (memory leak) or worse, reference the bd elements after the parent transaction has been freed. Although I've not seen any serious consequences, the problem becomes apparent with the previous patch's addition of: gfs2_assert_warn(sdp, list_empty(&tr->tr_ail1_list)); to function gfs2_trans_free(). This patch adds logic into gfs2_merge_trans() to move the merged transaction's ail lists to the sdp transaction. This prevents the use-after-free. To do this properly, we need to hold the ail lock, so we pass sdp into the function instead of the transaction itself. Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by:
-
Chaitanya Kulkarni authored
[ Upstream commit 5aec598c ] The function blk_log_remap() can be simplified by removing the call to get_pdu_remap() that copies the values into extra variable to print the data, which also fixes the endiannness warning reported by sparse. Signed-off-by:
Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Signed-off-by:
-
