The terminator for the mode 1 syscalls list was a 0, but that could be
a valid syscall number (e.g. x86_64 __NR_read). By luck, __NR_read was
listed first and the loop construct would not test it, so there was no
bug. However, this is fragile. Replace the terminator with -1 instead,
and make the variable name for mode 1 syscall lists more descriptive.
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Will Drewry <wad@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit fe4bfff86ec54773df3db79e8112e3b0f820c799)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: I3d91bf57236f2c20d71f22fa9c0ef7b0b8869bcf
We've been making heavy use of the seccomp notifier to intercept and
handle certain syscalls for containers. This patch allows a syscall
supervisor listening on a given notifier to be notified when a seccomp
filter has become unused.
A container is often managed by a singleton supervisor process the
so-called "monitor". This monitor process has an event loop which has
various event handlers registered. If the user specified a seccomp
profile that included a notifier for various syscalls then we also
register a seccomp notify even handler. For any container using a
separate pid namespace the lifecycle of the seccomp notifier is bound to
the init process of the pid namespace, i.e. when the init process exits
the filter must be unused.
If a new process attaches to a container we force it to assume a seccomp
profile. This can either be the same seccomp profile as the container
was started with or a modified one. If the attaching process makes use
of the seccomp notifier we will register a new seccomp notifier handler
in the monitor's event loop. However, when the attaching process exits
we can't simply delete the handler since other child processes could've
been created (daemons spawned etc.) that have inherited the seccomp
filter and so we need to keep the seccomp notifier fd alive in the event
loop. But this is problematic since we don't get a notification when the
seccomp filter has become unused and so we currently never remove the
seccomp notifier fd from the event loop and just keep accumulating fds
in the event loop. We've had this issue for a while but it has recently
become more pressing as more and larger users make use of this.
To fix this, we introduce a new "users" reference counter that tracks any
tasks and dependent filters making use of a filter. When a notifier is
registered waiting tasks will be notified that the filter is now empty
by receiving a (E)POLLHUP event.
The concept in this patch introduces is the same as for signal_struct,
i.e. reference counting for life-cycle management is decoupled from
reference counting taks using the object. There's probably some trickery
possible but the second counter is just the correct way of doing this
IMHO and has precedence.
Cc: Tycho Andersen <tycho@tycho.ws>
Cc: Kees Cook <keescook@chromium.org>
Cc: Matt Denton <mpdenton@google.com>
Cc: Sargun Dhillon <sargun@sargun.me>
Cc: Jann Horn <jannh@google.com>
Cc: Chris Palmer <palmer@google.com>
Cc: Aleksa Sarai <cyphar@cyphar.com>
Cc: Robert Sesek <rsesek@google.com>
Cc: Jeffrey Vander Stoep <jeffv@google.com>
Cc: Linux Containers <containers@lists.linux-foundation.org>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Link: https://lore.kernel.org/r/20200531115031.391515-3-christian.brauner@ubuntu.com
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 99cdb8b9a57393b5978e7a6310a2cba511dd179b)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: I1501f5134bf738fa641c8b35ed65a4bed01e6fef
Lift the wait_queue from struct notification into struct seccomp_filter.
This is cleaner overall and lets us avoid having to take the notifier
mutex in the future for EPOLLHUP notifications since we need to neither
read nor modify the notifier specific aspects of the seccomp filter. In
the exit path I'd very much like to avoid having to take the notifier mutex
for each filter in the task's filter hierarchy.
Cc: Tycho Andersen <tycho@tycho.ws>
Cc: Kees Cook <keescook@chromium.org>
Cc: Matt Denton <mpdenton@google.com>
Cc: Sargun Dhillon <sargun@sargun.me>
Cc: Jann Horn <jannh@google.com>
Cc: Chris Palmer <palmer@google.com>
Cc: Aleksa Sarai <cyphar@cyphar.com>
Cc: Robert Sesek <rsesek@google.com>
Cc: Jeffrey Vander Stoep <jeffv@google.com>
Cc: Linux Containers <containers@lists.linux-foundation.org>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 76194c4e830d570d9e369d637bb907591d2b3111)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: Id87b359f1155d26068cd62d5295dc39849d46495
The seccomp filter used to be released in free_task() which is called
asynchronously via call_rcu() and assorted mechanisms. Since we need
to inform tasks waiting on the seccomp notifier when a filter goes empty
we will notify them as soon as a task has been marked fully dead in
release_task(). To not split seccomp cleanup into two parts, move
filter release out of free_task() and into release_task() after we've
unhashed struct task from struct pid, exited signals, and unlinked it
from the threadgroups' thread list. We'll put the empty filter
notification infrastructure into it in a follow up patch.
This also renames put_seccomp_filter() to seccomp_filter_release() which
is a more descriptive name of what we're doing here especially once
we've added the empty filter notification mechanism in there.
We're also NULL-ing the task's filter tree entrypoint which seems
cleaner than leaving a dangling pointer in there. Note that this shouldn't
need any memory barriers since we're calling this when the task is in
release_task() which means it's EXIT_DEAD. So it can't modify its seccomp
filters anymore. You can also see this from the point where we're calling
seccomp_filter_release(). It's after __exit_signal() and at this point,
tsk->sighand will already have been NULLed which is required for
thread-sync and filter installation alike.
Cc: Tycho Andersen <tycho@tycho.ws>
Cc: Kees Cook <keescook@chromium.org>
Cc: Matt Denton <mpdenton@google.com>
Cc: Sargun Dhillon <sargun@sargun.me>
Cc: Jann Horn <jannh@google.com>
Cc: Chris Palmer <palmer@google.com>
Cc: Aleksa Sarai <cyphar@cyphar.com>
Cc: Robert Sesek <rsesek@google.com>
Cc: Jeffrey Vander Stoep <jeffv@google.com>
Cc: Linux Containers <containers@lists.linux-foundation.org>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Link: https://lore.kernel.org/r/20200531115031.391515-2-christian.brauner@ubuntu.com
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 3a15fb6ed92cb32b0a83f406aa4a96f28c9adbc3)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Resolved minor merge conflict in kernel/exit.c where 5.4 does not have
commits 7bc3e6e55acf0 and 6ade99ec6175a.
Change-Id: I4a0113f3f64a86937ba5c9ac6e2537926e2827be
Naming the lifetime counter of a seccomp filter "usage" suggests a
little too strongly that its about tasks that are using this filter
while it also tracks other references such as the user notifier or
ptrace. This also updates the documentation to note this fact.
We'll be introducing an actual usage counter in a follow-up patch.
Cc: Tycho Andersen <tycho@tycho.ws>
Cc: Kees Cook <keescook@chromium.org>
Cc: Matt Denton <mpdenton@google.com>
Cc: Sargun Dhillon <sargun@sargun.me>
Cc: Jann Horn <jannh@google.com>
Cc: Chris Palmer <palmer@google.com>
Cc: Aleksa Sarai <cyphar@cyphar.com>
Cc: Robert Sesek <rsesek@google.com>
Cc: Jeffrey Vander Stoep <jeffv@google.com>
Cc: Linux Containers <containers@lists.linux-foundation.org>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Link: https://lore.kernel.org/r/20200531115031.391515-1-christian.brauner@ubuntu.com
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit b707ddee11d1dc4518ab7f1aa5e7af9ceaa23317)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: If4c78f85b9873aea2dffa1c8afb250f534d0fedc
This adds a helper which can iterate through a seccomp_filter to
find a notification matching an ID. It removes several replicated
chunks of code.
Signed-off-by: Sargun Dhillon <sargun@sargun.me>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Reviewed-by: Tycho Andersen <tycho@tycho.ws>
Cc: Matt Denton <mpdenton@google.com>
Cc: Kees Cook <keescook@google.com>,
Cc: Jann Horn <jannh@google.com>,
Cc: Robert Sesek <rsesek@google.com>,
Cc: Chris Palmer <palmer@google.com>
Cc: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Tycho Andersen <tycho@tycho.ws>
Link: https://lore.kernel.org/r/20200601112532.150158-1-sargun@sargun.me
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 9f87dcf14b82b05ff0e26970439b372ae135de0c)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: I328edd8717fc06a415f7d4cf4fe561d86b2d4682
A common question asked when debugging seccomp filters is "how many
filters are attached to your process?" Provide a way to easily answer
this question through /proc/$pid/status with a "Seccomp_filters" line.
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit c818c03b661cd769e035e41673d5543ba2ebda64)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: Ib189ea77511a6088d5d328706c77c88709d8d63e
commit 5cb249686e67dbef3ffe53887fa725eefc5a7144 upstream.
addrconf_prefix_rcv returned early without releasing the inet6_dev
pointer when the PIO lifetime is less than accept_ra_min_lft.
Change-Id: Ic633a1ea28c96f712dce8875f24227ce02ab86b0
Fixes: 5027d54a9c30 ("net: change accept_ra_min_rtr_lft to affect all RA lifetimes")
Cc: Maciej Żenczykowski <maze@google.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: David Ahern <dsahern@kernel.org>
Cc: Simon Horman <horms@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: Patrick Rohr <prohr@google.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5027d54a9c30bc7ec808360378e2b4753f053f25 upstream.
accept_ra_min_rtr_lft only considered the lifetime of the default route
and discarded entire RAs accordingly.
This change renames accept_ra_min_rtr_lft to accept_ra_min_lft, and
applies the value to individual RA sections; in particular, router
lifetime, PIO preferred lifetime, and RIO lifetime. If any of those
lifetimes are lower than the configured value, the specific RA section
is ignored.
In order for the sysctl to be useful to Android, it should really apply
to all lifetimes in the RA, since that is what determines the minimum
frequency at which RAs must be processed by the kernel. Android uses
hardware offloads to drop RAs for a fraction of the minimum of all
lifetimes present in the RA (some networks have very frequent RAs (5s)
with high lifetimes (2h)). Despite this, we have encountered networks
that set the router lifetime to 30s which results in very frequent CPU
wakeups. Instead of disabling IPv6 (and dropping IPv6 ethertype in the
WiFi firmware) entirely on such networks, it seems better to ignore the
misconfigured routers while still processing RAs from other IPv6 routers
on the same network (i.e. to support IoT applications).
The previous implementation dropped the entire RA based on router
lifetime. This turned out to be hard to expand to the other lifetimes
present in the RA in a consistent manner; dropping the entire RA based
on RIO/PIO lifetimes would essentially require parsing the whole thing
twice.
Change-Id: I2168608875629ae07bbd30a02a061284110693e7
Fixes: 1671bcfd76fd ("net: add sysctl accept_ra_min_rtr_lft")
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Patrick Rohr <prohr@google.com>
Reviewed-by: Maciej Żenczykowski <maze@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20230726230701.919212-1-prohr@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1671bcfd76fdc0b9e65153cf759153083755fe4c upstream.
This change adds a new sysctl accept_ra_min_rtr_lft to specify the
minimum acceptable router lifetime in an RA. If the received RA router
lifetime is less than the configured value (and not 0), the RA is
ignored.
This is useful for mobile devices, whose battery life can be impacted
by networks that configure RAs with a short lifetime. On such networks,
the device should never gain IPv6 provisioning and should attempt to
drop RAs via hardware offload, if available.
Change-Id: I5e575f2e2d303c6736fc5e983b65003c7e7a075a
Signed-off-by: Patrick Rohr <prohr@google.com>
Cc: Maciej Żenczykowski <maze@google.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 52cc02b910284d6bddba46cce402044ab775f314 upstream.
LLVM_IAS is the user interface to set the -(no-)integrated-as flag,
and it should be used only for that purpose.
LLVM_IAS is checked in some places to determine the assembler type,
but it is not precise.
For example,
$ make CC=gcc LLVM_IAS=1
... will use the GNU assembler (i.e. binutils) since LLVM_IAS=1 is
effective only when $(CC) is clang.
Of course, 'CC=gcc LLVM_IAS=1' is an odd combination, but the build
system can be more robust against such insane input.
Commit ba64beb17493a ("kbuild: check the minimum assembler version in
Kconfig") introduced CONFIG_AS_IS_GNU/LLVM, which is more precise
because Kconfig checks the version string from the assembler in use.
Change-Id: I190f91350cdb4305a01cabc80d952b0541aef521
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
[nathan: Backport to 5.10]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2185a7e4b0ade86c2c57fc63d4a7535c40254bd0 upstream.
It has been brought up a few times in various code reviews that clang
3.5 introduced -f{,no-}integrated-as as the preferred way to enable and
disable the integrated assembler, mentioning that -{no-,}integrated-as
are now considered legacy flags.
Switch the kernel over to using those variants in case there is ever a
time where clang decides to remove the non-'f' variants of the flag.
Also, fix a typo in a comment ("intergrated" -> "integrated").
Link: https://releases.llvm.org/3.5.0/tools/clang/docs/ReleaseNotes.html#new-compiler-flags
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Change-Id: Id848bd57d5e27afb85cf51c26d9312751168407e
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
[nathan: Backport to 5.10]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Documentation/process/changes.rst defines the minimum assembler version
(binutils version), but we have never checked it in the build time.
Kbuild never invokes 'as' directly because all assembly files in the
kernel tree are *.S, hence must be preprocessed. I do not expect
raw assembly source files (*.s) would be added to the kernel tree.
Therefore, we always use $(CC) as the assembler driver, and commit
aa824e0c962b ("kbuild: remove AS variable") removed 'AS'. However,
we are still interested in the version of the assembler acting behind.
As usual, the --version option prints the version string.
$ as --version | head -n 1
GNU assembler (GNU Binutils for Ubuntu) 2.35.1
But, we do not have $(AS). So, we can add the -Wa prefix so that
$(CC) passes --version down to the backing assembler.
$ gcc -Wa,--version | head -n 1
gcc: fatal error: no input files
compilation terminated.
OK, we need to input something to satisfy gcc.
$ gcc -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
GNU assembler (GNU Binutils for Ubuntu) 2.35.1
The combination of Clang and GNU assembler works in the same way:
$ clang -no-integrated-as -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
GNU assembler (GNU Binutils for Ubuntu) 2.35.1
Clang with the integrated assembler fails like this:
$ clang -integrated-as -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
clang: error: unsupported argument '--version' to option 'Wa,'
For the last case, checking the error message is fragile. If the
proposal for -Wa,--version support [1] is accepted, this may not be
even an error in the future.
One easy way is to check if -integrated-as is present in the passed
arguments. We did not pass -integrated-as to CLANG_FLAGS before, but
we can make it explicit.
Nathan pointed out -integrated-as is the default for all of the
architectures/targets that the kernel cares about, but it goes
along with "explicit is better than implicit" policy. [2]
With all this in my mind, I implemented scripts/as-version.sh to
check the assembler version in Kconfig time.
$ scripts/as-version.sh gcc
GNU 23501
$ scripts/as-version.sh clang -no-integrated-as
GNU 23501
$ scripts/as-version.sh clang -integrated-as
LLVM 0
[1]: https://github.com/ClangBuiltLinux/linux/issues/1320
[2]: https://lore.kernel.org/linux-kbuild/20210307044253.v3h47ucq6ng25iay@archlinux-ax161/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
[nd: conflict in arch/Kconfig due to missing dc5723b02e523 ("kbuild: add
support for Clang LTO") which landed in v5.12-rc1]
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
(cherry picked from commit ba64beb17493a4bfec563100c86a462a15926f24)
Bug: 210043760
Change-Id: I9bcc528adbb86fa902123611ce979af0dd455ad5
commit f4c3b83b75b91c5059726cb91e3165cc01764ce7 upstream.
With commit 1e860048c53e ("gcc-plugins: simplify GCC plugin-dev
capability test") applied, this hunk can be way simplified because
now scripts/gcc-plugins/Kconfig only checks plugin-version.h
Change-Id: Ic718951bcba65cdfe92ac2b8b6857ad96424408c
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit b3d9fc1436808a4ef9927e558b3415e728e710c5 ]
There is a test in Kconfig which takes inverted value of a compiler
check:
* config CC_HAS_INT128
def_bool !$(cc-option,$(m64-flag) -D__SIZEOF_INT128__=0)
This results in CC_HAS_INT128 not being in super-config generated by
dummy-tools. So take this into account in the gcc script.
Change-Id: Iaf7eb5d969bd92617c622a164bf7a2db58675932
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Staring v4.18, Kconfig evaluates compiler capabilities, and hides CONFIG
options your compiler does not support. This works well if you configure
and build the kernel on the same host machine.
It is inconvenient if you prepare the .config that is carried to a
different build environment (typically this happens when you package
the kernel for distros) because using a different compiler potentially
produces different CONFIG options than the real build environment.
So, you probably want to make as many options visible as possible.
In other words, you need to create a super-set of CONFIG options that
cover any build environment. If some of the CONFIG options turned out
to be unsupported on the build machine, they are automatically disabled
by the nature of Kconfig.
However, it is not feasible to get a full-featured compiler for every
arch.
This issue was discussed here:
https://lkml.org/lkml/2019/12/9/620
Other than distros, savedefconfig is also a problem. Some arch sub-systems
periodically resync defconfig files. If you use a less-capable compiler
for savedefconfig, options that do not meet 'depends on $(cc-option,...)'
will be forcibly disabled. So, 'make defconfig && make savedefconfig'
may silently change the behavior.
This commit adds a set of dummy toolchains that pretend to support any
feature.
Most of compiler features are tested by cc-option, which simply checks
the exit code of $(CC). The dummy tools are shell scripts that always
exit with 0. So, $(cc-option, ...) is evaluated as 'y'.
There are more complicated checks such as:
scripts/gcc-x86_{32,64}-has-stack-protector.sh
scripts/gcc-plugin.sh
scripts/tools-support-relr.sh
scripts/dummy-tools/gcc passes all checks.
From the top directory of the source tree, you can do:
$ make CROSS_COMPILE=scripts/dummy-tools/ oldconfig
Change-Id: Ic0ed9f3c73888a14c38c5ce546bc171b479c35ed
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Tested-by: Jeremy Cline <jcline@redhat.com>
Change reason:to support the background speed limit function, we need to enable the configs as follow:
CONFIG_NET_SCH_PRIO=y [*]
CONFIG_NET_SCH_MULTIQ=y [*]
CONFIG_NET_SCH_TBF=y
CONFIG_NET_SCH_NETEM=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_FLOW=y
CONFIG_NET_EMATCH_CMP=y
CONFIG_NET_EMATCH_NBYTE=y
CONFIG_NET_EMATCH_META=y
CONFIG_NET_EMATCH_TEXT=y
CONFIG_NET_ACT_POLICE=y [*]
CONFIG_NET_ACT_GACT=y [*]
CONFIG_NET_ACT_MIRRED=y [*]
CONFIG_NET_ACT_SKBEDIT=y
[*] additionally enabled during backport to android11-5.4 to match 5.10+
Bug: 189705988
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: liuwei.a <liuwei.a@oppo.com>
Change-Id: I6f9a627bc2a2197b0da8a371ccd2a762b3147fc1
(cherry picked from commit da4b3a9637de63da6259e43bd4c0ead9504a8e40)
Currently, overlap calculation did not distinguish between ION and
non-ION buffers. This could result in incorrect offsets when an ION
buffer overlapped with a non-ION buffer, leading to out-of-bounds
writes and potential security issues. Calculate overlap ranges
separately for ION and non-ION buffers.
Change-Id: If5eb57d447b68d58d8821ecfbf2d9375b2cd1f8e
Signed-off-by: Ramesh Nallagopu <quic_rnallago@quicinc.com>
In case of unaligned start address and NOVA flag set, range validation
is by-passed. The page size calculated using unaligned address passed by
user is aligned to nearest boundary internally which returns page size
4KB more. In order to avoid out of bounds issue, check page range is within
map range.
Change-Id: Ie2de944206eee0730c8ba081f05b7d7cccc72276
Signed-off-by: Om Deore <quic_odeore@quicinc.com>
When deallocating dma-buf metadata in kgsl_destroy_ion, the priv_data
pointer in the associated kgsl_mem_entry structure is not reset after
kfree(). To avoid use after free, set entry->priv_data to NULL
immediately after freeing metadata.
Change-Id: Ia222d3a88666b7ee406f1508eb37a4eef766c83e
Signed-off-by: Shiv Kumar <shikum@qti.qualcomm.com>
Signed-off-by: Pankaj Gupta <gpankaj@qti.qualcomm.com>
This reverts commit 525fb1b48f.
Reason for revert: Breaks WiFi, likely needs additional changes to be
backported for it to work properly.
Change-Id: Ifc537c0dc80d759a9ab12671c7ff053ad6c31759
LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0
* tag 'LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0' of https://git.codelinaro.org/clo/la/platform/vendor/opensource/video-driver:
msm: vidc: Fix use after free in driver
msm: vidc: Enable hybrid mode only for HFR usecase
Change-Id: Ic2a5c64a04bcd2bed2c853f541255b7563d9b65c
LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0
* tag 'LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0' of https://git.codelinaro.org/clo/la/platform/vendor/opensource/dataipa:
ipa: Added changes to move the hdr entry to free list
msm: ipa: Avoid use-after-free scenario
Change-Id: I53d9b6e5cd83948d5a7cd67b8b7ffa58af13efef
LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0
* tag 'LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0' of https://git.codelinaro.org/clo/la/platform/vendor/opensource/audio-kernel:
asoc: lsm: thread safety issue in hw params management
asoc: lsm: Race condition protection in confidence levels handling
asoc: lsm: thread safety issue while accessing substream data
asoc: compress: race condition handling in stream cmd put function
asoc: handle heap overflow in effect driver
asoc: Update dai link for ACM8625S AMP.
asoc: Modification for 8ch capture
audio-kernel: Fix wcd938x DMIC unable to record
audio-kernel: Enable hdmi in audio function for AIO bar
dsp: q6adm: Checking array sizeof channel_type
asoc: codec: avoid out of bound write to map array
dsp: q6lsm: Check size of payload before access
Change-Id: I9eebb44e5b838891dc094853e28535930dee6b83
LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0
* tag 'LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0' of https://git.codelinaro.org/clo/la/platform/vendor/qcom-opensource/wlan/qcacld-3.0:
qcacld-3.0: Populate MBSSID cap in Ext CAP IE
Release 2.0.8.35G
qcacld-3.0: Fix underflow issue of beacon length
Release 2.0.8.35F
qcacld-3.0: don't overwrite psd_power flag if psd_set is true
qcacld-3.0: Add TPE IE EIRP power support for 6 GHz band
Release 2.0.8.35E
qcacld-3.0: Validate bw in lim calculate tpc
qcacld-3.0: Add Validation for WMA Handle and PSOC in Wake Event
Release 2.0.8.35D
qcacld-3.0: Add ini to apply RSSI delta for 6 GHz roam
Release 2.0.8.35C
qcacld-3.0: Update PMK from firmware for FT-SAE AKM also
Release 2.0.8.35B
qcacld-3.0: Rename variables name chan to chan_freq of wlan_hdd_mgmt_tx
qcacld-3.0: Fix mgmt tx from supplicant failed on 6 GHz chan
Release 2.0.8.35A
qcacld-3.0: Fix potential OOB memory access
Release 2.0.8.35
qcacld-3.0: Recalculate TX power post CSA
qcacld-3.0: Correcting the TSInfo structure size according to the Spec
qcacld-3.0: Fix the possible OOB write in country IE unpack
qcacld-3.0: Enhance the RSNXE inter-op logic
qcacld-3.0: Fix the AKM precedence order for RSN IE
qcacld-3.0: Update connect request crypto parameters
qcacld-3.0: Enable CFG80211_MULTI_AKM_CONNECT_SUPPORT from kernelv6.0
qcacld-3.0: Update wiphy max_num_akms_connect variable
Change-Id: I87412b74b79c527b7c867dd61b062ad38da8aab3
LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0
* tag 'LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0' of https://git.codelinaro.org/clo/la/platform/vendor/qcom-opensource/wlan/qca-wifi-host-cmn:
qcacmn: Validate vdev count before pdev CSA switch count update
qcacmn: Fix out of bounds read in extract_roam_scan_ap_stats_tlv
qcacmn: Update is_psd_power logic in reg get client pwr API
qcacmn: Keep counter atomicity while logging
qcacmn: Avoid OOB read in reg fill master channel API
qcacmn: Add macro to determine WPA3 AKM
qcacmn: Correct RSNXE capability indexes
Change-Id: I99ee7720aa22bc6dcfe52505d883498d767c7f09
Revert "reverting all USB patches"
This reverts commit 365834436c.
Conflicts:
drivers/usb/core/quirks.c
drivers/usb/dwc3/dwc3-qcom.c
drivers/usb/host/xhci-plat.c
drivers/usb/serial/option.c
Partially revert "reverting enum-conversion, Handle CPU state and all USB patches"
This partially reverts commit 2c3bda25f8.
Conflicts:
drivers/usb/core/quirks.c
drivers/usb/dwc3/gadget.c
drivers/usb/gadget/function/f_fs.c
drivers/usb/serial/option.c
Change-Id: I89f5ca04b3306fddb8b9ebd5382ec495ff9e1030
LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0
* tag 'LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0' of https://git.codelinaro.org/clo/la/kernel/msm-5.4:
msm:kgsl: Prevent sign extension on alignments
reverting all USB patches
msm: eva: OOB write issue in fence processing
kgsl: gmu: Use num_vma for safe GMU VMAs array access
net: Add netdevice notification for bridge activity
bridge: port structure members from 5.4 kernel
net: bridge: Fix for co-located mode
UPSTREAM: usb: gadget: configfs: Add frame-based frame format support
kgsl: Add buffer overflow check for perfcounter dynamic list
usb: gadget: uvc: Add grey and I420 YUV UVC format support
mtd: msm_qpic_nand: Use flash device ECC capability for erase page
mtd: msm_qpic_nand: check for page_erased bit along with op_err
UPSTREAM: usb: dwc3: Wait for EndXfer command completion
netfilter: fix NATTYPE refresh timeout issue
usb: gadget: uvc: Modify UVC_NUM_REQUESTS
reverting enum-conversion, Handle CPU state and all USB patches
msm: cvp: Fix for kernel address exposure vulnerability to user
cnss: Init reserved memory device
cnss: Dump stack by stack_trace_print
cnss: Add support for building CNSS as a loadable module
FROMLIST: media: venus: Add a check for packet size
Add configures to enable CNSS platform driver
FROMLIST: media: venus: Fix OOB read due to missing payload bound check
dma-mapping-fast: Fix PMD offset calculation for non-2M aligned start aperture
crypto: qcedev - fix UAF in crypto-qti driver
msm: adsprpc: Prevent refcount increment for duplicate dmahandles
dmaengine: msm_gpi: fix to avoid null pointer access
mdm: ipa3: support IPoGRE new IOCTL and proc params
msm: mhi_dev: Workqueue to handle host wakeup in M3+D0
iommu: Fix invalid access in av8l_fast_unmap_public
msm: mhi_dev: Handle host wakeup in M3/D0
msm: ep_pcie: Wake host in D3cold handling if wake is pending
FROMGIT: media: venus: hfi: add a check to handle OOB in sfr region
FROMGIT: media: venus: hfi: add check to handle incorrect queue size
FROMGIT: media: venus: hfi_parser: add check to avoid out of bound access
Revert "msm_ipa: Install exception rule for PPPoE-MPLS"
firmware: qcom_scm: do not clear dump mode from shutdown
msm: adsprpc: Avoid taking reference for group_info
adsprpc: Handle UAF scenario in put_args
msm: eva: Adding kref count for cvp_get_inst_from_id
wifi: cfg80211: Increase akm_suites array size in cfg80211_crypto_settings
thermal: qcom: Add support to update tsens trip based on nvmem data
Conflicts:
Makefile
arch/arm64/include/asm/cputype.h
drivers/char/adsprpc.c
drivers/hid/hid-ids.h
drivers/net/usb/rtl8150.c
drivers/platform/Kconfig
drivers/platform/Makefile
drivers/soc/qcom/mdt_loader.c
drivers/soc/qcom/rpmh-rsc.c
drivers/usb/core/quirks.c
drivers/usb/dwc3/dwc3-qcom.c
drivers/usb/dwc3/gadget.c
drivers/usb/gadget/function/f_fs.c
drivers/usb/gadget/function/f_ncm.c
mm/slub.c
mm/zsmalloc.c
net/ipv4/tcp_output.c
scripts/Makefile.extrawarn
Change-Id: Ia4f3356ed4a105a2f3b0feda3e78725a01a970b2
The commit 01ecebdbac6e ("BACKPORT: scripts/Makefile.clang: default to
LLVM_IAS=1") flipped LLVM_IAS to opt-out but did not update the
ifneq ($(LLVM_IAS),1) condition introduced by 2f5d594440ac ("FROMLIST:
Kbuild: do not emit debug info for assembly with LLVM_IAS=1"), causing
warnings when LLVM_IAS is unset:
warning: DWARF2 only supports one section per compilation unit
Fixes: 01ecebdbac6e ("BACKPORT: scripts/Makefile.clang: default to LLVM_IAS=1")
Change-Id: If373071466d851ee8d814751f9bc4672e68aaf34
Check for potential overflow before using the ALIGN macro,
as it is not overflow-safe.
Change-Id: Iffa1b7a01a9e072fb748c93f6625d0f1a163d0f8
Signed-off-by: Anandu Krishnan E <quic_anane@quicinc.com>
(cherry picked from commit 96a6c4a8768f73ba9041c15511f0d5888507c8f4)
Reason for revert: This commit was not needed on 5.10 and above.
This reverts commit 55bac51762.
Change-Id: I552769bda33fb27fcd32de5191ab0f45fb7f2efa
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
commit ead7f9b8de65632ef8060b84b0c55049a33cfea1 upstream.
In Cilium, we use bpf_csum_diff + bpf_l4_csum_replace to, among other
things, update the L4 checksum after reverse SNATing IPv6 packets. That
use case is however not currently supported and leads to invalid
skb->csum values in some cases. This patch adds support for IPv6 address
changes in bpf_l4_csum_update via a new flag.
When calling bpf_l4_csum_replace in Cilium, it ends up calling
inet_proto_csum_replace_by_diff:
1: void inet_proto_csum_replace_by_diff(__sum16 *sum, struct sk_buff *skb,
2: __wsum diff, bool pseudohdr)
3: {
4: if (skb->ip_summed != CHECKSUM_PARTIAL) {
5: csum_replace_by_diff(sum, diff);
6: if (skb->ip_summed == CHECKSUM_COMPLETE && pseudohdr)
7: skb->csum = ~csum_sub(diff, skb->csum);
8: } else if (pseudohdr) {
9: *sum = ~csum_fold(csum_add(diff, csum_unfold(*sum)));
10: }
11: }
The bug happens when we're in the CHECKSUM_COMPLETE state. We've just
updated one of the IPv6 addresses. The helper now updates the L4 header
checksum on line 5. Next, it updates skb->csum on line 7. It shouldn't.
For an IPv6 packet, the updates of the IPv6 address and of the L4
checksum will cancel each other. The checksums are set such that
computing a checksum over the packet including its checksum will result
in a sum of 0. So the same is true here when we update the L4 checksum
on line 5. We'll update it as to cancel the previous IPv6 address
update. Hence skb->csum should remain untouched in this case.
The same bug doesn't affect IPv4 packets because, in that case, three
fields are updated: the IPv4 address, the IP checksum, and the L4
checksum. The change to the IPv4 address and one of the checksums still
cancel each other in skb->csum, but we're left with one checksum update
and should therefore update skb->csum accordingly. That's exactly what
inet_proto_csum_replace_by_diff does.
This special case for IPv6 L4 checksums is also described atop
inet_proto_csum_replace16, the function we should be using in this case.
This patch introduces a new bpf_l4_csum_replace flag, BPF_F_IPV6,
to indicate that we're updating the L4 checksum of an IPv6 packet. When
the flag is set, inet_proto_csum_replace_by_diff will skip the
skb->csum update.
Fixes: 7d672345ed ("bpf: add generic bpf_csum_diff helper")
Change-Id: Ief7e9d62380eb344a218a149cda3dfeeaf568ae6
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://patch.msgid.link/96a6bc3a443e6f0b21ff7b7834000e17fb549e05.1748509484.git.paul.chaignon@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[ Note: Fixed conflict due to unrelated comment change. ]
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
commit 6043b794c7668c19dabc4a93c75b924a19474d59 upstream.
During ILA address translations, the L4 checksums can be handled in
different ways. One of them, adj-transport, consist in parsing the
transport layer and updating any found checksum. This logic relies on
inet_proto_csum_replace_by_diff and produces an incorrect skb->csum when
in state CHECKSUM_COMPLETE.
This bug can be reproduced with a simple ILA to SIR mapping, assuming
packets are received with CHECKSUM_COMPLETE:
$ ip a show dev eth0
14: eth0@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 62:ae:35:9e:0f:8d brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 3333:0:0:1::c078/64 scope global
valid_lft forever preferred_lft forever
inet6 fd00:10:244:1::c078/128 scope global nodad
valid_lft forever preferred_lft forever
inet6 fe80::60ae:35ff:fe9e:f8d/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
$ ip ila add loc_match fd00:10:244:1 loc 3333:0:0:1 \
csum-mode adj-transport ident-type luid dev eth0
Then I hit [fd00:10:244:1::c078]:8000 with a server listening only on
[3333:0:0:1::c078]:8000. With the bug, the SYN packet is dropped with
SKB_DROP_REASON_TCP_CSUM after inet_proto_csum_replace_by_diff changed
skb->csum. The translation and drop are visible on pwru [1] traces:
IFACE TUPLE FUNC
eth0:9 [fd00:10:244:3::3d8]:51420->[fd00:10:244:1::c078]:8000(tcp) ipv6_rcv
eth0:9 [fd00:10:244:3::3d8]:51420->[fd00:10:244:1::c078]:8000(tcp) ip6_rcv_core
eth0:9 [fd00:10:244:3::3d8]:51420->[fd00:10:244:1::c078]:8000(tcp) nf_hook_slow
eth0:9 [fd00:10:244:3::3d8]:51420->[fd00:10:244:1::c078]:8000(tcp) inet_proto_csum_replace_by_diff
eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) tcp_v6_early_demux
eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) ip6_route_input
eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) ip6_input
eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) ip6_input_finish
eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) ip6_protocol_deliver_rcu
eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) raw6_local_deliver
eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) ipv6_raw_deliver
eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) tcp_v6_rcv
eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) __skb_checksum_complete
eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) kfree_skb_reason(SKB_DROP_REASON_TCP_CSUM)
eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) skb_release_head_state
eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) skb_release_data
eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) skb_free_head
eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) kfree_skbmem
This is happening because inet_proto_csum_replace_by_diff is updating
skb->csum when it shouldn't. The L4 checksum is updated such that it
"cancels" the IPv6 address change in terms of checksum computation, so
the impact on skb->csum is null.
Note this would be different for an IPv4 packet since three fields
would be updated: the IPv4 address, the IP checksum, and the L4
checksum. Two would cancel each other and skb->csum would still need
to be updated to take the L4 checksum change into account.
This patch fixes it by passing an ipv6 flag to
inet_proto_csum_replace_by_diff, to skip the skb->csum update if we're
in the IPv6 case. Note the behavior of the only other user of
inet_proto_csum_replace_by_diff, the BPF subsystem, is left as is in
this patch and fixed in the subsequent patch.
With the fix, using the reproduction from above, I can confirm
skb->csum is not touched by inet_proto_csum_replace_by_diff and the TCP
SYN proceeds to the application after the ILA translation.
Link: https://github.com/cilium/pwru [1]
Fixes: 65d7ab8de5 ("net: Identifier Locator Addressing module")
Change-Id: Iff2bd64e26b7e318f3d580070ffc20d44bf630b2
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://patch.msgid.link/b5539869e3550d46068504feb02d37653d939c0b.1748509484.git.paul.chaignon@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[ Fixed conflict due to unrelated change in inet_proto_csum_replace_by_diff. ]
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
migrate_disable() is just a wrapper for preempt_disable() in
non-RT kernel. It is safe to replace it, and RT kernel will
benefit.
Note that it is introduced since Feb 2020.
Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Change-Id: I1365390ddebc37532188ebaadfe3289836b746ff
Signed-off-by: Cong Wang <cong.wang@bytedance.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20201205075946.497763-2-xiyou.wangcong@gmail.com
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
Also add a few missing things. (no functional change)
Change-Id: I5d29028ffdacb08afcde396543145e9cf21cb6fe
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
__bpfilter_process_sockopt never initialized the pos variable passed
to the pipe write. This has been mostly harmless in the past as pipes
ignore the offset, but the switch to kernel_write now verified the
position, which can lead to a failure depending on the exact stack
initialization pattern. Initialize the variable to zero to make
rw_verify_area happy.
Fixes: 6955a76fbcd5 ("bpfilter: switch to kernel_write")
Reported-by: Christian Brauner <christian.brauner@ubuntu.com>
Reported-by: Rodrigo Madera <rodrigo.madera@gmail.com>
Change-Id: I8881e10460784cece6b2a2338c1b418adf99965e
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Rodrigo Madera <rodrigo.madera@gmail.com>
Tested-by: Christian Brauner <christian.brauner@ubuntu.com>
Reviewed-by: Christian Brauner <christian.brauner@ubuntu.com>
Link: https://lore.kernel.org/bpf/20200730160900.187157-1-hch@lst.de
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
This is mostly to prepare for cleaning up the callers, as bpfilter by
design can't handle kernel pointers.
Change-Id: I2696c789576b662bcf3849b718a2b06b0a5a37a5
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
The bpfilter user mode helper processes the optval address using
process_vm_readv. Don't send it kernel addresses fed under
set_fs(KERNEL_DS) as that won't work.
Change-Id: Ifa43c1bea055758b57c5b0a7e46d36036dd09daf
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
Split __bpfilter_process_sockopt into a low-level send request routine and
the actual setsockopt hook to split the init time ping from the actual
setsockopt processing.
Change-Id: Ic1f2d56c8a714739a88672bd4e4d75d2b17ba415
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
The __user doesn't make sense when casting to an integer type, just
switch to a uintptr_t cast which also removes the need for the __force.
Change-Id: I12ac2ad1687b213037bd77db602350df40e144ce
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
Originally, bpfilter_umh was linked with -static only when
CONFIG_BPFILTER_UMH=y.
Commit 8a2cc0505cc4 ("bpfilter: use 'userprogs' syntax to build
bpfilter_umh") silently, accidentally dropped the CONFIG_BPFILTER_UMH=y
test in the Makefile. Revive it in order to link it dynamically when
CONFIG_BPFILTER_UMH=m.
Since commit b1183b6dca3e ("bpfilter: check if $(CC) can link static
libc in Kconfig"), the compiler must be capable of static linking to
enable CONFIG_BPFILTER_UMH, but it requires more than needed.
To loosen the compiler requirement, I changed the dependency as follows:
depends on CC_CAN_LINK
depends on m || CC_CAN_LINK_STATIC
If CONFIG_CC_CAN_LINK_STATIC in unset, CONFIG_BPFILTER_UMH is restricted
to 'm' or 'n'.
In theory, CONFIG_CC_CAN_LINK is not required for CONFIG_BPFILTER_UMH=y,
but I did not come up with a good way to describe it.
Fixes: 8a2cc0505cc4 ("bpfilter: use 'userprogs' syntax to build bpfilter_umh")
Reported-by: Michal Kubecek <mkubecek@suse.cz>
Change-Id: I2341985feef30c977f7562be1aab28457c88964f
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Tested-by: Michal Kubecek <mkubecek@suse.cz>
Link: https://lore.kernel.org/bpf/20200701092644.762234-1-masahiroy@kernel.org
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
