commit 16d51a590a upstream.
When going through execve(), zero out the NUMA fault statistics instead of
freeing them.
During execve, the task is reachable through procfs and the scheduler. A
concurrent /proc/*/sched reader can read data from a freed ->numa_faults
allocation (confirmed by KASAN) and write it back to userspace.
I believe that it would also be possible for a use-after-free read to occur
through a race between a NUMA fault and execve(): task_numa_fault() can
lead to task_numa_compare(), which invokes task_weight() on the currently
running task of a different CPU.
Another way to fix this would be to make ->numa_faults RCU-managed or add
extra locking, but it seems easier to wipe the NUMA fault statistics on
execve.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will@kernel.org>
Fixes: 82727018b0 ("sched/numa: Call task_numa_free() from do_execve()")
Link: https://lkml.kernel.org/r/20190716152047.14424-1-jannh@google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d7852fbd0f upstream.
It turns out that 'access()' (and 'faccessat()') can cause a lot of RCU
work because it installs a temporary credential that gets allocated and
freed for each system call.
The allocation and freeing overhead is mostly benign, but because
credentials can be accessed under the RCU read lock, the freeing
involves a RCU grace period.
Which is not a huge deal normally, but if you have a lot of access()
calls, this causes a fair amount of seconday damage: instead of having a
nice alloc/free patterns that hits in hot per-CPU slab caches, you have
all those delayed free's, and on big machines with hundreds of cores,
the RCU overhead can end up being enormous.
But it turns out that all of this is entirely unnecessary. Exactly
because access() only installs the credential as the thread-local
subjective credential, the temporary cred pointer doesn't actually need
to be RCU free'd at all. Once we're done using it, we can just free it
synchronously and avoid all the RCU overhead.
So add a 'non_rcu' flag to 'struct cred', which can be set by users that
know they only use it in non-RCU context (there are other potential
users for this). We can make it a union with the rcu freeing list head
that we need for the RCU case, so this doesn't need any extra storage.
Note that this also makes 'get_current_cred()' clear the new non_rcu
flag, in case we have filesystems that take a long-term reference to the
cred and then expect the RCU delayed freeing afterwards. It's not
entirely clear that this is required, but it makes for clear semantics:
the subjective cred remains non-RCU as long as you only access it
synchronously using the thread-local accessors, but you _can_ use it as
a generic cred if you want to.
It is possible that we should just remove the whole RCU markings for
->cred entirely. Only ->real_cred is really supposed to be accessed
through RCU, and the long-term cred copies that nfs uses might want to
explicitly re-enable RCU freeing if required, rather than have
get_current_cred() do it implicitly.
But this is a "minimal semantic changes" change for the immediate
problem.
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Paul E. McKenney <paulmck@linux.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Jan Glauber <jglauber@marvell.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Jayachandran Chandrasekharan Nair <jnair@marvell.com>
Cc: Greg KH <greg@kroah.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 7f1e541fc8 ]
Sometimes we know that it's safe to do potentially out-of-bounds access
because we know it won't cross a page boundary. Still, KASAN will
report this as a bug.
Add read_word_at_a_time() function which is supposed to be used in such
cases. In read_word_at_a_time() KASAN performs relaxed check - only the
first byte of access is validated.
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit bdb5ac801a ]
Instead of having two identical __read_once_size_nocheck() functions
with different attributes, consolidate all the difference in new macro
__no_kasan_or_inline and use it. No functional changes.
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 6282edb72b ]
Exynos SoCs based on CA7/CA15 have 2 timer interfaces: custom Exynos MCT
(Multi Core Timer) and standard ARM Architected Timers.
There are use cases, where both timer interfaces are used simultanously.
One of such examples is using Exynos MCT for the main system timer and
ARM Architected Timers for the KVM and virtualized guests (KVM requires
arch timers).
Exynos Multi-Core Timer driver (exynos_mct) must be however started
before ARM Architected Timers (arch_timer), because they both share some
common hardware blocks (global system counter) and turning on MCT is
needed to get ARM Architected Timer working properly.
To ensure selecting Exynos MCT as the main system timer, increase MCT
timer rating. To ensure proper starting order of both timers during
suspend/resume cycle, increase MCT hotplug priority over ARM Archictected
Timers.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 6da9f77517 ]
When debugging options are turned on, the rcu_read_lock() function
might not be inlined. This results in lockdep's print_lock() function
printing "rcu_read_lock+0x0/0x70" instead of rcu_read_lock()'s caller.
For example:
[ 10.579995] =============================
[ 10.584033] WARNING: suspicious RCU usage
[ 10.588074] 4.18.0.memcg_v2+ #1 Not tainted
[ 10.593162] -----------------------------
[ 10.597203] include/linux/rcupdate.h:281 Illegal context switch in
RCU read-side critical section!
[ 10.606220]
[ 10.606220] other info that might help us debug this:
[ 10.606220]
[ 10.614280]
[ 10.614280] rcu_scheduler_active = 2, debug_locks = 1
[ 10.620853] 3 locks held by systemd/1:
[ 10.624632] #0: (____ptrval____) (&type->i_mutex_dir_key#5){.+.+}, at: lookup_slow+0x42/0x70
[ 10.633232] #1: (____ptrval____) (rcu_read_lock){....}, at: rcu_read_lock+0x0/0x70
[ 10.640954] #2: (____ptrval____) (rcu_read_lock){....}, at: rcu_read_lock+0x0/0x70
These "rcu_read_lock+0x0/0x70" strings are not providing any useful
information. This commit therefore forces inlining of the rcu_read_lock()
function so that rcu_read_lock()'s caller is instead shown.
Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
PD#SWPL-3059
Problem:
vdin1 hisgram and screencap cannot be used simultaneously
Solution:
add vdin1 histgram,and make hist and screencap function to be compatible
Verify:
txlx r311
Change-Id: I759d1cdc69d59015ce845898990088eb6943cc41
Signed-off-by: xuhua zhang <xuhua.zhang@amlogic.com>
Conflicts:
drivers/amlogic/media/vin/tvin/vdin/vdin_drv.c
include/linux/amlogic/media/frame_provider/tvin/tvin.h
PD#OTT-1204
Problem:
don't support dvp camera
Solution:
add dvp camera gc2145 camera driver
Verify:
test pass on U200
Change-Id: I5927d49a93952587af7bb460a5c405293d692153
Signed-off-by: Guosong Zhou <guosong.zhou@amlogic.com>
Conflicts:
MAINTAINERS
arch/arm/boot/dts/amlogic/g12a_s905d2_u200.dts
PD#SWPL-418
Problem:
cec: support multi-logical address
Solution:
if working on multi-logical address, enable two ip
1.enable cec_a, cec_b
2.enable two interrupt
3.enable two pinmux oa_7, ao_8
4.cec_a only send all msg
5.cec_b only receive all msg
6.discard ceca broadcast msg
Verify:
r311
r321
p321
Change-Id: I1dc93429876ede951657102bcd7d41a500946719
Signed-off-by: Yong Qin <yong.qin@amlogic.com>
Conflicts:
drivers/amlogic/cec/hdmi_ao_cec.c
drivers/amlogic/media/vin/tvin/hdmirx/hdmi_rx_drv.h
PD#SWPL-418
Problem:
TXL can't bootup
Solution:
revert it
Verify:
p321
Revert "cec: for support multi-logical address [2/2]"
This reverts commit cc185dc81d.
Revert "cec: for support multi-logical address [1/2]"
This reverts commit b7922078ea.
Change-Id: I1cef0ac194464d75ffff3fe765f15b5f944406b2
Signed-off-by: Lei Qian <lei.qian@amlogic.com>
Conflicts:
drivers/amlogic/cec/hdmi_ao_cec.c
PD#SWPL-6193
Problem:
ramdump need write compressed data to persist storage device.
But if we write it under uboot, it may cause journal and block
bitmap mismatch due to different version of file system. This
caused kernel panic after ramdump finished.
Solution:
Write compressed data under kernel.
This change also removed some extern function of ramdump since
we use sticky register to store ramdump information.
Verify:
p212
Change-Id: Idd83ec6ead4783918b90a39cf716fd3117402278
Signed-off-by: Tao Zeng <tao.zeng@amlogic.com>
Conflicts:
arch/arm/boot/dts/amlogic/mesonaxg.dtsi
arch/arm/boot/dts/amlogic/mesong12a.dtsi
arch/arm/boot/dts/amlogic/mesongxl.dtsi
arch/arm/boot/dts/amlogic/mesongxm.dtsi
arch/arm/boot/dts/amlogic/mesontl1.dtsi
arch/arm/boot/dts/amlogic/mesontxl.dtsi
arch/arm/boot/dts/amlogic/mesontxlx.dtsi
arch/arm64/boot/dts/amlogic/mesonaxg.dtsi
arch/arm64/boot/dts/amlogic/mesong12a.dtsi
arch/arm64/boot/dts/amlogic/mesongxl.dtsi
arch/arm64/boot/dts/amlogic/mesongxm.dtsi
arch/arm64/boot/dts/amlogic/mesontxl.dtsi
arch/arm64/boot/dts/amlogic/mesontxlx.dtsi
drivers/amlogic/memory_ext/ram_dump.c
include/linux/amlogic/ramdump.h
PD#SWPL-1856
Problem:
refactored irblaster code
Solution:
1. Refactor the code according to the core, provider, and consumer
frameworks.
2. Provide software encode to let irblaster work according to different
protocols
3. Provide a unified consumer interface to allow other consumer drivers
to use irblaster.
Verify:
test pass on g12a_u200_v1
Change-Id: Ifd841ef0ed741b7fd721defc25691744ea2103f0
Signed-off-by: Bichao Zheng <bichao.zheng@amlogic.com>
Conflicts:
arch/arm/boot/dts/amlogic/mesontxl.dtsi
arch/arm64/boot/dts/amlogic/axg_s410.dts
arch/arm64/boot/dts/amlogic/mesontxl.dtsi
PD#SWPL-4035
Problem:
Setting different cpufreq tables according to efuse information.
Solution:
Setting different cpufreq tables according to efuse information.
Verify:
g12a_u200, verify pass
Change-Id: I1bf571f332244f5727ef3cd8743f215f71248146
Signed-off-by: Hong Guo <hong.guo@amlogic.com>
Conflicts:
drivers/amlogic/cpufreq/meson-cpufreq.c
PD#SWPL-4858
Problem:
tl1 not support sduart
Solution:
add not supported flag in match_data
Verify:
verify by tl1 skt
Change-Id: I651765433bb62892fad770c85a5eccd4805e7c79
Signed-off-by: Nan Li <nan.li@amlogic.com>
Conflicts:
arch/arm/boot/dts/amlogic/tl1_pxp.dts
arch/arm/boot/dts/amlogic/tl1_t962x2_skt.dts
drivers/amlogic/mmc/amlsd.c
PD#TV-3389
Problem:
add vad wake engine in kernel
Solution:
transfer audio data to wake engine
Verify:
x301
Change-Id: I7f44d0141141775bb40f01dbc344a295a72c9d87
Signed-off-by: Xing Wang <xing.wang@amlogic.com>
Conflicts:
MAINTAINERS
PD#SWPL-3435
Problem:
P321 doesn't support DTS HD decoding
Solution:
In HDMI RX module, we add a new field to
indicate whether the input audio is HBR.
With this info, hal can enable the PAO
mode to decode the HBR audio.
Verify:
P321
Change-Id: I6fd180e6636905f5119fe1d313214d4b56d07d5e
Signed-off-by: yujie.wu <yujie.wu@amlogic.com>
Conflicts:
drivers/amlogic/media/vin/tvin/hdmirx/hdmi_rx_drv.h
drivers/amlogic/media/vin/tvin/hdmirx/hdmi_rx_hw.c
PD#SWPL-5302
Problem:
For dongle products, it is connected to TV directly, and some
parameters are different from mbox.
Solution:
Add dongle mode for driver's usage
Verify:
U211/S905Y2
Change-Id: Ibe45b167800d3b830d78ca8e9d7b67efd64d8564
Signed-off-by: Zongdong Jiao <zongdong.jiao@amlogic.com>
Conflicts:
drivers/amlogic/media/vout/hdmitx/hdmi_tx_20/hw/hw_g12a.c
PD#SWPL-4705
Problem:
In 61207 patch, the define HDMI_IEEE_OUI is conflicted with the kernel
head file include/linux/hdmi.h
Solution:
rename HDMI_IEEE_OUI
Verify:
GXL/P212
Change-Id: I75a12734e85478f22edf0b48636ed86e60302b58
Signed-off-by: Zongdong Jiao <zongdong.jiao@amlogic.com>
Conflicts:
drivers/amlogic/media/vout/hdmitx/hdmi_tx_20/hdmi_tx_main.c
PD#SWPL-4705
Problem:
Lack ALLM function
Solution:
Add ALLM function
Verify:
GXL/P212
If Rx supports ALLM, then
echo 1 > /sys/class/amhdmitx/amhdmitx0/allm_mode
otherwise it will set failed, cat allm_mode and will get 0.
Change-Id: I00233e5a5aac133b405590e7df78c7c4805ed0ef
Signed-off-by: Zongdong Jiao <zongdong.jiao@amlogic.com>
Conflicts:
drivers/amlogic/media/vout/hdmitx/hdmi_tx_20/hdmi_tx_main.c
PD#SWPL-3702
Problem:
local dimming need analog pwm function
Solution:
add analog pwm support
Verify:
x301
Change-Id: I502bb7505947c1f3670f44d0d307f9546f1d57fd
Signed-off-by: Evoke Zhang <evoke.zhang@amlogic.com>
Conflicts:
arch/arm/boot/dts/amlogic/mesontl1_t309-panel.dtsi
arch/arm/boot/dts/amlogic/mesontl1_x301-panel.dtsi
arch/arm/boot/dts/amlogic/mesontxlx_r311-panel.dtsi
arch/arm64/boot/dts/amlogic/mesontl1_t309-panel.dtsi
arch/arm64/boot/dts/amlogic/mesontl1_x301-panel.dtsi
drivers/amlogic/media/vout/backlight/aml_ldim/ldim_dev_drv.c
drivers/amlogic/media/vout/backlight/aml_ldim/ldim_drv.h
include/linux/amlogic/media/vout/lcd/aml_ldim.h
PD#SWPL-4246
Problem:
the screen always flash after switch PAL to NTSC in AVin
Solution:
do not change pll M value, M value will case v by one fail
Verify:
verified on tl1 android p
Change-Id: Ib5ea8dfef1c40af5535e69fdc9241a7f77b4a7dd
Signed-off-by: Yong Qin <yong.qin@amlogic.com>
Conflicts:
drivers/amlogic/media/enhancement/amvecm/amvecm.c
drivers/amlogic/media/enhancement/amvecm/vlock.c
drivers/amlogic/media/enhancement/amvecm/vlock.h
PD#SWPL-6028
Problem:
save irqflag locally when ftrace_ramoops io
Solution:
save irqflag locally when ftrace_ramoops io
Verify:
TL1 x301
Change-Id: I6df9700cceaccc97dc983d88ada73197a6968f73
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
