Currently, when reading the following properties under
ucsi-source-psy-*, src_pdos array is accessed but it only checks
for the condition num_pdos > 0.
- voltage_max
- voltage_now
- current_max
In the case if a PPM passes num_pdos greater than UCSI_MAX_PDOS,
an OOB access can be made. Fix it by checking the upper bound for
src_pdos which is UCSI_MAX_PDOS.
This issue is detected by enabling UBSAN.
Bug: 186400956
Fixes: 992a60ed0d ("usb: typec: ucsi: register with power_supply class")
Fixes: 4dbc6a4ef0 ("usb: typec: ucsi: save power data objects in PD mode")
Change-Id: Id0aca674208b23329be089671cba873baca930cf
Signed-off-by: Subbaraman Narayanamurthy <quic_subbaram@quicinc.com>
Not_Supported Message is acceptable in VDM AMS. Redirect the VDM state
machine to VDM_STATE_DONE when receiving Not_Supported and finish the
VDM AMS.
Also, after the loop in vdm_state_machine_work, add more conditions of
VDM states to clear the vdm_sm_running flag because those are all
stopping states when leaving the loop.
In addition, finish the VDM AMS if the port partner responds BUSY.
Fixes: 8dea75e113 ("usb: typec: tcpm: Protocol Error handling")
Fixes: 8d3a0578ad ("usb: typec: tcpm: Respond Wait if VDM state machine is running")
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Kyle Tso <kyletso@google.com>
Link: https://lore.kernel.org/r/20210507062300.1945009-3-kyletso@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f1fbd950b5https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia52ad69f054b2211924ec3815b5a3d2cc09d8b88
When extcon is used in combination with dwc3, it is assumed that the dwc3
registers are untouched and as such are only configured if VBUS is valid
or ID is tied to ground.
In case VBUS is not valid or ID is floating, the registers are not
configured as such during driver initialization, causing a wrong
default state during boot.
If the registers are not in a default state, because they are for
instance touched by a boot loader, this can cause for a kernel error.
Signed-off-by: Marcel Hamer <marcel@solidxs.se>
Link: https://lore.kernel.org/r/20210427122118.1948340-1-marcel@solidxs.se
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e17b02d497https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ic460a111f59e5a4fd77db0402fb297e53bbc1d9e
As part of commit e81a7018d9 ("usb: dwc3: allocate gadget structure
dynamically") the dwc3_gadget_release() was added which will free
the dwc->gadget structure upon the device's removal when
usb_del_gadget_udc() is called in dwc3_gadget_exit().
However, simply freeing the gadget results a dangling pointer
situation: the endpoints created in dwc3_gadget_init_endpoints()
have their dep->endpoint.ep_list members chained off the list_head
anchored at dwc->gadget->ep_list. Thus when dwc->gadget is freed,
the first dwc3_ep in the list now has a dangling prev pointer and
likewise for the next pointer of the dwc3_ep at the tail of the list.
The dwc3_gadget_free_endpoints() that follows will result in a
use-after-free when it calls list_del().
This was caught by enabling KASAN and performing a driver unbind.
The recent commit 568262bf54 ("usb: dwc3: core: Add shutdown
callback for dwc3") also exposes this as a panic during shutdown.
There are a few possibilities to fix this. One could be to perform
a list_del() of the gadget->ep_list itself which removes it from
the rest of the dwc3_ep chain.
Another approach is what this patch does, by splitting up the
usb_del_gadget_udc() call into its separate "del" and "put"
components. This allows dwc3_gadget_free_endpoints() to be
called before the gadget is finally freed with usb_put_gadget().
Fixes: e81a7018d9 ("usb: dwc3: allocate gadget structure dynamically")
Reviewed-by: Peter Chen <peter.chen@kernel.org>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Link: https://lore.kernel.org/r/20210501093558.7375-1-jackp@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit bb9c74a5bdhttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0062f1ccdda604938d8e2f68de4ae27360397d9f
The dwc2 gadget support maps and unmaps DMA buffers as necessary. When
mapping and unmapping it uses the direction of the endpoint to select
the direction of the DMA transfer, but this fails for Control OUT
transfers because the unmap occurs after the endpoint direction has
been reversed for the status phase.
A possible solution would be to unmap the buffer before the direction
is changed, but a safer, less invasive fix is to remember the buffer
direction independently of the endpoint direction.
Fixes: fe0b94abcd ("usb: dwc2: gadget: manage ep0 state in software")
Acked-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Link: https://lore.kernel.org/r/20210506112200.2893922-1-phil@raspberrypi.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 75a41ce46bhttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1cdc8528842a33cadb0e05852b95670360db8ad3
The device event corresponding to End of Periodic Frame is only
found on older IP revisions (2.10a and prior, according to a
cursory SNPS databook search). On revisions 2.30a and newer,
including DWC3.1, the same event value and corresponding DEVTEN
bit were repurposed to indicate that the link has gone into
suspend state (U3 or L2/L1).
EOPF events had never been enabled before in this driver, and
going forward we expect current and future DWC3-based devices
won't likely to be using such old DWC3 IP revisions either.
Hence rather than keeping the deprecated EOPF macro names let's
rename them to indicate their usage for suspend events.
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Link: https://lore.kernel.org/r/20210428090111.3370-2-jackp@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6f26ebb79ahttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I8351dd713ce0e60b2212a22a3b51d1139ae89779
This reverts commit fb4c1c2e9f.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I7b12040440bc2bedfbabc71d60339cb843e59570
This reverts commit 2e8b3b0b8e.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I03a41fc3ba455ded7274f2a6b5566bb369a75a86
This reverts commit 22163a8ec8.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie256b7f1ed5b19f4600ff4c3681efaea5046adda
This reverts commit 1bbcc985d1.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I88427586de4df897c39bb3d48e8cba86ebf5c4bb
This reverts commit 1f2ef5a0f7.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I461f44ec54102dcf06ba73959a79172615cdb8fa
This reverts commit 9efd5df078.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia22b608e4d017c6056e481d2ec819074b35810cf
This reverts commit 25ed8827cf.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9928cdc06a26b9db3052b93067c557011e53f735
This reverts commit 85a5a6875c.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ibe7639f73acc11b356f6b2f8f76011844c7f451b
This reverts commit f8e71c667e.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6684b40d913a86b79899220cba823a74aea5923f
This reverts commit 2fa0387fa2.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: If6aba0f06d169907827ca1f76b52adc75c84c124
Changes in 5.10.35
mips: Do not include hi and lo in clobber list for R6
netfilter: conntrack: Make global sysctls readonly in non-init netns
net: usb: ax88179_178a: initialize local variables before use
igb: Enable RSS for Intel I211 Ethernet Controller
bpf: Fix masking negation logic upon negative dst register
bpf: Fix leakage of uninitialized bpf stack under speculation
net: qrtr: Avoid potential use after free in MHI send
perf data: Fix error return code in perf_data__create_dir()
capabilities: require CAP_SETFCAP to map uid 0
perf ftrace: Fix access to pid in array when setting a pid filter
tools/cgroup/slabinfo.py: updated to work on current kernel
driver core: add a min_align_mask field to struct device_dma_parameters
swiotlb: add a IO_TLB_SIZE define
swiotlb: factor out an io_tlb_offset helper
swiotlb: factor out a nr_slots helper
swiotlb: clean up swiotlb_tbl_unmap_single
swiotlb: refactor swiotlb_tbl_map_single
swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single
swiotlb: respect min_align_mask
nvme-pci: set min_align_mask
ovl: fix leaked dentry
ovl: allow upperdir inside lowerdir
ALSA: usb-audio: Add MIDI quirk for Vox ToneLab EX
USB: Add LPM quirk for Lenovo ThinkPad USB-C Dock Gen2 Ethernet
USB: Add reset-resume quirk for WD19's Realtek Hub
platform/x86: thinkpad_acpi: Correct thermal sensor allocation
perf/core: Fix unconditional security_locked_down() call
vfio: Depend on MMU
Linux 5.10.35
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iff7d5abe7b821f453bbe4d9dad94dfd35fe0a082
The inflight of partition 0 doesn't include inflight IOs to all
sub-partitions, since currently mq calculates inflight of specific
partition by simply camparing the value of the partition pointer.
Thus the following case is possible:
$ cat /sys/block/vda/inflight
0 0
$ cat /sys/block/vda/vda1/inflight
0 128
While single queue device (on a previous version, e.g. v3.10) has no
this issue:
$cat /sys/block/sda/sda3/inflight
0 33
$cat /sys/block/sda/inflight
0 33
Partition 0 should be specially handled since it represents the whole
disk. This issue is introduced since commit bf0ddaba65 ("blk-mq: fix
sysfs inflight counter").
Besides, this patch can also fix the inflight statistics of part 0 in
/proc/diskstats. Before this patch, the inflight statistics of part 0
doesn't include that of sub partitions. (I have marked the 'inflight'
field with asterisk.)
$cat /proc/diskstats
259 0 nvme0n1 45974469 0 367814768 6445794 1 0 1 0 *0* 111062 6445794 0 0 0 0 0 0
259 2 nvme0n1p1 45974058 0 367797952 6445727 0 0 0 0 *33* 111001 6445727 0 0 0 0 0 0
This is introduced since commit f299b7c7a9 ("blk-mq: provide internal
in-flight variant").
Fixes: bf0ddaba65 ("blk-mq: fix sysfs inflight counter")
Fixes: f299b7c7a9 ("blk-mq: provide internal in-flight variant")
Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
[axboe: adapt for 5.11 partition change]
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Bug: 187355247
Change-Id: I378b2cb7312a5e47d5e2ec7301dc392e6e7336d0
(cherry picked from commit b0d97557eb)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Set KMI_GENERATION=4 for 5/7 KMI update
Leaf changes summary: 2821 artifacts changed
Changed leaf types summary: 17 leaf types changed
Removed/Changed/Added functions summary: 1 Removed, 2752 Changed, 1 Added function
Removed/Changed/Added variables summary: 0 Removed, 49 Changed, 1 Added variable
1 Removed function:
[D] 'function file* filp_open(const char*, int, umode_t)'
1 Added function:
[A] 'function int __traceiter_android_vh_of_i2c_get_board_info(void*, device_node*, const char**)'
2752 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 0x53dbf80f to 0x27c5b1f0
[C] 'function void __ClearPageMovable(page*)' at compaction.c:138:1 has some sub-type changes:
CRC (modversions) changed from 0xc7c1f13e to 0x22571ed2
[C] 'function void __SetPageMovable(page*, address_space*)' at compaction.c:130:1 has some sub-type changes:
CRC (modversions) changed from 0x3b98a825 to 0x5f77584f
... 2749 omitted; 2752 symbols have only CRC changes
1 Added variable:
[A] 'tracepoint __tracepoint_android_vh_of_i2c_get_board_info'
49 Changed variables:
[C] 'bus_type amba_bustype' was changed at bus.c:215:1:
CRC (modversions) changed from 0x33a71197 to 0xabc9cec3
[C] 'const address_space_operations balloon_aops' was changed at balloon_compaction.c:253:1:
CRC (modversions) changed from 0x50598639 to 0xb8eca1a2
[C] 'const clk_ops clk_fixed_factor_ops' was changed at clk-fixed-factor.c:60:1:
CRC (modversions) changed from 0xaa612693 to 0xdbcf0d4e
... 46 omitted; 49 symbols have only CRC changes
'enum android_debug_symbol at android_debug_symbols.h:9:1' changed:
type size hasn't changed
7 enumerator insertions:
'android_debug_symbol::ADS_TOTAL_CMA' value '7'
'android_debug_symbol::ADS_SLAB_CACHES' value '8'
'android_debug_symbol::ADS_SLAB_MUTEX' value '9'
'android_debug_symbol::ADS_MIN_LOW_PFN' value '10'
'android_debug_symbol::ADS_MAX_PFN' value '11'
'android_debug_symbol::ADS_PAGE_OWNER_ENABLED' value '12'
'android_debug_symbol::ADS_SLUB_DEBUG' value '13'
1 enumerator change:
'android_debug_symbol::ADS_END' from value '7' to '14' at android_debug_symbols.h:9:1
one impacted interface
'enum binder_work_type at binder_internal.h:174:1' changed:
type size hasn't changed
1 enumerator insertion:
'binder_work_type::BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT' value '3'
5 enumerator changes:
'binder_work_type::BINDER_WORK_RETURN_ERROR' from value '3' to '4' at binder_internal.h:174:1
'binder_work_type::BINDER_WORK_NODE' from value '4' to '5' at binder_internal.h:174:1
'binder_work_type::BINDER_WORK_DEAD_BINDER' from value '5' to '6' at binder_internal.h:174:1
'binder_work_type::BINDER_WORK_DEAD_BINDER_AND_CLEAR' from value '6' to '7' at binder_internal.h:174:1
'binder_work_type::BINDER_WORK_CLEAR_DEATH_NOTIFICATION' from value '7' to '8' at binder_internal.h:174:1
5 impacted interfaces
'struct binder_alloc at binder_alloc.h:96:1' changed:
type size changed from 1024 to 1088 (in bits)
1 data member insertion:
'bool oneway_spam_detected', at offset 1024 (in bits) at binder_alloc.h:115:1
5 impacted interfaces
'struct binder_buffer at binder_alloc.h:40:1' changed:
type size hasn't changed
1 data member insertion:
'unsigned int oneway_spam_suspect', at offset 4 (in bits) at binder_alloc.h:50:1
there are data member changes:
'unsigned int debug_id' offset changed (by +1 bits)
4 impacted interfaces
'struct binder_proc at binder_internal.h:436:1' changed:
type size changed from 4480 to 4672 (in bits)
1 data member insertion:
'bool oneway_spam_detection_enabled', at offset 4608 (in bits) at binder_internal.h:471:1
there are data member changes:
type 'struct binder_stats' of 'binder_proc::stats' changed:
type size changed from 1664 to 1696 (in bits)
there are data member changes:
type 'atomic_t[19]' of 'binder_stats::br' changed:
type name changed from 'atomic_t[19]' to 'atomic_t[20]'
array type size changed from 608 to 640
array type subrange 1 changed length from 19 to 20
3 ('atomic_t bc[19]' .. 'atomic_t obj_deleted[7]') offsets changed (by +32 bits)
5 impacted interfaces
7 ('list_head delivered_death' .. 'dentry* debugfs_entry') offsets changed (by +64 bits)
type 'struct binder_alloc' of 'binder_proc::alloc' changed, as reported earlier
and offset changed from 3264 to 3328 (in bits) (by +64 bits)
4 ('binder_context* context' .. 'dentry* binderfs_entry') offsets changed (by +128 bits)
5 impacted interfaces
'struct binder_stats at binder_internal.h:157:1' changed:
details were reported earlier
'struct binder_thread at binder_internal.h:507:1' changed (indirectly):
type size changed from 3264 to 3328 (in bits)
there are data member changes:
type 'struct binder_stats' of 'binder_thread::stats' changed, as reported earlier
2 ('atomic_t tmp_ref' .. 'bool is_dead') offsets changed (by +32 bits)
'task_struct* task' offset changed (by +64 bits)
4 impacted interfaces
'struct dwc3 at core.h:1080:1' changed:
type size changed from 9216 to 9984 (in bits)
5 data member insertions:
'mutex mutex', at offset 2624 (in bits) at core.h:1115:1
'u64 android_kabi_reserved1', at offset 9728 (in bits) at core.h:1302:1
'u64 android_kabi_reserved2', at offset 9792 (in bits) at core.h:1303:1
'u64 android_kabi_reserved3', at offset 9856 (in bits) at core.h:1304:1
'u64 android_kabi_reserved4', at offset 9920 (in bits) at core.h:1305:1
there are data member changes:
type 'struct dwc3_request' of 'dwc3::ep0_usb_req' changed:
type size changed from 1472 to 1600 (in bits)
2 data member insertions:
'u64 android_kabi_reserved1', at offset 1472 (in bits) at core.h:947:1
'u64 android_kabi_reserved2', at offset 1536 (in bits) at core.h:948:1
2 impacted interfaces
2 ('completion ep0_in_setup' .. 'spinlock_t lock') offsets changed (by +128 bits)
53 ('device* dev' .. 'u8 num_eps') offsets changed (by +384 bits)
type 'struct dwc3_hwparams' of 'dwc3::hwparams' changed:
type size changed from 288 to 448 (in bits)
3 data member insertions:
'u32 hwparams9', at offset 288 (in bits) at core.h:872:1
'u64 android_kabi_reserved1', at offset 320 (in bits) at core.h:874:1
'u64 android_kabi_reserved2', at offset 384 (in bits) at core.h:875:1
2 impacted interfaces
and offset changed from 8512 to 8896 (in bits) (by +384 bits)
13 ('dentry* root' .. 'u16 imod_interval') offsets changed (by +512 bits)
2 impacted interfaces
'struct dwc3_ep at core.h:696:1' changed:
type size changed from 1664 to 1792 (in bits)
2 data member insertions:
'u64 android_kabi_reserved1', at offset 1664 (in bits) at core.h:761:1
'u64 android_kabi_reserved2', at offset 1728 (in bits) at core.h:762:1
2 impacted interfaces
'struct dwc3_event_buffer at core.h:646:1' changed:
type size changed from 384 to 448 (in bits)
1 data member insertion:
'u64 android_kabi_reserved1', at offset 384 (in bits) at core.h:666:1
2 impacted interfaces
'struct dwc3_hwparams at core.h:851:1' changed:
details were reported earlier
'struct dwc3_request at core.h:902:1' changed:
details were reported earlier
'struct mod_arch_specific at module.h:17:1' changed:
type size changed from 256 to 448 (in bits)
4 data member insertions:
'const Elf64_Rela* text_relocations', at offset 256 (in bits) at module.h:25:1
'const Elf64_Rela* rodata_relocations', at offset 320 (in bits) at module.h:26:1
'int num_text_relocations', at offset 384 (in bits) at module.h:27:1
'int num_rodata_relocations', at offset 416 (in bits) at module.h:28:1
2074 impacted interfaces
'struct module at module.h:367:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'struct mod_arch_specific' of 'module::arch' changed, as reported earlier
41 ('unsigned long int taints' .. 'u64 android_kabi_reserved4') offsets changed (by +192 bits)
2074 impacted interfaces
'struct queue_limits at blkdev.h:318:1' changed:
type size changed from 896 to 960 (in bits)
1 data member insertion:
'unsigned int bio_max_bytes', at offset 0 (in bits) at blkdev.h:319:1
there are data member changes:
27 ('unsigned long int bounce_pfn' .. 'blk_zoned_model zoned') offsets changed (by +64 bits)
2075 impacted interfaces
'struct request_queue at blkdev.h:396:1' changed (indirectly):
type size changed from 15104 to 15168 (in bits)
there are data member changes:
type 'struct queue_limits' of 'request_queue::limits' changed, as reported earlier
27 ('unsigned int required_elevator_features' .. 'u64 write_hints[5]') offsets changed (by +64 bits)
2074 impacted interfaces
'struct rproc_ops at remoteproc.h:380:1' changed:
type size hasn't changed
there are data member changes:
type 'void* (rproc*, typedef u64, typedef size_t)*' of 'rproc_ops::da_to_va' changed:
pointer type changed from: 'void* (rproc*, typedef u64, typedef size_t)*' to: 'void* (rproc*, typedef u64, typedef size_t, bool*)*'
17 impacted interfaces
Bug: 187507598
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I70911d8a70cb00828dcc6ce601e97a5a4ef1eace
bio size can grow up to 4GB when muli-page bvec is enabled.
but sometimes it would lead to inefficient behaviors.
in case of large chunk direct I/O, - 32MB chunk read in user space -
all pages for 32MB would be merged to a bio structure if the pages
physical addresses are contiguous. it makes some delay to submit
until merge complete. bio max size should be limited to a proper size.
When 32MB chunk read with direct I/O option is coming from userspace,
kernel behavior is below now in do_direct_IO() loop. it's timeline.
| bio merge for 32MB. total 8,192 pages are merged.
| total elapsed time is over 2ms.
|------------------ ... ----------------------->|
| 8,192 pages merged a bio.
| at this time, first bio submit is done.
| 1 bio is split to 32 read request and issue.
|--------------->
|--------------->
|--------------->
......
|--------------->
|--------------->|
total 19ms elapsed to complete 32MB read done from device. |
If bio max size is limited with 1MB, behavior is changed below.
| bio merge for 1MB. 256 pages are merged for each bio.
| total 32 bio will be made.
| total elapsed time is over 2ms. it's same.
| but, first bio submit timing is fast. about 100us.
|--->|--->|--->|---> ... -->|--->|--->|--->|--->|
| 256 pages merged a bio.
| at this time, first bio submit is done.
| and 1 read request is issued for 1 bio.
|--------------->
|--------------->
|--------------->
......
|--------------->
|--------------->|
total 17ms elapsed to complete 32MB read done from device. |
As a result, read request issue timing is faster if bio max size is limited.
Current kernel behavior with multipage bvec, super large bio can be created.
And it lead to delay first I/O request issue.
Signed-off-by: Changheun Lee <nanich.lee@samsung.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20210503095203.29076-1-nanich.lee@samsung.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Bug: 182716953
(cherry picked from commit cd2c7545ae)
Change-Id: Ie3876daa495535dc7f856ed9a281e65d72a437c1
Signed-off-by: Bart Van Assche <bvanassche@google.com>
"dev_name" for I2C devices won't have any value set, unless they are
instantiated thru ACPI interface. As a result of this, I2C driver will
assign some dynamic name in the format "%d-%04x" (e.g. 1-001f), and
further this device names are used for kernel wakelocks.
This dynamic names are difficult to associate with actual device and
hence it will help to have an ability where vendor can assign the
device name through vendor hooks.
Bug: 147496295
Signed-off-by: Manish Varma <varmam@google.com>
Change-Id: Idb417ef5330002063a9763544f9f0364f9581276
When async binder buffer got exhausted, some normal oneway transactions
will also be discarded and may cause system or application failures. By
that time, the binder debug information we dump may not be relevant to
the root cause. And this issue is difficult to debug if without the
backtrace of the thread sending spam.
This change will send BR_ONEWAY_SPAM_SUSPECT to userspace when oneway
spamming is detected, request to dump current backtrace. Oneway spamming
will be reported only once when exceeding the threshold (target process
dips below 80% of its oneway space, and current process is responsible
for either more than 50 transactions, or more than 50% of the oneway
space). And the detection will restart when the async buffer has
returned to a healthy state.
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Hang Lu <hangl@codeaurora.org>
Link: https://lore.kernel.org/r/1617961246-4502-3-git-send-email-hangl@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 181190340
Change-Id: Id3d2526099bc89f04d8ad3ad6e48141b2a8f2515
(cherry picked from commit a7dc1e6f99)
Signed-off-by: Hang Lu <hangl@codeaurora.org>
The fips140.ko module relies on ELF metadata that is normally discarded
by the module loader. In order to reduce the impact of the associated
changes on non-FIPS140 kernels, the module loader will be modified to
simply copy this metadata if it encounters a module whose name is
'fips140'. For this to work, we need a couple of fields in struct
mod_arch_specific so that this module can find this data at module init
time.
Adding these fields will change the type signature of struct module, and
hence affect the stable ABI. The FIPS140 module build depends on LTO,
and so its Kconfig symbol can only be enabled if LTO is enabled as well.
This implies that adding these mod_arch_specific fields conditionally,
based on CONFIG_CRYPTO_FIPS140_INTEGRITY_CHECK, would result in an ABI
fork between LTO and !LTO builds, which is obviously undesirable.
So let's just add these fields unconditionally. This will take 24 bytes
of kernel memory per module, but given that the size of struct module
(which is the only place where struct mod_arch_specific is allocated) is
rounded up to cacheline size (128 bytes on arm64), and this change does
not push it over the edge, the net result is that no additional memory
is used (struct module is currently 1 KiB)
Bug: 153614920
Change-Id: Ia617762f37c0bf7324e899b72fd317e382e39c03
Signed-off-by: Ard Biesheuvel <ardb@google.com>
A number of systems want access to the zram flip_open functionality,
which is now called filp_open_block() to remove any possiblity of bad
drivers trying to access filesystems directly.
Fix up the two symbol lists that were referring to the wrong symbol.
Bug: 157965270
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I368da14ca739b6048dd88a38fca4af8b7f02714d
Try to mitigate potential future driver core api changes by adding
padding to a number of dwc3 structures.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1826d885e3acf1f378d0e30b1ca2ddc56b16a9e4
Add symbols which will be used by the minidump module to
the debug symbol driver.
Bug: 184707701
Change-Id: I4cfdc59e0fcab89ad4df4fcb4de4a706a9c84cf8
Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
Add __bitmap_andnot and cpumask_any_but to symbol list.
Bug: 187463586
Change-Id: I936ee9778040ba96a3937e21da0c886b2929df7c
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
To free the fifo buffer allocated by __kfifo_alloc we need to use
__kfifo_free. This change adds the __kfifo_free symbol to the
qcom symbol list.
Bug: 184180643
Change-Id: I2d8a719be61af59cd0c7fd59b8d6957a0e5050e0
Signed-off-by: Siddharth Gupta <quic_sidgup@quicinc.com>
commit b2b12db535 upstream.
VFIO_IOMMU_TYPE1 does not compile with !MMU:
../drivers/vfio/vfio_iommu_type1.c: In function 'follow_fault_pfn':
../drivers/vfio/vfio_iommu_type1.c:536:22: error: implicit declaration of function 'pte_write'; did you mean 'vfs_write'? [-Werror=implicit-function-declaration]
So require it.
Suggested-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Message-Id: <0-v1-02cb5500df6e+78-vfio_no_mmu_jgg@nvidia.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 08ef1af4de upstream.
Currently, the lockdown state is queried unconditionally, even though
its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in
attr.sample_type. While that doesn't matter in case of the Lockdown LSM,
it causes trouble with the SELinux's lockdown hook implementation.
SELinux implements the locked_down hook with a check whether the current
task's type has the corresponding "lockdown" class permission
("integrity" or "confidentiality") allowed in the policy. This means
that calling the hook when the access control decision would be ignored
generates a bogus permission check and audit record.
Fix this by checking sample_type first and only calling the hook when
its result would be honored.
Fixes: b0c8fdc7fd ("lockdown: Lock down perf when in confidentiality mode")
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Paul Moore <paul@paul-moore.com>
Link: https://lkml.kernel.org/r/20210224215628.192519-1-omosnace@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6759e18e5c upstream.
On recent Thinkpad platforms it was reported that temp sensor 11 was
always incorrectly displaying 66C. It turns out the reason for this is
that this location in EC RAM is not a temperature sensor but is the
power supply ID (offset 0xC2).
Based on feedback from the Lenovo firmware team the EC RAM version can
be determined and for the current version (3) only the 0x78 to 0x7F
range is used for temp sensors. I don't have any details for earlier
versions so I have left the implementation unaltered there.
Note - in this block only 0x78 and 0x79 are officially designated (CPU &
GPU sensors). The use of the other locations in the block will vary from
platform to platform; but the existing logic to detect a sensor presence
holds.
Signed-off-by: Mark Pearson <markpearson@lenovo.com>
Link: https://lore.kernel.org/r/20210407212015.298222-1-markpearson@lenovo.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ca91fd8c76 upstream.
Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work
after the system resumes from suspend with remote wakeup enabled
device connected:
[ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71)
[ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71)
Information of this hub:
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 5
D: Ver= 2.10 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=5487 Rev= 1.47
S: Manufacturer=Dell Inc.
S: Product=Dell dock
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=01 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms
The failure results from the ETIMEDOUT by chance when turning on
the suspend feature for the specified port of the hub. The port
seems to be in an unknown state so the hub_activate during resume
fails the hub_port_status, then the hub will fail to work.
The quirky hub needs the reset-resume quirk to function correctly.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210420174651.6202-1-chris.chiu@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 708fa01597 upstream.
Commit 146d62e5a5 ("ovl: detect overlapping layers") made sure we don't
have overlapping layers, but it also broke the arguably valid use case of
mount -olowerdir=/,upperdir=/subdir,..
where upperdir overlaps lowerdir on the same filesystem. This has been
causing regressions.
Revert the check, but only for the specific case where upperdir and/or
workdir are subdirectories of lowerdir. Any other overlap (e.g. lowerdir
is subdirectory of upperdir, etc) case is crazy, so leave the check in
place for those.
Overlaps are detected at lookup time too, so reverting the mount time check
should be safe.
Fixes: 146d62e5a5 ("ovl: detect overlapping layers")
Cc: <stable@vger.kernel.org> # v5.2
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit eaab1d45cd upstream.
Since commit 6815f479ca ("ovl: use only uppermetacopy state in
ovl_lookup()"), overlayfs doesn't put temporary dentry when there is a
metacopy error, which leads to dentry leaks when shutting down the related
superblock:
overlayfs: refusing to follow metacopy origin for (/file0)
...
BUG: Dentry (____ptrval____){i=3f33,n=file3} still in use (1) [unmount of overlay overlay]
...
WARNING: CPU: 1 PID: 432 at umount_check.cold+0x107/0x14d
CPU: 1 PID: 432 Comm: unmount-overlay Not tainted 5.12.0-rc5 #1
...
RIP: 0010:umount_check.cold+0x107/0x14d
...
Call Trace:
d_walk+0x28c/0x950
? dentry_lru_isolate+0x2b0/0x2b0
? __kasan_slab_free+0x12/0x20
do_one_tree+0x33/0x60
shrink_dcache_for_umount+0x78/0x1d0
generic_shutdown_super+0x70/0x440
kill_anon_super+0x3e/0x70
deactivate_locked_super+0xc4/0x160
deactivate_super+0xfa/0x140
cleanup_mnt+0x22e/0x370
__cleanup_mnt+0x1a/0x30
task_work_run+0x139/0x210
do_exit+0xb0c/0x2820
? __kasan_check_read+0x1d/0x30
? find_held_lock+0x35/0x160
? lock_release+0x1b6/0x660
? mm_update_next_owner+0xa20/0xa20
? reacquire_held_locks+0x3f0/0x3f0
? __sanitizer_cov_trace_const_cmp4+0x22/0x30
do_group_exit+0x135/0x380
__do_sys_exit_group.isra.0+0x20/0x20
__x64_sys_exit_group+0x3c/0x50
do_syscall_64+0x45/0x70
entry_SYSCALL_64_after_hwframe+0x44/0xae
...
VFS: Busy inodes after unmount of overlay. Self-destruct in 5 seconds. Have a nice day...
This fix has been tested with a syzkaller reproducer.
Cc: Amir Goldstein <amir73il@gmail.com>
Cc: <stable@vger.kernel.org> # v5.8+
Reported-by: syzbot <syzkaller@googlegroups.com>
Fixes: 6815f479ca ("ovl: use only uppermetacopy state in ovl_lookup()")
Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com>
Link: https://lore.kernel.org/r/20210329164907.2133175-1-mic@digikod.net
Reviewed-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit: 3d2d861eb0
The PRP addressing scheme requires all PRP entries except for the
first one to have a zero offset into the NVMe controller pages (which
can be different from the Linux PAGE_SIZE). Use the min_align_mask
device parameter to ensure that swiotlb does not change the address
of the buffer modulo the device page size to ensure that the PRPs
won't be malformed.
Signed-off-by: Jianxiong Gao <jxgao@google.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Tested-by: Jianxiong Gao <jxgao@google.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit: 1f221a0d0d
swiotlb: respect min_align_mask
Respect the min_align_mask in struct device_dma_parameters in swiotlb.
There are two parts to it:
1) for the lower bits of the alignment inside the io tlb slot, just
extent the size of the allocation and leave the start of the slot
empty
2) for the high bits ensure we find a slot that matches the high bits
of the alignment to avoid wasting too much memory
Based on an earlier patch from Jianxiong Gao <jxgao@google.com>.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jianxiong Gao <jxgao@google.com>
Tested-by: Jianxiong Gao <jxgao@google.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jianxiong Gao <jxgao@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit: 16fc3cef33
swiotlb_tbl_map_single currently nevers sets a tlb_addr that is not
aligned to the tlb bucket size. But we're going to add such a case
soon, for which this adjustment would be bogus.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jianxiong Gao <jxgao@google.com>
Tested-by: Jianxiong Gao <jxgao@google.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jianxiong Gao <jxgao@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
