Previously it was possible to load a pKVM module after the userspace has
started, leaving on the modules the task of disabling the feature
(__pkvm_close_module_registration HVC).
Depreacte this way of loading modules in favor of the pre-userspace
loading via the cmdline kvm-arm.protected_modules=<module1>,<module2>.
Bug: 254835242
Change-Id: I38eef46b1482ff03af610b3b5d21b3ebfadda59b
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
[ qperret: fixed trivial conflict in nvhe/iommu.c due to aosp/2571370 ]
Signed-off-by: Quentin Perret <qperret@google.com>
Expose usb device state to userland as the information is useful in
detecting non-compliant setups and diagnosing enumeration failures.
For example:
- End-to-end signal integrity issues: the device would fail port reset
repeatedly and thus be stuck in POWERED state.
- Charge-only cables (missing D+/D- lines): the device would never enter
POWERED state as the HC would not see any pullup.
What's the status quo?
We do have error logs such as "Cannot enable. Maybe the USB cable is bad?"
to flag potential setup issues, but there's no good way to expose them to
userspace.
Why add a sysfs entry in struct usb_port instead of struct usb_device?
The struct usb_device is not device_add() to the system until it's in
ADDRESS state hence we would miss the first two states. The struct
usb_port is a better place to keep the information because its life
cycle is longer than the struct usb_device that is attached to the port.
Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202306042228.e532af6e-oliver.sang@intel.com
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Roy Luo <royluo@google.com>
Message-ID: <20230608015913.1679984-1-royluo@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(Backport conflicts: connector_ops wasn't there in port.c)
Bug: 285199434
(cherry picked from commit 83cb2604f6
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ usb-testing)
Signed-off-by: Roy Luo <royluo@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:ce2ae89fb6e5f73ae046aeb039a406ec10e626ba)
Change-Id: I1a0da6686e57be05ef10ae98892599eb37074014
Remove this log to avoid non-error conditions.
If CONFIG_USB_PHY is disabled, the following error message appears:
[ 0.231609] xhci-hcd f10f0000.usb3: xhci_plat_probe get usb3phy fail (ret=-6)
[ 0.239716] xhci-hcd f10f8000.usb3: xhci_plat_probe get usb3phy fail (ret=-6)
In this case, devm_usb_get_phy_by_phandle is declared static inline
and returns -ENXIO.
It is easy to pinpoint the failure to get the usb-phy using the debug
log in drivers/usb/phy/phy.c. Therefore, it can be removed.
Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Link: https://lore.kernel.org/r/20230510075129.28047-1-stanley_chang@realtek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 286930662
(cherry picked from commit 424e02931e
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
Change-Id: I872ceb810cd0389700342911cc601f1703d557cd
The Realtek RTD SoCs were designed with the global register address
offset at 0x8100. The default address offset is constant at
DWC3_GLOBALS_REGS_START (0xc100). Therefore, add a check if the
compatible name of the parent is realtek,rtd-dwc3, then global
register start address will remap to 0x8100.
Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20230505025104.18321-1-stanley_chang@realtek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 286930198
(cherry picked from commit ec5eb43813
git: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Change-Id: I436a3a3bd79696764ccd2fad104182ae8a1c9006
Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
Setting CONFIG_RPMSG_CTRL=y to add a user-space control interface
for RPMSG. It can provide a user-space program to create endpoints with
specific service name, source, and destination addresses.
Bug: 286965107
Change-Id: I86bc065d4b83582b3322f0823e46536ca5847cf6
Signed-off-by: James Tai <james.tai@realtek.com>
[ Upstream commit 8fe72b76db ]
There was a bug where this code forgot to unlock the tdev->mutex if the
kzalloc() failed. Fix this issue, by moving the allocation outside the
lock.
Bug: 275340532
Fixes: 2d1e952a2b ("mailbox: mailbox-test: Fix potential double-free in mbox_test_message_write()")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 7d233f9359)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I7a4a1bf06abbb2092aceb72610e3f894b2bfbf0f
[ Upstream commit 2d1e952a2b ]
If a user can make copy_from_user() fail, there is a potential for
UAF/DF due to a lack of locking around the allocation, use and freeing
of the data buffers.
This issue is not theoretical. I managed to author a POC for it:
BUG: KASAN: double-free in kfree+0x5c/0xac
Free of addr ffff29280be5de00 by task poc/356
CPU: 1 PID: 356 Comm: poc Not tainted 6.1.0-00001-g961aa6552c04-dirty #20
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace.part.0+0xe0/0xf0
show_stack+0x18/0x40
dump_stack_lvl+0x64/0x80
print_report+0x188/0x48c
kasan_report_invalid_free+0xa0/0xc0
____kasan_slab_free+0x174/0x1b0
__kasan_slab_free+0x18/0x24
__kmem_cache_free+0x130/0x2e0
kfree+0x5c/0xac
mbox_test_message_write+0x208/0x29c
full_proxy_write+0x90/0xf0
vfs_write+0x154/0x440
ksys_write+0xcc/0x180
__arm64_sys_write+0x44/0x60
invoke_syscall+0x60/0x190
el0_svc_common.constprop.0+0x7c/0x160
do_el0_svc+0x40/0xf0
el0_svc+0x2c/0x6c
el0t_64_sync_handler+0xf4/0x120
el0t_64_sync+0x18c/0x190
Allocated by task 356:
kasan_save_stack+0x3c/0x70
kasan_set_track+0x2c/0x40
kasan_save_alloc_info+0x24/0x34
__kasan_kmalloc+0xb8/0xc0
kmalloc_trace+0x58/0x70
mbox_test_message_write+0x6c/0x29c
full_proxy_write+0x90/0xf0
vfs_write+0x154/0x440
ksys_write+0xcc/0x180
__arm64_sys_write+0x44/0x60
invoke_syscall+0x60/0x190
el0_svc_common.constprop.0+0x7c/0x160
do_el0_svc+0x40/0xf0
el0_svc+0x2c/0x6c
el0t_64_sync_handler+0xf4/0x120
el0t_64_sync+0x18c/0x190
Freed by task 357:
kasan_save_stack+0x3c/0x70
kasan_set_track+0x2c/0x40
kasan_save_free_info+0x38/0x5c
____kasan_slab_free+0x13c/0x1b0
__kasan_slab_free+0x18/0x24
__kmem_cache_free+0x130/0x2e0
kfree+0x5c/0xac
mbox_test_message_write+0x208/0x29c
full_proxy_write+0x90/0xf0
vfs_write+0x154/0x440
ksys_write+0xcc/0x180
__arm64_sys_write+0x44/0x60
invoke_syscall+0x60/0x190
el0_svc_common.constprop.0+0x7c/0x160
do_el0_svc+0x40/0xf0
el0_svc+0x2c/0x6c
el0t_64_sync_handler+0xf4/0x120
el0t_64_sync+0x18c/0x190
Bug: 275340532
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit cad1abbe48)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I79753a9a63d8b04e139eaaeb9435bf1d05d38892
commit 7e01c7f704 upstream.
Currently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than
the calculated "min" value, but greater than zero, the logic sets
tx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB in
cdc_ncm_fill_tx_frame() where all the data is handled.
For small values of dwNtbOutMaxSize the memory allocated during
alloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due to
how size is aligned at alloc time:
size = SKB_DATA_ALIGN(size);
size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
Thus we hit the same bug that we tried to squash with
commit 2be6d4d16a ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero")
Low values of dwNtbOutMaxSize do not cause an issue presently because at
alloc_skb() time more memory (512b) is allocated than required for the
SKB headers alone (320b), leaving some space (512b - 320b = 192b)
for CDC data (172b).
However, if more elements (for example 3 x u64 = [24b]) were added to
one of the SKB header structs, say 'struct skb_shared_info',
increasing its original size (320b [320b aligned]) to something larger
(344b [384b aligned]), then suddenly the CDC data (172b) no longer
fits in the spare SKB data area (512b - 384b = 128b).
Consequently the SKB bounds checking semantics fails and panics:
skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:<NULL>
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:113!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 57 Comm: kworker/0:2 Not tainted 5.15.106-syzkaller-00249-g19c0ed55a470 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023
Workqueue: mld mld_ifc_work
RIP: 0010:skb_panic net/core/skbuff.c:113 [inline]
RIP: 0010:skb_over_panic+0x14c/0x150 net/core/skbuff.c:118
[snip]
Call Trace:
<TASK>
skb_put+0x151/0x210 net/core/skbuff.c:2047
skb_put_zero include/linux/skbuff.h:2422 [inline]
cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1131 [inline]
cdc_ncm_fill_tx_frame+0x11ab/0x3da0 drivers/net/usb/cdc_ncm.c:1308
cdc_ncm_tx_fixup+0xa3/0x100
Deal with too low values of dwNtbOutMaxSize, clamp it in the range
[USB_CDC_NCM_NTB_MIN_OUT_SIZE, CDC_NCM_NTB_MAX_SIZE_TX]. We ensure
enough data space is allocated to handle CDC data by making sure
dwNtbOutMaxSize is not smaller than USB_CDC_NCM_NTB_MIN_OUT_SIZE.
Fixes: 289507d336 ("net: cdc_ncm: use sysfs for rx/tx aggregation tuning")
Cc: stable@vger.kernel.org
Reported-by: syzbot+9f575a1f15fc0c01ed69@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=b982f1059506db48409d
Link: https://lore.kernel.org/all/20211202143437.1411410-1-lee.jones@linaro.org/
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20230517133808.1873695-2-tudor.ambarus@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 281604646
Bug: 281606231
Change-Id: Ic1d912e7bf2ba53620eb8293b68ec6046422e047
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The tarball, when implemented correctly, adds around
3.7MB of kheaders.tar.xz to the kernel image, which
increases memory usage. Since this tarball is usually
for debugging only, mark it as a module so it can
be conditionally loaded.
Bug: 276339429
Test: treehugger
Change-Id: Icc330a947ff25006fa48ffc5801d7a2746369893
Signed-off-by: Yifan Hong <elsk@google.com>
ISOC transfers expect a certain cadence of requests being queued. Not
keeping up with the expected rate of requests results in missed ISOC
transfers (EXDEV). The application layer may or may not produce video
frames to match this expectation, so uvc gadget driver must handle cases
where the application is not queuing up buffers fast enough to fulfill
ISOC requirements.
Currently, uvc gadget driver waits for new video buffer to become available
before queuing up usb requests. With this patch the gadget driver queues up
0 length usb requests whenever there are no video buffers available. The
USB controller's complete callback is used as the limiter for how quickly
the 0 length packets will be queued. Video buffers are still queued as
soon as they become available.
Link: https://lore.kernel.org/CAMHf4WKbi6KBPQztj9FA4kPvESc1fVKrC8G73-cs6tTeQby9=w@mail.gmail.com/
Signed-off-by: Avichal Rakesh <arakesh@google.com>
Link: https://lore.kernel.org/r/20230508231103.1621375-1-arakesh@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c3ff12a92b)
Bug: 271684194
Signed-off-by: Avichal Rakesh <arakesh@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:39cc781d6f7542117b07de2fd052e91cc21b66b5)
Change-Id: I3eed9b415f80ccea9c69b0d96593da8493dbf6bb
timerfd doesn't create any wakelocks, but eventpoll can. When it does,
it names them after the underlying file descriptor, and since all
timerfd file descriptors are named "[timerfd]" (which saves memory on
systems like desktops with potentially many timerfd instances), all
wakesources created as a result of using the eventpoll-on-timerfd idiom
are called... "[timerfd]".
However, it becomes impossible to tell which "[timerfd]" wakesource is
affliated with which process and hence troubleshooting is difficult.
Adding vendor hooks to allow vendor to assign appropriate names to
timerfd descriptors and eventoll wakesource.
Bug: 155142106
Signed-off-by: Manish Varma <varmam@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:0ff110fbb309be385126a42ac9f7004ba9b0644e)
Merged-In: I330a42ab48bed4b26d5eb2f636925c66061165ec
Change-Id: I330a42ab48bed4b26d5eb2f636925c66061165ec
Signed-off-by: Darren Hsu <darrenhsu@google.com>
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>
