and also fix memory leak to iommu mapping object, which was
detected by kmemleak detector.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJeZx9gAAoJEFc4NIkMQxK4XrcP/0kjKf+TKEAafd00Nn61FZZ9
GMRBAJL+OJreXINMIbMlolSZ2PDOrxvS/5N5LfF5d5coQjoYisRp8JoJQvP1FcYb
wcU8bdoFFWbC+wrH/qqI+TOgzP2VRR6JBe6HD8wgIHoZJLtF/wZHMLs49QUBQ7XY
YbPtkOR2Nv/QnNDb2Vovnlz8CSZbkcIFVJrxhp0X0pzRbyp/2SGQO6vkPJOUOmOE
P5GQYxnKHWP5gO3BcOshyL3PoEuP4369XKRVkdsyU2njn7lHaZ2GhAu4LA6FE1BC
WcJcHfgplaAoxLQCJWGTOu4IwLl95STKFLa0Vn9FmgCF5qfQBw1+tKW6b90bBlhK
QJsNmALqiZc+HAl0f6nHIpvk5uQA1vrfm2SGJtoXNHU/d95Hxi/kZa59N+8z9IYD
3SNZXA6jiE26IEXaBjnuSAXzWrpclsRWEDxIhVh7Vb2PZwD0wXhYU8p6m2VDgWOa
PKSxVISQUgk/i5lblaNs03ODpvmPzQy0mwmj/tS7cXDBFtMeCD9EEp+GIVOPS6RN
VWtkmt7sNI8cQvA1YDvh5mnOdabTZFB4vRN27S47JrjF+YCGhe34fo39h1D1j4yO
dP3eTd8hf3F5oAYxIL9a92ciW0Z5ch7qcZHY2j5JGAQw6Jv3dGaCXo5lVdZLQ2TO
GFcnThfb0sQE/ruN8CLa
=ymVK
-----END PGP SIGNATURE-----
Merge tag 'exynos-drm-fixes-for-v5.6-rc5-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes
Fix IOMMU initialization failure when Exynos DRM driver is rebound,
and also fix memory leak to iommu mapping object, which was
detected by kmemleak detector.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Inki Dae <inki.dae@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1583887109-4148-1-git-send-email-inki.dae@samsung.com
If the cacheline may still be busy, atomically mark it for future
release, and only if we can determine that it will never be used again,
immediately free it.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1392
Fixes: ebece75392 ("drm/i915: Keep timeline HWSP allocated until idle across the system")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v5.2+
Link: https://patchwork.freedesktop.org/patch/msgid/20200306154647.3528345-1-chris@chris-wilson.co.uk
(cherry picked from commit 2d4bd971f5)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
If we stop filling the ELSP due to an incompatible virtual engine
request, check if we should enable the timeslice on behalf of the queue.
This fixes the case where we are inspecting the last->next element when
we know that the last element is the last request in the execution queue,
and so decided we did not need to enable timeslicing despite the intent
to do so!
Fixes: 8ee36e048c ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: <stable@vger.kernel.org> # v5.4+
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306113012.3184606-1-chris@chris-wilson.co.uk
(cherry picked from commit 3df2deed41)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The alignment is u64, and yet is_power_of_2() assumes unsigned long,
which might give different results between 32b and 64b kernel.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305203534.210466-1-matthew.auld@intel.com
Cc: stable@vger.kernel.org
(cherry picked from commit 2920516b2f)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Commit c3b5a8430d ("drm/i915/gvt: Enable gfx virtualiztion for CFL")
added the support on CFL. The vgpu emulation hotplug support on CFL was
supposed to be included in that patch. Without the vgpu emulation
hotplug support, the dma-buf based display gives us a blur face.
So fix this issue by adding the vgpu emulation hotplug support on CFL.
Fixes: c3b5a8430d ("drm/i915/gvt: Enable gfx virtualiztion for CFL")
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200227010041.32248-1-tina.zhang@intel.com
(cherry picked from commit 135dde8853)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Requests within a timeline are ordered by that timeline, so awaiting for
the start of a request within the timeline is a no-op. This used to work
by falling out of the mutex_trylock() as the signaler and waiter had the
same timeline and not returning an error.
Fixes: 6a79d84840 ("drm/i915: Lock signaler timeline while navigating")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: <stable@vger.kernel.org> # v5.5+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305134822.2750496-1-chris@chris-wilson.co.uk
(cherry picked from commit ab7a69020f)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Fix the inverted test to emit the wait on the end of the previous
request if we /haven't/ already.
Fixes: 6a79d84840 ("drm/i915: Lock signaler timeline while navigating")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: <stable@vger.kernel.org> # v5.5+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305104210.2619967-1-chris@chris-wilson.co.uk
(cherry picked from commit 07e9c59d63)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Clang warns:
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c:2860:9: warning:
converting the result of '?:' with integer constants to a boolean always
evaluates to 'true' [-Wtautological-constant-compare]
return DPAA_FD_DATA_ALIGNMENT ? ALIGN(headroom,
^
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c:131:34: note: expanded
from macro 'DPAA_FD_DATA_ALIGNMENT'
\#define DPAA_FD_DATA_ALIGNMENT (fman_has_errata_a050385() ? 64 : 16)
^
1 warning generated.
This was exposed by commit 3c68b8fffb ("dpaa_eth: FMan erratum A050385
workaround") even though it appears to have been an issue since the
introductory commit 9ad1a37493 ("dpaa_eth: add support for DPAA
Ethernet") since DPAA_FD_DATA_ALIGNMENT has never been able to be zero.
Just replace the whole boolean expression with the true branch, as it is
always been true.
Link: https://github.com/ClangBuiltLinux/linux/issues/928
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix a bug where if userspace is writing to encrypted files while the
FS_IOC_REMOVE_ENCRYPTION_KEY ioctl (introduced in v5.4) is running,
dirty inodes could be evicted, causing writes could be lost or the
filesystem to hang due to a use-after-free. This was encountered during
real-world use, not just theoretical.
Tested with the existing fscrypt xfstests, and with a new xfstest I
wrote to reproduce this bug. This fix does expose an existing bug with
'-o lazytime' that Ted is working on fixing, but this fix is more
critical and needed anyway regardless of the lazytime fix.
-----BEGIN PGP SIGNATURE-----
iIoEABYIADIWIQSacvsUNc7UX4ntmEPzXCl4vpKOKwUCXmk8HxQcZWJpZ2dlcnNA
Z29vZ2xlLmNvbQAKCRDzXCl4vpKOK4YiAQC1RZyH4/mZ890Or6s8SzCgJTVmiLk9
ZTO/56XmLte6LAD+IBAExqDkkybmAF0rQ4kY1oL75f/e/nEs+50TXra9NQc=
=s2KD
-----END PGP SIGNATURE-----
Merge tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt
Pull fscrypt fix from Eric Biggers:
"Fix a bug where if userspace is writing to encrypted files while the
FS_IOC_REMOVE_ENCRYPTION_KEY ioctl (introduced in v5.4) is running,
dirty inodes could be evicted, causing writes could be lost or the
filesystem to hang due to a use-after-free. This was encountered
during real-world use, not just theoretical.
Tested with the existing fscrypt xfstests, and with a new xfstest I
wrote to reproduce this bug. This fix does expose an existing bug with
'-o lazytime' that Ted is working on fixing, but this fix is more
critical and needed anyway regardless of the lazytime fix"
* tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt:
fscrypt: don't evict dirty inodes after removing key
* three netlink validation fixes
* a mesh path selection fix
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEH1e1rEeCd0AIMq6MB8qZga/fl8QFAl5oproACgkQB8qZga/f
l8Qt8g/9Hn+zR5gyMEKMtk3jAb/0Qy/kfNtKY54Kd40T2GGLpTTqAYI22JO+1ypP
8tFPPLp66AgFOdgLDHqOBjf26PfsBIfF08ImePYbh9Jqfl0X/VekrcrvWYkSOOUp
Mt7xUX6snrGvYWAJ6MuN0/XaJg+qfNRFOlcyfOFQD6lt9I9JjGs0r0t3CGm40A8P
ncyXkmkUHtb7imQjYIkd4zfENyMQ25Q1nmLiU/pHwnVXPXoQ3SrbR82Pqo+AiSAG
CpH7TMGr6c3UPUPYU6nGh2ueeVpkNgRr4S6dNILGA15eJn0DOpmgrZ16MtNPYmjL
FDt+Qq/knBYhw9KkLuuF8krQ3hgeI1m7ZI6PBomLoy+Nu18AMwhDJOQ/pLxJSZl/
2774+Ed89UbWyZkPJ8ETExnDGI179eBlpo4mZLU6M5URwY000tbDOLEyS8YDKKlX
3uLVuHxVhjq5BX+s0H5carKoyrw9mXRr/vFgZWxFzYrxJo0U2Staw7hw8hVqgbxr
owRhjYpUxOlIiSVSJS9usFXIT+RyFORo1a5jYjDeMBbMJ/3ViR2dS+HefjjnjycL
B9hNw8ear7654P836I/Tf6sufRwMqNGB8ooj0gttOZO2RrfM0x1YCNPyKDgDgJlR
bQxMmxudt0XhqFlQgoNYsDSMNcl7SYg+KSrOqc2t9LcEj9s8IJk=
=BEkA
-----END PGP SIGNATURE-----
Merge tag 'mac80211-for-net-2020-03-11' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg says:
====================
A couple of fixes:
* three netlink validation fixes
* a mesh path selection fix
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCXmebNQAKCRCRxhvAZXjc
ohidAP4y7sujHKMe87Qd6RFQ+aPTB1cGVgBSyMV5DuvbTW0R9QEA/bWSUtye5+Ln
WRDkXapGM2l36s02xspgokaAhYiFoAE=
=a6eO
-----END PGP SIGNATURE-----
Merge tag 'for-linus-2020-03-10' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux
Pull thread fix from Christian Brauner:
"This contains a single fix for a regression which was introduced when
we introduced the ability to select a specific pid at process creation
time.
When this feature is requested, the error value will be set to -EPERM
after exiting the pid allocation loop. This caused EPERM to be
returned when e.g. the init process/child subreaper of the pid
namespace has already died where we used to return ENOMEM before.
The first patch here simply fixes the regression by unconditionally
setting the return value back to ENOMEM again once we've successfully
allocated the requested pid number. This should be easy to backport to
v5.5.
The second patch adds a comment explaining that we must keep returning
ENOMEM since we've been doing it for a long time and have explicitly
documented this behavior for userspace. This seemed worthwhile because
we now have at least two separate example where people tried to change
the return value to something other than ENOMEM (The first version of
the regression fix did that too and the commit message links to an
earlier patch that tried to do the same.).
I have a simple regression test to make sure we catch this regression
in the future but since that introduces a whole new selftest subdir
and test files I'll keep this for v5.7"
* tag 'for-linus-2020-03-10' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
pid: make ENOMEM return value more obvious
pid: Fix error return value in some cases
can break live patching.
-----BEGIN PGP SIGNATURE-----
iIoEABYIADIWIQRRSw7ePDh/lE+zeZMp5XQQmuv6qgUCXmj5ExQccm9zdGVkdEBn
b29kbWlzLm9yZwAKCRAp5XQQmuv6quQGAQDO35RBAQDGmpxnSCQPNwrzqokM8p8d
1e1xshwOVnwqgAEA7csC4u1n5Z8ncIl5Pd8ygt4nXeqw4AenHLeZIdhfegc=
=+AeW
-----END PGP SIGNATURE-----
Merge tag 'trace-v5.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull ftrace fix from Steven Rostedt:
"Have ftrace lookup_rec() return a consistent record otherwise it can
break live patching"
* tag 'trace-v5.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
ftrace: Return the first found result in lookup_rec()
- Fix some inverted pins in the Meson GLX driver.
- Align the i.MX SC message structs causing warnings from
KASan.
- Balance the kref in pinctrl hogs so they are actually free:d
when removing a pin control module. We haven't seen it before
as people don't use modules for pin control that much, I
think.
- Add a missing call to pinctrl_unregister_mappings() another
memory leak when using modules.
- Fix the fwspec parsing in the Qualcomm driver.
- Fix a syntax error in the Falcon driver.
- Assign .irq_eoi conditionally in the Qualcomm driver, fixing
a bug affecting elder Qualcomm platforms.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAl5orH8ACgkQQRCzN7AZ
XXOIwA/+P8i/v3kTrw7HwAvVwWkVLCCEAz6qUYd/msoFHupGQUoXimR3I6btUQP6
b946kJwFQqsryFbY9HvEOXpwr6oyknKxomj8SsYbg/lGnAVAy84CRnt+P/l5sGQ0
LokjisC9V/FcLcIkiPWwLMBASqVEVM8JQnWWtXDn8EuVnZy2ibEMXBy3mhVOLvMV
irBM0M1FxYrLaZxYJaZwWL+nLiX3UHkqeoHJEiWjQTp8sx71ScAE5st0+4meVCaS
7sCHMt8Zh5LqmMOYhOWxQMKuHjhEvEiXooItB2eWh7LREkPt0Xn5KfjAK0weNnqR
vJCcQukoQJoR5KWnW6lQNDqX6eU5OQO0Bl53RZna1wIKNt5Uu319lXDVr8AcYN5n
4SIl21QBujTA5A/Jbqh6szq1dp0NbR+aWXqRA5Yu+cl+5TLUQ25zCra/sqEAIJE1
lhXl2435fKP32rDKLj8jMsNQ1Gtf5IJH/28MaKu5eTeyb0maqmD/i7C350MH1ss7
QFZtw6Loeph3LHvn+F1eZeCnEyrLDq4mulSM1fiFrfWzOTndAoyiJTcvsy6Lmrtg
KiP6+qug8bIrDl/XNuRly0NhGNMn7dHBXGdaWiBiGlpoE5kguiQ/i8DCXsdwpKrH
fRNogzOq7Wu6+EeRAmLG7+8fyeIMW1JCJ1Rrn0I8ne7FtAIx+RU=
=QXHl
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v5.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Some pin control fixes for the v5.6 series.
It comes down to memory leaks in the core and driver fixes. Some
should have been sent earlier but they kept piling up and the world is
just so full of distractions these days.
- Fix some inverted pins in the Meson GLX driver.
- Align the i.MX SC message structs causing warnings from KASan.
- Balance the kref in pinctrl hogs so they are actually free:d when
removing a pin control module. We haven't seen it before as people
don't use modules for pin control that much, I think.
- Add a missing call to pinctrl_unregister_mappings() another memory
leak when using modules.
- Fix the fwspec parsing in the Qualcomm driver.
- Fix a syntax error in the Falcon driver.
- Assign .irq_eoi conditionally in the Qualcomm driver, fixing a bug
affecting elder Qualcomm platforms"
* tag 'pinctrl-v5.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: qcom: Assign irq_eoi conditionally
pinctrl: falcon: fix syntax error
pinctrl: qcom: ssbi-gpio: Fix fwspec parsing bug
pinctrl: madera: Add missing call to pinctrl_unregister_mappings
pinctrl: core: Remove extra kref_get which blocks hogs being freed
pinctrl: imx: scu: Align imx sc msg structs to 4
pinctrl: meson-gxl: fix GPIOX sdio pins
This does three inter-related things to clarify the usage of the
platform device dma_mask field. In the process, fix the bug introduced
by cdfee56232 ("driver core: initialize a default DMA mask for
platform device") that caused Artem Tashkinov's laptop to not boot with
newer Fedora kernels.
This does:
- First off, rename the field to "platform_dma_mask" to make it
greppable.
We have way too many different random fields called "dma_mask" in
various data structures, where some of them are actual masks, and
some of them are just pointers to the mask. And the structures all
have pointers to each other, or embed each other inside themselves,
and "pdev" sometimes means "platform device" and sometimes it means
"PCI device".
So to make it clear in the code when you actually use this new field,
give it a unique name (it really should be something even more unique
like "platform_device_dma_mask", since it's per platform device, not
per platform, but that gets old really fast, and this is unique
enough in context).
To further clarify when the field gets used, initialize it when we
actually start using it with the default value.
- Then, use this field instead of the random one-off allocation in
platform_device_register_full() that is now unnecessary since we now
already have a perfectly fine allocation for it in the platform
device structure.
- The above then allows us to fix the actual bug, where the error path
of platform_device_register_full() would unconditionally free the
platform device DMA allocation with 'kfree()'.
That kfree() was dont regardless of whether the allocation had been
done earlier with the (now removed) kmalloc, or whether
setup_pdev_dma_masks() had already been used and the dma_mask pointer
pointed to the mask that was part of the platform device.
It seems most people never triggered the error path, or only triggered
it from a call chain that set an explicit pdevinfo->dma_mask value (and
thus caused the unnecessary allocation that was "cleaned up" in the
error path) before calling platform_device_register_full().
Robin Murphy points out that in Artem's case the wdat_wdt driver failed
in platform_device_add(), and that was the one that had called
platform_device_register_full() with pdevinfo.dma_mask = 0, and would
have caused that kfree() of pdev.dma_mask corrupting the heap.
A later unrelated kmalloc() then oopsed due to the heap corruption.
Fixes: cdfee56232 ("driver core: initialize a default DMA mask for platform device")
Reported-bisected-and-tested-by: Artem S. Tashkinov <aros@gmx.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It appears that ip ranges can overlap so. In that case lookup_rec()
returns whatever results it got last even if it found nothing in last
searched page.
This breaks an obscure livepatch late module patching usecase:
- load livepatch
- load the patched module
- unload livepatch
- try to load livepatch again
To fix this return from lookup_rec() as soon as it found the record
containing searched-for ip. This used to be this way prior lookup_rec()
introduction.
Link: http://lkml.kernel.org/r/20200306174317.21699-1-asavkov@redhat.com
Cc: stable@vger.kernel.org
Fixes: 7e16f581a8 ("ftrace: Separate out functionality from ftrace_location_range()")
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
The bucket->lock is not needed in the sock_hash_free and sock_map_free
calls, in fact it is causing a splat due to being inside rcu block.
| BUG: sleeping function called from invalid context at net/core/sock.c:2935
| in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 62, name: kworker/0:1
| 3 locks held by kworker/0:1/62:
| #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0
| #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0
| #2: ffff8881381f6df8 (&stab->lock){+...}, at: sock_map_free+0x26/0x180
| CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04008-g7b083332376e #454
| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
| Workqueue: events bpf_map_free_deferred
| Call Trace:
| dump_stack+0x71/0xa0
| ___might_sleep.cold+0xa6/0xb6
| lock_sock_nested+0x28/0x90
| sock_map_free+0x5f/0x180
| bpf_map_free_deferred+0x58/0x80
| process_one_work+0x260/0x5e0
| worker_thread+0x4d/0x3e0
| kthread+0x108/0x140
| ? process_one_work+0x5e0/0x5e0
| ? kthread_park+0x90/0x90
| ret_from_fork+0x3a/0x50
The reason we have stab->lock and bucket->locks in sockmap code is to
handle checking EEXIST in update/delete cases. We need to be careful during
an update operation that we check for EEXIST and we need to ensure that the
psock object is not in some partial state of removal/insertion while we do
this. So both map_update_common and sock_map_delete need to guard from being
run together potentially deleting an entry we are checking, etc. But by the
time we get to the tear-down code in sock_{ma[|hash}_free we have already
disconnected the map and we just did synchronize_rcu() in the line above so
no updates/deletes should be in flight. Because of this we can drop the
bucket locks from the map free'ing code, noting no update/deletes can be
in-flight.
Fixes: 604326b41a ("bpf, sockmap: convert to generic sk_msg interface")
Reported-by: Jakub Sitnicki <jakub@cloudflare.com>
Suggested-by: Jakub Sitnicki <jakub@cloudflare.com>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/158385850787.30597.8346421465837046618.stgit@john-Precision-5820-Tower
When trying to transmit to an unknown destination, the mesh code would
unconditionally transmit a HWMP PREQ even if HWMP is not the current
path selection algorithm.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Link: https://lore.kernel.org/r/20200305140409.12204-1-cavallar@lri.fr
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add missing attribute validation for beacon report scanning
to the netlink policy.
Fixes: 1d76250bd3 ("nl80211: support beacon report scanning")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://lore.kernel.org/r/20200303051058.4089398-3-kuba@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Julian Wiedmann says:
====================
s390/qeth: fixes 2020-03-10
This fixes three minor issues:
1) a setup parameter gets cleared unnecessarily when the HW config
changes,
2) insufficient error handling when initially filling the RX ring, and
3) a rarely used worker that needs to be cancelled during tear down.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When qeth's napi poll code fails to refill an entirely empty RX ring, it
kicks off buffer_reclaim_work to try again later.
Make sure that this worker is cancelled when setting the qeth device
offline. Otherwise a RX refill action can unexpectedly end up running
concurrently to bigger re-configurations (eg. resizing the buffer pool),
without any locking.
Fixes: b333293058 ("qeth: add support for af_iucv HiperSockets transport")
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
qeth_init_qdio_queues() fills the RX ring with an initial set of
RX buffers. If qeth_init_input_buffer() fails to back one of the RX
buffers with memory, we need to bail out and report the error.
Fixes: 4a71df5004 ("qeth: new qeth device driver")
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When an OSA device in prio-queue setup is reduced to 1 TX queue due to
HW restrictions, we reset its the default_out_queue to 0.
In the old code this was needed so that qeth_get_priority_queue() gets
the queue selection right. But with proper multiqueue support we already
reduced dev->real_num_tx_queues to 1, and so the stack puts all traffic
on txq 0 without even calling .ndo_select_queue.
Thus we can preserve the user's configuration, and apply it if the OSA
device later re-gains support for multiple TX queues.
Fixes: 73dc2daf11 ("s390/qeth: add TX multiqueue support for OSA devices")
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Igor Russkikh says:
====================
MACSec bugfixes related to MAC address change
We found out that there's an issue in MACSec code when the MAC address
is changed.
Both s/w and offloaded implementations don't update SCI when the MAC
address changes at the moment, but they should do so, because SCI contains
MAC in its first 6 octets.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Notify the offload engine about MAC address change to reconfigure it
accordingly.
Fixes: 3cf3227a21 ("net: macsec: hardware offloading infrastructure")
Signed-off-by: Dmitry Bogdanov <dbogdanov@marvell.com>
Signed-off-by: Mark Starovoytov <mstarovoitov@marvell.com>
Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
SCI should be updated, because it contains MAC in its first 6 octets.
Fixes: c09440f7dc ("macsec: introduce IEEE 802.1AE driver")
Signed-off-by: Dmitry Bogdanov <dbogdanov@marvell.com>
Signed-off-by: Mark Starovoytov <mstarovoitov@marvell.com>
Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The ibmvnic driver does not check the device state when the device
is removed. If the device is removed while a device reset is being
processed, the remove may free structures needed by the reset,
causing an oops.
Fix this by checking the device state before processing device remove.
Signed-off-by: Juliet Kim <julietk@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
During IB device removal, cancel the event worker before the device
structure is freed.
Fixes: a4cf0443c4 ("smc: introduce SMC as an IB-client")
Reported-by: syzbot+b297c6825752e7a07272@syzkaller.appspotmail.com
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Reviewed-by: Ursula Braun <ubraun@linux.ibm.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Rafał found an issue that for non-Ethernet interface, if we down and up
frequently, the memory will be consumed slowly.
The reason is we add allnodes/allrouters addressed in multicast list in
ipv6_add_dev(). When link down, we call ipv6_mc_down(), store all multicast
addresses via mld_add_delrec(). But when link up, we don't call ipv6_mc_up()
for non-Ethernet interface to remove the addresses. This makes idev->mc_tomb
getting bigger and bigger. The call stack looks like:
addrconf_notify(NETDEV_REGISTER)
ipv6_add_dev
ipv6_dev_mc_inc(ff01::1)
ipv6_dev_mc_inc(ff02::1)
ipv6_dev_mc_inc(ff02::2)
addrconf_notify(NETDEV_UP)
addrconf_dev_config
/* Alas, we support only Ethernet autoconfiguration. */
return;
addrconf_notify(NETDEV_DOWN)
addrconf_ifdown
ipv6_mc_down
igmp6_group_dropped(ff02::2)
mld_add_delrec(ff02::2)
igmp6_group_dropped(ff02::1)
igmp6_group_dropped(ff01::1)
After investigating, I can't found a rule to disable multicast on
non-Ethernet interface. In RFC2460, the link could be Ethernet, PPP, ATM,
tunnels, etc. In IPv4, it doesn't check the dev type when calls ip_mc_up()
in inetdev_event(). Even for IPv6, we don't check the dev type and call
ipv6_add_dev(), ipv6_dev_mc_inc() after register device.
So I think it's OK to fix this memory consumer by calling ipv6_mc_up() for
non-Ethernet interface.
v2: Also check IFF_MULTICAST flag to make sure the interface supports
multicast
Reported-by: Rafał Miłecki <zajec5@gmail.com>
Tested-by: Rafał Miłecki <zajec5@gmail.com>
Fixes: 74235a25c6 ("[IPV6] addrconf: Fix IPv6 on tuntap tunnels")
Fixes: 1666d49e1d ("mld: do not remove mld souce list info when set link down")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It has been a while since the last time I sent one!
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEPjU5OPd5QIZ9jqqOGXyLc2htIW0FAl5nujkACgkQGXyLc2ht
IW3cUBAAtLrfdsFPr/uLeFpHFIPm+X3ZAq/nOQBdrerR4GJfMD/zDN5FjKiXlsfo
KWIk/kG0nyqEnRrwX/oh8XqGdx3kgGuniZY9Sjo9XOMggS4pdYZBYo/6LVnJ1Mgo
2AOb9z+5wqOvsOLeIH46M0avOk2V2+hdlClx/ns6WeQnTipqbMzgWAfdnsTWk3i7
ApK4Sc/1yQPKz1Nhr/REcADU38x2fyfHj1r2EvCm2E3ljC/che5LkvCmZHr5Iqud
iC/BooxdeCsFfN4mvl17IBsK1iveeRt+ZFW4NsijiMNBYrfUQ74PxEre+iCn1uk3
+KLsBnYVsqkrczyGPHjtZJnonEOjte7BQp076vA2QcTRDS3akAfdm94QsUwHJq39
iJVo8LHJhLPoIgfdhml3RFDLSA5FB7O5feC6gDNgPnq7X9FqNeNvJRJzqYTe3TtE
UqXpbbqFf4I+1GOBOmOSOL8eSBfnJVoTOwVJsvcMF1SBfwpyYyQApOXsIQjKcZH+
KGIoUTd6bS6xc4FMx/6/O2Z7aWUaH72X1jADo0uP947BhQGQDcnRmH/cu+IqXceB
sHs6a2a3wuJ9iqDb3fT1tEF/k2n9X5y9PPYqRynD1320E9OWihavG89+3m5BrfJd
NFSxp8Buw72hjbTJDRv79RtVhZcYdUOAauO26IX+3K5X9ThZfrk=
=t4To
-----END PGP SIGNATURE-----
Merge tag 'clang-format-for-linus-v5.6-rc6' of git://github.com/ojeda/linux
Pull clang-format update from Miguel Ojeda:
"Another update for the .clang-format macro list
It has been a while since the last time I sent one!"
* tag 'clang-format-for-linus-v5.6-rc6' of git://github.com/ojeda/linux:
clang-format: Update with the latest for_each macro list
If a TCP socket is allocated in IRQ context or cloned from unassociated
(i.e. not associated to a memcg) in IRQ context then it will remain
unassociated for its whole life. Almost half of the TCPs created on the
system are created in IRQ context, so, memory used by such sockets will
not be accounted by the memcg.
This issue is more widespread in cgroup v1 where network memory
accounting is opt-in but it can happen in cgroup v2 if the source socket
for the cloning was created in root memcg.
To fix the issue, just do the association of the sockets at the accept()
time in the process context and then force charge the memory buffer
already used and reserved by the socket.
Signed-off-by: Shakeel Butt <shakeelb@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We are testing network memory accounting in our setup and noticed
inconsistent network memory usage and often unrelated cgroups network
usage correlates with testing workload. On further inspection, it
seems like mem_cgroup_sk_alloc() and cgroup_sk_alloc() are broken in
irq context specially for cgroup v1.
mem_cgroup_sk_alloc() and cgroup_sk_alloc() can be called in irq context
and kind of assumes that this can only happen from sk_clone_lock()
and the source sock object has already associated cgroup. However in
cgroup v1, where network memory accounting is opt-in, the source sock
can be unassociated with any cgroup and the new cloned sock can get
associated with unrelated interrupted cgroup.
Cgroup v2 can also suffer if the source sock object was created by
process in the root cgroup or if sk_alloc() is called in irq context.
The fix is to just do nothing in interrupt.
WARNING: Please note that about half of the TCP sockets are allocated
from the IRQ context, so, memory used by such sockets will not be
accouted by the memcg.
The stack trace of mem_cgroup_sk_alloc() from IRQ-context:
CPU: 70 PID: 12720 Comm: ssh Tainted: 5.6.0-smp-DEV #1
Hardware name: ...
Call Trace:
<IRQ>
dump_stack+0x57/0x75
mem_cgroup_sk_alloc+0xe9/0xf0
sk_clone_lock+0x2a7/0x420
inet_csk_clone_lock+0x1b/0x110
tcp_create_openreq_child+0x23/0x3b0
tcp_v6_syn_recv_sock+0x88/0x730
tcp_check_req+0x429/0x560
tcp_v6_rcv+0x72d/0xa40
ip6_protocol_deliver_rcu+0xc9/0x400
ip6_input+0x44/0xd0
? ip6_protocol_deliver_rcu+0x400/0x400
ip6_rcv_finish+0x71/0x80
ipv6_rcv+0x5b/0xe0
? ip6_sublist_rcv+0x2e0/0x2e0
process_backlog+0x108/0x1e0
net_rx_action+0x26b/0x460
__do_softirq+0x104/0x2a6
do_softirq_own_stack+0x2a/0x40
</IRQ>
do_softirq.part.19+0x40/0x50
__local_bh_enable_ip+0x51/0x60
ip6_finish_output2+0x23d/0x520
? ip6table_mangle_hook+0x55/0x160
__ip6_finish_output+0xa1/0x100
ip6_finish_output+0x30/0xd0
ip6_output+0x73/0x120
? __ip6_finish_output+0x100/0x100
ip6_xmit+0x2e3/0x600
? ipv6_anycast_cleanup+0x50/0x50
? inet6_csk_route_socket+0x136/0x1e0
? skb_free_head+0x1e/0x30
inet6_csk_xmit+0x95/0xf0
__tcp_transmit_skb+0x5b4/0xb20
__tcp_send_ack.part.60+0xa3/0x110
tcp_send_ack+0x1d/0x20
tcp_rcv_state_process+0xe64/0xe80
? tcp_v6_connect+0x5d1/0x5f0
tcp_v6_do_rcv+0x1b1/0x3f0
? tcp_v6_do_rcv+0x1b1/0x3f0
__release_sock+0x7f/0xd0
release_sock+0x30/0xa0
__inet_stream_connect+0x1c3/0x3b0
? prepare_to_wait+0xb0/0xb0
inet_stream_connect+0x3b/0x60
__sys_connect+0x101/0x120
? __sys_getsockopt+0x11b/0x140
__x64_sys_connect+0x1a/0x20
do_syscall_64+0x51/0x200
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The stack trace of mem_cgroup_sk_alloc() from IRQ-context:
Fixes: 2d75807383 ("mm: memcontrol: consolidate cgroup socket tracking")
Fixes: d979a39d72 ("cgroup: duplicate cgroup reference when cloning sockets")
Signed-off-by: Shakeel Butt <shakeelb@google.com>
Reviewed-by: Roman Gushchin <guro@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- charlcd: replace zero-length array with flexible-array member
From the kernel-wide cleanup Gustavo A. R. Silva is performing
- img-ascii-lcd: convert to devm_platform_ioremap_resource
From Yangtao Li
- Fix Kconfig indentation
From Krzysztof Kozlowski
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEPjU5OPd5QIZ9jqqOGXyLc2htIW0FAl5nuYwACgkQGXyLc2ht
IW1bJQ//SghpbB2ArCM7/D2lblUs2DWdk3FvEpfQ4RmowFAM7bWZXH9w8Wfym+33
dUUXMK3mTi7FFFFsYuX1hEP3KFctfP5M262pmXX/fNRZj36g3zwIr63Vpx3l3cdg
5WwSxHUpJ8VpXfq+/wqNGNV+KenyIQDOyHefkf9zrhs/C5Da2YMwRTNK8WOITrgm
W/RBeCBYsTRbXKJ9REXFbUFq0AawV1Fd6OzDTxbPmywRbtmGD9tyelcHPQSxasI7
TMGJ7g2JVfdcM8jJFt7EKsehPgv2/2+oj5OxhY1m8L/tiIyIL7qwqMX5iG01YOkF
pFEvTEGrSWSIruD+tMeV0nlVqBW0ZSwOFv3DkO5g3Yfn5SEDV3jRrcsw/BpcXOcH
Tm1D3/AGT9mRtN1+gt3JnobGm0XJadu5u/dWngrM7KF9bua+dCMAlmIBugblwvwJ
bTkMleiLHk3rA3AJLLreywbYNW/9qejbQ5EODHr7UrPSA0LPTWNPWD1fBsMKt/hw
MXUVWMfLuo6sG9Tz9i3Suru1thrVzFHRVYioxfjUL6VhllyK//qzPIHk/oRKaiIo
1hDs39fxptRgFggzIaKTuBvra9Uf+UOn/7fUIU3iNWm6OlXprGAOPMWyOIw/eC0s
lxsYDzyOy7KCCFOU7cITAeU3eZhHzsCMR8dWGGkz8+KHG5WfnjI=
=63zv
-----END PGP SIGNATURE-----
Merge tag 'auxdisplay-for-linus-v5.6-rc6' of git://github.com/ojeda/linux
Pull auxdisplay updates from Miguel Ojeda:
"A few minor auxdisplay improvements:
- charlcd: replace zero-length array with flexible-array member
(kernel-wide cleanup by Gustavo A. R. Silva)
- img-ascii-lcd: convert to devm_platform_ioremap_resource (Yangtao
Li)
- Fix Kconfig indentation (Krzysztof Kozlowski)
* tag 'auxdisplay-for-linus-v5.6-rc6' of git://github.com/ojeda/linux:
auxdisplay: charlcd: replace zero-length array with flexible-array member
auxdisplay: img-ascii-lcd: convert to devm_platform_ioremap_resource
auxdisplay: Fix Kconfig indentation
Casey Leedomn <leedom@chelsio.com> is bouncing,
Vishal indicated he's happy to take the role.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull cgroup fixes from Tejun Heo:
- cgroup.procs listing related fixes.
It didn't interlock properly with exiting tasks leaving a short
window where a cgroup has empty cgroup.procs but still can't be
removed and misbehaved on short reads.
- psi_show() crash fix on 32bit ino archs
- Empty release_agent handling fix
* 'for-5.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
cgroup1: don't call release_agent when it is ""
cgroup: fix psi_show() crash on 32bit ino archs
cgroup: Iterate tasks that did not finish do_exit()
cgroup: cgroup_procs_next should increase position index
cgroup-v1: cgroup_pidlist_next should update position index
Pull workqueue fixes from Tejun Heo:
"Workqueue has been incorrectly round-robining per-cpu work items.
Hillf's patch fixes that.
The other patch documents memory-ordering properties of workqueue
operations"
* 'for-5.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
workqueue: don't use wq_select_unbound_cpu() for bound works
workqueue: Document (some) memory-ordering properties of {queue,schedule}_work()
dc to pplib interface is changed for navi1x, renoir.
display_config_changed is not called by dc anymore.
smu_write_watermarks_table is not executed for navi1x, renoir
during boot up.
solution: call smu_write_watermarks_table just after dc pass
watermark clock settings to pplib
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Yoshiki Komachi says:
====================
btf_enum_check_member() checked if the size of "enum" as a struct
member exceeded struct_size or not. Then, the function compared it
with the size of "int". Although the size of "enum" is 4-byte by
default (i.e., equivalent to "int"), the packing feature enables
us to reduce it, as illustrated by the following example:
struct A {
char m;
enum { E0, E1 } __attribute__((packed)) n;
};
With such a setup above, the bpf loader gave an error attempting
to load it:
------------------------------------------------------------------
...
[3] ENUM (anon) size=1 vlen=2
E0 val=0
E1 val=1
[4] STRUCT A size=2 vlen=2
m type_id=2 bits_offset=0
n type_id=3 bits_offset=8
[4] STRUCT A size=2 vlen=2
n type_id=3 bits_offset=8 Member exceeds struct_size
libbpf: Error loading .BTF into kernel: -22.
------------------------------------------------------------------
The related issue was previously fixed by the commit 9eea984979 ("bpf:
fix BTF verification of enums"). On the other hand, this series fixes
this issue as well, and adds a selftest program for it.
Changes in v2:
- change an example in commit message based on Andrii's review
- add a selftest program for packed "enum" type members in struct/union
====================
Acked-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
btf_enum_check_member() was currently sure to recognize the size of
"enum" type members in struct/union as the size of "int" even if
its size was packed.
This patch fixes BTF enum verification to use the correct size
of member in BPF programs.
Fixes: 179cde8cef ("bpf: btf: Check members of struct/union")
Signed-off-by: Yoshiki Komachi <komachi.yoshiki@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/1583825550-18606-2-git-send-email-komachi.yoshiki@gmail.com
wq_select_unbound_cpu() is designed for unbound workqueues only, but
it's wrongly called when using a bound workqueue too.
Fixing this ensures work queued to a bound workqueue with
cpu=WORK_CPU_UNBOUND always runs on the local CPU.
Before, that would happen only if wq_unbound_cpumask happened to include
it (likely almost always the case), or was empty, or we got lucky with
forced round-robin placement. So restricting
/sys/devices/virtual/workqueue/cpumask to a small subset of a machine's
CPUs would cause some bound work items to run unexpectedly there.
Fixes: ef55718044 ("workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs")
Cc: stable@vger.kernel.org # v4.5+
Signed-off-by: Hillf Danton <hdanton@sina.com>
[dj: massage changelog]
Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tejun Heo <tj@kernel.org>
The current URL mentioned in iwlwifi's W entry is outdated and
currently pointing to a dead link. Change it so that it points to the
correct Wiki page directly.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* Fix a locking issue in time events handling;
* A fix in rate-scaling;
* Fix for a potential NULL pointer deref;
* Enable antenna diversity in some devices that were erroneously not
doing it;
* Allow FW dumps to continue when the FW is stuck;
* A fix in the HE capabilities handling;
* Another fix for FW dumps where we were reading wrong addresses.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEF3LNfgb2BPWm68smoUecoho8xfoFAl5krooACgkQoUecoho8
xfrebhAAtodRYFgcK2iW0pk7noelDVqkzaYgEWdiOI3tTz8LnWQ5mJ7MA6eMxpU7
LirAvJ/rA1aLlk3jrDIEnY+jSL5J51tdcPOMBvYTtaJNn2dQarHCJCBGXadFv3UO
sz648ibiZUzW+00psSv0oFfs6nAE2x6Nlt1wJAMRgRRdG0kHSjRO78ckNyzDwi82
Gav8VjWxc2XjRfRqwWF6gy55IRBYsTAlXbtHEQ8DI4RoJROiPdOqfd/bZig3yOJs
/du6fUjz8Dt8kqmJsUQuxQ4GgscUNYKweesL2C0vT5OF0b/f2Dlce/edXJ5glN85
wWP/dq67wEvs5en4vWxbljDpWTE4oGdBTFhjDMAlYV2YkkXp+RzJXTQtHfj2Q3Of
Fc9waXamn7jfXB0JVAaDL0Q7Aq+0XGmSZnwbEUChpTvN9UvoE+B0om4HZ8TTvMhe
EK0ZKYwbYfk587RTFG/oYLJ5hzQlIhOKouHoR3kg/Tf0blvt2xfZBgkOujF+cYYP
4AsPLrFyhJzfSbQCp2PhER/pakh3Z0nE0XIUCqJIk7ZFbbF/HMEZUCK8wmyRt0rZ
7ZeUkCwTdjY4CM3dc8oDu2iaxEDBcw6GyoD0Y1DRnA9i/XOotLKqwJq6iSZnsdsJ
UoQmJdItlsLF+/Ug/g49/va3/7qk/twCTRxDWJo9wMKSR9mN5JA=
=0Le+
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-for-kalle-2020-03-08' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
First batch of fixes intended for v5.6
* Fix a locking issue in time events handling;
* A fix in rate-scaling;
* Fix for a potential NULL pointer deref;
* Enable antenna diversity in some devices that were erroneously not
doing it;
* Allow FW dumps to continue when the FW is stuck;
* A fix in the HE capabilities handling;
* Another fix for FW dumps where we were reading wrong addresses.
There is no compensating cgroup_bpf_put() for each ancestor cgroup in
cgroup_bpf_inherit(). If compute_effective_progs returns error, those cgroups
won't be freed ever. Fix it by putting them in cleanup code path.
Fixes: e10360f815 ("bpf: cgroup: prevent out-of-order release of cgroup bpf")
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Roman Gushchin <guro@fb.com>
Link: https://lore.kernel.org/bpf/20200309224017.1063297-1-andriin@fb.com
Dave Airlie
Chris Wilson
Matthew Auld
Tina Zhang
Nathan Chancellor
Linus Torvalds
David S. Miller
Christoph Hellwig
Artem Savkov
John Fastabend
Nicolas Cavallari
Jakub Kicinski
Julian Wiedmann
Dmitry Bogdanov
Juliet Kim
Karsten Graul
Hangbin Liu
Shakeel Butt
Hersen Wu
Alexei Starovoitov
Yoshiki Komachi
Hillf Danton
Luca Coelho
Kalle Valo
Jani Nikula
Marek Szyprowski
Andrii Nakryiko