Android 14 and later default to MGLRU [1] and field telemetry showed
occasional long tail latency (>100ms) in the reclaim path.
Tracing revealed priority inversion in the reclaim path. In
try_to_inc_max_seq(), when high priority tasks were blocked on
wait_event_killable(), the preemption of the low priority task to call
wake_up_all() caused those high priority tasks to wait longer than
necessary. In general, this problem is not different from others of its
kind, e.g., one caused by mutex_lock(). However, it is specific to MGLRU
because it introduced the new wait queue lruvec->mm_state.wait.
The purpose of this new wait queue is to avoid the thundering herd
problem. If many direct reclaimers rush into try_to_inc_max_seq(), only
one can succeed, i.e., the one to wake up the rest, and the rest who
failed might cause premature OOM kills if they do not wait. So far there
is no evidence supporting this scenario, based on how often the wait has
been hit. And this begs the question how useful the wait queue is in
practice.
Based on Minchan's recommendation, which is in line with his commit
6d4675e601 ("mm: don't be stuck to rmap lock on reclaim path") and the
rest of the MGLRU code which also uses trylock when possible, remove the
wait queue.
[1] https://android-review.googlesource.com/q/I7ed7fbfd6ef9ce10053347528125dd98c39e50bf
Link: https://lkml.kernel.org/r/20230413214326.2147568-1-kaleshsingh@google.com
Fixes: bd74fdaea1 ("mm: multi-gen LRU: support page table walks")
Change-Id: I911f3968fd1adb25171279cc5b6f48ccb7efc8de
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Suggested-by: Minchan Kim <minchan@kernel.org>
Reported-by: Wei Wang <wvw@google.com>
Acked-by: Yu Zhao <yuzhao@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Cc: Oleksandr Natalenko <oleksandr@natalenko.name>
Cc: Suleiman Souhlal <suleiman@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 7f63cf2d9b)
Bug: 277906484
[ Kalesh Singh - Fix conflicts in mm/vmscan.c ]
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
This reverts commit 397665b3ed.
Will be replace by closer to upstream verion and ABI will be updated.
Bug: 277906484
Change-Id: Ieabfeaad50ac5001f6a5b87c1dd1051d47bc40af
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
struct swap_info_struct :: ANDROID_VENDOR_DATA(1)
It is pointer to a struct to record the following message:
1) total swapin pages;
2) total swapout pages;
3) total number of cold pages swapin;
4) total number of swapout pages, specified by userspace;
5) total number of swapout pages, specified by kernel;
6) the maxmium number of swapout pages;
7) the maxmium number of swapout pages allowed by kernel;
8) the maxmium number of swapout pages allowed by framework;
Bug: 225795494
Change-Id: I779145a83d87e339db86ec81c7f962be99946afb
Signed-off-by: Bing Han <bing.han@transsion.com>
(cherry picked from commit af4eb0e377)
(cherry picked from commit 29277e2bf79d36eede562b529c8e7b295e9a53df)
struct swap_slots_cache :: ANDROID_VENDOR_DATA(1)
1) Multiple swap devices can be supported;
2) There are different kinds of data;
3) During data reclamation, different types of data are exchanged
to different swap devices;
4) Each swap device has corresponding arrays of slots and slots_ret;
5) Each swap device has corresponding indexes of nr, cur and n_ret;
6) This field is a pointer, it points to a struct which contains
all the other arrays and indexes;
Bug: 225795494
Change-Id: Icf116135926be98449a2d96fc458e58e5ad3b7e9
Signed-off-by: Bing Han <bing.han@transsion.com>
(cherry picked from commit a034320a68)
(cherry picked from commit 2fd1f19d555cb63bdf2f810f9b944feabf836dff)
struct lruvec :: ANDROID_VENDOR_DATA(1)
It is pointer to a struct to record the following message:
1）the account of workingset_restore pages of cached anonymous and
file pages
This is used to adjust the strategy and amount of reclaiming data.
Bug: 225795494
Change-Id: I34e57ee23b6c97ac91effa5b72513d238335a996
Signed-off-by: Bing Han <bing.han@transsion.com>
(cherry picked from commit 1b14ae01b0)
(cherry picked from commit dcac70709fb59478979519d7502b2bb5b8389ff6)
request_queue.requeue_work is no longer used since "block: Preserve the
order of requeued requests". Hence remove this request member.
Bug: 280677698
Change-Id: I1c9d9cd9a5f5d630bb638e5b0a64fbe0a9201459
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Ungating the clock asynchronously causes ufshcd_queuecommand() to
return SCSI_MLQUEUE_HOST_BUSY and hence causes commands to be requeued.
This is suboptimal. Allow ufshcd_queuecommand() to sleep such that
clock ungating does not trigger command requeuing.
Bug: 280677698
Change-Id: I36f78e9e3c307f4498c0d8c58a102560ecf38c7c
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Prepare for adding code in ufshcd_queuecommand() that may sleep.
Bug: 280677698
Change-Id: I20f0a2aa4571b6ca8a51bf75f5dbf0cd8855706a
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Prepare for adding code in ufshcd_queuecommand() that may sleep.
Bug: 280677698
Change-Id: I0fa2dc37ac19da889986a80f4dddd638e8571d8a
Signed-off-by: Bart Van Assche <bvanassche@google.com>
The following symbol no longer exists after backporting upstream commit
6fd1d51cfa ("net: SO_RCVMARK socket option for SO_MARK with
recvmsg()"). Removing the symbol fixes the following KMI build issue:
Symbols missing from the ksymtab:
__sock_recv_ts_and_drops
ERROR: Checking for kmi_symbol_list_strict_mode
Bug: 285364323
Cc: zhangao <zhangao@zeku.com>
Change-Id: I53038b3561c0d758b908307ea17d3f9c8c2ec472
Signed-off-by: Carlos Llamas <cmllamas@google.com>
The commit referenced in the "Fixes" tag added the SO_RCVMARK socket
option for receiving the skb mark in the ancillary data.
Since this is a new capability, and exposes admin configured details
regarding the underlying network setup to sockets, let's align the
needed capabilities with those of SO_MARK.
Fixes: 6fd1d51cfa ("net: SO_RCVMARK socket option for SO_MARK with recvmsg()")
Signed-off-by: Eyal Birger <eyal.birger@gmail.com>
Link: https://lore.kernel.org/r/20220504095459.2663513-1-eyal.birger@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 1f86123b97)
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I475283f1dc91d3f0b849c888d3a936fbf2105748
Currently, when regmap_raw_write() splits the data, it uses the
max_raw_write value defined for the bus. For any bus that includes
the target register address in the max_raw_write value, the chunked
transmission will always exceed the maximum transmission length.
To avoid this problem, subtract the length of the register and the
padding from the maximum transmission.
Signed-off-by: Jim Wylder <jwylder@google.com
Link: https://lore.kernel.org/r/20230517152444.3690870-2-jwylder@google.com
Signed-off-by: Mark Brown <broonie@kernel.org
Bug: 284126209
Change-Id: Ie265716bf523ed29c7d5ef9c0292e220adfb9dfc
(cherry picked from commit 3981514180)
Signed-off-by: Jim Wylder <jwylder@google.com>
With FEAT_FGT, most bits in hfgwtr_el2 must be set to 1 to enable
trapping of MSR writes of certain registers. However, there is a
notable (and arguably curious) exception for nSMPRI_EL1 and
nTPIDR2_EL0 which must be set to 1 to _disable_ trapping of the
corresponding SME registers.
Make sure to initialize hfgwtr_el2 in the pKVM init params accordingly
to avoid accidentally enabling certain traps on hardware that supports
FEAT_FGT and FEAT_SME.
Bug: 282917063
Bug: 282993310
Change-Id: Ia96fa6856b4e7ef98b3cea4f03fcbc0ee03f10c5
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Partially applies patch from Vincent Guittot
e5ed0550c0: ("sched/fair: unlink misfit task from cpu overutilized")
The full patch improves the search logic under thermal pressure, but
it's a bit intrusive to fully backport. We are interested in the part
that unlinks misfit from overutilized only.
Bug: 283975667
Signed-off-by: Qais Yousef <qyousef@google.com>
Change-Id: I2ae21499b846d13d3889f8cacdb70652817b066f
Add a new 'snps,parkmode-disable-hs-quirk' DT quirk to dwc3 core for
disable the high-speed parkmode.
For some USB wifi devices, if enable this feature it will reduce the
performance. Therefore, add an option for disabling HS park mode by
device-tree.
In Synopsys's dwc3 data book:
In a few high speed devices when an IN request is sent within 900ns of the
ACK of the previous packet, these devices send a NAK. When connected to
these devices, if required, the software can disable the park mode if you
see performance drop in your system. When park mode is disabled,
pipelining of multiple packet is disabled and instead one packet at a time
is requested by the scheduler. This allows up to 12 NAKs in a micro-frame
and improves performance of these slow devices.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
Link: https://lore.kernel.org/r/20230419020044.15475-2-stanley_chang@realtek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug:285992796
(cherry picked from commit 4a2f152af1
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git master)
Change-Id: If445a42082326b981f75ed21bc92a4b7c2fff685
Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
Setting the PARKMODE_DISABLE_HS bit in the DWC3_USB3_GUCTL1.
When this bit is set to '1' all HS bus instances in park mode are disabled
For some USB wifi devices, if enable this feature it will reduce the
performance. Therefore, add an option for disabling HS park mode by
device-tree.
In Synopsys's dwc3 data book:
In a few high speed devices when an IN request is sent within 900ns of the
ACK of the previous packet, these devices send a NAK. When connected to
these devices, if required, the software can disable the park mode if you
see performance drop in your system. When park mode is disabled,
pipelining of multiple packet is disabled and instead one packet at a time
is requested by the scheduler. This allows up to 12 NAKs in a micro-frame
and improves performance of these slow devices.
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
Link: https://lore.kernel.org/r/20230419020044.15475-1-stanley_chang@realtek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug:285992796
(cherry picked from commit d21a797a3e
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git master)
Change-Id: I81f3a0bf15d2405fbb85bbe3a55cdbeb015ce48e
Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
In the 3.0 device core, if the core is programmed to operate in
2.0 only, then setting the GUCTL1.DEV_FORCE_20_CLK_FOR_30_CLK makes
the internal 2.0(utmi/ulpi) clock to be routed as the 3.0 (pipe)
clock. Enabling this feature allows the pipe3 clock to be not-running
when forcibly operating in 2.0 device mode.
Tested-by: Michael Riesch <michael.riesch@wolfvision.net>
Signed-off-by: Bin Yang <yangbin@rock-chips.com>
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
Link: https://lore.kernel.org/r/20220228135700.1089526-6-pgwipeout@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug:285984663
(cherry picked from commit 62b20e6e0d
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git master)
Change-Id: I104aefd490413cc3ee8d9bceefba01c5b29a3250
Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
Add symbol list for Lenovo
1 function symbol added
'rebuild_sched_domains()'
Bug: 286015587
Change-Id: I35fe23cc6314fb6b7bf564f0fd749141f4c33752
Signed-off-by: vincent wang <vincentwang3@lenovo.com>
Vendor module needs to rebuild sched domains at boot, in the
event that cpufreq initializes the energy model too late.
Bug: 242898038
Change-Id: Ifaf1223366ac81c3f3c382dd0f61110fce9c1b20
Signed-off-by: Stephen Dickey <quic_dickey@quicinc.com>
(cherry picked from commit 20ba031cf8)
Adding the following symbols:
- snd_pcm_hw_constraint_integer
- snd_soc_set_runtime_hwparams
Bug: 264508873
Change-Id: I5616a0aa475456abdfb466d62c08accd5f8b222f
Signed-off-by: Robert Lee <lerobert@google.com>
PCIe r6.0, sec 5.9, requires a 10ms delay between programming a device to
change to or from D3hot and the time the device is next accessed (unless
Readiness Notifications are used).
The 10ms value (PCI_PM_D3HOT_WAIT) doesn't appear directly here because
some chipsets require 120ms for devices *below* them (pci_pm_d3hot_delay)
and some devices require more or less than 10ms (dev->d3hot_delay).
But msleep(10) typically waits about *20*ms, which is more than we need.
Switch to usleep_range() to improve the delay accuracy.
Based on a commit from Sajid in the Pixel 6 kernel tree [1]. On a Pixel 6,
the 10ms delay for the Exynos PCIe device delayed for an average of 19ms.
Switching to usleep_range() decreased the resume time by about 9ms.
[1] 18a8cad68d
[bhelgaas commit log, add timers-howto.rst link]
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/timers/timers-howto.rst?id=v5.19#n73
Link: https://lore.kernel.org/r/20220921212735.2131588-1-willmcvicker@google.com
Signed-off-by: Sajid Dalvi <sdalvi@google.com>
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Bug: 258100247
Change-Id: Iacde62a3ec8e4b924a21fb654c89a18df2ee2b87
(cherry picked from commit 3e347969a5)
Signed-off-by: Sajid Dalvi <sdalvi@google.com>
Android 14 and later default to MGLRU [1] and field telemetry showed
occasional long tail latency (>100ms) in the reclaim path.
Tracing revealed priority inversion in the reclaim path. In
try_to_inc_max_seq(), when high priority tasks were blocked on
wait_event_killable(), the preemption of the low priority task to call
wake_up_all() caused those high priority tasks to wait longer than
necessary. In general, this problem is not different from others of its
kind, e.g., one caused by mutex_lock(). However, it is specific to MGLRU
because it introduced the new wait queue lruvec->mm_state.wait.
The purpose of this new wait queue is to avoid the thundering herd
problem. If many direct reclaimers rush into try_to_inc_max_seq(), only
one can succeed, i.e., the one to wake up the rest, and the rest who
failed might cause premature OOM kills if they do not wait. So far there
is no evidence supporting this scenario, based on how often the wait has
been hit. And this begs the question how useful the wait queue is in
practice.
Based on Minchan's recommendation, which is in line with his commit
6d4675e601 ("mm: don't be stuck to rmap lock on reclaim path") and the
rest of the MGLRU code which also uses trylock when possible, remove the
wait queue.
[1] https://android-review.googlesource.com/q/I7ed7fbfd6ef9ce10053347528125dd98c39e50bf
Link: https://lkml.kernel.org/r/20230413214326.2147568-1-kaleshsingh@google.com
Fixes: bd74fdaea1 ("mm: multi-gen LRU: support page table walks")
Change-Id: Ia2c65c92652018bb833e632028075ea27b68477e
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Suggested-by: Minchan Kim <minchan@kernel.org>
Reported-by: Wei Wang <wvw@google.com>
Acked-by: Yu Zhao <yuzhao@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Cc: Oleksandr Natalenko <oleksandr@natalenko.name>
Cc: Suleiman Souhlal <suleiman@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 7f63cf2d9b)
Bug: 277906484
[ Kalesh Singh - Fix conflicts in mm/vmscan.c ]
[ Kalesh Singh - Fix up ABI breakages in include/linux/mmzone.h ]
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
On Android app cycle workloads, MGLRU showed a significant reduction in
workingset refaults although pgpgin/pswpin remained relatively unchanged.
This indicated MGLRU may be undercounting workingset refaults.
This has impact on userspace programs, like Android's LMKD, that monitor
workingset refault statistics to detect thrashing.
It was found that refaults were only accounted if the MGLRU shadow entry
was for a recently evicted folio. However, recently evicted folios should
be accounted as workingset activation, and refaults should be accounted
regardless of recency.
Fix MGLRU's workingset refault and activation accounting to more closely
match that of the conventional active/inactive LRU.
Link: https://lkml.kernel.org/r/20230523205922.3852731-1-kaleshsingh@google.com
Fixes: ac35a49023 ("mm: multi-gen LRU: minimal implementation")
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Reported-by: Charan Teja Kalla <quic_charante@quicinc.com>
Acked-by: Yu Zhao <yuzhao@google.com>
Cc: Brian Geffon <bgeffon@google.com>
Cc: Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Cc: Oleksandr Natalenko <oleksandr@natalenko.name>
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 02ad728453d2ddb09d7ce5e59854ebb27544d488 https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable)
Bug: 284043217
[ Kalesh Singh - Fix conflicts in mm/workingset.c ]
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Change-Id: I6d42cca9064e66099fbbc20aa2143961f84b2003
Disable CONFIG_ARM64_BTI_KERNEL since significant overhead has been observed
on systems that don't have BTI/PAC hardware support due to increased number
of NOPs added by these features.
BTI is not as important in kernels that have CFI enabled because the protection
these features offer overlap.
Keep PAC enabled and also enable dynamic SCS (CONFIG_UNWIND_PATCH_PAC_INTO_SCS)
which is available starting in v6.2. This removes SCS overhead on systems that
support PAC, and PAC overhead on systems that need SCS instead. This feature uses
runtime code patching, so it won't have the overhead of additional NOPs.
Bug: 267119345
Change-Id: Ifc7d5e502940bd15d13e7f89c5facd10b6c7b8a8
Signed-off-by: Todd Kjos <tkjos@google.com>
Implement dynamic shadow call stack support on Clang, by parsing the
unwind tables at init time to locate all occurrences of PACIASP/AUTIASP
instructions, and replacing them with the shadow call stack push and pop
instructions, respectively.
This is useful because the overhead of the shadow call stack is
difficult to justify on hardware that implements pointer authentication
(PAC), and given that the PAC instructions are executed as NOPs on
hardware that doesn't, we can just replace them without breaking
anything. As PACIASP/AUTIASP are guaranteed to be paired with respect to
manipulations of the return address, replacing them 1:1 with shadow call
stack pushes and pops is guaranteed to result in the desired behavior.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://lore.kernel.org/r/20221027155908.1940624-4-ardb@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 3b619e22c4)
Bug: 283954062
Change-Id: Idca66f03315191a9fb18ed17d5b79c5bfacc51b8
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
In order to allow arches to use code patching to conditionally emit the
shadow stack pushes and pops, rather than always taking the performance
hit even on CPUs that implement alternatives such as stack pointer
authentication on arm64, add a Kconfig symbol that can be set by the
arch to omit the SCS codegen itself, without otherwise affecting how
support code for SCS and compiler options (for register reservation, for
instance) are emitted.
Also, add a static key and some plumbing to omit the allocation of
shadow call stack for dynamic SCS configurations if SCS is disabled at
runtime.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://lore.kernel.org/r/20221027155908.1940624-3-ardb@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 9beccca098)
Bug: 283954062
Change-Id: I71ed23533124b071bd6bf5ab91b2af3bbf03b42b
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Enable asynchronous unwind table generation for both the core kernel as
well as modules, and emit the resulting .eh_frame sections as init code
so we can use the unwind directives for code patching at boot or module
load time.
This will be used by dynamic shadow call stack support, which will rely
on code patching rather than compiler codegen to emit the shadow call
stack push and pop instructions.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://lore.kernel.org/r/20221027155908.1940624-2-ardb@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 68c76ad4a9)
Bug: 283954062
Change-Id: I2e17c7171295dc3859ff385b11a10048f6c87ec5
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Setting CONFIG_PM_ADVANCED_DEBUG=y to expose device async fields
to userspace, allowing to fine-tune the suspend/resume path.
Bug: 235135485
Change-Id: I75060e88ce0c1e199aa8740f446a2c0f8167f3d7
Signed-off-by: Vincent Palomares <paillon@google.com>
Instead of running the request queue of each device associated with a
host every 3 ms (BLK_MQ_RESOURCE_DELAY) while host error handling is in
progress, run the request queue after error handling has finished.
Bug: 280478861
Change-Id: Icd06853dc4868778bc7942d7fac6de71a7a80f71
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Make the SCSI sense data available in the ftrace output.
Bug: 275581839
Change-Id: I0fc87346effe71940a450d3a114365029d851b77
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Patch "block: mq-deadline: Handle requeued requests correctly" broke
support for zone sizes that are not a power of two. Restore support for
zone sizes that are not a power of two.
Bug: 275581839
Change-Id: I05d1b3253247f21583891502291e4a861bebb15e
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Make it easier to debug out-of-order zoned writes.
Bug: 275581839
Change-Id: I5d1f1cd47ff1b4c10788edeebba5e80bd82b2bf3
Signed-off-by: Bart Van Assche <bvanassche@google.com>
If a queue is run before all requeued requests have been sent to the I/O
scheduler, the I/O scheduler may dispatch the wrong request. Fix this by
making __blk_mq_run_hw_queue() process the requeue_list instead of
blk_mq_requeue_work().
Bug: 275581839
Change-Id: Id72c0787607f90857ae8e75998d532b96b46b8c2
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Requeue requests instead of sending these to the dispatch list if a CPU
is unplugged to prevent reordering of zoned writes.
Bug: 275581839
Change-Id: I2f03ba0832fc9609472c2bfa19d2cdd8abeffd8d
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Make sure that the I/O scheduler has control over which requests are
dispatched.
Bug: 275581839
Change-Id: If8c70df11584b023c452fbba28c67b092ddac850
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Send requests with the REQ_FUA or REQ_PREFLUSH flag set to the I/O
scheduler. Do not change the behavior for REQ_OP_FLUSH requests.
This patch prevents that zoned writes with the REQ_FUA and/or
REQ_PREFLUSH flag set are reordered against each other.
Bug: 275581839
Change-Id: Ib7f18932a066c40f5b76dc69c1864a080350251d
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Combine two return statements into a single return statement.
Bug: 275581839
Change-Id: I543e3dad88766157c0c334def4d525c10334e476
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Remove the 'hctx' argument because it is not used.
Bug: 275581839
Change-Id: I1f632931bc6c3d1ad89c4e6e93417c7301699559
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Set KMI_GENERATION=7 for 5/24 KMI update
type 'struct binder_transaction' changed
byte size changed from 176 to 192
member 'pid_t from_pid' was added
member 'pid_t from_tid' was added
13 members ('struct binder_transaction* from_parent' .. 'kuid_t sender_euid') changed
offset changed by 64
member 'ktime_t start_time' was added
4 members ('struct list_head fd_fixups' .. 'u64 android_vendor_data1') changed
offset changed by 128
Bug: 283322303
Change-Id: Ic9eaacc3707e86614dfb9fc6abde30ba722ed3bf
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This commit adds support for getting the pid and tid information of
the sender for asynchronous transfers in binderfs transfer records.
In previous versions, it was not possible to obtain this information
from the transfer records. While this information may not be necessary
for all use cases, it can be useful in some scenarios.
Signed-off-by: Chuang Zhang <zhangchuang3@xiaomi.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/0c1e8bd37c68dd1518bb737b06b768cde9659386.1682333709.git.zhangchuang3@xiaomi.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 235773151
(cherry picked from commit c21c0f9a20
git: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
char-misc-next)
Change-Id: I7e729853353522164c4a3dd1094145dfd19af961
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This reverts commit ad2bd67e07.
Qualcomm is reporting that internal debugging tools in addition to
Lauterbach Trace32 (T32) debugger (vLT_20230509_159359) are having
issues with DWARFv5.
Since the change to the DWARF debug info format was made after the
Android Feature Complete deadline, revert it from android14-* kernel
branches. We'll leave DWARFv5 for android-mainline and try again next
release in android15-*.
Bug: 281863640
Reported-by: Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.com>
Change-Id: I5a1657bdf6785d23f3492dc12e6f3df0954b8deb
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
