This is the start of the stable review cycle for the 4.4.230 release. There are 19 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Jul 2020 14:57:34 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.230-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.4.230-rc1
Vasily Averin vvs@virtuozzo.com netfilter: nf_conntrack_h323: lost .data_len definition for Q.931/ipv6
Hauke Mehrtens hauke@hauke-m.de MIPS: Add missing EHB in mtc0 -> mfc0 sequence for DSPen
Zhang Xiaoxu zhangxiaoxu5@huawei.com cifs: Fix the target file was deleted when rename failed.
Paul Aurich paul@darkrain42.org SMB3: Honor persistent/resilient handle flags for multiuser mounts
Paul Aurich paul@darkrain42.org SMB3: Honor 'seal' flag for multiuser mounts
Greg Kroah-Hartman gregkh@linuxfoundation.org Revert "ALSA: usb-audio: Improve frames size computation"
Chris Packham chris.packham@alliedtelesis.co.nz i2c: algo-pca: Add 0x78 as SCL stuck low status for PCA9665
Hou Tao houtao1@huawei.com virtio-blk: free vblk-vqs in error path of virtblk_probe()
Misono Tomohiro misono.tomohiro@jp.fujitsu.com hwmon: (acpi_power_meter) Fix potential memory leak in acpi_power_meter_add()
Chu Lin linchuyuan@google.com hwmon: (max6697) Make sure the OVERT mask is set correctly
Shile Zhang shile.zhang@nokia.com sched/rt: Show the 'sched_rr_timeslice' SCHED_RR timeslice tuning knob in milliseconds
Herbert Xu herbert@gondor.apana.org.au crypto: af_alg - fix use-after-free in af_alg_accept() due to bh_lock_sock()
Douglas Anderson dianders@chromium.org kgdb: Avoid suspicious RCU usage warning
Zqiang qiang.zhang@windriver.com usb: usbtest: fix missing kfree(dev->buf) in usbtest_disconnect
Qian Cai cai@lca.pw mm/slub: fix stack overruns with SLUB_STATS
Borislav Petkov bp@suse.de EDAC/amd64: Read back the scrub rate PCI register on F15h
Hugh Dickins hughd@google.com mm: fix swap cache node allocation mask
Filipe Manana fdmanana@suse.com btrfs: fix data block group relocation failure due to concurrent scrub
Anand Jain Anand.Jain@oracle.com btrfs: cow_file_range() num_bytes and disk_num_bytes are same
-------------
Diffstat:
Makefile | 4 ++-- arch/mips/kernel/traps.c | 1 + crypto/af_alg.c | 26 +++++++++----------- crypto/algif_aead.c | 9 +++---- crypto/algif_hash.c | 9 +++---- crypto/algif_skcipher.c | 9 +++---- drivers/block/virtio_blk.c | 1 + drivers/edac/amd64_edac.c | 2 ++ drivers/hwmon/acpi_power_meter.c | 4 +++- drivers/hwmon/max6697.c | 7 +++--- drivers/i2c/algos/i2c-algo-pca.c | 3 ++- drivers/usb/misc/usbtest.c | 1 + fs/btrfs/inode.c | 36 ++++++++++++++++++++-------- fs/cifs/connect.c | 3 +++ fs/cifs/inode.c | 10 ++++++-- include/crypto/if_alg.h | 4 ++-- include/linux/sched/sysctl.h | 1 + kernel/debug/debug_core.c | 4 ++++ kernel/sched/core.c | 5 ++-- kernel/sched/rt.c | 1 + kernel/sysctl.c | 2 +- mm/slub.c | 3 ++- mm/swap_state.c | 3 ++- net/netfilter/nf_conntrack_h323_main.c | 1 + sound/usb/card.h | 4 ---- sound/usb/endpoint.c | 43 ++++------------------------------ sound/usb/endpoint.h | 1 - sound/usb/pcm.c | 2 -- 28 files changed, 95 insertions(+), 104 deletions(-)
From: Anand Jain Anand.Jain@oracle.com
[ Upstream commit 3752d22fcea160cc2493e34f5e0e41cdd7fdd921 ]
This patch deletes local variable disk_num_bytes as its value is same as num_bytes in the function cow_file_range().
Signed-off-by: Anand Jain anand.jain@oracle.com Reviewed-by: Nikolay Borisov nborisov@suse.com Reviewed-by: David Sterba dsterba@suse.com Signed-off-by: David Sterba dsterba@suse.com Signed-off-by: Sasha Levin sashal@kernel.org --- fs/btrfs/inode.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 972475eeb2dd0..ef8ed0cd8075a 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -926,7 +926,6 @@ static noinline int cow_file_range(struct inode *inode, u64 alloc_hint = 0; u64 num_bytes; unsigned long ram_size; - u64 disk_num_bytes; u64 cur_alloc_size; u64 blocksize = root->sectorsize; struct btrfs_key ins; @@ -942,7 +941,6 @@ static noinline int cow_file_range(struct inode *inode,
num_bytes = ALIGN(end - start + 1, blocksize); num_bytes = max(blocksize, num_bytes); - disk_num_bytes = num_bytes;
/* if this is a small write inside eof, kick off defrag */ if (num_bytes < 64 * 1024 && @@ -969,16 +967,15 @@ static noinline int cow_file_range(struct inode *inode, } }
- BUG_ON(disk_num_bytes > - btrfs_super_total_bytes(root->fs_info->super_copy)); + BUG_ON(num_bytes > btrfs_super_total_bytes(root->fs_info->super_copy));
alloc_hint = get_extent_allocation_hint(inode, start, num_bytes); btrfs_drop_extent_cache(inode, start, start + num_bytes - 1, 0);
- while (disk_num_bytes > 0) { + while (num_bytes > 0) { unsigned long op;
- cur_alloc_size = disk_num_bytes; + cur_alloc_size = num_bytes; ret = btrfs_reserve_extent(root, cur_alloc_size, root->sectorsize, 0, alloc_hint, &ins, 1, 1); @@ -1033,7 +1030,7 @@ static noinline int cow_file_range(struct inode *inode, goto out_drop_extent_cache; }
- if (disk_num_bytes < cur_alloc_size) + if (num_bytes < cur_alloc_size) break;
/* we're not doing compressed IO, don't unlock the first @@ -1050,8 +1047,10 @@ static noinline int cow_file_range(struct inode *inode, start + ram_size - 1, locked_page, EXTENT_LOCKED | EXTENT_DELALLOC, op); - disk_num_bytes -= cur_alloc_size; - num_bytes -= cur_alloc_size; + if (num_bytes < cur_alloc_size) + num_bytes = 0; + else + num_bytes -= cur_alloc_size; alloc_hint = ins.objectid + ins.offset; start += cur_alloc_size; }
From: Filipe Manana fdmanana@suse.com
[ Upstream commit 432cd2a10f1c10cead91fe706ff5dc52f06d642a ]
When running relocation of a data block group while scrub is running in parallel, it is possible that the relocation will fail and abort the current transaction with an -EINVAL error:
[134243.988595] BTRFS info (device sdc): found 14 extents, stage: move data extents [134243.999871] ------------[ cut here ]------------ [134244.000741] BTRFS: Transaction aborted (error -22) [134244.001692] WARNING: CPU: 0 PID: 26954 at fs/btrfs/ctree.c:1071 __btrfs_cow_block+0x6a7/0x790 [btrfs] [134244.003380] Modules linked in: btrfs blake2b_generic xor raid6_pq (...) [134244.012577] CPU: 0 PID: 26954 Comm: btrfs Tainted: G W 5.6.0-rc7-btrfs-next-58 #5 [134244.014162] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [134244.016184] RIP: 0010:__btrfs_cow_block+0x6a7/0x790 [btrfs] [134244.017151] Code: 48 c7 c7 (...) [134244.020549] RSP: 0018:ffffa41607863888 EFLAGS: 00010286 [134244.021515] RAX: 0000000000000000 RBX: ffff9614bdfe09c8 RCX: 0000000000000000 [134244.022822] RDX: 0000000000000001 RSI: ffffffffb3d63980 RDI: 0000000000000001 [134244.024124] RBP: ffff961589e8c000 R08: 0000000000000000 R09: 0000000000000001 [134244.025424] R10: ffffffffc0ae5955 R11: 0000000000000000 R12: ffff9614bd530d08 [134244.026725] R13: ffff9614ced41b88 R14: ffff9614bdfe2a48 R15: 0000000000000000 [134244.028024] FS: 00007f29b63c08c0(0000) GS:ffff9615ba600000(0000) knlGS:0000000000000000 [134244.029491] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [134244.030560] CR2: 00007f4eb339b000 CR3: 0000000130d6e006 CR4: 00000000003606f0 [134244.031997] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [134244.033153] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [134244.034484] Call Trace: [134244.034984] btrfs_cow_block+0x12b/0x2b0 [btrfs] [134244.035859] do_relocation+0x30b/0x790 [btrfs] [134244.036681] ? do_raw_spin_unlock+0x49/0xc0 [134244.037460] ? _raw_spin_unlock+0x29/0x40 [134244.038235] relocate_tree_blocks+0x37b/0x730 [btrfs] [134244.039245] relocate_block_group+0x388/0x770 [btrfs] [134244.040228] btrfs_relocate_block_group+0x161/0x2e0 [btrfs] [134244.041323] btrfs_relocate_chunk+0x36/0x110 [btrfs] [134244.041345] btrfs_balance+0xc06/0x1860 [btrfs] [134244.043382] ? btrfs_ioctl_balance+0x27c/0x310 [btrfs] [134244.045586] btrfs_ioctl_balance+0x1ed/0x310 [btrfs] [134244.045611] btrfs_ioctl+0x1880/0x3760 [btrfs] [134244.049043] ? do_raw_spin_unlock+0x49/0xc0 [134244.049838] ? _raw_spin_unlock+0x29/0x40 [134244.050587] ? __handle_mm_fault+0x11b3/0x14b0 [134244.051417] ? ksys_ioctl+0x92/0xb0 [134244.052070] ksys_ioctl+0x92/0xb0 [134244.052701] ? trace_hardirqs_off_thunk+0x1a/0x1c [134244.053511] __x64_sys_ioctl+0x16/0x20 [134244.054206] do_syscall_64+0x5c/0x280 [134244.054891] entry_SYSCALL_64_after_hwframe+0x49/0xbe [134244.055819] RIP: 0033:0x7f29b51c9dd7 [134244.056491] Code: 00 00 00 (...) [134244.059767] RSP: 002b:00007ffcccc1dd08 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 [134244.061168] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f29b51c9dd7 [134244.062474] RDX: 00007ffcccc1dda0 RSI: 00000000c4009420 RDI: 0000000000000003 [134244.063771] RBP: 0000000000000003 R08: 00005565cea4b000 R09: 0000000000000000 [134244.065032] R10: 0000000000000541 R11: 0000000000000202 R12: 00007ffcccc2060a [134244.066327] R13: 00007ffcccc1dda0 R14: 0000000000000002 R15: 00007ffcccc1dec0 [134244.067626] irq event stamp: 0 [134244.068202] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [134244.069351] hardirqs last disabled at (0): [<ffffffffb2abdedf>] copy_process+0x74f/0x2020 [134244.070909] softirqs last enabled at (0): [<ffffffffb2abdedf>] copy_process+0x74f/0x2020 [134244.072392] softirqs last disabled at (0): [<0000000000000000>] 0x0 [134244.073432] ---[ end trace bd7c03622e0b0a99 ]---
The -EINVAL error comes from the following chain of function calls:
__btrfs_cow_block() <-- aborts the transaction btrfs_reloc_cow_block() replace_file_extents() get_new_location() <-- returns -EINVAL
When relocating a data block group, for each allocated extent of the block group, we preallocate another extent (at prealloc_file_extent_cluster()), associated with the data relocation inode, and then dirty all its pages. These preallocated extents have, and must have, the same size that extents from the data block group being relocated have.
Later before we start the relocation stage that updates pointers (bytenr field of file extent items) to point to the the new extents, we trigger writeback for the data relocation inode. The expectation is that writeback will write the pages to the previously preallocated extents, that it follows the NOCOW path. That is generally the case, however, if a scrub is running it may have turned the block group that contains those extents into RO mode, in which case writeback falls back to the COW path.
However in the COW path instead of allocating exactly one extent with the expected size, the allocator may end up allocating several smaller extents due to free space fragmentation - because we tell it at cow_file_range() that the minimum allocation size can match the filesystem's sector size. This later breaks the relocation's expectation that an extent associated to a file extent item in the data relocation inode has the same size as the respective extent pointed by a file extent item in another tree - in this case the extent to which the relocation inode poins to is smaller, causing relocation.c:get_new_location() to return -EINVAL.
For example, if we are relocating a data block group X that has a logical address of X and the block group has an extent allocated at the logical address X + 128KiB with a size of 64KiB:
1) At prealloc_file_extent_cluster() we allocate an extent for the data relocation inode with a size of 64KiB and associate it to the file offset 128KiB (X + 128KiB - X) of the data relocation inode. This preallocated extent was allocated at block group Z;
2) A scrub running in parallel turns block group Z into RO mode and starts scrubing its extents;
3) Relocation triggers writeback for the data relocation inode;
4) When running delalloc (btrfs_run_delalloc_range()), we try first the NOCOW path because the data relocation inode has BTRFS_INODE_PREALLOC set in its flags. However, because block group Z is in RO mode, the NOCOW path (run_delalloc_nocow()) falls back into the COW path, by calling cow_file_range();
5) At cow_file_range(), in the first iteration of the while loop we call btrfs_reserve_extent() to allocate a 64KiB extent and pass it a minimum allocation size of 4KiB (fs_info->sectorsize). Due to free space fragmentation, btrfs_reserve_extent() ends up allocating two extents of 32KiB each, each one on a different iteration of that while loop;
6) Writeback of the data relocation inode completes;
7) Relocation proceeds and ends up at relocation.c:replace_file_extents(), with a leaf which has a file extent item that points to the data extent from block group X, that has a logical address (bytenr) of X + 128KiB and a size of 64KiB. Then it calls get_new_location(), which does a lookup in the data relocation tree for a file extent item starting at offset 128KiB (X + 128KiB - X) and belonging to the data relocation inode. It finds a corresponding file extent item, however that item points to an extent that has a size of 32KiB, which doesn't match the expected size of 64KiB, resuling in -EINVAL being returned from this function and propagated up to __btrfs_cow_block(), which aborts the current transaction.
To fix this make sure that at cow_file_range() when we call the allocator we pass it a minimum allocation size corresponding the desired extent size if the inode belongs to the data relocation tree, otherwise pass it the filesystem's sector size as the minimum allocation size.
CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Josef Bacik josef@toxicpanda.com Signed-off-by: Filipe Manana fdmanana@suse.com Signed-off-by: David Sterba dsterba@suse.com Signed-off-by: Sasha Levin sashal@kernel.org --- fs/btrfs/inode.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index ef8ed0cd8075a..b1125778b9080 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -926,6 +926,7 @@ static noinline int cow_file_range(struct inode *inode, u64 alloc_hint = 0; u64 num_bytes; unsigned long ram_size; + u64 min_alloc_size; u64 cur_alloc_size; u64 blocksize = root->sectorsize; struct btrfs_key ins; @@ -972,12 +973,28 @@ static noinline int cow_file_range(struct inode *inode, alloc_hint = get_extent_allocation_hint(inode, start, num_bytes); btrfs_drop_extent_cache(inode, start, start + num_bytes - 1, 0);
+ /* + * Relocation relies on the relocated extents to have exactly the same + * size as the original extents. Normally writeback for relocation data + * extents follows a NOCOW path because relocation preallocates the + * extents. However, due to an operation such as scrub turning a block + * group to RO mode, it may fallback to COW mode, so we must make sure + * an extent allocated during COW has exactly the requested size and can + * not be split into smaller extents, otherwise relocation breaks and + * fails during the stage where it updates the bytenr of file extent + * items. + */ + if (root->root_key.objectid == BTRFS_DATA_RELOC_TREE_OBJECTID) + min_alloc_size = num_bytes; + else + min_alloc_size = root->sectorsize; + while (num_bytes > 0) { unsigned long op;
cur_alloc_size = num_bytes; ret = btrfs_reserve_extent(root, cur_alloc_size, - root->sectorsize, 0, alloc_hint, + min_alloc_size, 0, alloc_hint, &ins, 1, 1); if (ret < 0) goto out_unlock;
From: Hugh Dickins hughd@google.com
[ Upstream commit 243bce09c91b0145aeaedd5afba799d81841c030 ]
Chris Murphy reports that a slightly overcommitted load, testing swap and zram along with i915, splats and keeps on splatting, when it had better fail less noisily:
gnome-shell: page allocation failure: order:0, mode:0x400d0(__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_RECLAIMABLE), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 2 PID: 1155 Comm: gnome-shell Not tainted 5.7.0-1.fc33.x86_64 #1 Call Trace: dump_stack+0x64/0x88 warn_alloc.cold+0x75/0xd9 __alloc_pages_slowpath.constprop.0+0xcfa/0xd30 __alloc_pages_nodemask+0x2df/0x320 alloc_slab_page+0x195/0x310 allocate_slab+0x3c5/0x440 ___slab_alloc+0x40c/0x5f0 __slab_alloc+0x1c/0x30 kmem_cache_alloc+0x20e/0x220 xas_nomem+0x28/0x70 add_to_swap_cache+0x321/0x400 __read_swap_cache_async+0x105/0x240 swap_cluster_readahead+0x22c/0x2e0 shmem_swapin+0x8e/0xc0 shmem_swapin_page+0x196/0x740 shmem_getpage_gfp+0x3a2/0xa60 shmem_read_mapping_page_gfp+0x32/0x60 shmem_get_pages+0x155/0x5e0 [i915] __i915_gem_object_get_pages+0x68/0xa0 [i915] i915_vma_pin+0x3fe/0x6c0 [i915] eb_add_vma+0x10b/0x2c0 [i915] i915_gem_do_execbuffer+0x704/0x3430 [i915] i915_gem_execbuffer2_ioctl+0x1ea/0x3e0 [i915] drm_ioctl_kernel+0x86/0xd0 [drm] drm_ioctl+0x206/0x390 [drm] ksys_ioctl+0x82/0xc0 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x5b/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9
Reported on 5.7, but it goes back really to 3.1: when shmem_read_mapping_page_gfp() was implemented for use by i915, and allowed for __GFP_NORETRY and __GFP_NOWARN flags in most places, but missed swapin's "& GFP_KERNEL" mask for page tree node allocation in __read_swap_cache_async() - that was to mask off HIGHUSER_MOVABLE bits from what page cache uses, but GFP_RECLAIM_MASK is now what's needed.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=208085 Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2006151330070.11064@eggly.anvils Fixes: 68da9f055755 ("tmpfs: pass gfp to shmem_getpage_gfp") Signed-off-by: Hugh Dickins hughd@google.com Reviewed-by: Vlastimil Babka vbabka@suse.cz Reviewed-by: Matthew Wilcox (Oracle) willy@infradead.org Reported-by: Chris Murphy lists@colorremedies.com Analyzed-by: Vlastimil Babka vbabka@suse.cz Analyzed-by: Matthew Wilcox willy@infradead.org Tested-by: Chris Murphy lists@colorremedies.com Cc: stable@vger.kernel.org [3.1+] Signed-off-by: Andrew Morton akpm@linux-foundation.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- mm/swap_state.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/swap_state.c b/mm/swap_state.c index d504adb7fa5f0..9e587464e6343 100644 --- a/mm/swap_state.c +++ b/mm/swap_state.c @@ -19,6 +19,7 @@ #include <linux/migrate.h>
#include <asm/pgtable.h> +#include "internal.h"
/* * swapper_space is a fiction, retained to simplify the path through @@ -319,7 +320,7 @@ struct page *__read_swap_cache_async(swp_entry_t entry, gfp_t gfp_mask, /* * call radix_tree_preload() while we can wait. */ - err = radix_tree_maybe_preload(gfp_mask & GFP_KERNEL); + err = radix_tree_maybe_preload(gfp_mask & GFP_RECLAIM_MASK); if (err) break;
From: Borislav Petkov bp@suse.de
[ Upstream commit ee470bb25d0dcdf126f586ec0ae6dca66cb340a4 ]
Commit:
da92110dfdfa ("EDAC, amd64_edac: Extend scrub rate support to F15hM60h")
added support for F15h, model 0x60 CPUs but in doing so, missed to read back SCRCTRL PCI config register on F15h CPUs which are *not* model 0x60. Add that read so that doing
$ cat /sys/devices/system/edac/mc/mc0/sdram_scrub_rate
can show the previously set DRAM scrub rate.
Fixes: da92110dfdfa ("EDAC, amd64_edac: Extend scrub rate support to F15hM60h") Reported-by: Anders Andersson pipatron@gmail.com Signed-off-by: Borislav Petkov bp@suse.de Cc: stable@vger.kernel.org #v4.4.. Link: https://lkml.kernel.org/r/CAKkunMbNWppx_i6xSdDHLseA2QQmGJqj_crY=NF-GZML5np4V... Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/edac/amd64_edac.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c index 932ba76761835..5f86075e34da9 100644 --- a/drivers/edac/amd64_edac.c +++ b/drivers/edac/amd64_edac.c @@ -248,6 +248,8 @@ static int get_scrub_rate(struct mem_ctl_info *mci)
if (pvt->model == 0x60) amd64_read_pci_cfg(pvt->F2, F15H_M60H_SCRCTRL, &scrubval); + else + amd64_read_pci_cfg(pvt->F3, SCRCTRL, &scrubval); } else amd64_read_pci_cfg(pvt->F3, SCRCTRL, &scrubval);
From: Qian Cai cai@lca.pw
[ Upstream commit a68ee0573991e90af2f1785db309206408bad3e5 ]
There is no need to copy SLUB_STATS items from root memcg cache to new memcg cache copies. Doing so could result in stack overruns because the store function only accepts 0 to clear the stat and returns an error for everything else while the show method would print out the whole stat.
Then, the mismatch of the lengths returns from show and store methods happens in memcg_propagate_slab_attrs():
else if (root_cache->max_attr_size < ARRAY_SIZE(mbuf)) buf = mbuf;
max_attr_size is only 2 from slab_attr_store(), then, it uses mbuf[64] in show_stat() later where a bounch of sprintf() would overrun the stack variable. Fix it by always allocating a page of buffer to be used in show_stat() if SLUB_STATS=y which should only be used for debug purpose.
# echo 1 > /sys/kernel/slab/fs_cache/shrink BUG: KASAN: stack-out-of-bounds in number+0x421/0x6e0 Write of size 1 at addr ffffc900256cfde0 by task kworker/76:0/53251
Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019 Workqueue: memcg_kmem_cache memcg_kmem_cache_create_func Call Trace: number+0x421/0x6e0 vsnprintf+0x451/0x8e0 sprintf+0x9e/0xd0 show_stat+0x124/0x1d0 alloc_slowpath_show+0x13/0x20 __kmem_cache_create+0x47a/0x6b0
addr ffffc900256cfde0 is located in stack of task kworker/76:0/53251 at offset 0 in frame: process_one_work+0x0/0xb90
this frame has 1 object: [32, 72) 'lockdep_map'
Memory state around the buggy address: ffffc900256cfc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffc900256cfd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffc900256cfd80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
^ ffffc900256cfe00: 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00 00 ffffc900256cfe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: __kmem_cache_create+0x6ac/0x6b0 Workqueue: memcg_kmem_cache memcg_kmem_cache_create_func Call Trace: __kmem_cache_create+0x6ac/0x6b0
Fixes: 107dab5c92d5 ("slub: slub-specific propagation changes") Signed-off-by: Qian Cai cai@lca.pw Signed-off-by: Andrew Morton akpm@linux-foundation.org Cc: Glauber Costa glauber@scylladb.com Cc: Christoph Lameter cl@linux.com Cc: Pekka Enberg penberg@kernel.org Cc: David Rientjes rientjes@google.com Cc: Joonsoo Kim iamjoonsoo.kim@lge.com Link: http://lkml.kernel.org/r/20200429222356.4322-1-cai@lca.pw Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- mm/slub.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/slub.c b/mm/slub.c index bb5237c67cbc9..a3870034bfcc4 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -5305,7 +5305,8 @@ static void memcg_propagate_slab_attrs(struct kmem_cache *s) */ if (buffer) buf = buffer; - else if (root_cache->max_attr_size < ARRAY_SIZE(mbuf)) + else if (root_cache->max_attr_size < ARRAY_SIZE(mbuf) && + !IS_ENABLED(CONFIG_SLUB_STATS)) buf = mbuf; else { buffer = (char *) get_zeroed_page(GFP_KERNEL);
From: Zqiang qiang.zhang@windriver.com
[ Upstream commit 28ebeb8db77035e058a510ce9bd17c2b9a009dba ]
BUG: memory leak unreferenced object 0xffff888055046e00 (size 256): comm "kworker/2:9", pid 2570, jiffies 4294942129 (age 1095.500s) hex dump (first 32 bytes): 00 70 04 55 80 88 ff ff 18 bb 5a 81 ff ff ff ff .p.U......Z..... f5 96 78 81 ff ff ff ff 37 de 8e 81 ff ff ff ff ..x.....7....... backtrace: [<00000000d121dccf>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] [<00000000d121dccf>] slab_post_alloc_hook mm/slab.h:586 [inline] [<00000000d121dccf>] slab_alloc_node mm/slub.c:2786 [inline] [<00000000d121dccf>] slab_alloc mm/slub.c:2794 [inline] [<00000000d121dccf>] kmem_cache_alloc_trace+0x15e/0x2d0 mm/slub.c:2811 [<000000005c3c3381>] kmalloc include/linux/slab.h:555 [inline] [<000000005c3c3381>] usbtest_probe+0x286/0x19d0 drivers/usb/misc/usbtest.c:2790 [<000000001cec6910>] usb_probe_interface+0x2bd/0x870 drivers/usb/core/driver.c:361 [<000000007806c118>] really_probe+0x48d/0x8f0 drivers/base/dd.c:551 [<00000000a3308c3e>] driver_probe_device+0xfc/0x2a0 drivers/base/dd.c:724 [<000000003ef66004>] __device_attach_driver+0x1b6/0x240 drivers/base/dd.c:831 [<00000000eee53e97>] bus_for_each_drv+0x14e/0x1e0 drivers/base/bus.c:431 [<00000000bb0648d0>] __device_attach+0x1f9/0x350 drivers/base/dd.c:897 [<00000000838b324a>] device_initial_probe+0x1a/0x20 drivers/base/dd.c:944 [<0000000030d501c1>] bus_probe_device+0x1e1/0x280 drivers/base/bus.c:491 [<000000005bd7adef>] device_add+0x131d/0x1c40 drivers/base/core.c:2504 [<00000000a0937814>] usb_set_configuration+0xe84/0x1ab0 drivers/usb/core/message.c:2030 [<00000000e3934741>] generic_probe+0x6a/0xe0 drivers/usb/core/generic.c:210 [<0000000098ade0f1>] usb_probe_device+0x90/0xd0 drivers/usb/core/driver.c:266 [<000000007806c118>] really_probe+0x48d/0x8f0 drivers/base/dd.c:551 [<00000000a3308c3e>] driver_probe_device+0xfc/0x2a0 drivers/base/dd.c:724
Acked-by: Alan Stern stern@rowland.harvard.edu Reported-by: Kyungtae Kim kt0755@gmail.com Signed-off-by: Zqiang qiang.zhang@windriver.com Link: https://lore.kernel.org/r/20200612035210.20494-1-qiang.zhang@windriver.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/usb/misc/usbtest.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c index bc92a498ec03d..9f19aa950bb19 100644 --- a/drivers/usb/misc/usbtest.c +++ b/drivers/usb/misc/usbtest.c @@ -2703,6 +2703,7 @@ static void usbtest_disconnect(struct usb_interface *intf)
usb_set_intfdata(intf, NULL); dev_dbg(&intf->dev, "disconnect\n"); + kfree(dev->buf); kfree(dev); }
From: Douglas Anderson dianders@chromium.org
[ Upstream commit 440ab9e10e2e6e5fd677473ee6f9e3af0f6904d6 ]
At times when I'm using kgdb I see a splat on my console about suspicious RCU usage. I managed to come up with a case that could reproduce this that looked like this:
WARNING: suspicious RCU usage 5.7.0-rc4+ #609 Not tainted ----------------------------- kernel/pid.c:395 find_task_by_pid_ns() needs rcu_read_lock() protection!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 3 locks held by swapper/0/1: #0: ffffff81b6b8e988 (&dev->mutex){....}-{3:3}, at: __device_attach+0x40/0x13c #1: ffffffd01109e9e8 (dbg_master_lock){....}-{2:2}, at: kgdb_cpu_enter+0x20c/0x7ac #2: ffffffd01109ea90 (dbg_slave_lock){....}-{2:2}, at: kgdb_cpu_enter+0x3ec/0x7ac
stack backtrace: CPU: 7 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc4+ #609 Hardware name: Google Cheza (rev3+) (DT) Call trace: dump_backtrace+0x0/0x1b8 show_stack+0x1c/0x24 dump_stack+0xd4/0x134 lockdep_rcu_suspicious+0xf0/0x100 find_task_by_pid_ns+0x5c/0x80 getthread+0x8c/0xb0 gdb_serial_stub+0x9d4/0xd04 kgdb_cpu_enter+0x284/0x7ac kgdb_handle_exception+0x174/0x20c kgdb_brk_fn+0x24/0x30 call_break_hook+0x6c/0x7c brk_handler+0x20/0x5c do_debug_exception+0x1c8/0x22c el1_sync_handler+0x3c/0xe4 el1_sync+0x7c/0x100 rpmh_rsc_probe+0x38/0x420 platform_drv_probe+0x94/0xb4 really_probe+0x134/0x300 driver_probe_device+0x68/0x100 __device_attach_driver+0x90/0xa8 bus_for_each_drv+0x84/0xcc __device_attach+0xb4/0x13c device_initial_probe+0x18/0x20 bus_probe_device+0x38/0x98 device_add+0x38c/0x420
If I understand properly we should just be able to blanket kgdb under one big RCU read lock and the problem should go away. We'll add it to the beast-of-a-function known as kgdb_cpu_enter().
With this I no longer get any splats and things seem to work fine.
Signed-off-by: Douglas Anderson dianders@chromium.org Link: https://lore.kernel.org/r/20200602154729.v2.1.I70e0d4fd46d5ed2aaf0c98a355e8e... Signed-off-by: Daniel Thompson daniel.thompson@linaro.org Signed-off-by: Sasha Levin sashal@kernel.org --- kernel/debug/debug_core.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c index 9c939c6bf21cb..321ccdbb73649 100644 --- a/kernel/debug/debug_core.c +++ b/kernel/debug/debug_core.c @@ -488,6 +488,7 @@ static int kgdb_cpu_enter(struct kgdb_state *ks, struct pt_regs *regs, arch_kgdb_ops.disable_hw_break(regs);
acquirelock: + rcu_read_lock(); /* * Interrupts will be restored by the 'trap return' code, except when * single stepping. @@ -542,6 +543,7 @@ return_normal: atomic_dec(&slaves_in_kgdb); dbg_touch_watchdogs(); local_irq_restore(flags); + rcu_read_unlock(); return 0; } cpu_relax(); @@ -560,6 +562,7 @@ return_normal: raw_spin_unlock(&dbg_master_lock); dbg_touch_watchdogs(); local_irq_restore(flags); + rcu_read_unlock();
goto acquirelock; } @@ -677,6 +680,7 @@ kgdb_restore: raw_spin_unlock(&dbg_master_lock); dbg_touch_watchdogs(); local_irq_restore(flags); + rcu_read_unlock();
return kgdb_info[cpu].ret_state; }
From: Herbert Xu herbert@gondor.apana.org.au
commit 34c86f4c4a7be3b3e35aa48bd18299d4c756064d upstream.
The locking in af_alg_release_parent is broken as the BH socket lock can only be taken if there is a code-path to handle the case where the lock is owned by process-context. Instead of adding such handling, we can fix this by changing the ref counts to atomic_t.
This patch also modifies the main refcnt to include both normal and nokey sockets. This way we don't have to fudge the nokey ref count when a socket changes from nokey to normal.
Credits go to Mauricio Faria de Oliveira who diagnosed this bug and sent a patch for it:
https://lore.kernel.org/linux-crypto/20200605161657.535043-1-mfo@canonical.c...
Reported-by: Brian Moyles bmoyles@netflix.com Reported-by: Mauricio Faria de Oliveira mfo@canonical.com Fixes: 37f96694cf73 ("crypto: af_alg - Use bh_lock_sock in...") Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu herbert@gondor.apana.org.au Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- crypto/af_alg.c | 26 +++++++++++--------------- crypto/algif_aead.c | 9 +++------ crypto/algif_hash.c | 9 +++------ crypto/algif_skcipher.c | 9 +++------ include/crypto/if_alg.h | 4 ++-- 5 files changed, 22 insertions(+), 35 deletions(-)
--- a/crypto/af_alg.c +++ b/crypto/af_alg.c @@ -130,21 +130,15 @@ EXPORT_SYMBOL_GPL(af_alg_release); void af_alg_release_parent(struct sock *sk) { struct alg_sock *ask = alg_sk(sk); - unsigned int nokey = ask->nokey_refcnt; - bool last = nokey && !ask->refcnt; + unsigned int nokey = atomic_read(&ask->nokey_refcnt);
sk = ask->parent; ask = alg_sk(sk);
- local_bh_disable(); - bh_lock_sock(sk); - ask->nokey_refcnt -= nokey; - if (!last) - last = !--ask->refcnt; - bh_unlock_sock(sk); - local_bh_enable(); + if (nokey) + atomic_dec(&ask->nokey_refcnt);
- if (last) + if (atomic_dec_and_test(&ask->refcnt)) sock_put(sk); } EXPORT_SYMBOL_GPL(af_alg_release_parent); @@ -189,7 +183,7 @@ static int alg_bind(struct socket *sock,
err = -EBUSY; lock_sock(sk); - if (ask->refcnt | ask->nokey_refcnt) + if (atomic_read(&ask->refcnt)) goto unlock;
swap(ask->type, type); @@ -238,7 +232,7 @@ static int alg_setsockopt(struct socket int err = -EBUSY;
lock_sock(sk); - if (ask->refcnt) + if (atomic_read(&ask->refcnt) != atomic_read(&ask->nokey_refcnt)) goto unlock;
type = ask->type; @@ -305,12 +299,14 @@ int af_alg_accept(struct sock *sk, struc
sk2->sk_family = PF_ALG;
- if (nokey || !ask->refcnt++) + if (atomic_inc_return_relaxed(&ask->refcnt) == 1) sock_hold(sk); - ask->nokey_refcnt += nokey; + if (nokey) { + atomic_inc(&ask->nokey_refcnt); + atomic_set(&alg_sk(sk2)->nokey_refcnt, 1); + } alg_sk(sk2)->parent = sk; alg_sk(sk2)->type = type; - alg_sk(sk2)->nokey_refcnt = nokey;
newsock->ops = type->ops; newsock->state = SS_CONNECTED; --- a/crypto/algif_aead.c +++ b/crypto/algif_aead.c @@ -528,7 +528,7 @@ static int aead_check_key(struct socket struct alg_sock *ask = alg_sk(sk);
lock_sock(sk); - if (ask->refcnt) + if (!atomic_read(&ask->nokey_refcnt)) goto unlock_child;
psk = ask->parent; @@ -540,11 +540,8 @@ static int aead_check_key(struct socket if (!tfm->has_key) goto unlock;
- if (!pask->refcnt++) - sock_hold(psk); - - ask->refcnt = 1; - sock_put(psk); + atomic_dec(&pask->nokey_refcnt); + atomic_set(&ask->nokey_refcnt, 0);
err = 0;
--- a/crypto/algif_hash.c +++ b/crypto/algif_hash.c @@ -252,7 +252,7 @@ static int hash_check_key(struct socket struct alg_sock *ask = alg_sk(sk);
lock_sock(sk); - if (ask->refcnt) + if (!atomic_read(&ask->nokey_refcnt)) goto unlock_child;
psk = ask->parent; @@ -264,11 +264,8 @@ static int hash_check_key(struct socket if (!tfm->has_key) goto unlock;
- if (!pask->refcnt++) - sock_hold(psk); - - ask->refcnt = 1; - sock_put(psk); + atomic_dec(&pask->nokey_refcnt); + atomic_set(&ask->nokey_refcnt, 0);
err = 0;
--- a/crypto/algif_skcipher.c +++ b/crypto/algif_skcipher.c @@ -774,7 +774,7 @@ static int skcipher_check_key(struct soc struct alg_sock *ask = alg_sk(sk);
lock_sock(sk); - if (ask->refcnt) + if (!atomic_read(&ask->nokey_refcnt)) goto unlock_child;
psk = ask->parent; @@ -786,11 +786,8 @@ static int skcipher_check_key(struct soc if (!tfm->has_key) goto unlock;
- if (!pask->refcnt++) - sock_hold(psk); - - ask->refcnt = 1; - sock_put(psk); + atomic_dec(&pask->nokey_refcnt); + atomic_set(&ask->nokey_refcnt, 0);
err = 0;
--- a/include/crypto/if_alg.h +++ b/include/crypto/if_alg.h @@ -30,8 +30,8 @@ struct alg_sock {
struct sock *parent;
- unsigned int refcnt; - unsigned int nokey_refcnt; + atomic_t refcnt; + atomic_t nokey_refcnt;
const struct af_alg_type *type; void *private;
From: Shile Zhang shile.zhang@nokia.com
[ Upstream commit 975e155ed8732cb81f55c021c441ae662dd040b5 ]
We added the 'sched_rr_timeslice_ms' SCHED_RR tuning knob in this commit:
ce0dbbbb30ae ("sched/rt: Add a tuning knob to allow changing SCHED_RR timeslice")
... which name suggests to users that it's in milliseconds, while in reality it's being set in milliseconds but the result is shown in jiffies.
This is obviously confusing when HZ is not 1000, it makes it appear like the value set failed, such as HZ=100:
root# echo 100 > /proc/sys/kernel/sched_rr_timeslice_ms root# cat /proc/sys/kernel/sched_rr_timeslice_ms 10
Fix this to be milliseconds all around.
Signed-off-by: Shile Zhang shile.zhang@nokia.com Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Cc: Linus Torvalds torvalds@linux-foundation.org Cc: Mike Galbraith efault@gmx.de Cc: Peter Zijlstra peterz@infradead.org Cc: Thomas Gleixner tglx@linutronix.de Link: http://lkml.kernel.org/r/1485612049-20923-1-git-send-email-shile.zhang@nokia... Signed-off-by: Ingo Molnar mingo@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- include/linux/sched/sysctl.h | 1 + kernel/sched/core.c | 5 +++-- kernel/sched/rt.c | 1 + kernel/sysctl.c | 2 +- 4 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h index c9e4731cf10b8..7fc36ebc5de33 100644 --- a/include/linux/sched/sysctl.h +++ b/include/linux/sched/sysctl.h @@ -81,6 +81,7 @@ extern unsigned int sysctl_sched_cfs_bandwidth_slice; extern unsigned int sysctl_sched_autogroup_enabled; #endif
+extern int sysctl_sched_rr_timeslice; extern int sched_rr_timeslice;
extern int sched_rr_handler(struct ctl_table *table, int write, diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 14a87c1f3a3ac..4a0a754f24c87 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -8266,8 +8266,9 @@ int sched_rr_handler(struct ctl_table *table, int write, /* make sure that internally we keep jiffies */ /* also, writing zero resets timeslice to default */ if (!ret && write) { - sched_rr_timeslice = sched_rr_timeslice <= 0 ? - RR_TIMESLICE : msecs_to_jiffies(sched_rr_timeslice); + sched_rr_timeslice = + sysctl_sched_rr_timeslice <= 0 ? RR_TIMESLICE : + msecs_to_jiffies(sysctl_sched_rr_timeslice); } mutex_unlock(&mutex); return ret; diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 801b4ec407023..5ee5740635f36 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -9,6 +9,7 @@ #include <linux/irq_work.h>
int sched_rr_timeslice = RR_TIMESLICE; +int sysctl_sched_rr_timeslice = (MSEC_PER_SEC / HZ) * RR_TIMESLICE;
static int do_sched_rt_period_timer(struct rt_bandwidth *rt_b, int overrun);
diff --git a/kernel/sysctl.c b/kernel/sysctl.c index c2dddd335d064..ecbb1b764a82e 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -412,7 +412,7 @@ static struct ctl_table kern_table[] = { }, { .procname = "sched_rr_timeslice_ms", - .data = &sched_rr_timeslice, + .data = &sysctl_sched_rr_timeslice, .maxlen = sizeof(int), .mode = 0644, .proc_handler = sched_rr_handler,
From: Chu Lin linchuyuan@google.com
[ Upstream commit 016983d138cbe99a5c0aaae0103ee88f5300beb3 ]
Per the datasheet for max6697, OVERT mask and ALERT mask are different. For example, the 7th bit of OVERT is the local channel but for alert mask, the 6th bit is the local channel. Therefore, we can't apply the same mask for both registers. In addition to that, the max6697 driver is supposed to be compatibale with different models. I manually went over all the listed chips and made sure all chip types have the same layout.
Testing; mask value of 0x9 should map to 0x44 for ALERT and 0x84 for OVERT. I used iotool to read the reg value back to verify. I only tested this change on max6581.
Reference: https://datasheets.maximintegrated.com/en/ds/MAX6581.pdf https://datasheets.maximintegrated.com/en/ds/MAX6697.pdf https://datasheets.maximintegrated.com/en/ds/MAX6699.pdf
Signed-off-by: Chu Lin linchuyuan@google.com Fixes: 5372d2d71c46e ("hwmon: Driver for Maxim MAX6697 and compatibles") Signed-off-by: Guenter Roeck linux@roeck-us.net Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/hwmon/max6697.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/max6697.c b/drivers/hwmon/max6697.c index f03a71722849a..d4bb3d6aaf18c 100644 --- a/drivers/hwmon/max6697.c +++ b/drivers/hwmon/max6697.c @@ -46,8 +46,9 @@ static const u8 MAX6697_REG_CRIT[] = { * Map device tree / platform data register bit map to chip bit map. * Applies to alert register and over-temperature register. */ -#define MAX6697_MAP_BITS(reg) ((((reg) & 0x7e) >> 1) | \ +#define MAX6697_ALERT_MAP_BITS(reg) ((((reg) & 0x7e) >> 1) | \ (((reg) & 0x01) << 6) | ((reg) & 0x80)) +#define MAX6697_OVERT_MAP_BITS(reg) (((reg) >> 1) | (((reg) & 0x01) << 7))
#define MAX6697_REG_STAT(n) (0x44 + (n))
@@ -586,12 +587,12 @@ static int max6697_init_chip(struct max6697_data *data, return ret;
ret = i2c_smbus_write_byte_data(client, MAX6697_REG_ALERT_MASK, - MAX6697_MAP_BITS(pdata->alert_mask)); + MAX6697_ALERT_MAP_BITS(pdata->alert_mask)); if (ret < 0) return ret;
ret = i2c_smbus_write_byte_data(client, MAX6697_REG_OVERT_MASK, - MAX6697_MAP_BITS(pdata->over_temperature_mask)); + MAX6697_OVERT_MAP_BITS(pdata->over_temperature_mask)); if (ret < 0) return ret;
From: Misono Tomohiro misono.tomohiro@jp.fujitsu.com
[ Upstream commit 8b97f9922211c44a739c5cbd9502ecbb9f17f6d1 ]
Although it rarely happens, we should call free_capabilities() if error happens after read_capabilities() to free allocated strings.
Fixes: de584afa5e188 ("hwmon driver for ACPI 4.0 power meters") Signed-off-by: Misono Tomohiro misono.tomohiro@jp.fujitsu.com Link: https://lore.kernel.org/r/20200625043242.31175-1-misono.tomohiro@jp.fujitsu.... Signed-off-by: Guenter Roeck linux@roeck-us.net Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/hwmon/acpi_power_meter.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/acpi_power_meter.c b/drivers/hwmon/acpi_power_meter.c index e27f7e12c05bb..9b4ad6c74041e 100644 --- a/drivers/hwmon/acpi_power_meter.c +++ b/drivers/hwmon/acpi_power_meter.c @@ -895,7 +895,7 @@ static int acpi_power_meter_add(struct acpi_device *device)
res = setup_attrs(resource); if (res) - goto exit_free; + goto exit_free_capability;
resource->hwmon_dev = hwmon_device_register(&device->dev); if (IS_ERR(resource->hwmon_dev)) { @@ -908,6 +908,8 @@ static int acpi_power_meter_add(struct acpi_device *device)
exit_remove: remove_attrs(resource); +exit_free_capability: + free_capabilities(resource); exit_free: kfree(resource); exit:
From: Hou Tao houtao1@huawei.com
[ Upstream commit e7eea44eefbdd5f0345a0a8b80a3ca1c21030d06 ]
Else there will be memory leak if alloc_disk() fails.
Fixes: 6a27b656fc02 ("block: virtio-blk: support multi virt queues per virtio-blk device") Signed-off-by: Hou Tao houtao1@huawei.com Reviewed-by: Stefano Garzarella sgarzare@redhat.com Reviewed-by: Ming Lei ming.lei@redhat.com Signed-off-by: Jens Axboe axboe@kernel.dk Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/block/virtio_blk.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 1e5cd39d0cc2f..bdc3efacd0d25 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -757,6 +757,7 @@ static int virtblk_probe(struct virtio_device *vdev) put_disk(vblk->disk); out_free_vq: vdev->config->del_vqs(vdev); + kfree(vblk->vqs); out_free_vblk: kfree(vblk); out_free_index:
From: Chris Packham chris.packham@alliedtelesis.co.nz
[ Upstream commit cd217f2300793a106b49c7dfcbfb26e348bc7593 ]
The PCA9665 datasheet says that I2CSTA = 78h indicates that SCL is stuck low, this differs to the PCA9564 which uses 90h for this indication. Treat either 0x78 or 0x90 as an indication that the SCL line is stuck.
Based on looking through the PCA9564 and PCA9665 datasheets this should be safe for both chips. The PCA9564 should not return 0x78 for any valid state and the PCA9665 should not return 0x90.
Fixes: eff9ec95efaa ("i2c-algo-pca: Add PCA9665 support") Signed-off-by: Chris Packham chris.packham@alliedtelesis.co.nz Reviewed-by: Andy Shevchenko andriy.shevchenko@linux.intel.com Signed-off-by: Wolfram Sang wsa@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/i2c/algos/i2c-algo-pca.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/algos/i2c-algo-pca.c b/drivers/i2c/algos/i2c-algo-pca.c index e370804ec8bc6..3a9db4626cb60 100644 --- a/drivers/i2c/algos/i2c-algo-pca.c +++ b/drivers/i2c/algos/i2c-algo-pca.c @@ -326,7 +326,8 @@ static int pca_xfer(struct i2c_adapter *i2c_adap, DEB2("BUS ERROR - SDA Stuck low\n"); pca_reset(adap); goto out; - case 0x90: /* Bus error - SCL stuck low */ + case 0x78: /* Bus error - SCL stuck low (PCA9665) */ + case 0x90: /* Bus error - SCL stuck low (PCA9564) */ DEB2("BUS ERROR - SCL Stuck low\n"); pca_reset(adap); goto out;
From: Greg Kroah-Hartman gregkh@linuxfoundation.org
This reverts commit 02c56650f3c118d3752122996d96173d26bb13aa which is commit f0bd62b64016508938df9babe47f65c2c727d25c upstream.
It causes a number of reported issues and a fix for it has not hit Linus's tree yet. Revert this to resolve those problems.
Cc: Alexander Tsoy alexander@tsoy.me Cc: Takashi Iwai tiwai@suse.de Cc: Sasha Levin sashal@kernel.org Cc: Hans de Goede jwrdegoede@fedoraproject.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- sound/usb/card.h | 4 ---- sound/usb/endpoint.c | 43 +++++-------------------------------------- sound/usb/endpoint.h | 1 - sound/usb/pcm.c | 2 -- 4 files changed, 5 insertions(+), 45 deletions(-)
--- a/sound/usb/card.h +++ b/sound/usb/card.h @@ -80,10 +80,6 @@ struct snd_usb_endpoint { dma_addr_t sync_dma; /* DMA address of syncbuf */
unsigned int pipe; /* the data i/o pipe */ - unsigned int framesize[2]; /* small/large frame sizes in samples */ - unsigned int sample_rem; /* remainder from division fs/fps */ - unsigned int sample_accum; /* sample accumulator */ - unsigned int fps; /* frames per second */ unsigned int freqn; /* nominal sampling rate in fs/fps in Q16.16 format */ unsigned int freqm; /* momentary sampling rate in fs/fps in Q16.16 format */ int freqshift; /* how much to shift the feedback value to get Q16.16 */ --- a/sound/usb/endpoint.c +++ b/sound/usb/endpoint.c @@ -137,12 +137,12 @@ int snd_usb_endpoint_implicit_feedback_s
/* * For streaming based on information derived from sync endpoints, - * prepare_outbound_urb_sizes() will call slave_next_packet_size() to + * prepare_outbound_urb_sizes() will call next_packet_size() to * determine the number of samples to be sent in the next packet. * - * For implicit feedback, slave_next_packet_size() is unused. + * For implicit feedback, next_packet_size() is unused. */ -int snd_usb_endpoint_slave_next_packet_size(struct snd_usb_endpoint *ep) +int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep) { unsigned long flags; int ret; @@ -159,29 +159,6 @@ int snd_usb_endpoint_slave_next_packet_s return ret; }
-/* - * For adaptive and synchronous endpoints, prepare_outbound_urb_sizes() - * will call next_packet_size() to determine the number of samples to be - * sent in the next packet. - */ -int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep) -{ - int ret; - - if (ep->fill_max) - return ep->maxframesize; - - ep->sample_accum += ep->sample_rem; - if (ep->sample_accum >= ep->fps) { - ep->sample_accum -= ep->fps; - ret = ep->framesize[1]; - } else { - ret = ep->framesize[0]; - } - - return ret; -} - static void retire_outbound_urb(struct snd_usb_endpoint *ep, struct snd_urb_ctx *urb_ctx) { @@ -226,8 +203,6 @@ static void prepare_silent_urb(struct sn
if (ctx->packet_size[i]) counts = ctx->packet_size[i]; - else if (ep->sync_master) - counts = snd_usb_endpoint_slave_next_packet_size(ep); else counts = snd_usb_endpoint_next_packet_size(ep);
@@ -904,17 +879,10 @@ int snd_usb_endpoint_set_params(struct s ep->maxpacksize = fmt->maxpacksize; ep->fill_max = !!(fmt->attributes & UAC_EP_CS_ATTR_FILL_MAX);
- if (snd_usb_get_speed(ep->chip->dev) == USB_SPEED_FULL) { + if (snd_usb_get_speed(ep->chip->dev) == USB_SPEED_FULL) ep->freqn = get_usb_full_speed_rate(rate); - ep->fps = 1000; - } else { + else ep->freqn = get_usb_high_speed_rate(rate); - ep->fps = 8000; - } - - ep->sample_rem = rate % ep->fps; - ep->framesize[0] = rate / ep->fps; - ep->framesize[1] = (rate + (ep->fps - 1)) / ep->fps;
/* calculate the frequency in 16.16 format */ ep->freqm = ep->freqn; @@ -973,7 +941,6 @@ int snd_usb_endpoint_start(struct snd_us ep->active_mask = 0; ep->unlink_mask = 0; ep->phase = 0; - ep->sample_accum = 0;
snd_usb_endpoint_start_quirk(ep);
--- a/sound/usb/endpoint.h +++ b/sound/usb/endpoint.h @@ -27,7 +27,6 @@ void snd_usb_endpoint_release(struct snd void snd_usb_endpoint_free(struct snd_usb_endpoint *ep);
int snd_usb_endpoint_implicit_feedback_sink(struct snd_usb_endpoint *ep); -int snd_usb_endpoint_slave_next_packet_size(struct snd_usb_endpoint *ep); int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep);
void snd_usb_handle_sync_urb(struct snd_usb_endpoint *ep, --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -1473,8 +1473,6 @@ static void prepare_playback_urb(struct for (i = 0; i < ctx->packets; i++) { if (ctx->packet_size[i]) counts = ctx->packet_size[i]; - else if (ep->sync_master) - counts = snd_usb_endpoint_slave_next_packet_size(ep); else counts = snd_usb_endpoint_next_packet_size(ep);
On Tue, 07 Jul 2020 17:10:17 +0200, Greg Kroah-Hartman wrote:
From: Greg Kroah-Hartman gregkh@linuxfoundation.org
This reverts commit 02c56650f3c118d3752122996d96173d26bb13aa which is commit f0bd62b64016508938df9babe47f65c2c727d25c upstream.
It causes a number of reported issues and a fix for it has not hit Linus's tree yet.
FYI, I'm going to send a pull request to Linus in tomorrow. So the fix will be available in a couple of days. Though...
Revert this to resolve those problems.
... I'm not against the revert itself if this needs to be addressed right now.
thanks,
Takashi
Cc: Alexander Tsoy alexander@tsoy.me Cc: Takashi Iwai tiwai@suse.de Cc: Sasha Levin sashal@kernel.org Cc: Hans de Goede jwrdegoede@fedoraproject.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
sound/usb/card.h | 4 ---- sound/usb/endpoint.c | 43 +++++-------------------------------------- sound/usb/endpoint.h | 1 - sound/usb/pcm.c | 2 -- 4 files changed, 5 insertions(+), 45 deletions(-)
--- a/sound/usb/card.h +++ b/sound/usb/card.h @@ -80,10 +80,6 @@ struct snd_usb_endpoint { dma_addr_t sync_dma; /* DMA address of syncbuf */ unsigned int pipe; /* the data i/o pipe */
- unsigned int framesize[2]; /* small/large frame sizes in samples */
- unsigned int sample_rem; /* remainder from division fs/fps */
- unsigned int sample_accum; /* sample accumulator */
- unsigned int fps; /* frames per second */ unsigned int freqn; /* nominal sampling rate in fs/fps in Q16.16 format */ unsigned int freqm; /* momentary sampling rate in fs/fps in Q16.16 format */ int freqshift; /* how much to shift the feedback value to get Q16.16 */
--- a/sound/usb/endpoint.c +++ b/sound/usb/endpoint.c @@ -137,12 +137,12 @@ int snd_usb_endpoint_implicit_feedback_s /*
- For streaming based on information derived from sync endpoints,
- prepare_outbound_urb_sizes() will call slave_next_packet_size() to
- prepare_outbound_urb_sizes() will call next_packet_size() to
- determine the number of samples to be sent in the next packet.
- For implicit feedback, slave_next_packet_size() is unused.
*/
- For implicit feedback, next_packet_size() is unused.
-int snd_usb_endpoint_slave_next_packet_size(struct snd_usb_endpoint *ep) +int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep) { unsigned long flags; int ret; @@ -159,29 +159,6 @@ int snd_usb_endpoint_slave_next_packet_s return ret; } -/*
- For adaptive and synchronous endpoints, prepare_outbound_urb_sizes()
- will call next_packet_size() to determine the number of samples to be
- sent in the next packet.
- */
-int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep) -{
- int ret;
- if (ep->fill_max)
return ep->maxframesize;- ep->sample_accum += ep->sample_rem;
- if (ep->sample_accum >= ep->fps) {
ep->sample_accum -= ep->fps;ret = ep->framesize[1];- } else {
ret = ep->framesize[0];- }
- return ret;
-}
static void retire_outbound_urb(struct snd_usb_endpoint *ep, struct snd_urb_ctx *urb_ctx) { @@ -226,8 +203,6 @@ static void prepare_silent_urb(struct sn if (ctx->packet_size[i]) counts = ctx->packet_size[i];
else if (ep->sync_master)counts = snd_usb_endpoint_slave_next_packet_size(ep);@@ -904,17 +879,10 @@ int snd_usb_endpoint_set_params(struct s ep->maxpacksize = fmt->maxpacksize; ep->fill_max = !!(fmt->attributes & UAC_EP_CS_ATTR_FILL_MAX);
- if (snd_usb_get_speed(ep->chip->dev) == USB_SPEED_FULL) {
- if (snd_usb_get_speed(ep->chip->dev) == USB_SPEED_FULL) ep->freqn = get_usb_full_speed_rate(rate);
ep->fps = 1000;- } else {
- else ep->freqn = get_usb_high_speed_rate(rate);
ep->fps = 8000;- }
- ep->sample_rem = rate % ep->fps;
- ep->framesize[0] = rate / ep->fps;
- ep->framesize[1] = (rate + (ep->fps - 1)) / ep->fps;
/* calculate the frequency in 16.16 format */ ep->freqm = ep->freqn; @@ -973,7 +941,6 @@ int snd_usb_endpoint_start(struct snd_us ep->active_mask = 0; ep->unlink_mask = 0; ep->phase = 0;
- ep->sample_accum = 0;
snd_usb_endpoint_start_quirk(ep); --- a/sound/usb/endpoint.h +++ b/sound/usb/endpoint.h @@ -27,7 +27,6 @@ void snd_usb_endpoint_release(struct snd void snd_usb_endpoint_free(struct snd_usb_endpoint *ep); int snd_usb_endpoint_implicit_feedback_sink(struct snd_usb_endpoint *ep); -int snd_usb_endpoint_slave_next_packet_size(struct snd_usb_endpoint *ep); int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep); void snd_usb_handle_sync_urb(struct snd_usb_endpoint *ep, --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -1473,8 +1473,6 @@ static void prepare_playback_urb(struct for (i = 0; i < ctx->packets; i++) { if (ctx->packet_size[i]) counts = ctx->packet_size[i];
else if (ep->sync_master)counts = snd_usb_endpoint_slave_next_packet_size(ep);
On Tue, Jul 07, 2020 at 05:13:59PM +0200, Takashi Iwai wrote:
On Tue, 07 Jul 2020 17:10:17 +0200, Greg Kroah-Hartman wrote:
From: Greg Kroah-Hartman gregkh@linuxfoundation.org
This reverts commit 02c56650f3c118d3752122996d96173d26bb13aa which is commit f0bd62b64016508938df9babe47f65c2c727d25c upstream.
It causes a number of reported issues and a fix for it has not hit Linus's tree yet.
FYI, I'm going to send a pull request to Linus in tomorrow. So the fix will be available in a couple of days. Though...
Revert this to resolve those problems.
... I'm not against the revert itself if this needs to be addressed right now.
It kind of does, I've gotten lots of distro complaints about it. As the original wasn't originally tagged for stable, we should just revert it for now so that people have working systems again.
thanks,
greg k-h
From: Paul Aurich paul@darkrain42.org
commit cc15461c73d7d044d56c47e869a215e49bd429c8 upstream.
Ensure multiuser SMB3 mounts use encryption for all users' tcons if the mount options are configured to require encryption. Without this, only the primary tcon and IPC tcons are guaranteed to be encrypted. Per-user tcons would only be encrypted if the server was configured to require encryption.
Signed-off-by: Paul Aurich paul@darkrain42.org CC: Stable stable@vger.kernel.org Signed-off-by: Steve French stfrench@microsoft.com Reviewed-by: Aurelien Aptel aaptel@suse.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- fs/cifs/connect.c | 1 + 1 file changed, 1 insertion(+)
--- a/fs/cifs/connect.c +++ b/fs/cifs/connect.c @@ -4206,6 +4206,7 @@ cifs_construct_tcon(struct cifs_sb_info vol_info->no_linux_ext = !master_tcon->unix_ext; vol_info->sectype = master_tcon->ses->sectype; vol_info->sign = master_tcon->ses->sign; + vol_info->seal = master_tcon->seal;
rc = cifs_set_vol_auth(vol_info, master_tcon->ses); if (rc) {
From: Paul Aurich paul@darkrain42.org
commit 00dfbc2f9c61185a2e662f27c45a0bb29b2a134f upstream.
Without this:
- persistent handles will only be enabled for per-user tcons if the server advertises the 'Continuous Availabity' capability - resilient handles would never be enabled for per-user tcons
Signed-off-by: Paul Aurich paul@darkrain42.org CC: Stable stable@vger.kernel.org Signed-off-by: Steve French stfrench@microsoft.com Reviewed-by: Aurelien Aptel aaptel@suse.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- fs/cifs/connect.c | 2 ++ 1 file changed, 2 insertions(+)
--- a/fs/cifs/connect.c +++ b/fs/cifs/connect.c @@ -4203,6 +4203,8 @@ cifs_construct_tcon(struct cifs_sb_info vol_info->retry = master_tcon->retry; vol_info->nocase = master_tcon->nocase; vol_info->local_lease = master_tcon->local_lease; + vol_info->resilient = master_tcon->use_resilient; + vol_info->persistent = master_tcon->use_persistent; vol_info->no_linux_ext = !master_tcon->unix_ext; vol_info->sectype = master_tcon->ses->sectype; vol_info->sign = master_tcon->ses->sign;
From: Zhang Xiaoxu zhangxiaoxu5@huawei.com
commit 9ffad9263b467efd8f8dc7ae1941a0a655a2bab2 upstream.
When xfstest generic/035, we found the target file was deleted if the rename return -EACESS.
In cifs_rename2, we unlink the positive target dentry if rename failed with EACESS or EEXIST, even if the target dentry is positived before rename. Then the existing file was deleted.
We should just delete the target file which created during the rename.
Reported-by: Hulk Robot hulkci@huawei.com Signed-off-by: Zhang Xiaoxu zhangxiaoxu5@huawei.com Cc: stable@vger.kernel.org Signed-off-by: Steve French stfrench@microsoft.com Reviewed-by: Aurelien Aptel aaptel@suse.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- fs/cifs/inode.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
--- a/fs/cifs/inode.c +++ b/fs/cifs/inode.c @@ -1737,6 +1737,7 @@ cifs_rename2(struct inode *source_dir, s FILE_UNIX_BASIC_INFO *info_buf_target; unsigned int xid; int rc, tmprc; + bool new_target = d_really_is_negative(target_dentry);
if (flags & ~RENAME_NOREPLACE) return -EINVAL; @@ -1813,8 +1814,13 @@ cifs_rename2(struct inode *source_dir, s */
unlink_target: - /* Try unlinking the target dentry if it's not negative */ - if (d_really_is_positive(target_dentry) && (rc == -EACCES || rc == -EEXIST)) { + /* + * If the target dentry was created during the rename, try + * unlinking it if it's not negative + */ + if (new_target && + d_really_is_positive(target_dentry) && + (rc == -EACCES || rc == -EEXIST)) { if (d_is_dir(target_dentry)) tmprc = cifs_rmdir(target_dir, target_dentry); else
From: Hauke Mehrtens hauke@hauke-m.de
commit fcec538ef8cca0ad0b84432235dccd9059c8e6f8 upstream.
This resolves the hazard between the mtc0 in the change_c0_status() and the mfc0 in configure_exception_vector(). Without resolving this hazard configure_exception_vector() could read an old value and would restore this old value again. This would revert the changes change_c0_status() did. I checked this by printing out the read_c0_status() at the end of per_cpu_trap_init() and the ST0_MX is not set without this patch.
The hazard is documented in the MIPS Architecture Reference Manual Vol. III: MIPS32/microMIPS32 Privileged Resource Architecture (MD00088), rev 6.03 table 8.1 which includes:
Producer | Consumer | Hazard ----------|----------|---------------------------- mtc0 | mfc0 | any coprocessor 0 register
I saw this hazard on an Atheros AR9344 rev 2 SoC with a MIPS 74Kc CPU. There the change_c0_status() function would activate the DSPen by setting ST0_MX in the c0_status register. This was reverted and then the system got a DSP exception when the DSP registers were saved in save_dsp() in the first process switch. The crash looks like this:
[ 0.089999] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.097796] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.107070] Kernel panic - not syncing: Unexpected DSP exception [ 0.113470] Rebooting in 1 seconds..
We saw this problem in OpenWrt only on the MIPS 74Kc based Atheros SoCs, not on the 24Kc based SoCs. We only saw it with kernel 5.4 not with kernel 4.19, in addition we had to use GCC 8.4 or 9.X, with GCC 8.3 it did not happen.
In the kernel I bisected this problem to commit 9012d011660e ("compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING"), but when this was reverted it also happened after commit 172dcd935c34b ("MIPS: Always allocate exception vector for MIPSr2+").
Commit 0b24cae4d535 ("MIPS: Add missing EHB in mtc0 -> mfc0 sequence.") does similar changes to a different file. I am not sure if there are more places affected by this problem.
Signed-off-by: Hauke Mehrtens hauke@hauke-m.de Cc: stable@vger.kernel.org Signed-off-by: Thomas Bogendoerfer tsbogend@alpha.franken.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- arch/mips/kernel/traps.c | 1 + 1 file changed, 1 insertion(+)
--- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -2080,6 +2080,7 @@ static void configure_status(void)
change_c0_status(ST0_CU|ST0_MX|ST0_RE|ST0_FR|ST0_BEV|ST0_TS|ST0_KX|ST0_SX|ST0_UX, status_set); + back_to_back_c0_hazard(); }
/* configure HWRENA register */
From: Vasily Averin vvs@virtuozzo.com
Could you please push this patch into stable@? it fixes memory corruption in kernels v3.5 .. v4.10
Lost .data_len definition leads to write beyond end of struct nf_ct_h323_master. Usually it corrupts following struct nf_conn_nat, however if nat is not loaded it corrupts following slab object.
In mainline this problem went away in v4.11, after commit 9f0f3ebeda47 ("netfilter: helpers: remove data_len usage for inkernel helpers") however many stable kernels are still affected.
Fixes: 1afc56794e03 ("netfilter: nf_ct_helper: implement variable length helper private data") # v3.5 cc: stable@vger.kernel.org Reviewed-by: Florian Westphal fw@strlen.de Signed-off-by: Vasily Averin vvs@virtuozzo.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- net/netfilter/nf_conntrack_h323_main.c | 1 + 1 file changed, 1 insertion(+)
--- a/net/netfilter/nf_conntrack_h323_main.c +++ b/net/netfilter/nf_conntrack_h323_main.c @@ -1225,6 +1225,7 @@ static struct nf_conntrack_helper nf_con { .name = "Q.931", .me = THIS_MODULE, + .data_len = sizeof(struct nf_ct_h323_master), .tuple.src.l3num = AF_INET6, .tuple.src.u.tcp.port = cpu_to_be16(Q931_PORT), .tuple.dst.protonum = IPPROTO_TCP,
On Tue, 7 Jul 2020 at 20:41, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.4.230 release. There are 19 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Jul 2020 14:57:34 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.230-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386.
Summary ------------------------------------------------------------------------
kernel: 4.4.230-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: c19eba6b34341e17e0a49be45b010f483dd95de7 git describe: v4.4.229-20-gc19eba6b3434 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.229-20-...
No regressions (compared to build v4.4.228-155-gc19eba6b3434)
No fixes (compared to build v4.4.228-155-gc19eba6b3434)
Ran 17904 total tests in the following environments and test suites.
Environments -------------- - i386 - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - x15 - arm - x86_64 - x86-kasan
Test Suites ----------- * build * kselftest * kselftest/drivers * kselftest/filesystems * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * network-basic-tests * perf * v4l2-compliance * kvm-unit-tests * install-android-platform-tools-r2600 * install-android-platform-tools-r2800 * kselftest/net * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-native/drivers * kselftest-vsyscall-mode-native/filesystems * kselftest-vsyscall-mode-none * kselftest-vsyscall-mode-none/drivers * kselftest-vsyscall-mode-none/filesystems
Summary ------------------------------------------------------------------------
kernel: 4.4.230-rc1 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.230-rc1-hikey-20200707-761 git commit: 1e4ecd8e5eab1c328ff83cd29d52021eb6035bc8 git describe: 4.4.230-rc1-hikey-20200707-761 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.2...
No regressions (compared to build 4.4.229-rc1-hikey-20200629-759)
No fixes (compared to build 4.4.229-rc1-hikey-20200629-759)
Ran 1861 total tests in the following environments and test suites.
Environments -------------- - hi6220-hikey - arm64
Test Suites ----------- * build * install-android-platform-tools-r2600 * kselftest * kselftest/drivers * kselftest/filesystems * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * spectre-meltdown-checker-test * v4l2-compliance
On 07/07/2020 16:10, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.230 release. There are 19 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Jul 2020 14:57:34 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.230-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below.
thanks,
greg k-h
All tests are passing for Tegra ...
Test results for stable-v4.4: 6 builds: 6 pass, 0 fail 12 boots: 12 pass, 0 fail 25 tests: 25 pass, 0 fail
Linux version: 4.4.230-rc1-gc19eba6b3434 Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra30-cardhu-a04
Cheers Jon
Kind regards, Chris
-----Original Message----- From: stable-owner@vger.kernel.org stable-owner@vger.kernel.org On Behalf Of Greg Kroah-Hartman Sent: 07 July 2020 16:10 To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman gregkh@linuxfoundation.org; torvalds@linux- foundation.org; akpm@linux-foundation.org; linux@roeck-us.net; shuah@kernel.org; patches@kernelci.org; ben.hutchings@codethink.co.uk; lkft-triage@lists.linaro.org; stable@vger.kernel.org Subject: [PATCH 4.4 00/19] 4.4.230-rc1 review
This is the start of the stable review cycle for the 4.4.230 release. There are 19 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Jul 2020 14:57:34 +0000. Anything received after that time might be too late.
No build/boot issues seen for CIP configs with Linux 4.4.230-rc1 (c19eba6b3434).
Build/test pipeline/logs: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/16... GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master... Relevant LAVA jobs: https://lava.ciplatform.org/scheduler/alljobs?length=25&search=c19eba#ta...
Kind regards, Chris
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable- review/patch-4.4.230-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable- rc.git linux-4.4.y and the diffstat can be found below.
thanks,
greg k-h
Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.4.230-rc1
Vasily Averin vvs@virtuozzo.com netfilter: nf_conntrack_h323: lost .data_len definition for Q.931/ipv6
Hauke Mehrtens hauke@hauke-m.de MIPS: Add missing EHB in mtc0 -> mfc0 sequence for DSPen
Zhang Xiaoxu zhangxiaoxu5@huawei.com cifs: Fix the target file was deleted when rename failed.
Paul Aurich paul@darkrain42.org SMB3: Honor persistent/resilient handle flags for multiuser mounts
Paul Aurich paul@darkrain42.org SMB3: Honor 'seal' flag for multiuser mounts
Greg Kroah-Hartman gregkh@linuxfoundation.org Revert "ALSA: usb-audio: Improve frames size computation"
Chris Packham chris.packham@alliedtelesis.co.nz i2c: algo-pca: Add 0x78 as SCL stuck low status for PCA9665
Hou Tao houtao1@huawei.com virtio-blk: free vblk-vqs in error path of virtblk_probe()
Misono Tomohiro misono.tomohiro@jp.fujitsu.com hwmon: (acpi_power_meter) Fix potential memory leak in acpi_power_meter_add()
Chu Lin linchuyuan@google.com hwmon: (max6697) Make sure the OVERT mask is set correctly
Shile Zhang shile.zhang@nokia.com sched/rt: Show the 'sched_rr_timeslice' SCHED_RR timeslice tuning knob in milliseconds
Herbert Xu herbert@gondor.apana.org.au crypto: af_alg - fix use-after-free in af_alg_accept() due to bh_lock_sock()
Douglas Anderson dianders@chromium.org kgdb: Avoid suspicious RCU usage warning
Zqiang qiang.zhang@windriver.com usb: usbtest: fix missing kfree(dev->buf) in usbtest_disconnect
Qian Cai cai@lca.pw mm/slub: fix stack overruns with SLUB_STATS
Borislav Petkov bp@suse.de EDAC/amd64: Read back the scrub rate PCI register on F15h
Hugh Dickins hughd@google.com mm: fix swap cache node allocation mask
Filipe Manana fdmanana@suse.com btrfs: fix data block group relocation failure due to concurrent scrub
Anand Jain Anand.Jain@oracle.com btrfs: cow_file_range() num_bytes and disk_num_bytes are same
Diffstat:
Makefile | 4 ++-- arch/mips/kernel/traps.c | 1 + crypto/af_alg.c | 26 +++++++++----------- crypto/algif_aead.c | 9 +++---- crypto/algif_hash.c | 9 +++---- crypto/algif_skcipher.c | 9 +++---- drivers/block/virtio_blk.c | 1 + drivers/edac/amd64_edac.c | 2 ++ drivers/hwmon/acpi_power_meter.c | 4 +++- drivers/hwmon/max6697.c | 7 +++--- drivers/i2c/algos/i2c-algo-pca.c | 3 ++- drivers/usb/misc/usbtest.c | 1 + fs/btrfs/inode.c | 36 ++++++++++++++++++++-------- fs/cifs/connect.c | 3 +++ fs/cifs/inode.c | 10 ++++++-- include/crypto/if_alg.h | 4 ++-- include/linux/sched/sysctl.h | 1 + kernel/debug/debug_core.c | 4 ++++ kernel/sched/core.c | 5 ++-- kernel/sched/rt.c | 1 + kernel/sysctl.c | 2 +- mm/slub.c | 3 ++- mm/swap_state.c | 3 ++- net/netfilter/nf_conntrack_h323_main.c | 1 + sound/usb/card.h | 4 ---- sound/usb/endpoint.c | 43 ++++------------------------------ sound/usb/endpoint.h | 1 - sound/usb/pcm.c | 2 -- 28 files changed, 95 insertions(+), 104 deletions(-)
On 7/7/20 9:10 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.230 release. There are 19 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Jul 2020 14:57:34 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.230-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks, -- Shuah
On Tue, Jul 07, 2020 at 05:10:03PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.230 release. There are 19 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 09 Jul 2020 14:57:34 +0000. Anything received after that time might be too late.
Build results: total: 169 pass: 169 fail: 0 Qemu test results: total: 332 pass: 332 fail: 0
Guenter
linux-stable-mirror@lists.linaro.org
-
Chris Paterson -
Greg Kroah-Hartman -
Guenter Roeck -
Jon Hunter -
Naresh Kamboju -
Shuah Khan -
Takashi Iwai