aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-01-26media: cec: add stm32 driverYannick Fertre1-0/+1
Missing stm32 directory to Makefile. Signed-off-by: Yannick Fertre <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Fixes: 4be5e8648b0c ("media: move CEC platform drivers to a separate directory") Cc: <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2021-01-26media: cedrus: Fix H264 decodingJernej Skrabec1-1/+1
During H264 API overhaul subtle bug was introduced Cedrus driver. Progressive references have both, top and bottom reference flags set. Cedrus reference list expects only bottom reference flag and only when interlaced frames are decoded. However, due to a bug in Cedrus check, exclusivity is not tested and that flag is set also for progressive references. That causes "jumpy" background with many videos. Fix that by checking that only bottom reference flag is set in control and nothing else. Tested-by: Andre Heider <[email protected]> Fixes: cfc8c3ed533e ("media: cedrus: h264: Properly configure reference field") Signed-off-by: Jernej Skrabec <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Cc: <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2021-01-26media: v4l2-subdev.h: BIT() is not available in userspaceHans Verkuil1-1/+1
The BIT macro is not available in userspace, so replace BIT(0) by 0x00000001. Signed-off-by: Hans Verkuil <[email protected]> Fixes: 6446ec6cbf46 ("media: v4l2-subdev: add VIDIOC_SUBDEV_QUERYCAP ioctl") Cc: <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2021-01-26arm64: Fix kernel address detection of __is_lm_address()Vincenzo Frascino1-2/+4
Currently, the __is_lm_address() check just masks out the top 12 bits of the address, but if they are 0, it still yields a true result. This has as a side effect that virt_addr_valid() returns true even for invalid virtual addresses (e.g. 0x0). Fix the detection checking that it's actually a kernel address starting at PAGE_OFFSET. Fixes: 68dd8ef32162 ("arm64: memory: Fix virt_addr_valid() using __is_lm_address()") Cc: <[email protected]> # 5.4.x Cc: Will Deacon <[email protected]> Suggested-by: Catalin Marinas <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Acked-by: Mark Rutland <[email protected]> Signed-off-by: Vincenzo Frascino <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2021-01-26dmaengine: ti: k3-udma: Fix a resource leak in an error handling pathChristophe JAILLET1-1/+2
In 'dma_pool_create()', we return -ENOMEM, but don't release the resources already allocated, as in all the other error handling paths. Go to 'err_res_free' instead of returning directly. Fixes: 017794739702 ("dmaengine: ti: k3-udma: Initial support for K3 BCDMA") Signed-off-by: Christophe JAILLET <[email protected]> Acked-by: Peter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2021-01-26ALSA: hda/via: Apply the workaround generically for Clevo machinesTakashi Iwai1-1/+1
We've got another report indicating a similar problem wrt the power-saving behavior with VIA codec on Clevo machines. Let's apply the existing workaround generically to all Clevo devices with VIA codecs to cover all in once. BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1181330 Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-01-26bpf: Drop disabled LSM hooks from the sleepable setMikko Ylinen1-0/+12
Some networking and keys LSM hooks are conditionally enabled and when building the new sleepable BPF LSM hooks with those LSM hooks disabled, the following build error occurs: BTFIDS vmlinux FAILED unresolved symbol bpf_lsm_socket_socketpair To fix the error, conditionally add the relevant networking/keys LSM hooks to the sleepable set. Fixes: 423f16108c9d8 ("bpf: Augment the set of sleepable LSM hooks") Signed-off-by: Mikko Ylinen <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: KP Singh <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2021-01-26Revert "arm64: dts: amlogic: add missing ethernet reset ID"Neil Armstrong3-7/+0
It has been reported on IRC and in KernelCI boot tests, this change breaks internal PHY support on the Amlogic G12A/SM1 Based boards. We suspect the added signal to reset more than the Ethernet MAC but also the MDIO/(RG)MII mux used to redirect the MAC signals to the internal PHY. This reverts commit f3362f0c18174a1f334a419ab7d567a36bd1b3f3 while we find and acceptable solution to cleanly reset the Ethernet MAC. Reported-by: Corentin Labbe <[email protected]> Acked-by: Jérôme Brunet <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-01-26io_uring: fix cancellation taking mutex while TASK_UNINTERRUPTIBLEPavel Begunkov1-17/+22
do not call blocking ops when !TASK_RUNNING; state=2 set at [<00000000ced9dbfc>] prepare_to_wait+0x1f4/0x3b0 kernel/sched/wait.c:262 WARNING: CPU: 1 PID: 19888 at kernel/sched/core.c:7853 __might_sleep+0xed/0x100 kernel/sched/core.c:7848 RIP: 0010:__might_sleep+0xed/0x100 kernel/sched/core.c:7848 Call Trace: __mutex_lock_common+0xc4/0x2ef0 kernel/locking/mutex.c:935 __mutex_lock kernel/locking/mutex.c:1103 [inline] mutex_lock_nested+0x1a/0x20 kernel/locking/mutex.c:1118 io_wq_submit_work+0x39a/0x720 fs/io_uring.c:6411 io_run_cancel fs/io-wq.c:856 [inline] io_wqe_cancel_pending_work fs/io-wq.c:990 [inline] io_wq_cancel_cb+0x614/0xcb0 fs/io-wq.c:1027 io_uring_cancel_files fs/io_uring.c:8874 [inline] io_uring_cancel_task_requests fs/io_uring.c:8952 [inline] __io_uring_files_cancel+0x115d/0x19e0 fs/io_uring.c:9038 io_uring_files_cancel include/linux/io_uring.h:51 [inline] do_exit+0x2e6/0x2490 kernel/exit.c:780 do_group_exit+0x168/0x2d0 kernel/exit.c:922 get_signal+0x16b5/0x2030 kernel/signal.c:2770 arch_do_signal_or_restart+0x8e/0x6a0 arch/x86/kernel/signal.c:811 handle_signal_work kernel/entry/common.c:147 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0xac/0x1e0 kernel/entry/common.c:201 __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline] syscall_exit_to_user_mode+0x48/0x190 kernel/entry/common.c:302 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Rewrite io_uring_cancel_files() to mimic __io_uring_task_cancel()'s counting scheme, so it does all the heavy work before setting TASK_UNINTERRUPTIBLE. Cc: [email protected] # 5.9+ Reported-by: [email protected] Signed-off-by: Pavel Begunkov <[email protected]> [axboe: fix inverted task check] Signed-off-by: Jens Axboe <[email protected]>
2021-01-26io_uring: fix __io_uring_files_cancel() with TASK_UNINTERRUPTIBLEPavel Begunkov1-6/+5
If the tctx inflight number haven't changed because of cancellation, __io_uring_task_cancel() will continue leaving the task in TASK_UNINTERRUPTIBLE state, that's not expected by __io_uring_files_cancel(). Ensure we always call finish_wait() before retrying. Cc: [email protected] # 5.9+ Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-01-26usb: xhci-mtk: fix unreleased bandwidth dataIkjoon Jang5-39/+111
xhci-mtk needs XHCI_MTK_HOST quirk functions in add_endpoint() and drop_endpoint() to handle its own sw bandwidth management. It stores bandwidth data into an internal table every time add_endpoint() is called, and drops those in drop_endpoint(). But when bandwidth allocation fails at one endpoint, all earlier allocation from the same interface could still remain at the table. This patch moves bandwidth management codes to check_bandwidth() and reset_bandwidth() path. To do so, this patch also adds those functions to xhci_driver_overrides and lets mtk-xhci to release all failed endpoints in reset_bandwidth() path. Fixes: 08e469de87a2 ("usb: xhci-mtk: supports bandwidth scheduling with multi-TT") Signed-off-by: Ikjoon Jang <[email protected]> Link: https://lore.kernel.org/r/20210113180444.v6.1.Id0d31b5f3ddf5e734d2ab11161ac5821921b1e1e@changeid Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-01-26usb: gadget: aspeed: add missing of_node_putkernel test robot1-1/+3
Breaking out of for_each_child_of_node requires a put on the child value. Generated by: scripts/coccinelle/iterators/for_each_child.cocci Fixes: 82c2d81361ec ("coccinelle: iterators: Add for_each_child.cocci script") CC: Sumera Priyadarsini <[email protected]> Reported-by: kernel test robot <[email protected]> Signed-off-by: kernel test robot <[email protected]> Signed-off-by: Julia Lawall <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2101211907060.14700@hadrien Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-01-26USB: usblp: don't call usb_set_interface if there's a single altJeremy Figgins1-8/+11
Some devices, such as the Winbond Electronics Corp. Virtual Com Port (Vendor=0416, ProdId=5011), lockup when usb_set_interface() or usb_clear_halt() are called. This device has only a single altsetting, so it should not be necessary to call usb_set_interface(). Acked-by: Pete Zaitcev <[email protected]> Signed-off-by: Jeremy Figgins <[email protected]> Link: https://lore.kernel.org/r/YAy9kJhM/rG8EQXC@watson Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-01-26futex: Handle faults correctly for PI futexesThomas Gleixner1-37/+20
fixup_pi_state_owner() tries to ensure that the state of the rtmutex, pi_state and the user space value related to the PI futex are consistent before returning to user space. In case that the user space value update faults and the fault cannot be resolved by faulting the page in via fault_in_user_writeable() the function returns with -EFAULT and leaves the rtmutex and pi_state owner state inconsistent. A subsequent futex_unlock_pi() operates on the inconsistent pi_state and releases the rtmutex despite not owning it which can corrupt the RB tree of the rtmutex and cause a subsequent kernel stack use after free. It was suggested to loop forever in fixup_pi_state_owner() if the fault cannot be resolved, but that results in runaway tasks which is especially undesired when the problem happens due to a programming error and not due to malice. As the user space value cannot be fixed up, the proper solution is to make the rtmutex and the pi_state consistent so both have the same owner. This leaves the user space value out of sync. Any subsequent operation on the futex will fail because the 10th rule of PI futexes (pi_state owner and user space value are consistent) has been violated. As a consequence this removes the inept attempts of 'fixing' the situation in case that the current task owns the rtmutex when returning with an unresolvable fault by unlocking the rtmutex which left pi_state::owner and rtmutex::owner out of sync in a different and only slightly less dangerous way. Fixes: 1b7558e457ed ("futexes: fix fault handling in futex_lock_pi") Reported-by: [email protected] Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Cc: [email protected]
2021-01-26futex: Simplify fixup_pi_state_owner()Thomas Gleixner1-27/+26
Too many gotos already and an upcoming fix would make it even more unreadable. Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Cc: [email protected]
2021-01-26futex: Use pi_state_update_owner() in put_pi_state()Thomas Gleixner1-7/+1
No point in open coding it. This way it gains the extra sanity checks. Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Cc: [email protected]
2021-01-26rtmutex: Remove unused argument from rt_mutex_proxy_unlock()Thomas Gleixner3-5/+3
Nothing uses the argument. Remove it as preparation to use pi_state_update_owner(). Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Cc: [email protected]
2021-01-26futex: Provide and use pi_state_update_owner()Thomas Gleixner1-33/+33
Updating pi_state::owner is done at several places with the same code. Provide a function for it and use that at the obvious places. This is also a preparation for a bug fix to avoid yet another copy of the same code or alternatively introducing a completely unpenetratable mess of gotos. Originally-by: Peter Zijlstra <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Cc: [email protected]
2021-01-26futex: Replace pointless printk in fixup_owner()Thomas Gleixner1-7/+3
If that unexpected case of inconsistent arguments ever happens then the futex state is left completely inconsistent and the printk is not really helpful. Replace it with a warning and make the state consistent. Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Cc: [email protected]
2021-01-26futex: Ensure the correct return value from futex_lock_pi()Thomas Gleixner1-15/+16
In case that futex_lock_pi() was aborted by a signal or a timeout and the task returned without acquiring the rtmutex, but is the designated owner of the futex due to a concurrent futex_unlock_pi() fixup_owner() is invoked to establish consistent state. In that case it invokes fixup_pi_state_owner() which in turn tries to acquire the rtmutex again. If that succeeds then it does not propagate this success to fixup_owner() and futex_lock_pi() returns -EINTR or -ETIMEOUT despite having the futex locked. Return success from fixup_pi_state_owner() in all cases where the current task owns the rtmutex and therefore the futex and propagate it correctly through fixup_owner(). Fixup the other callsite which does not expect a positive return value. Fixes: c1e2f0eaf015 ("futex: Avoid violating the 10th rule of futex") Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Cc: [email protected]
2021-01-26drm/i915/gt: Always try to reserve GGTT address 0x0Chris Wilson1-12/+35
Since writing to address 0 is a very common mistake, let's try to avoid putting anything sensitive there. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2989 Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Cc: [email protected] (cherry picked from commit 56b429cc584c6ed8b895d8d8540959655db1ff73) Signed-off-by: Jani Nikula <[email protected]>
2021-01-26drm/i915: Always flush the active worker before returning from the waitChris Wilson1-13/+15
The first thing the active retirement worker does is decrement the i915_active count. The first thing we do during i915_active_wait is try to increment the i915_active count, but only if already active [non-zero]. The wait may see that the retirement is already started and so marked the i915_active as idle, and skip waiting for the retirement handler. However, the caller of i915_active_wait may immediately free the i915_active upon returning (e.g. i915_vma_destroy) so we must not return before the concurrent access from the worker is completed. We must always flush the worker. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2473 Fixes: 274cbf20fd10 ("drm/i915: Push the i915_active.retire into a worker") Signed-off-by: Chris Wilson <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: <[email protected]> # v5.5+ Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 977a372e972cb42799746c284035a33c64ebace9) Signed-off-by: Jani Nikula <[email protected]>
2021-01-26drm/i915/selftest: Fix potential memory leakPan Bian1-1/+1
Object out is not released on path that no VMA instance found. The root cause is jumping to an unexpected label on the error path. Fixes: a47e788c2310 ("drm/i915/selftests: Exercise CS TLB invalidation") Signed-off-by: Pan Bian <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 2b015017d5cb01477a79ca184ac25c247d664568) Signed-off-by: Jani Nikula <[email protected]>
2021-01-26drm/i915: Check for all subplatform bitsUmesh Nerlige Ramappa1-1/+1
Current code is checking only 2 bits in the subplatform, but actually 3 bits are allocated for the field. Check all 3 bits. Fixes: 805446c8347c ("drm/i915: Introduce concept of a sub-platform") Cc: Tvrtko Ursulin <[email protected]> Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 27b695ee1af9bb36605e67055874ec081306ac28) Signed-off-by: Jani Nikula <[email protected]>
2021-01-26drm/i915: Fix ICL MG PHY vswing handlingVille Syrjälä1-4/+3
The MH PHY vswing table does have all the entries these days. Get rid of the old hacks in the code which claim otherwise. This hack was totally bogus anyway. The correct way to handle the lack of those two entries would have been to declare our max vswing and pre-emph to both be level 2. Cc: José Roberto de Souza <[email protected]> Cc: Clinton Taylor <[email protected]> Fixes: 9f7ffa297978 ("drm/i915/tc/icl: Update TC vswing tables") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> (cherry picked from commit 5ec346476e795089b7dac8ab9dcee30c8d80ad84) Signed-off-by: Jani Nikula <[email protected]>
2021-01-26drm/i915/gt: Clear CACHE_MODE prior to clearing residualsChris Wilson1-0/+12
Since we do a bare context switch with no restore, the clear residual kernel runs on dirty state, and we must be careful to avoid executing with bad state from context registers inherited from a malicious client. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2955 Fixes: 09aa9e45863e ("drm/i915/gt: Restore clear-residual mitigations for Ivybridge, Baytrail") Testcase: igt/gem_ctx_isolation # ivb,vlv Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Akeem G Abodunrin <[email protected]> Reviewed-by: Akeem G Abodunrin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit ace44e13e577c2ae59980e9a6ff5ca253b1cf831) Signed-off-by: Jani Nikula <[email protected]>
2021-01-26Merge tag 'asoc-fix-v5.11-rc5' of ↵Takashi Iwai22-61/+184
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.11 More fixes for v5.11, almost all driver specific issues including new device IDs - there's one error handling fix for the topology stuff too.
2021-01-26staging: rtl8723bs: fix wireless regulatory API misuseJohannes Berg3-13/+9
This code ends up calling wiphy_apply_custom_regulatory(), for which we document that it should be called before wiphy_register(). This driver doesn't do that, but calls it from ndo_open() with the RTNL held, which caused deadlocks. Since the driver just registers static regdomain data and then the notifier applies the channel changes if any, there's no reason for it to call this in ndo_open(), move it earlier to fix the deadlock. Reported-and-tested-by: Hans de Goede <[email protected]> Fixes: 51d62f2f2c50 ("cfg80211: Save the regulatory domain with a lock") Link: https://lore.kernel.org/r/20210126115409.d5fd6f8fe042.Ib5823a6feb2e2aa01ca1a565d2505367f38ad246@changeid Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2021-01-26mac80211: pause TX while changing interface typeJohannes Berg2-0/+7
syzbot reported a crash that happened when changing the interface type around a lot, and while it might have been easy to fix just the symptom there, a little deeper investigation found that really the reason is that we allowed packets to be transmitted while in the middle of changing the interface type. Disallow TX by stopping the queues while changing the type. Fixes: 34d4bc4d41d2 ("mac80211: support runtime interface type changes") Reported-by: [email protected] Link: https://lore.kernel.org/r/20210122171115.b321f98f4d4f.I6997841933c17b093535c31d29355be3c0c39628@changeid Signed-off-by: Johannes Berg <[email protected]>
2021-01-26wext: fix NULL-ptr-dereference with cfg80211's lack of commit()Johannes Berg1-2/+3
Since cfg80211 doesn't implement commit, we never really cared about that code there (and it's configured out w/o CONFIG_WIRELESS_EXT). After all, since it has no commit, it shouldn't return -EIWCOMMIT to indicate commit is needed. However, EIWCOMMIT is actually an alias for EINPROGRESS, which _can_ happen if e.g. we try to change the frequency but we're already in the process of connecting to some network, and drivers could return that value (or even cfg80211 itself might). This then causes us to crash because dev->wireless_handlers is NULL but we try to check dev->wireless_handlers->standard[0]. Fix this by also checking dev->wireless_handlers. Also simplify the code a little bit. Cc: [email protected] Reported-by: [email protected] Reported-by: [email protected] Link: https://lore.kernel.org/r/20210121171621.2076e4a37d5a.I5d9c72220fe7bb133fb718751da0180a57ecba4e@changeid Signed-off-by: Johannes Berg <[email protected]>
2021-01-26HID: wacom: Correct NULL dereference on AES pen proximityJason Gerecke2-4/+5
The recent commit to fix a memory leak introduced an inadvertant NULL pointer dereference. The `wacom_wac->pen_fifo` variable was never intialized, resuling in a crash whenever functions tried to use it. Since the FIFO is only used by AES pens (to buffer events from pen proximity until the hardware reports the pen serial number) this would have been easily overlooked without testing an AES device. This patch converts `wacom_wac->pen_fifo` over to a pointer (since the call to `devres_alloc` allocates memory for us) and ensures that we assign it to point to the allocated and initalized `pen_fifo` before the function returns. Link: https://github.com/linuxwacom/input-wacom/issues/230 Fixes: 37309f47e2f5 ("HID: wacom: Fix memory leakage caused by kfifo_alloc") CC: [email protected] # v4.19+ Signed-off-by: Jason Gerecke <[email protected]> Tested-by: Ping Cheng <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2021-01-26xen-blkfront: allow discard-* nodes to be optionalRoger Pau Monne1-13/+7
This is inline with the specification described in blkif.h: * discard-granularity: should be set to the physical block size if node is not present. * discard-alignment, discard-secure: should be set to 0 if node not present. This was detected as QEMU would only create the discard-granularity node but not discard-alignment, and thus the setup done in blkfront_setup_discard would fail. Fix blkfront_setup_discard to not fail on missing nodes, and also fix blkif_set_queue_limits to set the discard granularity to the physical block size if none is specified in xenbus. Fixes: ed30bf317c5ce ('xen-blkfront: Handle discard requests.') Reported-by: Arthur Borsboom <[email protected]> Signed-off-by: Roger Pau Monné <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Tested-By: Arthur Borsboom <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2021-01-26ecryptfs: fix uid translation for setxattr on security.capabilityMiklos Szeredi1-3/+7
Prior to commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into vfs_setxattr()") the translation of nscap->rootid did not take stacked filesystems (overlayfs and ecryptfs) into account. That patch fixed the overlay case, but made the ecryptfs case worse. Restore old the behavior for ecryptfs that existed before the overlayfs fix. This does not fix ecryptfs's handling of complex user namespace setups, but it does make sure existing setups don't regress. Reported-by: Eric W. Biederman <[email protected]> Cc: Tyler Hicks <[email protected]> Fixes: 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into vfs_setxattr()") Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Tyler Hicks <[email protected]>
2021-01-25KVM: x86: allow KVM_REQ_GET_NESTED_STATE_PAGES outside guest mode for VMXPaolo Bonzini3-9/+29
VMX also uses KVM_REQ_GET_NESTED_STATE_PAGES for the Hyper-V eVMCS, which may need to be loaded outside guest mode. Therefore we cannot WARN in that case. However, that part of nested_get_vmcs12_pages is _not_ needed at vmentry time. Split it out of KVM_REQ_GET_NESTED_STATE_PAGES handling, so that both vmentry and migration (and in the latter case, independent of is_guest_mode) do the parts that are needed. Cc: <[email protected]> # 5.10.x: f2c7ef3ba: KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES Cc: <[email protected]> # 5.10.x Signed-off-by: Paolo Bonzini <[email protected]>
2021-01-25KVM: x86: Revert "KVM: x86: Mark GPRs dirty when written"Sean Christopherson1-26/+25
Revert the dirty/available tracking of GPRs now that KVM copies the GPRs to the GHCB on any post-VMGEXIT VMRUN, even if a GPR is not dirty. Per commit de3cd117ed2f ("KVM: x86: Omit caching logic for always-available GPRs"), tracking for GPRs noticeably impacts KVM's code footprint. This reverts commit 1c04d8c986567c27c56c05205dceadc92efb14ff. Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-01-25KVM: SVM: Unconditionally sync GPRs to GHCB on VMRUN of SEV-ES guestSean Christopherson1-9/+6
Drop the per-GPR dirty checks when synchronizing GPRs to the GHCB, the GRPs' dirty bits are set from time zero and never cleared, i.e. will always be seen as dirty. The obvious alternative would be to clear the dirty bits when appropriate, but removing the dirty checks is desirable as it allows reverting GPR dirty+available tracking, which adds overhead to all flavors of x86 VMs. Note, unconditionally writing the GPRs in the GHCB is tacitly allowed by the GHCB spec, which allows the hypervisor (or guest) to provide unnecessary info; it's the guest's responsibility to consume only what it needs (the hypervisor is untrusted after all). The guest and hypervisor can supply additional state if desired but must not rely on that additional state being provided. Cc: Brijesh Singh <[email protected]> Cc: Tom Lendacky <[email protected]> Fixes: 291bd20d5d88 ("KVM: SVM: Add initial support for a VMGEXIT VMEXIT") Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-01-25KVM: nVMX: Sync unsync'd vmcs02 state to vmcs12 on migrationMaxim Levitsky1-5/+8
Even when we are outside the nested guest, some vmcs02 fields may not be in sync vs vmcs12. This is intentional, even across nested VM-exit, because the sync can be delayed until the nested hypervisor performs a VMCLEAR or a VMREAD/VMWRITE that affects those rarely accessed fields. However, during KVM_GET_NESTED_STATE, the vmcs12 has to be up to date to be able to restore it. To fix that, call copy_vmcs02_to_vmcs12_rare() before the vmcs12 contents are copied to userspace. Fixes: 7952d769c29ca ("KVM: nVMX: Sync rarely accessed guest fields only when needed") Reviewed-by: Sean Christopherson <[email protected]> Signed-off-by: Maxim Levitsky <[email protected]> Message-Id: <[email protected]> Cc: [email protected] Signed-off-by: Paolo Bonzini <[email protected]>
2021-01-25kvm: tracing: Fix unmatched kvm_entry and kvm_exit eventsLorenzo Brescia3-2/+5
On VMX, if we exit and then re-enter immediately without leaving the vmx_vcpu_run() function, the kvm_entry event is not logged. That means we will see one (or more) kvm_exit, without its (their) corresponding kvm_entry, as shown here: CPU-1979 [002] 89.871187: kvm_entry: vcpu 1 CPU-1979 [002] 89.871218: kvm_exit: reason MSR_WRITE CPU-1979 [002] 89.871259: kvm_exit: reason MSR_WRITE It also seems possible for a kvm_entry event to be logged, but then we leave vmx_vcpu_run() right away (if vmx->emulation_required is true). In this case, we will have a spurious kvm_entry event in the trace. Fix these situations by moving trace_kvm_entry() inside vmx_vcpu_run() (where trace_kvm_exit() already is). A trace obtained with this patch applied looks like this: CPU-14295 [000] 8388.395387: kvm_entry: vcpu 0 CPU-14295 [000] 8388.395392: kvm_exit: reason MSR_WRITE CPU-14295 [000] 8388.395393: kvm_entry: vcpu 0 CPU-14295 [000] 8388.395503: kvm_exit: reason EXTERNAL_INTERRUPT Of course, not calling trace_kvm_entry() in common x86 code any longer means that we need to adjust the SVM side of things too. Signed-off-by: Lorenzo Brescia <[email protected]> Signed-off-by: Dario Faggioli <[email protected]> Message-Id: <160873470698.11652.13483635328769030605.stgit@Wayrath> Signed-off-by: Paolo Bonzini <[email protected]>
2021-01-25KVM: Documentation: Update description of KVM_{GET,CLEAR}_DIRTY_LOGZenghui Yu1-9/+7
Update various words, including the wrong parameter name and the vague description of the usage of "slot" field. Signed-off-by: Zenghui Yu <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-01-25KVM: x86: get smi pending status correctlyJay Zhou1-0/+4
The injection process of smi has two steps: Qemu KVM Step1: cpu->interrupt_request &= \ ~CPU_INTERRUPT_SMI; kvm_vcpu_ioctl(cpu, KVM_SMI) call kvm_vcpu_ioctl_smi() and kvm_make_request(KVM_REQ_SMI, vcpu); Step2: kvm_vcpu_ioctl(cpu, KVM_RUN, 0) call process_smi() if kvm_check_request(KVM_REQ_SMI, vcpu) is true, mark vcpu->arch.smi_pending = true; The vcpu->arch.smi_pending will be set true in step2, unfortunately if vcpu paused between step1 and step2, the kvm_run->immediate_exit will be set and vcpu has to exit to Qemu immediately during step2 before mark vcpu->arch.smi_pending true. During VM migration, Qemu will get the smi pending status from KVM using KVM_GET_VCPU_EVENTS ioctl at the downtime, then the smi pending status will be lost. Signed-off-by: Jay Zhou <[email protected]> Signed-off-by: Shengen Zhuang <[email protected]> Message-Id: <[email protected]> Cc: [email protected] Signed-off-by: Paolo Bonzini <[email protected]>
2021-01-25KVM: x86/pmu: Fix HW_REF_CPU_CYCLES event pseudo-encoding in intel_arch_events[]Like Xu1-1/+1
The HW_REF_CPU_CYCLES event on the fixed counter 2 is pseudo-encoded as 0x0300 in the intel_perfmon_event_map[]. Correct its usage. Fixes: 62079d8a4312 ("KVM: PMU: add proper support for fixed counter 2") Signed-off-by: Like Xu <[email protected]> Message-Id: <[email protected]> Reviewed-by: Sean Christopherson <[email protected]> Cc: [email protected] Signed-off-by: Paolo Bonzini <[email protected]>
2021-01-25KVM: x86/pmu: Fix UBSAN shift-out-of-bounds warning in intel_pmu_refresh()Like Xu1-0/+4
Since we know vPMU will not work properly when (1) the guest bit_width(s) of the [gp|fixed] counters are greater than the host ones, or (2) guest requested architectural events exceeds the range supported by the host, so we can setup a smaller left shift value and refresh the guest cpuid entry, thus fixing the following UBSAN shift-out-of-bounds warning: shift exponent 197 is too large for 64-bit type 'long long unsigned int' Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:395 intel_pmu_refresh.cold+0x75/0x99 arch/x86/kvm/vmx/pmu_intel.c:348 kvm_vcpu_after_set_cpuid+0x65a/0xf80 arch/x86/kvm/cpuid.c:177 kvm_vcpu_ioctl_set_cpuid2+0x160/0x440 arch/x86/kvm/cpuid.c:308 kvm_arch_vcpu_ioctl+0x11b6/0x2d70 arch/x86/kvm/x86.c:4709 kvm_vcpu_ioctl+0x7b9/0xdb0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3386 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reported-by: [email protected] Signed-off-by: Like Xu <[email protected]> Message-Id: <[email protected]> Cc: [email protected] Signed-off-by: Paolo Bonzini <[email protected]>
2021-01-25KVM: x86: Add more protection against undefined behavior in rsvd_bits()Sean Christopherson1-1/+8
Add compile-time asserts in rsvd_bits() to guard against KVM passing in garbage hardcoded values, and cap the upper bound at '63' for dynamic values to prevent generating a mask that would overflow a u64. Suggested-by: Paolo Bonzini <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-01-25KVM: Documentation: Fix spec for KVM_CAP_ENABLE_CAP_VMQuentin Perret1-1/+1
The documentation classifies KVM_ENABLE_CAP with KVM_CAP_ENABLE_CAP_VM as a vcpu ioctl, which is incorrect. Fix it by specifying it as a VM ioctl. Fixes: e5d83c74a580 ("kvm: make KVM_CAP_ENABLE_CAP_VM architecture agnostic") Signed-off-by: Quentin Perret <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-01-25Merge tag 'kvmarm-fixes-5.11-2' of ↵Paolo Bonzini6-49/+74
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 5.11, take #2 - Don't allow tagged pointers to point to memslots - Filter out ARMv8.1+ PMU events on v8.0 hardware - Hide PMU registers from userspace when no PMU is configured - More PMU cleanups - Don't try to handle broken PSCI firmware - More sys_reg() to reg_to_encoding() conversions
2021-01-25Merge branch 'linus' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "Fix a regression in the cesa driver" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: marvel/cesa - Fix tdma descriptor on 64-bit
2021-01-25uapi: fix big endian definition of ipv6_rpl_sr_hdrJustin Iurman1-3/+3
Following RFC 6554 [1], the current order of fields is wrong for big endian definition. Indeed, here is how the header looks like: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CmprI | CmprE | Pad | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This patch reorders fields so that big endian definition is now correct. [1] https://tools.ietf.org/html/rfc6554#section-3 Fixes: cfa933d938d8 ("include: uapi: linux: add rpl sr header definition") Signed-off-by: Justin Iurman <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-25dt-bindings: usb: j721e: add ranges and dma-coherent propsGrygorii Strashko1-0/+4
Add missed 'ranges' and 'dma-coherent' properties as cdns-usb DT nodes has child node and DMA IO is coherent on TI K3 J721E/J7200 SoCs. This also fixes dtbs_check warning: cdns-usb@4104000: 'dma-coherent', 'ranges' do not match any of the regexes: '^usb@', 'pinctrl-[0-9]+' Signed-off-by: Grygorii Strashko <[email protected]> Acked-by: Aswath Govindraju <[email protected]> Reviewed-by: Aswath Govindraju <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring <[email protected]>
2021-01-26arm64: dts: rockchip: Disable display for NanoPi R2SRobin Murphy1-0/+4
NanoPi R2S is headless, so rightly does not enable any of the display interface hardware, which currently provokes an obnoxious error in the boot log from the fake DRM device failing to find anything to bind to. It probably isn't *too* hard to obviate the fake device shenanigans entirely with a bit of driver reshuffling, but for now let's just disable it here to shut up the spurious error. Signed-off-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/c4553dfad1ad6792c4f22454c135ff55de77e2d6.1611186099.git.robin.murphy@arm.com Signed-off-by: Heiko Stuebner <[email protected]>
2021-01-26doc: gcc-plugins: update gcc-plugins.rstMasahiro Yamada1-20/+21
This document was written a long time ago. Update it. [1] Drop the version information The range of the supported GCC versions are always changing. The current minimal GCC version is 4.9, and commit 1e860048c53e ("gcc-plugins: simplify GCC plugin-dev capability test") removed the old code accordingly. We do not need to mention specific version ranges like "all gcc versions from 4.5 to 6.0" since we forget to update the documentation when we raise the minimal compiler version. [2] Drop the C compiler statements Since commit 77342a02ff6e ("gcc-plugins: drop support for GCC <= 4.7") the GCC plugin infrastructure only supports g++. [3] Drop supported architectures As of v5.11-rc4, the infrastructure supports more architectures; arm, arm64, mips, powerpc, riscv, s390, um, and x86. (just grep "select HAVE_GCC_PLUGINS") Again, we miss to update this document when a new architecture is supported. Let's just say "only some architectures". [4] Update the apt-get example We are now discussing to bump the minimal version to GCC 5. The GCC 4.9 support will be removed sooner or later. Change the package example to gcc-10-plugin-dev while we are here. [5] Update the build target Since commit ce2fd53a10c7 ("kbuild: descend into scripts/gcc-plugins/ via scripts/Makefile"), "make gcc-plugins" is not supported. "make scripts" builds all the enabled plugins, including some other tools. [6] Update the steps for adding a new plugin At first, all CONFIG options for GCC plugins were located in arch/Kconfig. After commit 45332b1bdfdc ("gcc-plugins: split out Kconfig entries to scripts/gcc-plugins/Kconfig"), scripts/gcc-plugins/Kconfig became the central place to collect plugin CONFIG options. In my understanding, this requirement no longer exists because commit 9f671e58159a ("security: Create "kernel hardening" config area") moved some of plugin CONFIG options to another file. Find an appropriate place to add the new CONFIG. The sub-directory support was never used by anyone, and removed by commit c17d6179ad5a ("gcc-plugins: remove unused GCC_PLUGIN_SUBDIR"). Remove the useless $(src)/ prefix. Signed-off-by: Masahiro Yamada <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.