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 77ec462536 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 77ec462536)
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 f4dddf90d5
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 7ad721bf10
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 f95091536f
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
0213b7083e ("sched/uclamp: Fix uclamp_tg_restrict()") missing
from 5.10. ]
Bug: 192559209
(cherry picked from commit ca4984a7dd
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 2112f5c133 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 90b7198001 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: 77adb8bdf4 ("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 cb10f68ad8https://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 d25d85061bhttps://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 7a062ce318 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>
Booting a KVM host in protected mode with kmemleak quickly results
in a pretty bad crash, as kmemleak doesn't know that the HYP sections
have been taken away. This is specially true for the BSS section,
which is part of the kernel BSS section and registered at boot time
by kmemleak itself.
Unregister the HYP part of the BSS before making that section
HYP-private. The rest of the HYP-specific data is obtained via
the page allocator or lives in other sections, none of which is
subjected to kmemleak.
Fixes: 90134ac9ca ("KVM: arm64: Protect the .hyp sections from the host")
Reviewed-by: Quentin Perret <qperret@google.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org # 5.13
Link: https://lore.kernel.org/r/20210802123830.2195174-3-maz@kernel.org
(cherry picked from commit 47e6223c84 git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git next)
Signed-off-by: Marc Zyngier <mzyngier@google.com>
Bug: 194868924
Change-Id: I2881fc146d8a8dd8c9ad9bd9da3a8356968be794
The HYP rodata section is currently lumped together with the BSS,
which isn't exactly what is expected (it gets registered with
kmemleak, for example).
Move it away so that it is actually marked RO. As an added
benefit, it isn't registered with kmemleak anymore.
Fixes: 380e18ade4 ("KVM: arm64: Introduce a BSS section for use at Hyp")
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org #5.13
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20210802123830.2195174-2-maz@kernel.org
(cherry picked from commit eb48d154cd git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git next)
Signed-off-by: Marc Zyngier <mzyngier@google.com>
Bug: 194868924
Change-Id: I83eb8a573640a37d7272f004d5f1626080395d93
Due to the xhci bugfix, the abi .xml has to be updated as one of the
reserved fields for padding was needed to be used.
Leaf changes summary: 1 artifact changed (1 filtered out)
Changed leaf types summary: 1 (1 filtered out) leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct xhci_hcd at xhci.h:1753:1' changed:
type size hasn't changed
1 data member insertion:
'union {xhci_vendor_ops* vendor_ops; struct {u64 android_kabi_reserved1;} __UNIQUE_ID_android_kabi_hide321; union {};}', at offset 59392 (in bits) at xhci.h:1932:1
there are data member changes:
data member u64 android_kabi_reserved1 at offset 59392 (in bits) became anonymous data member 'union {xhci_vendor_ops* vendor_ops; struct {u64 android_kabi_reserved1;} __UNIQUE_ID_android_kabi_hide315; union {};}'
18 impacted interfaces
Bug: 194461020
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9ed5203273a951d00d7e6bc5db159411c6db0a58
slab-out-of-bounds happens if the xhci platform drivers don't define
the extra_priv_size in their xhci_driver_overrides structure. Move
xhci_vendor_ops structure to xhci main structure to avoid
extra_priv_size affacts xhci_vendor_get_ops which causes the
slab-out-of-bounds error.
Bug: 194461020
Test: build and boot pass
Change-Id: Id17fdfbfd3e8edcc89a05c9c2f553ffab494215e
Signed-off-by: Howard Yen <howardyen@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Since commit 1b6b26ae70 ("pipe: fix and clarify pipe write wakeup
logic") we have sanitized the pipe write logic, and would only try to
wake up readers if they needed it.
In particular, if the pipe already had data in it before the write,
there was no point in trying to wake up a reader, since any existing
readers must have been aware of the pre-existing data already. Doing
extraneous wakeups will only cause potential thundering herd problems.
However, it turns out that some Android libraries have misused the EPOLL
interface, and expected "edge triggered" be to "any new write will
trigger it". Even if there was no edge in sight.
Quoting Sandeep Patil:
"The commit 1b6b26ae70 ('pipe: fix and clarify pipe write wakeup
logic') changed pipe write logic to wakeup readers only if the pipe
was empty at the time of write. However, there are libraries that
relied upon the older behavior for notification scheme similar to
what's described in [1]
One such library 'realm-core'[2] is used by numerous Android
applications. The library uses a similar notification mechanism as GNU
Make but it never drains the pipe until it is full. When Android moved
to v5.10 kernel, all applications using this library stopped working.
The library has since been fixed[3] but it will be a while before all
applications incorporate the updated library"
Our regression rule for the kernel is that if applications break from
new behavior, it's a regression, even if it was because the application
did something patently wrong. Also note the original report [4] by
Michal Kerrisk about a test for this epoll behavior - but at that point
we didn't know of any actual broken use case.
So add the extraneous wakeup, to approximate the old behavior.
[ I say "approximate", because the exact old behavior was to do a wakeup
not for each write(), but for each pipe buffer chunk that was filled
in. The behavior introduced by this change is not that - this is just
"every write will cause a wakeup, whether necessary or not", which
seems to be sufficient for the broken library use. ]
It's worth noting that this adds the extraneous wakeup only for the
write side, while the read side still considers the "edge" to be purely
about reading enough from the pipe to allow further writes.
See commit f467a6a664 ("pipe: fix and clarify pipe read wakeup logic")
for the pipe read case, which remains that "only wake up if the pipe was
full, and we read something from it".
Link: https://lore.kernel.org/lkml/CAHk-=wjeG0q1vgzu4iJhW5juPkTsjTYmiqiMUYAebWW+0bam6w@mail.gmail.com/ [1]
Link: https://github.com/realm/realm-core [2]
Link: https://github.com/realm/realm-core/issues/4666 [3]
Link: https://lore.kernel.org/lkml/CAKgNAkjMBGeAwF=2MKK758BhxvW58wYTgYKB2V-gY1PwXxrH+Q@mail.gmail.com/ [4]
Link: https://lore.kernel.org/lkml/20210729222635.2937453-1-sspatil@android.com/
Bug: 193851993
Reported-by: Sandeep Patil <sspatil@android.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 3a34b13a88)
Signed-off-by: Sandeep Patil <sspatil@android.com>
Change-Id: Idcf3e8faa31bff47ada4b815237a355e0757b964
Enable CONFIG_USB_EHCI_ROOT_HUB_TT so that EHCI controllers
on i.MX8MM can integrate transaction translators.
Bug: 194108974
Signed-off-by: Jindong Yue <jindong.yue@nxp.com>
Change-Id: If06b571e1a3a74946953fa48f86545b282b20b4d
This tries to fix priority inversion in the below condition resulting in
long checkpoint delay.
f2fs_get_node_info()
- nat_tree_lock
-> sleep to grab journal_rwsem by contention
checkpoint
- waiting for nat_tree_lock
In order to let checkpoint go, let's release nat_tree_lock, if there's a
journal_rwsem contention.
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 191987855
(cherry picked from commit 2eeb0dce72
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev)
Change-Id: I97ac4f9d3bde399ab4f17f5b3a6e949ae9b79f0f
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Some hardware has a way to restore all keyslots at once that is
significantly faster than restoring each keyslot individually, as is
done by blk_ksm_reprogram_all_keys(). Add a hook
"android_rvh_ufs_reprogram_all_keys" that allows overriding the
restoration of all keyslots after UFS reset. This may sleep, so this
must be a "restricted" Android vendor hook rather than a regular one.
Note that currently this functionality can't be upstreamed, as support
for the hardware that needs it would need to be upstreamed first.
Bug: 162257402
Bug: 181905172
Change-Id: I0b25393a5131941f085892560e08a64e63cd1369
Signed-off-by: Eric Biggers <ebiggers@google.com>
Initial list of rockchip symbols. These are all already included in the
existing list of symbols supported, so no .xml file update is needed at
this time.
Bug: 194515348
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3d31281597bf2e3fb0016629ff75bb304052b1c4
This patch is for updating GKI allowed symbol list without adding any
new symbol. Next patch will introduce newly added symbols for Exynosauto
SoC GKI vendor modules.
Bug: 194547942
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Change-Id: I5f50e0c7b7991953aa40b9555277f6a208629303
Add hook to tcp/udp to collect network info and do performance tuning.
Bug: 190523684
Change-Id: Id790a381d5ce6c35a747697510f14678ccf3ff2f
Signed-off-by: Liangliang Li <liliangliang@vivo.com>
commit '1b6b26ae7053 ("pipe: fix and clarify pipe write wakeup logic")'
change `pipe_write()` wakeup logic to wakeup readers only if the pipe
was empty.
This meant that applications that are not draining the pipe
before each write were exposed to unexpected timeouts / hangs in
epoll_wait() waiting for data in a pipe using EPOLLIN | EPOLLET flags.
This behaviour can be easily tested with android12-5.4 kernel where
the test that uses pipes for notifications in this way works while it
fails 100% with android12-5.10.
This change restores the old behavior to wakeup all pipe_readers if any
new data is written to the pipe.
Bug: 193851993
Bug: 193846582
Change-Id: If0c5a844091ccf16d5236bd072326325d4d5447a
Signed-off-by: Sandeep Patil <sspatil@google.com>
Trying to verify that all of the proper files are being pulled in for
the ABI symbol list is easier if they are in sorted order.
Bug: 193853163
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I663313ea6d61b2ab80b3fd8e29098e694ff4ef00
This reverts commit 52f8b40ff6.
It turns out that the unisoc file was never even hooked up to the gki
symbol build script so this file is doing nothing at all.
I tried to add it, but it breaks the build as it includes a lot of
symbols that are not even part of this kernel tree, so it must have been
created from a different kernel version.
Please resubmit this file properly, and hook it up to the build process
(by adding it to the list in the build.config.gki.aarch64 file.)
Bug: 186088840
Signed-off-by: Jian Gong <jian.gong@unisoc.com>
Fixes: 52f8b40ff6 ("ANDROID: ABI: update symbols to unisoc whitelist for the fifth time")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ibdb7d57f0901aa7273c0c29e0a7e0eaf26909e26
