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
This reverts commit d25d85061b as it is
reported to cause problems on many different types of boards.
Reported-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Reported-by: John Stultz <john.stultz@linaro.org>
Cc: Ray Chi <raychi@google.com>
Link: https://lore.kernel.org/r/CANcMJZCEVxVLyFgLwK98hqBEdc0_n4P0x_K6Gih8zNH3ouzbJQ@mail.gmail.com
Fixes: d25d85061b ("usb: dwc3: gadget: Use list_replace_init() before traversing lists")
Cc: stable <stable@vger.kernel.org>
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Wesley Cheng <wcheng@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 664cc971fbhttps://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: I211e8ab42340d18f7f342ff5bc4fb3efe37e1f2e
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmEPgjkACgkQONu9yGCS
aT4rgg//V+2igeM1O6aFCZODXLiagKe4k52bWC8N28KfjgDTo8znJSvg9wMlQ1vb
YbUIOFqiTTM3JncZB3V260JRiT+abclyxVXlsXOkUpgZJPaBHGSINm5047Uo/Wwf
/xLDPMmT1Yn/o8VUfRArm1+Q5wGCnb7a++2LAozElOAiCifk4S915940KDKQDs5f
PNewMcAhSsPd8lLg+/AqFfACFFmd0CSsLQoF67Cq0fngOEd/2F0tgQkT40+7KBEM
rd9BSHWFFG3uYE/DnkchmxqY0sJ84hdDdNf1Y3UddIiyXPRLOAenUBeBzbHhAVpb
LelR/F5SX4BW+z2+25dj4kD4fKxwWjdESGiWse1GEijLWXRKLTTbgCfMphQOz/km
5qf7wJ7EAfMXmIwHCtF86wHGr1ax37j9qfGSsi+TucLdqafQVTDuSRRH+0gLXCqX
0ST4kAB/N0EjkAYrYNJSNvKqEFFW7YlWtlk9AO+hHfP52XaeOKzW7z/tgqwiGZOZ
pfJfQyqxLpfIeVGzkANJaMwIdqcwOhge3FWScscBpuoxhIkbcdByvTYCr3s7wSzv
jmqja1ofSXoe/7sGNrmRg6VcgnfBgbaOHWuPKvWw/tQlML6bHBflt2Pq1RkyoAsm
LEF+IuZRfLCV/PoqatzA0PT/W9RDniQ0JEjwooOakDX5C5a91Dw=
=X3WM
-----END PGP SIGNATURE-----
Merge 5.10.57 into android12-5.10-lts
Changes in 5.10.57
drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser"
Revert "drm/i915: Propagate errors on awaiting already signaled fences"
btrfs: fix race causing unnecessary inode logging during link and rename
btrfs: fix lost inode on log replay after mix of fsync, rename and inode eviction
regulator: rtmv20: Fix wrong mask for strobe-polarity-high
regulator: rt5033: Fix n_voltages settings for BUCK and LDO
spi: stm32h7: fix full duplex irq handler handling
ASoC: tlv320aic31xx: fix reversed bclk/wclk master bits
r8152: Fix potential PM refcount imbalance
qed: fix possible unpaired spin_{un}lock_bh in _qed_mcp_cmd_and_union()
ASoC: rt5682: Fix the issue of garbled recording after powerd_dbus_suspend
net: Fix zero-copy head len calculation.
ASoC: ti: j721e-evm: Fix unbalanced domain activity tracking during startup
ASoC: ti: j721e-evm: Check for not initialized parent_clk_id
efi/mokvar: Reserve the table only if it is in boot services data
nvme: fix nvme_setup_command metadata trace event
drm/amd/display: Fix comparison error in dcn21 DML
drm/amd/display: Fix max vstartup calculation for modes with borders
ACPI: fix NULL pointer dereference
Revert "Bluetooth: Shutdown controller after workqueues are flushed or cancelled"
firmware: arm_scmi: Ensure drivers provide a probe function
firmware: arm_scmi: Add delayed response status check
Revert "watchdog: iTCO_wdt: Account for rebooting on second timeout"
selftests/bpf: Add a test for ptr_to_map_value on stack for helper access
selftest/bpf: Adjust expected verifier errors
bpf, selftests: Adjust few selftest result_unpriv outcomes
bpf: Update selftests to reflect new error states
bpf, selftests: Adjust few selftest outcomes wrt unreachable code
selftest/bpf: Verifier tests for var-off access
spi: mediatek: Fix fifo transfer
Linux 5.10.57
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ic9f65afb3ff8d01e17fa27dff20c3592910280f2
Sync up with android12-5.10 for the following commits:
1efc36b815 ANDROID: sched: add a helper function to change PELT half-life
bda49ad060 FROMGIT: loop: Select I/O scheduler 'none' from inside add_disk()
d8b946254e FROMGIT: blk-mq: Introduce the BLK_MQ_F_NO_SCHED_BY_DEFAULT flag
8914725a58 FROMGIT: usb: typec: tcpm: Keep other events when receiving FRS and Sourcing_vbus events
bed43a725d FROMGIT: usb: dwc3: gadget: Avoid runtime resume if disabling pullup
41b79ac98d FROMGIT: usb: dwc3: gadget: Use list_replace_init() before traversing lists
58f1839adc FROMGIT: arm64/cpufeature: Optionally disable MTE via command-line
20c3903ad7 ANDROID: ABI: update ABI XML
e9ab28e1c5 ANDROID: ABI: update generic symbol list
bce9e7942a ANDROID: PCI/PM: Use usleep_range for d3hot_delay
045204b080 FROMGIT: KVM: arm64: Unregister HYP sections from kmemleak in protected mode
21e59d0563 FROMGIT: arm64: Move .hyp.rodata outside of the _sdata.._edata range
Change-Id: I0e1e2203a0790184c2b0ac7acda39b9c384e60f7
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit 0d5c3954b3 upstream.
Commit 3a70dd2d05 ("spi: mediatek: fix fifo rx mode") claims that
fifo RX mode was never handled, and adds the presumably missing code
to the FIFO transfer function. However, the claim that receive data
was not handled is incorrect. It was handled as part of interrupt
handling after the transfer was complete. The code added with the above
mentioned commit reads data from the receive FIFO before the transfer
is started, which is wrong. This results in an actual transfer error
on a Hayato Chromebook.
Remove the code trying to handle receive data before the transfer is
started to fix the problem.
Fixes: 3a70dd2d05 ("spi: mediatek: fix fifo rx mode")
Cc: Peter Hess <peter.hess@ph-home.de>
Cc: Frank Wunderlich <frank-w@public-files.de>
Cc: Tzung-Bi Shih <tzungbi@google.com>
Cc: Hsin-Yi Wang <hsinyi@google.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Hsin-Yi Wang <hsinyi@google.com>
Tested-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20210802030023.1748777-1-linux@roeck-us.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7a22930c41 upstream
Add tests for the new functionality - reading and writing to the stack
through a variable-offset pointer.
Signed-off-by: Andrei Matei <andreimatei1@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20210207011027.676572-4-andreimatei1@gmail.com
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 973377ffe8 upstream
In almost all cases from test_verifier that have been changed in here, we've
had an unreachable path with a load from a register which has an invalid
address on purpose. This was basically to make sure that we never walk this
path and to have the verifier complain if it would otherwise. Change it to
match on the right error for unprivileged given we now test these paths
under speculative execution.
There's one case where we match on exact # of insns_processed. Due to the
extra path, this will of course mismatch on unprivileged. Thus, restrict the
test->insn_processed check to privileged-only.
In one other case, we result in a 'pointer comparison prohibited' error. This
is similarly due to verifying an 'invalid' branch where we end up with a value
pointer on one side of the comparison.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d7a5091351 upstream
Update various selftest error messages:
* The 'Rx tried to sub from different maps, paths, or prohibited types'
is reworked into more specific/differentiated error messages for better
guidance.
* The change into 'value -4294967168 makes map_value pointer be out of
bounds' is due to moving the mixed bounds check into the speculation
handling and thus occuring slightly later than above mentioned sanity
check.
* The change into 'math between map_value pointer and register with
unbounded min value' is similarly due to register sanity check coming
before the mixed bounds check.
* The case of 'map access: known scalar += value_ptr from different maps'
now loads fine given masks are the same from the different paths (despite
max map value size being different).
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1bad6fd52b upstream
Given we don't need to simulate the speculative domain for registers with
immediates anymore since the verifier uses direct imm-based rewrites instead
of having to mask, we can also lift a few cases that were previously rejected.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a680cb3d8e upstream
The verifier errors around stack accesses have changed slightly in the
previous commit (generally for the better).
Signed-off-by: Andrei Matei <andreimatei1@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20210207011027.676572-3-andreimatei1@gmail.com
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b4b638c36b upstream
Change bpf_iter_task.c such that pointer to map_value may appear
on the stack for bpf_seq_printf() to access. Without previous
verifier patch, the bpf_iter test will fail.
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Song Liu <songliubraving@fb.com>
Link: https://lore.kernel.org/bpf/20201210013350.943985-1-yhs@fb.com
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 39ed17de8c which is
commit cb011044e3 upstream.
It is reported to cause problems with systems and probably should not
have been backported in the first place :(
Link: https://lore.kernel.org/r/20210803165108.4154cd52@endymion
Reported-by: Jean Delvare <jdelvare@suse.de>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>
Cc: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f1748b1ee1 upstream.
A successfully received delayed response could anyway report a failure at
the protocol layer in the message status field.
Add a check also for this error condition.
Link: https://lore.kernel.org/r/20210608103056.3388-1-cristian.marussi@arm.com
Fixes: 58ecdf03db ("firmware: arm_scmi: Add support for asynchronous commands and delayed response")
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5e469dac32 upstream.
The bus probe callback calls the driver callback without further
checking. Better be safe than sorry and refuse registration of a driver
without a probe function to prevent a NULL pointer exception.
Link: https://lore.kernel.org/r/20210624095059.4010157-2-sudeep.holla@arm.com
Fixes: 933c504424 ("firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices")
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit fc68f42aa7 ]
Commit 71f6428332 ("ACPI: utils: Fix reference counting in
for_each_acpi_dev_match()") started doing "acpi_dev_put()" on a pointer
that was possibly NULL. That fails miserably, because that helper
inline function is not set up to handle that case.
Just make acpi_dev_put() silently accept a NULL pointer, rather than
calling down to put_device() with an invalid offset off that NULL
pointer.
Link: https://lore.kernel.org/lkml/a607c149-6bf6-0fd0-0e31-100378504da2@kernel.dk/
Reported-and-tested-by: Jens Axboe <axboe@kernel.dk>
Tested-by: Daniel Scally <djrscally@gmail.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit d7940911fc ]
[Why]
Vertical and horizontal borders in timings are treated as increasing the
active area - vblank and hblank actually shrink.
Our input into DML does not include these borders so it incorrectly
assumes it has more time than available for vstartup and tmdl
calculations for some modes with borders.
An example of such a timing would be 640x480@72Hz:
h_total: 832
h_border_left: 8
h_addressable: 640
h_border_right: 8
h_front_porch: 16
h_sync_width: 40
v_total: 520
v_border_top: 8
v_addressable: 480
v_border_bottom: 8
v_front_porch: 1
v_sync_width: 3
pix_clk_100hz: 315000
[How]
Include borders as part of destination vactive/hactive.
This change DCN20+ so it has wide impact, but the destination vactive
and hactive are only really used for vstartup calculation anyway.
Most modes do not have vertical or horizontal borders.
Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ec3102dc6b ]
[why]
A comparison error made it possible to not iterate through all the
specified prefetch modes.
[how]
Correct "<" to "<="
Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: Yongqiang Sun <Yongqiang.Sun@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Victor Lu <victorchengchi.lu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 234211b8dd ]
The metadata address is set after the trace event, so the trace is not
capturing anything useful. Rather than logging the memory address, it's
useful to know if the command carries a metadata payload, so change the
trace event to log that true/false state instead.
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 47e1e233e9 ]
One of the SUSE QA tests triggered:
localhost kernel: efi: Failed to lookup EFI memory descriptor for 0x000000003dcf8000
which comes from x86's version of efi_arch_mem_reserve() trying to
reserve a memory region. Usually, that function expects
EFI_BOOT_SERVICES_DATA memory descriptors but the above case is for the
MOKvar table which is allocated in the EFI shim as runtime services.
That lead to a fix changing the allocation of that table to boot services.
However, that fix broke booting SEV guests with that shim leading to
this kernel fix
8d651ee9c7 ("x86/ioremap: Map EFI-reserved memory as encrypted for SEV")
which extended the ioremap hint to map reserved EFI boot services as
decrypted too.
However, all that wasn't needed, IMO, because that error message in
efi_arch_mem_reserve() was innocuous in this case - if the MOKvar table
is not in boot services, then it doesn't need to be reserved in the
first place because it is, well, in runtime services which *should* be
reserved anyway.
So do that reservation for the MOKvar table only if it is allocated
in boot services data. I couldn't find any requirement about where
that table should be allocated in, unlike the ESRT which allocation is
mandated to be done in boot services data by the UEFI spec.
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 82d28b67f7 ]
During probe the parent_clk_id is set to -1 which should not be used to
array index within hsdiv_rates[].
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Link: https://lore.kernel.org/r/20210717122820.1467-3-peter.ujfalusi@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 78d2a05ef2 ]
In case of an error within j721e_audio_startup() the domain->active must
be decremented to avoid unbalanced counter.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Link: https://lore.kernel.org/r/20210717122820.1467-2-peter.ujfalusi@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a17ad09617 ]
In some cases skb head could be locked and entire header
data is pulled from skb. When skb_zerocopy() called in such cases,
following BUG is triggered. This patch fixes it by copying entire
skb in such cases.
This could be optimized incase this is performance bottleneck.
---8<---
kernel BUG at net/core/skbuff.c:2961!
invalid opcode: 0000 [#1] SMP PTI
CPU: 2 PID: 0 Comm: swapper/2 Tainted: G OE 5.4.0-77-generic #86-Ubuntu
Hardware name: OpenStack Foundation OpenStack Nova, BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:skb_zerocopy+0x37a/0x3a0
RSP: 0018:ffffbcc70013ca38 EFLAGS: 00010246
Call Trace:
<IRQ>
queue_userspace_packet+0x2af/0x5e0 [openvswitch]
ovs_dp_upcall+0x3d/0x60 [openvswitch]
ovs_dp_process_packet+0x125/0x150 [openvswitch]
ovs_vport_receive+0x77/0xd0 [openvswitch]
netdev_port_receive+0x87/0x130 [openvswitch]
netdev_frame_hook+0x4b/0x60 [openvswitch]
__netif_receive_skb_core+0x2b4/0xc90
__netif_receive_skb_one_core+0x3f/0xa0
__netif_receive_skb+0x18/0x60
process_backlog+0xa9/0x160
net_rx_action+0x142/0x390
__do_softirq+0xe1/0x2d6
irq_exit+0xae/0xb0
do_IRQ+0x5a/0xf0
common_interrupt+0xf/0xf
Code that triggered BUG:
int
skb_zerocopy(struct sk_buff *to, struct sk_buff *from, int len, int hlen)
{
int i, j = 0;
int plen = 0; /* length of skb->head fragment */
int ret;
struct page *page;
unsigned int offset;
BUG_ON(!from->head_frag && !hlen);
Signed-off-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 6a503e1c45 ]
While using the DMIC recording, the garbled data will be captured by the
DMIC. It is caused by the critical power of PLL closed in the jack detect
function.
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Link: https://lore.kernel.org/r/20210716085853.20170-1-oder_chiou@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 6206b7981a ]
Liajian reported a bug_on hit on a ThunderX2 arm64 server with FastLinQ
QL41000 ethernet controller:
BUG: scheduling while atomic: kworker/0:4/531/0x00000200
[qed_probe:488()]hw prepare failed
kernel BUG at mm/vmalloc.c:2355!
Internal error: Oops - BUG: 0 [#1] SMP
CPU: 0 PID: 531 Comm: kworker/0:4 Tainted: G W 5.4.0-77-generic #86-Ubuntu
pstate: 00400009 (nzcv daif +PAN -UAO)
Call trace:
vunmap+0x4c/0x50
iounmap+0x48/0x58
qed_free_pci+0x60/0x80 [qed]
qed_probe+0x35c/0x688 [qed]
__qede_probe+0x88/0x5c8 [qede]
qede_probe+0x60/0xe0 [qede]
local_pci_probe+0x48/0xa0
work_for_cpu_fn+0x24/0x38
process_one_work+0x1d0/0x468
worker_thread+0x238/0x4e0
kthread+0xf0/0x118
ret_from_fork+0x10/0x18
In this case, qed_hw_prepare() returns error due to hw/fw error, but in
theory work queue should be in process context instead of interrupt.
The root cause might be the unpaired spin_{un}lock_bh() in
_qed_mcp_cmd_and_union(), which causes botton half is disabled incorrectly.
Reported-by: Lijian Zhang <Lijian.Zhang@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9c23aa5147 ]
rtl8152_close() takes the refcount via usb_autopm_get_interface() but
it doesn't release when RTL8152_UNPLUG test hits. This may lead to
the imbalance of PM refcount. This patch addresses it.
Link: https://bugzilla.suse.com/show_bug.cgi?id=1186194
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9cf76a72af ]
These are backwards from Table 7-71 of the TLV320AIC3100 spec [1].
This was broken in 12eb4d66ba when BCLK_MASTER and WCLK_MASTER
were converted from 0x08 and 0x04 to BIT(2) and BIT(3), respectively.
-#define AIC31XX_BCLK_MASTER 0x08
-#define AIC31XX_WCLK_MASTER 0x04
+#define AIC31XX_BCLK_MASTER BIT(2)
+#define AIC31XX_WCLK_MASTER BIT(3)
Probably just a typo since the defines were not listed in bit order.
[1] https://www.ti.com/lit/gpn/tlv320aic3100
Signed-off-by: Kyle Russell <bkylerussell@gmail.com>
Link: https://lore.kernel.org/r/20210622010941.241386-1-bkylerussell@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e4a5c19888 ]
In case of Full-Duplex mode, DXP flag is set when RXP and TXP flags are
set. But to avoid 2 different handlings, just add TXP and RXP flag in
the mask instead of DXP, and then keep the initial handling of TXP and
RXP events.
Also rephrase comment about EOTIE which is one of the interrupt enable
bits. It is not triggered by any event.
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Reviewed-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Link: https://lore.kernel.org/r/1625042723-661-3-git-send-email-alain.volmat@foss.st.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 6549c46af8 ]
For linear regulators, the n_voltages should be (max - min) / step + 1.
Buck voltage from 1v to 3V, per step 100mV, and vout mask is 0x1f.
If value is from 20 to 31, the voltage will all be fixed to 3V.
And LDO also, just vout range is different from 1.2v to 3v, step is the
same. If value is from 18 to 31, the voltage will also be fixed to 3v.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/20210627080418.1718127-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ecc64fab7d ]
When checking if we need to log the new name of a renamed inode, we are
checking if the inode and its parent inode have been logged before, and if
not we don't log the new name. The check however is buggy, as it directly
compares the logged_trans field of the inodes versus the ID of the current
transaction. The problem is that logged_trans is a transient field, only
stored in memory and never persisted in the inode item, so if an inode
was logged before, evicted and reloaded, its logged_trans field is set to
a value of 0, meaning the check will return false and the new name of the
renamed inode is not logged. If the old parent directory was previously
fsynced and we deleted the logged directory entries corresponding to the
old name, we end up with a log that when replayed will delete the renamed
inode.
The following example triggers the problem:
$ mkfs.btrfs -f /dev/sdc
$ mount /dev/sdc /mnt
$ mkdir /mnt/A
$ mkdir /mnt/B
$ echo -n "hello world" > /mnt/A/foo
$ sync
# Add some new file to A and fsync directory A.
$ touch /mnt/A/bar
$ xfs_io -c "fsync" /mnt/A
# Now trigger inode eviction. We are only interested in triggering
# eviction for the inode of directory A.
$ echo 2 > /proc/sys/vm/drop_caches
# Move foo from directory A to directory B.
# This deletes the directory entries for foo in A from the log, and
# does not add the new name for foo in directory B to the log, because
# logged_trans of A is 0, which is less than the current transaction ID.
$ mv /mnt/A/foo /mnt/B/foo
# Now make an fsync to anything except A, B or any file inside them,
# like for example create a file at the root directory and fsync this
# new file. This syncs the log that contains all the changes done by
# previous rename operation.
$ touch /mnt/baz
$ xfs_io -c "fsync" /mnt/baz
<power fail>
# Mount the filesystem and replay the log.
$ mount /dev/sdc /mnt
# Check the filesystem content.
$ ls -1R /mnt
/mnt/:
A
B
baz
/mnt/A:
bar
/mnt/B:
$
# File foo is gone, it's neither in A/ nor in B/.
Fix this by using the inode_logged() helper at btrfs_log_new_name(), which
safely checks if an inode was logged before in the current transaction.
A test case for fstests will follow soon.
CC: stable@vger.kernel.org # 4.14+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit de53d892e5 ]
When we are doing a rename or a link operation for an inode that was logged
in the previous transaction and that transaction is still committing, we
have a time window where we incorrectly consider that the inode was logged
previously in the current transaction and therefore decide to log it to
update it in the log. The following steps give an example on how this
happens during a link operation:
1) Inode X is logged in transaction 1000, so its logged_trans field is set
to 1000;
2) Task A starts to commit transaction 1000;
3) The state of transaction 1000 is changed to TRANS_STATE_UNBLOCKED;
4) Task B starts a link operation for inode X, and as a consequence it
starts transaction 1001;
5) Task A is still committing transaction 1000, therefore the value stored
at fs_info->last_trans_committed is still 999;
6) Task B calls btrfs_log_new_name(), it reads a value of 999 from
fs_info->last_trans_committed and because the logged_trans field of
inode X has a value of 1000, the function does not return immediately,
instead it proceeds to logging the inode, which should not happen
because the inode was logged in the previous transaction (1000) and
not in the current one (1001).
This is not a functional problem, just wasted time and space logging an
inode that does not need to be logged, contributing to higher latency
for link and rename operations.
So fix this by comparing the inodes' logged_trans field with the
generation of the current transaction instead of comparing with the value
stored in fs_info->last_trans_committed.
This case is often hit when running dbench for a long enough duration, as
it does lots of rename operations.
This patch belongs to a patch set that is comprised of the following
patches:
btrfs: fix race causing unnecessary inode logging during link and rename
btrfs: fix race that results in logging old extents during a fast fsync
btrfs: fix race that causes unnecessary logging of ancestor inodes
btrfs: fix race that makes inode logging fallback to transaction commit
btrfs: fix race leading to unnecessary transaction commit when logging inode
btrfs: do not block inode logging for so long during transaction commit
Performance results are mentioned in the change log of the last patch.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3761baae90 upstream.
This reverts commit 9e31c1fe45. Ever
since that commit, we've been having issues where a hang in one client
can propagate to another. In particular, a hang in an app can propagate
to the X server which causes the whole desktop to lock up.
Error propagation along fences sound like a good idea, but as your bug
shows, surprising consequences, since propagating errors across security
boundaries is not a good thing.
What we do have is track the hangs on the ctx, and report information to
userspace using RESET_STATS. That's how arb_robustness works. Also, if my
understanding is still correct, the EIO from execbuf is when your context
is banned (because not recoverable or too many hangs). And in all these
cases it's up to userspace to figure out what is all impacted and should
be reported to the application, that's not on the kernel to guess and
automatically propagate.
What's more, we're also building more features on top of ctx error
reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the
userspace fence wait also relies on that mechanism. So it is the path
going forward for reporting gpu hangs and resets to userspace.
So all together that's why I think we should just bury this idea again as
not quite the direction we want to go to, hence why I think the revert is
the right option here.
For backporters: Please note that you _must_ have a backport of
https://lore.kernel.org/dri-devel/20210602164149.391653-2-jason@jlekstrand.net/
for otherwise backporting just this patch opens up a security bug.
v2: Augment commit message. Also restore Jason's sob that I
accidentally lost.
v3: Add a note for backporters
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reported-by: Marcin Slusarz <marcin.slusarz@intel.com>
Cc: <stable@vger.kernel.org> # v5.6+
Cc: Jason Ekstrand <jason.ekstrand@intel.com>
Cc: Marcin Slusarz <marcin.slusarz@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
Fixes: 9e31c1fe45 ("drm/i915: Propagate errors on awaiting already signaled fences")
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210714193419.1459723-3-jason@jlekstrand.net
(cherry picked from commit 93a2711cdd)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c9d9fdbc10 upstream.
This reverts 686c7c35ab ("drm/i915/gem: Asynchronous cmdparser"). The
justification for this commit in the git history was a vague comment
about getting it out from under the struct_mutex. While this may
improve perf for some workloads on Gen7 platforms where we rely on the
command parser for features such as indirect rendering, no numbers were
provided to prove such an improvement. It claims to closed two
gitlab/bugzilla issues but with no explanation whatsoever as to why or
what bug it's fixing.
Meanwhile, by moving command parsing off to an async callback, it leaves
us with a problem of what to do on error. When things were synchronous,
EXECBUFFER2 would fail with an error code if parsing failed. When
moving it to async, we needed another way to handle that error and the
solution employed was to set an error on the dma_fence and then trust
that said error gets propagated to the client eventually. Moving back
to synchronous will help us untangle the fence error propagation mess.
This also reverts most of 0edbb9ba1b ("drm/i915: Move cmd parser
pinning to execbuffer") which is a refactor of some of our allocation
paths for asynchronous parsing. Now that everything is synchronous, we
don't need it.
v2 (Daniel Vetter):
- Add stabel Cc and Fixes tag
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: <stable@vger.kernel.org> # v5.6+
Fixes: 9e31c1fe45 ("drm/i915: Propagate errors on awaiting already signaled fences")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210714193419.1459723-2-jason@jlekstrand.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
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>
When receiving FRS and Sourcing_Vbus events from low-level drivers, keep
other events which come a bit earlier so that they will not be ignored
in the event handler.
Fixes: 8dc4bd0736 ("usb: typec: tcpm: Add support for Sink Fast Role SWAP(FRS)")
Cc: stable <stable@vger.kernel.org>
Cc: Badhri Jagan Sridharan <badhri@google.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Badhri Jagan Sridharan <badhri@google.com>
Signed-off-by: Kyle Tso <kyletso@google.com>
Link: https://lore.kernel.org/r/20210803091314.3051302-1-kyletso@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 43ad944cd7https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Bug: 194987217
Signed-off-by: Kyle Tso <kyletso@google.com>
Change-Id: Ibb4a2ccd2bbb34e53d4fbe44803aad521bb7029f
