Dave Airlie [Tue, 7 Apr 2020 23:14:21 +0000 (09:14 +1000)]
Merge tag 'drm-misc-next-fixes-2020-04-04' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
A bunch of fixes to avoid null pointer dereference in fbcon, fix a return
in xen, some DT bindings fixes, a vc4 issue with 1920x1200 mode validation,
and a conflicting framebuffer in vboxvideo.
Ben Skeggs [Tue, 31 Mar 2020 06:08:44 +0000 (16:08 +1000)]
drm/nouveau/gr/gp107,gp108: implement workaround for HW hanging during init
Certain boards with GP107/GP108 chipsets hang (often, but randomly) for
unknown reasons during GR initialisation.
The first tell-tale symptom of this issue is:
nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 409800 [ TIMEOUT ]
appearing in dmesg, likely followed by many other failures being logged.
Karol found this WAR for the issue a while back, but efforts to isolate
the root cause and proper fix have not yielded success so far. I've
modified the original patch to include a few more details, limit it to
GP107/GP108 by default, and added a config option to override this choice.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com>
Karol Herbst [Tue, 24 Mar 2020 20:29:23 +0000 (21:29 +0100)]
drm/nouveau: workaround runpm fail by disabling PCI power management on certain intel bridges
Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
Depending on the used kernel there might be messages like those in demsg:
"nouveau 0000:01:00.0: Refused to change power state, currently in D3"
"nouveau 0000:01:00.0: can't change power state from D3cold to D0 (config
space inaccessible)"
followed by backtraces of kernel crashes or timeouts within nouveau.
It's still unkown why this issue exists, but this is a reliable workaround
and solves a very annoying issue for user having to choose between a
crashing kernel or higher power consumption of their Laptops.
Signed-off-by: Karol Herbst <kherbst@redhat.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Mika Westerberg <mika.westerberg@intel.com> Cc: linux-pci@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ralph Campbell [Wed, 4 Mar 2020 00:13:38 +0000 (16:13 -0800)]
drm/nouveau/svm: remove useless SVM range check
When nouveau processes GPU faults, it checks to see if the fault address
falls within the "unmanaged" range which is reserved for fixed allocations
instead of addresses chosen by the core mm code. If start is greater than
or equal to svmm->unmanaged.limit, then limit will also be greater than
svmm->unmanaged.limit which is greater than svmm->unmanaged.start and the
start = max_t(u64, start, svmm->unmanaged.limit) will change nothing.
Just remove the useless lines of code.
Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ralph Campbell [Wed, 4 Mar 2020 00:13:37 +0000 (16:13 -0800)]
drm/nouveau/svm: check for SVM initialized before migrating
When migrating system memory to GPU memory, check that SVM has been
enabled. Even though most errors can be ignored since migration is
a performance optimization, return an error because this is a violation
of the API.
Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ralph Campbell [Wed, 4 Mar 2020 00:13:36 +0000 (16:13 -0800)]
drm/nouveau/svm: fix vma range check for migration
find_vma_intersection(mm, start, end) only guarantees that end is greater
than or equal to vma->vm_start but doesn't guarantee that start is
greater than or equal to vma->vm_start. The calculation for the
intersecting range in nouveau_svmm_bind() isn't accounting for this and
can call migrate_vma_setup() with a starting address less than
vma->vm_start. This results in migrate_vma_setup() returning -EINVAL for
the range instead of nouveau skipping that part of the range and migrating
the rest.
Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Wambui Karuga [Tue, 18 Feb 2020 17:28:17 +0000 (20:28 +0300)]
drm/nouveau: remove checks for return value of debugfs functions
As there is no need to check for the return value of debugfs_create_file
and drm_debugfs_create_files, remove unnecessary checks and error
handling in nouveau_drm_debugfs_init.
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Dave Airlie [Thu, 2 Apr 2020 20:09:51 +0000 (06:09 +1000)]
Merge branch 'ttm-transhuge' of git://people.freedesktop.org/~thomash/linux into drm-next
Huge page-table entries for TTM
In order to reduce CPU usage [1] and in theory TLB misses this patchset enables
huge- and giant page-table entries for TTM and TTM-enabled graphics drivers.
Dave Airlie [Tue, 31 Mar 2020 06:34:49 +0000 (16:34 +1000)]
Merge tag 'drm-msm-next-2020-03-22' of https://gitlab.freedesktop.org/drm/msm into drm-next
A bit smaller this time around.. there are still a couple uabi
additions for vulkan waiting in the wings, but I punted on them this
cycle due to running low on time. (They should be easy enough to
rebase, and if it is a problem for anyone I can push a next+uabi
branch so that tu work can proceed.)
The bigger change is refactoring dpu resource manager and moving dpu
to use atomic global state. Other than that, it is mostly cleanups
and fixes.
Rob Herring [Fri, 13 Mar 2020 18:07:27 +0000 (13:07 -0500)]
dt-bindings: display: ti: Fix dtc unit-address warnings in examples
Extra dtc warnings (roughly what W=1 enables) are now enabled by default
when building the binding examples. These were fixed treewide in
5.6-rc5, but some new display bindings have been added with new
warnings:
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.example.dts:21.27-49.11: Warning (unit_address_format): /example-0/dss@04a00000: unit name should not have leading 0s
Documentation/devicetree/bindings/display/ti/ti,j721e-dss.example.dts:21.27-72.11: Warning (unit_address_format): /example-0/dss@04a00000: unit name should not have leading 0s
Documentation/devicetree/bindings/display/ti/ti,k2g-dss.example.dts:20.27-42.11: Warning (unit_address_format): /example-0/dss@02540000: unit name should not have leading 0s
Dave Airlie [Mon, 30 Mar 2020 05:56:03 +0000 (15:56 +1000)]
Merge tag 'drm-intel-next-fixes-2020-03-27' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
Fixes for instability on Baytrail and Haswell;
Ice Lake RPS; Sandy Bridge RC6; and few others around
GT hangchec/reset; livelock; and a null dereference.
Linus Torvalds [Sun, 29 Mar 2020 17:40:31 +0000 (10:40 -0700)]
Merge branch 'akpm' (patches from Andrew)
Merge vm fixes from Andrew Morton:
"5 fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
mm/sparse: fix kernel crash with pfn_section_valid check
mm: fork: fix kernel_stack memcg stats for various stack implementations
hugetlb_cgroup: fix illegal access to memory
drivers/base/memory.c: indicate all memory blocks as removable
mm/swapfile.c: move inode_lock out of claim_swapfile
Linus Torvalds [Sun, 29 Mar 2020 17:36:29 +0000 (10:36 -0700)]
Merge tag 'timers-urgent-2020-03-29' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fix from Thomas Gleixner:
"A single fix for the Hyper-V clocksource driver to make sched clock
actually return nanoseconds and not the virtual clock value which
increments at 10e7 HZ (100ns)"
* tag 'timers-urgent-2020-03-29' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
clocksource/drivers/hyper-v: Make sched clock return nanoseconds correctly
mm/sparse: fix kernel crash with pfn_section_valid check
Fix the crash like this:
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc000000000c3447c
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
CPU: 11 PID: 7519 Comm: lt-ndctl Not tainted 5.6.0-rc7-autotest #1
...
NIP [c000000000c3447c] vmemmap_populated+0x98/0xc0
LR [c000000000088354] vmemmap_free+0x144/0x320
Call Trace:
section_deactivate+0x220/0x240
__remove_pages+0x118/0x170
arch_remove_memory+0x3c/0x150
memunmap_pages+0x1cc/0x2f0
devm_action_release+0x30/0x50
release_nodes+0x2f8/0x3e0
device_release_driver_internal+0x168/0x270
unbind_store+0x130/0x170
drv_attr_store+0x44/0x60
sysfs_kf_write+0x68/0x80
kernfs_fop_write+0x100/0x290
__vfs_write+0x3c/0x70
vfs_write+0xcc/0x240
ksys_write+0x7c/0x140
system_call+0x5c/0x68
The crash is due to NULL dereference at
test_bit(idx, ms->usage->subsection_map);
due to ms->usage = NULL in pfn_section_valid()
With commit 9082c462c394 ("mm/hotplug: fix hot remove failure in
SPARSEMEM|!VMEMMAP case") section_mem_map is set to NULL after
depopulate_section_mem(). This was done so that pfn_page() can work
correctly with kernel config that disables SPARSEMEM_VMEMMAP. With that
config pfn_to_page does
Now with SPASEMEM_VMEMAP enabled, mem_section->usage->subsection_map is
used to check the pfn validity (pfn_valid()). Since section_deactivate
release mem_section->usage if a section is fully deactivated,
pfn_valid() check after a subsection_deactivate cause a kernel crash.
static inline int pfn_valid(unsigned long pfn)
{
...
return early_section(ms) || pfn_section_valid(ms, pfn);
}
where
static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
{
int idx = subsection_map_index(pfn);
Avoid this by clearing SECTION_HAS_MEM_MAP when mem_section->usage is
freed. For architectures like ppc64 where large pages are used for
vmmemap mapping (16MB), a specific vmemmap mapping can cover multiple
sections. Hence before a vmemmap mapping page can be freed, the kernel
needs to make sure there are no valid sections within that mapping.
Clearing the section valid bit before depopulate_section_memap enables
this.
[aneesh.kumar@linux.ibm.com: add comment] Link: http://lkml.kernel.org/r/20200326133235.343616-1-aneesh.kumar@linux.ibm.comLink: Fixes: 9082c462c394 ("mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case") Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com> Reviewed-by: Baoquan He <bhe@redhat.com> Reviewed-by: Wei Yang <richard.weiyang@gmail.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Dan Williams <dan.j.williams@intel.com> Cc: David Hildenbrand <david@redhat.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Roman Gushchin [Sun, 29 Mar 2020 02:17:25 +0000 (19:17 -0700)]
mm: fork: fix kernel_stack memcg stats for various stack implementations
Depending on CONFIG_VMAP_STACK and the THREAD_SIZE / PAGE_SIZE ratio the
space for task stacks can be allocated using __vmalloc_node_range(),
alloc_pages_node() and kmem_cache_alloc_node().
In the first and the second cases page->mem_cgroup pointer is set, but
in the third it's not: memcg membership of a slab page should be
determined using the memcg_from_slab_page() function, which looks at
page->slab_cache->memcg_params.memcg . In this case, using
mod_memcg_page_state() (as in account_kernel_stack()) is incorrect:
page->mem_cgroup pointer is NULL even for pages charged to a non-root
memory cgroup.
It can lead to kernel_stack per-memcg counters permanently showing 0 on
some architectures (depending on the configuration).
In order to fix it, let's introduce a mod_memcg_obj_state() helper,
which takes a pointer to a kernel object as a first argument, uses
mem_cgroup_from_obj() to get a RCU-protected memcg pointer and calls
mod_memcg_state(). It allows to handle all possible configurations
(CONFIG_VMAP_STACK and various THREAD_SIZE/PAGE_SIZE values) without
spilling any memcg/kmem specifics into fork.c .
Note: This is a special version of the patch created for stable
backports. It contains code from the following two patches:
- mm: memcg/slab: introduce mem_cgroup_from_obj()
- mm: fork: fix kernel_stack memcg stats for various stack implementations
[guro@fb.com: introduce mem_cgroup_from_obj()] Link: http://lkml.kernel.org/r/20200324004221.GA36662@carbon.dhcp.thefacebook.com Fixes: bafe805e79f5 ("mm: memcg/slab: stop setting page->mem_cgroup pointer for slab pages") Signed-off-by: Roman Gushchin <guro@fb.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Shakeel Butt <shakeelb@google.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Bharata B Rao <bharata@linux.ibm.com> Cc: Shakeel Butt <shakeelb@google.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20200303233550.251375-1-guro@fb.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Mina Almasry [Sun, 29 Mar 2020 02:17:22 +0000 (19:17 -0700)]
hugetlb_cgroup: fix illegal access to memory
This appears to be a mistake in commit 8baa6aa26d07d ("mm: hugetlb
controller for cgroups v2").
Essentially that commit does a hugetlb_cgroup_from_counter assuming that
page_counter_try_charge has initialized counter.
But if that has failed then it seems will not initialize counter, so
hugetlb_cgroup_from_counter(counter) ends up pointing to random memory,
causing kasan to complain.
The solution is to simply use 'h_cg', instead of
hugetlb_cgroup_from_counter(counter), since that is a reference to the
hugetlb_cgroup anyway. After this change kasan ceases to complain.
Fixes: 8baa6aa26d07d ("mm: hugetlb controller for cgroups v2") Reported-by: syzbot+cac0c4e204952cf449b1@syzkaller.appspotmail.com Signed-off-by: Mina Almasry <almasrymina@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Giuseppe Scrivano <gscrivan@redhat.com> Acked-by: Tejun Heo <tj@kernel.org> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: David Rientjes <rientjes@google.com> Link: http://lkml.kernel.org/r/20200313223920.124230-1-almasrymina@google.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
drivers/base/memory.c: indicate all memory blocks as removable
We see multiple issues with the implementation/interface to compute
whether a memory block can be offlined (exposed via
/sys/devices/system/memory/memoryX/removable) and would like to simplify
it (remove the implementation).
1. It runs basically lockless. While this might be good for performance,
we see possible races with memory offlining that will require at
least some sort of locking to fix.
2. Nowadays, more false positives are possible. No arch-specific checks
are performed that validate if memory offlining will not be denied
right away (and such check will require locking). For example, arm64
won't allow to offline any memory block that was added during boot -
which will imply a very high error rate. Other archs have other
constraints.
3. The interface is inherently racy. E.g., if a memory block is detected
to be removable (and was not a false positive at that time), there is
still no guarantee that offlining will actually succeed. So any
caller already has to deal with false positives.
4. It is unclear which performance benefit this interface actually
provides. The introducing commit b80d8c7700d9 ("memory-hotplug: add
sysfs removable attribute for hotplug memory remove") mentioned
"A user-level agent must be able to identify which sections
of memory are likely to be removable before attempting the
potentially expensive operation."
However, no actual performance comparison was included.
Known users:
- lsmem: Will group memory blocks based on the "removable" property. [1]
- chmem: Indirect user. It has a RANGE mode where one can specify
removable ranges identified via lsmem to be offlined. However,
it also has a "SIZE" mode, which allows a sysadmin to skip the
manual "identify removable blocks" step. [2]
- powerpc-utils: Uses the "removable" attribute to skip some memory
blocks right away when trying to find some to offline+remove.
However, with ballooning enabled, it already skips this
information completely (because it once resulted in many false
negatives). Therefore, the implementation can deal with false
positives properly already. [3]
According to Nathan Fontenot, DLPAR on powerpc is nowadays no longer
driven from userspace via the drmgr command (powerpc-utils). Nowadays
it's managed in the kernel - including onlining/offlining of memory
blocks - triggered by drmgr writing to /sys/kernel/dlpar. So the
affected legacy userspace handling is only active on old kernels. Only
very old versions of drmgr on a new kernel (unlikely) might execute
slower - totally acceptable.
With CONFIG_MEMORY_HOTREMOVE, always indicating "removable" should not
break any user space tool. We implement a very bad heuristic now.
Without CONFIG_MEMORY_HOTREMOVE we cannot offline anything, so report
"not removable" as before.
Original discussion can be found in [4] ("[PATCH RFC v1] mm:
is_mem_section_removable() overhaul").
Other users of is_mem_section_removable() will be removed next, so that
we can remove is_mem_section_removable() completely.
Naohiro Aota [Sun, 29 Mar 2020 02:17:15 +0000 (19:17 -0700)]
mm/swapfile.c: move inode_lock out of claim_swapfile
claim_swapfile() currently keeps the inode locked when it is successful,
or the file is already swapfile (with -EBUSY). And, on the other error
cases, it does not lock the inode.
This inconsistency of the lock state and return value is quite confusing
and actually causing a bad unlock balance as below in the "bad_swap"
section of __do_sys_swapon().
This commit fixes this issue by moving the inode_lock() and IS_SWAPFILE
check out of claim_swapfile(). The inode is unlocked in
"bad_swap_unlock_inode" section, so that the inode is ensured to be
unlocked at "bad_swap". Thus, error handling codes after the locking now
jumps to "bad_swap_unlock_inode" instead of "bad_swap".
=====================================
WARNING: bad unlock balance detected!
5.5.0-rc7+ #176 Not tainted
-------------------------------------
swapon/4294 is trying to release lock (&sb->s_type->i_mutex_key) at: __do_sys_swapon+0x94b/0x3550
but there are no more locks to release!
other info that might help us debug this:
no locks held by swapon/4294.
1) Fix memory leak in vti6, from Torsten Hilbrich.
2) Fix double free in xfrm_policy_timer, from YueHaibing.
3) NL80211_ATTR_CHANNEL_WIDTH attribute is put with wrong type, from
Johannes Berg.
4) Wrong allocation failure check in qlcnic driver, from Xu Wang.
5) Get ks8851-ml IO operations right, for real this time, from Marek
Vasut.
* git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (22 commits)
r8169: fix PHY driver check on platforms w/o module softdeps
net: ks8851-ml: Fix IO operations, again
mlxsw: spectrum_mr: Fix list iteration in error path
qlcnic: Fix bad kzalloc null test
mac80211: set IEEE80211_TX_CTRL_PORT_CTRL_PROTO for nl80211 TX
mac80211: mark station unauthorized before key removal
mac80211: Check port authorization in the ieee80211_tx_dequeue() case
cfg80211: Do not warn on same channel at the end of CSA
mac80211: drop data frames without key on encrypted links
ieee80211: fix HE SPR size calculation
nl80211: fix NL80211_ATTR_CHANNEL_WIDTH attribute type
xfrm: policy: Fix doulbe free in xfrm_policy_timer
bpf: Explicitly memset some bpf info structures declared on the stack
bpf: Explicitly memset the bpf_attr structure
bpf: Sanitize the bpf_struct_ops tcp-cc name
vti6: Fix memory leak of skb if input policy check fails
esp: remove the skb from the chain when it's enqueued in cryptd_wq
ipv6: xfrm6_tunnel.c: Use built-in RCU list checking
xfrm: add the missing verify_sec_ctx_len check in xfrm_add_acquire
xfrm: fix uctx len check in verify_sec_ctx_len
...
Linus Torvalds [Sat, 28 Mar 2020 16:14:16 +0000 (09:14 -0700)]
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Two small fixes: one in drivers (qla2xxx), and one in the core (sd) to
try to cope with USB enclosures that silently change reported
parameters"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: sd: Fix optimal I/O size for devices that change reported values
scsi: qla2xxx: Fix I/Os being passed down when FC device is being deleted
The following pull-request contains BPF updates for your *net* tree.
We've added 3 non-merge commits during the last 4 day(s) which contain
a total of 4 files changed, 25 insertions(+), 20 deletions(-).
The main changes are:
1) Explicitly memset the bpf_attr structure on bpf() syscall to avoid
having to rely on compiler to do so. Issues have been noticed on
some compilers with padding and other oddities where the request was
then unexpectedly rejected, from Greg Kroah-Hartman.
2) Sanitize the bpf_struct_ops TCP congestion control name in order to
avoid problematic characters such as whitespaces, from Martin KaFai Lau.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Heiner Kallweit [Fri, 27 Mar 2020 16:33:32 +0000 (17:33 +0100)]
r8169: fix PHY driver check on platforms w/o module softdeps
On Android/x86 the module loading infrastructure can't deal with
softdeps. Therefore the check for presence of the Realtek PHY driver
module fails. mdiobus_register() will try to load the PHY driver
module, therefore move the check to after this call and explicitly
check that a dedicated PHY driver is bound to the PHY device.
Fixes: b21013e58931 ("r8169: check that Realtek PHY driver module is loaded") Reported-by: Chih-Wei Huang <cwhuang@android-x86.org> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
1) Handle NETDEV_UNREGISTER for xfrm device to handle asynchronous
unregister events cleanly. From Raed Salem.
2) Fix vti6 tunnel inter address family TX through bpf_redirect().
From Nicolas Dichtel.
3) Fix lenght check in verify_sec_ctx_len() to avoid a
slab-out-of-bounds. From Xin Long.
4) Add a missing verify_sec_ctx_len check in xfrm_add_acquire
to avoid a possible out-of-bounds to access. From Xin Long.
5) Use built-in RCU list checking of hlist_for_each_entry_rcu
to silence false lockdep warning in __xfrm6_tunnel_spi_lookup
when CONFIG_PROVE_RCU_LIST is enabled. From Madhuparna Bhowmik.
6) Fix a panic on esp offload when crypto is done asynchronously.
From Xin Long.
7) Fix a skb memory leak in an error path of vti6_rcv.
From Torsten Hilbrich.
8) Fix a race that can lead to a doulbe free in xfrm_policy_timer.
From Xin Long.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Linus Torvalds [Fri, 27 Mar 2020 20:52:32 +0000 (13:52 -0700)]
Merge tag 'arm-soc-fixes-5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM DT and driver fixes from Arnd Bergmann:
"For the devicetree files, there are a total of 20 patches, almost
entirely for 32-bit machines:
- The Allwinner/sun9i r40 SoC dtsi file contains a number of issues,
both for correctness and for style that are addressed in separate
patches. This causes most of the changed lines of the DT updates
this time.
- More Allwinner updates fixing the identification of the security
system on sun8i/A33, a recent regression of the A83t ethernet, and
a few board specific issues on the TBS-A711 macine.
- Several bug fixes for OMAP dts files, most notably fixing the
timings for the NAND flash on the Nokia N900 that regressed a while
ago after the move to configuring them from DT. Some other OMAPs
now set the correct dma limits on the L3 bus, and a regression fix
addresses lost Ethernet on dm814x
- One incorrect setting in the newly added Raspberry Pi Zero W that
may cause issues with the SD card controller.
- A missing property on the bcm2835 firmware node caused incorrect
DMA settings.
- An old bug on the oxnas platform causing spurious interrupts is
finally addressed.
- A regression on the Exynos Midas board broke the OLED panel power
supply.
- The i.MX6 phycore SoM specified the wrong voltage for the SoC, this
is now set to the values from the datasheet.
- Some 64-bit machines use a deprecated string to identify the PSCI
firmware.
There are also several small code fixes addressing mostly serious
issues:
- Fix the sunxi rsb bus access to no longer return incorrect data
when mixing 8 and 16 bit I/O.
- Fix a suspend/resume regression on the OMAP2+ lcdc from a missing
quirk in the ti-sysc driver
- Fix a NULL pointer access from a race in the fsl dpio driver
- Fix a v5.5 regression in the exynos-chipid driver that caused an
invalid error code probing the device on non-exynos platforms
- Fix an out-of-bounds access in the AMD TEE driver"
* tag 'arm-soc-fixes-5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (24 commits)
soc: samsung: chipid: Fix return value on non-Exynos platforms
arm64: dts: Fix leftover entry-methods for PSCI
ARM: dts: exynos: Fix regulator node aliasing on Midas-based boards
ARM: dts: oxnas: Fix clear-mask property
ARM: dts: bcm283x: Fix vc4's firmware bus DMA limitations
ARM: dts: omap5: Add bus_dma_limit for L3 bus
ARM: dts: omap4-droid4: Fix lost touchscreen interrupts
ARM: dts: dra7: Add bus_dma_limit for L3 bus
ARM: bcm2835-rpi-zero-w: Add missing pinctrl name
ARM: dts: sun8i: a33: add the new SS compatible
dt-bindings: crypto: add new compatible for A33 SS
ARM: dts: sun8i: r40: Move SPI device nodes based on address order
ARM: dts: sun8i: r40: Fix register base address for SPI2 and SPI3
ARM: dts: sun8i: r40: Move AHCI device node based on address order
ARM: dts: imx6: phycore-som: fix arm and soc minimum voltage
soc: fsl: dpio: register dpio irq handlers after dpio create
tee: amdtee: out of bounds read in find_session()
ARM: dts: N900: fix onenand timings
bus: ti-sysc: Fix quirk flags for lcdc on am335x
ARM: dts: Fix dm814x Ethernet by changing to use rgmii-id mode
...
Linus Torvalds [Fri, 27 Mar 2020 18:06:10 +0000 (11:06 -0700)]
Merge tag 'riscv-for-linus-5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Palmer Dabbelt:
"Sorry for the last minute patches, but a few things fell through the
cracks recently. I was on the fence about sending a late pull request
just for the M-mode fixes, as we don't really have any users, but the
last patch fixes the build for Fedora which I consider pretty
important.
Given that the M-mode fixes should be very low risk, I figured it's
worth sending them along as well.
Thhis passes my standard 'boot in QEMU' test"
* tag 'riscv-for-linus-5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
RISC-V: Move all address space definition macros to one place
RISC-V: Only select essential drivers for SOC_VIRT config
riscv: fix the IPI missing issue in nommu mode
riscv: uaccess should be used in nommu mode
Linus Torvalds [Fri, 27 Mar 2020 16:33:48 +0000 (09:33 -0700)]
Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clk fixes from Stephen Boyd:
"A handful of clk driver fixes.
Mostly they're around the i.MX drivers fixing the parents of a few
clks and making KASAN happy with how the message passing code works.
Besides that we have a TI driver fix for the RTC parent and a fix for
the basic gate type registration functions introduced this release
where they didn't actually pass the arguments in the right places to
the multiplexer function down below"
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
clk: imx: Align imx sc clock parent msg structs to 4
clk: imx: Align imx sc clock msg structs to 4
clk: Pass correct arguments to __clk_hw_register_gate()
clk: ti: am43xx: Fix clock parent for RTC clock
clk: imx8mp: Correct the enet_qos parent clock
clk: imx8mp: Correct IMX8MP_CLK_HDMI_AXI clock parent
Linus Torvalds [Fri, 27 Mar 2020 16:21:52 +0000 (09:21 -0700)]
Merge tag 'drm-fixes-2020-03-27' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"Pretty quiet: some minor sg mapping fixes for 3 drivers, and a single
oops fix for the scheduler. I'm hoping nobody tries to send me a fixes
pull today but I'll keep an eye out of the weekend.
radeon/amdgpu/dma-buf:
- sg list fixes
scheduler:
- oops fix"
* tag 'drm-fixes-2020-03-27' of git://anongit.freedesktop.org/drm/drm:
drm/scheduler: fix rare NULL ptr race
drm/radeon: fix scatter-gather mapping with user pages
drm/amdgpu: fix scatter-gather mapping with user pages
drm/prime: use dma length macro when mapping sg
Dirk Mueller [Tue, 14 Jan 2020 17:53:41 +0000 (18:53 +0100)]
scripts/dtc: Remove redundant YYLOC global declaration
gcc 10 will default to -fno-common, which causes this error at link
time:
(.text+0x0): multiple definition of `yylloc'; dtc-lexer.lex.o (symbol from plugin):(.text+0x0): first defined here
This is because both dtc-lexer as well as dtc-parser define the same
global symbol yyloc. Before with -fcommon those were merged into one
defintion. The proper solution would be to to mark this as "extern",
however that leads to:
dtc-lexer.l:26:16: error: redundant redeclaration of 'yylloc' [-Werror=redundant-decls]
26 | extern YYLTYPE yylloc;
| ^~~~~~
In file included from dtc-lexer.l:24:
dtc-parser.tab.h:127:16: note: previous declaration of 'yylloc' was here
127 | extern YYLTYPE yylloc;
| ^~~~~~
cc1: all warnings being treated as errors
which means the declaration is completely redundant and can just be
dropped.
Signed-off-by: Dirk Mueller <dmueller@suse.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[robh: cherry-pick from upstream] Cc: stable@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
Current mode validation impedes setting up some video modes which should
be supported otherwise. Namely 1920x1200@60Hz.
Fix this by lowering the minimum HDMI state machine clock to pixel clock
ratio allowed.
Fixes: 8b626665f6b4 ("drm/vc4: Reject HDMI modes with too high of clocks.") Reported-by: Stefan Wahren <stefan.wahren@i2se.com> Suggested-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200326122001.22215-1-nsaenzjulienne@suse.de
Marek Vasut [Wed, 25 Mar 2020 14:25:47 +0000 (15:25 +0100)]
net: ks8851-ml: Fix IO operations, again
This patch reverts e6aaf03eebc0 ("net: ks8851-ml: Fix 16-bit IO operation")
and 517742d72c91 ("net: ks8851-ml: Fix 16-bit data access"), because it
turns out these were only necessary due to buggy hardware. This patch adds
a check for such a buggy hardware to prevent any such mistakes again.
While working further on the KS8851 driver, it came to light that the
KS8851-16MLL is capable of switching bus endianness by a hardware strap,
EESK pin. If this strap is incorrect, the IO accesses require such endian
swapping as is being reverted by this patch. Such swapping also impacts
the performance significantly.
Hence, in addition to removing it, detect that the hardware is broken,
report to user, and fail to bind with such hardware.
Fixes: e6aaf03eebc0 ("net: ks8851-ml: Fix 16-bit IO operation") Fixes: 517742d72c91 ("net: ks8851-ml: Fix 16-bit data access") Signed-off-by: Marek Vasut <marex@denx.de> Cc: David S. Miller <davem@davemloft.net> Cc: Lukas Wunner <lukas@wunner.de> Cc: Petr Stetiar <ynezz@true.cz> Cc: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Atish Patra [Thu, 26 Mar 2020 22:55:46 +0000 (15:55 -0700)]
RISC-V: Move all address space definition macros to one place
We get the following compilation error if CONFIG_SPARSEMEM_VMEMMAP is set.
---------------------------------------------------------------
./arch/riscv/include/asm/pgtable-64.h: In function ‘pud_page’:
./include/asm-generic/memory_model.h:54:29: error: ‘vmemmap’ undeclared
(first use in this function); did you mean ‘mem_map’?
#define __pfn_to_page(pfn) (vmemmap + (pfn))
^~~~~~~
./include/asm-generic/memory_model.h:82:21: note: in expansion of
macro ‘__pfn_to_page’
#define pfn_to_page __pfn_to_page
^~~~~~~~~~~~~
./arch/riscv/include/asm/pgtable-64.h:70:9: note: in expansion of macro
‘pfn_to_page’
return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT);
---------------------------------------------------------------
Fix the compliation errors by moving all the address space definition
macros before including pgtable-64.h.
David Howells [Thu, 26 Mar 2020 15:24:07 +0000 (15:24 +0000)]
afs: Fix unpinned address list during probing
When it's probing all of a fileserver's interfaces to find which one is
best to use, afs_do_probe_fileserver() takes a lock on the server record
and notes the pointer to the address list.
It doesn't, however, pin the address list, so as soon as it drops the
lock, there's nothing to stop the address list from being freed under
us.
Fix this by taking a ref on the address list inside the locked section
and dropping it at the end of the function.
Fixes: b6139ef5ddf3 ("afs: Probe multiple fileservers simultaneously") Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Marc Dionne <marc.dionne@auristor.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Thu, 26 Mar 2020 22:44:41 +0000 (15:44 -0700)]
Merge tag 'ceph-for-5.6-rc8' of git://github.com/ceph/ceph-client
Pull ceph fixes from Ilya Dryomov:
"A patch for a rather old regression in fullness handling and two
memory leak fixes, marked for stable"
* tag 'ceph-for-5.6-rc8' of git://github.com/ceph/ceph-client:
ceph: fix memory leak in ceph_cleanup_snapid_map()
libceph: fix alloc_msg_with_page_vector() memory leaks
ceph: check POOL_FLAG_FULL/NEARFULL in addition to OSDMAP_FULL/NEARFULL
Linus Torvalds [Thu, 26 Mar 2020 22:30:49 +0000 (15:30 -0700)]
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull KVM fixes from Paolo Bonzini:
"x86 bug fixes"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: X86: Narrow down the IPI fastpath to single target IPI
KVM: LAPIC: Also cancel preemption timer when disarm LAPIC timer
KVM: VMX: don't allow memory operands for inline asm that modifies SP
KVM: LAPIC: Mark hrtimer for period or oneshot mode to expire in hard interrupt context
KVM: SVM: Issue WBINVD after deactivating an SEV guest
KVM: SVM: document KVM_MEM_ENCRYPT_OP, let userspace detect if SEV is available
KVM: x86: remove bogus user-triggerable WARN_ON
Linus Torvalds [Thu, 26 Mar 2020 22:12:19 +0000 (15:12 -0700)]
MAINTAINERS: fix bad file pattern
Testing 'parse-maintainers' due to the previous commit shows a bad file
pattern for the "TI VPE/CAL DRIVERS" entry in the MAINTAINERS file.
There's also a lot of mis-ordered entries, but I'm still a bit nervous
about the inevitable and annoying merge problems it would probably cause
to fix them up.
The MAINTAINERS file is one of my least favorite files due to being huge
and centralized, but fixing it is also horribly painful for that reason.
Joe Perches [Sun, 8 Mar 2020 02:59:05 +0000 (18:59 -0800)]
parse-maintainers: Do not sort section content by default
Add an --order switch to control section reordering.
Default for --order is off.
Change the default ordering to a slightly more sensible:
M: Person acting as a maintainer
R: Person acting as a patch reviewer
L: Mailing list where patches should be sent
S: Maintenance status
W: URI for general information
Q: URI for patchwork tracking
B: URI for bug tracking/submission
C: URI for chat
P: URI or file for subsystem specific coding styles
T: SCM tree type and location
F: File and directory pattern
X: File and directory exclusion pattern
N: File glob
K: Keyword - patch content regex
Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dmitry Torokhov [Thu, 26 Mar 2020 19:54:02 +0000 (12:54 -0700)]
Input: move the new KEY_SELECTIVE_SCREENSHOT keycode
We should try to keep keycodes sequential unless there is a reason to leave
a gap in numbering, so let's move it from 0x280 to 0x27a while we still
can.
Fixes: 60e02c9cdbe9 ("Input: allocate keycode for Selective Screenshot key") Acked-by: Rajat Jain <rajatja@google.com> Link: https://lore.kernel.org/r/20200326182711.GA259753@dtor-ws Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
David S. Miller [Thu, 26 Mar 2020 19:03:02 +0000 (12:03 -0700)]
Merge tag 'mac80211-for-net-2020-03-26' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg says:
====================
We have the following fixes:
* drop data packets if there's no key for them anymore, after
there had been one, to avoid sending them in clear when
hostapd removes the key before it removes the station and
the packets are still queued
* check port authorization again after dequeue, to avoid
sending packets if the station is no longer authorized
* actually remove the authorization flag before the key so
packets are also dropped properly because of this
* fix nl80211 control port packet tagging to handle them as
packets allowed to go out without encryption
* fix NL80211_ATTR_CHANNEL_WIDTH outgoing netlink attribute
width (should be 32 bits, not 8)
* don't WARN in a CSA scenario that happens on some APs
* fix HE spatial reuse element size calculation
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Thu, 26 Mar 2020 14:17:33 +0000 (16:17 +0200)]
mlxsw: spectrum_mr: Fix list iteration in error path
list_for_each_entry_from_reverse() iterates backwards over the list from
the current position, but in the error path we should start from the
previous position.
Fix this by using list_for_each_entry_continue_reverse() instead.
This suppresses the following error from coccinelle:
drivers/net/ethernet/mellanox/mlxsw//spectrum_mr.c:655:34-38: ERROR:
invalid reference to the index variable of the iterator on line 636
Fixes: f9fc91e83986 ("mlxsw: spectrum: Add the multicast routing offloading logic") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Linus Torvalds [Thu, 26 Mar 2020 17:39:36 +0000 (10:39 -0700)]
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
Pull rdma fixes from Jason Gunthorpe:
"A small set of late-rc patches, mostly fixes for various crashers,
some syzkaller fixes and a mlx5 HW limitation:
- Several MAINTAINERS updates
- Memory leak regression in ODP
- Several fixes for syzkaller related crashes. Google recently taught
syzkaller to create the software RDMA devices
- Crash fixes for HFI1
- Several fixes for mlx5 crashes
- Prevent unprivileged access to an unsafe mlx5 HW resource"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
RDMA/mlx5: Block delay drop to unprivileged users
RDMA/mlx5: Fix access to wrong pointer while performing flush due to error
RDMA/core: Ensure security pkey modify is not lost
MAINTAINERS: Clean RXE section and add Zhu as RXE maintainer
IB/hfi1: Ensure pq is not left on waitlist
IB/rdmavt: Free kernel completion queue when done
RDMA/mad: Do not crash if the rdma device does not have a umad interface
RDMA/core: Fix missing error check on dev_set_name()
RDMA/nl: Do not permit empty devices names during RDMA_NLDEV_CMD_NEWLINK/SET
RDMA/mlx5: Fix the number of hwcounters of a dynamic counter
MAINTAINERS: Update maintainers for HISILICON ROCE DRIVER
RDMA/odp: Fix leaking the tgid for implicit ODP
Uma Shankar [Thu, 26 Mar 2020 12:51:11 +0000 (18:21 +0530)]
drm/i915/display: Fix mode private_flags comparison at atomic_check
This patch fixes the private_flags of mode to be checked and
compared against uapi.mode and not from hw.mode. This helps
properly trigger modeset at boot if desired by driver.
It helps resolve audio_codec initialization issues if display
is connected at boot. Initial discussion on this issue has happened
on below thread:
https://patchwork.freedesktop.org/series/74828/
v2: No functional change. Fixed the Closes tag and added
Maarten's RB.
v3: Added Fixes tag.
Cc: Ville Syrjä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Souza, Jose <jose.souza@intel.com> Fixes: 62e79d0b6e93 ("drm/i915: Complete crtc hw/uapi split, v6.") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1363 Suggested-by: Ville Syrjä <ville.syrjala@linux.intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: SweeAun Khor <swee.aun.khor@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200326125111.11081-1-uma.shankar@intel.com
(cherry picked from commit d5e56705927e00f703b2eb5a98299dd6622d16e5) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Chris Wilson [Wed, 25 Mar 2020 13:00:59 +0000 (13:00 +0000)]
drm/i915/gt: Stage the transfer of the virtual breadcrumb
We move the virtual breadcrumb from one physical engine to the next, if
the next virtual request is scheduled on a new physical engine. Since
the virtual context can only be in one signal queue, we need it to track
the current physical engine for the new breadcrumbs. However, to move
the list we need both breadcrumb locks -- and since we cannot take both
at the same time (unless we are careful and always ensure consistent
ordering) stage the movement of the signaler via the current virtual
request.
Chris Wilson [Tue, 24 Mar 2020 13:42:32 +0000 (13:42 +0000)]
drm/i915/gt: Select the deepest available parking mode for rc6
On Ivybridge, we can go lower than rc6 to rc6p. And this is required for
Ivybridge to hit the same minimum power consumption as rc6 on other
platforms, so make it so.
v2: Update selftest to include all rc6 residency counters
Note that Andi did mention that we should be converting the magic
numbers into opaque magic macros, so if they ever get reused (unlikely
given only Ivybridge used the extra modes) we'll need to pay back the
technical debt.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1518 Fixes: 20ff1deabb8c ("drm/i915/gt: Manual rc6 entry upon parking")
Testcase: igt/i915_pm_rc6_residency/rc6-idle Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200324134232.8773-1-chris@chris-wilson.co.uk
(cherry picked from commit 13c5a577b342d80ea06b7300ce69420a2d0928ca) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Chris Wilson [Mon, 23 Mar 2020 09:28:35 +0000 (09:28 +0000)]
drm/i915: Avoid live-lock with i915_vma_parked()
Abuse^W Take advantage that we know we are inside the GT wakeref and
that prevents any client execbuf from reopening the i915_vma in order to
claim all the vma to close without having to drop the spinlock to free
each one individually. By keeping the spinlock, we do not have to
restart if we run concurrently with i915_gem_free_objects -- which
causes them both to restart continually and make very very slow
progress.
Chris Wilson [Sun, 22 Mar 2020 16:32:24 +0000 (16:32 +0000)]
drm/i915/gt: Treat idling as a RPS downclock event
If we park/unpark faster than we can respond to RPS events, we never
will process a downclock event after expiring a waitboost, and thus we
will forever restart the GPU at max clocks even if the workload switches
and doesn't justify full power.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1500 Fixes: 60057c8cc5ff ("drm/i915: Extract GT render power state management") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Cc: Lyude Paul <lyude@redhat.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200322163225.28791-1-chris@chris-wilson.co.uk Cc: <stable@vger.kernel.org> # v5.5+
(cherry picked from commit 21abf0bf168dffff1192e0f072af1dc74ae1ff0e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The vboxvideo driver is missing a call to remove conflicting framebuffers.
Surprisingly, when using legacy BIOS booting this does not really cause
any issues. But when using UEFI to boot the VM then plymouth will draw
on both the efifb /dev/fb0 and /dev/drm/card0 (which has registered
/dev/fb1 as fbdev emulation).
VirtualBox will actual display the output of both devices (I guess it is
showing whatever was drawn last), this causes weird artifacts because of
pitch issues in the efifb when the VM window is not sized at 1024x768
(the window will resize to its last size once the vboxvideo driver loads,
changing the pitch).
Adding the missing drm_fb_helper_remove_conflicting_pci_framebuffers()
call fixes this.
Changes in v2:
-Make the drm_fb_helper_remove_conflicting_pci_framebuffers() call one of
the first things we do in our probe() method
Johannes Berg [Thu, 26 Mar 2020 14:53:34 +0000 (15:53 +0100)]
mac80211: set IEEE80211_TX_CTRL_PORT_CTRL_PROTO for nl80211 TX
When a frame is transmitted via the nl80211 TX rather than as a
normal frame, IEEE80211_TX_CTRL_PORT_CTRL_PROTO wasn't set and
this will lead to wrong decisions (rate control etc.) being made
about the frame; fix this.
Johannes Berg [Thu, 26 Mar 2020 14:51:35 +0000 (15:51 +0100)]
mac80211: mark station unauthorized before key removal
If a station is still marked as authorized, mark it as no longer
so before removing its keys. This allows frames transmitted to it
to be rejected, providing additional protection against leaking
plain text data during the disconnection flow.
Jouni Malinen [Thu, 26 Mar 2020 14:51:34 +0000 (15:51 +0100)]
mac80211: Check port authorization in the ieee80211_tx_dequeue() case
mac80211 used to check port authorization in the Data frame enqueue case
when going through start_xmit(). However, that authorization status may
change while the frame is waiting in a queue. Add a similar check in the
dequeue case to avoid sending previously accepted frames after
authorization change. This provides additional protection against
potential leaking of frames after a station has been disconnected and
the keys for it are being removed.
Ilan Peer [Thu, 26 Mar 2020 13:09:43 +0000 (15:09 +0200)]
cfg80211: Do not warn on same channel at the end of CSA
When cfg80211_update_assoc_bss_entry() is called, there is a
verification that the BSS channel actually changed. As some APs use
CSA also for bandwidth changes, this would result with a kernel
warning.
Johannes Berg [Thu, 26 Mar 2020 13:09:42 +0000 (15:09 +0200)]
mac80211: drop data frames without key on encrypted links
If we know that we have an encrypted link (based on having had
a key configured for TX in the past) then drop all data frames
in the key selection handler if there's no key anymore.
This fixes an issue with mac80211 internal TXQs - there we can
buffer frames for an encrypted link, but then if the key is no
longer there when they're dequeued, the frames are sent without
encryption. This happens if a station is disconnected while the
frames are still on the TXQ.
Detecting that a link should be encrypted based on a first key
having been configured for TX is fine as there are no use cases
for a connection going from with encryption to no encryption.
With extended key IDs, however, there is a case of having a key
configured for only decryption, so we can't just trigger this
behaviour on a key being configured.
Yintian Tao [Mon, 23 Mar 2020 11:19:37 +0000 (19:19 +0800)]
drm/scheduler: fix rare NULL ptr race
There is one one corner case at dma_fence_signal_locked
which will raise the NULL pointer problem just like below.
->dma_fence_signal
->dma_fence_signal_locked
->test_and_set_bit
here trigger dma_fence_release happen due to the zero of fence refcount.
->dma_fence_put
->dma_fence_release
->drm_sched_fence_release_scheduled
->call_rcu
here make the union fled “cb_list” at finished fence
to NULL because struct rcu_head contains two pointer
which is same as struct list_head cb_list
Therefore, to hold the reference of finished fence at drm_sched_process_job
to prevent the null pointer during finished fence dma_fence_signal
v2: hold the finished fence at drm_sched_process_job instead of
amdgpu_fence_process
v3: resume the blank line
Signed-off-by: Yintian Tao <yttao@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Wanpeng Li [Thu, 26 Mar 2020 02:20:01 +0000 (10:20 +0800)]
KVM: X86: Narrow down the IPI fastpath to single target IPI
The original single target IPI fastpath patch forgot to filter the
ICR destination shorthand field. Multicast IPI is not suitable for
this feature since wakeup the multiple sleeping vCPUs will extend
the interrupt disabled time, it especially worse in the over-subscribe
and VM has a little bit more vCPUs scenario. Let's narrow it down to
single target IPI.
Two VMs, each is 76 vCPUs, one running 'ebizzy -M', the other
running cyclictest on all vCPUs, w/ this patch, the avg score
of cyclictest can improve more than 5%. (pv tlb, pv ipi, pv
sched yield are disabled during testing to avoid the disturb).
Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
Message-Id: <1585189202-1708-3-git-send-email-wanpengli@tencent.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Stephen Boyd [Wed, 25 Mar 2020 02:22:57 +0000 (19:22 -0700)]
clk: Pass correct arguments to __clk_hw_register_gate()
I copy/pasted these macros and forgot to update the argument
names and where they're passed to. Fix it so that these macros make
sense.
Reported-by: Maxime Ripard <maxime@cerno.tech> Fixes: ab47db938adc ("clk: gate: Add support for specifying parents via DT/pointers") Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lkml.kernel.org/r/20200325022257.148244-1-sboyd@kernel.org Tested-by: Maxime Ripard <mripard@kernel.org>
Monk Liu [Wed, 4 Mar 2020 07:21:22 +0000 (15:21 +0800)]
drm/amdgpu: don't try to reserve training bo for sriov (v2)
1) SRIOV guest KMD doesn't care training buffer
2) if we resered training buffer that will overlap with IP discovery
reservation because training buffer is at vram_size - 0x8000 and
IP discovery is at ()vram_size - 0x10000 => vram_size -1)
v2: squash in warning fix from Nirmoy
Signed-off-by: Monk Liu <Monk.Liu@amd.com> Reviewed-by: Emily Deng <Emily.Deng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Fri, 20 Mar 2020 17:45:59 +0000 (13:45 -0400)]
drm/amdgpu/smu11: add support for SMU AC/DC interrupts
Driver needs to send the ack message when it receives the
AC/DC interrupt from the SMU.
TODO: verify the client and src ids.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
For boards that do not support automatic AC/DC transitions
in firmware, manually tell the firmware when the status
changes.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Fri, 20 Mar 2020 16:37:23 +0000 (12:37 -0400)]
drm/amdgpu/swSMU: handle DC controlled by GPIO for navi1x
Check the platform caps in the vbios pptable to decide
whether to enable automatic AC/DC transitions.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Fri, 20 Mar 2020 16:45:09 +0000 (12:45 -0400)]
drm/amdgpu/swSMU: set AC/DC mode based on the current system state (v2)
Check of the pointer exists and we are actually on AC power.
v2: fix error message to reflect AC/DC mode.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Evan Quan [Fri, 20 Mar 2020 18:09:21 +0000 (14:09 -0400)]
drm/amdgpu/swSMU: correct the bootup power source for Navi1X (v2)
PMFW may boots those ASICs with DC mode. Need to set it back
to AC mode.
v2: split from Evan's original patch (Alex)
Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Fri, 20 Mar 2020 18:07:08 +0000 (14:07 -0400)]
drm/amdgpu/swSMU: use the smu11 power source helper for navi1x
The smu_v11_0 version works for navi1x.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Fri, 20 Mar 2020 17:42:26 +0000 (13:42 -0400)]
drm/amdgpu/smu11: add a helper to set the power source
Add a common smu11 helper to set the AC/DC power source.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Evan Quan [Fri, 20 Mar 2020 18:03:25 +0000 (14:03 -0400)]
drm/amd/swSMU: add callback to set AC/DC power source (v2)
This is needed to tell the SMU firmware what state is in
in certain cases. DC mode does not allow overclocking
for example.
v2: split Evan's original patch (Alex)
Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Yintian Tao [Mon, 23 Mar 2020 11:19:37 +0000 (19:19 +0800)]
drm/scheduler: fix rare NULL ptr race
There is one one corner case at dma_fence_signal_locked
which will raise the NULL pointer problem just like below.
->dma_fence_signal
->dma_fence_signal_locked
->test_and_set_bit
here trigger dma_fence_release happen due to the zero of fence refcount.
->dma_fence_put
->dma_fence_release
->drm_sched_fence_release_scheduled
->call_rcu
here make the union fled “cb_list” at finished fence
to NULL because struct rcu_head contains two pointer
which is same as struct list_head cb_list
Therefore, to hold the reference of finished fence at drm_sched_process_job
to prevent the null pointer during finished fence dma_fence_signal
v2: hold the finished fence at drm_sched_process_job instead of
amdgpu_fence_process
v3: resume the blank line
Signed-off-by: Yintian Tao <yttao@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dennis Li [Mon, 23 Mar 2020 05:02:39 +0000 (13:02 +0800)]
drm/amdgpu: fix the coverage issue to clear ArcVPGRs
Set ComputePGMRSRC1.VGPRS as 0x3f to clear all ArcVGPRs.
Signed-off-by: Dennis Li <Dennis.Li@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Mario Kleiner [Mon, 2 Mar 2020 06:17:32 +0000 (07:17 +0100)]
drm/amd/display: Fix pageflip event race condition for DCN.
Commit '833776a3d0ce ("drm/amd/display: Send vblank and user
events at vsartup for DCN")' introduces a new way of pageflip
completion handling for DCN, and some trouble.
The current implementation introduces a race condition, which
can cause pageflip completion events to be sent out one vblank
too early, thereby confusing userspace and causing flicker:
--> Deadline for surface address regs double-buffering passes on
target pipe.
4. dc_commit_updates_for_stream() MMIO programs the new pageflip
into hw, but too late for current vblank.
=> pflip_status == AMDGPU_FLIP_SUBMITTED, but flip won't complete
in current vblank due to missing the double-buffering deadline
by a tiny bit.
5. VSTARTUP trigger point in vblank is reached, VSTARTUP irq fires,
dm_dcn_crtc_high_irq() gets called.
6. Detects pflip_status == AMDGPU_FLIP_SUBMITTED and assumes the
pageflip has been completed/will complete in this vblank and
sends out pageflip completion event to userspace and resets
pflip_status = AMDGPU_FLIP_NONE.
=> Flip completion event sent out one vblank too early.
This behaviour has been observed during my testing with measurement
hardware a couple of time.
The commit message says that the extra flip event code was added to
dm_dcn_crtc_high_irq() to prevent missing to send out pageflip events
in case the pflip irq doesn't fire, because the "DCH HUBP" component
is clock gated and doesn't fire pflip irqs in that state. Also that
this clock gating may happen if no planes are active. This suggests
that the problem addressed by that commit can't happen if planes
are active.
The proposed solution is therefore to only execute the extra pflip
completion code iff the count of active planes is zero and otherwise
leave pflip completion handling to the pflip irq handler, for a
more race-free experience.
Note that i don't know if this fixes the problem the original commit
tried to address, as i don't know what the test scenario was. It
does fix the observed too early pageflip events though and points
out the problem introduced.
Fixes: 833776a3d0ce ("drm/amd/display: Send vblank and user events at vsartup for DCN") Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
projects / kernel.git / log