Add a vendor hook after attaching a task to a cgroup to
recognize the group_id for performance tuning
Bug: 181917687
Signed-off-by: Frankie Chang <frankie.chang@mediatek.com>
Change-Id: I603afa3d893dd575a7dcb97f83bd9eacb8315bab
(cherry picked from commit bed1e2a75b0000d99a00177272b93e5c8430308b)
./build/config.sh provides Kbuild's configuration editor in kernel/build
environment, plus support for editing config fragments. Set
FRAGMENT_CONFIG for ./build/config.sh.
Bug: 169398826
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
[jstultz: Dropped sorting the config fragment]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: Id09967bb06d0652788d17373ade2619a310c9e87
move hook to collect scheduling information and apply vendor's
tuning before task's scheduling priority is changed
Bug: 163431711
Signed-off-by: Frankie Chang <frankie.chang@mediatek.com>
Change-Id: I61a7ab663316c0fbcb28d1b6e523649a6374b492
(cherry picked from commit 5cf5bc7523bd5608590de487de896c1026161a18)
In 5.4.102 the icmpv6_send() was replaced with an inline function.
Bring it back to provide for modules that used this symbol to preserve
the ABI.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id1a914518f6e850f6bb96b5449c15eda3a7a7fd8
commit ee576c47db60432c37e54b1e2b43a8ca6d3a8dca upstream.
The icmp{,v6}_send functions make all sorts of use of skb->cb, casting
it with IPCB or IP6CB, assuming the skb to have come directly from the
inet layer. But when the packet comes from the ndo layer, especially
when forwarded, there's no telling what might be in skb->cb at that
point. As a result, the icmp sending code risks reading bogus memory
contents, which can result in nasty stack overflows such as this one
reported by a user:
panic+0x108/0x2ea
__stack_chk_fail+0x14/0x20
__icmp_send+0x5bd/0x5c0
icmp_ndo_send+0x148/0x160
In icmp_send, skb->cb is cast with IPCB and an ip_options struct is read
from it. The optlen parameter there is of particular note, as it can
induce writes beyond bounds. There are quite a few ways that can happen
in __ip_options_echo. For example:
// sptr/skb are attacker-controlled skb bytes
sptr = skb_network_header(skb);
// dptr/dopt points to stack memory allocated by __icmp_send
dptr = dopt->__data;
// sopt is the corrupt skb->cb in question
if (sopt->rr) {
optlen = sptr[sopt->rr+1]; // corrupt skb->cb + skb->data
soffset = sptr[sopt->rr+2]; // corrupt skb->cb + skb->data
// this now writes potentially attacker-controlled data, over
// flowing the stack:
memcpy(dptr, sptr+sopt->rr, optlen);
}
In the icmpv6_send case, the story is similar, but not as dire, as only
IP6CB(skb)->iif and IP6CB(skb)->dsthao are used. The dsthao case is
worse than the iif case, but it is passed to ipv6_find_tlv, which does
a bit of bounds checking on the value.
This is easy to simulate by doing a `memset(skb->cb, 0x41,
sizeof(skb->cb));` before calling icmp{,v6}_ndo_send, and it's only by
good fortune and the rarity of icmp sending from that context that we've
avoided reports like this until now. For example, in KASAN:
BUG: KASAN: stack-out-of-bounds in __ip_options_echo+0xa0e/0x12b0
Write of size 38 at addr ffff888006f1f80e by task ping/89
CPU: 2 PID: 89 Comm: ping Not tainted 5.10.0-rc7-debug+ #5
Call Trace:
dump_stack+0x9a/0xcc
print_address_description.constprop.0+0x1a/0x160
__kasan_report.cold+0x20/0x38
kasan_report+0x32/0x40
check_memory_region+0x145/0x1a0
memcpy+0x39/0x60
__ip_options_echo+0xa0e/0x12b0
__icmp_send+0x744/0x1700
Actually, out of the 4 drivers that do this, only gtp zeroed the cb for
the v4 case, while the rest did not. So this commit actually removes the
gtp-specific zeroing, while putting the code where it belongs in the
shared infrastructure of icmp{,v6}_ndo_send.
This commit fixes the issue by passing an empty IPCB or IP6CB along to
the functions that actually do the work. For the icmp_send, this was
already trivial, thanks to __icmp_send providing the plumbing function.
For icmpv6_send, this required a tiny bit of refactoring to make it
behave like the v4 case, after which it was straight forward.
Fixes: a2b78e9b2c ("sunvnet: generate ICMP PTMUD messages for smaller port MTUs")
Reported-by: SinYu <liuxyon@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://lore.kernel.org/netdev/CAF=yD-LOF116aHub6RMe8vB8ZpnrrnoTdqhobEx+bvoA8AsP0w@mail.gmail.com/T/
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Link: https://lore.kernel.org/r/20210223131858.72082-1-Jason@zx2c4.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 9875cb3c09)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5ca6554f162b3d64d2c4aad80c3382089b2438a4
commit 1faba27f11c8da244e793546a1b35a9b1da8208e upstream.
The W=1 compilation of allmodconfig generates the following warning:
net/ipv6/icmp.c:448:6: warning: no previous prototype for 'icmp6_send' [-Wmissing-prototypes]
448 | void icmp6_send(struct sk_buff *skb, u8 type, u8 code, __u32 info,
| ^~~~~~~~~~
Fix it by providing function declaration for builds with ipv6 as a module.
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 354fb7244f)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I2d4f57e63640c18bf93c103da0a3b72c67152ed6
commit cc7a21b6fbd945f8d8f61422ccd27203c1fafeb7 upstream.
If IPv6 is builtin, we do not need an expensive indirect call
to reach icmp6_send().
v2: put inline keyword before the type to avoid sparse warnings.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e528edf1e5)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0d19f581c6360b4317e6934972845f6a39203de5
commit 45942ba890e6f35232727a5fa33d732681f4eb9f upstream.
Because xfrmi is calling icmp from network device context, it should use
the ndo helper so that the rate limiting applies correctly.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c30e93eee3)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I404cf4d493272eefd88c28b65712bca5f5e12744
commit 67c9a7e1e3ac491b5df018803639addc36f154ba upstream.
Because sunvnet is calling icmp from network device context, it should use
the ndo helper so that the rate limiting applies correctly. While we're
at it, doing the additional route lookup before calling icmp_ndo_send is
superfluous, since this is the job of the icmp code in the first place.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e1ec06b833)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia0ae7b14d4785c83547824563edb019c30cda79f
commit e0fce6f945a26d4e953a147fe7ca11410322c9fe upstream.
Because gtp is calling icmp from network device context, it should use
the ndo helper so that the rate limiting applies correctly.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Harald Welte <laforge@gnumonks.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit d8d268ce1a)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I87cecb7368e63ad10a3a6a43d990797997019f92
commit a8e41f6033a0c5633d55d6e35993c9e2005d872f upstream.
The icmpv6_send function has long had a static inline implementation
with an empty body for CONFIG_IPV6=n, so that code calling it doesn't
need to be ifdef'd. The new icmpv6_ndo_send function, which is intended
for drivers as a drop-in replacement with an identical function
signature, should follow the same pattern. Without this patch, drivers
that used to work with CONFIG_IPV6=n now result in a linker error.
Cc: Chen Zhou <chenzhou10@huawei.com>
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 0b41713b6066 ("icmp: introduce helper for nat'd source address in network device context")
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit dd28e735df)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I4f30fef204264bd40c432e5e5408495b87e02d03
commit 0b41713b606694257b90d61ba7e2712d8457648b upstream.
This introduces a helper function to be called only by network drivers
that wraps calls to icmp[v6]_send in a conntrack transformation, in case
NAT has been used. We don't want to pollute the non-driver path, though,
so we introduce this as a helper to be called by places that actually
make use of this, as suggested by Florian.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 2019554f96)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iec63f040ae2d82f3dc4bf1cd303a773e2e551b92
Bug: 177075428
Test: incfs_test passes
atest GtsIncrementalInstallTestCases has only 8 failures
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I73accfc1982aec1cd7947996c25a23e4a97cfdac
Bug: 174692664
Test: incfs_test passes, incremental installs work with ag/13082306
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Ib1c924bbaff759f58f7d83bad8e23d7224ba7ed9
Add config settings to enable wifi via modules on db845c
Bug: 146449535
Change-Id: I81892c4cc48db7839fe99aa5fb0b0a0782cab321
Signed-off-by: John Stultz <john.stultz@linaro.org>
commit ef8576789e869b7584684ae81126a465eb1deeb6 upstream.
Add a node describing the watchdog found in the application subsystem.
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
(cherry picked from commit ef8576789e869b7584684ae81126a465eb1deeb6)
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: I835d512c13c392e356c5190e865c0617e97041c2
The redistributable firmware should work on any engineering device, so
lets push this to qcom/sdm845, rather than qcom/db845c. Also specify the
path for the modem firmware.
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20191113203951.3704428-1-bjorn.andersson@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
(cherry picked from commit 82b1cc447a2c7c5121ce34f15f9840110ee3499f)
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: Ica785dd7faee17dce933379dbb6ada32a3697bdb
commit b70b3a36ec33a2c8d3292f3b33fe2047a8f57b9a upstream.
Unless we sleep for a while before transitioning the MSA memory to WLAN
the MPSS.AT.4.0.c2-01184-SDM845_GEN_PACK-1 firmware triggers a security
violation fairly reliably. Unforutnately recovering from this failure
always results in the entire system freezing.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit b70b3a36ec33a2c8d3292f3b33fe2047a8f57b9a)
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: Ie44e86d404f1897b7cc349a03972178374fef89c
If a client comes up early in the boot process (perhaps was a built-in
driver), qmi_handle_init() will likely fail with a EAFNOSUPPORT since the
underlying ipc router hasn't init'd and registered the address family.
This should not be a fatal error since chances are, the router will come
up later, so recode the error to EPROBE_DEFER so that clients will retry
later.
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Link: https://lore.kernel.org/r/20191106230511.1290-1-jeffrey.l.hugo@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
(cherry picked from commit 52af26e33e700158e6549f1465fcf9da099fabfa)
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: I26a0dabe9b1f3b8e9cc793f7f52ee8f658ecdce3
Add the following symbols to QCOM allowed-list:
-- pcie_bus_configure_settings
Bug: 180475310
Change-Id: I49ed1ada673a9199370344cf2b89d7369f92d3f2
Signed-off-by: Tony Truong <truong@codeaurora.org>
This merges the 5.4.86 upstream LTS release into the android11-5.4
branch so that all devices can get the needed important security and
other bugfixes that are in here. All devices must upgrade to remain
properly secure from known issues.
Bug: 180469075
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1041e0d08d55a3eb2e0f49b7d2384960f48d9b11
Update the android/abi_gki_aarch64_qcom with recent symbol additions.
No need to update the .xml file, as no new symbol addition.
Bug: 180426964
Signed-off-by: Raviteja Tamatam <travitej@codeaurora.org>
Change-Id: I301d36b0385756d6cfd5924c2655d5b728637a24
CONFIG_KASAN_PANIC_ON_WARN was added in a custom patch for Pixel kernels,
which would make KASAN panic the kernel after the first report regardless
of whether the panic_on_warn parameter is set. (Coincidentally, that patch
also would break instrumentation mode selection for KASAN.)
As that patch was never applied to the common kernel,
CONFIG_KASAN_PANIC_ON_WARN doesn't exist here. This change drops the
non-existent CONFIG_KASAN_PANIC_ON_WARN from build.config.gki_kasan.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Change-Id: I9f42bb5f3515f18e2a5774241ea73a59d8883955
On a device like a cellphone which is constantly suspending
and resuming CLOCK_MONOTONIC is not particularly useful for
keeping track of or reacting to external network events.
Instead you want to use CLOCK_BOOTTIME.
Hence add bpf_ktime_get_boot_ns() as a mirror of bpf_ktime_get_ns()
based around CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
(cherry picked from commit 71d19214776e61b33da48f7c1b46e522c7f78221)
Change-Id: Ifd62c410dcc5112fd1a473a7e1f70231ca514bc0
Update the android/abi_gki_aarch64_qcom with recent symbol additions.
Simple change and no need to update the .xml file, as no new symbol
addition.
Bug: 179747683
Signed-off-by: Neeraja P <neerp@codeaurora.org>
Signed-off-by: Kamal Agrawal <kamaagra@codeaurora.org>
Change-Id: I1d5252ed623f83611a5b064a8e0e33e4f0d188c5
Export clk_hw_register_composite() to support user built as module.
ERROR: modpost: "clk_hw_register_composite" [drivers/clk/imx/mxc-clk.ko]
undefined!
(cherry picked from commit d7d7518fdcc8f43da69fb40073273e77f24be24f)
[Jindong: Resolved minor conflict in drivers/clk/clk-composite.c ]
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Jindong Yue <jindong.yue@nxp.com>
Change-Id: I54496d44d4bf6599af3a3ec9c40c02556d55cf17
Several symbols in DesignWare PCI Core driver are used
to support PCIe controller work at Endpoint Mode.
Export them to support such driver built as module.
Bug: 159736148
Signed-off-by: Jindong Yue <jindong.yue@nxp.com>
Change-Id: I2c77bfbfbec750ecdf21f0cd1bbb20fe339a2f0c
commit 34b1a1ce1458f50ef27c54e28eb9b1947012907a upstream
fixup_pi_state_owner() tries to ensure that the state of the rtmutex,
pi_state and the user space value related to the PI futex are consistent
before returning to user space. In case that the user space value update
faults and the fault cannot be resolved by faulting the page in via
fault_in_user_writeable() the function returns with -EFAULT and leaves
the rtmutex and pi_state owner state inconsistent.
A subsequent futex_unlock_pi() operates on the inconsistent pi_state and
releases the rtmutex despite not owning it which can corrupt the RB tree of
the rtmutex and cause a subsequent kernel stack use after free.
It was suggested to loop forever in fixup_pi_state_owner() if the fault
cannot be resolved, but that results in runaway tasks which is especially
undesired when the problem happens due to a programming error and not due
to malice.
As the user space value cannot be fixed up, the proper solution is to make
the rtmutex and the pi_state consistent so both have the same owner. This
leaves the user space value out of sync. Any subsequent operation on the
futex will fail because the 10th rule of PI futexes (pi_state owner and
user space value are consistent) has been violated.
As a consequence this removes the inept attempts of 'fixing' the situation
in case that the current task owns the rtmutex when returning with an
unresolvable fault by unlocking the rtmutex which left pi_state::owner and
rtmutex::owner out of sync in a different and only slightly less dangerous
way.
Fixes: 1b7558e457 ("futexes: fix fault handling in futex_lock_pi")
Reported-by: gzobqq@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 34b1a1ce1458f50ef27c54e28eb9b1947012907a)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iabd44dad5d4b8385b8a20e44d18308708cc3b701
commit f2dac39d93987f7de1e20b3988c8685523247ae2 upstream
Too many gotos already and an upcoming fix would make it even more
unreadable.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f2dac39d93987f7de1e20b3988c8685523247ae2)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5a97587c0f696d4f4b849f7f106990a5587fa402
commit 6ccc84f917d33312eb2846bd7b567639f585ad6d upstream
No point in open coding it. This way it gains the extra sanity checks.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6ccc84f917d33312eb2846bd7b567639f585ad6d)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ic34513518cd4996b3eb4cb82b669d727be522597
commit 2156ac1934166d6deb6cd0f6ffc4c1076ec63697 upstream
Nothing uses the argument. Remove it as preparation to use
pi_state_update_owner().
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 2156ac1934166d6deb6cd0f6ffc4c1076ec63697)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I126088d93c5f05db654e508dfd4195e5c1696164
commit c5cade200ab9a2a3be9e7f32a752c8d86b502ec7 upstream
Updating pi_state::owner is done at several places with the same
code. Provide a function for it and use that at the obvious places.
This is also a preparation for a bug fix to avoid yet another copy of the
same code or alternatively introducing a completely unpenetratable mess of
gotos.
Originally-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c5cade200ab9a2a3be9e7f32a752c8d86b502ec7)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I17a67806a035338a55b27eea673d707fc4d8c529
commit 04b79c55201f02ffd675e1231d731365e335c307 upstream
If that unexpected case of inconsistent arguments ever happens then the
futex state is left completely inconsistent and the printk is not really
helpful. Replace it with a warning and make the state consistent.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 04b79c55201f02ffd675e1231d731365e335c307)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I32bd64130d9414f65155ecd80646d01eb4374a60
commit 12bb3f7f1b03d5913b3f9d4236a488aa7774dfe9 upstream
In case that futex_lock_pi() was aborted by a signal or a timeout and the
task returned without acquiring the rtmutex, but is the designated owner of
the futex due to a concurrent futex_unlock_pi() fixup_owner() is invoked to
establish consistent state. In that case it invokes fixup_pi_state_owner()
which in turn tries to acquire the rtmutex again. If that succeeds then it
does not propagate this success to fixup_owner() and futex_lock_pi()
returns -EINTR or -ETIMEOUT despite having the futex locked.
Return success from fixup_pi_state_owner() in all cases where the current
task owns the rtmutex and therefore the futex and propagate it correctly
through fixup_owner(). Fixup the other callsite which does not expect a
positive return value.
Fixes: c1e2f0eaf0 ("futex: Avoid violating the 10th rule of futex")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 12bb3f7f1b03d5913b3f9d4236a488aa7774dfe9)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6dfb7407620fdf8293edbfbe54463f0c8ff63a57
commit 757fed1d0898b893d7daa84183947c70f27632f3 upstream.
This reverts commit dde3c6b72a16c2db826f54b2d49bdea26c3534a2.
syzbot report a double-free bug. The following case can cause this bug.
- mm/slab_common.c: create_cache(): if the __kmem_cache_create() fails,
it does:
out_free_cache:
kmem_cache_free(kmem_cache, s);
- but __kmem_cache_create() - at least for slub() - will have done
sysfs_slab_add(s)
-> sysfs_create_group() .. fails ..
-> kobject_del(&s->kobj); .. which frees s ...
We can't remove the kmem_cache_free() in create_cache(), because other
error cases of __kmem_cache_create() do not free this.
So, revert the commit dde3c6b72a16 ("mm/slub: fix a memory leak in
sysfs_slab_add()") to fix this.
Reported-by: syzbot+d0bd96b4696c1ef67991@syzkaller.appspotmail.com
Fixes: dde3c6b72a16 ("mm/slub: fix a memory leak in sysfs_slab_add()")
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 757fed1d0898b893d7daa84183947c70f27632f3)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3743749e527dddde63620ac16a0db66c475ac404
commit 1e106aa3509b86738769775969822ffc1ec21bf4 upstream.
The exit_pi_state_list() function calls put_pi_state() with IRQs disabled
and is not expecting that IRQs will be enabled inside the function.
Use the _irqsave() variant so that IRQs are restored to the original state
instead of being enabled unconditionally.
Fixes: 153fbd1226 ("futex: Fix more put_pi_state() vs. exit_pi_state_list() races")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201106085205.GA1159983@mwanda
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 2192d905df)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I10bc011b54ffc6d66c0a499ecebfa5b2d96d58ce
commit 9f5d1c336a10c0d24e83e40b4c1b9539f7dba627 upstream.
Gratian managed to trigger the BUG_ON(!newowner) in fixup_pi_state_owner().
This is one possible chain of events leading to this:
Task Prio Operation
T1 120 lock(F)
T2 120 lock(F) -> blocks (top waiter)
T3 50 (RT) lock(F) -> boosts T1 and blocks (new top waiter)
XX timeout/ -> wakes T2
signal
T1 50 unlock(F) -> wakes T3 (rtmutex->owner == NULL, waiter bit is set)
T2 120 cleanup -> try_to_take_mutex() fails because T3 is the top waiter
and the lower priority T2 cannot steal the lock.
-> fixup_pi_state_owner() sees newowner == NULL -> BUG_ON()
The comment states that this is invalid and rt_mutex_real_owner() must
return a non NULL owner when the trylock failed, but in case of a queued
and woken up waiter rt_mutex_real_owner() == NULL is a valid transient
state. The higher priority waiter has simply not yet managed to take over
the rtmutex.
The BUG_ON() is therefore wrong and this is just another retry condition in
fixup_pi_state_owner().
Drop the locks, so that T3 can make progress, and then try the fixup again.
Gratian provided a great analysis, traces and a reproducer. The analysis is
to the point, but it confused the hell out of that tglx dude who had to
page in all the futex horrors again. Condensed version is above.
[ tglx: Wrote comment and changelog ]
Fixes: c1e2f0eaf0 ("futex: Avoid violating the 10th rule of futex")
Reported-by: Gratian Crisan <gratian.crisan@ni.com>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/87a6w6x7bb.fsf@ni.com
Link: https://lore.kernel.org/r/87sg9pkvf7.fsf@nanos.tec.linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 2716e78a64)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9ab0878641624448cacb1951506b5accb4c92a00
[ Upstream commit 921c7ebd1337d1a46783d7e15a850e12aed2eaa0 ]
If should_futex_fail() returns true in futex_wake_pi(), then the 'ret'
variable is set to -EFAULT and then immediately overwritten. So the failure
injection is non-functional.
Fix it by actually leaving the function and returning -EFAULT.
The Fixes tag is kinda blury because the initial commit which introduced
failure injection was already sloppy, but the below mentioned commit broke
it completely.
[ tglx: Massaged changelog ]
Fixes: 6b4f4bc9cb ("locking/futex: Allow low-level atomic operations to return -EAGAIN")
Signed-off-by: Mateusz Nosek <mateusznosek0@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20200927000858.24219-1-mateusznosek0@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 2db7590371)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I22198b7a65630cb5649f3e889810783b147bfada
