This patch enables KCSAN for arm64, with updates to build rules
to not use KCSAN for several incompatible compilation units.
Recent GCC version(at least GCC10) made outline-atomics as the
default option(unlike Clang), which will cause linker errors
for kernel/kcsan/core.o. Disables the out-of-line atomics by
no-outline-atomics to fix the linker errors.
Meanwhile, as Mark said[1], some latent issues are needed to be
fixed which isn't just a KCSAN problem, we make the KCSAN depends
on EXPERT for now.
Tested selftest and kcsan_test(built with GCC11 and Clang 13),
and all passed.
[1] https://lkml.kernel.org/r/YadiUPpJ0gADbiHQ@FVFF77S0Q05N
Acked-by: Marco Elver <elver@google.com> # kernel/kcsan
Tested-by: Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Link: https://lore.kernel.org/r/20211211131734.126874-1-wangkefeng.wang@huawei.com
[catalin.marinas@arm.com: added comment to justify EXPERT]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 286152957
Change-Id: I369e13fdd1a86c5c5dca0e72c60eae5fb1595299
(cherry picked from commit dd03762ab6)
[joey: Resolve minor conflicts in arch/arm64/Kconfig,
arch/arm64/kvm/hyp/nvhe/Makefile,
kernel/kcsan/Makefile]
Signed-off-by: Joey Jiao <quic_jiangenj@quicinc.com>
See also commit 9102217567.
Revert the code that sends requests back to the I/O scheduler if
dispatching fails because it is suspected to have introduced the
following BFQ crash:
==================================================================
BUG: KASAN: invalid-access in bfq_get_queue+0x500/0x560
Write at addr faffff8056fd8b30 by task Thread-11/27396
Pointer tag: [fa], memory tag: [fe]
CPU: 5 PID: 27396 Comm: Thread-11 Tainted: G S W OE 5.15.110-android14-7-00150-gf82b53108826-ab10234611 #1
Call trace:
dump_backtrace+0xf8/0x1e8
dump_stack_lvl+0x74/0xa4
print_report+0x344/0x958
kasan_report+0x90/0xe4
__do_kernel_fault+0xc4/0x2ac
do_bad_area+0x3c/0x154
do_tag_check_fault+0x18/0x24
do_mem_abort+0x60/0x134
el1_abort+0x38/0x54
el1h_64_sync_handler+0x54/0x88
el1h_64_sync+0x78/0x7c
bfq_get_queue+0x500/0x560
bfq_insert_requests+0x98c/0x1474
blk_mq_sched_insert_requests+0xec/0x334
blk_mq_flush_plug_list+0x138/0x234
blk_flush_plug_list+0x118/0x164
read_pages+0x38c/0x408
page_cache_ra_unbounded+0x22c/0x2f4
do_sync_mmap_readahead+0x1a4/0x208
filemap_fault+0x27c/0x8f4
f2fs_filemap_fault+0x28/0xfc
__do_fault+0xc0/0x204
handle_pte_fault+0x28c/0xdf8
do_handle_mm_fault+0x504/0x7b8
do_page_fault+0x5dc/0x798
do_translation_fault+0x40/0x54
do_mem_abort+0x60/0x134
el0_ia+0x74/0x158
el0t_64_sync_handler+0xac/0xe4
el0t_64_sync+0x1b0/0x1b4
The buggy address belongs to the object at ffffff8056fd8a50
which belongs to the cache bfq_io_cq of size 232
The buggy address is located 224 bytes inside of
232-byte region [ffffff8056fd8a50, ffffff8056fd8b38)
The buggy address belongs to the physical page:
page:00000000a0db99e0 refcount:1 mapcount:0 mapping:0000000000000000 index:0xfaffff8056fd8a50 pfn:0xd6fd8
head:00000000a0db99e0 order:1 compound_mapcount:0
flags: 0x4000000000010200(slab|head|zone=1|kasantag=0x0)
raw: 4000000000010200 fffffffe2306b300 0000000400000004 f2ffff800a71f700
raw: faffff8056fd8a50 000000008022001d 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffffff8056fd8900: fe fe fe fe fe fe fd fd fd fd fd fd fd fd fd fd
ffffff8056fd8a00: fd fd fd fd fd fe fe fe fe fe fe fe fe fe fe fe
>ffffff8056fd8b00: fe fe fe fe fb fb fb fb fb fb fb fb fb fb fb fb
^
ffffff8056fd8c00: fb fb fb f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4
ffffff8056fd8d00: f4 f4 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
==================================================================
Bug: 285769645
Change-Id: Ia870feee81988ae47a2be0e1b145d18165588f8a
Signed-off-by: Bart Van Assche <bvanassche@google.com>
This reverts commit 88819308f5.
Revert this commit in preparation of partially reverting "Send requeued
requests to the I/O scheduler".
Bug: 285769645
Change-Id: Ic447d3a245957c4b6a739cbe87503b6a14c8d627
Signed-off-by: Bart Van Assche <bvanassche@google.com>
This adds passthrough only support for ioctls with fuse-bpf.
compat_ioctls will return -ENOTTY.
Bug: 279519292
Test: F2fsMiscTest#testAtomicWrite
Change-Id: Ia3052e465d87dc1d15ae13955fba8a7f93bc387b
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Set KMI_GENERATION=8 for 6/7 KMI update
1 function symbol(s) removed
'void __sock_recv_ts_and_drops(struct msghdr*, struct sock*, struct sk_buff*)'
function symbol changed from 'int ufshcd_hold(struct ufs_hba*, bool)' to 'void ufshcd_hold(struct ufs_hba*, bool)'
CRC changed from 0x97fc06b5 to 0x35a1ce51
type changed from 'int(struct ufs_hba*, bool)' to 'void(struct ufs_hba*, bool)'
return type changed from 'int' to 'void'
function symbol 'struct block_device* I_BDEV(struct inode*)' changed
CRC changed from 0x5c732fed to 0x6ad768b0
function symbol 'void* PDE_DATA(const struct inode*)' changed
CRC changed from 0x782fda7f to 0x1b12d990
function symbol 'void __ClearPageMovable(struct page*)' changed
CRC changed from 0xdf0d01db to 0x5ed16e08
... 3668 omitted; 3671 symbols have only CRC changes
type 'struct page' changed
member 'union { struct { union { struct list_head lru; struct list_head buddy_list; struct list_head pcp_list; }; struct address_space* mapping; unsigned long index; unsigned long private; }; struct { unsigned long pp_magic; struct page_pool* pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; union { unsigned long dma_addr_upper; atomic_long_t pp_frag_count; }; }; struct { union { struct list_head slab_list; struct { struct page* next; int pages; int pobjects; }; }; struct kmem_cache* slab_cache; void* freelist; union { void* s_mem; unsigned long counters; struct { unsigned int inuse:16; unsigned int objects:15; unsigned int frozen:1; }; }; }; struct { unsigned long compound_head; unsigned char compound_dtor; unsigned char compound_order; atomic_t compound_mapcount; unsigned int compound_nr; }; struct { unsigned long _compound_pad_1; atomic_t hpage_pinned_refcount; struct list_head deferred_list; }; struct { unsigned long _pt_pad_1; pgtable_t pmd_huge_pte; unsigned long _pt_pad_2; union { struct mm_struct* pt_mm; atomic_t pt_frag_refcount; }; spinlock_t ptl; }; struct { struct dev_pagemap* pgmap; void* zone_device_data; }; struct callback_head callback_head; }' was added
member 'union { struct { struct list_head lru; struct address_space* mapping; unsigned long index; unsigned long private; }; struct { unsigned long pp_magic; struct page_pool* pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; union { unsigned long dma_addr_upper; atomic_long_t pp_frag_count; }; }; struct { union { struct list_head slab_list; struct { struct page* next; int pages; int pobjects; }; }; struct kmem_cache* slab_cache; void* freelist; union { void* s_mem; unsigned long counters; struct { unsigned int inuse:16; unsigned int objects:15; unsigned int frozen:1; }; }; }; struct { unsigned long compound_head; unsigned char compound_dtor; unsigned char compound_order; atomic_t compound_mapcount; unsigned int compound_nr; }; struct { unsigned long _compound_pad_1; atomic_t hpage_pinned_refcount; struct list_head deferred_list; }; struct { unsigned long _pt_pad_1; pgtable_t pmd_huge_pte; unsigned long _pt_pad_2; union { struct mm_struct* pt_mm; atomic_t pt_frag_refcount; }; spinlock_t ptl; }; struct { struct dev_pagemap* pgmap; void* zone_device_data; }; struct callback_head callback_head; }' was removed
type 'struct request_queue' changed
byte size changed from 2240 to 2104
member 'struct delayed_work requeue_work' was removed
22 members ('struct mutex sysfs_lock' .. 'u64 android_oem_data1') changed
offset changed by -1088
type 'struct Scsi_Host' changed
member 'unsigned int queuecommand_may_block:1' was added
2 members ('unsigned int short_inquiry:1' .. 'unsigned int no_scsi2_lun_in_cdb:1') changed
offset changed by 1
type 'struct pglist_data' changed
byte size changed from 7168 to 7232
2 members ('unsigned long flags' .. 'struct lru_gen_mm_walk mm_walk') changed
offset changed by 128
member 'struct lru_gen_memcg memcg_lru' changed
offset changed by 256
3 members ('struct zone_padding _pad2_' .. 'atomic_long_t vm_stat[41]') changed
offset changed by 512
type 'struct phy_device' changed
byte size changed from 1600 to 1640
member 'struct phy_led_trigger* phy_led_triggers' was added
member 'unsigned int phy_num_led_triggers' was added
member 'struct phy_led_trigger* last_triggered' was added
member 'struct phy_led_trigger* led_link_trigger' was added
member 'int irq' changed
offset changed by 288
21 members ('void* priv' .. 'u64 android_kabi_reserved4') changed
offset changed by 320
type 'struct scsi_host_template' changed
member 'unsigned int queuecommand_may_block:1' was added
type 'struct mem_cgroup_per_node' changed
byte size changed from 2080 to 2096
9 members ('struct lruvec_stats_percpu* lruvec_stats_percpu' .. 'struct mem_cgroup* memcg') changed
offset changed by 128
type 'struct per_cpu_pages' changed
byte size changed from 336 to 320
member 'spinlock_t lock' was added
4 members ('int count' .. 'short free_factor') changed
offset changed by 32
member changed from 'struct list_head lists[20]' to 'struct list_head lists[17]'
offset changed from 128 to 192
type changed from 'struct list_head[20]' to 'struct list_head[17]'
number of elements changed from 20 to 17
type 'struct swap_info_struct' changed
byte size changed from 288 to 296
member 'u64 android_vendor_data1' was added
member 'struct plist_node avail_lists[0]' changed
offset changed by 64
type 'struct lruvec' changed
byte size changed from 1224 to 1240
member 'struct lru_gen_mm_state mm_state' changed
offset changed by 128
member 'struct pglist_data* pgdat' changed
offset changed by -64
member 'u64 android_vendor_data1' was added
member 'u64 android_kabi_reserved1' was added
member 'u64 android_kabi_reserved2' was added
type 'struct lru_gen_mm_walk' changed
byte size changed from 152 to 168
member 'u64 android_kabi_reserved1' was added
member 'u64 android_kabi_reserved2' was added
type 'struct lru_gen_memcg' changed
byte size changed from 160 to 176
member 'u64 android_kabi_reserved1' was added
member 'u64 android_kabi_reserved2' was added
type 'struct lru_gen_page' changed
byte size changed from 960 to 976
member 'u64 android_kabi_reserved1' was added
member 'u64 android_kabi_reserved2' was added
type 'struct lru_gen_mm_state' changed
byte size changed from 120 to 96
member 'struct wait_queue_head wait' was removed
2 members ('unsigned long* filters[2]' .. 'unsigned long stats[1][6]') changed
offset changed by -192
member 'u64 android_kabi_reserved1' was added
member 'int nr_walkers' was removed
Bug: 285364323
Change-Id: I7bde6d93581c7abf225556bdcec7efe25edcc572
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Enable CONFIG_LED_TRIGGER_PHY to support for tracking link state.
This also makes GKI on arm64 consistent with GKI on x86.
This could affect KMI breakage by changing struct phy_device,
so it should be fixed until KMI freeze.
Bug: 278043288
Change-Id: I45839d6199787f4e52e74cba4ab004ed72957098
Signed-off-by: Norihiko Hama <Norihiko.Hama@alpsalpine.com>
struct per_cpu_pages is no longer strictly local as PCP lists can be
drained remotely using a lock for protection. While the use of local_lock
works, it goes against the intent of local_lock which is for "pure CPU
local concurrency control mechanisms and not suited for inter-CPU
concurrency control" (Documentation/locking/locktypes.rst)
local_lock protects against migration between when the percpu pointer is
accessed and the pcp->lock acquired. The lock acquisition is a preemption
point so in the worst case, a task could migrate to another NUMA node and
accidentally allocate remote memory. The main requirement is to pin the
task to a CPU that is suitable for PREEMPT_RT and !PREEMPT_RT.
Replace local_lock with helpers that pin a task to a CPU, lookup the
per-cpu structure and acquire the embedded lock. It's similar to
local_lock without breaking the intent behind the API. It is not a
complete API as only the parts needed for PCP-alloc are implemented but in
theory, the generic helpers could be promoted to a general API if there
was demand for an embedded lock within a per-cpu struct with a guarantee
that the per-cpu structure locked matches the running CPU and cannot use
get_cpu_var due to RT concerns. PCP requires these semantics to avoid
accidentally allocating remote memory.
[mgorman@techsingularity.net: use pcp_spin_trylock_irqsave instead of pcpu_spin_trylock_irqsave]
Link: https://lkml.kernel.org/r/20220627084645.GA27531@techsingularity.net
Link: https://lkml.kernel.org/r/20220624125423.6126-8-mgorman@techsingularity.net
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Tested-by: Yu Zhao <yuzhao@google.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Tested-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Tested-by: Yu Zhao <yuzhao@google.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 230899966
(cherry picked from commit 01b44456a7)
Change-Id: Ia2b4606f93b4e39b99cb9a525024158c03fd5469
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Some setups, notably NOHZ_FULL CPUs, are too busy to handle the per-cpu
drain work queued by __drain_all_pages(). So introduce a new mechanism to
remotely drain the per-cpu lists. It is made possible by remotely locking
'struct per_cpu_pages' new per-cpu spinlocks. A benefit of this new
scheme is that drain operations are now migration safe.
There was no observed performance degradation vs. the previous scheme.
Both netperf and hackbench were run in parallel to triggering the
__drain_all_pages(NULL, true) code path around ~100 times per second. The
new scheme performs a bit better (~5%), although the important point here
is there are no performance regressions vs. the previous mechanism.
Per-cpu lists draining happens only in slow paths.
Minchan Kim tested an earlier version and reported;
My workload is not NOHZ CPUs but run apps under heavy memory
pressure so they goes to direct reclaim and be stuck on
drain_all_pages until work on workqueue run.
unit: nanosecond
max(dur) avg(dur) count(dur)
166713013 487511.77786438033 1283
From traces, system encountered the drain_all_pages 1283 times and
worst case was 166ms and avg was 487us.
The other problem was alloc_contig_range in CMA. The PCP draining
takes several hundred millisecond sometimes though there is no
memory pressure or a few of pages to be migrated out but CPU were
fully booked.
Your patch perfectly removed those wasted time.
Link: https://lkml.kernel.org/r/20220624125423.6126-7-mgorman@techsingularity.net
Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Tested-by: Yu Zhao <yuzhao@google.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Hugh Dickins <hughd@google.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 230899966
(cherry picked from commit 443c2accd1)
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I8c4120d215836b04c53d0e4950a821fce4c99075
Currently the PCP lists are protected by using local_lock_irqsave to
prevent migration and IRQ reentrancy but this is inconvenient. Remote
draining of the lists is impossible and a workqueue is required and every
task allocation/free must disable then enable interrupts which is
expensive.
As preparation for dealing with both of those problems, protect the
lists with a spinlock. The IRQ-unsafe version of the lock is used
because IRQs are already disabled by local_lock_irqsave. spin_trylock
is used in combination with local_lock_irqsave() but later will be
replaced with a spin_trylock_irqsave when the local_lock is removed.
The per_cpu_pages still fits within the same number of cache lines after
this patch relative to before the series.
struct per_cpu_pages {
spinlock_t lock; /* 0 4 */
int count; /* 4 4 */
int high; /* 8 4 */
int batch; /* 12 4 */
short int free_factor; /* 16 2 */
short int expire; /* 18 2 */
/* XXX 4 bytes hole, try to pack */
struct list_head lists[13]; /* 24 208 */
/* size: 256, cachelines: 4, members: 7 */
/* sum members: 228, holes: 1, sum holes: 4 */
/* padding: 24 */
} __attribute__((__aligned__(64)));
There is overhead in the fast path due to acquiring the spinlock even
though the spinlock is per-cpu and uncontended in the common case. Page
Fault Test (PFT) running on a 1-socket reported the following results on a
1 socket machine.
5.19.0-rc3 5.19.0-rc3
vanilla mm-pcpspinirq-v5r16
Hmean faults/sec-1 869275.7381 ( 0.00%) 874597.5167 * 0.61%*
Hmean faults/sec-3 2370266.6681 ( 0.00%) 2379802.0362 * 0.40%*
Hmean faults/sec-5 2701099.7019 ( 0.00%) 2664889.7003 * -1.34%*
Hmean faults/sec-7 3517170.9157 ( 0.00%) 3491122.8242 * -0.74%*
Hmean faults/sec-8 3965729.6187 ( 0.00%) 3939727.0243 * -0.66%*
There is a small hit in the number of faults per second but given that the
results are more stable, it's borderline noise.
[akpm@linux-foundation.org: add missing local_unlock_irqrestore() on contention path]
Link: https://lkml.kernel.org/r/20220624125423.6126-6-mgorman@techsingularity.net
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Tested-by: Yu Zhao <yuzhao@google.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Tested-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Hugh Dickins <hughd@google.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 230899966
(cherry picked from commit 4b23a68f95)
[surenb: resolved merge conflicts due to the differences with 6.0]
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I03ff1c22301e7f8735947e71413376ea143e855a
The per_cpu_pages is cache-aligned on a standard x86-64 distribution
configuration but a later patch will add a new field which would push the
structure into the next cache line. Use only one list to store THP-sized
pages on the per-cpu list. This assumes that the vast majority of
THP-sized allocations are GFP_MOVABLE but even if it was another type, it
would not contribute to serious fragmentation that potentially causes a
later THP allocation failure. Align per_cpu_pages on the cacheline
boundary to ensure there is no false cache sharing.
After this patch, the structure sizing is;
struct per_cpu_pages {
int count; /* 0 4 */
int high; /* 4 4 */
int batch; /* 8 4 */
short int free_factor; /* 12 2 */
short int expire; /* 14 2 */
struct list_head lists[13]; /* 16 208 */
/* size: 256, cachelines: 4, members: 6 */
/* padding: 32 */
} __attribute__((__aligned__(64)));
Link: https://lkml.kernel.org/r/20220624125423.6126-3-mgorman@techsingularity.net
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Tested-by: Minchan Kim <minchan@kernel.org>
Acked-by: Minchan Kim <minchan@kernel.org>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Tested-by: Yu Zhao <yuzhao@google.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 230899966
(cherry picked from commit 5d0a661d80)
[surenb: fixed trivial merge conflicts]
Change-Id: Id4e625a0400aaba24961a221d23926bb6d2712ce
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Patch series "Drain remote per-cpu directly", v5.
Some setups, notably NOHZ_FULL CPUs, may be running realtime or
latency-sensitive applications that cannot tolerate interference due to
per-cpu drain work queued by __drain_all_pages(). Introduce a new
mechanism to remotely drain the per-cpu lists. It is made possible by
remotely locking 'struct per_cpu_pages' new per-cpu spinlocks. This has
two advantages, the time to drain is more predictable and other unrelated
tasks are not interrupted.
This series has the same intent as Nicolas' series "mm/page_alloc: Remote
per-cpu lists drain support" -- avoid interference of a high priority task
due to a workqueue item draining per-cpu page lists. While many workloads
can tolerate a brief interruption, it may cause a real-time task running
on a NOHZ_FULL CPU to miss a deadline and at minimum, the draining is
non-deterministic.
Currently an IRQ-safe local_lock protects the page allocator per-cpu
lists. The local_lock on its own prevents migration and the IRQ disabling
protects from corruption due to an interrupt arriving while a page
allocation is in progress.
This series adjusts the locking. A spinlock is added to struct
per_cpu_pages to protect the list contents while local_lock_irq is
ultimately replaced by just the spinlock in the final patch. This allows
a remote CPU to safely. Follow-on work should allow the spin_lock_irqsave
to be converted to spin_lock to avoid IRQs being disabled/enabled in most
cases. The follow-on patch will be one kernel release later as it is
relatively high risk and it'll make bisections more clear if there are any
problems.
Patch 1 is a cosmetic patch to clarify when page->lru is storing buddy pages
and when it is storing per-cpu pages.
Patch 2 shrinks per_cpu_pages to make room for a spin lock. Strictly speaking
this is not necessary but it avoids per_cpu_pages consuming another
cache line.
Patch 3 is a preparation patch to avoid code duplication.
Patch 4 is a minor correction.
Patch 5 uses a spin_lock to protect the per_cpu_pages contents while still
relying on local_lock to prevent migration, stabilise the pcp
lookup and prevent IRQ reentrancy.
Patch 6 remote drains per-cpu pages directly instead of using a workqueue.
Patch 7 uses a normal spinlock instead of local_lock for remote draining
This patch (of 7):
The page allocator uses page->lru for storing pages on either buddy or PCP
lists. Create page->buddy_list and page->pcp_list as a union with
page->lru. This is simply to clarify what type of list a page is on in
the page allocator.
No functional change intended.
[minchan@kernel.org: fix page lru fields in macros]
Link: https://lkml.kernel.org/r/20220624125423.6126-2-mgorman@techsingularity.net
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Tested-by: Minchan Kim <minchan@kernel.org>
Acked-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Tested-by: Yu Zhao <yuzhao@google.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 230899966
(cherry picked from commit bf75f20056)
[surenb: fixed trivial merge conflicts]
Change-Id: Ieef253fa28c2a411008da64b38716f6401a66961
Signed-off-by: Suren Baghdasaryan <surenb@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: 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>
