The QCOM PDC driver creates a bunch of unnecessary levels in
the interrupt hierarchy when dealing with non-wakeup-capable
interrupts. By definition, these lines are terminated at the
PDC level, and everything below this is completely fake.
This also results in additional complexity as most of the
callbacks have to check for the validity of the parent level.
Needless to say, this doesn't look very good.
Solve this by disconnecting the interrupt hierarchy below
the last valid level, and considerably simplify the handling
of all the other interrupts by avoiding now unnecessary cheks.
In most cases, the standard irq_*_parent() handlers are directly
used.
This also cures an issue reporting by Maulik where gpio_to_irq()
returns an error after having observed a set of invalid levels.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Tested-by: Maulik Shah <mkshah@codeaurora.org>
Link: https://lore.kernel.org/r/1629705880-27877-3-git-send-email-mkshah@codeaurora.org
Bug: 196928089
(cherry picked from commit 9d4f24bfe043274d9274bcfe223b901bd8fb7182
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/irqchip-next)
Change-Id: Idec7d3b80e0d170be425f1e24efd41ad451bff4e
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
This change adds the dev_coredumpm() API to the symbol list
to allow for custom read and free functions to be called to
dump data.
Bug: 197318507
Change-Id: Ib84b25dd2f075ae9bf8919dcd76451fff5e86f2b
Signed-off-by: Siddharth Gupta <quic_sidgup@quicinc.com>
Originally the addr != NULL check was meant to take care of the case
where __kfence_pool == NULL (KFENCE is disabled). However, this does
not work for addresses where addr > 0 && addr < KFENCE_POOL_SIZE.
This can be the case on NULL-deref where addr > 0 && addr < PAGE_SIZE or
any other faulting access with addr < KFENCE_POOL_SIZE. While the
kernel would likely crash, the stack traces and report might be
confusing due to double faults upon KFENCE's attempt to unprotect such
an address.
Fix it by just checking that __kfence_pool != NULL instead.
Link: https://lkml.kernel.org/r/20210818130300.2482437-1-elver@google.com
Fixes: 0ce20dd84089 ("mm: add Kernel Electric-Fence infrastructure")
Signed-off-by: Marco Elver <elver@google.com>
Reported-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Acked-by: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org> [5.12+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit a7cb5d23eaea148f8582229846f8dfff192f05c3)
Bug: 196937223
Bug: 197197917
Test: local QEMU runs with init/main.c modified to access the NULL page
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: I6a339e8c6b4d2bdc3ee9bd575725489a8233aade
Expicitly set what is visible to userspace
Bug: 196046570
Test: passed netd test suites
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: Iacec0ef8ae290e01f1b60508d8abcd40a3653c83
Initialize message buffer for quota2_log to avoid sending
random data.
Bug: 196046570
Test: passed netd test suites
Fixes: 10cda83af9 ("ANDROID: netfilter: xt_quota2: adding the
original quota2 from xtables-addons")
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: Ic9f34aaa2593809b375fc649b74567190c99dc62
Make sure string only contains the characters specified by userspace.
Fix cherry-picked from xtables-extensions project
Signed-off-by: Sam Liddicott <sam@liddicott.com>
Bug: 196046570
Test: passed netd test suites
Fixes: 10cda83af9 ("ANDROID: netfilter: xt_quota2: adding the
original quota2 from xtables-addons")
Signed-off-by: Todd Kjos <tkjos@google.com>
(cherry picked from https://git.code.sf.net/p/xtables-addons/xtables-addons
bc2bcc383c70b293bd816c29523a952ca8736fb5)
Change-Id: I965448564906e5fbf0fe6d6414f44d9e257ea195
Add the below to ABI symbol list -
console_printk
kmsg_dump_get_line
send_sig_info
Bug: 197173550
Signed-off-by: linjunting <linjunting@oppo.com>
Change-Id: Ia515c994dbf31a4f4e902a11835a635ab2b319b7
If rcu_read_lock_sched tracing is enabled, the tracing subsystem can
perform a jump which needs to be checked by CFI. For example, stm_ftrace
source is enabled as a module and hooks into enabled ftrace events. This
can cause an recursive loop where find_shadow_check_fn ->
rcu_read_lock_sched -> (call to stm_ftrace generates cfi slowpath) ->
find_shadow_check_fn -> rcu_read_lock_sched -> ...
To avoid the recursion, either the ftrace codes needs to be marked with
__no_cfi or CFI should not trace. Use the "_notrace" in CFI to avoid
tracing so that CFI can guard ftrace.
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Cc: stable@vger.kernel.org
Fixes: cf68fffb66d6 ("add support for Clang CFI")
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210811155914.19550-1-quic_eberman@quicinc.com
Bug: 194223154
Change-Id: I7d112496c7f503f95ba69390f6454623cf6dfed2
(cherry picked from commit 14c4c8e41511aa8fba7fb239b20b6539b5bce201)
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
unix_gc() assumes that candidate sockets can never gain an external
reference (i.e. be installed into an fd) while the unix_gc_lock is
held. Except for MSG_PEEK this is guaranteed by modifying inflight
count under the unix_gc_lock.
MSG_PEEK does not touch any variable protected by unix_gc_lock (file
count is not), yet it needs to be serialized with garbage collection.
Do this by locking/unlocking unix_gc_lock:
1) increment file count
2) lock/unlock barrier to make sure incremented file count is visible
to garbage collection
3) install file into fd
This is a lock barrier (unlike smp_mb()) that ensures that garbage
collection is run completely before or completely after the barrier.
Cc: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit cbcf01128d0a92e131bd09f1688fe032480b65ca)
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 196926917
Change-Id: Iaae09d2603c9a680b596d0501479296491ee3d64
Add initial i.MX symbol list file: abi_gki_aarch64_imx.
No new symbols added.
Bug: 194108974
Signed-off-by: Jindong Yue <jindong.yue@nxp.com>
Change-Id: Ic948edbb9a9b9ef866702e4901d714b0c89881bf
If rcu_print_task_stall() is invoked on an rcu_node structure that does
not contain any tasks blocking the current grace period, it takes an
early exit that fails to release that rcu_node structure's lock. This
results in a self-deadlock, which is detected by lockdep.
To reproduce this bug:
tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 3 --trust-make --configs "TREE03" --kconfig "CONFIG_PROVE_LOCKING=y" --bootargs "rcutorture.stall_cpu=30 rcutorture.stall_cpu_block=1 rcutorture.fwd_progress=0 rcutorture.test_boost=0"
This will also result in other complaints, including RCU's scheduler
hook complaining about blocking rather than preemption and an rcutorture
writer stall.
Only a partial RCU CPU stall warning message will be printed because of
the self-deadlock.
This commit therefore releases the lock on the rcu_print_task_stall()
function's early exit path.
Fixes: c583bcb8f5 ("rcu: Don't invoke try_invoke_on_locked_down_task() with irqs disabled")
Tested-by: Qais Yousef <qais.yousef@arm.com>
Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
BUG: 196874644
(cherry picked from commit dc87740c8a6806bd2162bfb441770e4e53be5601
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev)
Signed-off-by: Cheng Jui Wang <cheng-jui.wang@mediatek.com>
Change-Id: I0942973e3fbac2d666d8eb9ed59b1701af13248a
The following scenario describes an echo test for
Samsung USBC Headset (AKG) with VID/PID (0x04e8/0xa051).
We first start a capture stream(USB IN transfer) in 96Khz/24bit/1ch mode.
In clock find source function, we get value 0x2 for clock selector
and 0x1 for clock source.
Kernel-4.14 behavior
Since clock source is valid so clock selector was not set again.
We pass through this function and start a playback stream(USB OUT transfer)
in 48Khz/32bit/2ch mode. This time we get value 0x1 for clock selector
and 0x1 for clock source. Finally clock id with this setting is 0x9.
Kernel-5.10 behavior
Clock selector was always set one more time even it is valid.
When we start a playback stream, we will get 0x2 for clock selector
and 0x1 for clock source. In this case clock id becomes 0xA.
This is an incorrect clock source setting and results in severe noises.
We see wrong data rate in USB IN transfer.
(From 288 bytes/ms becomes 144 bytes/ms) It should keep in 288 bytes/ms.
This earphone works fine on older kernel version load because
this is a newly-added behavior.
Bug: 196943902
Link: https://lore.kernel.org/patchwork/patch/1466711/
cherry picked from commit 4511781f95da0a3b2bad34f3f5e3967e80cd2d18
Signed-off-by: chihhao.chen <chihhao.chen@mediatek.com>
Change-Id: I02731595572e3066fc1abda6009ca6c032b467e8
The logs attached to bug 196797012 show that the error handler has been
activated and also that a SECURITY PROTOCOL OUT command is being
retried but not why. Hence this patch that adds more logging.
Notes:
- The code that initializes the completion status to
OCS_INVALID_COMMAND_STATUS was introduced by the initial UFS commit.
See also 7a3e97b0dc ("[SCSI] ufshcd: UFS Host controller driver").
- The behavior to retry a command if the controller did not overwrite
the completion status was introduced by commit e8e7f27139 ("scsi:
ufs: Improve UFS fatal error handling") without explaining why. From
that commit:
+ case OCS_INVALID_COMMAND_STATUS:
+ result |= DID_REQUEUE << 16;
+ break;
Bug: 196797012
Change-Id: I86ce4149babde1daf07af94464b878e9e697b37b
Signed-off-by: Bart Van Assche <bvanassche@google.com>
For power and performance monitoring, need to known tasks' runtime for
loading estimation.
But now, other modules can't get task_scehd_runtime.
Export task_sched_runtime to let other modules get task_scehd_runtime.
Bug: 195914330
Signed-off-by: Poting Chen <poting.chen@mediatek.com>
Signed-off-by: Cheng Jui Wang <cheng-jui.wang@mediatek.com>
Change-Id: Ida5caf8ed0a32954fc0b0ed950f163c7ca493fef
There is a usecase in Android that an app process's memory is swapped
out by process_madvise() with MADV_PAGEOUT, such as the memory is
swapped to zram or a backing device. When the process is scheduled to
running, like switch to foreground, multiple page faults may cause the
app dropped frames.
To reduce the problem, SMS can read-ahead memory of the process
immediately when the app switches to forground.
Calling process_madvise() with MADV_WILLNEED can meet this need.
Link: https://lore.kernel.org/patchwork/patch/1472006/
Bug: 194967441
Signed-off-by: Kui Zhang <zhagnkui@oppo.com>
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
Change-Id: Ie4203ff76da74cf34498cfee6569a6c7fc624bb2
Mailbox channels for the base protocol are setup during probe.
There can be a scenario where probe fails to acquire the base
protocol due to a timeout leading to cleaning up of all device
managed memory including the scmi_mailbox structure setup during
mailbox_chan_setup function.
| arm-scmi soc:qcom,scmi: timed out in resp(caller: version_get+0x84/0x140)
| arm-scmi soc:qcom,scmi: unable to communicate with SCMI
| arm-scmi: probe of soc:qcom,scmi failed with error -110
Now when a message arrives at cpu slightly after the timeout, the mailbox
controller will try to call the rx_callback of the client and might end
up accessing freed memory.
| rx_callback+0x24/0x160
| mbox_chan_received_data+0x44/0x94
| __handle_irq_event_percpu+0xd4/0x240
This patch frees the mailbox channels setup during probe and adds some more
error handling in case the probe fails.
Link: https://lore.kernel.org/r/1628111999-21595-1-git-send-email-rishabhb@codeaurora.org
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Bug: 196063834
(cherry picked from commit 1e7cbfaa66d39e78bd24df0c78b55df68176b59e
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/ for-next/scmi)
Signed-off-by: Rishabh Bhatnagar <quic_rishabhb@quicinc.com>
Change-Id: I3502b0905dd5e21e6189c125f182fd1fb29eaba8
Enable CONFIG_NFC to support GKI general android device.
When we set CONFIG_NFC=m for driver enable, nfc.ko module needs many
network ABI. So, make CONFIG_NFC=y in gki kernel to ensure all other
nfc device can use without adding ABI list.
- ABI list needed by nfc.ko (CONFIG_NFC=m)
add_wait_queue
add_wait_queue_exclusive
capable
class_dev_iter_exit
class_dev_iter_init
class_dev_iter_next
_copy_from_iter_full
datagram_poll
default_wake_function
lock_sock_nested
nla_strlcpy
proto_register
proto_unregister
__pskb_copy_fclone
release_sock
remove_wait_queue
security_sock_graft
sk_alloc
skb_copy_datagram_iter
skb_free_datagram
skb_recv_datagram
skb_unlink
sk_free
sock_alloc_send_skb
sock_init_data
sock_no_accept
sock_no_bind
sock_no_connect
sock_no_getname
sock_no_ioctl
sock_no_listen
sock_no_mmap
sock_no_sendmsg
sock_no_shutdown
sock_no_socketpair
sock_queue_rcv_skb
__sock_recv_timestamp
__sock_recv_wifi_status
sock_register
sock_unregister
Bug: 196480985
Change-Id: Ie6f0d4bec65c1e2663493e9165b7072dea7c5348
Signed-off-by: Hajun Sung <hajun.sung@samsung.com>
There is currently nothing preventing tasks from changing their per-task
clamp values in anyway that they like. The rationale is probably that
system administrators are still able to limit those clamps thanks to the
cgroup interface. However, this causes pain in a system where both
per-task and per-cgroup clamp values are expected to be under the
control of core system components (as is the case for Android).
To fix this, let's require CAP_SYS_NICE to change per-task clamp values.
There are ongoing discussions upstream about more flexible approaches
than this using the RLIMIT API -- see [1]. But the upstream discussion
has not converged yet, and this is way too late for UAPI changes in
android12-5.10 anyway, so let's apply this change which provides the
behaviour we want without actually impacting UAPIs.
[1] https://lore.kernel.org/lkml/20210623123441.592348-4-qperret@google.com/
Bug: 187186685
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: I749312a77306460318ac5374cf243d00b78120dd
blk_ksm_init_passthrough() is now used.
Bug: 191417025
Change-Id: I414f03df413e44230a7569ba284d39178fbfe104
Signed-off-by: Eric Biggers <ebiggers@google.com>
Enable CONFIG_SCSI_UFS_HPB such that the UFS HPB (Host Performance Booster)
feature can be used. From an Android test device running a kernel with this
patch applied:
$ cd /sys/devices/...ufs/host0
$ grep -aH . */*/hpb*/*
grep: target0:0:0/0:0:0:0/hpb_params/activation_thld: No such device
grep: target0:0:0/0:0:0:0/hpb_params/eviction_thld_enter: No such device
grep: target0:0:0/0:0:0:0/hpb_params/eviction_thld_exit: No such device
grep: target0:0:0/0:0:0:0/hpb_params/inflight_map_req: No such device
grep: target0:0:0/0:0:0:0/hpb_params/normalization_factor: No such device
grep: target0:0:0/0:0:0:0/hpb_params/read_timeout_expiries: No such device
grep: target0:0:0/0:0:0:0/hpb_params/read_timeout_ms: No such device
grep: target0:0:0/0:0:0:0/hpb_params/requeue_timeout_ms: No such device
grep: target0:0:0/0:0:0:0/hpb_params/timeout_polling_interval_ms: No such device
grep: target0:0:0/0:0:0:0/hpb_stats/hit_cnt: No such device
grep: target0:0:0/0:0:0:0/hpb_stats/map_req_cnt: No such device
grep: target0:0:0/0:0:0:0/hpb_stats/miss_cnt: No such device
grep: target0:0:0/0:0:0:0/hpb_stats/rb_active_cnt: No such device
grep: target0:0:0/0:0:0:0/hpb_stats/rb_inactive_cnt: No such device
grep: target0:0:0/0:0:0:0/hpb_stats/rb_noti_cnt: No such device
grep: target0:0:0/0:0:0:0/hpb_stats/umap_req_cnt: No such device
grep: target0:0:0/0:0:0:1/hpb_params/activation_thld: No such device
grep: target0:0:0/0:0:0:1/hpb_params/eviction_thld_enter: No such device
grep: target0:0:0/0:0:0:1/hpb_params/eviction_thld_exit: No such device
grep: target0:0:0/0:0:0:1/hpb_params/inflight_map_req: No such device
grep: target0:0:0/0:0:0:1/hpb_params/normalization_factor: No such device
grep: target0:0:0/0:0:0:1/hpb_params/read_timeout_expiries: No such device
grep: target0:0:0/0:0:0:1/hpb_params/read_timeout_ms: No such device
grep: target0:0:0/0:0:0:1/hpb_params/requeue_timeout_ms: No such device
grep: target0:0:0/0:0:0:1/hpb_params/timeout_polling_interval_ms: No such device
grep: target0:0:0/0:0:0:1/hpb_stats/hit_cnt: No such device
grep: target0:0:0/0:0:0:1/hpb_stats/map_req_cnt: No such device
grep: target0:0:0/0:0:0:1/hpb_stats/miss_cnt: No such device
grep: target0:0:0/0:0:0:1/hpb_stats/rb_active_cnt: No such device
grep: target0:0:0/0:0:0:1/hpb_stats/rb_inactive_cnt: No such device
grep: target0:0:0/0:0:0:1/hpb_stats/rb_noti_cnt: No such device
grep: target0:0:0/0:0:0:1/hpb_stats/umap_req_cnt: No such device
grep: target0:0:0/0:0:0:2/hpb_params/activation_thld: No such device
grep: target0:0:0/0:0:0:2/hpb_params/eviction_thld_enter: No such device
grep: target0:0:0/0:0:0:2/hpb_params/eviction_thld_exit: No such device
grep: target0:0:0/0:0:0:2/hpb_params/inflight_map_req: No such device
grep: target0:0:0/0:0:0:2/hpb_params/normalization_factor: No such device
grep: target0:0:0/0:0:0:2/hpb_params/read_timeout_expiries: No such device
grep: target0:0:0/0:0:0:2/hpb_params/read_timeout_ms: No such device
grep: target0:0:0/0:0:0:2/hpb_params/requeue_timeout_ms: No such device
grep: target0:0:0/0:0:0:2/hpb_params/timeout_polling_interval_ms: No such device
grep: target0:0:0/0:0:0:2/hpb_stats/hit_cnt: No such device
grep: target0:0:0/0:0:0:2/hpb_stats/map_req_cnt: No such device
grep: target0:0:0/0:0:0:2/hpb_stats/miss_cnt: No such device
grep: target0:0:0/0:0:0:2/hpb_stats/rb_active_cnt: No such device
grep: target0:0:0/0:0:0:2/hpb_stats/rb_inactive_cnt: No such device
grep: target0:0:0/0:0:0:2/hpb_stats/rb_noti_cnt: No such device
grep: target0:0:0/0:0:0:2/hpb_stats/umap_req_cnt: No such device
grep: target0:0:0/0:0:0:3/hpb_params/activation_thld: No such device
grep: target0:0:0/0:0:0:3/hpb_params/eviction_thld_enter: No such device
grep: target0:0:0/0:0:0:3/hpb_params/eviction_thld_exit: No such device
grep: target0:0:0/0:0:0:3/hpb_params/inflight_map_req: No such device
grep: target0:0:0/0:0:0:3/hpb_params/normalization_factor: No such device
grep: target0:0:0/0:0:0:3/hpb_params/read_timeout_expiries: No such device
grep: target0:0:0/0:0:0:3/hpb_params/read_timeout_ms: No such device
grep: target0:0:0/0:0:0:3/hpb_params/requeue_timeout_ms: No such device
grep: target0:0:0/0:0:0:3/hpb_params/timeout_polling_interval_ms: No such device
grep: target0:0:0/0:0:0:3/hpb_stats/hit_cnt: No such device
grep: target0:0:0/0:0:0:3/hpb_stats/map_req_cnt: No such device
grep: target0:0:0/0:0:0:3/hpb_stats/miss_cnt: No such device
grep: target0:0:0/0:0:0:3/hpb_stats/rb_active_cnt: No such device
grep: target0:0:0/0:0:0:3/hpb_stats/rb_inactive_cnt: No such device
grep: target0:0:0/0:0:0:3/hpb_stats/rb_noti_cnt: No such device
grep: target0:0:0/0:0:0:3/hpb_stats/umap_req_cnt: No such device
grep: target0:0:0/0:0:0:49456/hpb_params/activation_thld: No such device
grep: target0:0:0/0:0:0:49456/hpb_params/eviction_thld_enter: No such device
grep: target0:0:0/0:0:0:49456/hpb_params/eviction_thld_exit: No such device
grep: target0:0:0/0:0:0:49456/hpb_params/inflight_map_req: No such device
grep: target0:0:0/0:0:0:49456/hpb_params/normalization_factor: No such device
grep: target0:0:0/0:0:0:49456/hpb_params/read_timeout_expiries: No such device
grep: target0:0:0/0:0:0:49456/hpb_params/read_timeout_ms: No such device
grep: target0:0:0/0:0:0:49456/hpb_params/requeue_timeout_ms: No such device
grep: target0:0:0/0:0:0:49456/hpb_params/timeout_polling_interval_ms: No such device
grep: target0:0:0/0:0:0:49456/hpb_stats/hit_cnt: No such device
grep: target0:0:0/0:0:0:49456/hpb_stats/map_req_cnt: No such device
grep: target0:0:0/0:0:0:49456/hpb_stats/miss_cnt: No such device
grep: target0:0:0/0:0:0:49456/hpb_stats/rb_active_cnt: No such device
grep: target0:0:0/0:0:0:49456/hpb_stats/rb_inactive_cnt: No such device
grep: target0:0:0/0:0:0:49456/hpb_stats/rb_noti_cnt: No such device
grep: target0:0:0/0:0:0:49456/hpb_stats/umap_req_cnt: No such device
grep: target0:0:0/0:0:0:49476/hpb_params/activation_thld: No such device
grep: target0:0:0/0:0:0:49476/hpb_params/eviction_thld_enter: No such device
grep: target0:0:0/0:0:0:49476/hpb_params/eviction_thld_exit: No such device
grep: target0:0:0/0:0:0:49476/hpb_params/inflight_map_req: No such device
grep: target0:0:0/0:0:0:49476/hpb_params/normalization_factor: No such device
grep: target0:0:0/0:0:0:49476/hpb_params/read_timeout_expiries: No such device
grep: target0:0:0/0:0:0:49476/hpb_params/read_timeout_ms: No such device
grep: target0:0:0/0:0:0:49476/hpb_params/requeue_timeout_ms: No such device
grep: target0:0:0/0:0:0:49476/hpb_params/timeout_polling_interval_ms: No such device
grep: target0:0:0/0:0:0:49476/hpb_stats/hit_cnt: No such device
grep: target0:0:0/0:0:0:49476/hpb_stats/map_req_cnt: No such device
grep: target0:0:0/0:0:0:49476/hpb_stats/miss_cnt: No such device
grep: target0:0:0/0:0:0:49476/hpb_stats/rb_active_cnt: No such device
grep: target0:0:0/0:0:0:49476/hpb_stats/rb_inactive_cnt: No such device
grep: target0:0:0/0:0:0:49476/hpb_stats/rb_noti_cnt: No such device
grep: target0:0:0/0:0:0:49476/hpb_stats/umap_req_cnt: No such device
grep: target0:0:0/0:0:0:49488/hpb_params/activation_thld: No such device
grep: target0:0:0/0:0:0:49488/hpb_params/eviction_thld_enter: No such device
grep: target0:0:0/0:0:0:49488/hpb_params/eviction_thld_exit: No such device
grep: target0:0:0/0:0:0:49488/hpb_params/inflight_map_req: No such device
grep: target0:0:0/0:0:0:49488/hpb_params/normalization_factor: No such device
grep: target0:0:0/0:0:0:49488/hpb_params/read_timeout_expiries: No such device
grep: target0:0:0/0:0:0:49488/hpb_params/read_timeout_ms: No such device
grep: target0:0:0/0:0:0:49488/hpb_params/requeue_timeout_ms: No such device
grep: target0:0:0/0:0:0:49488/hpb_params/timeout_polling_interval_ms: No such device
grep: target0:0:0/0:0:0:49488/hpb_stats/hit_cnt: No such device
grep: target0:0:0/0:0:0:49488/hpb_stats/map_req_cnt: No such device
grep: target0:0:0/0:0:0:49488/hpb_stats/miss_cnt: No such device
grep: target0:0:0/0:0:0:49488/hpb_stats/rb_active_cnt: No such device
grep: target0:0:0/0:0:0:49488/hpb_stats/rb_inactive_cnt: No such device
grep: target0:0:0/0:0:0:49488/hpb_stats/rb_noti_cnt: No such device
grep: target0:0:0/0:0:0:49488/hpb_stats/umap_req_cnt: No such device
Bug: 194163838
Bug: 195507090
Change-Id: I1aab63c83445e243be190396c452a4203e93dbc1
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Move the ufshpb_dev member into a new structure such that enabling HPB
does not affect the layout of other members of struct ufs_hba. This change
does not affect the ABI since UFS HPB support is currently disabled.
The only function that allocates a struct ufs_hba instance is
ufshcd_alloc_host() and that function allocates struct ufs_hba dynamically.
Modify that function such that it also allocates memory for the HPB data if
necessary.
Bug: 194163838
Bug: 195507090
Test: Built the kernel with this patch applied and installed it on an Android device.
Change-Id: Ia4c5ba07ae343576373ec116553c5fdee8f75a94
Signed-off-by: Bart Van Assche <bvanassche@google.com>
commit 77ec462536a13d4b428a1eead725c4818a49f0b1 upstream.
(The upstream patch was not marked as fixed but this can fix
Fixes: 28b1a824a4 ("arm64: vdso: Substitute gettimeofday() with C implementation")
sysbench memory comparison:
- Before: 3072.00 MB transferred (2601.11 MB/sec)
- After: 3072.00 MB transferred (3217.86 MB/sec)
)
We can avoid the expensive ISB instruction after reading the counter in
the vDSO gettime functions by creating a fake address hazard against a
dummy stack read, just like we do inside the kernel.
Bug: 195968646
Fixes: 28b1a824a4 ("arm64: vdso: Substitute gettimeofday() with C implementation")
Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lore.kernel.org/r/20210318170738.7756-5-will@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
CC: stable@vger.kernel.org
(cherry picked from commit 77ec462536a13d4b428a1eead725c4818a49f0b1)
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Change-Id: I891873626c27060e7ead724754096a7c5f59e4e6
Android does not use these drivers and enabling them causes additional
and unwanted epoll wakeups due to uevents at suspend/resume time.
Bug: 195607946
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: Id3d58dc695c0cd6d2a65503a421de1afebd83784
SCHED_FLAG_KEEP_PARAMS can be passed to sched_setattr to specify that
the call must not touch scheduling parameters (nice or priority). This
is particularly handy for uclamp when used in conjunction with
SCHED_FLAG_KEEP_POLICY as that allows to issue a syscall that only
impacts uclamp values.
However, sched_setattr always checks whether the priorities and nice
values passed in sched_attr are valid first, even if those never get
used down the line. This is useless at best since userspace can
trivially bypass this check to set the uclamp values by specifying low
priorities. However, it is cumbersome to do so as there is no single
expression of this that skips both RT and CFS checks at once. As such,
userspace needs to query the task policy first with e.g. sched_getattr
and then set sched_attr.sched_priority accordingly. This is racy and
slower than a single call.
As the priority and nice checks are useless when SCHED_FLAG_KEEP_PARAMS
is specified, simply inherit them in this case to match the policy
inheritance of SCHED_FLAG_KEEP_POLICY.
Reported-by: Wei Wang <wvw@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Reviewed-by: Qais Yousef <qais.yousef@arm.com>
Link: https://lore.kernel.org/r/20210805102154.590709-3-qperret@google.com
Bug: 190237315
(cherry picked from commit f4dddf90d58d77b48492b775868af4041a217f4c
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core)
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: Ifdbc9262b82c7f5c0d34952ece07770a53e3f6a5
SCHED_FLAG_SUGOV is supposed to be a kernel-only flag that userspace
cannot interact with. However, sched_getattr() currently reports it
in sched_flags if called on a sugov worker even though it is not
actually defined in a UAPI header. To avoid this, make sure to
clean-up the sched_flags field in sched_getattr() before returning to
userspace.
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20210727101103.2729607-3-qperret@google.com
Bug: 190237315
(cherry picked from commit 7ad721bf10718a4e480a27ded8bb16b8f6feb2d1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core)
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: Ib998d497fc38a7f8e6ccb80119336c9ac30719b7
It is possible for sched_getattr() to incorrectly report the state of
the reset_on_fork flag when called on a deadline task.
Indeed, if the flag was set on a deadline task using sched_setattr()
with flags (SCHED_FLAG_RESET_ON_FORK | SCHED_FLAG_KEEP_PARAMS), then
p->sched_reset_on_fork will be set, but __setscheduler() will bail out
early, which means that the dl_se->flags will not get updated by
__setscheduler_params()->__setparam_dl(). Consequently, if
sched_getattr() is then called on the task, __getparam_dl() will
override kattr.sched_flags with the now out-of-date copy in dl_se->flags
and report the stale value to userspace.
To fix this, make sure to only copy the flags that are relevant to
sched_deadline to and from the dl_se->flags field.
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20210727101103.2729607-2-qperret@google.com
Bug: 190237315
(cherry picked from commit f95091536f78971b269ec321b057b8d630b0ad8a
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core)
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: I251a433e0ddde6b63881f92821bc0d47c1693a02
The UCLAMP_FLAG_IDLE flag is set on a runqueue when dequeueing the last
uclamp active task (that is, when buckets.tasks reaches 0 for all
buckets) to maintain the last uclamp.max and prevent blocked util from
suddenly becoming visible.
However, there is an asymmetry in how the flag is set and cleared which
can lead to having the flag set whilst there are active tasks on the rq.
Specifically, the flag is cleared in the uclamp_rq_inc() path, which is
called at enqueue time, but set in uclamp_rq_dec_id() which is called
both when dequeueing a task _and_ in the update_uclamp_active() path. As
a result, when both uclamp_rq_{dec,ind}_id() are called from
update_uclamp_active(), the flag ends up being set but not cleared,
hence leaving the runqueue in a broken state.
Fix this by clearing the flag in update_uclamp_active() as well.
Fixes: e496187da7 ("sched/uclamp: Enforce last task's UCLAMP_MAX")
Reported-by: Rick Yiu <rickyiu@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Qais Yousef <qais.yousef@arm.com>
Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Link: https://lore.kernel.org/r/20210805102154.590709-2-qperret@google.com
[ qperret: BACKPORT due to trivial cherry-pick conflict caused by
0213b7083e81 ("sched/uclamp: Fix uclamp_tg_restrict()") missing
from 5.10. ]
Bug: 192559209
(cherry picked from commit ca4984a7dd863f3e1c0df775ae3e744bff24c303
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core)
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: I7b3418e553ba0f06dd5ef6f0d38a99c3210ae897
Add a new helper function and export it for vendor module to
dynamically switch to an alternative half-life at runtime.
Bug: 195474490
Signed-off-by: JianMin Liu <jian-min.liu@mediatek.com>
Change-Id: Ife41997a032fe3384cfa126cbf7aee929c5c11cf
We noticed that the user interface of Android devices becomes very slow
under memory pressure. This is because Android uses the zram driver on top
of the loop driver for swapping, because under memory pressure the swap
code alternates reads and writes quickly, because mq-deadline is the
default scheduler for loop devices and because mq-deadline delays writes by
five seconds for such a workload with default settings. Fix this by making
the kernel select I/O scheduler 'none' from inside add_disk() for loop
devices. This default can be overridden at any time from user space,
e.g. via a udev rule. This approach has an advantage compared to changing
the I/O scheduler from userspace from 'mq-deadline' into 'none', namely
that synchronize_rcu() does not get called.
Additionally, this patch reduces the Android boot time on my test setup
with 0.5 seconds compared to configuring the loop I/O scheduler from user
space.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Bug: 194450129
(cherry picked from commit 2112f5c1330a671fa852051d85cb9eadc05d7eb7 git://git.kernel.dk/linux-block/ for-5.15/block)
Change-Id: I6f9579b4cd2cb22fcb5c858d4f292f1870336fdd
Signed-off-by: Bart Van Assche <bvanassche@google.com>
elevator_get_default() uses the following algorithm to select an I/O
scheduler from inside add_disk():
- In case of a single hardware queue or sharing hardware queues across
multiple request queues (BLK_MQ_F_TAG_HCTX_SHARED), use mq-deadline.
- Otherwise, use 'none'.
This is a good choice for most but not for all block drivers. Make it
possible to override the selection of mq-deadline with a new flag,
namely BLK_MQ_F_NO_SCHED_BY_DEFAULT.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Bug: 194450129
(cherry picked from commit 90b7198001f23ea37d3b46dc631bdaa2357a20b1 git://git.kernel.dk/linux-block/ for-5.15/block)
Change-Id: I4fb658957c193f350e74bdb5876c20a8f628fcb1
Signed-off-by: Bart Van Assche <bvanassche@google.com>
If the device is already in the runtime suspended state, any call to
the pullup routine will issue a runtime resume on the DWC3 core
device. If the USB gadget is disabling the pullup, then avoid having
to issue a runtime resume, as DWC3 gadget has already been
halted/stopped.
This fixes an issue where the following condition occurs:
usb_gadget_remove_driver()
-->usb_gadget_disconnect()
-->dwc3_gadget_pullup(0)
-->pm_runtime_get_sync() -> ret = 0
-->pm_runtime_put() [async]
-->usb_gadget_udc_stop()
-->dwc3_gadget_stop()
-->dwc->gadget_driver = NULL
...
dwc3_suspend_common()
-->dwc3_gadget_suspend()
-->DWC3 halt/stop routine skipped, driver_data == NULL
This leads to a situation where the DWC3 gadget is not properly
stopped, as the runtime resume would have re-enabled EP0 and event
interrupts, and since we avoided the DWC3 gadget suspend, these
resources were never disabled.
Fixes: 77adb8bdf422 ("usb: dwc3: gadget: Allow runtime suspend if UDC unbinded")
Cc: stable <stable@vger.kernel.org>
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1628058245-30692-1-git-send-email-wcheng@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit cb10f68ad8150f243964b19391711aaac5e8ff42
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Bug: 195568631
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I98cb28c7cfbc2965aa6e470912e0eb6700a74be9
The list_for_each_entry_safe() macro saves the current item (n) and
the item after (n+1), so that n can be safely removed without
corrupting the list. However, when traversing the list and removing
items using gadget giveback, the DWC3 lock is briefly released,
allowing other routines to execute. There is a situation where, while
items are being removed from the cancelled_list using
dwc3_gadget_ep_cleanup_cancelled_requests(), the pullup disable
routine is running in parallel (due to UDC unbind). As the cleanup
routine removes n, and the pullup disable removes n+1, once the
cleanup retakes the DWC3 lock, it references a request who was already
removed/handled. With list debug enabled, this leads to a panic.
Ensure all instances of the macro are replaced where gadget giveback
is used.
Example call stack:
Thread#1:
__dwc3_gadget_ep_set_halt() - CLEAR HALT
-> dwc3_gadget_ep_cleanup_cancelled_requests()
->list_for_each_entry_safe()
->dwc3_gadget_giveback(n)
->dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list]
->spin_unlock
->Thread#2 executes
...
->dwc3_gadget_giveback(n+1)
->Already removed!
Thread#2:
dwc3_gadget_pullup()
->waiting for dwc3 spin_lock
...
->Thread#1 released lock
->dwc3_stop_active_transfers()
->dwc3_remove_requests()
->fetches n+1 item from cancelled_list (n removed by Thread#1)
->dwc3_gadget_giveback()
->dwc3_gadget_del_and_unmap_request()- n+1
deleted[cancelled_list]
->spin_unlock
Fix this condition by utilizing list_replace_init(), and traversing
through a local copy of the current elements in the endpoint lists.
This will also set the parent list as empty, so if another thread is
also looping through the list, it will be empty on the next iteration.
Fixes: d4f1afe5e8 ("usb: dwc3: gadget: move requests to cancelled_list")
Cc: stable <stable@vger.kernel.org>
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1627543994-20327-1-git-send-email-wcheng@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit d25d85061bd856d6be221626605319154f9b5043
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Bug: 195570448
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0eebb6938d7fac97f6126deda2984387dec1e794
MTE support needs to be optionally disabled in runtime
for HW issue workaround, FW development and some
evaluation works on system resource and performance.
This patch makes two changes:
(1) moves init of tag-allocation bits(ATA/ATA0) to
cpu_enable_mte() as not cached in TLB.
(2) allows ID_AA64PFR1_EL1.MTE to be overridden on
its shadow value by giving "arm64.nomte" on cmdline.
When the feature value is off, ATA and TCF will not set
and the related functionalities are accordingly suppressed.
Change-Id: Ic9cf6d3a12a33b312643d96101c72a657cb714af
Link: https://lore.kernel.org/lkml/20210803070824.7586-2-yee.lee@mediatek.com/
(cherry picked from commit 7a062ce31807eb402c38edbec50c1b848b4298f3 git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git next)
Bug: 195507092
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Suggested-by: Marc Zyngier <maz@kernel.org>
Suggested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Yee Lee <yee.lee@mediatek.com>
This patch implements a vendor hook that changes d3hot_delay to use
usleep_range() instead of msleep() to reduce the resume time from 20ms to 10ms.
The call sequence is as follows:
pci_pm_resume_noirq()
pci_pm_default_resume_early()
pci_power_up()
pci_raw_set_power_state() --> msleep(10)
The default d3hot_delay is 10ms. Using msleep for delays less than 20ms could
result in delays up to 20ms.
Reference: Documentation/timers/timers-howto.rst
Using usleep_range() results in the delay being closer to 10ms and this reduces
the resume time.
Bug: 194231641
Change-Id: If3e4dcfb99edad302371273933fa6784854cf892
Signed-off-by: Sajid Dalvi <sdalvi@google.com>
