GDB produces the following warning when debugging kernels built with
CONFIG_RELR:
BFD: /android0/linux-next/vmlinux: unknown type [0x13] section `.relr.dyn'
when loading a kernel built with CONFIG_RELR into GDB. It can also
prevent debugging symbols using such relocations.
Peter sugguests:
[That flag] means that lld will use dynamic tags and section type
numbers in the OS-specific range rather than the generic range. The
kernel itself doesn't care about these numbers; it determines the
location of the RELR section using symbols defined by a linker script.
Suggested-by: Peter Collingbourne <pcc@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://github.com/ClangBuiltLinux/linux/issues/1057
Bug: 182884953
(am from https://lore.kernel.org/linux-kbuild/20210319000708.1694662-1-ndesaulniers@google.com/T/#u)
Change-Id: I2c2508da33fcf3cf8485d63be60c523970e3d120
Leaf changes summary: 2670 artifacts changed
Changed leaf types summary: 22 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 2573 Changed, 19 Added functions
Removed/Changed/Added variables summary: 0 Removed, 49 Changed, 7 Added variables
19 Added functions:
[A] 'function void __cfi_slowpath(uint64_t, void*, void*)'
[A] 'function void* android_debug_per_cpu_symbol(android_debug_per_cpu_symbol)'
[A] 'function void* android_debug_symbol(android_debug_symbol)'
[A] 'function long int copy_from_kernel_nofault(void*, void*, size_t)'
[A] 'function irq_desc** ipi_desc_get()'
[A] 'function unsigned int kstat_irqs_cpu(unsigned int, int)'
[A] 'function unsigned int kstat_irqs_usr(unsigned int)'
[A] 'function char* log_buf_addr_get()'
[A] 'function u32 log_buf_len_get()'
[A] 'function int nr_ipi_get()'
[A] 'function int pci_dev_present(const pci_device_id*)'
[A] 'function phys_addr_t per_cpu_ptr_to_phys(void*)'
[A] 'function int register_die_notifier(notifier_block*)'
[A] 'function int register_module_notifier(notifier_block*)'
[A] 'function int sched_setattr(task_struct*, const sched_attr*)'
[A] 'function int seq_buf_printf(seq_buf*, const char*, ...)'
[A] 'function int sysfs_emit(char*, const char*, ...)'
[A] 'function int unregister_die_notifier(notifier_block*)'
[A] 'function int unregister_module_notifier(notifier_block*)'
2573 functions with some sub-type change:
[C] 'function void* PDE_DATA(const inode*)' at generic.c:799:1 has some sub-type changes:
CRC (modversions) changed from 0x8f0b8b7c to 0x44ca679
[C] 'function void __ClearPageMovable(page*)' at compaction.c:138:1 has some sub-type changes:
CRC (modversions) changed from 0x2f37d230 to 0x44484f05
[C] 'function void __SetPageMovable(page*, address_space*)' at compaction.c:130:1 has some sub-type changes:
CRC (modversions) changed from 0x5eea6e25 to 0x8978c2df
... 2570 omitted; 2573 symbols have only CRC changes
7 Added variables:
[A] 'tracepoint __tracepoint_android_vh_ftrace_dump_buffer'
[A] 'tracepoint __tracepoint_android_vh_ftrace_format_check'
[A] 'tracepoint __tracepoint_android_vh_ftrace_oops_enter'
[A] 'tracepoint __tracepoint_android_vh_ftrace_oops_exit'
[A] 'tracepoint __tracepoint_android_vh_ftrace_size_check'
[A] 'kernel_stat kstat'
[A] 'int nr_irqs'
49 Changed variables:
[C] 'task_struct init_task' was changed at init_task.c:64:1:
size of symbol changed from 4288 to 4480
CRC (modversions) changed from 0x81ecaff to 0x44b5de7e
type of variable changed:
type size changed from 34304 to 35840 (in bits)
10 data member insertions:
'unsigned long int last_switch_count', at offset 15680 (in bits) at sched.h:972:1
'unsigned long int last_switch_time', at offset 15744 (in bits) at sched.h:973:1
'u64 android_kabi_reserved1', at offset 26304 (in bits) at sched.h:1374:1
'u64 android_kabi_reserved2', at offset 26368 (in bits) at sched.h:1375:1
'u64 android_kabi_reserved3', at offset 26432 (in bits) at sched.h:1376:1
'u64 android_kabi_reserved4', at offset 26496 (in bits) at sched.h:1377:1
'u64 android_kabi_reserved5', at offset 26560 (in bits) at sched.h:1378:1
'u64 android_kabi_reserved6', at offset 26624 (in bits) at sched.h:1379:1
'u64 android_kabi_reserved7', at offset 26688 (in bits) at sched.h:1380:1
'u64 android_kabi_reserved8', at offset 26752 (in bits) at sched.h:1381:1
there are data member changes:
type 'struct sched_entity' of 'task_struct::se' changed:
type size changed from 3584 to 4096 (in bits)
4 data member insertions:
'u64 android_kabi_reserved1', at offset 3584 (in bits) at sched.h:490:1
'u64 android_kabi_reserved2', at offset 3648 (in bits) at sched.h:491:1
'u64 android_kabi_reserved3', at offset 3712 (in bits) at sched.h:492:1
'u64 android_kabi_reserved4', at offset 3776 (in bits) at sched.h:493:1
2709 impacted interfaces
type 'struct sched_rt_entity' of 'task_struct::rt' changed:
type size changed from 384 to 640 (in bits)
4 data member insertions:
'u64 android_kabi_reserved1', at offset 384 (in bits) at sched.h:513:1
'u64 android_kabi_reserved2', at offset 448 (in bits) at sched.h:514:1
'u64 android_kabi_reserved3', at offset 512 (in bits) at sched.h:515:1
'u64 android_kabi_reserved4', at offset 576 (in bits) at sched.h:516:1
2709 impacted interfaces
and offset changed from 5120 to 5632 (in bits) (by +512 bits)
76 ('task_group* sched_task_group' .. 'nameidata* nameidata') offsets changed (by +768 bits)
57 ('fs_struct* fs' .. 'tlbflush_unmap_batch tlb_ubc') offsets changed (by +896 bits)
while looking at anonymous data member 'union {refcount_t rcu_users; callback_head rcu;}':
the internal name of that anonymous data member changed from:
__anonymous_union__42
to:
__anonymous_union__7
This is usually due to an anonymous member type being added or removed from the containing type
and offset changed from 19648 to 20544 (in bits) (by +896 bits)
20 ('pipe_inode_info* splice_pipe' .. 'u64 android_oem_data1[6]') offsets changed (by +896 bits)
'thread_struct thread' offset changed (by +1408 bits)
2709 impacted interfaces
[C] 'task_group root_task_group' was changed at core.c:7333:1:
CRC (modversions) changed from 0x9b394bce to 0x5a6eab97
type of variable changed:
type size hasn't changed
4 data member insertions:
'u64 android_kabi_reserved1', at offset 3200 (in bits) at sched.h:433:1
'u64 android_kabi_reserved2', at offset 3264 (in bits) at sched.h:434:1
'u64 android_kabi_reserved3', at offset 3328 (in bits) at sched.h:435:1
'u64 android_kabi_reserved4', at offset 3392 (in bits) at sched.h:436:1
2709 impacted interfaces
[C] 'rq runqueues' was changed at core.c:49:1:
CRC (modversions) changed from 0xdbe39db6 to 0xfbaeea47
type of variable changed:
type size hasn't changed
4 data member insertions:
'u64 android_kabi_reserved1', at offset 32832 (in bits) at sched.h:1072:1
'u64 android_kabi_reserved2', at offset 32896 (in bits) at sched.h:1073:1
'u64 android_kabi_reserved3', at offset 32960 (in bits) at sched.h:1074:1
'u64 android_kabi_reserved4', at offset 33024 (in bits) at sched.h:1075:1
2709 impacted interfaces
[C] 'bus_type amba_bustype' was changed at bus.c:215:1:
CRC (modversions) changed from 0x51184ff2 to 0xbbb1e519
[C] 'const clk_ops clk_fixed_factor_ops' was changed at clk-fixed-factor.c:60:1:
CRC (modversions) changed from 0x3c1cb271 to 0x8a6ece13
[C] 'const clk_ops clk_fixed_rate_ops' was changed at clk-fixed-rate.c:46:1:
CRC (modversions) changed from 0xd36c1692 to 0x3ea7e2f0
... 43 omitted; 46 symbols have only CRC changes
'struct class at class.h:54:1' changed:
type size changed from 960 to 1024 (in bits)
1 data member insertion:
'u64 android_kabi_reserved1', at offset 960 (in bits) at class.h:79:1
2709 impacted interfaces
'struct cma at cma.h:7:1' changed:
type size changed from 1280 to 1472 (in bits)
3 data member insertions:
'atomic64_t nr_pages_succeeded', at offset 1280 (in bits) at cma.h:27:1
'atomic64_t nr_pages_failed', at offset 1344 (in bits) at cma.h:29:1
'cma_kobject* cma_kobj', at offset 1408 (in bits) at cma.h:31:1
2711 impacted interfaces
'struct device_link at device.h:571:1' changed:
type size changed from 6976 to 7104 (in bits)
2 data member insertions:
'u64 android_kabi_reserved1', at offset 6976 (in bits) at device.h:585:1
'u64 android_kabi_reserved2', at offset 7040 (in bits) at device.h:586:1
2 impacted interfaces
'struct device_node at of.h:51:1' changed (indirectly):
type size changed from 1920 to 1984 (in bits)
there are data member changes:
type 'struct fwnode_handle' of 'device_node::fwnode' changed:
type size changed from 512 to 576 (in bits)
1 data member insertion:
'u64 android_kabi_reserved1', at offset 512 (in bits) at fwnode.h:38:1
2709 impacted interfaces
8 ('property* properties' .. 'void* data') offsets changed (by +64 bits)
2709 impacted interfaces
'struct drm_crtc_helper_funcs at drm_modeset_helper_vtables.h:61:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'int (drm_crtc*, drm_framebuffer*, int, int, enum mode_set_atomic)*' of 'drm_crtc_helper_funcs::mode_set_base_atomic' changed:
pointer type changed from: 'int (drm_crtc*, drm_framebuffer*, int, int, enum mode_set_atomic)*' to: 'int (drm_crtc*, drm_framebuffer*, int, int, enum mode_set_atomic)*'
246 impacted interfaces
'struct fwnode_handle at fwnode.h:30:1' changed:
details were reported earlier
'struct iommu_flush_ops at io-pgtable.h:39:1' changed:
type size changed from 256 to 192 (in bits)
1 data member deletion:
'void (unsigned long int, typedef size_t, typedef size_t, void*)* tlb_flush_leaf', at offset 128 (in bits) at io-pgtable.h:43:1
there are data member changes:
'void (iommu_iotlb_gather*, unsigned long int, typedef size_t, void*)* tlb_add_page' offset changed (by -64 bits)
one impacted interface
'struct iommu_ops at iommu.h:248:1' changed:
type size hasn't changed
there are data member changes:
type 'void (iommu_domain*)*' of 'iommu_ops::iotlb_sync_map' changed:
pointer type changed from: 'void (iommu_domain*)*' to: 'void (iommu_domain*, unsigned long int, typedef size_t)*'
2709 impacted interfaces
'struct module at module.h:366:1' changed:
type size changed from 7680 to 8192 (in bits)
5 data member insertions:
'cfi_check_fn cfi_check', at offset 2176 (in bits) at module.h:390:1
'u64 android_kabi_reserved1', at offset 7744 (in bits) at module.h:550:1
'u64 android_kabi_reserved2', at offset 7808 (in bits) at module.h:551:1
'u64 android_kabi_reserved3', at offset 7872 (in bits) at module.h:552:1
'u64 android_kabi_reserved4', at offset 7936 (in bits) at module.h:553:1
there are data member changes:
15 ('mutex param_lock' .. 'int ()* init') offsets changed (by +64 bits)
40 ('module_layout core_layout' .. 'unsigned int num_ei_funcs') offsets changed (by +512 bits)
2709 impacted interfaces
'struct root_domain at sched.h:777:1' changed:
type size changed from 14848 to 15104 (in bits)
4 data member insertions:
'u64 android_kabi_reserved1', at offset 14848 (in bits) at sched.h:838:1
'u64 android_kabi_reserved2', at offset 14912 (in bits) at sched.h:839:1
'u64 android_kabi_reserved3', at offset 14976 (in bits) at sched.h:840:1
'u64 android_kabi_reserved4', at offset 15040 (in bits) at sched.h:841:1
2709 impacted interfaces
'struct rq at sched.h:897:1' changed:
details were reported earlier
'struct sched_entity at sched.h:452:1' changed:
details were reported earlier
'struct sched_rt_entity at sched.h:490:1' changed:
details were reported earlier
'struct signal_struct at signal.h:82:1' changed:
type size changed from 8448 to 8704 (in bits)
4 data member insertions:
'u64 android_kabi_reserved1', at offset 8448 (in bits) at signal.h:240:1
'u64 android_kabi_reserved2', at offset 8512 (in bits) at signal.h:241:1
'u64 android_kabi_reserved3', at offset 8576 (in bits) at signal.h:242:1
'u64 android_kabi_reserved4', at offset 8640 (in bits) at signal.h:243:1
2709 impacted interfaces
'struct sk_buff at skbuff.h:714:1' changed:
type size hasn't changed
2 data member insertions:
'__u8 redirected', at offset 5 (in bits) at skbuff.h:856:1
'__u8 from_ingress', at offset 6 (in bits) at skbuff.h:857:1
2709 impacted interfaces
'struct sock at sock.h:347:1' changed:
type size changed from 6144 to 6656 (in bits)
8 data member insertions:
'u64 android_kabi_reserved1', at offset 6144 (in bits) at sock.h:525:1
'u64 android_kabi_reserved2', at offset 6208 (in bits) at sock.h:526:1
'u64 android_kabi_reserved3', at offset 6272 (in bits) at sock.h:527:1
'u64 android_kabi_reserved4', at offset 6336 (in bits) at sock.h:528:1
'u64 android_kabi_reserved5', at offset 6400 (in bits) at sock.h:529:1
'u64 android_kabi_reserved6', at offset 6464 (in bits) at sock.h:530:1
'u64 android_kabi_reserved7', at offset 6528 (in bits) at sock.h:531:1
'u64 android_kabi_reserved8', at offset 6592 (in bits) at sock.h:532:1
2709 impacted interfaces
'struct task_group at sched.h:379:1' changed:
details were reported earlier
'struct task_struct at sched.h:641:1' changed:
details were reported earlier
'struct vfsmount at mount.h:71:1' changed:
type size changed from 192 to 448 (in bits)
4 data member insertions:
'u64 android_kabi_reserved1', at offset 192 (in bits) at mount.h:77:1
'u64 android_kabi_reserved2', at offset 256 (in bits) at mount.h:78:1
'u64 android_kabi_reserved3', at offset 320 (in bits) at mount.h:79:1
'u64 android_kabi_reserved4', at offset 384 (in bits) at mount.h:80:1
2709 impacted interfaces
'struct vm_area_struct at mm_types.h:306:1' changed:
type size changed from 1600 to 1856 (in bits)
4 data member insertions:
'u64 android_kabi_reserved1', at offset 1600 (in bits) at mm_types.h:388:1
'u64 android_kabi_reserved2', at offset 1664 (in bits) at mm_types.h:389:1
'u64 android_kabi_reserved3', at offset 1728 (in bits) at mm_types.h:390:1
'u64 android_kabi_reserved4', at offset 1792 (in bits) at mm_types.h:391:1
2709 impacted interfaces
'struct vsock_sock at af_vsock.h:27:1' changed (indirectly):
type size changed from 10176 to 10688 (in bits)
there are data member changes:
type 'struct sock' of 'vsock_sock::sk' changed, as reported earlier
25 ('const vsock_transport* transport' .. 'void* trans') offsets changed (by +512 bits)
30 impacted interfaces
'struct zone at mmzone.h:430:1' changed:
type size hasn't changed
4 data member insertions:
'u64 android_kabi_reserved1', at offset 12544 (in bits) at mmzone.h:586:1
'u64 android_kabi_reserved2', at offset 12608 (in bits) at mmzone.h:587:1
'u64 android_kabi_reserved3', at offset 12672 (in bits) at mmzone.h:588:1
'u64 android_kabi_reserved4', at offset 12736 (in bits) at mmzone.h:589:1
2709 impacted interfaces
Bug: 183615388
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I74a12a1c49d46ea2adddad5272d73f3f3dc2f1c3
This reverts commit 3520187422.
Reason for revert: need to reapply after 3/26
Change-Id: I57a17fdd39c6eb1eb372a4b031f1935b6661cb62
Signed-off-by: Todd Kjos <tkjos@google.com>
Turn on KMI_SYMBOL_LIST_STRICT_MODE and TRIM_NONLISTED_KMI=1
to match the other KMI branches
Bug: 183615388
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I11a1d4bf093827ffaa6741d010513d6e8b4ff0b2
Updates the branch to the 5.10.26 upstream kernel version.
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I84aa29bf4e4e809051eb346830c4c4b5acb78c8c
This is for rate limiting, I'm surprised to discover these weren't already on.
Test: TreeHugger
Bug: 179454839
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I3a82dc91215c1d233b16566d965af2acaf72c25c
This test extends the current mremap tests to validate that
the MREMAP_DONTUNMAP operation can be performed on shmem mappings.
Signed-off-by: Brian Geffon <bgeffon@google.com>
Signed-off-by: Lokesh Gidra <lokeshgidra@google.com>
Link: https://lore.kernel.org/patchwork/patch/1401225/
Bug: 160737021
Bug: 169683130
Change-Id: Ib357e58526af739cf8df49fc9604372996a9a6b3
Currently MREMAP_DONTUNMAP only accepts private anonymous mappings.
This restriction was placed initially for simplicity and not because
there exists a technical reason to do so.
This change will widen the support to include any mappings which are not
VM_DONTEXPAND or VM_PFNMAP. The primary use case is to support
MREMAP_DONTUNMAP on mappings which may have been created from a memfd.
This change will result in mremap(MREMAP_DONTUNMAP) returning -EINVAL
if VM_DONTEXPAND or VM_PFNMAP mappings are specified.
Lokesh Gidra who works on the Android JVM, provided an explanation of how
such a feature will improve Android JVM garbage collection:
"Android is developing a new garbage collector (GC), based on userfaultfd.
The garbage collector will use userfaultfd (uffd) on the java heap during
compaction. On accessing any uncompacted page, the application threads will
find it missing, at which point the thread will create the compacted page
and then use UFFDIO_COPY ioctl to get it mapped and then resume execution.
Before starting this compaction, in a stop-the-world pause the heap will be
mremap(MREMAP_DONTUNMAP) so that the java heap is ready to receive
UFFD_EVENT_PAGEFAULT events after resuming execution.
To speedup mremap operations, pagetable movement was optimized by moving
PUD entries instead of PTE entries [1]. It was necessary as mremap of even
modest sized memory ranges also took several milliseconds, and stopping the
application for that long isn't acceptable in response-time sensitive
cases.
With UFFDIO_CONTINUE feature [2], it will be even more efficient to
implement this GC, particularly the 'non-moveable' portions of the heap.
It will also help in reducing the need to copy (UFFDIO_COPY) the pages.
However, for this to work, the java heap has to be on a 'shared' vma.
Currently MREMAP_DONTUNMAP only supports private anonymous mappings, this
patch will enable using UFFDIO_CONTINUE for the new userfaultfd-based heap
compaction."
[1] https://lore.kernel.org/linux-mm/20201215030730.NC3CU98e4%25akpm@linux-foundation.org/
[2] https://lore.kernel.org/linux-mm/20210302000133.272579-1-axelrasmussen@google.com/
Signed-off-by: Brian Geffon <bgeffon@google.com>
Acked-by: Hugh Dickins <hughd@google.com>
Tested-by: Lokesh Gidra <lokeshgidra@google.com>
Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com>
Signed-off-by: Lokesh Gidra <lokeshgidra@google.com>
Link: https://lore.kernel.org/patchwork/patch/1401224/
Bug: 160737021
Bug: 169683130
Change-Id: Ic4f023dff404d7b0e35adbe92c7a12536aa0f70d
Since CMA is getting used more widely, it's more important to
keep monitoring CMA statistics for system health since it's
directly related to user experience.
This feature introduces sysfs statistics for CMA, in order to provide
some basic monitoring of the CMA allocator.
* the number of CMA page successful allocations
* the number of CMA page allocation failures
These two values allow the user to calculate the allocation
failure rate for each CMA area.
Bug: 179256052
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I5c8dc58a5d195d2e1b2e25628545f7d2a9c3b7df
Since it's not stable until it could be merged into Linus's tree
lets make it as experimental. If a vendor want to use it, they
should carry on cma_sysfs.experimental=Y on kernel parameter.
Otherwise, it will be disabled.
If some vendor enables it, it means they know this is experimental
faeture so Android never guarantee it in the future.
Bug: 179256052
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: Ic6566197a7865dfcab6964d008103d3686c9d14b
Since CMA is getting used more widely, it's more important to
keep monitoring CMA statistics for system health since it's
directly related to user experience.
This patch introduces sysfs statistics for CMA, in order to provide
some basic monitoring of the CMA allocator.
* the number of CMA page successful allocations
* the number of CMA page allocation failures
These two values allow the user to calcuate the allocation
failure rate for each CMA area.
e.g.)
/sys/kernel/mm/cma/WIFI/alloc_pages_[success|fail]
/sys/kernel/mm/cma/SENSOR/alloc_pages_[success|fail]
/sys/kernel/mm/cma/BLUETOOTH/alloc_pages_[success|fail]
The cma_stat was intentionally allocated by dynamic allocation
to harmonize with kobject lifetime management.
https://lore.kernel.org/linux-mm/YCOAmXqt6dZkCQYs@kroah.com/
Link: https://lore.kernel.org/linux-mm/20210324230759.2213957-1-minchan@kernel.org/
Bug: 179256052
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Link: https://lore.kernel.org/linux-mm/20210316100433.17665-1-colin.king@canonical.com/
Addresses-Coverity: ("Dereference after null check")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I86239db91c7853a62a22b2161d1bf8c9099152b7
The hook may modify index. In that case, target_state and
related values should be assigned and pre-processing should
be executed according to the modified index.
Bug: 183690687
Signed-off-by: Choonghoon Park <choong.park@samsung.com>
Change-Id: Ie641270f9560d0e4a5b4890b7f63ccc5a31277db
In commit b7ff91fd03 ("ext4: find old entry again if failed to rename
whiteout") a new call to ext4_find_entry() was made, but in commit
705a3e5b18 ("ANDROID: ext4: Handle casefolding with encryption")
only in the ANDROID tree, a new parameter is added to that function.
Add NULL there to keep the build working, hopefully one-day the
out-of-tree patch will get merged upstream...
Fixes: 705a3e5b18 ("ANDROID: ext4: Handle casefolding with encryption")
Fixes: b7ff91fd03 ("ext4: find old entry again if failed to rename whiteout")
Cc: Daniel Rosenberg <drosen@google.com>
Cc: Paul Lawrence <paullawrence@google.com>
Bug: 138322712
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>BB
Change-Id: I69b7f9c12d1f9016b8269e5bc7878469700b6477
Changes in 5.10.26
ASoC: ak4458: Add MODULE_DEVICE_TABLE
ASoC: ak5558: Add MODULE_DEVICE_TABLE
spi: cadence: set cqspi to the driver_data field of struct device
ALSA: dice: fix null pointer dereference when node is disconnected
ALSA: hda/realtek: apply pin quirk for XiaomiNotebook Pro
ALSA: hda: generic: Fix the micmute led init state
ALSA: hda/realtek: Apply headset-mic quirks for Xiaomi Redmibook Air
ALSA: hda/realtek: fix mute/micmute LEDs for HP 840 G8
ALSA: hda/realtek: fix mute/micmute LEDs for HP 440 G8
ALSA: hda/realtek: fix mute/micmute LEDs for HP 850 G8
Revert "PM: runtime: Update device status before letting suppliers suspend"
s390/vtime: fix increased steal time accounting
s390/pci: refactor zpci_create_device()
s390/pci: remove superfluous zdev->zbus check
s390/pci: fix leak of PCI device structure
zonefs: Fix O_APPEND async write handling
zonefs: prevent use of seq files as swap file
zonefs: fix to update .i_wr_refcnt correctly in zonefs_open_zone()
btrfs: fix race when cloning extent buffer during rewind of an old root
btrfs: fix slab cache flags for free space tree bitmap
vhost-vdpa: fix use-after-free of v->config_ctx
vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails
drm/amd/display: Correct algorithm for reversed gamma
ASoC: fsl_ssi: Fix TDM slot setup for I2S mode
ASoC: Intel: bytcr_rt5640: Fix HP Pavilion x2 10-p0XX OVCD current threshold
ASoC: SOF: Intel: unregister DMIC device on probe error
ASoC: SOF: intel: fix wrong poll bits in dsp power down
ASoC: qcom: sdm845: Fix array out of bounds access
ASoC: qcom: sdm845: Fix array out of range on rx slim channels
ASoC: codecs: wcd934x: add a sanity check in set channel map
ASoC: qcom: lpass-cpu: Fix lpass dai ids parse
ASoC: simple-card-utils: Do not handle device clock
afs: Fix accessing YFS xattrs on a non-YFS server
afs: Stop listxattr() from listing "afs.*" attributes
ALSA: usb-audio: Fix unintentional sign extension issue
nvme: fix Write Zeroes limitations
nvme-tcp: fix misuse of __smp_processor_id with preemption enabled
nvme-tcp: fix possible hang when failing to set io queues
nvme-tcp: fix a NULL deref when receiving a 0-length r2t PDU
nvmet: don't check iosqes,iocqes for discovery controllers
nfsd: Don't keep looking up unhashed files in the nfsd file cache
nfsd: don't abort copies early
NFSD: Repair misuse of sv_lock in 5.10.16-rt30.
NFSD: fix dest to src mount in inter-server COPY
svcrdma: disable timeouts on rdma backchannel
vfio: IOMMU_API should be selected
vhost_vdpa: fix the missing irq_bypass_unregister_producer() invocation
sunrpc: fix refcount leak for rpc auth modules
i915/perf: Start hrtimer only if sampling the OA buffer
pstore: Fix warning in pstore_kill_sb()
io_uring: ensure that SQPOLL thread is started for exit
net/qrtr: fix __netdev_alloc_skb call
kbuild: Fix <linux/version.h> for empty SUBLEVEL or PATCHLEVEL again
cifs: fix allocation size on newly created files
riscv: Correct SPARSEMEM configuration
scsi: lpfc: Fix some error codes in debugfs
scsi: myrs: Fix a double free in myrs_cleanup()
scsi: ufs: ufs-mediatek: Correct operator & -> &&
RISC-V: correct enum sbi_ext_rfence_fid
counter: stm32-timer-cnt: Report count function when SLAVE_MODE_DISABLED
gpiolib: Assign fwnode to parent's if no primary one provided
nvme-rdma: fix possible hang when failing to set io queues
ibmvnic: add some debugs
ibmvnic: serialize access to work queue on remove
tty: serial: stm32-usart: Remove set but unused 'cookie' variables
serial: stm32: fix DMA initialization error handling
bpf: Declare __bpf_free_used_maps() unconditionally
RDMA/rtrs: Remove unnecessary argument dir of rtrs_iu_free
RDMA/rtrs-srv: Jump to dereg_mr label if allocate iu fails
RDMA/rtrs: Introduce rtrs_post_send
RDMA/rtrs: Fix KASAN: stack-out-of-bounds bug
module: merge repetitive strings in module_sig_check()
module: avoid *goto*s in module_sig_check()
module: harden ELF info handling
scsi: pm80xx: Make mpi_build_cmd locking consistent
scsi: pm80xx: Make running_req atomic
scsi: pm80xx: Fix pm8001_mpi_get_nvmd_resp() race condition
scsi: pm8001: Neaten debug logging macros and uses
scsi: libsas: Remove notifier indirection
scsi: libsas: Introduce a _gfp() variant of event notifiers
scsi: mvsas: Pass gfp_t flags to libsas event notifiers
scsi: isci: Pass gfp_t flags in isci_port_link_down()
scsi: isci: Pass gfp_t flags in isci_port_link_up()
scsi: isci: Pass gfp_t flags in isci_port_bc_change_received()
RDMA/mlx5: Allow creating all QPs even when non RDMA profile is used
powerpc/sstep: Fix load-store and update emulation
powerpc/sstep: Fix darn emulation
i40e: Fix endianness conversions
net: phy: micrel: set soft_reset callback to genphy_soft_reset for KSZ8081
MIPS: compressed: fix build with enabled UBSAN
drm/amd/display: turn DPMS off on connector unplug
iwlwifi: Add a new card for MA family
io_uring: fix inconsistent lock state
media: cedrus: h264: Support profile controls
ibmvnic: remove excessive irqsave
s390/qeth: schedule TX NAPI on QAOB completion
drm/amd/pm: fulfill the Polaris implementation for get_clock_by_type_with_latency()
io_uring: don't attempt IO reissue from the ring exit path
io_uring: clear IOCB_WAITQ for non -EIOCBQUEUED return
net: bonding: fix error return code of bond_neigh_init()
regulator: pca9450: Add SD_VSEL GPIO for LDO5
regulator: pca9450: Enable system reset on WDOG_B assertion
regulator: pca9450: Clear PRESET_EN bit to fix BUCK1/2/3 voltage setting
gfs2: Add common helper for holding and releasing the freeze glock
gfs2: move freeze glock outside the make_fs_rw and _ro functions
gfs2: bypass signal_our_withdraw if no journal
powerpc: Force inlining of cpu_has_feature() to avoid build failure
usb-storage: Add quirk to defeat Kindle's automatic unload
usbip: Fix incorrect double assignment to udc->ud.tcp_rx
usb: gadget: configfs: Fix KASAN use-after-free
usb: typec: Remove vdo[3] part of tps6598x_rx_identity_reg struct
usb: typec: tcpm: Invoke power_supply_changed for tcpm-source-psy-
usb: dwc3: gadget: Allow runtime suspend if UDC unbinded
usb: dwc3: gadget: Prevent EP queuing while stopping transfers
thunderbolt: Initialize HopID IDAs in tb_switch_alloc()
thunderbolt: Increase runtime PM reference count on DP tunnel discovery
iio:adc:stm32-adc: Add HAS_IOMEM dependency
iio:adc:qcom-spmi-vadc: add default scale to LR_MUX2_BAT_ID channel
iio: adis16400: Fix an error code in adis16400_initial_setup()
iio: gyro: mpu3050: Fix error handling in mpu3050_trigger_handler
iio: adc: ab8500-gpadc: Fix off by 10 to 3
iio: adc: ad7949: fix wrong ADC result due to incorrect bit mask
iio: adc: adi-axi-adc: add proper Kconfig dependencies
iio: hid-sensor-humidity: Fix alignment issue of timestamp channel
iio: hid-sensor-prox: Fix scale not correct issue
iio: hid-sensor-temperature: Fix issues of timestamp channel
counter: stm32-timer-cnt: fix ceiling write max value
counter: stm32-timer-cnt: fix ceiling miss-alignment with reload register
PCI: rpadlpar: Fix potential drc_name corruption in store functions
perf/x86/intel: Fix a crash caused by zero PEBS status
perf/x86/intel: Fix unchecked MSR access error caused by VLBR_EVENT
x86/ioapic: Ignore IRQ2 again
kernel, fs: Introduce and use set_restart_fn() and arch_set_restart_data()
x86: Move TS_COMPAT back to asm/thread_info.h
x86: Introduce TS_COMPAT_RESTART to fix get_nr_restart_syscall()
efivars: respect EFI_UNSUPPORTED return from firmware
ext4: fix error handling in ext4_end_enable_verity()
ext4: find old entry again if failed to rename whiteout
ext4: stop inode update before return
ext4: do not try to set xattr into ea_inode if value is empty
ext4: fix potential error in ext4_do_update_inode
ext4: fix rename whiteout with fast commit
MAINTAINERS: move some real subsystems off of the staging mailing list
MAINTAINERS: move the staging subsystem to lists.linux.dev
static_call: Fix static_call_update() sanity check
efi: use 32-bit alignment for efi_guid_t literals
firmware/efi: Fix a use after bug in efi_mem_reserve_persistent
genirq: Disable interrupts for force threaded handlers
x86/apic/of: Fix CPU devicetree-node lookups
cifs: Fix preauth hash corruption
Linux 5.10.26
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6f6bdd1dc46dc744c848e778f9edd0be558b46ac
This is an incompatible ABI XML version change.
Bitfield offsets are now correct.
Bug: 183612421
Change-Id: I8871009e3a129c075b70d95612a55822b0f9d9e3
Signed-off-by: Giuliano Procida <gprocida@google.com>
Leaf changes summary: 2669 artifacts changed
Changed leaf types summary: 20 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 2563 Changed, 29 Added functions
Removed/Changed/Added variables summary: 0 Removed, 50 Changed, 7 Added variables
29 Added functions:
[A] 'function void* android_debug_per_cpu_symbol(android_debug_per_cpu_symbol)'
[A] 'function void* android_debug_symbol(android_debug_symbol)'
[A] 'function long int copy_from_kernel_nofault(void*, void*, unsigned long int)'
[A] 'function irq_desc** ipi_desc_get()'
[A] 'function int is_dma_buf_file(file*)'
[A] 'function unsigned int kstat_irqs_cpu(unsigned int, int)'
[A] 'function unsigned int kstat_irqs_usr(unsigned int)'
[A] 'function char* log_buf_addr_get()'
[A] 'function u32 log_buf_len_get()'
[A] 'function int nr_ipi_get()'
[A] 'function int pci_dev_present(const pci_device_id*)'
[A] 'function phys_addr_t per_cpu_ptr_to_phys(void*)'
[A] 'function int register_die_notifier(notifier_block*)'
[A] 'function int register_module_notifier(notifier_block*)'
[A] 'function int sched_setattr(task_struct*, const sched_attr*)'
[A] 'function int seq_buf_printf(seq_buf*, const char*, ...)'
[A] 'function int sysfs_emit(char*, const char*, ...)'
[A] 'function int unregister_die_notifier(notifier_block*)'
[A] 'function int unregister_module_notifier(notifier_block*)'
[A] 'function xhci_command* xhci_alloc_command(xhci_hcd*, bool, unsigned int)'
[A] 'function int xhci_alloc_erst(xhci_hcd*, xhci_ring*, xhci_erst*, gfp_t)'
[A] 'function void xhci_free_command(xhci_hcd*, xhci_command*)'
[A] 'function void xhci_free_erst(xhci_hcd*, xhci_erst*)'
[A] 'function unsigned int xhci_get_endpoint_index(usb_endpoint_descriptor*)'
[A] 'function int xhci_queue_stop_endpoint(xhci_hcd*, xhci_command*, int, unsigned int, int)'
[A] 'function xhci_ring* xhci_ring_alloc(xhci_hcd*, unsigned int, unsigned int, xhci_ring_type, unsigned int, gfp_t)'
[A] 'function void xhci_ring_cmd_db(xhci_hcd*)'
[A] 'function void xhci_ring_free(xhci_hcd*, xhci_ring*)'
[A] 'function long long unsigned int xhci_trb_virt_to_dma(xhci_segment*, xhci_trb*)'
2563 functions with some sub-type change:
[C] 'function void* PDE_DATA(const inode*)' at proc_fs.h:112:1 has some sub-type changes:
CRC (modversions) changed from 0x8f0b8b7c to 0xb095f157
[C] 'function void __ClearPageMovable(page*)' at compaction.c:138:1 has some sub-type changes:
CRC (modversions) changed from 0xb9a01cb4 to 0x8d0d1323
[C] 'function void __SetPageMovable(page*, address_space*)' at compaction.c:130:1 has some sub-type changes:
CRC (modversions) changed from 0x8981e72b to 0x33d724d0
... 2560 omitted; 2563 symbols have only CRC changes
7 Added variables:
[A] 'tracepoint __tracepoint_android_vh_ftrace_dump_buffer'
[A] 'tracepoint __tracepoint_android_vh_ftrace_format_check'
[A] 'tracepoint __tracepoint_android_vh_ftrace_oops_enter'
[A] 'tracepoint __tracepoint_android_vh_ftrace_oops_exit'
[A] 'tracepoint __tracepoint_android_vh_ftrace_size_check'
[A] 'kernel_stat kstat'
[A] 'int nr_irqs'
50 Changed variables:
[C] 'task_struct init_task' was changed at init_task.c:64:1:
size of symbol changed from 4288 to 4480
CRC (modversions) changed from 0x81ecaff to 0x4b41d5a6
type of variable changed:
type size changed from 34304 to 35840 (in bits)
8 data member insertions:
'u64 task_struct::android_kabi_reserved1', at offset 26176 (in bits) at sched.h:1374:1
'u64 task_struct::android_kabi_reserved2', at offset 26240 (in bits) at sched.h:1375:1
'u64 task_struct::android_kabi_reserved3', at offset 26304 (in bits) at sched.h:1376:1
'u64 task_struct::android_kabi_reserved4', at offset 26368 (in bits) at sched.h:1377:1
'u64 task_struct::android_kabi_reserved5', at offset 26432 (in bits) at sched.h:1378:1
'u64 task_struct::android_kabi_reserved6', at offset 26496 (in bits) at sched.h:1379:1
'u64 task_struct::android_kabi_reserved7', at offset 26560 (in bits) at sched.h:1380:1
'u64 task_struct::android_kabi_reserved8', at offset 26624 (in bits) at sched.h:1381:1
there are data member changes:
type 'struct sched_entity' of 'task_struct::se' changed:
type size changed from 3584 to 4096 (in bits)
4 data member insertions:
'u64 sched_entity::android_kabi_reserved1', at offset 3584 (in bits) at sched.h:490:1
'u64 sched_entity::android_kabi_reserved2', at offset 3648 (in bits) at sched.h:491:1
'u64 sched_entity::android_kabi_reserved3', at offset 3712 (in bits) at sched.h:492:1
'u64 sched_entity::android_kabi_reserved4', at offset 3776 (in bits) at sched.h:493:1
2622 impacted interfaces
type 'struct sched_rt_entity' of 'task_struct::rt' changed:
type size changed from 384 to 640 (in bits)
4 data member insertions:
'u64 sched_rt_entity::android_kabi_reserved1', at offset 384 (in bits) at sched.h:513:1
'u64 sched_rt_entity::android_kabi_reserved2', at offset 448 (in bits) at sched.h:514:1
'u64 sched_rt_entity::android_kabi_reserved3', at offset 512 (in bits) at sched.h:515:1
'u64 sched_rt_entity::android_kabi_reserved4', at offset 576 (in bits) at sched.h:516:1
2622 impacted interfaces
and offset changed from 5120 to 5632 (in bits) (by +512 bits)
133 ('task_group* task_struct::sched_task_group' .. 'tlbflush_unmap_batch task_struct::tlb_ubc') offsets changed (by +768 bits)
anonymous data member 'union {refcount_t rcu_users; callback_head rcu;}' offset changed from 19648 to 20416 (in bits) (by +768 bits)
20 ('pipe_inode_info* task_struct::splice_pipe' .. 'u64 task_struct::android_oem_data1[6]') offsets changed (by +768 bits)
'thread_struct task_struct::thread' offset changed (by +1280 bits)
2622 impacted interfaces
[C] 'task_group root_task_group' was changed at core.c:7335:1:
CRC (modversions) changed from 0x88b74fcd to 0xa2be3823
type of variable changed:
type size hasn't changed
4 data member insertions:
'u64 task_group::android_kabi_reserved1', at offset 3200 (in bits) at sched.h:433:1
'u64 task_group::android_kabi_reserved2', at offset 3264 (in bits) at sched.h:434:1
'u64 task_group::android_kabi_reserved3', at offset 3328 (in bits) at sched.h:435:1
'u64 task_group::android_kabi_reserved4', at offset 3392 (in bits) at sched.h:436:1
2622 impacted interfaces
[C] 'rq runqueues' was changed at core.c:49:1:
CRC (modversions) changed from 0xc91ed962 to 0xed491a1
type of variable changed:
type size hasn't changed
4 data member insertions:
'u64 rq::android_kabi_reserved1', at offset 32832 (in bits) at sched.h:1072:1
'u64 rq::android_kabi_reserved2', at offset 32896 (in bits) at sched.h:1073:1
'u64 rq::android_kabi_reserved3', at offset 32960 (in bits) at sched.h:1074:1
'u64 rq::android_kabi_reserved4', at offset 33024 (in bits) at sched.h:1075:1
2622 impacted interfaces
[C] 'bus_type amba_bustype' was changed at bus.c:215:1:
CRC (modversions) changed from 0x51184ff2 to 0x5e5bc98f
[C] 'const clk_ops clk_fixed_factor_ops' was changed at clk-fixed-factor.c:60:1:
CRC (modversions) changed from 0x3c1cb271 to 0xd048978b
[C] 'const clk_ops clk_fixed_rate_ops' was changed at clk-fixed-rate.c:46:1:
CRC (modversions) changed from 0xd36c1692 to 0x6b88426a
... 44 omitted; 47 symbols have only CRC changes
'struct class at class.h:54:1' changed:
type size changed from 960 to 1024 (in bits)
1 data member insertion:
'u64 class::android_kabi_reserved1', at offset 960 (in bits) at class.h:79:1
2622 impacted interfaces
'struct device_link at device.h:571:1' changed:
type size changed from 6976 to 7104 (in bits)
2 data member insertions:
'u64 device_link::android_kabi_reserved1', at offset 6976 (in bits) at device.h:585:1
'u64 device_link::android_kabi_reserved2', at offset 7040 (in bits) at device.h:586:1
2 impacted interfaces
'struct device_node at of.h:51:1' changed (indirectly):
type size changed from 1920 to 1984 (in bits)
there are data member changes:
type 'struct fwnode_handle' of 'device_node::fwnode' changed:
type size changed from 512 to 576 (in bits)
1 data member insertion:
'u64 fwnode_handle::android_kabi_reserved1', at offset 512 (in bits) at fwnode.h:38:1
2622 impacted interfaces
8 ('property* device_node::properties' .. 'void* device_node::data') offsets changed (by +64 bits)
2622 impacted interfaces
'struct fwnode_handle at fwnode.h:30:1' changed:
details were reported earlier
'struct iommu_flush_ops at io-pgtable.h:39:1' changed:
type size changed from 256 to 192 (in bits)
1 data member deletion:
'void (unsigned long int, typedef size_t, typedef size_t, void*)* iommu_flush_ops::tlb_flush_leaf', at offset 128 (in bits) at io-pgtable.h:43:1
there are data member changes:
'void (iommu_iotlb_gather*, unsigned long int, typedef size_t, void*)* iommu_flush_ops::tlb_add_page' offset changed (by -64 bits)
one impacted interface
'struct iommu_ops at iommu.h:248:1' changed:
type size hasn't changed
there are data member changes:
type 'void (iommu_domain*)*' of 'iommu_ops::iotlb_sync_map' changed:
pointer type changed from: 'void (iommu_domain*)*' to: 'void (iommu_domain*, unsigned long int, typedef size_t)*'
2622 impacted interfaces
'struct module at module.h:366:1' changed:
type size hasn't changed
4 data member insertions:
'u64 module::android_kabi_reserved1', at offset 7232 (in bits) at module.h:550:1
'u64 module::android_kabi_reserved2', at offset 7296 (in bits) at module.h:551:1
'u64 module::android_kabi_reserved3', at offset 7360 (in bits) at module.h:552:1
'u64 module::android_kabi_reserved4', at offset 7424 (in bits) at module.h:553:1
2622 impacted interfaces
'struct root_domain at sched.h:777:1' changed:
type size changed from 14848 to 15104 (in bits)
4 data member insertions:
'u64 root_domain::android_kabi_reserved1', at offset 14848 (in bits) at sched.h:838:1
'u64 root_domain::android_kabi_reserved2', at offset 14912 (in bits) at sched.h:839:1
'u64 root_domain::android_kabi_reserved3', at offset 14976 (in bits) at sched.h:840:1
'u64 root_domain::android_kabi_reserved4', at offset 15040 (in bits) at sched.h:841:1
2622 impacted interfaces
'struct rq at sched.h:897:1' changed:
details were reported earlier
'struct sched_entity at sched.h:452:1' changed:
details were reported earlier
'struct sched_rt_entity at sched.h:490:1' changed:
details were reported earlier
'struct signal_struct at signal.h:82:1' changed:
type size changed from 8448 to 8704 (in bits)
4 data member insertions:
'u64 signal_struct::android_kabi_reserved1', at offset 8448 (in bits) at signal.h:240:1
'u64 signal_struct::android_kabi_reserved2', at offset 8512 (in bits) at signal.h:241:1
'u64 signal_struct::android_kabi_reserved3', at offset 8576 (in bits) at signal.h:242:1
'u64 signal_struct::android_kabi_reserved4', at offset 8640 (in bits) at signal.h:243:1
2622 impacted interfaces
'struct sk_buff at skbuff.h:714:1' changed:
type size hasn't changed
2 data member insertions:
'__u8 sk_buff::from_ingress', at offset 1 (in bits) at skbuff.h:857:1
'__u8 sk_buff::redirected', at offset 2 (in bits) at skbuff.h:856:1
343 impacted interfaces
'struct sock at sock.h:347:1' changed:
type size changed from 6144 to 6656 (in bits)
8 data member insertions:
'u64 sock::android_kabi_reserved1', at offset 6144 (in bits) at sock.h:525:1
'u64 sock::android_kabi_reserved2', at offset 6208 (in bits) at sock.h:526:1
'u64 sock::android_kabi_reserved3', at offset 6272 (in bits) at sock.h:527:1
'u64 sock::android_kabi_reserved4', at offset 6336 (in bits) at sock.h:528:1
'u64 sock::android_kabi_reserved5', at offset 6400 (in bits) at sock.h:529:1
'u64 sock::android_kabi_reserved6', at offset 6464 (in bits) at sock.h:530:1
'u64 sock::android_kabi_reserved7', at offset 6528 (in bits) at sock.h:531:1
'u64 sock::android_kabi_reserved8', at offset 6592 (in bits) at sock.h:532:1
284 impacted interfaces
'struct task_group at sched.h:379:1' changed:
details were reported earlier
'struct task_struct at sched.h:641:1' changed:
details were reported earlier
'struct vfsmount at mount.h:71:1' changed:
type size changed from 192 to 448 (in bits)
4 data member insertions:
'u64 vfsmount::android_kabi_reserved1', at offset 192 (in bits) at mount.h:77:1
'u64 vfsmount::android_kabi_reserved2', at offset 256 (in bits) at mount.h:78:1
'u64 vfsmount::android_kabi_reserved3', at offset 320 (in bits) at mount.h:79:1
'u64 vfsmount::android_kabi_reserved4', at offset 384 (in bits) at mount.h:80:1
2622 impacted interfaces
'struct vm_area_struct at mm_types.h:306:1' changed:
type size changed from 1600 to 1856 (in bits)
4 data member insertions:
'u64 vm_area_struct::android_kabi_reserved1', at offset 1600 (in bits) at mm_types.h:388:1
'u64 vm_area_struct::android_kabi_reserved2', at offset 1664 (in bits) at mm_types.h:389:1
'u64 vm_area_struct::android_kabi_reserved3', at offset 1728 (in bits) at mm_types.h:390:1
'u64 vm_area_struct::android_kabi_reserved4', at offset 1792 (in bits) at mm_types.h:391:1
2622 impacted interfaces
'struct vsock_sock at af_vsock.h:27:1' changed (indirectly):
type size changed from 10176 to 10688 (in bits)
there are data member changes:
type 'struct sock' of 'vsock_sock::sk' changed, as reported earlier
25 ('const vsock_transport* vsock_sock::transport' .. 'void* vsock_sock::trans') offsets changed (by +512 bits)
30 impacted interfaces
'struct zone at mmzone.h:450:1' changed:
type size hasn't changed
4 data member insertions:
'u64 zone::android_kabi_reserved1', at offset 12544 (in bits) at mmzone.h:606:1
'u64 zone::android_kabi_reserved2', at offset 12608 (in bits) at mmzone.h:607:1
'u64 zone::android_kabi_reserved3', at offset 12672 (in bits) at mmzone.h:608:1
'u64 zone::android_kabi_reserved4', at offset 12736 (in bits) at mmzone.h:609:1
2622 impacted interfaces
Bug: 183612421
Change-Id: I22fb5e4bf670ae630a439678055a92b7f9f6e363
commit 05946d4b7a upstream.
smb311_update_preauth_hash() uses the shash in server->secmech without
appropriate locking, and this can lead to sessions corrupting each
other's preauth hashes.
The following script can easily trigger the problem:
#!/bin/sh -e
NMOUNTS=10
for i in $(seq $NMOUNTS);
mkdir -p /tmp/mnt$i
umount /tmp/mnt$i 2>/dev/null || :
done
while :; do
for i in $(seq $NMOUNTS); do
mount -t cifs //192.168.0.1/test /tmp/mnt$i -o ... &
done
wait
for i in $(seq $NMOUNTS); do
umount /tmp/mnt$i
done
done
Usually within seconds this leads to one or more of the mounts failing
with the following errors, and a "Bad SMB2 signature for message" is
seen in the server logs:
CIFS: VFS: \\192.168.0.1 failed to connect to IPC (rc=-13)
CIFS: VFS: cifs_mount failed w/return code = -13
Fix it by holding the server mutex just like in the other places where
the shashes are used.
Fixes: 8bd68c6e47 ("CIFS: implement v3.11 preauth integrity")
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
CC: <stable@vger.kernel.org>
Reviewed-by: Aurelien Aptel <aaptel@suse.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
[aaptel: backport to kernel without CIFS_SESS_OP]
Signed-off-by: Aurelien Aptel <aaptel@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dd926880da upstream.
Architectures that describe the CPU topology in devicetree and do not have
an identity mapping between physical and logical CPU ids must override the
default implementation of arch_match_cpu_phys_id().
Failing to do so breaks CPU devicetree-node lookups using of_get_cpu_node()
and of_cpu_device_node_get() which several drivers rely on. It also causes
the CPU struct devices exported through sysfs to point to the wrong
devicetree nodes.
On x86, CPUs are described in devicetree using their APIC ids and those
do not generally coincide with the logical ids, even if CPU0 typically
uses APIC id 0.
Add the missing implementation of arch_match_cpu_phys_id() so that CPU-node
lookups work also with SMP.
Apart from fixing the broken sysfs devicetree-node links this likely does
not affect current users of mainline kernels on x86.
Fixes: 4e07db9c8d ("x86/devicetree: Use CPU description from Device Tree")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20210312092033.26317-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 81e2073c17 upstream.
With interrupt force threading all device interrupt handlers are invoked
from kernel threads. Contrary to hard interrupt context the invocation only
disables bottom halfs, but not interrupts. This was an oversight back then
because any code like this will have an issue:
thread(irq_A)
irq_handler(A)
spin_lock(&foo->lock);
interrupt(irq_B)
irq_handler(B)
spin_lock(&foo->lock);
This has been triggered with networking (NAPI vs. hrtimers) and console
drivers where printk() happens from an interrupt which interrupted the
force threaded handler.
Now people noticed and started to change the spin_lock() in the handler to
spin_lock_irqsave() which affects performance or add IRQF_NOTHREAD to the
interrupt request which in turn breaks RT.
Fix the root cause and not the symptom and disable interrupts before
invoking the force threaded handler which preserves the regular semantics
and the usefulness of the interrupt force threading as a general debugging
tool.
For not RT this is not changing much, except that during the execution of
the threaded handler interrupts are delayed until the handler
returns. Vs. scheduling and softirq processing there is no difference.
For RT kernels there is no issue.
Fixes: 8d32a307e4 ("genirq: Provide forced interrupt threading")
Reported-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Johan Hovold <johan@kernel.org>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20210317143859.513307808@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9ceee7d084 upstream.
In the for loop in efi_mem_reserve_persistent(), prsv = rsv->next
use the unmapped rsv. Use the unmapped pages will cause segment
fault.
Fixes: 18df7577ad ("efi/memreserve: deal with memreserve entries in unmapped memory")
Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fb98cc0b3a upstream.
Commit 494c704f9a ("efi: Use 32-bit alignment for efi_guid_t") updated
the type definition of efi_guid_t to ensure that it always appears
sufficiently aligned (the UEFI spec is ambiguous about this, but given
the fact that its EFI_GUID type is defined in terms of a struct carrying
a uint32_t, the natural alignment is definitely >= 32 bits).
However, we missed the EFI_GUID() macro which is used to instantiate
efi_guid_t literals: that macro is still based on the guid_t type,
which does not have a minimum alignment at all. This results in warnings
such as
In file included from drivers/firmware/efi/mokvar-table.c:35:
include/linux/efi.h:1093:34: warning: passing 1-byte aligned argument to
4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer
access [-Walign-mismatch]
status = get_var(L"SecureBoot", &EFI_GLOBAL_VARIABLE_GUID, NULL, &size,
^
include/linux/efi.h:1101:24: warning: passing 1-byte aligned argument to
4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer
access [-Walign-mismatch]
get_var(L"SetupMode", &EFI_GLOBAL_VARIABLE_GUID, NULL, &size, &setupmode);
The distinction only matters on CPUs that do not support misaligned loads
fully, but 32-bit ARM's load-multiple instructions fall into that category,
and these are likely to be emitted by the compiler that built the firmware
for loading word-aligned 128-bit GUIDs from memory
So re-implement the initializer in terms of our own efi_guid_t type, so that
the alignment becomes a property of the literal's type.
Fixes: 494c704f9a ("efi: Use 32-bit alignment for efi_guid_t")
Reported-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Link: https://github.com/ClangBuiltLinux/linux/issues/1327
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 38c9358737 upstream.
Sites that match init_section_contains() get marked as INIT. For
built-in code init_sections contains both __init and __exit text. OTOH
kernel_text_address() only explicitly includes __init text (and there
are no __exit text markers).
Match what jump_label already does and ignore the warning for INIT
sites. Also see the excellent changelog for commit: 8f35eaa5f2
("jump_label: Don't warn on __exit jump entries")
Fixes: 9183c3f9ed ("static_call: Add inline static call infrastructure")
Reported-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
Tested-by: Sumit Garg <sumit.garg@linaro.org>
Link: https://lkml.kernel.org/r/20210318113610.739542434@infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8210bb29c1 upstream.
This patch adds rename whiteout support in fast commits. Note that the
whiteout object that gets created is actually char device. Which
imples, the function ext4_inode_journal_mode(struct inode *inode)
would return "JOURNAL_DATA" for this inode. This has a consequence in
fast commit code that it will make creation of the whiteout object a
fast-commit ineligible behavior and thus will fall back to full
commits. With this patch, this can be observed by running fast commits
with rename whiteout and seeing the stats generated by ext4_fc_stats
tracepoint as follows:
ext4_fc_stats: dev 254:32 fc ineligible reasons:
XATTR:0, CROSS_RENAME:0, JOURNAL_FLAG_CHANGE:0, NO_MEM:0, SWAP_BOOT:0,
RESIZE:0, RENAME_DIR:0, FALLOC_RANGE:0, INODE_JOURNAL_DATA:16;
num_commits:6, ineligible: 6, numblks: 3
So in short, this patch guarantees that in case of rename whiteout, we
fall back to full commits.
Amir mentioned that instead of creating a new whiteout object for
every rename, we can create a static whiteout object with irrelevant
nlink. That will make fast commits to not fall back to full
commit. But until this happens, this patch will ensure correctness by
falling back to full commits.
Fixes: 8016e29f43 ("ext4: fast commit recovery path")
Cc: stable@kernel.org
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Link: https://lore.kernel.org/r/20210316221921.1124955-1-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6b22489911 upstream.
Syzbot report a warning that ext4 may create an empty ea_inode if set
an empty extent attribute to a file on the file system which is no free
blocks left.
WARNING: CPU: 6 PID: 10667 at fs/ext4/xattr.c:1640 ext4_xattr_set_entry+0x10f8/0x1114 fs/ext4/xattr.c:1640
...
Call trace:
ext4_xattr_set_entry+0x10f8/0x1114 fs/ext4/xattr.c:1640
ext4_xattr_block_set+0x1d0/0x1b1c fs/ext4/xattr.c:1942
ext4_xattr_set_handle+0x8a0/0xf1c fs/ext4/xattr.c:2390
ext4_xattr_set+0x120/0x1f0 fs/ext4/xattr.c:2491
ext4_xattr_trusted_set+0x48/0x5c fs/ext4/xattr_trusted.c:37
__vfs_setxattr+0x208/0x23c fs/xattr.c:177
...
Now, ext4 try to store extent attribute into an external inode if
ext4_xattr_block_set() return -ENOSPC, but for the case of store an
empty extent attribute, store the extent entry into the extent
attribute block is enough. A simple reproduce below.
fallocate test.img -l 1M
mkfs.ext4 -F -b 2048 -O ea_inode test.img
mount test.img /mnt
dd if=/dev/zero of=/mnt/foo bs=2048 count=500
setfattr -n "user.test" /mnt/foo
Reported-by: syzbot+98b881fdd8ebf45ab4ae@syzkaller.appspotmail.com
Fixes: 9c6e7853c5 ("ext4: reserve space for xattr entries/names")
Cc: stable@kernel.org
Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
Link: https://lore.kernel.org/r/20210305120508.298465-1-yi.zhang@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b7ff91fd03 upstream.
If we failed to add new entry on rename whiteout, we cannot reset the
old->de entry directly, because the old->de could have moved from under
us during make indexed dir. So find the old entry again before reset is
needed, otherwise it may corrupt the filesystem as below.
/dev/sda: Entry '00000001' in ??? (12) has deleted/unused inode 15. CLEARED.
/dev/sda: Unattached inode 75
/dev/sda: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Fixes: 6b4b8e6b4a ("ext4: fix bug for rename with RENAME_WHITEOUT")
Cc: stable@vger.kernel.org
Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
Link: https://lore.kernel.org/r/20210303131703.330415-1-yi.zhang@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f053cf7aa6 upstream.
ext4 didn't properly clean up if verity failed to be enabled on a file:
- It left verity metadata (pages past EOF) in the page cache, which
would be exposed to userspace if the file was later extended.
- It didn't truncate the verity metadata at all (either from cache or
from disk) if an error occurred while setting the verity bit.
Fix these bugs by adding a call to truncate_inode_pages() and ensuring
that we truncate the verity metadata (both from cache and from disk) in
all error paths. Also rework the code to cleanly separate the success
path from the error paths, which makes it much easier to understand.
Reported-by: Yunlei He <heyunlei@hihonor.com>
Fixes: c93d8f8858 ("ext4: add basic fs-verity support")
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20210302200420.137977-2-ebiggers@kernel.org
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 483028edac upstream.
As per UEFI spec 2.8B section 8.2, EFI_UNSUPPORTED may be returned by
EFI variable runtime services if no variable storage is supported by
firmware. In this case, there is no point for kernel to continue
efivars initialization. That said, efivar_init() should fail by
returning an error code, so that efivarfs will not be mounted on
/sys/firmware/efi/efivars at all. Otherwise, user space like efibootmgr
will be confused by the EFIVARFS_MAGIC seen there, while EFI variable
calls cannot be made successfully.
Cc: <stable@vger.kernel.org> # v5.10+
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8c150ba2fb upstream.
The comment in get_nr_restart_syscall() says:
* The problem is that we can get here when ptrace pokes
* syscall-like values into regs even if we're not in a syscall
* at all.
Yes, but if not in a syscall then the
status & (TS_COMPAT|TS_I386_REGS_POKED)
check below can't really help:
- TS_COMPAT can't be set
- TS_I386_REGS_POKED is only set if regs->orig_ax was changed by
32bit debugger; and even in this case get_nr_restart_syscall()
is only correct if the tracee is 32bit too.
Suppose that a 64bit debugger plays with a 32bit tracee and
* Tracee calls sleep(2) // TS_COMPAT is set
* User interrupts the tracee by CTRL-C after 1 sec and does
"(gdb) call func()"
* gdb saves the regs by PTRACE_GETREGS
* does PTRACE_SETREGS to set %rip='func' and %orig_rax=-1
* PTRACE_CONT // TS_COMPAT is cleared
* func() hits int3.
* Debugger catches SIGTRAP.
* Restore original regs by PTRACE_SETREGS.
* PTRACE_CONT
get_nr_restart_syscall() wrongly returns __NR_restart_syscall==219, the
tracee calls ia32_sys_call_table[219] == sys_madvise.
Add the sticky TS_COMPAT_RESTART flag which survives after return to user
mode. It's going to be removed in the next step again by storing the
information in the restart block. As a further cleanup it might be possible
to remove also TS_I386_REGS_POKED with that.
Test-case:
$ cvs -d :pserver:anoncvs:anoncvs@sourceware.org:/cvs/systemtap co ptrace-tests
$ gcc -o erestartsys-trap-debuggee ptrace-tests/tests/erestartsys-trap-debuggee.c --m32
$ gcc -o erestartsys-trap-debugger ptrace-tests/tests/erestartsys-trap-debugger.c -lutil
$ ./erestartsys-trap-debugger
Unexpected: retval 1, errno 22
erestartsys-trap-debugger: ptrace-tests/tests/erestartsys-trap-debugger.c:421
Fixes: 609c19a385 ("x86/ptrace: Stop setting TS_COMPAT in ptrace code")
Reported-by: Jan Kratochvil <jan.kratochvil@redhat.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210201174709.GA17895@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 66c1b6d74c upstream.
Move TS_COMPAT back to asm/thread_info.h, close to TS_I386_REGS_POKED.
It was moved to asm/processor.h by b9d989c721 ("x86/asm: Move the
thread_info::status field to thread_struct"), then later 37a8f7c383
("x86/asm: Move 'status' from thread_struct to thread_info") moved the
'status' field back but TS_COMPAT was forgotten.
Preparatory patch to fix the COMPAT case for get_nr_restart_syscall()
Fixes: 609c19a385 ("x86/ptrace: Stop setting TS_COMPAT in ptrace code")
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210201174649.GA17880@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a501b048a9 upstream.
Vitaly ran into an issue with hotplugging CPU0 on an Amazon instance where
the matrix allocator claimed to be out of vectors. He analyzed it down to
the point that IRQ2, the PIC cascade interrupt, which is supposed to be not
ever routed to the IO/APIC ended up having an interrupt vector assigned
which got moved during unplug of CPU0.
The underlying issue is that IRQ2 for various reasons (see commit
af174783b9 ("x86: I/O APIC: Never configure IRQ2" for details) is treated
as a reserved system vector by the vector core code and is not accounted as
a regular vector. The Amazon BIOS has an routing entry of pin2 to IRQ2
which causes the IO/APIC setup to claim that interrupt which is granted by
the vector domain because there is no sanity check. As a consequence the
allocation counter of CPU0 underflows which causes a subsequent unplug to
fail with:
[ ... ] CPU 0 has 4294967295 vectors, 589 available. Cannot disable CPU
There is another sanity check missing in the matrix allocator, but the
underlying root cause is that the IO/APIC code lost the IRQ2 ignore logic
during the conversion to irqdomains.
For almost 6 years nobody complained about this wreckage, which might
indicate that this requirement could be lifted, but for any system which
actually has a PIC IRQ2 is unusable by design so any routing entry has no
effect and the interrupt cannot be connected to a device anyway.
Due to that and due to history biased paranoia reasons restore the IRQ2
ignore logic and treat it as non existent despite a routing entry claiming
otherwise.
Fixes: d32932d02e ("x86/irq: Convert IOAPIC to use hierarchical irqdomain interfaces")
Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210318192819.636943062@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2dc0572f2c upstream.
On a Haswell machine, the perf_fuzzer managed to trigger this message:
[117248.075892] unchecked MSR access error: WRMSR to 0x3f1 (tried to
write 0x0400000000000000) at rIP: 0xffffffff8106e4f4
(native_write_msr+0x4/0x20)
[117248.089957] Call Trace:
[117248.092685] intel_pmu_pebs_enable_all+0x31/0x40
[117248.097737] intel_pmu_enable_all+0xa/0x10
[117248.102210] __perf_event_task_sched_in+0x2df/0x2f0
[117248.107511] finish_task_switch.isra.0+0x15f/0x280
[117248.112765] schedule_tail+0xc/0x40
[117248.116562] ret_from_fork+0x8/0x30
A fake event called VLBR_EVENT may use the bit 58 of the PEBS_ENABLE, if
the precise_ip is set. The bit 58 is reserved by the HW. Accessing the
bit causes the unchecked MSR access error.
The fake event doesn't support PEBS. The case should be rejected.
Fixes: 097e4311cd ("perf/x86: Add constraint to create guest LBR event without hw counter")
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/1615555298-140216-2-git-send-email-kan.liang@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d88d05a9e0 upstream.
A repeatable crash can be triggered by the perf_fuzzer on some Haswell
system.
https://lore.kernel.org/lkml/7170d3b-c17f-1ded-52aa-cc6d9ae999f4@maine.edu/
For some old CPUs (HSW and earlier), the PEBS status in a PEBS record
may be mistakenly set to 0. To minimize the impact of the defect, the
commit was introduced to try to avoid dropping the PEBS record for some
cases. It adds a check in the intel_pmu_drain_pebs_nhm(), and updates
the local pebs_status accordingly. However, it doesn't correct the PEBS
status in the PEBS record, which may trigger the crash, especially for
the large PEBS.
It's possible that all the PEBS records in a large PEBS have the PEBS
status 0. If so, the first get_next_pebs_record_by_bit() in the
__intel_pmu_pebs_event() returns NULL. The at = NULL. Since it's a large
PEBS, the 'count' parameter must > 1. The second
get_next_pebs_record_by_bit() will crash.
Besides the local pebs_status, correct the PEBS status in the PEBS
record as well.
Fixes: 01330d7288 ("perf/x86: Allow zero PEBS status with only single active event")
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/1615555298-140216-1-git-send-email-kan.liang@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cc7a0bb058 upstream.
Both add_slot_store() and remove_slot_store() try to fix up the
drc_name copied from the store buffer by placing a NUL terminator at
nbyte + 1 or in place of a '\n' if present. However, the static buffer
that we copy the drc_name data into is not zeroed and can contain
anything past the n-th byte.
This is problematic if a '\n' byte appears in that buffer after nbytes
and the string copied into the store buffer was not NUL terminated to
start with as the strchr() search for a '\n' byte will mark this
incorrectly as the end of the drc_name string resulting in a drc_name
string that contains garbage data after the n-th byte.
Additionally it will cause us to overwrite that '\n' byte on the stack
with NUL, potentially corrupting data on the stack.
The following debugging shows an example of the drmgr utility writing
"PHB 4543" to the add_slot sysfs attribute, but add_slot_store()
logging a corrupted string value.
drmgr: drmgr: -c phb -a -s PHB 4543 -d 1
add_slot_store: drc_name = PHB 4543°|<82>!, rc = -19
Fix this by using strscpy() instead of memcpy() to ensure the string
is NUL terminated when copied into the static drc_name buffer.
Further, since the string is now NUL terminated the code only needs to
change '\n' to '\0' when present.
Cc: stable@vger.kernel.org
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
[mpe: Reformat change log and add mention of possible stack corruption]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210315214821.452959-1-tyreld@linux.ibm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b14d72ac73 upstream.
Ceiling value may be miss-aligned with what's actually configured into the
ARR register. This is seen after probe as currently the ARR value is zero,
whereas ceiling value is set to the maximum. So:
- reading ceiling reports zero
- in case the counter gets enabled without any prior configuration,
it won't count.
- in case the function gets set by the user 1st, (priv->ceiling) is used.
Fix it by getting rid of the cached "priv->ceiling" variable. Rather use
the ARR register value directly by using regmap read or write when needed.
There should be no drawback on performance as priv->ceiling isn't used in
performance critical path.
There's also no point in writing ARR while setting function (sms), so
it can be safely removed.
Fixes: ad29937e20 ("counter: Add STM32 Timer quadrature encoder")
Suggested-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1614793789-10346-1-git-send-email-fabrice.gasnier@foss.st.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
