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>
commit: ca10d0f8e5
swiotlb: clean up swiotlb_tbl_unmap_single
Remove a layer of pointless indentation, replace a hard to follow
ternary expression with a plain if/else.
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: 36950f2da1
Some devices rely on the address offset in a page to function
correctly (NVMe driver as an example). These devices may use
a different page size than the Linux kernel. The address offset
has to be preserved upon mapping, and in order to do so, we
need to record the page_offset_mask first.
Signed-off-by: Jianxiong Gao <jxgao@google.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 671b60cb6a ]
Command 'perf ftrace -v -- ls' fails in s390 (at least 5.12.0rc6).
The root cause is a missing pointer dereference which causes an
array element address to be used as PID.
Fix this by extracting the PID.
Output before:
# ./perf ftrace -v -- ls
function_graph tracer is used
write '-263732416' to tracing/set_ftrace_pid failed: Invalid argument
failed to set ftrace pid
#
Output after:
./perf ftrace -v -- ls
function_graph tracer is used
# tracer: function_graph
#
# CPU DURATION FUNCTION CALLS
# | | | | | | |
4) | rcu_read_lock_sched_held() {
4) 0.552 us | rcu_lockdep_current_cpu_online();
4) 6.124 us | }
Reported-by: Alexander Schmidt <alexschm@de.ibm.com>
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Sven Schnelle <svens@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Link: http://lore.kernel.org/lkml/20210421120400.2126433-1-tmricht@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit db2e718a47 ]
cap_setfcap is required to create file capabilities.
Since commit 8db6c34f1d ("Introduce v3 namespaced file capabilities"),
a process running as uid 0 but without cap_setfcap is able to work
around this as follows: unshare a new user namespace which maps parent
uid 0 into the child namespace.
While this task will not have new capabilities against the parent
namespace, there is a loophole due to the way namespaced file
capabilities are represented as xattrs. File capabilities valid in
userns 1 are distinguished from file capabilities valid in userns 2 by
the kuid which underlies uid 0. Therefore the restricted root process
can unshare a new self-mapping namespace, add a namespaced file
capability onto a file, then use that file capability in the parent
namespace.
To prevent that, do not allow mapping parent uid 0 if the process which
opened the uid_map file does not have CAP_SETFCAP, which is the
capability for setting file capabilities.
As a further wrinkle: a task can unshare its user namespace, then open
its uid_map file itself, and map (only) its own uid. In this case we do
not have the credential from before unshare, which was potentially more
restricted. So, when creating a user namespace, we record whether the
creator had CAP_SETFCAP. Then we can use that during map_write().
With this patch:
1. Unprivileged user can still unshare -Ur
ubuntu@caps:~$ unshare -Ur
root@caps:~# logout
2. Root user can still unshare -Ur
ubuntu@caps:~$ sudo bash
root@caps:/home/ubuntu# unshare -Ur
root@caps:/home/ubuntu# logout
3. Root user without CAP_SETFCAP cannot unshare -Ur:
root@caps:/home/ubuntu# /sbin/capsh --drop=cap_setfcap --
root@caps:/home/ubuntu# /sbin/setcap cap_setfcap=p /sbin/setcap
unable to set CAP_SETFCAP effective capability: Operation not permitted
root@caps:/home/ubuntu# unshare -Ur
unshare: write failed /proc/self/uid_map: Operation not permitted
Note: an alternative solution would be to allow uid 0 mappings by
processes without CAP_SETFCAP, but to prevent such a namespace from
writing any file capabilities. This approach can be seen at [1].
Background history: commit 95ebabde38 ("capabilities: Don't allow
writing ambiguous v3 file capabilities") tried to fix the issue by
preventing v3 fscaps to be written to disk when the root uid would map
to the same uid in nested user namespaces. This led to regressions for
various workloads. For example, see [2]. Ultimately this is a valid
use-case we have to support meaning we had to revert this change in
3b0c2d3eaa ("Revert 95ebabde38 ("capabilities: Don't allow writing
ambiguous v3 file capabilities")").
Link: https://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux.git/log/?h=2021-04-15/setfcap-nsfscaps-v4 [1]
Link: https://github.com/containers/buildah/issues/3071 [2]
Signed-off-by: Serge Hallyn <serge@hallyn.com>
Reviewed-by: Andrew G. Morgan <morgan@kernel.org>
Tested-by: Christian Brauner <christian.brauner@ubuntu.com>
Reviewed-by: Christian Brauner <christian.brauner@ubuntu.com>
Tested-by: Giuseppe Scrivano <gscrivan@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 47a017f339 upstream.
It is possible that the MHI ul_callback will be invoked immediately
following the queueing of the skb for transmission, leading to the
callback decrementing the refcount of the associated sk and freeing the
skb.
As such the dereference of skb and the increment of the sk refcount must
happen before the skb is queued, to avoid the skb to be used after free
and potentially the sk to drop its last refcount..
Fixes: 6e728f3213 ("net: qrtr: Add MHI transport layer")
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 801c6058d1 upstream.
The current implemented mechanisms to mitigate data disclosure under
speculation mainly address stack and map value oob access from the
speculative domain. However, Piotr discovered that uninitialized BPF
stack is not protected yet, and thus old data from the kernel stack,
potentially including addresses of kernel structures, could still be
extracted from that 512 bytes large window. The BPF stack is special
compared to map values since it's not zero initialized for every
program invocation, whereas map values /are/ zero initialized upon
their initial allocation and thus cannot leak any prior data in either
domain. In the non-speculative domain, the verifier ensures that every
stack slot read must have a prior stack slot write by the BPF program
to avoid such data leaking issue.
However, this is not enough: for example, when the pointer arithmetic
operation moves the stack pointer from the last valid stack offset to
the first valid offset, the sanitation logic allows for any intermediate
offsets during speculative execution, which could then be used to
extract any restricted stack content via side-channel.
Given for unprivileged stack pointer arithmetic the use of unknown
but bounded scalars is generally forbidden, we can simply turn the
register-based arithmetic operation into an immediate-based arithmetic
operation without the need for masking. This also gives the benefit
of reducing the needed instructions for the operation. Given after
the work in 7fedb63a83 ("bpf: Tighten speculative pointer arithmetic
mask"), the aux->alu_limit already holds the final immediate value for
the offset register with the known scalar. Thus, a simple mov of the
immediate to AX register with using AX as the source for the original
instruction is sufficient and possible now in this case.
Reported-by: Piotr Krysiuk <piotras@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Piotr Krysiuk <piotras@gmail.com>
Reviewed-by: Piotr Krysiuk <piotras@gmail.com>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b9b34ddbe2 upstream.
The negation logic for the case where the off_reg is sitting in the
dst register is not correct given then we cannot just invert the add
to a sub or vice versa. As a fix, perform the final bitwise and-op
unconditionally into AX from the off_reg, then move the pointer from
the src to dst and finally use AX as the source for the original
pointer arithmetic operation such that the inversion yields a correct
result. The single non-AX mov in between is possible given constant
blinding is retaining it as it's not an immediate based operation.
Fixes: 979d63d50c ("bpf: prevent out of bounds speculation on pointer arithmetic")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Piotr Krysiuk <piotras@gmail.com>
Reviewed-by: Piotr Krysiuk <piotras@gmail.com>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6e6026f2dd upstream.
The Intel I211 Ethernet Controller supports 2 Receive Side Scaling (RSS)
queues. It should not be excluded from having this feature enabled.
Via commit c883de9fd7 ("igb: rename igb define to be more generic")
E1000_MRQC_ENABLE_RSS_4Q was renamed to E1000_MRQC_ENABLE_RSS_MQ to
indicate that this is a generic bit flag to enable queues and not
a flag that is specific to devices that support 4 queues
The bit flag enables 2, 4 or 8 queues appropriately depending on the part.
Tested with a multicore CPU and frames were then distributed as expected.
This issue appears to have been introduced because of confusion caused
by the prior name.
Signed-off-by: Nick Lowe <nick.lowe@gmail.com>
Tested-by: David Switzer <david.switzer@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2671fa4dc0 upstream.
These sysctls point to global variables:
- NF_SYSCTL_CT_MAX (&nf_conntrack_max)
- NF_SYSCTL_CT_EXPECT_MAX (&nf_ct_expect_max)
- NF_SYSCTL_CT_BUCKETS (&nf_conntrack_htable_size_user)
Because their data pointers are not updated to point to per-netns
structures, they must be marked read-only in a non-init_net ns.
Otherwise, changes in any net namespace are reflected in (leaked into)
all other net namespaces. This problem has existed since the
introduction of net namespaces.
The current logic marks them read-only only if the net namespace is
owned by an unprivileged user (other than init_user_ns).
Commit d0febd81ae ("netfilter: conntrack: re-visit sysctls in
unprivileged namespaces") "exposes all sysctls even if the namespace is
unpriviliged." Since we need to mark them readonly in any case, we can
forego the unprivileged user check altogether.
Fixes: d0febd81ae ("netfilter: conntrack: re-visit sysctls in unprivileged namespaces")
Signed-off-by: Jonathon Reinhart <Jonathon.Reinhart@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1d7ba0165d upstream.
From [1]
"GCC 10 (PR 91233) won't silently allow registers that are not
architecturally available to be present in the clobber list anymore,
resulting in build failure for mips*r6 targets in form of:
...
.../sysdep.h:146:2: error: the register ‘lo’ cannot be clobbered in ‘asm’ for the current target
146 | __asm__ volatile ( \
| ^~~~~~~
This is because base R6 ISA doesn't define hi and lo registers w/o DSP
extension. This patch provides the alternative clobber list for r6 targets
that won't include those registers."
Since kernel 5.4 and mips support for generic vDSO [2], the kernel fail to
build for mips r6 cpus with gcc 10 for the same reason as glibc.
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=020b2a97bb15f807c0482f0faee2184ed05bcad8
[2] '24640f233b46 ("mips: Add support for generic vDSO")'
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We already applied the 'vendor hook' for Dtask Debugging Information
in below issue.
(https://issuetracker.google.com/issues/162776704)
There are vendor hook call in mutex and rw_semaphore, but not for rt_mutex
Please refer to description in details as below,
1. Description
This feature writes rt mutex lock waiting information
on the task_struct structure. We can check mutex information and
mutex owner through the kernel log and custom analysis tools.
Like the previous feature in mutex and rw semaphore,
added data can be checked by ramdump analysis.
2. Vendor Hook Position
1) VENDOR_DATA
- struct task_struct in sched.h
VENDOR_DATA_ARRAY(2)
[0] : type // RTmutex (Mutex, Rwsem, ...)
[1] : pointer // address of lock
2) VENDOR_HOOKs
- __rt_mutex_slowlock() in kernel/locking/rtmutex.c
3. Example
- SysRq-w in kernel log
...
[ 54.164463] [3: kworker/u16:3: 253] kworker/3:2 D12736 418 2 0x00000228
[ 54.164497] [3: kworker/u16:3: 253] RTmutex: 0xffffffc051fa3ae8: owner[sh :9003]
[ 54.167812] [3: kworker/u16:3: 253] sh D12848 9003 6900 0x04000200
[ 54.167824] [3: kworker/u16:3: 253] RTmutex: 0xffffffc051fa3b08: owner[kworker/3:2 :418]
...
Bug: 186567468
Signed-off-by: JINHO LIM <jordan.lim@samsung.com>
Change-Id: I93f9753be0b2c1fa1a6eaea09379d54c31d1ebcf
(cherry picked from commit e289faa9f1)
