-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update 5.15.x+fslc up to v5.15.63 #598
Commits on Aug 22, 2022
-
Merge tag 'v5.15.57' into 5.15.x+fslc
This is the 5.15.57 stable release Signed-off-by: Andrey Zhizhikin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 1ebe04d - Browse repository at this point
Copy the full SHA 1ebe04dView commit details -
Merge tag 'v5.15.58' into 5.15.x+fslc
This is the 5.15.58 stable release Signed-off-by: Andrey Zhizhikin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 4eb5770 - Browse repository at this point
Copy the full SHA 4eb5770View commit details -
Merge tag 'v5.15.59' into 5.15.x+fslc
This is the 5.15.59 stable release Signed-off-by: Andrey Zhizhikin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 4018da5 - Browse repository at this point
Copy the full SHA 4018da5View commit details -
Merge tag 'v5.15.60' into 5.15.x+fslc
This is the 5.15.60 stable release Signed-off-by: Andrey Zhizhikin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for a97aa82 - Browse repository at this point
Copy the full SHA a97aa82View commit details -
Merge tag 'v5.15.61' into 5.15.x+fslc
This is the 5.15.61 stable release Signed-off-by: Andrey Zhizhikin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 1568ef4 - Browse repository at this point
Copy the full SHA 1568ef4View commit details -
Merge tag 'v5.15.62' into 5.15.x+fslc
This is the 5.15.62 stable release Signed-off-by: Andrey Zhizhikin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for b5f19e6 - Browse repository at this point
Copy the full SHA b5f19e6View commit details
Commits on Aug 25, 2022
-
ALSA: info: Fix llseek return value when using callback
commit 9be080e upstream. When using callback there was a flow of ret = -EINVAL if (callback) { offset = callback(); goto out; } ... offset = some other value in case of no callback; ret = offset; out: return ret; which causes the snd_info_entry_llseek() to return -EINVAL when there is callback handler. Fix this by setting "ret" directly to callback return value before jumping to "out". Fixes: 73029e0 ("ALSA: info - Implement common llseek for binary mode") Signed-off-by: Amadeusz Sławiński <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 5d396df - Browse repository at this point
Copy the full SHA 5d396dfView commit details -
ALSA: hda/realtek: Add quirk for Clevo NS50PU, NS70PU
commit 90d74fd upstream. Fixes headset microphone detection on Clevo NS50PU and NS70PU. Signed-off-by: Christoffer Sandberg <[email protected]> Signed-off-by: Werner Sembach <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for e9a6a3b - Browse repository at this point
Copy the full SHA e9a6a3bView commit details -
KVM: Unconditionally get a ref to /dev/kvm module when creating a VM
commit 405294f upstream. Unconditionally get a reference to the /dev/kvm module when creating a VM instead of using try_get_module(), which will fail if the module is in the process of being forcefully unloaded. The error handling when try_get_module() fails doesn't properly unwind all that has been done, e.g. doesn't call kvm_arch_pre_destroy_vm() and doesn't remove the VM from the global list. Not removing VMs from the global list tends to be fatal, e.g. leads to use-after-free explosions. The obvious alternative would be to add proper unwinding, but the justification for using try_get_module(), "rmmod --wait", is completely bogus as support for "rmmod --wait", i.e. delete_module() without O_NONBLOCK, was removed by commit 3f2b9c9 ("module: remove rmmod --wait option.") nearly a decade ago. It's still possible for try_get_module() to fail due to the module dying (more like being killed), as the module will be tagged MODULE_STATE_GOING by "rmmod --force", i.e. delete_module(..., O_TRUNC), but playing nice with forced unloading is an exercise in futility and gives a falsea sense of security. Using try_get_module() only prevents acquiring _new_ references, it doesn't magically put the references held by other VMs, and forced unloading doesn't wait, i.e. "rmmod --force" on KVM is all but guaranteed to cause spectacular fireworks; the window where KVM will fail try_get_module() is tiny compared to the window where KVM is building and running the VM with an elevated module refcount. Addressing KVM's inability to play nice with "rmmod --force" is firmly out-of-scope. Forcefully unloading any module taints kernel (for obvious reasons) _and_ requires the kernel to be built with CONFIG_MODULE_FORCE_UNLOAD=y, which is off by default and comes with the amusing disclaimer that it's "mainly for kernel developers and desperate users". In other words, KVM is free to scoff at bug reports due to using "rmmod --force" while VMs may be running. Fixes: 5f6de5c ("KVM: Prevent module exit until all VMs are freed") Cc: [email protected] Cc: David Matlack <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 177bf35 - Browse repository at this point
Copy the full SHA 177bf35View commit details -
x86/mm: Use proper mask when setting PUD mapping
commit 88e0a74 upstream. Commit c164fbb("x86/mm: thread pgprot_t through init_memory_mapping()") mistakenly used __pgprot() which doesn't respect __default_kernel_pte_mask when setting PUD mapping. Fix it by only setting the one bit we actually need (PSE) and leaving the other bits (that have been properly masked) alone. Fixes: c164fbb ("x86/mm: thread pgprot_t through init_memory_mapping()") Signed-off-by: Aaron Lu <[email protected]> Cc: [email protected] Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for d26beb9 - Browse repository at this point
Copy the full SHA d26beb9View commit details -
rds: add missing barrier to release_refill
commit 9f414eb upstream. The functions clear_bit and set_bit do not imply a memory barrier, thus it may be possible that the waitqueue_active function (which does not take any locks) is moved before clear_bit and it could miss a wakeup event. Fix this bug by adding a memory barrier after clear_bit. Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 852f6a7 - Browse repository at this point
Copy the full SHA 852f6a7View commit details -
locking/atomic: Make test_and_*_bit() ordered on failure
commit 415d832 upstream. These operations are documented as always ordered in include/asm-generic/bitops/instrumented-atomic.h, and producer-consumer type use cases where one side needs to ensure a flag is left pending after some shared data was updated rely on this ordering, even in the failure case. This is the case with the workqueue code, which currently suffers from a reproducible ordering violation on Apple M1 platforms (which are notoriously out-of-order) that ends up causing the TTY layer to fail to deliver data to userspace properly under the right conditions. This change fixes that bug. Change the documentation to restrict the "no order on failure" story to the _lock() variant (for which it makes sense), and remove the early-exit from the generic implementation, which is what causes the missing barrier semantics in that case. Without this, the remaining atomic op is fully ordered (including on ARM64 LSE, as of recent versions of the architecture spec). Suggested-by: Linus Torvalds <[email protected]> Cc: [email protected] Fixes: e986a0d ("locking/atomics, asm-generic/bitops/atomic.h: Rewrite using atomic_*() APIs") Fixes: 61e0239 ("locking/atomic/bitops: Document and clarify ordering semantics for failed test_and_{}_bit()") Signed-off-by: Hector Martin <[email protected]> Acked-by: Will Deacon <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 1b7e048 - Browse repository at this point
Copy the full SHA 1b7e048View commit details -
commit c20ee57 upstream. Appears to be ok with general GA10x code. Signed-off-by: Karol Herbst <[email protected]> Cc: <[email protected]> # v5.15+ Reviewed-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 016b714 - Browse repository at this point
Copy the full SHA 016b714View commit details -
drm/ttm: Fix dummy res NULL ptr deref bug
commit cf4b738 upstream. Check the bo->resource value before accessing the resource mem_type. v2: Fix commit description unwrapped warning <log snip> [ 40.191227][ T184] general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [Freescale#1] SMP KASAN PTI [ 40.192995][ T184] KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] [ 40.194411][ T184] CPU: 1 PID: 184 Comm: systemd-udevd Not tainted 5.19.0-rc4-00721-gb297c22b7070 Freescale#1 [ 40.196063][ T184] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014 [ 40.199605][ T184] RIP: 0010:ttm_bo_validate+0x1b3/0x240 [ttm] [ 40.200754][ T184] Code: e8 72 c5 ff ff 83 f8 b8 74 d4 85 c0 75 54 49 8b 9e 58 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 10 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 04 3c 03 7e 44 8b 53 10 31 c0 85 d2 0f 85 58 [ 40.203685][ T184] RSP: 0018:ffffc900006df0c8 EFLAGS: 00010202 [ 40.204630][ T184] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 1ffff1102f4bb71b [ 40.205864][ T184] RDX: 0000000000000002 RSI: ffffc900006df208 RDI: 0000000000000010 [ 40.207102][ T184] RBP: 1ffff920000dbe1a R08: ffffc900006df208 R09: 0000000000000000 [ 40.208394][ T184] R10: ffff88817a5f0000 R11: 0000000000000001 R12: ffffc900006df110 [ 40.209692][ T184] R13: ffffc900006df0f0 R14: ffff88817a5db800 R15: ffffc900006df208 [ 40.210862][ T184] FS: 00007f6b1d16e8c0(0000) GS:ffff88839d700000(0000) knlGS:0000000000000000 [ 40.212250][ T184] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 40.213275][ T184] CR2: 000055a1001d4ff0 CR3: 00000001700f4000 CR4: 00000000000006e0 [ 40.214469][ T184] Call Trace: [ 40.214974][ T184] <TASK> [ 40.215438][ T184] ? ttm_bo_bounce_temp_buffer+0x140/0x140 [ttm] [ 40.216572][ T184] ? mutex_spin_on_owner+0x240/0x240 [ 40.217456][ T184] ? drm_vma_offset_add+0xaa/0x100 [drm] [ 40.218457][ T184] ttm_bo_init_reserved+0x3d6/0x540 [ttm] [ 40.219410][ T184] ? shmem_get_inode+0x744/0x980 [ 40.220231][ T184] ttm_bo_init_validate+0xb1/0x200 [ttm] [ 40.221172][ T184] ? bo_driver_evict_flags+0x340/0x340 [drm_vram_helper] [ 40.222530][ T184] ? ttm_bo_init_reserved+0x540/0x540 [ttm] [ 40.223643][ T184] ? __do_sys_finit_module+0x11a/0x1c0 [ 40.224654][ T184] ? __shmem_file_setup+0x102/0x280 [ 40.234764][ T184] drm_gem_vram_create+0x305/0x480 [drm_vram_helper] [ 40.235766][ T184] ? bo_driver_evict_flags+0x340/0x340 [drm_vram_helper] [ 40.236846][ T184] ? __kasan_slab_free+0x108/0x180 [ 40.237650][ T184] drm_gem_vram_fill_create_dumb+0x134/0x340 [drm_vram_helper] [ 40.238864][ T184] ? local_pci_probe+0xdf/0x180 [ 40.239674][ T184] ? drmm_vram_helper_init+0x400/0x400 [drm_vram_helper] [ 40.240826][ T184] drm_client_framebuffer_create+0x19c/0x400 [drm] [ 40.241955][ T184] ? drm_client_buffer_delete+0x200/0x200 [drm] [ 40.243001][ T184] ? drm_client_pick_crtcs+0x554/0xb80 [drm] [ 40.244030][ T184] drm_fb_helper_generic_probe+0x23f/0x940 [drm_kms_helper] [ 40.245226][ T184] ? __cond_resched+0x1c/0xc0 [ 40.245987][ T184] ? drm_fb_helper_memory_range_to_clip+0x180/0x180 [drm_kms_helper] [ 40.247316][ T184] ? mutex_unlock+0x80/0x100 [ 40.248005][ T184] ? __mutex_unlock_slowpath+0x2c0/0x2c0 [ 40.249083][ T184] drm_fb_helper_single_fb_probe+0x907/0xf00 [drm_kms_helper] [ 40.250314][ T184] ? drm_fb_helper_check_var+0x1180/0x1180 [drm_kms_helper] [ 40.251540][ T184] ? __cond_resched+0x1c/0xc0 [ 40.252321][ T184] ? mutex_lock+0x9f/0x100 [ 40.253062][ T184] __drm_fb_helper_initial_config_and_unlock+0xb9/0x2c0 [drm_kms_helper] [ 40.254394][ T184] drm_fbdev_client_hotplug+0x56f/0x840 [drm_kms_helper] [ 40.255477][ T184] drm_fbdev_generic_setup+0x165/0x3c0 [drm_kms_helper] [ 40.256607][ T184] bochs_pci_probe+0x6b7/0x900 [bochs] [ 40.257515][ T184] ? _raw_spin_lock_irqsave+0x87/0x100 [ 40.258312][ T184] ? bochs_hw_init+0x480/0x480 [bochs] [ 40.259244][ T184] ? bochs_hw_init+0x480/0x480 [bochs] [ 40.260186][ T184] local_pci_probe+0xdf/0x180 [ 40.260928][ T184] pci_call_probe+0x15f/0x500 [ 40.265798][ T184] ? _raw_spin_lock+0x81/0x100 [ 40.266508][ T184] ? pci_pm_suspend_noirq+0x980/0x980 [ 40.267322][ T184] ? pci_assign_irq+0x81/0x280 [ 40.268096][ T184] ? pci_match_device+0x351/0x6c0 [ 40.268883][ T184] ? kernfs_put+0x18/0x40 [ 40.269611][ T184] pci_device_probe+0xee/0x240 [ 40.270352][ T184] really_probe+0x435/0xa80 [ 40.271021][ T184] __driver_probe_device+0x2ab/0x480 [ 40.271828][ T184] driver_probe_device+0x49/0x140 [ 40.272627][ T184] __driver_attach+0x1bd/0x4c0 [ 40.273372][ T184] ? __device_attach_driver+0x240/0x240 [ 40.274273][ T184] bus_for_each_dev+0x11e/0x1c0 [ 40.275080][ T184] ? subsys_dev_iter_exit+0x40/0x40 [ 40.275951][ T184] ? klist_add_tail+0x132/0x280 [ 40.276767][ T184] bus_add_driver+0x39b/0x580 [ 40.277574][ T184] driver_register+0x20f/0x3c0 [ 40.278281][ T184] ? 0xffffffffc04a2000 [ 40.278894][ T184] do_one_initcall+0x8a/0x300 [ 40.279642][ T184] ? trace_event_raw_event_initcall_level+0x1c0/0x1c0 [ 40.280707][ T184] ? kasan_unpoison+0x23/0x80 [ 40.281479][ T184] ? kasan_unpoison+0x23/0x80 [ 40.282197][ T184] do_init_module+0x190/0x640 [ 40.282926][ T184] load_module+0x221b/0x2780 [ 40.283611][ T184] ? layout_and_allocate+0x5c0/0x5c0 [ 40.284401][ T184] ? kernel_read_file+0x286/0x6c0 [ 40.285216][ T184] ? __x64_sys_fspick+0x2c0/0x2c0 [ 40.286043][ T184] ? mmap_region+0x4e7/0x1300 [ 40.286832][ T184] ? __do_sys_finit_module+0x11a/0x1c0 [ 40.287743][ T184] __do_sys_finit_module+0x11a/0x1c0 [ 40.288636][ T184] ? __ia32_sys_init_module+0xc0/0xc0 [ 40.289557][ T184] ? __seccomp_filter+0x15e/0xc80 [ 40.290341][ T184] ? vm_mmap_pgoff+0x185/0x240 [ 40.291060][ T184] do_syscall_64+0x3b/0xc0 [ 40.291763][ T184] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 40.292678][ T184] RIP: 0033:0x7f6b1d6279b9 [ 40.293438][ T184] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a7 54 0c 00 f7 d8 64 89 01 48 [ 40.296302][ T184] RSP: 002b:00007ffe7f51b798 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 40.297633][ T184] RAX: ffffffffffffffda RBX: 00005642dcca2880 RCX: 00007f6b1d6279b9 [ 40.298890][ T184] RDX: 0000000000000000 RSI: 00007f6b1d7b2e2d RDI: 0000000000000016 [ 40.300199][ T184] RBP: 0000000000020000 R08: 0000000000000000 R09: 00005642dccd5530 [ 40.301547][ T184] R10: 0000000000000016 R11: 0000000000000246 R12: 00007f6b1d7b2e2d [ 40.302698][ T184] R13: 0000000000000000 R14: 00005642dcca4230 R15: 00005642dcca2880 Signed-off-by: Arunpravin Paneer Selvam <[email protected]> Reported-by: kernel test robot <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Christian König <[email protected]> CC: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 76672cd - Browse repository at this point
Copy the full SHA 76672cdView commit details -
drm/amd/display: Check correct bounds for stream encoder instances fo…
…r DCN303 commit 89b0082 upstream. [Why & How] eng_id for DCN303 cannot be more than 1, since we have only two instances of stream encoders. Check the correct boundary condition for engine ID for DCN303 prevent the potential out of bounds access. Fixes: cd6d421 ("drm/amd/display: Initial DC support for Beige Goby") Reported-by: Dan Carpenter <[email protected]> Cc: [email protected] Reviewed-by: Chris Park <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Acked-by: Tom Chung <[email protected]> Signed-off-by: Aurabindo Pillai <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 82a27c1 - Browse repository at this point
Copy the full SHA 82a27c1View commit details -
ata: libata-eh: Add missing command name
commit d3122bf upstream. Add the missing command name for ATA_CMD_NCQ_NON_DATA to ata_get_cmd_name(). Fixes: 661ce1f ("libata/libsas: Define ATA_CMD_NCQ_NON_DATA") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 23179d5 - Browse repository at this point
Copy the full SHA 23179d5View commit details -
mmc: pxamci: Fix another error handling path in pxamci_probe()
commit b886f54 upstream. The commit in Fixes: has introduced an new error handling without branching to the existing error handling path. Update it now and release some resources if pxamci_init_ocr() fails. Fixes: 61951fd ("mmc: pxamci: let mmc core handle regulators") Signed-off-by: Christophe JAILLET <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/07a2dcebf8ede69b484103de8f9df043f158cffd.1658862932.git.christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 8b7ed38 - Browse repository at this point
Copy the full SHA 8b7ed38View commit details -
mmc: pxamci: Fix an error handling path in pxamci_probe()
commit 98d7c5e upstream. The commit in Fixes: has moved some code around without updating gotos to the error handling path. Update it now and release some resources if pxamci_of_init() fails. Fixes: fa3a511 ("mmc: pxamci: call mmc_of_parse()") Signed-off-by: Christophe JAILLET <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/6d75855ad4e2470e9ed99e0df21bc30f0c925a29.1658862932.git.christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 6c4541d - Browse repository at this point
Copy the full SHA 6c4541dView commit details -
mmc: meson-gx: Fix an error handling path in meson_mmc_probe()
commit b3e1cf3 upstream. The commit in Fixes has introduced a new error handling which should goto the existing error handling path. Otherwise some resources leak. Fixes: 19c6bea ("mmc: meson-gx: add device reset") Signed-off-by: Christophe JAILLET <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/be4b863bacf323521ba3a02efdc4fca9cdedd1a6.1659855351.git.christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for d8fc9df - Browse repository at this point
Copy the full SHA d8fc9dfView commit details -
btrfs: unset reloc control if transaction commit fails in prepare_to_…
…relocate() commit 85f02d6 upstream. In btrfs_relocate_block_group(), the rc is allocated. Then btrfs_relocate_block_group() calls relocate_block_group() prepare_to_relocate() set_reloc_control() that assigns rc to the variable fs_info->reloc_ctl. When prepare_to_relocate() returns, it calls btrfs_commit_transaction() btrfs_start_dirty_block_groups() btrfs_alloc_path() kmem_cache_zalloc() which may fail for example (or other errors could happen). When the failure occurs, btrfs_relocate_block_group() detects the error and frees rc and doesn't set fs_info->reloc_ctl to NULL. After that, in btrfs_init_reloc_root(), rc is retrieved from fs_info->reloc_ctl and then used, which may cause a use-after-free bug. This possible bug can be triggered by calling btrfs_ioctl_balance() before calling btrfs_ioctl_defrag(). To fix this possible bug, in prepare_to_relocate(), check if btrfs_commit_transaction() fails. If the failure occurs, unset_reloc_control() is called to set fs_info->reloc_ctl to NULL. The error log in our fault-injection testing is shown as follows: [ 58.751070] BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x7ca/0x920 [btrfs] ... [ 58.753577] Call Trace: ... [ 58.755800] kasan_report+0x45/0x60 [ 58.756066] btrfs_init_reloc_root+0x7ca/0x920 [btrfs] [ 58.757304] record_root_in_trans+0x792/0xa10 [btrfs] [ 58.757748] btrfs_record_root_in_trans+0x463/0x4f0 [btrfs] [ 58.758231] start_transaction+0x896/0x2950 [btrfs] [ 58.758661] btrfs_defrag_root+0x250/0xc00 [btrfs] [ 58.759083] btrfs_ioctl_defrag+0x467/0xa00 [btrfs] [ 58.759513] btrfs_ioctl+0x3c95/0x114e0 [btrfs] ... [ 58.768510] Allocated by task 23683: [ 58.768777] ____kasan_kmalloc+0xb5/0xf0 [ 58.769069] __kmalloc+0x227/0x3d0 [ 58.769325] alloc_reloc_control+0x10a/0x3d0 [btrfs] [ 58.769755] btrfs_relocate_block_group+0x7aa/0x1e20 [btrfs] [ 58.770228] btrfs_relocate_chunk+0xf1/0x760 [btrfs] [ 58.770655] __btrfs_balance+0x1326/0x1f10 [btrfs] [ 58.771071] btrfs_balance+0x3150/0x3d30 [btrfs] [ 58.771472] btrfs_ioctl_balance+0xd84/0x1410 [btrfs] [ 58.771902] btrfs_ioctl+0x4caa/0x114e0 [btrfs] ... [ 58.773337] Freed by task 23683: ... [ 58.774815] kfree+0xda/0x2b0 [ 58.775038] free_reloc_control+0x1d6/0x220 [btrfs] [ 58.775465] btrfs_relocate_block_group+0x115c/0x1e20 [btrfs] [ 58.775944] btrfs_relocate_chunk+0xf1/0x760 [btrfs] [ 58.776369] __btrfs_balance+0x1326/0x1f10 [btrfs] [ 58.776784] btrfs_balance+0x3150/0x3d30 [btrfs] [ 58.777185] btrfs_ioctl_balance+0xd84/0x1410 [btrfs] [ 58.777621] btrfs_ioctl+0x4caa/0x114e0 [btrfs] ... Reported-by: TOTE Robot <[email protected]> CC: [email protected] # 5.15+ Reviewed-by: Sweet Tea Dorminy <[email protected]> Reviewed-by: Nikolay Borisov <[email protected]> Signed-off-by: Zixuan Fu <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 78f8c23 - Browse repository at this point
Copy the full SHA 78f8c23View commit details -
btrfs: reset RO counter on block group if we fail to relocate
commit 74944c8 upstream. With the automatic block group reclaim code we will preemptively try to mark the block group RO before we start the relocation. We do this to make sure we should actually try to relocate the block group. However if we hit an error during the actual relocation we won't clean up our RO counter and the block group will remain RO. This was observed internally with file systems reporting less space available from df when we had failed background relocations. Fix this by doing the dec_ro in the error case. Fixes: 18bb8bb ("btrfs: zoned: automatically reclaim zones") CC: [email protected] # 5.15+ Reviewed-by: Boris Burkov <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 7ac430e - Browse repository at this point
Copy the full SHA 7ac430eView commit details -
btrfs: fix lost error handling when looking up extended ref on log re…
…play commit 7a6b75b upstream. During log replay, when processing inode references, if we get an error when looking up for an extended reference at __add_inode_ref(), we ignore it and proceed, returning success (0) if no other error happens after the lookup. This is obviously wrong because in case an extended reference exists and it encodes some name not in the log, we need to unlink it, otherwise the filesystem state will not match the state it had after the last fsync. So just make __add_inode_ref() return an error it gets from the extended reference lookup. Fixes: f186373 ("btrfs: extended inode refs") CC: [email protected] # 4.9+ Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 6379a9a - Browse repository at this point
Copy the full SHA 6379a9aView commit details -
cifs: Fix memory leak on the deferred close
commit ca08d0e upstream. xfstests on smb21 report kmemleak as below: unreferenced object 0xffff8881767d6200 (size 64): comm "xfs_io", pid 1284, jiffies 4294777434 (age 20.789s) hex dump (first 32 bytes): 80 5a d0 11 81 88 ff ff 78 8a aa 63 81 88 ff ff .Z......x..c.... 00 71 99 76 81 88 ff ff 00 00 00 00 00 00 00 00 .q.v............ backtrace: [<00000000ad04e6ea>] cifs_close+0x92/0x2c0 [<0000000028b93c82>] __fput+0xff/0x3f0 [<00000000d8116851>] task_work_run+0x85/0xc0 [<0000000027e14f9e>] do_exit+0x5e5/0x1240 [<00000000fb492b95>] do_group_exit+0x58/0xe0 [<00000000129a32d9>] __x64_sys_exit_group+0x28/0x30 [<00000000e3f7d8e9>] do_syscall_64+0x35/0x80 [<00000000102e8a0b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 When cancel the deferred close work, we should also cleanup the struct cifs_deferred_close. Fixes: 9e99275 ("cifs: Call close synchronously during unlink/rename/lease break.") Fixes: e3fc065 ("cifs: Deferred close performance improvements") Cc: [email protected] Reviewed-by: Shyam Prasad N <[email protected]> Signed-off-by: Zhang Xiaoxu <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 860efae - Browse repository at this point
Copy the full SHA 860efaeView commit details -
x86/kprobes: Fix JNG/JNLE emulation
commit 8924779 upstream. When kprobes emulates JNG/JNLE instructions on x86 it uses the wrong condition. For JNG (opcode: 0F 8E), according to Intel SDM, the jump is performed if (ZF == 1 or SF != OF). However the kernel emulation currently uses 'and' instead of 'or'. As a result, setting a kprobe on JNG/JNLE might cause the kernel to behave incorrectly whenever the kprobe is hit. Fix by changing the 'and' to 'or'. Fixes: 6256e66 ("x86/kprobes: Use int3 instead of debug trap for single-step") Signed-off-by: Nadav Amit <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 14674e4 - Browse repository at this point
Copy the full SHA 14674e4View commit details -
tracing/perf: Fix double put of trace event when init fails
commit 7249921 upstream. If in perf_trace_event_init(), the perf_trace_event_open() fails, then it will call perf_trace_event_unreg() which will not only unregister the perf trace event, but will also call the put() function of the tp_event. The problem here is that the trace_event_try_get_ref() is called by the caller of perf_trace_event_init() and if perf_trace_event_init() returns a failure, it will then call trace_event_put(). But since the perf_trace_event_unreg() already called the trace_event_put() function, it triggers a WARN_ON(). WARNING: CPU: 1 PID: 30309 at kernel/trace/trace_dynevent.c:46 trace_event_dyn_put_ref+0x15/0x20 If perf_trace_event_reg() does not call the trace_event_try_get_ref() then the perf_trace_event_unreg() should not be calling trace_event_put(). This breaks symmetry and causes bugs like these. Pull out the trace_event_put() from perf_trace_event_unreg() and call it in the locations that perf_trace_event_unreg() is called. This not only fixes this bug, but also brings back the proper symmetry of the reg/unreg vs get/put logic. Link: https://lore.kernel.org/all/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Cc: [email protected] Fixes: 1d18538 ("tracing: Have dynamic events have a ref counter") Reported-by: Krister Johansen <[email protected]> Reviewed-by: Krister Johansen <[email protected]> Tested-by: Krister Johansen <[email protected]> Acked-by: Jiri Olsa <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 0d7970e - Browse repository at this point
Copy the full SHA 0d7970eView commit details -
tracing/eprobes: Do not allow eprobes to use $stack, or % for regs
commit 2673c60 upstream. While playing with event probes (eprobes), I tried to see what would happen if I attempted to retrieve the instruction pointer (%rip) knowing that event probes do not use pt_regs. The result was: BUG: kernel NULL pointer dereference, address: 0000000000000024 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [Freescale#1] PREEMPT SMP PTI CPU: 1 PID: 1847 Comm: trace-cmd Not tainted 5.19.0-rc5-test+ Freescale#309 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:get_event_field.isra.0+0x0/0x50 Code: ff 48 c7 c7 c0 8f 74 a1 e8 3d 8b f5 ff e8 88 09 f6 ff 4c 89 e7 e8 50 6a 13 00 48 89 ef 5b 5d 41 5c 41 5d e9 42 6a 13 00 66 90 <48> 63 47 24 8b 57 2c 48 01 c6 8b 47 28 83 f8 02 74 0e 83 f8 04 74 RSP: 0018:ffff916c394bbaf0 EFLAGS: 00010086 RAX: ffff916c854041d8 RBX: ffff916c8d9fbf50 RCX: ffff916c255d2000 RDX: 0000000000000000 RSI: ffff916c255d2008 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff916c3a2a0c08 R09: ffff916c394bbda8 R10: 0000000000000000 R11: 0000000000000000 R12: ffff916c854041d8 R13: ffff916c854041b0 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff916c9ea40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000024 CR3: 000000011b60a002 CR4: 00000000001706e0 Call Trace: <TASK> get_eprobe_size+0xb4/0x640 ? __mod_node_page_state+0x72/0xc0 __eprobe_trace_func+0x59/0x1a0 ? __mod_lruvec_page_state+0xaa/0x1b0 ? page_remove_file_rmap+0x14/0x230 ? page_remove_rmap+0xda/0x170 event_triggers_call+0x52/0xe0 trace_event_buffer_commit+0x18f/0x240 trace_event_raw_event_sched_wakeup_template+0x7a/0xb0 try_to_wake_up+0x260/0x4c0 __wake_up_common+0x80/0x180 __wake_up_common_lock+0x7c/0xc0 do_notify_parent+0x1c9/0x2a0 exit_notify+0x1a9/0x220 do_exit+0x2ba/0x450 do_group_exit+0x2d/0x90 __x64_sys_exit_group+0x14/0x20 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Obviously this is not the desired result. Move the testing for TPARG_FL_TPOINT which is only used for event probes to the top of the "$" variable check, as all the other variables are not used for event probes. Also add a check in the register parsing "%" to fail if an event probe is used. Link: https://lkml.kernel.org/r/[email protected] Cc: [email protected] Cc: Ingo Molnar <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Tzvetomir Stoyanov <[email protected]> Cc: Tom Zanussi <[email protected]> Fixes: 7491e2c ("tracing: Add a probe that attaches to trace events") Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for ba53c21 - Browse repository at this point
Copy the full SHA ba53c21View commit details -
tracing/eprobes: Do not hardcode $comm as a string
commit 02333de upstream. The variable $comm is hard coded as a string, which is true for both kprobes and uprobes, but for event probes (eprobes) it is a field name. In most cases the "comm" field would be a string, but there's no guarantee of that fact. Do not assume that comm is a string. Not to mention, it currently forces comm fields to fault, as string processing for event probes is currently broken. Link: https://lkml.kernel.org/r/[email protected] Cc: [email protected] Cc: Ingo Molnar <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: Tzvetomir Stoyanov <[email protected]> Cc: Tom Zanussi <[email protected]> Fixes: 7491e2c ("tracing: Add a probe that attaches to trace events") Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for a11ce7b - Browse repository at this point
Copy the full SHA a11ce7bView commit details -
tracing/eprobes: Have event probes be consistent with kprobes and upr…
…obes commit 6a832ec upstream. Currently, if a symbol "@" is attempted to be used with an event probe (eprobes), it will cause a NULL pointer dereference crash. Both kprobes and uprobes can reference data other than the main registers. Such as immediate address, symbols and the current task name. Have eprobes do the same thing. For "comm", if "comm" is used and the event being attached to does not have the "comm" field, then make it the "$comm" that kprobes has. This is consistent to the way histograms and filters work. Link: https://lkml.kernel.org/r/[email protected] Cc: [email protected] Cc: Ingo Molnar <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: Tzvetomir Stoyanov <[email protected]> Cc: Tom Zanussi <[email protected]> Fixes: 7491e2c ("tracing: Add a probe that attaches to trace events") Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for b489aca - Browse repository at this point
Copy the full SHA b489acaView commit details -
tracing/probes: Have kprobes and uprobes use $COMM too
commit ab83844 upstream. Both $comm and $COMM can be used to get current->comm in eprobes and the filtering and histogram logic. Make kprobes and uprobes consistent in this regard and allow both $comm and $COMM as well. Currently kprobes and uprobes only handle $comm, which is inconsistent with the other utilities, and can be confusing to users. Link: https://lkml.kernel.org/r/[email protected] Link: https://lore.kernel.org/all/[email protected]/ Cc: [email protected] Cc: Ingo Molnar <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Tzvetomir Stoyanov <[email protected]> Cc: Tom Zanussi <[email protected]> Fixes: 5330592 ("tracing: probeevent: Introduce new argument fetching code") Suggested-by: Masami Hiramatsu (Google) <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for dac2b60 - Browse repository at this point
Copy the full SHA dac2b60View commit details -
tracing: Have filter accept "common_cpu" to be consistent
commit b238057 upstream. Make filtering consistent with histograms. As "cpu" can be a field of an event, allow for "common_cpu" to keep it from being confused with the "cpu" field of the event. Link: https://lkml.kernel.org/r/[email protected] Link: https://lore.kernel.org/all/[email protected]/ Cc: [email protected] Cc: Ingo Molnar <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Tzvetomir Stoyanov <[email protected]> Cc: Tom Zanussi <[email protected]> Fixes: 1e3bac7 ("tracing/histogram: Rename "cpu" to "common_cpu"") Suggested-by: Masami Hiramatsu (Google) <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 2fb8f62 - Browse repository at this point
Copy the full SHA 2fb8f62View commit details -
ALSA: usb-audio: More comprehensive mixer map for ASUS ROG Zenith II
commit 6bc2906 upstream. ASUS ROG Zenith II has two USB interfaces, one for the front headphone and another for the rest I/O. Currently we provided the mixer mapping for the latter but with an incomplete form. This patch corrects and provides more comprehensive mixer mapping, as well as providing the proper device names for both the front headphone and main audio. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211005 Fixes: 2a48218 ("ALSA: usb-audio: Add mixer workaround for TRX40 and co") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 2294f43 - Browse repository at this point
Copy the full SHA 2294f43View commit details -
dt-bindings: usb: mtk-xhci: Allow wakeup interrupt-names to be optional
commit b2c510f upstream. Add missing "minItems: 1" to the interrupt-names property to allow the second interrupt-names, "wakeup", to be optional. Fixes: fe8e488 ("dt-bindings: usb: mtk-xhci: add wakeup interrupt") Signed-off-by: Nícolas F. R. A. Prado <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Acked-by: Chunfeng Yun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 43ae966 - Browse repository at this point
Copy the full SHA 43ae966View commit details -
can: ems_usb: fix clang's -Wunaligned-access warning
commit a4cb6e6 upstream. clang emits a -Wunaligned-access warning on struct __packed ems_cpc_msg. The reason is that the anonymous union msg (not declared as packed) is being packed right after some non naturally aligned variables (3*8 bits + 2*32) inside a packed struct: | struct __packed ems_cpc_msg { | u8 type; /* type of message */ | u8 length; /* length of data within union 'msg' */ | u8 msgid; /* confirmation handle */ | __le32 ts_sec; /* timestamp in seconds */ | __le32 ts_nsec; /* timestamp in nano seconds */ | /* ^ not naturally aligned */ | | union { | /* ^ not declared as packed */ | u8 generic[64]; | struct cpc_can_msg can_msg; | struct cpc_can_params can_params; | struct cpc_confirm confirmation; | struct cpc_overrun overrun; | struct cpc_can_error error; | struct cpc_can_err_counter err_counter; | u8 can_state; | } msg; | }; Starting from LLVM 14, having an unpacked struct nested in a packed struct triggers a warning. c.f. [1]. Fix the warning by marking the anonymous union as packed. [1] llvm/llvm-project#55520 Fixes: 702171a ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface") Link: https://lore.kernel.org/all/[email protected] Cc: Gerhard Uttenthaler <[email protected]> Cc: Sebastian Haas <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 8bc5ed7 - Browse repository at this point
Copy the full SHA 8bc5ed7View commit details -
apparmor: fix quiet_denied for file rules
commit 68ff854 upstream. Global quieting of denied AppArmor generated file events is not handled correctly. Unfortunately the is checking if quieting of all audit events is set instead of just denied events. Fixes: 67012e8 ("AppArmor: basic auditing infrastructure.") Signed-off-by: John Johansen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 017b0ea - Browse repository at this point
Copy the full SHA 017b0eaView commit details -
apparmor: fix absroot causing audited secids to begin with =
commit 511f7b5 upstream. AppArmor is prefixing secids that are converted to secctx with the = to indicate the secctx should only be parsed from an absolute root POV. This allows catching errors where secctx are reparsed back into internal labels. Unfortunately because audit is using secid to secctx conversion this means that subject and object labels can result in a very unfortunate == that can break audit parsing. eg. the subj==unconfined term in the below audit message type=USER_LOGIN msg=audit(1639443365.233:160): pid=1633 uid=0 auid=1000 ses=3 subj==unconfined msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=192.168.122.1 addr=192.168.122.1 terminal=/dev/pts/1 res=success' Fix this by switch the prepending of = to a _. This still works as a special character to flag this case without breaking audit. Also move this check behind debug as it should not be needed during normal operqation. Fixes: 26b7899 ("apparmor: add support for absolute root view based labels") Reported-by: Casey Schaufler <[email protected]> Signed-off-by: John Johansen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 31b35b6 - Browse repository at this point
Copy the full SHA 31b35b6View commit details -
apparmor: Fix failed mount permission check error message
commit ec240b5 upstream. When the mount check fails due to a permission check failure instead of explicitly at one of the subcomponent checks, AppArmor is reporting a failure in the flags match. However this is not true and AppArmor can not attribute the error at this point to any particular component, and should only indicate the mount failed due to missing permissions. Fixes: 2ea3ffb ("apparmor: add mount mediation") Signed-off-by: John Johansen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for a683a0d - Browse repository at this point
Copy the full SHA a683a0dView commit details -
apparmor: fix aa_label_asxprint return check
commit 3e2a3a0 upstream. Clang static analysis reports this issue label.c:1802:3: warning: 2nd function call argument is an uninitialized value pr_info("%s", str); ^~~~~~~~~~~~~~~~~~ str is set from a successful call to aa_label_asxprint(&str, ...) On failure a negative value is returned, not a -1. So change the check. Fixes: f1bd904 ("apparmor: add the base fns() for domain labels") Signed-off-by: Tom Rix <[email protected]> Signed-off-by: John Johansen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 3104c8a - Browse repository at this point
Copy the full SHA 3104c8aView commit details -
apparmor: fix setting unconfined mode on a loaded profile
commit 3bbb7b2 upstream. When loading a profile that is set to unconfined mode, that label flag is not set when it should be. Ensure it is set so that when used in a label the unconfined check will be applied correctly. Fixes: 0381650 ("apparmor: allow setting any profile into the unconfined state") Signed-off-by: John Johansen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for e89b95f - Browse repository at this point
Copy the full SHA e89b95fView commit details -
apparmor: fix overlapping attachment computation
commit 2504db2 upstream. When finding the profile via patterned attachments, the longest left match is being set to the static compile time value and not using the runtime computed value. Fix this by setting the candidate value to the greater of the precomputed value or runtime computed value. Fixes: 21f6066 ("apparmor: improve overlapping domain attachment resolution") Signed-off-by: John Johansen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for c62f2f5 - Browse repository at this point
Copy the full SHA c62f2f5View commit details -
apparmor: fix reference count leak in aa_pivotroot()
commit 11c3627 upstream. The aa_pivotroot() function has a reference counting bug in a specific path. When aa_replace_current_label() returns on success, the function forgets to decrement the reference count of “target”, which is increased earlier by build_pivotroot(), causing a reference leak. Fix it by decreasing the refcount of “target” in that path. Fixes: 2ea3ffb ("apparmor: add mount mediation") Co-developed-by: Xiyu Yang <[email protected]> Signed-off-by: Xiyu Yang <[email protected]> Co-developed-by: Xin Tan <[email protected]> Signed-off-by: Xin Tan <[email protected]> Signed-off-by: Xin Xiong <[email protected]> Signed-off-by: John Johansen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 64103ea - Browse repository at this point
Copy the full SHA 64103eaView commit details -
apparmor: Fix memleak in aa_simple_write_to_buffer()
commit 417ea9f upstream. When copy_from_user failed, the memory is freed by kvfree. however the management struct and data blob are allocated independently, so only kvfree(data) cause a memleak issue here. Use aa_put_loaddata(data) to fix this issue. Fixes: a6a5257 ("apparmor: split load data into management struct and data blob") Signed-off-by: Xiu Jianfeng <[email protected]> Signed-off-by: John Johansen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for bf7ebeb - Browse repository at this point
Copy the full SHA bf7ebebView commit details -
Documentation: ACPI: EINJ: Fix obsolete example
commit 9066e15 upstream. Since commit 488dac0 ("libfs: fix error cast of negative value in simple_attr_write()"), the EINJ debugfs interface no longer accepts negative values as input. Attempt to do so will result in EINVAL. Fixes: 488dac0 ("libfs: fix error cast of negative value in simple_attr_write()") Signed-off-by: Qifu Zhang <[email protected]> Reviewed-by: Tony Luck <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 6aea903 - Browse repository at this point
Copy the full SHA 6aea903View commit details -
NFSv4.1: Don't decrease the value of seq_nr_highest_sent
commit f07a5d2 upstream. When we're trying to figure out what the server may or may not have seen in terms of request numbers, do not assume that requests with a larger number were missed, just because we saw a reply to a request with a smaller number. Fixes: 3453d57 ("NFSv4.1: Avoid false retries when RPC calls are interrupted") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 0696115 - Browse repository at this point
Copy the full SHA 0696115View commit details -
NFSv4.1: Handle NFS4ERR_DELAY replies to OP_SEQUENCE correctly
commit 7ccafd4 upstream. Don't assume that the NFS4ERR_DELAY means that the server is processing this slot id. Fixes: 3453d57 ("NFSv4.1: Avoid false retries when RPC calls are interrupted") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for b32780c - Browse repository at this point
Copy the full SHA b32780cView commit details -
NFSv4: Fix races in the legacy idmapper upcall
commit 51fd2eb upstream. nfs_idmap_instantiate() will cause the process that is waiting in request_key_with_auxdata() to wake up and exit. If there is a second process waiting for the idmap->idmap_mutex, then it may wake up and start a new call to request_key_with_auxdata(). If the call to idmap_pipe_downcall() from the first process has not yet finished calling nfs_idmap_complete_pipe_upcall_locked(), then we may end up triggering the WARN_ON_ONCE() in nfs_idmap_prepare_pipe_upcall(). The fix is to ensure that we clear idmap->idmap_upcall_data before calling nfs_idmap_instantiate(). Fixes: e9ab41b ("NFSv4: Clean up the legacy idmapper upcall") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 281c6a4 - Browse repository at this point
Copy the full SHA 281c6a4View commit details -
NFSv4.1: RECLAIM_COMPLETE must handle EACCES
commit e35a5e7 upstream. A client should be able to handle getting an EACCES error while doing a mount operation to reclaim state due to NFS4CLNT_RECLAIM_REBOOT being set. If the server returns RPC_AUTH_BADCRED because authentication failed when we execute "exportfs -au", then RECLAIM_COMPLETE will go a wrong way. After mount succeeds, all OPEN call will fail due to an NFS4ERR_GRACE error being returned. This patch is to fix it by resending a RPC request. Signed-off-by: Zhang Xianwei <[email protected]> Signed-off-by: Yi Wang <[email protected]> Fixes: aa5190d ("NFSv4: Kill nfs4_async_handle_error() abuses by NFSv4.1") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 1e9fd95 - Browse repository at this point
Copy the full SHA 1e9fd95View commit details -
NFSv4/pnfs: Fix a use-after-free bug in open
commit 2135e5d upstream. If someone cancels the open RPC call, then we must not try to free either the open slot or the layoutget operation arguments, since they are likely still in use by the hung RPC call. Fixes: 6949493 ("NFSv4: Don't hold the layoutget locks across multiple RPC calls") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for a4cf3da - Browse repository at this point
Copy the full SHA a4cf3daView commit details -
BPF: Fix potential bad pointer dereference in bpf_sys_bpf()
commit e2dcac2 upstream. The bpf_sys_bpf() helper function allows an eBPF program to load another eBPF program from within the kernel. In this case the argument union bpf_attr pointer (as well as the insns and license pointers inside) is a kernel address instead of a userspace address (which is the case of a usual bpf() syscall). To make the memory copying process in the syscall work in both cases, bpfptr_t was introduced to wrap around the pointer and distinguish its origin. Specifically, when copying memory contents from a bpfptr_t, a copy_from_user() is performed in case of a userspace address and a memcpy() is performed for a kernel address. This can lead to problems because the in-kernel pointer is never checked for validity. The problem happens when an eBPF syscall program tries to call bpf_sys_bpf() to load a program but provides a bad insns pointer -- say 0xdeadbeef -- in the bpf_attr union. The helper calls __sys_bpf() which would then call bpf_prog_load() to load the program. bpf_prog_load() is responsible for copying the eBPF instructions to the newly allocated memory for the program; it creates a kernel bpfptr_t for insns and invokes copy_from_bpfptr(). Internally, all bpfptr_t operations are backed by the corresponding sockptr_t operations, which performs direct memcpy() on kernel pointers for copy_from/strncpy_from operations. Therefore, the code is always happy to dereference the bad pointer to trigger a un-handle-able page fault and in turn an oops. However, this is not supposed to happen because at that point the eBPF program is already verified and should not cause a memory error. Sample KASAN trace: [ 25.685056][ T228] ================================================================== [ 25.685680][ T228] BUG: KASAN: user-memory-access in copy_from_bpfptr+0x21/0x30 [ 25.686210][ T228] Read of size 80 at addr 00000000deadbeef by task poc/228 [ 25.686732][ T228] [ 25.686893][ T228] CPU: 3 PID: 228 Comm: poc Not tainted 5.19.0-rc7 Freescale#7 [ 25.687375][ T228] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014 [ 25.687991][ T228] Call Trace: [ 25.688223][ T228] <TASK> [ 25.688429][ T228] dump_stack_lvl+0x73/0x9e [ 25.688747][ T228] print_report+0xea/0x200 [ 25.689061][ T228] ? copy_from_bpfptr+0x21/0x30 [ 25.689401][ T228] ? _printk+0x54/0x6e [ 25.689693][ T228] ? _raw_spin_lock_irqsave+0x70/0xd0 [ 25.690071][ T228] ? copy_from_bpfptr+0x21/0x30 [ 25.690412][ T228] kasan_report+0xb5/0xe0 [ 25.690716][ T228] ? copy_from_bpfptr+0x21/0x30 [ 25.691059][ T228] kasan_check_range+0x2bd/0x2e0 [ 25.691405][ T228] ? copy_from_bpfptr+0x21/0x30 [ 25.691734][ T228] memcpy+0x25/0x60 [ 25.692000][ T228] copy_from_bpfptr+0x21/0x30 [ 25.692328][ T228] bpf_prog_load+0x604/0x9e0 [ 25.692653][ T228] ? cap_capable+0xb4/0xe0 [ 25.692956][ T228] ? security_capable+0x4f/0x70 [ 25.693324][ T228] __sys_bpf+0x3af/0x580 [ 25.693635][ T228] bpf_sys_bpf+0x45/0x240 [ 25.693937][ T228] bpf_prog_f0ec79a5a3caca46_bpf_func1+0xa2/0xbd [ 25.694394][ T228] bpf_prog_run_pin_on_cpu+0x2f/0xb0 [ 25.694756][ T228] bpf_prog_test_run_syscall+0x146/0x1c0 [ 25.695144][ T228] bpf_prog_test_run+0x172/0x190 [ 25.695487][ T228] __sys_bpf+0x2c5/0x580 [ 25.695776][ T228] __x64_sys_bpf+0x3a/0x50 [ 25.696084][ T228] do_syscall_64+0x60/0x90 [ 25.696393][ T228] ? fpregs_assert_state_consistent+0x50/0x60 [ 25.696815][ T228] ? exit_to_user_mode_prepare+0x36/0xa0 [ 25.697202][ T228] ? syscall_exit_to_user_mode+0x20/0x40 [ 25.697586][ T228] ? do_syscall_64+0x6e/0x90 [ 25.697899][ T228] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 25.698312][ T228] RIP: 0033:0x7f6d543fb759 [ 25.698624][ T228] Code: 08 5b 89 e8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 a6 0e 00 f7 d8 64 89 01 48 [ 25.699946][ T228] RSP: 002b:00007ffc3df78468 EFLAGS: 00000287 ORIG_RAX: 0000000000000141 [ 25.700526][ T228] RAX: ffffffffffffffda RBX: 00007ffc3df78628 RCX: 00007f6d543fb759 [ 25.701071][ T228] RDX: 0000000000000090 RSI: 00007ffc3df78478 RDI: 000000000000000a [ 25.701636][ T228] RBP: 00007ffc3df78510 R08: 0000000000000000 R09: 0000000000300000 [ 25.702191][ T228] R10: 0000000000000005 R11: 0000000000000287 R12: 0000000000000000 [ 25.702736][ T228] R13: 00007ffc3df78638 R14: 000055a1584aca68 R15: 00007f6d5456a000 [ 25.703282][ T228] </TASK> [ 25.703490][ T228] ================================================================== [ 25.704050][ T228] Disabling lock debugging due to kernel taint Update copy_from_bpfptr() and strncpy_from_bpfptr() so that: - for a kernel pointer, it uses the safe copy_from_kernel_nofault() and strncpy_from_kernel_nofault() functions. - for a userspace pointer, it performs copy_from_user() and strncpy_from_user(). Fixes: af2ac3e ("bpf: Prepare bpf syscall to be used from kernel and user space.") Link: https://lore.kernel.org/bpf/[email protected]/ Signed-off-by: Jinghao Jia <[email protected]> Acked-by: Yonghong Song <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 41fd6cc - Browse repository at this point
Copy the full SHA 41fd6ccView commit details -
bpf: Don't reinit map value in prealloc_lru_pop
commit 275c30b upstream. The LRU map that is preallocated may have its elements reused while another program holds a pointer to it from bpf_map_lookup_elem. Hence, only check_and_free_fields is appropriate when the element is being deleted, as it ensures proper synchronization against concurrent access of the map value. After that, we cannot call check_and_init_map_value again as it may rewrite bpf_spin_lock, bpf_timer, and kptr fields while they can be concurrently accessed from a BPF program. This is safe to do as when the map entry is deleted, concurrent access is protected against by check_and_free_fields, i.e. an existing timer would be freed, and any existing kptr will be released by it. The program can create further timers and kptrs after check_and_free_fields, but they will eventually be released once the preallocated items are freed on map destruction, even if the item is never reused again. Hence, the deleted item sitting in the free list can still have resources attached to it, and they would never leak. With spin_lock, we never touch the field at all on delete or update, as we may end up modifying the state of the lock. Since the verifier ensures that a bpf_spin_lock call is always paired with bpf_spin_unlock call, the program will eventually release the lock so that on reuse the new user of the value can take the lock. Essentially, for the preallocated case, we must assume that the map value may always be in use by the program, even when it is sitting in the freelist, and handle things accordingly, i.e. use proper synchronization inside check_and_free_fields, and never reinitialize the special fields when it is reused on update. Fixes: 6813466 ("bpf: Add map side support for bpf timers.") Acked-by: Yonghong Song <[email protected]> Signed-off-by: Kumar Kartikeya Dwivedi <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 18a994e - Browse repository at this point
Copy the full SHA 18a994eView commit details -
bpf: Acquire map uref in .init_seq_private for array map iterator
commit f76fa6b upstream. bpf_iter_attach_map() acquires a map uref, and the uref may be released before or in the middle of iterating map elements. For example, the uref could be released in bpf_iter_detach_map() as part of bpf_link_release(), or could be released in bpf_map_put_with_uref() as part of bpf_map_release(). Alternative fix is acquiring an extra bpf_link reference just like a pinned map iterator does, but it introduces unnecessary dependency on bpf_link instead of bpf_map. So choose another fix: acquiring an extra map uref in .init_seq_private for array map iterator. Fixes: d3cc2ab ("bpf: Implement bpf iterator for array maps") Signed-off-by: Hou Tao <[email protected]> Acked-by: Yonghong Song <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 370805f - Browse repository at this point
Copy the full SHA 370805fView commit details -
bpf: Acquire map uref in .init_seq_private for hash map iterator
commit ef1e93d upstream. bpf_iter_attach_map() acquires a map uref, and the uref may be released before or in the middle of iterating map elements. For example, the uref could be released in bpf_iter_detach_map() as part of bpf_link_release(), or could be released in bpf_map_put_with_uref() as part of bpf_map_release(). So acquiring an extra map uref in bpf_iter_init_hash_map() and releasing it in bpf_iter_fini_hash_map(). Fixes: d6c4503 ("bpf: Implement bpf iterator for hash maps") Signed-off-by: Hou Tao <[email protected]> Acked-by: Yonghong Song <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 2f56304 - Browse repository at this point
Copy the full SHA 2f56304View commit details -
bpf: Acquire map uref in .init_seq_private for sock local storage map…
… iterator commit 3c5f6e6 upstream. bpf_iter_attach_map() acquires a map uref, and the uref may be released before or in the middle of iterating map elements. For example, the uref could be released in bpf_iter_detach_map() as part of bpf_link_release(), or could be released in bpf_map_put_with_uref() as part of bpf_map_release(). So acquiring an extra map uref in bpf_iter_init_sk_storage_map() and releasing it in bpf_iter_fini_sk_storage_map(). Fixes: 5ce6e77 ("bpf: Implement bpf iterator for sock local storage map") Signed-off-by: Hou Tao <[email protected]> Acked-by: Yonghong Song <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for e51b568 - Browse repository at this point
Copy the full SHA e51b568View commit details -
bpf: Acquire map uref in .init_seq_private for sock{map,hash} iterator
commit f0d2b27 upstream. sock_map_iter_attach_target() acquires a map uref, and the uref may be released before or in the middle of iterating map elements. For example, the uref could be released in sock_map_iter_detach_target() as part of bpf_link_release(), or could be released in bpf_map_put_with_uref() as part of bpf_map_release(). Fixing it by acquiring an extra map uref in .init_seq_private and releasing it in .fini_seq_private. Fixes: 0365351 ("net: Allow iterating sockmap and sockhash") Signed-off-by: Hou Tao <[email protected]> Acked-by: Yonghong Song <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 03ca12e - Browse repository at this point
Copy the full SHA 03ca12eView commit details -
bpf: Check the validity of max_rdwr_access for sock local storage map…
… iterator commit 52bd05e upstream. The value of sock local storage map is writable in map iterator, so check max_rdwr_access instead of max_rdonly_access. Fixes: 5ce6e77 ("bpf: Implement bpf iterator for sock local storage map") Signed-off-by: Hou Tao <[email protected]> Acked-by: Yonghong Song <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 6648647 - Browse repository at this point
Copy the full SHA 6648647View commit details -
can: mcp251x: Fix race condition on receive interrupt
commit d80d60b upstream. The mcp251x driver uses both receiving mailboxes of the CAN controller chips. For retrieving the CAN frames from the controller via SPI, it checks once per interrupt which mailboxes have been filled and will retrieve the messages accordingly. This introduces a race condition, as another CAN frame can enter mailbox 1 while mailbox 0 is emptied. If now another CAN frame enters mailbox 0 until the interrupt handler is called next, mailbox 0 is emptied before mailbox 1, leading to out-of-order CAN frames in the network device. This is fixed by checking the interrupt flags once again after freeing mailbox 0, to correctly also empty mailbox 1 before leaving the handler. For reproducing the bug I created the following setup: - Two CAN devices, one Raspberry Pi with MCP2515, the other can be any. - Setup CAN to 1 MHz - Spam bursts of 5 CAN-messages with increasing CAN-ids - Continue sending the bursts while sleeping a second between the bursts - Check on the RPi whether the received messages have increasing CAN-ids - Without this patch, every burst of messages will contain a flipped pair v3: https://lore.kernel.org/all/[email protected] v2: https://lore.kernel.org/all/[email protected] v1: https://lore.kernel.org/all/[email protected] Fixes: bf66f37 ("can: mcp251x: Move to threaded interrupts instead of workqueues.") Signed-off-by: Sebastian Würl <[email protected]> Link: https://lore.kernel.org/all/[email protected] [mkl: reduce scope of intf1, eflag1] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 890aba5 - Browse repository at this point
Copy the full SHA 890aba5View commit details -
can: j1939: j1939_session_destroy(): fix memory leak of skbs
commit 8c21c54 upstream. We need to drop skb references taken in j1939_session_skb_queue() when destroying a session in j1939_session_destroy(). Otherwise those skbs would be lost. Link to Syzkaller info and repro: https://forge.ispras.ru/issues/11743. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. V1: https://lore.kernel.org/all/[email protected] Fixes: 9d71dd0 ("can: add support of SAE J1939 protocol") Suggested-by: Oleksij Rempel <[email protected]> Signed-off-by: Fedor Pchelkin <[email protected]> Signed-off-by: Alexey Khoroshilov <[email protected]> Acked-by: Oleksij Rempel <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 98dc8fb - Browse repository at this point
Copy the full SHA 98dc8fbView commit details -
net: atlantic: fix aq_vec index out of range error
commit 2ba5e47 upstream. The final update statement of the for loop exceeds the array range, the dereference of self->aq_vec[i] is not checked and then leads to the index out of range error. Also fixed this kind of coding style in other for loop. [ 97.937604] UBSAN: array-index-out-of-bounds in drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48 [ 97.937607] index 8 is out of range for type 'aq_vec_s *[8]' [ 97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ Freescale#2 [ 97.937610] Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022 [ 97.937611] Workqueue: events_unbound async_run_entry_fn [ 97.937616] Call Trace: [ 97.937617] <TASK> [ 97.937619] dump_stack_lvl+0x49/0x63 [ 97.937624] dump_stack+0x10/0x16 [ 97.937626] ubsan_epilogue+0x9/0x3f [ 97.937627] __ubsan_handle_out_of_bounds.cold+0x44/0x49 [ 97.937629] ? __scm_send+0x348/0x440 [ 97.937632] ? aq_vec_stop+0x72/0x80 [atlantic] [ 97.937639] aq_nic_stop+0x1b6/0x1c0 [atlantic] [ 97.937644] aq_suspend_common+0x88/0x90 [atlantic] [ 97.937648] aq_pm_suspend_poweroff+0xe/0x20 [atlantic] [ 97.937653] pci_pm_suspend+0x7e/0x1a0 [ 97.937655] ? pci_pm_suspend_noirq+0x2b0/0x2b0 [ 97.937657] dpm_run_callback+0x54/0x190 [ 97.937660] __device_suspend+0x14c/0x4d0 [ 97.937661] async_suspend+0x23/0x70 [ 97.937663] async_run_entry_fn+0x33/0x120 [ 97.937664] process_one_work+0x21f/0x3f0 [ 97.937666] worker_thread+0x4a/0x3c0 [ 97.937668] ? process_one_work+0x3f0/0x3f0 [ 97.937669] kthread+0xf0/0x120 [ 97.937671] ? kthread_complete_and_exit+0x20/0x20 [ 97.937672] ret_from_fork+0x22/0x30 [ 97.937676] </TASK> v2. fixed "warning: variable 'aq_vec' set but not used" v3. simplified a for loop Fixes: 97bde5c ("net: ethernet: aquantia: Support for NIC-specific code") Signed-off-by: Chia-Lin Kao (AceLan) <[email protected]> Acked-by: Sudarsana Reddy Kalluru <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 422a02a - Browse repository at this point
Copy the full SHA 422a02aView commit details -
m68k: coldfire/device.c: protect FLEXCAN blocks
commit 3c2bf17 upstream. When CAN_FLEXCAN=y and M5441x is not set/enabled, there are build errors in coldfire/device.c: ../arch/m68k/coldfire/device.c:595:26: error: 'MCFFLEXCAN_BASE0' undeclared here (not in a function); did you mean 'MCFDMA_BASE0'? 595 | .start = MCFFLEXCAN_BASE0, ../arch/m68k/coldfire/device.c:596:43: error: 'MCFFLEXCAN_SIZE' undeclared here (not in a function) 596 | .end = MCFFLEXCAN_BASE0 + MCFFLEXCAN_SIZE, ../arch/m68k/coldfire/device.c:600:26: error: 'MCF_IRQ_IFL0' undeclared here (not in a function); did you mean 'MCF_IRQ_I2C0'? 600 | .start = MCF_IRQ_IFL0, ../arch/m68k/coldfire/device.c:605:26: error: 'MCF_IRQ_BOFF0' undeclared here (not in a function); did you mean 'MCF_IRQ_I2C0'? 605 | .start = MCF_IRQ_BOFF0, ../arch/m68k/coldfire/device.c:610:26: error: 'MCF_IRQ_ERR0' undeclared here (not in a function); did you mean 'MCF_IRQ_I2C0'? 610 | .start = MCF_IRQ_ERR0, Protect the FLEXCAN code blocks by checking if MCFFLEXCAN_SIZE is defined. Fixes: 35a9f93 ("m68k: m5441x: add flexcan support") Signed-off-by: Randy Dunlap <[email protected]> Cc: Greg Ungerer <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Angelo Dureghello <[email protected]> Signed-off-by: Greg Ungerer <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 3f16630 - Browse repository at this point
Copy the full SHA 3f16630View commit details -
sunrpc: fix expiry of auth creds
commit f1bafa7 upstream. Before this commit, with a large enough LRU of expired items (100), the loop skipped all the expired items and was entirely ineffectual in trimming the LRU list. Fixes: 95cd623 ('SUNRPC: Clean up the AUTH cache code') Signed-off-by: Dan Aloni <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 63e921d - Browse repository at this point
Copy the full SHA 63e921dView commit details -
commit c770f31 upstream. I discovered that xdr_encode_bool() was returning the same address that was passed in the @p parameter. The documenting comment states that the intent is to return the address of the next buffer location, just like the other "xdr_encode_*" helpers. The result was the encoded results of NFSv3 PATHCONF operations were not formed correctly. Fixes: ded04a5 ("NFSD: Update the NFSv3 PATHCONF3res encoder to use struct xdr_stream") Signed-off-by: Chuck Lever <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for d3c262f - Browse repository at this point
Copy the full SHA d3c262fView commit details -
SUNRPC: Reinitialise the backchannel request buffers before reuse
commit 6622e3a upstream. When we're reusing the backchannel requests instead of freeing them, then we should reinitialise any values of the send/receive xdr_bufs so that they reflect the available space. Fixes: 0d2a970 ("SUNRPC: Fix a backchannel race") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 9721e23 - Browse repository at this point
Copy the full SHA 9721e23View commit details -
virtio_net: fix memory leak inside XPD_TX with mergeable
commit 7a542be upstream. When we call xdp_convert_buff_to_frame() to get xdpf, if it returns NULL, we should check if xdp_page was allocated by xdp_linearize_page(). If it is newly allocated, it should be freed here alone. Just like any other "goto err_xdp". Fixes: 44fa2db ("xdp: transition into using xdp_frame for ndo_xdp_xmit") Signed-off-by: Xuan Zhuo <[email protected]> Acked-by: Jason Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for d3723ea - Browse repository at this point
Copy the full SHA d3723eaView commit details -
devlink: Fix use-after-free after a failed reload
commit 6b4db2e upstream. After a failed devlink reload, devlink parameters are still registered, which means user space can set and get their values. In the case of the mlxsw "acl_region_rehash_interval" parameter, these operations will trigger a use-after-free [1]. Fix this by rejecting set and get operations while in the failed state. Return the "-EOPNOTSUPP" error code which does not abort the parameters dump, but instead causes it to skip over the problematic parameter. Another possible fix is to perform these checks in the mlxsw parameter callbacks, but other drivers might be affected by the same problem and I am not aware of scenarios where these stricter checks will cause a regression. [1] mlxsw_spectrum3 0000:00:10.0: Port 125: Failed to register netdev mlxsw_spectrum3 0000:00:10.0: Failed to create ports ================================================================== BUG: KASAN: use-after-free in mlxsw_sp_acl_tcam_vregion_rehash_intrvl_get+0xbd/0xd0 drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:904 Read of size 4 at addr ffff8880099dcfd8 by task kworker/u4:4/777 CPU: 1 PID: 777 Comm: kworker/u4:4 Not tainted 5.19.0-rc7-custom-126601-gfe26f28c586d Freescale#1 Hardware name: QEMU MSN4700, BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x92/0xbd lib/dump_stack.c:106 print_address_description mm/kasan/report.c:313 [inline] print_report.cold+0x5e/0x5cf mm/kasan/report.c:429 kasan_report+0xb9/0xf0 mm/kasan/report.c:491 __asan_report_load4_noabort+0x14/0x20 mm/kasan/report_generic.c:306 mlxsw_sp_acl_tcam_vregion_rehash_intrvl_get+0xbd/0xd0 drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:904 mlxsw_sp_acl_region_rehash_intrvl_get+0x49/0x60 drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c:1106 mlxsw_sp_params_acl_region_rehash_intrvl_get+0x33/0x80 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3854 devlink_param_get net/core/devlink.c:4981 [inline] devlink_nl_param_fill+0x238/0x12d0 net/core/devlink.c:5089 devlink_param_notify+0xe5/0x230 net/core/devlink.c:5168 devlink_ns_change_notify net/core/devlink.c:4417 [inline] devlink_ns_change_notify net/core/devlink.c:4396 [inline] devlink_reload+0x15f/0x700 net/core/devlink.c:4507 devlink_pernet_pre_exit+0x112/0x1d0 net/core/devlink.c:12272 ops_pre_exit_list net/core/net_namespace.c:152 [inline] cleanup_net+0x494/0xc00 net/core/net_namespace.c:582 process_one_work+0x9fc/0x1710 kernel/workqueue.c:2289 worker_thread+0x675/0x10b0 kernel/workqueue.c:2436 kthread+0x30c/0x3d0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> The buggy address belongs to the physical page: page:ffffea0000267700 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99dc flags: 0x100000000000000(node=0|zone=1) raw: 0100000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099dce80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff8880099dcf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff8880099dcf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff8880099dd000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff8880099dd080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Fixes: 98bbf70 ("mlxsw: spectrum: add "acl_region_rehash_interval" devlink param") Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for c4d09fd - Browse repository at this point
Copy the full SHA c4d09fdView commit details -
net: phy: Warn about incorrect mdio_bus_phy_resume() state
commit 744d23c upstream. Calling mdio_bus_phy_resume() with neither the PHY state machine set to PHY_HALTED nor phydev->mac_managed_pm set to true is a good indication that we can produce a race condition looking like this: CPU0 CPU1 bcmgenet_resume -> phy_resume -> phy_init_hw -> phy_start -> phy_resume phy_start_aneg() mdio_bus_phy_resume -> phy_resume -> phy_write(..., BMCR_RESET) -> usleep() -> phy_read() with the phy_resume() function triggering a PHY behavior that might have to be worked around with (see bf8bfc4 ("net: phy: broadcom: Fix brcm_fet_config_init()") for instance) that ultimately leads to an error reading from the PHY. Fixes: fba863b ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM") Signed-off-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 47ac7b2 - Browse repository at this point
Copy the full SHA 47ac7b2View commit details -
net: bcmgenet: Indicate MAC is in charge of PHY PM
commit bc3410f upstream. Avoid the PHY library call unnecessarily into the suspend/resume functions by setting phydev->mac_managed_pm to true. The GENET driver essentially does exactly what mdio_bus_phy_resume() does by calling phy_init_hw() plus phy_resume(). Fixes: fba863b ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM") Signed-off-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for eb2d9dc - Browse repository at this point
Copy the full SHA eb2d9dcView commit details -
net: bgmac: Fix a BUG triggered by wrong bytes_compl
commit 1b7680c upstream. On one of our machines we got: kernel BUG at lib/dynamic_queue_limits.c:27! Internal error: Oops - BUG: 0 [Freescale#1] PREEMPT SMP ARM CPU: 0 PID: 1166 Comm: irq/41-bgmac Tainted: G W O 4.14.275-rt132 Freescale#1 Hardware name: BRCM XGS iProc task: ee3415c0 task.stack: ee32a000 PC is at dql_completed+0x168/0x178 LR is at bgmac_poll+0x18c/0x6d8 pc : [<c03b9430>] lr : [<c04b5a18>] psr: 800a0313 sp : ee32be14 ip : 000005ea fp : 00000bd4 r10: ee558500 r9 : c0116298 r8 : 00000002 r7 : 00000000 r6 : ef128810 r5 : 01993267 r4 : 01993851 r3 : ee558000 r2 : 000070e1 r1 : 00000bd4 r0 : ee52c180 Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 12c5387d Table: 8e88c04a DAC: 00000051 Process irq/41-bgmac (pid: 1166, stack limit = 0xee32a210) Stack: (0xee32be14 to 0xee32c000) be00: ee558520 ee52c100 ef128810 be20: 00000000 00000002 c0116298 c04b5a18 00000000 c0a0c8c4 c0951780 00000040 be40: c0701780 ee558500 ee55d520 ef05b340 ef6f9780 ee558520 00000001 00000040 be60: ffffe000 c0a56878 ef6fa040 c0952040 0000012c c0528744 ef6f97b0 fffcfb6a be80: c0a04104 2eda8000 c0a0c4ec c0a0d368 ee32bf44 c0153534 ee32be98 ee32be98 bea0: ee32bea0 ee32bea0 ee32bea8 ee32bea8 00000000 c01462e4 ffffe000 ef6f22a8 bec0: ffffe000 00000008 ee32bee4 c0147430 ffffe000 c094a2a8 00000003 ffffe000 bee0: c0a54528 00208040 0000000c c0a0c8c4 c0a65980 c0124d3c 00000008 ee558520 bf00: c094a23c c0a02080 00000000 c07a9910 ef136970 ef136970 ee30a440 ef136900 bf20: ee30a440 00000001 ef136900 ee30a440 c016d990 00000000 c0108db0 c012500c bf40: ef136900 c016da14 ee30a464 ffffe000 00000001 c016dd14 00000000 c016db28 bf60: ffffe000 ee21a080 ee30a400 00000000 ee32a000 ee30a440 c016dbfc ee25fd70 bf80: ee21a09c c013edcc ee32a000 ee30a400 c013ec7c 00000000 00000000 00000000 bfa0: 00000000 00000000 00000000 c0108470 00000000 00000000 00000000 00000000 bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [<c03b9430>] (dql_completed) from [<c04b5a18>] (bgmac_poll+0x18c/0x6d8) [<c04b5a18>] (bgmac_poll) from [<c0528744>] (net_rx_action+0x1c4/0x494) [<c0528744>] (net_rx_action) from [<c0124d3c>] (do_current_softirqs+0x1ec/0x43c) [<c0124d3c>] (do_current_softirqs) from [<c012500c>] (__local_bh_enable+0x80/0x98) [<c012500c>] (__local_bh_enable) from [<c016da14>] (irq_forced_thread_fn+0x84/0x98) [<c016da14>] (irq_forced_thread_fn) from [<c016dd14>] (irq_thread+0x118/0x1c0) [<c016dd14>] (irq_thread) from [<c013edcc>] (kthread+0x150/0x158) [<c013edcc>] (kthread) from [<c0108470>] (ret_from_fork+0x14/0x24) Code: a83f15e0 0200001a 0630a0e1 c3ffffea (f201f0e7) The issue seems similar to commit 90b3b33 ("net: hisilicon: Fix a BUG trigered by wrong bytes_compl") and potentially introduced by commit b38c83d ("bgmac: simplify tx ring index handling"). If there is an RX interrupt between setting ring->end and netdev_sent_queue() we can hit the BUG_ON as bgmac_dma_tx_free() can miscalculate the queue size while called from bgmac_poll(). The machine which triggered the BUG runs a v4.14 RT kernel - but the issue seems present in mainline too. Fixes: b38c83d ("bgmac: simplify tx ring index handling") Signed-off-by: Sandor Bodo-Merle <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for c506c9a - Browse repository at this point
Copy the full SHA c506c9aView commit details -
selftests: forwarding: Fix failing tests with old libnet
commit 8bcfb4a upstream. The custom multipath hash tests use mausezahn in order to test how changes in various packet fields affect the packet distribution across the available nexthops. The tool uses the libnet library for various low-level packet construction and injection. The library started using the "SO_BINDTODEVICE" socket option for IPv6 sockets in version 1.1.6 and for IPv4 sockets in version 1.2. When the option is not set, packets are not routed according to the table associated with the VRF master device and tests fail. Fix this by prefixing the command with "ip vrf exec", which will cause the route lookup to occur in the VRF routing table. This makes the tests pass regardless of the libnet library version. Fixes: 511e8db ("selftests: forwarding: Add test for custom multipath hash") Fixes: 185b0c1 ("selftests: forwarding: Add test for custom multipath hash with IPv4 GRE") Fixes: b7715ac ("selftests: forwarding: Add test for custom multipath hash with IPv6 GRE") Reported-by: Ivan Vecera <[email protected]> Tested-by: Ivan Vecera <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Amit Cohen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 8b7bf35 - Browse repository at this point
Copy the full SHA 8b7bf35View commit details -
dt-bindings: arm: qcom: fix Alcatel OneTouch Idol 3 compatibles
commit 944de51 upstream. The MSM8916 Alcatel OneTouch Idol 3 does not use MTP fallbacks in compatibles: msm8916-alcatel-idol347.dtb: /: compatible: 'oneOf' conditional failed, one must be fixed: ['alcatel,idol347', 'qcom,msm8916'] is too short Reported-by: Rob Herring <[email protected]> Fixes: e9dd2f7 ("dt-bindings: arm: qcom: Document alcatel,idol347 board") Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Rob Herring <[email protected]> Reviewed-by: Stephan Gerhold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 79eb8e9 - Browse repository at this point
Copy the full SHA 79eb8e9View commit details -
pinctrl: nomadik: Fix refcount leak in nmk_pinctrl_dt_subnode_to_map
commit 4b32e05 upstream. of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak." Fixes: c2f6d05 ("pinctrl: nomadik: refactor DT parser to take two paths") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 9272265 - Browse repository at this point
Copy the full SHA 9272265View commit details -
pinctrl: qcom: msm8916: Allow CAMSS GP clocks to be muxed
commit 4433939 upstream. GPIO 31, 32 can be muxed to GCC_CAMSS_GP(1,2)_CLK respectively but the function was never assigned to the pingroup (even though the function exists already). Add this mode to the related pins. Fixes: 5373a2c ("pinctrl: qcom: Add msm8916 pinctrl driver") Signed-off-by: Nikita Travkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for c1c7a7c - Browse repository at this point
Copy the full SHA c1c7a7cView commit details -
pinctrl: amd: Don't save/restore interrupt status and wake status bits
commit b8c824a upstream. Saving/restoring interrupt and wake status bits across suspend can cause the suspend to fail if an IRQ is serviced across the suspend cycle. Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Basavaraj Natikar <[email protected]> Fixes: 79d2c8b ("pinctrl/amd: save pin registers over suspend/resume") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for be82dc0 - Browse repository at this point
Copy the full SHA be82dc0View commit details -
pinctrl: sunxi: Add I/O bias setting for H6 R-PIO
commit fc153c8 upstream. H6 requires I/O bias configuration on both of its PIO devices. Previously it was only done for the main PIO. The setting for Port L is at bit 0, so the bank calculation needs to account for the pin base. Otherwise the wrong bit is used. Fixes: cc62383 ("pinctrl: sunxi: Support I/O bias voltage setting on H6") Reviewed-by: Jernej Skrabec <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Samuel Holland <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for fed2247 - Browse repository at this point
Copy the full SHA fed2247View commit details -
pinctrl: qcom: sm8250: Fix PDC map
commit 4b759ca upstream. Fix the PDC mapping for SM8250, gpio39 is mapped to irq73(not irq37). Fixes: b41efee("pinctrl: qcom: sm8250: Specify PDC map.") Signed-off-by: Jianhua Lu <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for a4a9456 - Browse repository at this point
Copy the full SHA a4a9456View commit details -
Input: exc3000 - fix return value check of wait_for_completion_timeout
commit 6bb7144 upstream. wait_for_completion_timeout() returns unsigned long not int. It returns 0 if timed out, and positive if completed. The check for <= 0 is ambiguous and should be == 0 here indicating timeout which is the only error case. Fixes: 102feb1 ("Input: exc3000 - factor out vendor data request") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 0a02159 - Browse repository at this point
Copy the full SHA 0a02159View commit details -
octeontx2-pf: Fix NIX_AF_TL3_TL2X_LINKX_CFG register configuration
commit 13c9f4d upstream. For packets scheduled to RPM and LBK, NIX_AF_PSE_CHANNEL_LEVEL[BP_LEVEL] selects the TL3 or TL2 scheduling level as the one used for link/channel selection and backpressure. For each scheduling queue at the selected level: Setting NIX_AF_TL3_TL2(0..255)_LINK(0..12)_CFG[ENA] = 1 allows the TL3/TL2 queue to schedule packets to a specified RPM or LBK link and channel. There is an issue in the code where NIX_AF_PSE_CHANNEL_LEVEL[BP_LEVEL] is set to TL3 where as the NIX_AF_TL3_TL2(0..255)_LINK(0..12)_CFG is configured for TL2 queue in some cases. As a result packets will not transmit on that link/channel. This patch fixes the issue by configuring the NIX_AF_TL3_TL2(0..255)_LINK(0..12)_CFG register depending on the NIX_AF_PSE_CHANNEL_LEVEL[BP_LEVEL] value. Fixes: caa2da3 ("octeontx2-pf: Initialize and config queues") Signed-off-by: Naveen Mamindlapalli <[email protected]> Signed-off-by: Sunil Kovvuri Goutham <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 17c3ea7 - Browse repository at this point
Copy the full SHA 17c3ea7View commit details -
octeontx2-af: Apply tx nibble fixup always
commit dd1d1a8 upstream. NPC_PARSE_NIBBLE for TX interface has to be equal to the RX one for some silicon revisions. Mistakenly this fixup was only applied to the default MKEX profile while it should also be applied to any loaded profile. Fixes: 1c1935c ("octeontx2-af: Add NIX1 interfaces to NPC") Signed-off-by: Stanislaw Kardach <[email protected]> Signed-off-by: Subbaraya Sundeep <[email protected]> Signed-off-by: Sunil Goutham <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for e0fe6aa - Browse repository at this point
Copy the full SHA e0fe6aaView commit details -
octeontx2-af: suppress external profile loading warning
commit cf24376 upstream. The packet parser profile supplied as firmware may not be present all the time and default profile is used mostly. Hence suppress firmware loading warning from kernel due to absence of firmware in kernel image. Fixes: 3a72441 ("octeontx2-af: add support for custom KPU entries") Signed-off-by: Harman Kalra <[email protected]> Signed-off-by: Subbaraya Sundeep <[email protected]> Signed-off-by: Sunil Goutham <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for f9a36fa - Browse repository at this point
Copy the full SHA f9a36faView commit details -
octeontx2-af: Fix mcam entry resource leak
commit 3f8fe40 upstream. The teardown sequence in FLR handler returns if no NIX LF is attached to PF/VF because it indicates that graceful shutdown of resources already happened. But there is a chance of all allocated MCAM entries not being freed by PF/VF. Hence free mcam entries even in case of detached LF. Fixes: c554f9c ("octeontx2-af: Teardown NPA, NIX LF upon receiving FLR") Signed-off-by: Subbaraya Sundeep <[email protected]> Signed-off-by: Sunil Goutham <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for dc5be2d - Browse repository at this point
Copy the full SHA dc5be2dView commit details -
octeontx2-af: Fix key checking for source mac
commit c3c2902 upstream. Given a field with its location/offset in input packet, the key checking logic verifies whether extracting the field can be supported or not based on the mkex profile loaded in hardware. This logic is wrong wrt source mac and this patch fixes that. Fixes: 9b179a9 ("octeontx2-af: Generate key field bit mask from KEX profile") Signed-off-by: Subbaraya Sundeep <[email protected]> Signed-off-by: Sunil Goutham <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 06337b9 - Browse repository at this point
Copy the full SHA 06337b9View commit details -
ACPI: property: Return type of acpi_add_nondev_subnodes() should be bool
commit 85140ef upstream. The value acpi_add_nondev_subnodes() returns is bool so change the return type of the function to match that. Fixes: 445b0eb ("ACPI / property: Add support for data-only subnodes") Signed-off-by: Sakari Ailus <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for f150c1f - Browse repository at this point
Copy the full SHA f150c1fView commit details -
geneve: do not use RT_TOS for IPv6 flowlabel
commit ca2bb69 upstream. According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. Fixes: 3a56f86 ("geneve: handle ipv6 priority like ipv4 tos") Acked-by: Guillaume Nault <[email protected]> Signed-off-by: Matthias May <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 02b2b73 - Browse repository at this point
Copy the full SHA 02b2b73View commit details -
mlx5: do not use RT_TOS for IPv6 flowlabel
commit bcb0da7 upstream. According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. Fixes: ce99f6b ("net/mlx5e: Support SRIOV TC encapsulation offloads for IPv6 tunnels") Acked-by: Guillaume Nault <[email protected]> Signed-off-by: Matthias May <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 5c9e5c4 - Browse repository at this point
Copy the full SHA 5c9e5c4View commit details -
ipv6: do not use RT_TOS for IPv6 flowlabel
commit ab7e2e0 upstream. According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. Fixes: 571912c ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Acked-by: Guillaume Nault <[email protected]> Signed-off-by: Matthias May <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 133a08a - Browse repository at this point
Copy the full SHA 133a08aView commit details -
commit bc3c8fe upstream. WARNING: suspicious RCU usage 5.2.0-rc2-00605-g2638eb8b50cfc Freescale#1 Not tainted drivers/net/plip/plip.c:1110 suspicious rcu_dereference_check() usage! plip_open is called with RTNL held, switch to the correct helper. Fixes: 2638eb8 ("net: ipv4: provide __rcu annotation for ifa_list") Reported-by: kernel test robot <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 38b2ab9 - Browse repository at this point
Copy the full SHA 38b2ab9View commit details -
vsock: Fix memory leak in vsock_connect()
commit 7e97cfe upstream. An O_NONBLOCK vsock_connect() request may try to reschedule @connect_work. Imagine the following sequence of vsock_connect() requests: 1. The 1st, non-blocking request schedules @connect_work, which will expire after 200 jiffies. Socket state is now SS_CONNECTING; 2. Later, the 2nd, blocking request gets interrupted by a signal after a few jiffies while waiting for the connection to be established. Socket state is back to SS_UNCONNECTED, but @connect_work is still pending, and will expire after 100 jiffies. 3. Now, the 3rd, non-blocking request tries to schedule @connect_work again. Since @connect_work is already scheduled, schedule_delayed_work() silently returns. sock_hold() is called twice, but sock_put() will only be called once in vsock_connect_timeout(), causing a memory leak reported by syzbot: BUG: memory leak unreferenced object 0xffff88810ea56a40 (size 1232): comm "syz-executor756", pid 3604, jiffies 4294947681 (age 12.350s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace: [<ffffffff837c830e>] sk_prot_alloc+0x3e/0x1b0 net/core/sock.c:1930 [<ffffffff837cbe22>] sk_alloc+0x32/0x2e0 net/core/sock.c:1989 [<ffffffff842ccf68>] __vsock_create.constprop.0+0x38/0x320 net/vmw_vsock/af_vsock.c:734 [<ffffffff842ce8f1>] vsock_create+0xc1/0x2d0 net/vmw_vsock/af_vsock.c:2203 [<ffffffff837c0cbb>] __sock_create+0x1ab/0x2b0 net/socket.c:1468 [<ffffffff837c3acf>] sock_create net/socket.c:1519 [inline] [<ffffffff837c3acf>] __sys_socket+0x6f/0x140 net/socket.c:1561 [<ffffffff837c3bba>] __do_sys_socket net/socket.c:1570 [inline] [<ffffffff837c3bba>] __se_sys_socket net/socket.c:1568 [inline] [<ffffffff837c3bba>] __x64_sys_socket+0x1a/0x20 net/socket.c:1568 [<ffffffff84512815>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84512815>] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:80 [<ffffffff84600068>] entry_SYSCALL_64_after_hwframe+0x44/0xae <...> Use mod_delayed_work() instead: if @connect_work is already scheduled, reschedule it, and undo sock_hold() to keep the reference count balanced. Reported-and-tested-by: [email protected] Fixes: d021c34 ("VSOCK: Introduce VM Sockets") Co-developed-by: Stefano Garzarella <[email protected]> Signed-off-by: Stefano Garzarella <[email protected]> Reviewed-by: Stefano Garzarella <[email protected]> Signed-off-by: Peilin Ye <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for e4c0428 - Browse repository at this point
Copy the full SHA e4c0428View commit details -
vsock: Set socket state back to SS_UNCONNECTED in vsock_connect_timeo…
…ut() commit a3e7b29 upstream. Imagine two non-blocking vsock_connect() requests on the same socket. The first request schedules @connect_work, and after it times out, vsock_connect_timeout() sets *sock* state back to TCP_CLOSE, but keeps *socket* state as SS_CONNECTING. Later, the second request returns -EALREADY, meaning the socket "already has a pending connection in progress", even though the first request has already timed out. As suggested by Stefano, fix it by setting *socket* state back to SS_UNCONNECTED, so that the second request will return -ETIMEDOUT. Suggested-by: Stefano Garzarella <[email protected]> Fixes: d021c34 ("VSOCK: Introduce VM Sockets") Reviewed-by: Stefano Garzarella <[email protected]> Signed-off-by: Peilin Ye <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 52d8f48 - Browse repository at this point
Copy the full SHA 52d8f48View commit details -
dt-bindings: gpio: zynq: Add missing compatible strings
commit 7668048 upstream. "xlnx,zynqmp-gpio-1.0", "xlnx,versal-gpio-1.0" and "xlnx,pmc-gpio-1.0" compatible strings were not moved to yaml format. But they were in origin text file. Fixes: 45ca160 ("dt-bindings: gpio: zynq: convert bindings to YAML") Signed-off-by: Michal Simek <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/72c973da5670b5ae81d050c582948894ee4174f8.1634206453.git.michal.simek@xilinx.com Signed-off-by: Michal Simek <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 3632c64 - Browse repository at this point
Copy the full SHA 3632c64View commit details -
dt-bindings: arm: qcom: fix Longcheer L8150 compatibles
commit 25d203d upstream. The MSM8916 Longcheer L8150 uses a fallback in compatible: msm8916-longcheer-l8150.dtb: /: compatible: 'oneOf' conditional failed, one must be fixed: ['longcheer,l8150', 'qcom,msm8916-v1-qrd/9-v1', 'qcom,msm8916'] is too long Fixes: b72160f ("dt-bindings: qcom: Document bindings for new MSM8916 devices") Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Rob Herring <[email protected]> Reviewed-by: Stephan Gerhold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for e7a0e9e - Browse repository at this point
Copy the full SHA e7a0e9eView commit details -
dt-bindings: arm: qcom: fix MSM8916 MTP compatibles
commit bb35fe1 upstream. The order of compatibles for MSM8916 MTP board is different: msm8916-mtp.dtb: /: compatible: 'oneOf' conditional failed, one must be fixed: ['qcom,msm8916-mtp', 'qcom,msm8916-mtp/1', 'qcom,msm8916'] is too long Fixes: 9d3ef77 ("dt-bindings: arm: Convert QCom board/soc bindings to json-schema") Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 5aa6548 - Browse repository at this point
Copy the full SHA 5aa6548View commit details -
dt-bindings: arm: qcom: fix MSM8994 boards compatibles
commit c704bd3 upstream. The compatibles for APQ8094/MSM8994 boards are different than specified in bindings. None of them use fallback to other SoC variant. Fixes: 9ad3c08 ("dt-bindings: arm: qcom: Document sony boards for apq8094") Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 4e96aa5 - Browse repository at this point
Copy the full SHA 4e96aa5View commit details -
dt-bindings: clock: qcom,gcc-msm8996: add more GCC clock sources
commit 2b4e75a upstream. Add additional GCC clock sources. This includes PCIe and USB PIPE and UFS symbol clocks. Fixes: 2a8aa18 ("dt-bindings: clk: qcom: Fix self-validation, split, and clean cruft") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 506fc3c - Browse repository at this point
Copy the full SHA 506fc3cView commit details -
spi: dt-bindings: cadence: add missing 'required'
commit 6eee27c upstream. During the conversion the bindings lost list of required properties. Fixes: aa79686 ("spi: convert Cadence SPI bindings to YAML") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for b847ea5 - Browse repository at this point
Copy the full SHA b847ea5View commit details -
spi: dt-bindings: zynqmp-qspi: add missing 'required'
commit acfc34f upstream. During the conversion the bindings lost list of required properties. Fixes: c58db2a ("spi: convert Xilinx Zynq UltraScale+ MPSoC GQSPI bindings to YAML") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for e49c178 - Browse repository at this point
Copy the full SHA e49c178View commit details -
ceph: use correct index when encoding client supported features
commit fea013e upstream. Feature bits have to be encoded into the correct locations. This hasn't been an issue so far because the only hole in the feature bits was in bit 10 (CEPHFS_FEATURE_RECLAIM_CLIENT), which is located in the 2nd byte. When adding more bits that go beyond the this 2nd byte, the bug will show up. [xiubli: remove incorrect comment for CEPHFS_FEATURES_CLIENT_SUPPORTED] Fixes: 9ba1e22 ("ceph: allocate the correct amount of extra bytes for the session features") Signed-off-by: Luís Henriques <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Xiubo Li <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for d27e183 - Browse repository at this point
Copy the full SHA d27e183View commit details -
tools/vm/slabinfo: use alphabetic order when two values are equal
commit 4f5ceb8 upstream. When the number of partial slabs in each cache is the same (e.g., the value are 0), the results of the `slabinfo -X -N5` and `slabinfo -P -N5` are different. / # slabinfo -X -N5 ... Slabs sorted by number of partial slabs --------------------------------------- Name Objects Objsize Space Slabs/Part/Cpu O/S O %Fr %Ef Flg inode_cache 15180 392 6217728 758/0/1 20 1 0 95 a kernfs_node_cache 22494 88 2002944 488/0/1 46 0 0 98 shmem_inode_cache 663 464 319488 38/0/1 17 1 0 96 biovec-max 50 3072 163840 4/0/1 10 3 0 93 A dentry 19050 136 2600960 633/0/2 30 0 0 99 a / # slabinfo -P -N5 Name Objects Objsize Space Slabs/Part/Cpu O/S O %Fr %Ef Flg bdev_cache 32 984 32.7K 1/0/1 16 2 0 96 Aa ext4_inode_cache 42 752 32.7K 1/0/1 21 2 0 96 a dentry 19050 136 2.6M 633/0/2 30 0 0 99 a TCPv6 17 1840 32.7K 0/0/1 17 3 0 95 A RAWv6 18 856 16.3K 0/0/1 18 2 0 94 A This problem is caused by the sort_slabs(). So let's use alphabetic order when two values are equal in the sort_slabs(). By the way, the content of the `slabinfo -h` is not aligned because the `-P|--partial Sort by number of partial slabs` uses tabs instead of spaces. So let's use spaces instead of tabs to fix it. Link: https://lkml.kernel.org/r/[email protected] Fixes: 1106b20 ("tools/vm/slabinfo: add partial slab listing to -X") Signed-off-by: Yuanzheng Song <[email protected]> Cc: "Tobin C. Harding" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 3e7ee4d - Browse repository at this point
Copy the full SHA 3e7ee4dView commit details -
ceph: don't leak snap_rwsem in handle_cap_grant
commit 58dd438 upstream. When handle_cap_grant is called on an IMPORT op, then the snap_rwsem is held and the function is expected to release it before returning. It currently fails to do that in all cases which could lead to a deadlock. Fixes: 6f05b30 ("ceph: reset i_requested_max_size if file write is not wanted") Link: https://tracker.ceph.com/issues/55857 Signed-off-by: Jeff Layton <[email protected]> Reviewed-by: Luís Henriques <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for f546faa - Browse repository at this point
Copy the full SHA f546faaView commit details -
kbuild: dummy-tools: avoid tmpdir leak in dummy gcc
commit aac2896 upstream. When passed -print-file-name=plugin, the dummy gcc script creates a temporary directory that is never cleaned up. To avoid cluttering $TMPDIR, instead use a static directory included in the source tree. Fixes: 76426e2 ("kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig") Signed-off-by: Ondrej Mosnacek <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 86ff544 - Browse repository at this point
Copy the full SHA 86ff544View commit details -
tools build: Switch to new openssl API for test-libcrypto
commit 5b24598 upstream. Switch to new EVP API for detecting libcrypto, as Fedora 36 returns an error when it encounters the deprecated function MD5_Init() and the others. The error would be interpreted as missing libcrypto, while in reality it is not. Fixes: 6e8ccb4 ("tools/bpf: properly account for libbfd variations") Signed-off-by: Roberto Sassu <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Andrii Nakryiko <[email protected]> Cc: [email protected] Cc: Daniel Borkmann <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: John Fastabend <[email protected]> Cc: KP Singh <[email protected]> Cc: [email protected] Cc: Martin KaFai Lau <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Nick Terrell <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Quentin Monnet <[email protected]> Cc: Song Liu <[email protected]> Cc: Stanislav Fomichev <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for cffd1ce - Browse repository at this point
Copy the full SHA cffd1ceView commit details -
NTB: ntb_tool: uninitialized heap data in tool_fn_write()
commit 45e1058 upstream. The call to: ret = simple_write_to_buffer(buf, size, offp, ubuf, size); will return success if it is able to write even one byte to "buf". The value of "*offp" controls which byte. This could result in reading uninitialized data when we do the sscanf() on the next line. This code is not really desigined to handle partial writes where *offp is non-zero and the "buf" is preserved and re-used between writes. Just ban partial writes and replace the simple_write_to_buffer() with copy_from_user(). Fixes: 578b881 ("NTB: Add tool test client") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Jon Mason <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 5c21186 - Browse repository at this point
Copy the full SHA 5c21186View commit details -
nfp: ethtool: fix the display error of
ethtool -m DEVNAME
commit 4ae97ca upstream. The port flag isn't set to `NFP_PORT_CHANGED` when using `ethtool -m DEVNAME` before, so the port state (e.g. interface) cannot be updated. Therefore, it caused that `ethtool -m DEVNAME` sometimes cannot read the correct information. E.g. `ethtool -m DEVNAME` cannot work when load driver before plug in optical module, as the port interface is still NONE without port update. Now update the port state before sending info to NIC to ensure that port interface is correct (latest state). Fixes: 61f7c6f ("nfp: implement ethtool get module EEPROM") Reviewed-by: Louis Peens <[email protected]> Signed-off-by: Yu Xiao <[email protected]> Signed-off-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for d98b50d - Browse repository at this point
Copy the full SHA d98b50dView commit details -
xen/xenbus: fix return type in xenbus_file_read()
commit 32ad111 upstream. This code tries to store -EFAULT in an unsigned int. The xenbus_file_read() function returns type ssize_t so the negative value is returned as a positive value to the user. This change forces another change to the min() macro. Originally, the min() macro used "unsigned" type which checkpatch complains about. Also unsigned type would break if "len" were not capped at MAX_RW_COUNT. Use size_t for the min(). (No effect on runtime for the min_t() change). Fixes: 2fb3683 ("xen: Add xenbus device driver") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Oleksandr Tyshchenko <[email protected]> Link: https://lore.kernel.org/r/YutxJUaUYRG/VLVc@kili Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 75b8101 - Browse repository at this point
Copy the full SHA 75b8101View commit details -
atm: idt77252: fix use-after-free bugs caused by tst_timer
commit 3f4093e upstream. There are use-after-free bugs caused by tst_timer. The root cause is that there are no functions to stop tst_timer in idt77252_exit(). One of the possible race conditions is shown below: (thread 1) | (thread 2) | idt77252_init_one | init_card | fill_tst | mod_timer(&card->tst_timer, ...) idt77252_exit | (wait a time) | tst_timer | | ... kfree(card) // FREE | | card->soft_tst[e] // USE The idt77252_dev is deallocated in idt77252_exit() and used in timer handler. This patch adds del_timer_sync() in idt77252_exit() in order that the timer handler could be stopped before the idt77252_dev is deallocated. Fixes: 1da177e ("Linux-2.6.12-rc2") Signed-off-by: Duoming Zhou <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for a5d7ce0 - Browse repository at this point
Copy the full SHA a5d7ce0View commit details -
geneve: fix TOS inheriting for ipv4
commit b4ab94d upstream. The current code retrieves the TOS field after the lookup on the ipv4 routing table. The routing process currently only allows routing based on the original 3 TOS bits, and not on the full 6 DSCP bits. As a result the retrieved TOS is cut to the 3 bits. However for inheriting purposes the full 6 bits should be used. Extract the full 6 bits before the route lookup and use that instead of the cut off 3 TOS bits. Fixes: e305ac6 ("geneve: Add support to collect tunnel metadata.") Signed-off-by: Matthias May <[email protected]> Acked-by: Guillaume Nault <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 51471b6 - Browse repository at this point
Copy the full SHA 51471b6View commit details -
perf probe: Fix an error handling path in 'parse_perf_probe_command()'
commit 4bf6dca upstream. If a memory allocation fail, we should branch to the error handling path in order to free some resources allocated a few lines above. Fixes: 15354d5 ("perf probe: Generate event name with line number") Signed-off-by: Christophe JAILLET <[email protected]> Acked-by: Masami Hiramatsu <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: [email protected] Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/r/b71bcb01fa0c7b9778647235c3ab490f699ba278.1659797452.git.christophe.jaillet@wanadoo.fr Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for e8ab875 - Browse repository at this point
Copy the full SHA e8ab875View commit details -
perf parse-events: Fix segfault when event parser gets an error
commit 2e82858 upstream. parse_events() is often called with parse_events_error set to NULL. Make parse_events_error__handle() not segfault in that case. A subsequent patch changes to avoid passing NULL in the first place. Fixes: 43eb05d ("perf tests: Support 'Track with sched_switch' test for hybrid") Signed-off-by: Adrian Hunter <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Jin Yao <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 5958ef8 - Browse repository at this point
Copy the full SHA 5958ef8View commit details -
perf tests: Fix Track with sched_switch test for hybrid case
commit 1da1d60 upstream. If cpu_core PMU event fails to parse, try also cpu_atom PMU event when parsing cycles event. Fixes: 43eb05d ("perf tests: Support 'Track with sched_switch' test for hybrid") Signed-off-by: Adrian Hunter <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Jin Yao <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for f39b424 - Browse repository at this point
Copy the full SHA f39b424View commit details -
dpaa2-eth: trace the allocated address instead of page struct
commit e34f493 upstream. We should trace the allocated address instead of page struct. Fixes: 27c8748 ("dpaa2-eth: Use a single page per Rx buffer") Signed-off-by: Chen Lin <[email protected]> Reviewed-by: Ioana Ciornei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 69979b5 - Browse repository at this point
Copy the full SHA 69979b5View commit details -
fs/ntfs3: Fix using uninitialized value n when calling indx_read
commit ae5a4e4 upstream. This value is checked in indx_read, so it must be initialized Fixes: 82cae26 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Yan Lei <[email protected]> Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for ecda80a - Browse repository at this point
Copy the full SHA ecda80aView commit details -
fs/ntfs3: Fix NULL deref in ntfs_update_mftmirr
commit 321460c upstream. If ntfs_fill_super() wasn't called then sbi->sb will be equal to NULL. Code should check this ptr before dereferencing. Syzbot hit this issue via passing wrong mount param as can be seen from log below Fail log: ntfs3: Unknown parameter 'iochvrset' general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [Freescale#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 1 PID: 3589 Comm: syz-executor210 Not tainted 5.18.0-rc3-syzkaller-00016-gb253435746d9 #0 ... Call Trace: <TASK> put_ntfs+0x1ed/0x2a0 fs/ntfs3/super.c:463 ntfs_fs_free+0x6a/0xe0 fs/ntfs3/super.c:1363 put_fs_context+0x119/0x7a0 fs/fs_context.c:469 do_new_mount+0x2b4/0xad0 fs/namespace.c:3044 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] Fixes: 82cae26 ("fs/ntfs3: Add initialization of super block") Reported-and-tested-by: [email protected] Signed-off-by: Pavel Skripkin <[email protected]> Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 8e8e1a8 - Browse repository at this point
Copy the full SHA 8e8e1a8View commit details -
fs/ntfs3: Don't clear upper bits accidentally in log_replay()
commit 9260343 upstream. The "vcn" variable is a 64 bit. The "log->clst_per_page" variable is a u32. This means that the mask accidentally clears out the high 32 bits when it was only supposed to clear some low bits. Fix this by adding a cast to u64. Fixes: b46acd6 ("fs/ntfs3: Add NTFS journal") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Namjae Jeon <[email protected]> Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 8feb848 - Browse repository at this point
Copy the full SHA 8feb848View commit details -
fs/ntfs3: Fix double free on remount
commit cd39981 upstream. Pointer to options was freed twice on remount Fixes xfstest generic/361 Fixes: 82cae26 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 78e4aeb - Browse repository at this point
Copy the full SHA 78e4aebView commit details -
fs/ntfs3: Do not change mode if ntfs_set_ea failed
commit 460bbf2 upstream. ntfs_set_ea can fail with NOSPC, so we don't need to change mode in this situation. Fixes xfstest generic/449 Fixes: be71b5c ("fs/ntfs3: Add attrib operations") Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for efdcf4d - Browse repository at this point
Copy the full SHA efdcf4dView commit details -
fs/ntfs3: Fix missing i_op in ntfs_read_mft
commit 37a530b upstream. There is null pointer dereference because i_op == NULL. The bug happens because we don't initialize i_op for records in $Extend. Fixes: 82cae26 ("fs/ntfs3: Add initialization of super block") Reported-by: Liangbin Lian <[email protected]> Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for c293e8a - Browse repository at this point
Copy the full SHA c293e8aView commit details -
nios2: page fault et.al. are *not* restartable syscalls...
commit 8535c23 upstream. make sure that ->orig_r2 is negative for everything except the syscalls. Fixes: 82ed08d ("nios2: Exception handling") Signed-off-by: Al Viro <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 35d5fd7 - Browse repository at this point
Copy the full SHA 35d5fd7View commit details -
nios2: don't leave NULLs in sys_call_table[]
commit 45ec746 upstream. fill the gaps in there with sys_ni_syscall, as everyone does... Fixes: 82ed08d ("nios2: Exception handling") Signed-off-by: Al Viro <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 80cae5d - Browse repository at this point
Copy the full SHA 80cae5dView commit details -
nios2: traced syscall does need to check the syscall number
commit 25ba820 upstream. all checks done before letting the tracer modify the register state are worthless... Fixes: 82ed08d ("nios2: Exception handling") Signed-off-by: Al Viro <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for f794d1f - Browse repository at this point
Copy the full SHA f794d1fView commit details -
nios2: fix syscall restart checks
commit 2d631bd upstream. sys_foo() returns -512 (aka -ERESTARTSYS) => do_signal() sees 512 in r2 and 1 in r1. sys_foo() returns 512 => do_signal() sees 512 in r2 and 0 in r1. The former is restart-worthy; the latter obviously isn't. Fixes: b53e906 ("nios2: Signal handling support") Signed-off-by: Al Viro <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 3bee7b7 - Browse repository at this point
Copy the full SHA 3bee7b7View commit details -
nios2: restarts apply only to the first sigframe we build...
commit 411a76b upstream. Fixes: b53e906 ("nios2: Signal handling support") Signed-off-by: Al Viro <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for c9f78de - Browse repository at this point
Copy the full SHA c9f78deView commit details -
nios2: add force_successful_syscall_return()
commit fd0c153 upstream. If we use the ancient SysV syscall ABI, we'd better have tell the kernel how to claim that a negative return value is a success. Use ->orig_r2 for that - it's inaccessible via ptrace, so it's a fair game for changes and it's normally[*] non-negative on return from syscall. Set to -1; syscall is not going to be restart-worthy by definition, so we won't interfere with that use either. [*] the only exception is rt_sigreturn(), where we skip the entire messing with r1/r2 anyway. Fixes: 82ed08d ("nios2: Exception handling") Signed-off-by: Al Viro <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 8af269e - Browse repository at this point
Copy the full SHA 8af269eView commit details -
iavf: Fix adminq error handling
commit 4198316 upstream. iavf_alloc_asq_bufs/iavf_alloc_arq_bufs allocates with dma_alloc_coherent memory for VF mailbox. Free DMA regions for both ASQ and ARQ in case error happens during configuration of ASQ/ARQ registers. Without this change it is possible to see when unloading interface: 74626.583369: dma_debug_device_change: device driver has pending DMA allocations while released from device [count=32] One of leaked entries details: [device address=0x0000000b27ff9000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent] Fixes: d358aa9 ("i40evf: init code and hardware support") Signed-off-by: Przemyslaw Patynowski <[email protected]> Signed-off-by: Jedrzej Jagielski <[email protected]> Tested-by: Marek Szlosek <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for dab6b55 - Browse repository at this point
Copy the full SHA dab6b55View commit details -
iavf: Fix reset error handling
commit 3107117 upstream. Do not call iavf_close in iavf_reset_task error handling. Doing so can lead to double call of napi_disable, which can lead to deadlock there. Removing VF would lead to iavf_remove task being stuck, because it requires crit_lock, which is held by iavf_close. Call iavf_disable_vf if reset fail, so that driver will clean up remaining invalid resources. During rapid VF resets, HW can fail to setup VF mailbox. Wrong error handling can lead to iavf_remove being stuck with: [ 5218.999087] iavf 0000:82:01.0: Failed to init adminq: -53 ... [ 5267.189211] INFO: task repro.sh:11219 blocked for more than 30 seconds. [ 5267.189520] Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty Freescale#1 [ 5267.189764] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 5267.190062] task:repro.sh state:D stack: 0 pid:11219 ppid: 8162 flags:0x00000000 [ 5267.190347] Call Trace: [ 5267.190647] <TASK> [ 5267.190927] __schedule+0x460/0x9f0 [ 5267.191264] schedule+0x44/0xb0 [ 5267.191563] schedule_preempt_disabled+0x14/0x20 [ 5267.191890] __mutex_lock.isra.12+0x6e3/0xac0 [ 5267.192237] ? iavf_remove+0xf9/0x6c0 [iavf] [ 5267.192565] iavf_remove+0x12a/0x6c0 [iavf] [ 5267.192911] ? _raw_spin_unlock_irqrestore+0x1e/0x40 [ 5267.193285] pci_device_remove+0x36/0xb0 [ 5267.193619] device_release_driver_internal+0xc1/0x150 [ 5267.193974] pci_stop_bus_device+0x69/0x90 [ 5267.194361] pci_stop_and_remove_bus_device+0xe/0x20 [ 5267.194735] pci_iov_remove_virtfn+0xba/0x120 [ 5267.195130] sriov_disable+0x2f/0xe0 [ 5267.195506] ice_free_vfs+0x7d/0x2f0 [ice] [ 5267.196056] ? pci_get_device+0x4f/0x70 [ 5267.196496] ice_sriov_configure+0x78/0x1a0 [ice] [ 5267.196995] sriov_numvfs_store+0xfe/0x140 [ 5267.197466] kernfs_fop_write_iter+0x12e/0x1c0 [ 5267.197918] new_sync_write+0x10c/0x190 [ 5267.198404] vfs_write+0x24e/0x2d0 [ 5267.198886] ksys_write+0x5c/0xd0 [ 5267.199367] do_syscall_64+0x3a/0x80 [ 5267.199827] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 5267.200317] RIP: 0033:0x7f5b381205c8 [ 5267.200814] RSP: 002b:00007fff8c7e8c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 5267.201981] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f5b381205c8 [ 5267.202620] RDX: 0000000000000002 RSI: 00005569420ee900 RDI: 0000000000000001 [ 5267.203426] RBP: 00005569420ee900 R08: 000000000000000a R09: 00007f5b38180820 [ 5267.204327] R10: 000000000000000a R11: 0000000000000246 R12: 00007f5b383c06e0 [ 5267.205193] R13: 0000000000000002 R14: 00007f5b383bb880 R15: 0000000000000002 [ 5267.206041] </TASK> [ 5267.206970] Kernel panic - not syncing: hung_task: blocked tasks [ 5267.207809] CPU: 48 PID: 551 Comm: khungtaskd Kdump: loaded Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty Freescale#1 [ 5267.208726] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.11.0 11/02/2019 [ 5267.209623] Call Trace: [ 5267.210569] <TASK> [ 5267.211480] dump_stack_lvl+0x33/0x42 [ 5267.212472] panic+0x107/0x294 [ 5267.213467] watchdog.cold.8+0xc/0xbb [ 5267.214413] ? proc_dohung_task_timeout_secs+0x30/0x30 [ 5267.215511] kthread+0xf4/0x120 [ 5267.216459] ? kthread_complete_and_exit+0x20/0x20 [ 5267.217505] ret_from_fork+0x22/0x30 [ 5267.218459] </TASK> Fixes: f0db789 ("i40evf: use netdev variable in reset task") Signed-off-by: Przemyslaw Patynowski <[email protected]> Signed-off-by: Jedrzej Jagielski <[email protected]> Tested-by: Marek Szlosek <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 743dc43 - Browse repository at this point
Copy the full SHA 743dc43View commit details -
ASoC: SOF: debug: Fix potential buffer overflow by snprintf()
commit 1eb123c upstream. snprintf() returns the would-be-filled size when the string overflows the given buffer size, hence using this value may result in the buffer overflow (although it's unrealistic). This patch replaces with a safer version, scnprintf() for papering over such a potential issue. Fixes: 5b10b62 ("ASoC: SOF: Add `memory_info` file to debugfs") Signed-off-by: Takashi Iwai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for b318b9d - Browse repository at this point
Copy the full SHA b318b9dView commit details -
ASoC: tas2770: Set correct FSYNC polarity
commit e9ac31f upstream. Fix setting of FSYNC polarity for DAI formats other than I2S. Also add support for polarity inversion. Fixes: 1a476ab ("tas2770: add tas2770 smart PA kernel driver") Signed-off-by: Martin Povišer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 480bf1e - Browse repository at this point
Copy the full SHA 480bf1eView commit details -
ASoC: tas2770: Allow mono streams
commit bf54d97 upstream. The part is a mono speaker amp, but it can do downmix and switch between left and right channel, so the right channel range is 1 to 2. Fixes: 1a476ab ("tas2770: add tas2770 smart PA kernel driver") Signed-off-by: Martin Povišer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 0a63bc2 - Browse repository at this point
Copy the full SHA 0a63bc2View commit details -
ASoC: tas2770: Drop conflicting set_bias_level power setting
commit 482c23f upstream. The driver is setting the PWR_CTRL field in both the set_bias_level callback and on DAPM events of the DAC widget (and also in the mute_stream method). Drop the set_bias_level callback altogether as the power setting it does is in conflict with the other code paths. Fixes: 1a476ab ("tas2770: add tas2770 smart PA kernel driver") Signed-off-by: Martin Povišer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 8eab210 - Browse repository at this point
Copy the full SHA 8eab210View commit details -
ASoC: tas2770: Fix handling of mute/unmute
commit 1e5907b upstream. Because the PWR_CTRL field is modeled as the power state of the DAC widget, and at the same time it is used to implement mute/unmute, we need some additional book-keeping to have the right end result no matter the sequence of calls. Without this fix, one can mute an ongoing stream by toggling a speaker pin control. Fixes: 1a476ab ("tas2770: add tas2770 smart PA kernel driver") Signed-off-by: Martin Povišer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 18b5a57 - Browse repository at this point
Copy the full SHA 18b5a57View commit details -
ASoC: codec: tlv320aic32x4: fix mono playback via I2S
commit b4b5f29 upstream. The two commits referenced below break mono playback via I2S DAI because they set BCLK to half the required speed. For PCM transport over I2S, the number of transmitted channels is always 2, even for mono playback. Fixes: dcd7936 ("ASoC: codec: tlv3204: Enable 24 bit audio support") Fixes: 40b3713 ("ASoC: tlv320aic32x4: Fix bdiv clock rate derivation") Signed-off-by: Philipp Zabel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for cacdddf - Browse repository at this point
Copy the full SHA cacdddfView commit details -
netfilter: nf_tables: use READ_ONCE and WRITE_ONCE for shared generat…
…ion id access commit 3400278 upstream. The generation ID is bumped from the commit path while holding the mutex, however, netlink dump operations rely on RCU. This patch also adds missing cb->base_eq initialization in nf_tables_dump_set(). Fixes: 38e029f ("netfilter: nf_tables: set NLM_F_DUMP_INTR if netlink dumping is stale") Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 8a38a73 - Browse repository at this point
Copy the full SHA 8a38a73View commit details -
fs/ntfs3: uninitialized variable in ntfs_set_acl_ex()
commit d407359 upstream. The goto out calls kfree(value) on an uninitialized pointer. Just return directly as the other error paths do. Fixes: 460bbf2 ("fs/ntfs3: Do not change mode if ntfs_set_ea failed") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 81dcb3b - Browse repository at this point
Copy the full SHA 81dcb3bView commit details -
netfilter: nf_tables: disallow NFTA_SET_ELEM_KEY_END with NFT_SET_ELE…
…M_INTERVAL_END flag commit 4963674 upstream. These are mutually exclusive, actually NFTA_SET_ELEM_KEY_END replaces the flag notation. Fixes: 7b225d0 ("netfilter: nf_tables: add NFTA_SET_ELEM_KEY_END attribute") Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 3be4d59 - Browse repository at this point
Copy the full SHA 3be4d59View commit details -
netfilter: nf_tables: possible module reference underflow in error path
commit c485c35 upstream. dst->ops is set on when nft_expr_clone() fails, but module refcount has not been bumped yet, therefore nft_expr_destroy() leads to module reference underflow. Fixes: 8cfd9b0 ("netfilter: nftables: generalize set expressions support") Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for b59bee8 - Browse repository at this point
Copy the full SHA b59bee8View commit details -
netfilter: nf_tables: really skip inactive sets when allocating name
commit 271c5ca upstream. While looping to build the bitmap of used anonymous set names, check the current set in the iteration, instead of the one that is being created. Fixes: 37a9cc5 ("netfilter: nf_tables: add generation mask to sets") Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 8a6775e - Browse repository at this point
Copy the full SHA 8a6775eView commit details -
netfilter: nf_tables: validate NFTA_SET_ELEM_OBJREF based on NFT_SET_…
…OBJECT flag commit 5a2f3dc upstream. If the NFTA_SET_ELEM_OBJREF netlink attribute is present and NFT_SET_OBJECT flag is set on, report EINVAL. Move existing sanity check earlier to validate that NFT_SET_OBJECT requires NFTA_SET_ELEM_OBJREF. Fixes: 8aeff92 ("netfilter: nf_tables: add stateful object reference to set elements") Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 46f64e6 - Browse repository at this point
Copy the full SHA 46f64e6View commit details -
netfilter: nf_tables: NFTA_SET_ELEM_KEY_END requires concat and inter…
…val flags commit 88cccd9 upstream. If the NFT_SET_CONCAT|NFT_SET_INTERVAL flags are set on, then the netlink attribute NFTA_SET_ELEM_KEY_END must be specified. Otherwise, NFTA_SET_ELEM_KEY_END should not be present. For catch-all element, NFTA_SET_ELEM_KEY_END should not be present. The NFT_SET_ELEM_INTERVAL_END is never used with this set flags combination. Fixes: 7b225d0 ("netfilter: nf_tables: add NFTA_SET_ELEM_KEY_END attribute") Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 0df32f4 - Browse repository at this point
Copy the full SHA 0df32f4View commit details -
netfilter: nf_tables: disallow NFT_SET_ELEM_CATCHALL and NFT_SET_ELEM…
…_INTERVAL_END commit fc0ae52 upstream. These flags are mutually exclusive, report EINVAL in this case. Fixes: aaa3104 ("netfilter: nftables: add catch-all set element support") Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 7ac21b9 - Browse repository at this point
Copy the full SHA 7ac21b9View commit details -
netfilter: nf_tables: check NFT_SET_CONCAT flag if field_count is spe…
…cified commit 1b6345d upstream. Since f3a2181 ("netfilter: nf_tables: Support for sets with multiple ranged fields"), it possible to combine intervals and concatenations. Later on, ef516e8 ("netfilter: nf_tables: reintroduce the NFT_SET_CONCAT flag") provides the NFT_SET_CONCAT flag for userspace to report that the set stores a concatenation. Make sure NFT_SET_CONCAT is set on if field_count is specified for consistency. Otherwise, if NFT_SET_CONCAT is specified with no field_count, bail out with EINVAL. Fixes: ef516e8 ("netfilter: nf_tables: reintroduce the NFT_SET_CONCAT flag") Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for e58d1a9 - Browse repository at this point
Copy the full SHA e58d1a9View commit details -
powerpc/pci: Fix get_phb_number() locking
commit 8d48562 upstream. The recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEP warning on some systems: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 1 lock held by swapper/1: #0: c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220 Preemption disabled at: [<00000000>] 0x0 CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0-yocto-standard+ Freescale#1 Call Trace: [d101dc90] [c073b264] dump_stack_lvl+0x50/0x8c (unreliable) [d101dcb0] [c0093b70] __might_resched+0x258/0x2a8 [d101dcd0] [c0d3e634] __mutex_lock+0x6c/0x6ec [d101dd50] [c0a84174] of_alias_get_id+0x50/0xf4 [d101dd80] [c002ec78] pcibios_alloc_controller+0x1b8/0x220 [d101ddd0] [c140c9dc] pmac_pci_init+0x198/0x784 [d101de50] [c140852c] discover_phbs+0x30/0x4c [d101de60] [c0007fd4] do_one_initcall+0x94/0x344 [d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c [d101df1] [c00086e0] kernel_init+0x34/0x160 [d101df30] [c001b334] ret_from_kernel_thread+0x5c/0x64 This is because pcibios_alloc_controller() holds hose_spinlock but of_alias_get_id() takes of_mutex which can sleep. The hose_spinlock protects the phb_bitmap, and also the hose_list, but it doesn't need to be held while get_phb_number() calls the OF routines, because those are only looking up information in the device tree. So fix it by having get_phb_number() take the hose_spinlock itself, only where required, and then dropping the lock before returning. pcibios_alloc_controller() then needs to take the lock again before the list_add() but that's safe, the order of the list is not important. Fixes: 0fe1e96 ("powerpc/pci: Prefer PCI domain assignment via DT 'linux,pci-domain' and alias") Reported-by: Guenter Roeck <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 1d9e75c - Browse repository at this point
Copy the full SHA 1d9e75cView commit details -
spi: meson-spicc: add local pow2 clock ops to preserve rate between m…
…essages commit 0999202 upstream. At the end of a message, the HW gets a reset in meson_spicc_unprepare_transfer(), this resets the SPICC_CONREG register and notably the value set by the Common Clock Framework. This is problematic because: - the register value CCF can be different from the corresponding CCF cached rate - CCF is allowed to change the clock rate whenever the HW state This introduces: - local pow2 clock ops checking the HW state before allowing a clock operation - separation of legacy pow2 clock patch and new enhanced clock path - SPICC_CONREG datarate value is now value kepts across messages It has been checked that: - SPICC_CONREG datarate value is kept across messages - CCF is only allowed to change the SPICC_CONREG datarate value when busy - SPICC_CONREG datarate value is correct for each transfer This didn't appear before commit 3e0cf4d ("spi: meson-spicc: add a linear clock divider support") because we recalculated and wrote the rate for each xfer. Fixes: 3e0cf4d ("spi: meson-spicc: add a linear clock divider support") Reported-by: Da Xue <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for dd32ea3 - Browse repository at this point
Copy the full SHA dd32ea3View commit details -
net/sunrpc: fix potential memory leaks in rpc_sysfs_xprt_state_change()
commit bfc48f1 upstream. The issue happens on some error handling paths. When the function fails to grab the object `xprt`, it simply returns 0, forgetting to decrease the reference count of another object `xps`, which is increased by rpc_sysfs_xprt_kobj_get_xprt_switch(), causing refcount leaks. Also, the function forgets to check whether `xps` is valid before using it, which may result in NULL-dereferencing issues. Fix it by adding proper error handling code when either `xprt` or `xps` is NULL. Fixes: 5b7eb78 ("SUNRPC: take a xprt offline using sysfs") Signed-off-by: Xin Xiong <[email protected]> Signed-off-by: Xin Tan <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for c0434f0 - Browse repository at this point
Copy the full SHA c0434f0View commit details -
net: dsa: mv88e6060: prevent crash on an unused port
commit 246bbf2 upstream. If the port isn't a CPU port nor a user port, 'cpu_dp' is a null pointer and a crash happened on dereferencing it in mv88e6060_setup_port(): [ 9.575872] Unable to handle kernel NULL pointer dereference at virtual address 00000014 ... [ 9.942216] mv88e6060_setup from dsa_register_switch+0x814/0xe84 [ 9.948616] dsa_register_switch from mdio_probe+0x2c/0x54 [ 9.954433] mdio_probe from really_probe.part.0+0x98/0x2a0 [ 9.960375] really_probe.part.0 from driver_probe_device+0x30/0x10c [ 9.967029] driver_probe_device from __device_attach_driver+0xb8/0x13c [ 9.973946] __device_attach_driver from bus_for_each_drv+0x90/0xe0 [ 9.980509] bus_for_each_drv from __device_attach+0x110/0x184 [ 9.986632] __device_attach from bus_probe_device+0x8c/0x94 [ 9.992577] bus_probe_device from deferred_probe_work_func+0x78/0xa8 [ 9.999311] deferred_probe_work_func from process_one_work+0x290/0x73c [ 10.006292] process_one_work from worker_thread+0x30/0x4b8 [ 10.012155] worker_thread from kthread+0xd4/0x10c [ 10.017238] kthread from ret_from_fork+0x14/0x3c Fixes: 0abfd49 ("net: dsa: use dedicated CPU port") CC: Vivien Didelot <[email protected]> CC: Florian Fainelli <[email protected]> Signed-off-by: Sergei Antonov <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for dd236b6 - Browse repository at this point
Copy the full SHA dd236b6View commit details -
mlxsw: spectrum: Clear PTP configuration after unregistering the netd…
…evice commit a159e98 upstream. Currently as part of removing port, PTP API is called to clear the existing configuration and set the 'rx_filter' and 'tx_type' to zero. The clearing is done before unregistering the netdevice, which means that there is a window of time in which the user can reconfigure PTP in the port, and this configuration will not be cleared. Reorder the operations, clear PTP configuration after unregistering the netdevice. Fixes: 8748642 ("mlxsw: spectrum: PTP: Support SIOCGHWTSTAMP, SIOCSHWTSTAMP ioctls") Signed-off-by: Amit Cohen <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Petr Machata <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for a44a1a1 - Browse repository at this point
Copy the full SHA a44a1a1View commit details -
net: moxa: pass pdev instead of ndev to DMA functions
commit 3a12df2 upstream. dma_map_single() calls fail in moxart_mac_setup_desc_ring() and moxart_mac_start_xmit() which leads to an incessant output of this: [ 16.043925] moxart-ethernet 92000000.mac eth0: DMA mapping error [ 16.050957] moxart-ethernet 92000000.mac eth0: DMA mapping error [ 16.058229] moxart-ethernet 92000000.mac eth0: DMA mapping error Passing pdev to DMA is a common approach among net drivers. Fixes: 6c821bd ("net: Add MOXA ART SoCs ethernet driver") Signed-off-by: Sergei Antonov <[email protected]> Suggested-by: Andrew Lunn <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for c7118a5 - Browse repository at this point
Copy the full SHA c7118a5View commit details -
net: fix potential refcount leak in ndisc_router_discovery()
commit 7396ba8 upstream. The issue happens on specific paths in the function. After both the object `rt` and `neigh` are grabbed successfully, when `lifetime` is nonzero but the metric needs change, the function just deletes the route and set `rt` to NULL. Then, it may try grabbing `rt` and `neigh` again if above conditions hold. The function simply overwrite `neigh` if succeeds or returns if fails, without decreasing the reference count of previous `neigh`. This may result in memory leaks. Fix it by decrementing the reference count of `neigh` in place. Fixes: 6b2e04b ("net: allow user to set metric on default route learned via Router Advertisement") Signed-off-by: Xin Xiong <[email protected]> Signed-off-by: Xin Tan <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for ffb1559 - Browse repository at this point
Copy the full SHA ffb1559View commit details -
net: dsa: microchip: ksz9477: fix fdb_dump last invalid entry
commit 36c0d93 upstream. In the ksz9477_fdb_dump function it reads the ALU control register and exit from the timeout loop if there is valid entry or search is complete. After exiting the loop, it reads the alu entry and report to the user space irrespective of entry is valid. It works till the valid entry. If the loop exited when search is complete, it reads the alu table. The table returns all ones and it is reported to user space. So bridge fdb show gives ff:ff:ff:ff:ff:ff as last entry for every port. To fix it, after exiting the loop the entry is reported only if it is valid one. Fixes: b987e98 ("dsa: add DSA switch driver for Microchip KSZ9477") Signed-off-by: Arun Ramadoss <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 29c5956 - Browse repository at this point
Copy the full SHA 29c5956View commit details -
net: dsa: felix: fix ethtool 256-511 and 512-1023 TX packet counters
commit 40d21c4 upstream. What the driver actually reports as 256-511 is in fact 512-1023, and the TX packets in the 256-511 bucket are not reported. Fix that. Fixes: 5605194 ("net: dsa: ocelot: add driver for Felix switch family") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 232fab5 - Browse repository at this point
Copy the full SHA 232fab5View commit details -
net: genl: fix error path memory leak in policy dumping
commit 2498013 upstream. If construction of the array of policies fails when recording non-first policy we need to unwind. netlink_policy_dump_add_policy() itself also needs fixing as it currently gives up on error without recording the allocated pointer in the pstate pointer. Reported-by: [email protected] Fixes: 50a896c ("genetlink: properly support per-op policy dumping") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for b067289 - Browse repository at this point
Copy the full SHA b067289View commit details -
net: dsa: don't warn in dsa_port_set_state_now() when driver doesn't …
…support it commit 211987f upstream. ds->ops->port_stp_state_set() is, like most DSA methods, optional, and if absent, the port is supposed to remain in the forwarding state (as standalone). Such is the case with the mv88e6060 driver, which does not offload the bridge layer. DSA warns that the STP state can't be changed to FORWARDING as part of dsa_port_enable_rt(), when in fact it should not. The error message is also not up to modern standards, so take the opportunity to make it more descriptive. Fixes: fd36454 ("net: dsa: change scope of STP state setter") Reported-by: Sergei Antonov <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Sergei Antonov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for caa80c1 - Browse repository at this point
Copy the full SHA caa80c1View commit details -
net: dsa: sja1105: fix buffer overflow in sja1105_setup_devlink_regio…
…ns() commit fd8e899 upstream. If an error occurs in dsa_devlink_region_create(), then 'priv->regions' array will be accessed by negative index '-1'. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Rustam Subkhankulov <[email protected]> Fixes: bf425b8 ("net: dsa: sja1105: expose static config as devlink region") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for e84c632 - Browse repository at this point
Copy the full SHA e84c632View commit details -
ice: Ignore EEXIST when setting promisc mode
commit 11e551a upstream. Ignore EEXIST error when setting promiscuous mode. This fix is needed because the driver could set promiscuous mode when it still has not cleared properly. Promiscuous mode could be set only once, so setting it second time will be rejected. Fixes: 5eda8af ("ice: Add support for PF/VF promiscuous mode") Signed-off-by: Grzegorz Siwik <[email protected]> Link: https://lore.kernel.org/all/CAK8fFZ7m-KR57M_rYX6xZN39K89O=LGooYkKsu6HKt0Bs+x6xQ@mail.gmail.com/ Tested-by: Jaroslav Pulchart <[email protected]> Tested-by: Igor Raits <[email protected]> Tested-by: Gurucharan <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for b4ac119 - Browse repository at this point
Copy the full SHA b4ac119View commit details -
i2c: imx: Make sure to unregister adapter on remove()
commit d98bdd3 upstream. If for whatever reasons pm_runtime_resume_and_get() fails and .remove() is exited early, the i2c adapter stays around and the irq still calls its handler, while the driver data and the register mapping go away. So if later the i2c adapter is accessed or the irq triggers this results in havoc accessing freed memory and unmapped registers. So unregister the software resources even if resume failed, and only skip the hardware access in that case. Fixes: 588eb93 ("i2c: imx: add runtime pm support to improve the performance") Signed-off-by: Uwe Kleine-König <[email protected]> Acked-by: Oleksij Rempel <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 09e512a - Browse repository at this point
Copy the full SHA 09e512aView commit details -
regulator: pca9450: Remove restrictions for regulator-name
commit b0de7fa upstream. The device bindings shouldn't put any constraints on the regulator-name property specified in the generic bindings. This allows using arbitrary and descriptive names for the regulators. Suggested-by: Mark Brown <[email protected]> Fixes: 7ae9e3a ("dt-bindings: regulator: add pca9450 regulator yaml") Signed-off-by: Frieder Schrempf <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for bd1fd0a - Browse repository at this point
Copy the full SHA bd1fd0aView commit details -
i40e: Fix to stop tx_timeout recovery if GLOBR fails
commit 57c942b upstream. When a tx_timeout fires, the PF attempts to recover by incrementally resetting. First we try a PFR, then CORER and finally a GLOBR. If the GLOBR fails, then we keep hitting the tx_timeout and incrementing the recovery level and issuing dmesgs, which is both annoying to the user and accomplishes nothing. If the GLOBR fails, then we're pretty much totally hosed, and there's not much else we can do to recover, so this makes it such that we just kill the VSI and stop hitting the tx_timeout in such a case. Fixes: 41c445f ("i40e: main driver core") Signed-off-by: Alan Brady <[email protected]> Signed-off-by: Mateusz Palczewski <[email protected]> Tested-by: Gurucharan <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for c56e1fc - Browse repository at this point
Copy the full SHA c56e1fcView commit details -
fec: Fix timer capture timing in
fec_ptp_enable_pps()
commit 61d5e2a upstream. Code reimplements functionality already in `fec_ptp_read()`, but misses check for FEC_QUIRK_BUG_CAPTURE. Replace with function call. Fixes: 28b5f05 ("net: fec: ptp: fix convergence issue to support LinuxPTP stack") Signed-off-by: Csókás Bence <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 334554a - Browse repository at this point
Copy the full SHA 334554aView commit details -
stmmac: intel: Add a missing clk_disable_unprepare() call in intel_et…
…h_pci_remove() commit 5c23d6b upstream. Commit 09f012e ("stmmac: intel: Fix clock handling on error and remove paths") removed this clk_disable_unprepare() This was partly revert by commit ac322f8 ("net: stmmac: Fix clock handling on remove path") which removed this clk_disable_unprepare() because: " While unloading the dwmac-intel driver, clk_disable_unprepare() is being called twice in stmmac_dvr_remove() and intel_eth_pci_remove(). This causes kernel panic on the second call. " However later on, commit 5ec5582 ("net: stmmac: add clocks management for gmac driver") has updated stmmac_dvr_remove() which do not call clk_disable_unprepare() anymore. So this call should now be called from intel_eth_pci_remove(). Fixes: 5ec5582 ("net: stmmac: add clocks management for gmac driver") Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/d7c8c1dadf40df3a7c9e643f76ffadd0ccc1ad1b.1660659689.git.christophe.jaillet@wanadoo.fr Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 4712953 - Browse repository at this point
Copy the full SHA 4712953View commit details -
igb: Add lock to avoid data race
commit 6faee3d upstream. The commit c23d92b ("igb: Teardown SR-IOV before unregister_netdev()") places the unregister_netdev() call after the igb_disable_sriov() call to avoid functionality issue. However, it introduces several race conditions when detaching a device. For example, when .remove() is called, the below interleaving leads to use-after-free. (FREE from device detaching) | (USE from netdev core) igb_remove | igb_ndo_get_vf_config igb_disable_sriov | vf >= adapter->vfs_allocated_count? kfree(adapter->vf_data) | adapter->vfs_allocated_count = 0 | | memcpy(... adapter->vf_data[vf] Moreover, the igb_disable_sriov() also suffers from data race with the requests from VF driver. (FREE from device detaching) | (USE from requests) igb_remove | igb_msix_other igb_disable_sriov | igb_msg_task kfree(adapter->vf_data) | vf < adapter->vfs_allocated_count adapter->vfs_allocated_count = 0 | To this end, this commit first eliminates the data races from netdev core by using rtnl_lock (similar to commit 7194792 ("dpaa2-eth: add MAC/PHY support through phylink")). And then adds a spinlock to eliminate races from driver requests. (similar to commit 1e53834 ("ixgbe: Add locking to prevent panic when setting sriov_numvfs to zero") Fixes: c23d92b ("igb: Teardown SR-IOV before unregister_netdev()") Signed-off-by: Lin Ma <[email protected]> Tested-by: Konrad Jankowski <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 8ee44ab - Browse repository at this point
Copy the full SHA 8ee44abView commit details -
kbuild: fix the modules order between drivers and libs
commit 1131475 upstream. Commit b2c8855 ("kbuild: update modules.order only when contained modules are updated") accidentally changed the modules order. Prior to that commit, the modules order was determined based on vmlinux-dirs, which lists core-y/m, drivers-y/m, libs-y/m, in this order. Now, subdir-modorder lists them in a different order: core-y/m, libs-y/m, drivers-y/m. Presumably, there was no practical issue because the modules in drivers and libs are orthogonal, but there is no reason to have this distortion. Get back to the original order. Fixes: b2c8855 ("kbuild: update modules.order only when contained modules are updated") Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for a2cafe2 - Browse repository at this point
Copy the full SHA a2cafe2View commit details -
gcc-plugins: Undefine LATENT_ENTROPY_PLUGIN when plugin disabled for …
…a file commit 012e8d2 upstream. Commit 36d4b36 ("lib/nodemask: inline next_node_in() and node_random()") refactored some code by moving node_random() from lib/nodemask.c to include/linux/nodemask.h, thus requiring nodemask.h to include random.h, which conditionally defines add_latent_entropy() depending on whether the macro LATENT_ENTROPY_PLUGIN is defined. This broke the build on powerpc, where nodemask.h is indirectly included in arch/powerpc/kernel/prom_init.c, part of the early boot machinery that is excluded from the latent entropy plugin using DISABLE_LATENT_ENTROPY_PLUGIN. It turns out that while we add a gcc flag to disable the actual plugin, we don't undefine LATENT_ENTROPY_PLUGIN. This leads to the following: CC arch/powerpc/kernel/prom_init.o In file included from ./include/linux/nodemask.h:97, from ./include/linux/mmzone.h:17, from ./include/linux/gfp.h:7, from ./include/linux/xarray.h:15, from ./include/linux/radix-tree.h:21, from ./include/linux/idr.h:15, from ./include/linux/kernfs.h:12, from ./include/linux/sysfs.h:16, from ./include/linux/kobject.h:20, from ./include/linux/pci.h:35, from arch/powerpc/kernel/prom_init.c:24: ./include/linux/random.h: In function 'add_latent_entropy': ./include/linux/random.h:25:46: error: 'latent_entropy' undeclared (first use in this function); did you mean 'add_latent_entropy'? 25 | add_device_randomness((const void *)&latent_entropy, sizeof(latent_entropy)); | ^~~~~~~~~~~~~~ | add_latent_entropy ./include/linux/random.h:25:46: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [scripts/Makefile.build:249: arch/powerpc/kernel/prom_init.o] Fehler 1 make[1]: *** [scripts/Makefile.build:465: arch/powerpc/kernel] Fehler 2 make: *** [Makefile:1855: arch/powerpc] Error 2 Change the DISABLE_LATENT_ENTROPY_PLUGIN flags to undefine LATENT_ENTROPY_PLUGIN for files where the plugin is disabled. Cc: Yury Norov <[email protected]> Fixes: 38addce ("gcc-plugins: Add latent_entropy plugin") Link: https://bugzilla.kernel.org/show_bug.cgi?id=216367 Link: https://lore.kernel.org/linuxppc-dev/[email protected]/ Reported-by: Erhard Furtner <[email protected]> Signed-off-by: Andrew Donnellan <[email protected]> Reviewed-by: Yury Norov <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 8304264 - Browse repository at this point
Copy the full SHA 8304264View commit details -
tracing/eprobes: Fix reading of string fields
commit f04dec9 upstream. Currently when an event probe (eprobe) hooks to a string field, it does not display it as a string, but instead as a number. This makes the field rather useless. Handle the different kinds of strings, dynamic, static, relational/dynamic etc. Now when a string field is used, the ":string" type can be used to display it: echo "e:sw sched/sched_switch comm=$next_comm:string" > dynamic_events Link: https://lkml.kernel.org/r/[email protected] Cc: [email protected] Cc: Ingo Molnar <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Tzvetomir Stoyanov <[email protected]> Cc: Tom Zanussi <[email protected]> Fixes: 7491e2c ("tracing: Add a probe that attaches to trace events") Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 1c7e569 - Browse repository at this point
Copy the full SHA 1c7e569View commit details -
drm/imx/dcss: get rid of HPD warning message
[ Upstream commit 30bdc36 ] When DCSS + MIPI_DSI is used, and the last bridge in the chain supports HPD, we can see a "Hot plug detection already enabled" warning stack trace dump that's thrown when DCSS is initialized. The problem appeared when HPD was enabled by default in the bridge_connector initialization, which made the drm_bridge_connector_enable_hpd() call, in DCSS init path, redundant. So, let's remove that call. Fixes: 09077bc ("drm/bridge_connector: enable HPD by default if supported") Signed-off-by: Laurentiu Palcu <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 88db4a2 - Browse repository at this point
Copy the full SHA 88db4a2View commit details -
ASoC: SOF: Intel: hda: Define rom_status_reg in sof_intel_dsp_desc
[ Upstream commit 71778f7 ] Add the rom_status_reg field to struct sof_intel_dsp_desc and define it for HDA platforms. This will be used to check the ROM status during FW boot. Signed-off-by: Ranjani Sridharan <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Péter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 3142b5f - Browse repository at this point
Copy the full SHA 3142b5fView commit details -
ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf()
[ Upstream commit 94c1ceb ] snprintf() returns the would-be-filled size when the string overflows the given buffer size, hence using this value may result in the buffer overflow (although it's unrealistic). This patch replaces with a safer version, scnprintf() for papering over such a potential issue. Fixes: 29c8e43 ("ASoC: SOF: Intel: hda: add extended rom status dump to error log") Signed-off-by: Takashi Iwai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 6ee1310 - Browse repository at this point
Copy the full SHA 6ee1310View commit details -
drm/meson: Fix refcount bugs in meson_vpu_has_available_connectors()
[ Upstream commit 91b3c8d ] In this function, there are two refcount leak bugs: (1) when breaking out of for_each_endpoint_of_node(), we need call the of_node_put() for the 'ep'; (2) we should call of_node_put() for the reference returned by of_graph_get_remote_port() when it is not used anymore. Fixes: bbbe775 ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by: Liang He <[email protected]> Acked-by: Martin Blumenstingl <[email protected]> Acked-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for fe71d84 - Browse repository at this point
Copy the full SHA fe71d84View commit details -
drm/sun4i: dsi: Prevent underflow when computing packet sizes
[ Upstream commit 82a1356 ] Currently, the packet overhead is subtracted using unsigned arithmetic. With a short sync pulse, this could underflow and wrap around to near the maximal u16 value. Fix this by using signed subtraction. The call to max() will correctly handle any negative numbers that are produced. Apply the same fix to the other timings, even though those subtractions are less likely to underflow. Fixes: 133add5 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller support") Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Jernej Skrabec <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 98e28de - Browse repository at this point
Copy the full SHA 98e28deView commit details -
net: qrtr: start MHI channel after endpoit creation
[ Upstream commit 68a838b ] MHI channel may generates event/interrupt right after enabling. It may leads to 2 race conditions issues. 1) Such event may be dropped by qcom_mhi_qrtr_dl_callback() at check: if (!qdev || mhi_res->transaction_status) return; Because dev_set_drvdata(&mhi_dev->dev, qdev) may be not performed at this moment. In this situation qrtr-ns will be unable to enumerate services in device. --------------------------------------------------------------- 2) Such event may come at the moment after dev_set_drvdata() and before qrtr_endpoint_register(). In this case kernel will panic with accessing wrong pointer at qcom_mhi_qrtr_dl_callback(): rc = qrtr_endpoint_post(&qdev->ep, mhi_res->buf_addr, mhi_res->bytes_xferd); Because endpoint is not created yet. -------------------------------------------------------------- So move mhi_prepare_for_transfer_autoqueue after endpoint creation to fix it. Fixes: a2e2cc0 ("net: qrtr: Start MHI channels during init") Signed-off-by: Maxim Kochetkov <[email protected]> Reviewed-by: Hemant Kumar <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Loic Poulain <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for c682fb7 - Browse repository at this point
Copy the full SHA c682fb7View commit details -
KVM: arm64: Treat PMCR_EL1.LC as RES1 on asymmetric systems
[ Upstream commit f3c6efc ] KVM does not support AArch32 on asymmetric systems. To that end, enforce AArch64-only behavior on PMCR_EL1.LC when on an asymmetric system. Fixes: 2122a83 ("arm64: Allow mismatched 32-bit EL0 support") Signed-off-by: Oliver Upton <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for cb332a6 - Browse repository at this point
Copy the full SHA cb332a6View commit details -
KVM: arm64: Reject 32bit user PSTATE on asymmetric systems
[ Upstream commit b10d86f ] KVM does not support AArch32 EL0 on asymmetric systems. To that end, prevent userspace from configuring a vCPU in such a state through setting PSTATE. It is already ABI that KVM rejects such a write on a system where AArch32 EL0 is unsupported. Though the kernel's definition of a 32bit system changed in commit 2122a83 ("arm64: Allow mismatched 32-bit EL0 support"), KVM's did not. Fixes: 2122a83 ("arm64: Allow mismatched 32-bit EL0 support") Signed-off-by: Oliver Upton <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 57b5be2 - Browse repository at this point
Copy the full SHA 57b5be2View commit details -
HID: multitouch: new device class fix Lenovo X12 trackpad sticky
[ Upstream commit 54eed5c ] The trackpad of the given device sends continuous report of pointers status as per wxn8 spec. However, the spec did not clarify when the fingers are lifted so fast that between the interval of two report frames fingers on pad reduced from >=2 to 0. The second last report contains >=2 fingers with tip state 1 and the last report contains only 1 finger with tip state 0. Although this can happen unfrequently, a quick fix will be improve the consistency to 100%. A quick fix is to disable MT_QUIRK_ALWAYS_VALID and enable MT_QUIRK_NOT_SEEN_MEANS_UP. Test for hid-tools is added in [1] In addition to this, I2C device 04CA:00B1 may also need similar class but with MT_QUIRK_FORCE_MULTI_INPUT disabled (but it does not harm to enable it on non-multi-input device either). The respective owner has been notified and a patch may coming soon after test. [1]: https://gitlab.freedesktop.org/libevdev/hid-tools/-/merge_requests/130 Signed-off-by: Tao Jin <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 6fc955b - Browse repository at this point
Copy the full SHA 6fc955bView commit details -
PCI: Add ACS quirk for Broadcom BCM5750x NICs
[ Upstream commit afd306a ] The Broadcom BCM5750x NICs may be multi-function devices. They do not advertise ACS capability. Peer-to-peer transactions are not possible between the individual functions, so it is safe to treat them as fully isolated. Add an ACS quirk for these devices so the functions can be in independent IOMMU groups and attached individually to userspace applications using VFIO. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Pavan Chebbi <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for da56759 - Browse repository at this point
Copy the full SHA da56759View commit details -
platform/chrome: cros_ec_proto: don't show MKBP version if unsupported
[ Upstream commit b36f064 ] It wrongly showed the following message when it doesn't support MKBP: "MKBP support version 4294967295". Fix it. Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Tzung-Bi Shih <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 08c0a77 - Browse repository at this point
Copy the full SHA 08c0a77View commit details -
usb: cdns3 fix use-after-free at workaround 2
[ Upstream commit 7d602f3 ] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xac cdns3_wa2_remove_old_request() { ... kfree(priv_req->request.buf); cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request); list_del_init(&priv_req->list); ^^^ use after free ... } cdns3_gadget_ep_free_request() free the space pointed by priv_req, but priv_req is used in the following list_del_init(). This patch move list_del_init() before cdns3_gadget_ep_free_request(). Signed-off-by: Frank Li <[email protected]> Signed-off-by: Faqiang Zhu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for c3c1dba - Browse repository at this point
Copy the full SHA c3c1dbaView commit details -
usb: cdns3: fix random warning message when driver load
[ Upstream commit 8659ab3 ] Warning log: [ 4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code! [ 4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c Freescale#20 [ 4.158010] Hardware name: Freescale i.MX8QXP MEK (DT) [ 4.163155] Call trace: [ 4.165600] dump_backtrace+0x0/0x1b0 [ 4.169286] show_stack+0x18/0x68 [ 4.172611] dump_stack_lvl+0x68/0x84 [ 4.176286] dump_stack+0x18/0x34 [ 4.179613] kmalloc_fix_flags+0x60/0x88 [ 4.183550] new_slab+0x334/0x370 [ 4.186878] ___slab_alloc.part.108+0x4d4/0x748 [ 4.191419] __slab_alloc.isra.109+0x30/0x78 [ 4.195702] kmem_cache_alloc+0x40c/0x420 [ 4.199725] dma_pool_alloc+0xac/0x1f8 [ 4.203486] cdns3_allocate_trb_pool+0xb4/0xd0 pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags) { ... page = kmalloc(sizeof(*page), mem_flags); page->vaddr = dma_alloc_coherent(pool->dev, pool->allocation, &page->dma, mem_flags); ... } kmalloc was called with mem_flags, which is passed down in cdns3_allocate_trb_pool() and have GFP_DMA32 flags. kmall_fix_flags() report warning. GFP_DMA32 is not useful at all. dma_alloc_coherent() will handle DMA memory region correctly by pool->dev. GFP_DMA32 can be removed safely. Signed-off-by: Frank Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 8e14274 - Browse repository at this point
Copy the full SHA 8e14274View commit details -
usb: gadget: uvc: calculate the number of request depending on framesize
[ Upstream commit 87d76b5 ] The current limitation of possible number of requests being handled is dependent on the gadget speed. It makes more sense to depend on the typical frame size when calculating the number of requests. This patch is changing this and is using the previous limits as boundaries for reasonable minimum and maximum number of requests. For a 1080p jpeg encoded video stream with a maximum imagesize of e.g. 800kB with a maxburst of 8 and an multiplier of 1 the resulting number of requests is calculated to 49. 800768 1 nreqs = ------ * -------------- ~= 49 2 (1024 * 8 * 1) Tested-by: Dan Vacura <[email protected]> Signed-off-by: Michael Grzeschik <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for de6aa7a - Browse repository at this point
Copy the full SHA de6aa7aView commit details -
usb: gadget: uvc: call uvc uvcg_warn on completed status instead of u…
…vcg_info [ Upstream commit a725d0f ] Likewise to the uvcvideo hostside driver, this patch is changing the usb_request message of an non zero completion handler call from dev_info to dev_warn. Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Michael Grzeschik <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for fb76cdd - Browse repository at this point
Copy the full SHA fb76cddView commit details -
PCI: aardvark: Fix reporting Slot capabilities on emulated bridge
[ Upstream commit bcdb6fd ] Slot capabilities are currently not reported because emulated bridge does not report the PCI_EXP_FLAGS_SLOT flag. Set PCI_EXP_FLAGS_SLOT to let the kernel know that PCI_EXP_SLT* registers are supported. Move setting of PCI_EXP_SLTCTL register from "dynamic" pcie_conf_read function to static buffer as it is only statically filled the PCI_EXP_SLTSTA_PDS flag and dynamic read callback is not needed for this register. Set Presence State Bit to 1 since there is no support for unplugging the card and there is currently no platform able to detect presence of a card - in such a case the bit needs to be set to 1. Finally correctly set Physical Slot Number to 1 since there is only one port and zero value is reserved for ports within the same silicon as Root Port which is not our case for Aardvark HW. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Marek Behún <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 4996809 - Browse repository at this point
Copy the full SHA 4996809View commit details -
irqchip/tegra: Fix overflow implicit truncation warnings
[ Upstream commit 4436859 ] Fix -Woverflow warnings for tegra irqchip driver which is a result of moving arm64 custom MMIO accessor macros to asm-generic function implementations giving a bonus type-checking now and uncovering these overflow warnings. drivers/irqchip/irq-tegra.c: In function ‘tegra_ictlr_suspend’: drivers/irqchip/irq-tegra.c:151:18: warning: large integer implicitly truncated to unsigned type [-Woverflow] writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR); ^ Suggested-by: Marc Zyngier <[email protected]> Signed-off-by: Sai Prakash Ranjan <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Cc: Marc Zyngier <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for b01d6bf - Browse repository at this point
Copy the full SHA b01d6bfView commit details -
drm/meson: Fix overflow implicit truncation warnings
[ Upstream commit 98692f5 ] Fix -Woverflow warnings for drm/meson driver which is a result of moving arm64 custom MMIO accessor macros to asm-generic function implementations giving a bonus type-checking now and uncovering these overflow warnings. drivers/gpu/drm/meson/meson_viu.c: In function ‘meson_viu_init’: drivers/gpu/drm/meson/meson_registers.h:1826:48: error: large integer implicitly truncated to unsigned type [-Werror=overflow] #define VIU_OSD_BLEND_REORDER(dest, src) ((src) << (dest * 4)) ^ drivers/gpu/drm/meson/meson_viu.c:472:18: note: in expansion of macro ‘VIU_OSD_BLEND_REORDER’ writel_relaxed(VIU_OSD_BLEND_REORDER(0, 1) | ^~~~~~~~~~~~~~~~~~~~~ Reported-by: kernel test robot <[email protected]> Signed-off-by: Sai Prakash Ranjan <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Neil Armstrong <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 00c274b - Browse repository at this point
Copy the full SHA 00c274bView commit details -
clk: ti: Stop using legacy clkctrl names for omap4 and 5
[ Upstream commit 255584b ] With the addition of clock-output-names, we can now unify the internal clock naming for omap4 and 5 to follow the other TI SoCs. We are still using legacy clkctrl names for omap4 and 5 based on the clock manager name which is wrong. Instead, we want to use the clkctrl clock based naming. We must now also drop the legacy TI_CLK_CLKCTRL_COMPAT quirk for the clkctrl clock. This change will allow further devicetree warning cleanup as already done for am3/4 and dra7. Cc: [email protected] Cc: Stephen Boyd <[email protected]> Cc: Tero Kristo <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 35c3ec7 - Browse repository at this point
Copy the full SHA 35c3ec7View commit details -
scsi: ufs: ufs-mediatek: Fix the timing of configuring device regulators
[ Upstream commit 3fd23b8 ] Currently the LPM configurations of device regulators may not work since VCC is not disabled yet while ufs_mtk_vreg_set_lpm() is executed. Fix this by changing the timing of invoking ufs_mtk_vreg_set_lpm(). Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Stanley Chu <[email protected]> Signed-off-by: Po-Wen Kao <[email protected]> Signed-off-by: Stanley Chu <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 4d6bab8 - Browse repository at this point
Copy the full SHA 4d6bab8View commit details -
usb: host: ohci-ppc-of: Fix refcount leak bug
[ Upstream commit 40a959d ] In ohci_hcd_ppc_of_probe(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore. Acked-by: Alan Stern <[email protected]> Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 0fc62bb - Browse repository at this point
Copy the full SHA 0fc62bbView commit details -
usb: renesas: Fix refcount leak bug
[ Upstream commit 9d6d530 ] In usbhs_rza1_hardware_init(), of_find_node_by_name() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore. Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for fbdbd61 - Browse repository at this point
Copy the full SHA fbdbd61View commit details -
usb: dwc2: gadget: remove D+ pull-up while no vbus with usb-role-switch
[ Upstream commit db638c6 ] When using usb-role-switch, D+ pull-up is set as soon as DTCL_SFTDISCON is cleared, whatever the vbus valid signal state is. The pull-up should not be set when vbus isn't present (this is determined by the drd controller). This patch ensures that B-Session (so Peripheral role + vbus valid signal) is valid before clearing the DCTL_SFTDISCON bit when role switch is used. Keep original behavior when usb-role-switch isn't used. Acked-by: Minas Harutyunyan <[email protected]> Signed-off-by: Amelie Delaunay <[email protected]> Signed-off-by: Fabrice Gasnier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for b9c31d4 - Browse repository at this point
Copy the full SHA b9c31d4View commit details -
vboxguest: Do not use devm for irq
[ Upstream commit 6169525 ] When relying on devm it doesn't get freed early enough which causes the following warning when unloading the module: [249348.837181] remove_proc_entry: removing non-empty directory 'irq/20', leaking at least 'vboxguest' [249348.837219] WARNING: CPU: 0 PID: 6708 at fs/proc/generic.c:715 remove_proc_entry+0x119/0x140 [249348.837379] Call Trace: [249348.837385] unregister_irq_proc+0xbd/0xe0 [249348.837392] free_desc+0x23/0x60 [249348.837396] irq_free_descs+0x4a/0x70 [249348.837401] irq_domain_free_irqs+0x160/0x1a0 [249348.837452] mp_unmap_irq+0x5c/0x60 [249348.837458] acpi_unregister_gsi_ioapic+0x29/0x40 [249348.837463] acpi_unregister_gsi+0x17/0x30 [249348.837467] acpi_pci_irq_disable+0xbf/0xe0 [249348.837473] pcibios_disable_device+0x20/0x30 [249348.837478] pci_disable_device+0xef/0x120 [249348.837482] vbg_pci_remove+0x6c/0x70 [vboxguest] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Pascal Terjan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 348274a - Browse repository at this point
Copy the full SHA 348274aView commit details -
clk: qcom: ipq8074: dont disable gcc_sleep_clk_src
[ Upstream commit 1bf7305 ] Once the usb sleep clocks are disabled, clock framework is trying to disable the sleep clock source also. However, it seems that it cannot be disabled and trying to do so produces: [ 245.436390] ------------[ cut here ]------------ [ 245.441233] gcc_sleep_clk_src status stuck at 'on' [ 245.441254] WARNING: CPU: 2 PID: 223 at clk_branch_wait+0x130/0x140 [ 245.450435] Modules linked in: xhci_plat_hcd xhci_hcd dwc3 dwc3_qcom leds_gpio [ 245.456601] CPU: 2 PID: 223 Comm: sh Not tainted 5.18.0-rc4 Freescale#215 [ 245.463889] Hardware name: Xiaomi AX9000 (DT) [ 245.470050] pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 245.474307] pc : clk_branch_wait+0x130/0x140 [ 245.481073] lr : clk_branch_wait+0x130/0x140 [ 245.485588] sp : ffffffc009f2bad0 [ 245.489838] x29: ffffffc009f2bad0 x28: ffffff8003e6c800 x27: 0000000000000000 [ 245.493057] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800226ef20 [ 245.500175] x23: ffffffc0089ff550 x22: 0000000000000000 x21: ffffffc008476ad0 [ 245.507294] x20: 0000000000000000 x19: ffffffc00965ac70 x18: fffffffffffc51a7 [ 245.514413] x17: 68702e3030303837 x16: 3a6d726f6674616c x15: ffffffc089f2b777 [ 245.521531] x14: ffffffc0095c9d18 x13: 0000000000000129 x12: 0000000000000129 [ 245.528649] x11: 00000000ffffffea x10: ffffffc009621d18 x9 : 0000000000000001 [ 245.535767] x8 : 0000000000000001 x7 : 0000000000017fe8 x6 : 0000000000000001 [ 245.542885] x5 : ffffff803fdca6d8 x4 : 0000000000000000 x3 : 0000000000000027 [ 245.550002] x2 : 0000000000000027 x1 : 0000000000000023 x0 : 0000000000000026 [ 245.557122] Call trace: [ 245.564229] clk_branch_wait+0x130/0x140 [ 245.566490] clk_branch2_disable+0x2c/0x40 [ 245.570656] clk_core_disable+0x60/0xb0 [ 245.574561] clk_core_disable+0x68/0xb0 [ 245.578293] clk_disable+0x30/0x50 [ 245.582113] dwc3_qcom_remove+0x60/0xc0 [dwc3_qcom] [ 245.585588] platform_remove+0x28/0x60 [ 245.590361] device_remove+0x4c/0x80 [ 245.594179] device_release_driver_internal+0x1dc/0x230 [ 245.597914] device_driver_detach+0x18/0x30 [ 245.602861] unbind_store+0xec/0x110 [ 245.607027] drv_attr_store+0x24/0x40 [ 245.610847] sysfs_kf_write+0x44/0x60 [ 245.614405] kernfs_fop_write_iter+0x128/0x1c0 [ 245.618052] new_sync_write+0xc0/0x130 [ 245.622391] vfs_write+0x1d4/0x2a0 [ 245.626123] ksys_write+0x58/0xe0 [ 245.629508] __arm64_sys_write+0x1c/0x30 [ 245.632895] invoke_syscall.constprop.0+0x5c/0x110 [ 245.636890] do_el0_svc+0xa0/0x150 [ 245.641488] el0_svc+0x18/0x60 [ 245.644872] el0t_64_sync_handler+0xa4/0x130 [ 245.647914] el0t_64_sync+0x174/0x178 [ 245.652340] ---[ end trace 0000000000000000 ]--- So, add CLK_IS_CRITICAL flag to the clock so that the kernel won't try to disable the sleep clock. Signed-off-by: Robert Marko <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 17d5849 - Browse repository at this point
Copy the full SHA 17d5849View commit details -
uacce: Handle parent device removal or parent driver module rmmod
[ Upstream commit 80fc671 ] The uacce driver must deal with a possible removal of the parent device or parent driver module rmmod at any time. Although uacce_remove(), called on device removal and on driver unbind, prevents future use of the uacce fops by removing the cdev, fops that were called before that point may still be running. Serialize uacce_fops_open() and uacce_remove() with uacce->mutex. Serialize other fops against uacce_remove() with q->mutex. Since we need to protect uacce_fops_poll() which gets called on the fast path, replace uacce->queues_lock with q->mutex to improve scalability. The other fops are only used during setup. uacce_queue_is_valid(), checked under q->mutex or uacce->mutex, denotes whether uacce_remove() has disabled all queues. If that is the case, don't go any further since the parent device is being removed and uacce->ops should not be called anymore. Reported-by: Yang Shen <[email protected]> Signed-off-by: Zhangfei Gao <[email protected]> Signed-off-by: Jean-Philippe Brucker <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 50de504 - Browse repository at this point
Copy the full SHA 50de504View commit details -
zram: do not lookup algorithm in backends table
[ Upstream commit dc89997 ] Always use crypto_has_comp() so that crypto can lookup module, call usermodhelper to load the modules, wait for usermodhelper to finish and so on. Otherwise crypto will do all of these steps under CPU hot-plug lock and this looks like too much stuff to handle under the CPU hot-plug lock. Besides this can end up in a deadlock when usermodhelper triggers a code path that attempts to lock the CPU hot-plug lock, that zram already holds. An example of such deadlock: - path A. zram grabs CPU hot-plug lock, execs /sbin/modprobe from crypto and waits for modprobe to finish disksize_store zcomp_create __cpuhp_state_add_instance __cpuhp_state_add_instance_cpuslocked zcomp_cpu_up_prepare crypto_alloc_base crypto_alg_mod_lookup call_usermodehelper_exec wait_for_completion_killable do_wait_for_common schedule - path B. async work kthread that brings in scsi device. It wants to register CPUHP states at some point, and it needs the CPU hot-plug lock for that, which is owned by zram. async_run_entry_fn scsi_probe_and_add_lun scsi_mq_alloc_queue blk_mq_init_queue blk_mq_init_allocated_queue blk_mq_realloc_hw_ctxs __cpuhp_state_add_instance __cpuhp_state_add_instance_cpuslocked mutex_lock schedule - path C. modprobe sleeps, waiting for all aync works to finish. load_module do_init_module async_synchronize_full async_synchronize_cookie_domain schedule [[email protected]: add comment] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Sergey Senozhatsky <[email protected]> Cc: Minchan Kim <[email protected]> Cc: Nitin Gupta <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 2504102 - Browse repository at this point
Copy the full SHA 2504102View commit details -
clk: qcom: clk-alpha-pll: fix clk_trion_pll_configure description
[ Upstream commit 94bed9b ] After merging lucid and trion pll functions in commit 0b01489 ("clk: qcom: clk-alpha-pll: same regs and ops for trion and lucid") the function clk_trion_pll_configure() is left with an old description header, which results in a W=2 compile time warning, fix it. Acked-by: Stephen Boyd <[email protected]> Reviewed-by: Vinod Koul <[email protected]> Signed-off-by: Vladimir Zapolskiy <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 0af01d2 - Browse repository at this point
Copy the full SHA 0af01d2View commit details -
scsi: lpfc: Prevent buffer overflow crashes in debugfs with malformed…
… user input [ Upstream commit f8191d4 ] Malformed user input to debugfs results in buffer overflow crashes. Adapt input string lengths to fit within internal buffers, leaving space for NULL terminators. Link: https://lore.kernel.org/r/[email protected] Co-developed-by: Justin Tee <[email protected]> Signed-off-by: Justin Tee <[email protected]> Signed-off-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for b92506d - Browse repository at this point
Copy the full SHA b92506dView commit details -
scsi: lpfc: Fix possible memory leak when failing to issue CMF WQE
[ Upstream commit 2f67dc7 ] There is no corresponding free routine if lpfc_sli4_issue_wqe fails to issue the CMF WQE in lpfc_issue_cmf_sync_wqe. If ret_val is non-zero, then free the iocbq request structure. Link: https://lore.kernel.org/r/[email protected] Co-developed-by: Justin Tee <[email protected]> Signed-off-by: Justin Tee <[email protected]> Signed-off-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 9c8e2e6 - Browse repository at this point
Copy the full SHA 9c8e2e6View commit details -
gadgetfs: ep_io - wait until IRQ finishes
[ Upstream commit 04cb742 ] after usb_ep_queue() if wait_for_completion_interruptible() is interrupted we need to wait until IRQ gets finished. Otherwise complete() from epio_complete() can corrupt stack. Signed-off-by: Jozef Martiniak <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 94aadba - Browse repository at this point
Copy the full SHA 94aadbaView commit details -
coresight: etm4x: avoid build failure with unrolled loops
[ Upstream commit 4d45bc8 ] When the following configs are enabled: * CORESIGHT * CORESIGHT_SOURCE_ETM4X * UBSAN * UBSAN_TRAP Clang fails assemble the kernel with the error: <instantiation>:1:7: error: expected constant expression in '.inst' directive .inst (0xd5200000|((((2) << 19) | ((1) << 16) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 7) & 0x7)) << 12) | ((((((((((0x160 + (i * 4))))) >> 2))) & 0xf)) << 8) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 4) & 0x7)) << 5)))|(.L__reg_num_x8)) ^ drivers/hwtracing/coresight/coresight-etm4x-core.c:702:4: note: while in macro instantiation etm4x_relaxed_read32(csa, TRCCNTVRn(i)); ^ drivers/hwtracing/coresight/coresight-etm4x.h:403:4: note: expanded from macro 'etm4x_relaxed_read32' read_etm4x_sysreg_offset((offset), false))) ^ drivers/hwtracing/coresight/coresight-etm4x.h:383:12: note: expanded from macro 'read_etm4x_sysreg_offset' __val = read_etm4x_sysreg_const_offset((offset)); \ ^ drivers/hwtracing/coresight/coresight-etm4x.h:149:2: note: expanded from macro 'read_etm4x_sysreg_const_offset' READ_ETM4x_REG(ETM4x_OFFSET_TO_REG(offset)) ^ drivers/hwtracing/coresight/coresight-etm4x.h:144:2: note: expanded from macro 'READ_ETM4x_REG' read_sysreg_s(ETM4x_REG_NUM_TO_SYSREG((reg))) ^ arch/arm64/include/asm/sysreg.h:1108:15: note: expanded from macro 'read_sysreg_s' asm volatile(__mrs_s("%0", r) : "=r" (__val)); \ ^ arch/arm64/include/asm/sysreg.h:1074:2: note: expanded from macro '__mrs_s' " mrs_s " v ", " __stringify(r) "\n" \ ^ Consider the definitions of TRCSSCSRn and TRCCNTVRn: drivers/hwtracing/coresight/coresight-etm4x.h:56 #define TRCCNTVRn(n) (0x160 + (n * 4)) drivers/hwtracing/coresight/coresight-etm4x.h:81 #define TRCSSCSRn(n) (0x2A0 + (n * 4)) Where the macro parameter is expanded to i; a loop induction variable from etm4_disable_hw. When any compiler can determine that loops may be unrolled, then the __builtin_constant_p check in read_etm4x_sysreg_offset() defined in drivers/hwtracing/coresight/coresight-etm4x.h may evaluate to true. This can lead to the expression `(0x160 + (i * 4))` being passed to read_etm4x_sysreg_const_offset. Via the trace above, this is passed through READ_ETM4x_REG, read_sysreg_s, and finally to __mrs_s where it is string-ified and used directly in inline asm. Regardless of which compiler or compiler options determine whether a loop can or can't be unrolled, which determines whether __builtin_constant_p evaluates to true when passed an expression using a loop induction variable, it is NEVER safe to allow the preprocessor to construct inline asm like: asm volatile (".inst (0x160 + (i * 4))" : "=r"(__val)); ^ expected constant expression Instead of read_etm4x_sysreg_offset() using __builtin_constant_p(), use __is_constexpr from include/linux/const.h instead to ensure only expressions that are valid integer constant expressions get passed through to read_sysreg_s(). This is not a bug in clang; it's a potentially unsafe use of the macro arguments in read_etm4x_sysreg_offset dependent on __builtin_constant_p. Link: ClangBuiltLinux#1310 Reported-by: Arnd Bergmann <[email protected]> Reported-by: Tao Zhang <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Suzuki K Poulose <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 1693fe9 - Browse repository at this point
Copy the full SHA 1693fe9View commit details -
habanalabs/gaudi: fix shift out of bounds
[ Upstream commit 0162209 ] When validating NIC queues, queue offset calculation must be performed only for NIC queues. Signed-off-by: Ofir Bitton <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for b09e5ab - Browse repository at this point
Copy the full SHA b09e5abView commit details -
habanalabs/gaudi: mask constant value before cast
[ Upstream commit e3f4943 ] This fixes a sparse warning of "cast truncates bits from constant value" Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 0f59165 - Browse repository at this point
Copy the full SHA 0f59165View commit details -
mmc: tmio: avoid glitches when resetting
[ Upstream commit 2e586f8 ] If we reset because of an error, we need to preserve values for the clock frequency. Otherwise, glitches may be seen on the bus. To achieve that, we introduce a 'preserve' parameter to the reset function and the IP core specific reset callbacks to handle everything accordingly. Reported-by: Yoshihiro Shimoda <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Tested-by: Yoshihiro Shimoda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 67b5870 - Browse repository at this point
Copy the full SHA 67b5870View commit details -
pinctrl: intel: Check against matching data instead of ACPI companion
[ Upstream commit c551bd8 ] In some cases we may get a platform device that has ACPI companion which is different to the pin control described in the ACPI tables. This is primarily happens when device is instantiated by board file. In order to allow this device being enumerated, refactor intel_pinctrl_get_soc_data() to check the matching data instead of ACPI companion. Reported-by: Henning Schild <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Tested-by: Henning Schild <[email protected]> Acked-by: Hans de Goede <[email protected]> Acked-by: Mika Westerberg <[email protected]> Acked-by: Linus Walleij <[email protected]> Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 5e24cd7 - Browse repository at this point
Copy the full SHA 5e24cd7View commit details -
cxl: Fix a memory leak in an error handling path
[ Upstream commit 3a15b45 ] A bitmap_zalloc() must be balanced by a corresponding bitmap_free() in the error handling path of afu_allocate_irqs(). Acked-by: Andrew Donnellan <[email protected]> Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/ce5869418f5838187946eb6b11a52715a93ece3d.1657566849.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for addff63 - Browse repository at this point
Copy the full SHA addff63View commit details -
PCI/ACPI: Guard ARM64-specific mcfg_quirks
[ Upstream commit 40a6cc1 ] Guard ARM64-specific quirks with CONFIG_ARM64 to avoid build errors, since mcfg_quirks will be shared by more than one architectures. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 405f655 - Browse repository at this point
Copy the full SHA 405f655View commit details -
um: add "noreboot" command line option for PANIC_TIMEOUT=-1 setups
[ Upstream commit dda520d ] QEMU has a -no-reboot option, which halts instead of reboots when the guest asks to reboot. This is invaluable when used with CONFIG_PANIC_TIMEOUT=-1 (and panic_on_warn), because it allows panics and warnings to be caught immediately in CI. Implement this in UML too, by way of a basic setup param. Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for e799817 - Browse repository at this point
Copy the full SHA e799817View commit details -
dmaengine: dw-axi-dmac: do not print NULL LLI during error
[ Upstream commit 86cb0de ] During debugging we have seen an issue where axi_chan_dump_lli() is passed a NULL LLI pointer which ends up causing an OOPS due to trying to get fields from it. Simply print NULL LLI and exit to avoid this. Signed-off-by: Ben Dooks <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for af76e6f - Browse repository at this point
Copy the full SHA af76e6fView commit details -
dmaengine: dw-axi-dmac: ignore interrupt if no descriptor
[ Upstream commit 820f5ce ] If the channel has no descriptor and the interrupt is raised then the kernel will OOPS. Check the result of vchan_next_desc() in the handler axi_chan_block_xfer_complete() to avoid the error happening. Signed-off-by: Ben Dooks <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 54aa6c4 - Browse repository at this point
Copy the full SHA 54aa6c4View commit details -
RDMA/rxe: Limit the number of calls to each tasklet
[ Upstream commit eff6d99 ] Limit the maximum number of calls to each tasklet from rxe_do_task() before yielding the cpu. When the limit is reached reschedule the tasklet and exit the calling loop. This patch prevents one tasklet from consuming 100% of a cpu core and causing a deadlock or soft lockup. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bob Pearson <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for fda4bff - Browse repository at this point
Copy the full SHA fda4bffView commit details -
csky/kprobe: reclaim insn_slot on kprobe unregistration
[ Upstream commit a2310c7 ] On kprobe registration kernel allocate one insn_slot for new kprobe, but it forget to reclaim the insn_slot on unregistration, leading to a potential leakage. Reported-by: Chen Guokai <[email protected]> Reviewed-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Liao Chang <[email protected]> Signed-off-by: Guo Ren <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 3645ed6 - Browse repository at this point
Copy the full SHA 3645ed6View commit details -
selftests/kprobe: Do not test for GRP/ without event failures
[ Upstream commit f5eab65 ] A new feature is added where kprobes (and other probes) do not need to explicitly state the event name when creating a probe. The event name will come from what is being attached. That is: # echo 'p:foo/ vfs_read' > kprobe_events Will no longer error, but instead create an event: # cat kprobe_events p:foo/p_vfs_read_0 vfs_read This should not be tested as an error case anymore. Remove it from the selftest as now this feature "breaks" the selftest as it no longer fails as expected. Link: https://lore.kernel.org/all/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for d0e2b8e - Browse repository at this point
Copy the full SHA d0e2b8eView commit details -
dmaengine: sprd: Cleanup in .remove() after pm_runtime_get_sync() failed
[ Upstream commit 1e42f82 ] It's not allowed to quit remove early without cleaning up completely. Otherwise this results in resource leaks that probably yield graver problems later. Here for example some tasklets might survive the lifetime of the sprd-dma device and access sdev which is freed after .remove() returns. As none of the device freeing requires an active device, just ignore the return value of pm_runtime_get_sync(). Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Baolin Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for d1fc64b - Browse repository at this point
Copy the full SHA d1fc64bView commit details -
openrisc: io: Define iounmap argument as volatile
[ Upstream commit 52e0ea9 ] When OpenRISC enables PCI it allows for more drivers to be compiled resulting in exposing the following with -Werror. drivers/video/fbdev/riva/fbdev.c: In function 'rivafb_probe': drivers/video/fbdev/riva/fbdev.c:2062:42: error: passing argument 1 of 'iounmap' discards 'volatile' qualifier from pointer target type drivers/video/fbdev/nvidia/nvidia.c: In function 'nvidiafb_probe': drivers/video/fbdev/nvidia/nvidia.c:1414:20: error: passing argument 1 of 'iounmap' discards 'volatile' qualifier from pointer target type drivers/scsi/aic7xxx/aic7xxx_osm.c: In function 'ahc_platform_free': drivers/scsi/aic7xxx/aic7xxx_osm.c:1231:41: error: passing argument 1 of 'iounmap' discards 'volatile' qualifier from pointer target type Most architectures define the iounmap argument to be volatile. To fix this issue we do the same for OpenRISC. This patch must go before PCI is enabled on OpenRISC to avoid any compile failures. Link: https://lore.kernel.org/lkml/[email protected]/ Reported-by: Guenter Roeck <[email protected]> Tested-by: Guenter Roeck <[email protected]> Signed-off-by: Stafford Horne <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 405ea6d - Browse repository at this point
Copy the full SHA 405ea6dView commit details -
phy: samsung: phy-exynos-pcie: sanitize init/power_on callbacks
[ Upstream commit f281222 ] The exynos-pcie driver called phy_power_on() before phy_init() for some historical reasons. However the generic PHY framework assumes that the proper sequence is to call phy_init() first, then phy_power_on(). The operations done by both functions should be considered as one action and as such they are called by the exynos-pcie driver (without doing anything between them). The initialization is just a sequence of register writes, which cannot be altered without breaking the hardware operation. To match the generic PHY framework requirement, simply move all register writes to the phy_init()/phy_exit() and drop power_on()/power_off() callbacks. This way the driver will also work with the old (incorrect) PHY initialization call sequence. Link: https://lore.kernel.org/r/[email protected] Reported-by: Bjorn Helgaas <[email protected]> Signed-off-by: Marek Szyprowski <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Chanho Park <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Acked-By: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 2dc9615 - Browse repository at this point
Copy the full SHA 2dc9615View commit details -
md: Notify sysfs sync_completed in md_reap_sync_thread()
[ Upstream commit 9973f0f ] The mdadm test 07layouts randomly produces a kernel hung task deadlock. The deadlock is caused by the suspend_lo/suspend_hi files being set by the mdadm background process during reshape and not being cleared because the process hangs. (Leaving aside the issue of the fragility of freezing kernel tasks by buggy userspace processes...) When the background mdadm process hangs it, is waiting (without a timeout) on a change to the sync_completed file signalling that the reshape has completed. The process is woken up a couple times when the reshape finishes but it is woken up before MD_RECOVERY_RUNNING is cleared so sync_completed_show() reports 0 instead of "none". To fix this, notify the sysfs file in md_reap_sync_thread() after MD_RECOVERY_RUNNING has been cleared. This wakes up mdadm and causes it to continue and write to suspend_lo/suspend_hi to allow IO to continue. Signed-off-by: Logan Gunthorpe <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Song Liu <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for e59ef9b - Browse repository at this point
Copy the full SHA e59ef9bView commit details -
nvmet-tcp: fix lockdep complaint on nvmet_tcp_wq flush during queue t…
…eardown [ Upstream commit 533d2e8 ] We probably need nvmet_tcp_wq to have MEM_RECLAIM as we are sending/receiving for the socket from works on this workqueue. Also this eliminates lockdep complaints: -- [ 6174.010200] workqueue: WQ_MEM_RECLAIM nvmet-wq:nvmet_tcp_release_queue_work [nvmet_tcp] is flushing !WQ_MEM_RECLAIM nvmet_tcp_wq:nvmet_tcp_io_work [nvmet_tcp] [ 6174.010216] WARNING: CPU: 20 PID: 14456 at kernel/workqueue.c:2628 check_flush_dependency+0x110/0x14c Reported-by: Yi Zhang <[email protected]> Signed-off-by: Sagi Grimberg <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for a600ed2 - Browse repository at this point
Copy the full SHA a600ed2View commit details -
drivers:md:fix a potential use-after-free bug
[ Upstream commit 1042124 ] In line 2884, "raid5_release_stripe(sh);" drops the reference to sh and may cause sh to be released. However, sh is subsequently used in lines 2886 "if (sh->batch_head && sh != sh->batch_head)". This may result in an use-after-free bug. It can be fixed by moving "raid5_release_stripe(sh);" to the bottom of the function. Signed-off-by: Wentao_Liang <[email protected]> Signed-off-by: Song Liu <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for d9b94c3 - Browse repository at this point
Copy the full SHA d9b94c3View commit details -
ext4: avoid remove directory when directory is corrupted
[ Upstream commit b24e77e ] Now if check directoy entry is corrupted, ext4_empty_dir may return true then directory will be removed when file system mounted with "errors=continue". In order not to make things worse just return false when directory is corrupted. Signed-off-by: Ye Bin <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 0e734f9 - Browse repository at this point
Copy the full SHA 0e734f9View commit details -
ext4: avoid resizing to a partial cluster size
[ Upstream commit 69cb8e9 ] This patch avoids an attempt to resize the filesystem to an unaligned cluster boundary. An online resize to a size that is not integral to cluster size results in the last iteration attempting to grow the fs by a negative amount, which trips a BUG_ON and leaves the fs with a corrupted in-memory superblock. Signed-off-by: Oleg Kiselev <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 72b850a - Browse repository at this point
Copy the full SHA 72b850aView commit details -
lib/list_debug.c: Detect uninitialized lists
[ Upstream commit 0cc011c ] In some circumstances, attempts are made to add entries to or to remove entries from an uninitialized list. A prime example is amdgpu_bo_vm_destroy(): It is indirectly called from ttm_bo_init_reserved() if that function fails, and tries to remove an entry from a list. However, that list is only initialized in amdgpu_bo_create_vm() after the call to ttm_bo_init_reserved() returned success. This results in crashes such as BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [Freescale#1] PREEMPT SMP NOPTI CPU: 1 PID: 1479 Comm: chrome Not tainted 5.10.110-15768-g29a72e65dae5 Hardware name: Google Grunt/Grunt, BIOS Google_Grunt.11031.149.0 07/15/2020 RIP: 0010:__list_del_entry_valid+0x26/0x7d ... Call Trace: amdgpu_bo_vm_destroy+0x48/0x8b ttm_bo_init_reserved+0x1d7/0x1e0 amdgpu_bo_create+0x212/0x476 ? amdgpu_bo_user_destroy+0x23/0x23 ? kmem_cache_alloc+0x60/0x271 amdgpu_bo_create_vm+0x40/0x7d amdgpu_vm_pt_create+0xe8/0x24b ... Check if the list's prev and next pointers are NULL to catch such problems. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Cc: Steven Rostedt <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for ce0432a - Browse repository at this point
Copy the full SHA ce0432aView commit details -
tty: serial: Fix refcount leak bug in ucc_uart.c
[ Upstream commit d24d7bb ] In soc_info(), of_find_node_by_type() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore. Acked-by: Timur Tabi <[email protected]> Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 17c3254 - Browse repository at this point
Copy the full SHA 17c3254View commit details -
KVM: PPC: Book3S HV: Fix "rm_exit" entry in debugfs timings
[ Upstream commit 9981bac ] At debugfs/kvm/<pid>/vcpu0/timings we show how long each part of the code takes to run: $ cat /sys/kernel/debug/kvm/*-*/vcpu0/timings rm_entry: 123785 49398892 118 4898 rm_intr: 123780 6075890 22 390 rm_exit: 0 0 0 0 <-- NOK guest: 123780 46732919988 402 9997638 cede: 0 0 0 0 <-- OK, no cede napping in P9 The "rm_exit" is always showing zero because it is the last one and end_timing does not increment the counter of the previous entry. We can fix it by calling accumulate_time again instead of end_timing. That way the counter gets incremented. The rest of the arithmetic can be ignored because there are no timing points after this and the accumulators are reset before the next round. Signed-off-by: Fabiano Rosas <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for a1d8021 - Browse repository at this point
Copy the full SHA a1d8021View commit details -
vfio: Clear the caps->buf to NULL after free
[ Upstream commit 6641085 ] On buffer resize failure, vfio_info_cap_add() will free the buffer, report zero for the size, and return -ENOMEM. As additional hardening, also clear the buffer pointer to prevent any chance of a double free. Signed-off-by: Schspa Shi <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for c983edb - Browse repository at this point
Copy the full SHA c983edbView commit details -
mips: cavium-octeon: Fix missing of_node_put() in octeon2_usb_clocks_…
…start [ Upstream commit 7a9f743 ] We should call of_node_put() for the reference 'uctl_node' returned by of_get_parent() which will increase the refcount. Otherwise, there will be a refcount leak bug. Signed-off-by: Liang He <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 7822d99 - Browse repository at this point
Copy the full SHA 7822d99View commit details -
iommu/io-pgtable-arm-v7s: Add a quirk to allow pgtable PA up to 35bit
[ Upstream commit bfdd231 ] Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA and cause pgtable PA size larger than 32bit. Since Mediatek IOMMU hardware support at most 35bit PA in pgtable, so add a quirk to allow the PA of pgtables support up to bit35. Signed-off-by: Ning Li <[email protected]> Signed-off-by: Yunfei Wang <[email protected]> Reviewed-by: Robin Murphy <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 2097c78 - Browse repository at this point
Copy the full SHA 2097c78View commit details -
modules: Ensure natural alignment for .altinstructions and __bug_tabl…
…e sections [ Upstream commit 87c482b ] In the kernel image vmlinux.lds.S linker scripts the .altinstructions and __bug_table sections are 4- or 8-byte aligned because they hold 32- and/or 64-bit values. Most architectures use altinstructions and BUG() or WARN() in modules as well, but in the module linker script (module.lds.S) those sections are currently missing. As consequence the linker will store their content byte-aligned by default, which then can lead to unnecessary unaligned memory accesses by the CPU when those tables are processed at runtime. Usually unaligned memory accesses are unnoticed, because either the hardware (as on x86 CPUs) or in-kernel exception handlers (e.g. on parisc or sparc) emulate and fix them up at runtime. Nevertheless, such unaligned accesses introduce a performance penalty and can even crash the kernel if there is a bug in the unalignment exception handlers (which happened once to me on the parisc architecture and which is why I noticed that issue at all). This patch fixes a non-critical issue and might be backported at any time. It's trivial and shouldn't introduce any regression because it simply tells the linker to use a different (8-byte alignment) for those sections by default. Signed-off-by: Helge Deller <[email protected]> Link: https://lore.kernel.org/all/Yr8%2Fgr8e8I7tVX4d@p100/ Signed-off-by: Luis Chamberlain <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 9774b96 - Browse repository at this point
Copy the full SHA 9774b96View commit details -
ASoC: rsnd: care default case on rsnd_ssiu_busif_err_irq_ctrl()
[ Upstream commit ef30911 ] Before, ssiu.c didn't care SSI5-8, thus, commit b1384d4 ("ASoC: rsnd: care default case on rsnd_ssiu_busif_err_status_clear()") cares it for status clear. But we should care it for error irq handling, too. This patch cares it. Reported-by: Nguyen Bao Nguyen <[email protected]> Reported-by: Nishiyama Kunihiko <[email protected]> Signed-off-by: Kuninori Morimoto <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 21d7843 - Browse repository at this point
Copy the full SHA 21d7843View commit details -
riscv: dts: sifive: Add fu740 topology information
[ Upstream commit bf6cd1c ] The fu740 has no cpu-map node, so tools like hwloc cannot correctly parse the topology. Add the node using the existing node labels. Reported-by: Brice Goglin <[email protected]> Link: open-mpi/hwloc#536 Signed-off-by: Conor Dooley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 2306947 - Browse repository at this point
Copy the full SHA 2306947View commit details -
riscv: dts: canaan: Add k210 topology information
[ Upstream commit d9d193d ] The k210 has no cpu-map node, so tools like hwloc cannot correctly parse the topology. Add the node using the existing node labels. Reported-by: Brice Goglin <[email protected]> Link: open-mpi/hwloc#536 Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for e751030 - Browse repository at this point
Copy the full SHA e751030View commit details -
riscv: mmap with PROT_WRITE but no PROT_READ is invalid
[ Upstream commit 2139619 ] As mentioned in Table 4.5 in RISC-V spec Volume 2 Section 4.3, write but not read is "Reserved for future use.". For now, they are not valid. In the current code, -wx is marked as invalid, but -w- is not marked as invalid. This patch refines that judgment. Reported-by: xctan <[email protected]> Co-developed-by: dram <[email protected]> Signed-off-by: dram <[email protected]> Co-developed-by: Ruizhe Pan <[email protected]> Signed-off-by: Ruizhe Pan <[email protected]> Signed-off-by: Celeste Liu <[email protected]> Link: https://lore.kernel.org/r/PH7PR14MB559464DBDD310E755F5B21E8CEDC9@PH7PR14MB5594.namprd14.prod.outlook.com Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 64f94e6 - Browse repository at this point
Copy the full SHA 64f94e6View commit details -
RISC-V: Add fast call path of crash_kexec()
[ Upstream commit 3f19011 ] Currently, almost all archs (x86, arm64, mips...) support fast call of crash_kexec() when "regs && kexec_should_crash()" is true. But RISC-V not, it can only enter crash system via panic(). However panic() doesn't pass the regs of the real accident scene to crash_kexec(), it caused we can't get accurate backtrace via gdb, $ riscv64-linux-gnu-gdb vmlinux vmcore Reading symbols from vmlinux... [New LWP 95] #0 console_unlock () at kernel/printk/printk.c:2557 2557 if (do_cond_resched) (gdb) bt #0 console_unlock () at kernel/printk/printk.c:2557 Freescale#1 0x0000000000000000 in ?? () With the patch we can get the accurate backtrace, $ riscv64-linux-gnu-gdb vmlinux vmcore Reading symbols from vmlinux... [New LWP 95] #0 0xffffffe00063a4e0 in test_thread (data=<optimized out>) at drivers/test_crash.c:81 81 *(int *)p = 0xdead; (gdb) (gdb) bt #0 0xffffffe00064d5c0 in test_thread (data=<optimized out>) at drivers/test_crash.c:81 Freescale#1 0x0000000000000000 in ?? () Test code to produce NULL address dereference in test_crash.c, void *p = NULL; *(int *)p = 0xdead; Reviewed-by: Guo Ren <[email protected]> Tested-by: Xianting Tian <[email protected]> Signed-off-by: Xianting Tian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for c5a8d05 - Browse repository at this point
Copy the full SHA c5a8d05View commit details -
watchdog: export lockup_detector_reconfigure
[ Upstream commit 7c56a87 ] In some circumstances it may be interesting to reconfigure the watchdog from inside the kernel. On PowerPC, this may helpful before and after a LPAR migration (LPM) is initiated, because it implies some latencies, watchdog, and especially NMI watchdog is expected to be triggered during this operation. Reconfiguring the watchdog with a factor, would prevent it to happen too frequently during LPM. Rename lockup_detector_reconfigure() as __lockup_detector_reconfigure() and create a new function lockup_detector_reconfigure() calling __lockup_detector_reconfigure() under the protection of watchdog_mutex. Signed-off-by: Laurent Dufour <[email protected]> [mpe: Squash in build fix from Laurent, reported by Sachin] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 6568e52 - Browse repository at this point
Copy the full SHA 6568e52View commit details -
powerpc/32: Set an IBAT covering up to _einittext during init
[ Upstream commit 2a0fb3c ] Always set an IBAT covering up to _einittext during init because when CONFIG_MODULES is not selected there is no reason to have an exception handler for kernel instruction TLB misses. It implies DBAT and IBAT are now totaly independent, IBATs are set by setibat() and DBAT by setbat(). This allows to revert commit 9bb162f ("powerpc/603: Fix boot failure with DEBUG_PAGEALLOC and KFENCE") Reported-by: Maxime Bizon <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/ce7f04a39593934d9b1ee68c69144ccd3d4da4a1.1655202804.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 3d5d2dc - Browse repository at this point
Copy the full SHA 3d5d2dcView commit details -
powerpc/32: Don't always pass -mcpu=powerpc to the compiler
[ Upstream commit 446cda1 ] Since commit 4bf4f42 ("powerpc/kbuild: Set default generic machine type for 32-bit compile"), when building a 32 bits kernel with a bi-arch version of GCC, or when building a book3s/32 kernel, the option -mcpu=powerpc is passed to GCC at all time, relying on it being eventually overriden by a subsequent -mcpu=xxxx. But when building the same kernel with a 32 bits only version of GCC, that is not done, relying on gcc being built with the expected default CPU. This logic has two problems. First, it is a bit fragile to rely on whether the GCC version is bi-arch or not, because today we can have bi-arch versions of GCC configured with a 32 bits default. Second, there are some versions of GCC which don't support -mcpu=powerpc, for instance for e500 SPE-only versions. So, stop relying on this approximative logic and allow the user to decide whether he/she wants to use the toolchain's default CPU or if he/she wants to set one, and allow only possible CPUs based on the selected target. Reported-by: Pali Rohár <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Tested-by: Pali Rohár <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Reviewed-by: Segher Boessenkool <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/d4df724691351531bf46d685d654689e5dfa0d74.1657549153.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 0480540 - Browse repository at this point
Copy the full SHA 0480540View commit details -
ovl: warn if trusted xattr creation fails
[ Upstream commit b10b85f ] When mounting overlayfs in an unprivileged user namespace, trusted xattr creation will fail. This will lead to failures in some file operations, e.g. in the following situation: mkdir lower upper work merged mkdir lower/directory mount -toverlay -olowerdir=lower,upperdir=upper,workdir=work none merged rmdir merged/directory mkdir merged/directory The last mkdir will fail: mkdir: cannot create directory 'merged/directory': Input/output error The cause for these failures is currently extremely non-obvious and hard to debug. Hence, warn the user and suggest using the userxattr mount option, if it is not already supplied and xattr creation fails during the self-check. Reported-by: Alois Wohlschlager <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 8641e0b - Browse repository at this point
Copy the full SHA 8641e0bView commit details -
powerpc/ioda/iommu/debugfs: Generate unique debugfs entries
[ Upstream commit d73b46c ] The iommu_table::it_index is a LIOBN which is not initialized on PowerNV as it is not used except IOMMU debugfs where it is used for a node name. This initializes it_index witn a unique number to avoid warnings and have a node for every iommu_table. This should not cause any behavioral change without CONFIG_IOMMU_DEBUGFS. Signed-off-by: Alexey Kardashevskiy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for a5ec4cd - Browse repository at this point
Copy the full SHA a5ec4cdView commit details -
ALSA: core: Add async signal helpers
[ Upstream commit ef34a0a ] Currently the call of kill_fasync() from an interrupt handler might lead to potential spin deadlocks, as spotted by syzkaller. Unfortunately, it's not so trivial to fix this lock chain as it's involved with the tasklist_lock that is touched in allover places. As a temporary workaround, this patch provides the way to defer the async signal notification in a work. The new helper functions, snd_fasync_helper() and snd_kill_faync() are replacements for fasync_helper() and kill_fasync(), respectively. In addition, snd_fasync_free() needs to be called at the destructor of the relevant file object. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 60110fd - Browse repository at this point
Copy the full SHA 60110fdView commit details -
ALSA: timer: Use deferred fasync helper
[ Upstream commit 95cc637 ] For avoiding the potential deadlock via kill_fasync() call, use the new fasync helpers to defer the invocation from PCI API. Note that it's merely a workaround. Reported-by: [email protected] Reported-by: [email protected] Reported-by: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 409e6a7 - Browse repository at this point
Copy the full SHA 409e6a7View commit details -
ALSA: control: Use deferred fasync helper
[ Upstream commit 4a971e8 ] For avoiding the potential deadlock via kill_fasync() call, use the new fasync helpers to defer the invocation from the control API. Note that it's merely a workaround. Another note: although we haven't received reports about the deadlock with the control API, the deadlock is still potentially possible, and it's better to align the behavior with other core APIs (PCM and timer); so let's move altogether. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 3895d35 - Browse repository at this point
Copy the full SHA 3895d35View commit details -
f2fs: fix to avoid use f2fs_bug_on() in f2fs_new_node_page()
[ Upstream commit 141170b ] As Dipanjan Das <[email protected]> reported, syzkaller found a f2fs bug as below: RIP: 0010:f2fs_new_node_page+0x19ac/0x1fc0 fs/f2fs/node.c:1295 Call Trace: write_all_xattrs fs/f2fs/xattr.c:487 [inline] __f2fs_setxattr+0xe76/0x2e10 fs/f2fs/xattr.c:743 f2fs_setxattr+0x233/0xab0 fs/f2fs/xattr.c:790 f2fs_xattr_generic_set+0x133/0x170 fs/f2fs/xattr.c:86 __vfs_setxattr+0x115/0x180 fs/xattr.c:182 __vfs_setxattr_noperm+0x125/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1cf/0x260 fs/xattr.c:277 vfs_setxattr+0x13f/0x330 fs/xattr.c:303 setxattr+0x146/0x160 fs/xattr.c:611 path_setxattr+0x1a7/0x1d0 fs/xattr.c:630 __do_sys_lsetxattr fs/xattr.c:653 [inline] __se_sys_lsetxattr fs/xattr.c:649 [inline] __x64_sys_lsetxattr+0xbd/0x150 fs/xattr.c:649 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 NAT entry and nat bitmap can be inconsistent, e.g. one nid is free in nat bitmap, and blkaddr in its NAT entry is not NULL_ADDR, it may trigger BUG_ON() in f2fs_new_node_page(), fix it. Reported-by: Dipanjan Das <[email protected]> Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 5a01e45 - Browse repository at this point
Copy the full SHA 5a01e45View commit details -
f2fs: fix to do sanity check on segment type in build_sit_entries()
[ Upstream commit 09beadf ] As Wenqing Liu <[email protected]> reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216285 RIP: 0010:memcpy_erms+0x6/0x10 f2fs_update_meta_page+0x84/0x570 [f2fs] change_curseg.constprop.0+0x159/0xbd0 [f2fs] f2fs_do_replace_block+0x5c7/0x18a0 [f2fs] f2fs_replace_block+0xeb/0x180 [f2fs] recover_data+0x1abd/0x6f50 [f2fs] f2fs_recover_fsync_data+0x12ce/0x3250 [f2fs] f2fs_fill_super+0x4459/0x6190 [f2fs] mount_bdev+0x2cf/0x3b0 legacy_get_tree+0xed/0x1d0 vfs_get_tree+0x81/0x2b0 path_mount+0x47e/0x19d0 do_mount+0xce/0xf0 __x64_sys_mount+0x12c/0x1a0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The root cause is segment type is invalid, so in f2fs_do_replace_block(), f2fs accesses f2fs_sm_info::curseg_array with out-of-range segment type, result in accessing invalid curseg->sum_blk during memcpy in f2fs_update_meta_page(). Fix this by adding sanity check on segment type in build_sit_entries(). Reported-by: Wenqing Liu <[email protected]> Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 3c20113 - Browse repository at this point
Copy the full SHA 3c20113View commit details -
smb3: check xattr value length earlier
[ Upstream commit 5fa2cff ] Coverity complains about assigning a pointer based on value length before checking that value length goes beyond the end of the SMB. Although this is even more unlikely as value length is a single byte, and the pointer is not dereferenced until laterm, it is clearer to check the lengths first. Addresses-Coverity: 1467704 ("Speculative execution data leak") Reviewed-by: Ronnie Sahlberg <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for ecdba23 - Browse repository at this point
Copy the full SHA ecdba23View commit details -
powerpc/64: Init jump labels before parse_early_param()
[ Upstream commit ca829e0 ] On 64-bit, calling jump_label_init() in setup_feature_keys() is too late because static keys may be used in subroutines of parse_early_param() which is again subroutine of early_init_devtree(). For example booting with "threadirqs": static_key_enable_cpuslocked(): static key '0xc000000002953260' used before call to jump_label_init() WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120 ... NIP static_key_enable_cpuslocked+0xfc/0x120 LR static_key_enable_cpuslocked+0xf8/0x120 Call Trace: static_key_enable_cpuslocked+0xf8/0x120 (unreliable) static_key_enable+0x30/0x50 setup_forced_irqthreads+0x28/0x40 do_early_param+0xa0/0x108 parse_args+0x290/0x4e0 parse_early_options+0x48/0x5c parse_early_param+0x58/0x84 early_init_devtree+0xd4/0x518 early_setup+0xb4/0x214 So call jump_label_init() just before parse_early_param() in early_init_devtree(). Suggested-by: Michael Ellerman <[email protected]> Signed-off-by: Zhouyi Zhou <[email protected]> [mpe: Add call trace to change log and minor wording edits.] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for e3c9e94 - Browse repository at this point
Copy the full SHA e3c9e94View commit details -
venus: pm_helpers: Fix warning in OPP during probe
[ Upstream commit 1d95af0 ] Fix the following WARN triggered during Venus driver probe on 5.19.0-rc8-next-20220728: WARNING: CPU: 7 PID: 339 at drivers/opp/core.c:2471 dev_pm_opp_set_config+0x49c/0x610 Modules linked in: qcom_spmi_adc5 rtc_pm8xxx qcom_spmi_adc_tm5 leds_qcom_lpg led_class_multicolor qcom_pon qcom_vadc_common venus_core(+) qcom_spmi_temp_alarm v4l2_mem2mem videobuf2_v4l2 msm(+) videobuf2_common crct10dif_ce spi_geni_qcom snd_soc_sm8250 i2c_qcom_geni gpu_sched snd_soc_qcom_common videodev qcom_q6v5_pas soundwire_qcom drm_dp_aux_bus qcom_stats drm_display_helper qcom_pil_info soundwire_bus snd_soc_lpass_va_macro mc qcom_q6v5 phy_qcom_snps_femto_v2 qcom_rng snd_soc_lpass_macro_common snd_soc_lpass_wsa_macro lpass_gfm_sm8250 slimbus qcom_sysmon qcom_common qcom_glink_smem qmi_helpers qcom_wdt mdt_loader socinfo icc_osm_l3 display_connector drm_kms_helper qnoc_sm8250 drm fuse ip_tables x_tables ipv6 CPU: 7 PID: 339 Comm: systemd-udevd Not tainted 5.19.0-rc8-next-20220728 Freescale#4 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : dev_pm_opp_set_config+0x49c/0x610 lr : dev_pm_opp_set_config+0x58/0x610 sp : ffff8000093c3710 x29: ffff8000093c3710 x28: ffffbca3959d82b8 x27: ffff8000093c3d00 x26: ffffbca3959d8e08 x25: ffff4396cac98118 x24: ffff4396c0e24810 x23: ffff4396c4272c40 x22: ffff4396c0e24810 x21: ffff8000093c3810 x20: ffff4396cac36800 x19: ffff4396cac96800 x18: 0000000000000000 x17: 0000000000000003 x16: ffffbca3f4edf198 x15: 0000001cba64a858 x14: 0000000000000180 x13: 000000000000017e x12: 0000000000000000 x11: 0000000000000002 x10: 0000000000000a60 x9 : ffff8000093c35c0 x8 : ffff4396c4273700 x7 : ffff43983efca6c0 x6 : ffff43983efca640 x5 : 00000000410fd0d0 x4 : ffff4396c4272c40 x3 : ffffbca3f5d1e008 x2 : 0000000000000000 x1 : ffff4396c2421600 x0 : ffff4396cac96860 Call trace: dev_pm_opp_set_config+0x49c/0x610 devm_pm_opp_set_config+0x18/0x70 vcodec_domains_get+0xb8/0x1638 [venus_core] core_get_v4+0x1d8/0x218 [venus_core] venus_probe+0xf4/0x468 [venus_core] platform_probe+0x68/0xd8 really_probe+0xbc/0x2a8 __driver_probe_device+0x78/0xe0 driver_probe_device+0x3c/0xf0 __driver_attach+0x70/0x120 bus_for_each_dev+0x70/0xc0 driver_attach+0x24/0x30 bus_add_driver+0x150/0x200 driver_register+0x64/0x120 __platform_driver_register+0x28/0x38 qcom_venus_driver_init+0x24/0x1000 [venus_core] do_one_initcall+0x54/0x1c8 do_init_module+0x44/0x1d0 load_module+0x16c8/0x1aa0 __do_sys_finit_module+0xbc/0x110 __arm64_sys_finit_module+0x20/0x30 invoke_syscall+0x44/0x108 el0_svc_common.constprop.0+0xcc/0xf0 do_el0_svc+0x2c/0xb8 el0_svc+0x2c/0x88 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x18c/0x190 qcom-venus: probe of aa00000.video-codec failed with error -16 The fix is re-ordering the code related to OPP core. The OPP core expects all configuration options to be provided before the OPP table is added. Reported-by: Linux Kernel Functional Testing <[email protected]> Suggested-by: Viresh Kumar <[email protected]> Signed-off-by: Stanimir Varbanov <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 0bdec5e - Browse repository at this point
Copy the full SHA 0bdec5eView commit details -
video: fbdev: i740fb: Check the argument of i740_calc_vclk()
[ Upstream commit 40bf722 ] Since the user can control the arguments of the ioctl() from the user space, under special arguments that may result in a divide-by-zero bug. If the user provides an improper 'pixclock' value that makes the argumet of i740_calc_vclk() less than 'I740_RFREQ_FIX', it will cause a divide-by-zero bug in: drivers/video/fbdev/i740fb.c:353 p_best = min(15, ilog2(I740_MAX_VCO_FREQ / (freq / I740_RFREQ_FIX))); The following log can reveal it: divide error: 0000 [Freescale#1] PREEMPT SMP KASAN PTI RIP: 0010:i740_calc_vclk drivers/video/fbdev/i740fb.c:353 [inline] RIP: 0010:i740fb_decode_var drivers/video/fbdev/i740fb.c:646 [inline] RIP: 0010:i740fb_set_par+0x163f/0x3b70 drivers/video/fbdev/i740fb.c:742 Call Trace: fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Fix this by checking the argument of i740_calc_vclk() first. Signed-off-by: Zheyu Ma <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for e740e78 - Browse repository at this point
Copy the full SHA e740e78View commit details -
MIPS: tlbex: Explicitly compare _PAGE_NO_EXEC against 0
[ Upstream commit 74de14f ] When CONFIG_XPA is enabled, Clang warns: arch/mips/mm/tlbex.c:629:24: error: converting the result of '<<' to a boolean; did you mean '(1 << _PAGE_NO_EXEC_SHIFT) != 0'? [-Werror,-Wint-in-bool-context] if (cpu_has_rixi && !!_PAGE_NO_EXEC) { ^ arch/mips/include/asm/pgtable-bits.h:174:28: note: expanded from macro '_PAGE_NO_EXEC' # define _PAGE_NO_EXEC (1 << _PAGE_NO_EXEC_SHIFT) ^ arch/mips/mm/tlbex.c:2568:24: error: converting the result of '<<' to a boolean; did you mean '(1 << _PAGE_NO_EXEC_SHIFT) != 0'? [-Werror,-Wint-in-bool-context] if (!cpu_has_rixi || !_PAGE_NO_EXEC) { ^ arch/mips/include/asm/pgtable-bits.h:174:28: note: expanded from macro '_PAGE_NO_EXEC' # define _PAGE_NO_EXEC (1 << _PAGE_NO_EXEC_SHIFT) ^ 2 errors generated. _PAGE_NO_EXEC can be '0' or '1 << _PAGE_NO_EXEC_SHIFT' depending on the build and runtime configuration, which is what the negation operators are trying to convey. To silence the warning, explicitly compare against 0 so the result of the '<<' operator is not implicitly converted to a boolean. According to its documentation, GCC enables -Wint-in-bool-context with -Wall but this warning is not visible when building the same configuration with GCC. It appears GCC only warns when compiling C++, not C, although the documentation makes no note of this: https://godbolt.org/z/x39q3brxf Reported-by: Sudip Mukherjee (Codethink) <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for e740363 - Browse repository at this point
Copy the full SHA e740363View commit details -
can: j1939: j1939_sk_queue_activate_next_locked(): replace WARN_ON_ON…
…CE with netdev_warn_once() commit 8ef49f7 upstream. We should warn user-space that it is doing something wrong when trying to activate sessions with identical parameters but WARN_ON_ONCE macro can not be used here as it serves a different purpose. So it would be good to replace it with netdev_warn_once() message. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 9d71dd0 ("can: add support of SAE J1939 protocol") Signed-off-by: Fedor Pchelkin <[email protected]> Signed-off-by: Alexey Khoroshilov <[email protected]> Acked-by: Oleksij Rempel <[email protected]> Link: https://lore.kernel.org/all/[email protected] [mkl: fix indention] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 1a9f541 - Browse repository at this point
Copy the full SHA 1a9f541View commit details -
scsi: ufs: ufs-mediatek: Fix build error and type mismatch
commit f54912b upstream. If CONFIG_PM_SLEEP is not set. make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-, will fail: drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_vreg_fix_vcc’: drivers/ufs/host/ufs-mediatek.c:688:46: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘long unsigned int’ [-Wformat=] snprintf(vcc_name, MAX_VCC_NAME, "vcc-opt%u", res.a1); ~^ ~~~~~~ %lu drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_system_suspend’: drivers/ufs/host/ufs-mediatek.c:1371:8: error: implicit declaration of function ‘ufshcd_system_suspend’; did you mean ‘ufs_mtk_system_suspend’? [-Werror=implicit-function-declaration] ret = ufshcd_system_suspend(dev); ^~~~~~~~~~~~~~~~~~~~~ ufs_mtk_system_suspend drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_system_resume’: drivers/ufs/host/ufs-mediatek.c:1386:9: error: implicit declaration of function ‘ufshcd_system_resume’; did you mean ‘ufs_mtk_system_resume’? [-Werror=implicit-function-declaration] return ufshcd_system_resume(dev); ^~~~~~~~~~~~~~~~~~~~ ufs_mtk_system_resume cc1: some warnings being treated as errors The declaration of func "ufshcd_system_suspend()" depends on CONFIG_PM_SLEEP, so the function wrapper ufs_mtk_system_suspend() should wrapped by CONFIG_PM_SLEEP too. Link: https://lore.kernel.org/r/[email protected] Fixes: 3fd23b8 ("scsi: ufs: ufs-mediatek: Fix the timing of configuring device regulators") Reported-by: Hulk Robot <[email protected]> Reviewed-by: Stanley Chu <[email protected]> Signed-off-by: Ren Zhijie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> [only take the suspend/resume portion of the commit - gregkh] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for d66d392 - Browse repository at this point
Copy the full SHA d66d392View commit details -
xfs: flush inodegc workqueue tasks before cancel
[ Upstream commit 6191cf3 ] The xfs_inodegc_stop() helper performs a high level flush of pending work on the percpu queues and then runs a cancel_work_sync() on each of the percpu work tasks to ensure all work has completed before returning. While cancel_work_sync() waits for wq tasks to complete, it does not guarantee work tasks have started. This means that the _stop() helper can queue and instantly cancel a wq task without having completed the associated work. This can be observed by tracepoint inspection of a simple "rm -f <file>; fsfreeze -f <mnt>" test: xfs_destroy_inode: ... ino 0x83 ... xfs_inode_set_need_inactive: ... ino 0x83 ... xfs_inodegc_stop: ... ... xfs_inodegc_start: ... xfs_inodegc_worker: ... xfs_inode_inactivating: ... ino 0x83 ... The first few lines show that the inode is removed and need inactive state set, but the inactivation work has not completed before the inodegc mechanism stops. The inactivation doesn't actually occur until the fs is unfrozen and the gc mechanism starts back up. Note that this test requires fsfreeze to reproduce because xfs_freeze indirectly invokes xfs_fs_statfs(), which calls xfs_inodegc_flush(). When this occurs, the workqueue try_to_grab_pending() logic first tries to steal the pending bit, which does not succeed because the bit has been set by queue_work_on(). Subsequently, it checks for association of a pool workqueue from the work item under the pool lock. This association is set at the point a work item is queued and cleared when dequeued for processing. If the association exists, the work item is removed from the queue and cancel_work_sync() returns true. If the pwq association is cleared, the remove attempt assumes the task is busy and retries (eventually returning false to the caller after waiting for the work task to complete). To avoid this race, we can flush each work item explicitly before cancel. However, since the _queue_all() already schedules each underlying work item, the workqueue level helpers are sufficient to achieve the same ordering effect. E.g., the inodegc enabled flag prevents scheduling any further work in the _stop() case. Use the drain_workqueue() helper in this particular case to make the intent a bit more self explanatory. Signed-off-by: Brian Foster <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Signed-off-by: Leah Rumancik <[email protected]> Acked-by: Darrick J. Wong <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 139e6fc - Browse repository at this point
Copy the full SHA 139e6fcView commit details -
xfs: reserve quota for dir expansion when linking/unlinking files
[ Upstream commit 871b931 ] XFS does not reserve quota for directory expansion when linking or unlinking children from a directory. This means that we don't reject the expansion with EDQUOT when we're at or near a hard limit, which means that unprivileged userspace can use link()/unlink() to exceed quota. The fix for this is nuanced -- link operations don't always expand the directory, and we allow a link to proceed with no space reservation if we don't need to add a block to the directory to handle the addition. Unlink operations generally do not expand the directory (you'd have to free a block and then cause a btree split) and we can defer the directory block freeing if there is no space reservation. Moreover, there is a further bug in that we do not trigger the blockgc workers to try to clear space when we're out of quota. To fix both cases, create a new xfs_trans_alloc_dir function that allocates the transaction, locks and joins the inodes, and reserves quota for the directory. If there isn't sufficient space or quota, we'll switch the caller to reservationless mode. This should prevent quota usage overruns with the least restriction in functionality. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Signed-off-by: Leah Rumancik <[email protected]> Acked-by: Darrick J. Wong <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 5e7f687 - Browse repository at this point
Copy the full SHA 5e7f687View commit details -
xfs: reserve quota for target dir expansion when renaming files
[ Upstream commit 4166726 ] XFS does not reserve quota for directory expansion when renaming children into a directory. This means that we don't reject the expansion with EDQUOT when we're at or near a hard limit, which means that unprivileged userspace can use rename() to exceed quota. Rename operations don't always expand the target directory, and we allow a rename to proceed with no space reservation if we don't need to add a block to the target directory to handle the addition. Moreover, the unlink operation on the source directory generally does not expand the directory (you'd have to free a block and then cause a btree split) and it's probably of little consequence to leave the corner case that renaming a file out of a directory can increase its size. As with link and unlink, there is a further bug in that we do not trigger the blockgc workers to try to clear space when we're out of quota. Because rename is its own special tricky animal, we'll patch xfs_rename directly to reserve quota to the rename transaction. We'll leave cleaning up the rest of xfs_rename for the metadata directory tree patchset. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Signed-off-by: Leah Rumancik <[email protected]> Acked-by: Darrick J. Wong <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 130b596 - Browse repository at this point
Copy the full SHA 130b596View commit details -
xfs: remove infinite loop when reserving free block pool
[ Upstream commit 15f04fd ] Infinite loops in kernel code are scary. Calls to xfs_reserve_blocks should be rare (people should just use the defaults!) so we really don't need to try so hard. Simplify the logic here by removing the infinite loop. Cc: Brian Foster <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Signed-off-by: Leah Rumancik <[email protected]> Acked-by: Darrick J. Wong <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 07e17dc - Browse repository at this point
Copy the full SHA 07e17dcView commit details -
xfs: always succeed at setting the reserve pool size
[ Upstream commit 0baa265 ] Nowadays, xfs_mod_fdblocks will always choose to fill the reserve pool with freed blocks before adding to fdblocks. Therefore, we can change the behavior of xfs_reserve_blocks slightly -- setting the target size of the pool should always succeed, since a deficiency will eventually be made up as blocks get freed. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Signed-off-by: Leah Rumancik <[email protected]> Acked-by: Darrick J. Wong <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 90f4146 - Browse repository at this point
Copy the full SHA 90f4146View commit details -
xfs: fix overfilling of reserve pool
[ Upstream commit 82be38b ] Due to cycling of m_sb_lock, it's possible for multiple callers of xfs_reserve_blocks to race at changing the pool size, subtracting blocks from fdblocks, and actually putting it in the pool. The result of all this is that we can overfill the reserve pool to hilarious levels. xfs_mod_fdblocks, when called with a positive value, already knows how to take freed blocks and either fill the reserve until it's full, or put them in fdblocks. Use that instead of setting m_resblks_avail directly. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Signed-off-by: Leah Rumancik <[email protected]> Acked-by: Darrick J. Wong <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for bbc256b - Browse repository at this point
Copy the full SHA bbc256bView commit details -
xfs: fix soft lockup via spinning in filestream ag selection loop
[ Upstream commit f650df7 ] The filestream AG selection loop uses pagf data to aid in AG selection, which depends on pagf initialization. If the in-core structure is not initialized, the caller invokes the AGF read path to do so and carries on. If another task enters the loop and finds a pagf init already in progress, the AGF read returns -EAGAIN and the task continues the loop. This does not increment the current ag index, however, which means the task spins on the current AGF buffer until unlocked. If the AGF read I/O submitted by the initial task happens to be delayed for whatever reason, this results in soft lockup warnings via the spinning task. This is reproduced by xfs/170. To avoid this problem, fix the AGF trylock failure path to properly iterate to the next AG. If a task iterates all AGs without making progress, the trylock behavior is dropped in favor of blocking locks and thus a soft lockup is no longer possible. Fixes: f48e2df ("xfs: make xfs_*read_agf return EAGAIN to ALLOC_FLAG_TRYLOCK callers") Signed-off-by: Brian Foster <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Dave Chinner <[email protected]> Signed-off-by: Leah Rumancik <[email protected]> Acked-by: Darrick J. Wong <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 12689d9 - Browse repository at this point
Copy the full SHA 12689d9View commit details -
xfs: revert "xfs: actually bump warning counts when we send warnings"
[ Upstream commit bc37e4f ] This reverts commit 4b8628d. XFS quota has had the concept of a "quota warning limit" since the earliest Irix implementation, but a mechanism for incrementing the warning counter was never implemented, as documented in the xfs_quota(8) man page. We do know from the historical archive that it was never incremented at runtime during quota reservation operations. With this commit, the warning counter quickly increments for every allocation attempt after the user has crossed a quote soft limit threshold, and this in turn transitions the user to hard quota failures, rendering soft quota thresholds and timers useless. This was reported as a regression by users. Because the intended behavior of this warning counter has never been understood or documented, and the result of this change is a regression in soft quota functionality, revert this commit to make soft quota limits and timers operable again. Fixes: 4b8628d ("xfs: actually bump warning counts when we send warnings) Signed-off-by: Eric Sandeen <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Signed-off-by: Dave Chinner <[email protected]> Signed-off-by: Leah Rumancik <[email protected]> Acked-by: Darrick J. Wong <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 1350a4c - Browse repository at this point
Copy the full SHA 1350a4cView commit details -
xfs: reject crazy array sizes being fed to XFS_IOC_GETBMAP*
[ Upstream commit 29d650f ] Syzbot tripped over the following complaint from the kernel: WARNING: CPU: 2 PID: 15402 at mm/util.c:597 kvmalloc_node+0x11e/0x125 mm/util.c:597 While trying to run XFS_IOC_GETBMAP against the following structure: struct getbmap fubar = { .bmv_count = 0x22dae649, }; Obviously, this is a crazy huge value since the next thing that the ioctl would do is allocate 37GB of memory. This is enough to make kvmalloc mad, but isn't large enough to trip the validation functions. In other words, I'm fussing with checks that were **already sufficient** because that's easier than dealing with 644 internal bug reports. Yes, that's right, six hundred and forty-four. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Allison Henderson <[email protected]> Reviewed-by: Catherine Hoang <[email protected]> Signed-off-by: Leah Rumancik <[email protected]> Acked-by: Darrick J. Wong <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for b92be74 - Browse repository at this point
Copy the full SHA b92be74View commit details -
Link: https://lore.kernel.org/r/[email protected] Tested-by: Shuah Khan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Ron Economos <[email protected]> Tested-by: Guenter Roeck <[email protected]> Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Sudip Mukherjee <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for addc900 - Browse repository at this point
Copy the full SHA addc900View commit details
Commits on Aug 26, 2022
-
Merge tag 'v5.15.63' into 5.15.x+fslc
This is the 5.15.63 stable release Signed-off-by: Andrey Zhizhikin <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 204257e - Browse repository at this point
Copy the full SHA 204257eView commit details