4.19.132-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 4.19.132-rc1 review
This is the start of the stable review cycle for the 4.19.132 release. There are 36 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.19.132-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.19.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.19.132-rc1
Peter Jones <[email protected]>
efi: Make it possible to disable efivar_ssdt entirely
Hou Tao <[email protected]>
dm zoned: assign max_io_len correctly
Marc Zyngier <[email protected]>
irqchip/gic: Atomically update affinity
Hauke Mehrtens <[email protected]>
MIPS: Add missing EHB in mtc0 -> mfc0 sequence for DSPen
Zhang Xiaoxu <[email protected]>
cifs: Fix the target file was deleted when rename failed.
Paul Aurich <[email protected]>
SMB3: Honor lease disabling for multiuser mounts
Paul Aurich <[email protected]>
SMB3: Honor persistent/resilient handle flags for multiuser mounts
Paul Aurich <[email protected]>
SMB3: Honor 'seal' flag for multiuser mounts
Greg Kroah-Hartman <[email protected]>
Revert "ALSA: usb-audio: Improve frames size computation"
J. Bruce Fields <[email protected]>
nfsd: apply umask on fs without ACL support
Wolfram Sang <[email protected]>
i2c: mlxcpld: check correct size of maximum RECV_LEN packet
Chris Packham <[email protected]>
i2c: algo-pca: Add 0x78 as SCL stuck low status for PCA9665
Christoph Hellwig <[email protected]>
nvme: fix a crash in nvme_mpath_add_disk
Paul Aurich <[email protected]>
SMB3: Honor 'posix' flag for multiuser mounts
Hou Tao <[email protected]>
virtio-blk: free vblk-vqs in error path of virtblk_probe()
Chen-Yu Tsai <[email protected]>
drm: sun4i: hdmi: Remove extra HPD polling
Misono Tomohiro <[email protected]>
hwmon: (acpi_power_meter) Fix potential memory leak in acpi_power_meter_add()
Chu Lin <[email protected]>
hwmon: (max6697) Make sure the OVERT mask is set correctly
Rahul Lakkireddy <[email protected]>
cxgb4: fix SGE queue dump destination buffer context
Rahul Lakkireddy <[email protected]>
cxgb4: use correct type for all-mask IP address comparison
Rahul Lakkireddy <[email protected]>
cxgb4: parse TC-U32 key values and masks natively
Rahul Lakkireddy <[email protected]>
cxgb4: use unaligned conversion for fetching timestamp
Chen Tao <[email protected]>
drm/msm/dpu: fix error return code in dpu_encoder_init
Herbert Xu <[email protected]>
crypto: af_alg - fix use-after-free in af_alg_accept() due to bh_lock_sock()
Douglas Anderson <[email protected]>
kgdb: Avoid suspicious RCU usage warning
Anton Eidelman <[email protected]>
nvme-multipath: fix deadlock between ana_work and scan_work
Sagi Grimberg <[email protected]>
nvme: fix possible deadlock when I/O is blocked
Keith Busch <[email protected]>
nvme-multipath: set bdi capabilities once
Christian Borntraeger <[email protected]>
s390/debug: avoid kernel warning on too large number of pages
Zqiang <[email protected]>
usb: usbtest: fix missing kfree(dev->buf) in usbtest_disconnect
Qian Cai <[email protected]>
mm/slub: fix stack overruns with SLUB_STATS
Dongli Zhang <[email protected]>
mm/slub.c: fix corrupted freechain in deactivate_slab()
Tuomas Tynkkynen <[email protected]>
usbnet: smsc95xx: Fix use-after-free after removal
Borislav Petkov <[email protected]>
EDAC/amd64: Read back the scrub rate PCI register on F15h
Hugh Dickins <[email protected]>
mm: fix swap cache node allocation mask
Filipe Manana <[email protected]>
btrfs: fix a block group ref counter leak after failure to remove block group
-------------
Diffstat:
Makefile | 4 +- arch/mips/kernel/traps.c | 1 + arch/s390/kernel/debug.c | 3 +- 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/firmware/efi/Kconfig | 11 ++ drivers/firmware/efi/efi.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +- drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 5 +- drivers/hwmon/acpi_power_meter.c | 4 +- drivers/hwmon/max6697.c | 7 +- drivers/i2c/algos/i2c-algo-pca.c | 3 +- drivers/i2c/busses/i2c-mlxcpld.c | 4 +- drivers/irqchip/irq-gic.c | 14 +-- drivers/md/dm-zoned-target.c | 2 +- drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c | 6 +- drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c | 10 +- drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c | 18 +-- .../ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h | 122 ++++++++++++++------- drivers/net/ethernet/chelsio/cxgb4/sge.c | 2 +- drivers/net/usb/smsc95xx.c | 2 +- drivers/nvme/host/core.c | 1 - drivers/nvme/host/multipath.c | 33 ++++-- drivers/usb/misc/usbtest.c | 1 + fs/btrfs/extent-tree.c | 19 ++-- fs/cifs/connect.c | 9 +- fs/cifs/inode.c | 10 +- fs/nfsd/vfs.c | 6 + include/crypto/if_alg.h | 4 +- kernel/debug/debug_core.c | 4 + mm/slub.c | 30 ++++- mm/swap_state.c | 3 +- sound/usb/card.h | 4 - sound/usb/endpoint.c | 43 +------- sound/usb/endpoint.h | 1 - sound/usb/pcm.c | 2 - 40 files changed, 256 insertions(+), 192 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/36 btrfs: fix a block group ref counter leak after failure to remove block group
From: Filipe Manana <[email protected]>
[ Upstream commit 9fecd13202f520f3f25d5b1c313adb740fe19773 ]
When removing a block group, if we fail to delete the block group's item from the extent tree, we jump to the 'out' label and end up decrementing the block group's reference count once only (by 1), resulting in a counter leak because the block group at that point was already removed from the block group cache rbtree - so we have to decrement the reference count twice, once for the rbtree and once for our lookup at the start of the function.
There is a second bug where if removing the free space tree entries (the call to remove_block_group_free_space()) fails we end up jumping to the 'out_put_group' label but end up decrementing the reference count only once, when we should have done it twice, since we have already removed the block group from the block group cache rbtree. This happens because the reference count decrement for the rbtree reference happens after attempting to remove the free space tree entries, which is far away from the place where we remove the block group from the rbtree.
To make things less error prone, decrement the reference count for the rbtree immediately after removing the block group from it. This also eleminates the need for two different exit labels on error, renaming 'out_put_label' to just 'out' and removing the old 'out'.
--- fs/btrfs/extent-tree.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-)
fs/btrfs/extent-tree.c +9 -10
@@ -10286,7 +10286,7 @@ int btrfs_remove_block_group(struct btrfs_trans_handle *trans, path =btrfs_alloc_path ();if (!path) { ret = -ENOMEM ; - goto out_put_group; + goto out; }/*
@@ -10323,7 +10323,7 @@ int btrfs_remove_block_group(struct btrfs_trans_handle *trans, ret =btrfs_orphan_add (trans,BTRFS_I (inode));if (ret) {btrfs_add_delayed_iput (inode); - goto out_put_group; + goto out; }clear_nlink (inode);/* One for the block groups ref */
@@ -10346,13 +10346,13 @@ int btrfs_remove_block_group(struct btrfs_trans_handle *trans, ret =btrfs_search_slot (trans, tree_root, &key, path,-1 ,1 );if (ret <0 ) - goto out_put_group; + goto out;if (ret >0 )btrfs_release_path (path);if (ret ==0 ) { ret =btrfs_del_item (trans, tree_root, path);if (ret) - goto out_put_group; + goto out;btrfs_release_path (path); }
@@ -10361,6 +10361,9 @@ int btrfs_remove_block_group(struct btrfs_trans_handle *trans, &fs_info->block_group_cache_tree);RB_CLEAR_NODE (&block_group->cache_node); +/* Once for the block groups rbtree */ +btrfs_put_block_group (block_group); +if (fs_info->first_logical_byte == block_group->key.objectid) fs_info->first_logical_byte = (u64)-1 ;spin_unlock (&fs_info->block_group_cache_lock);
@@ -10494,10 +10497,7 @@ int btrfs_remove_block_group(struct btrfs_trans_handle *trans, ret =remove_block_group_free_space (trans, block_group);if (ret) - goto out_put_group; - -/* Once for the block groups rbtree */ -btrfs_put_block_group (block_group); + goto out; ret =btrfs_search_slot (trans, root, &key, path,-1 ,1 );if (ret >0 )
@@ -10525,10 +10525,9 @@ int btrfs_remove_block_group(struct btrfs_trans_handle *trans,free_extent_map (em); } -out_put_group: +out:/* Once for the lookup reference */ btrfs_put_block_group (block_group); -out:btrfs_free_path (path);return ret; }
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 2/36 mm: fix swap cache node allocation mask
In reply to Greg Kroah-HartmanFrom: Hugh Dickins <[email protected]>
[ 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/0xa9Reported 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.
--- mm/swap_state.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
mm/swap_state.c +2 -1
@@ -23,6 +23,7 @@#include <linux/huge_mm.h> #include <asm/pgtable.h> +#include "internal.h" /* * swapper_space is a fiction, retained to simplify the path through
@@ -416,7 +417,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 ;
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 3/36 EDAC/amd64: Read back the scrub rate PCI register on F15h
In reply to Greg Kroah-HartmanFrom: Borislav Petkov <[email protected]>
[ 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.
--- drivers/edac/amd64_edac.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/edac/amd64_edac.c +2 -0
@@ -261,6 +261,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);break ;case 0x17 :
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 4/36 usbnet: smsc95xx: Fix use-after-free after removal
In reply to Greg Kroah-HartmanFrom: Tuomas Tynkkynen <[email protected]>
[ Upstream commit b835a71ef64a61383c414d6bf2896d2c0161deca ]
Syzbot reports an use-after-free in workqueue context:
BUG: KASAN: use-after-free in mutex_unlock+0x19/0x40 kernel/locking/mutex.c:737 mutex_unlock+0x19/0x40 kernel/locking/mutex.c:737 __smsc95xx_mdio_read drivers/net/usb/smsc95xx.c:217 [inline] smsc95xx_mdio_read+0x583/0x870 drivers/net/usb/smsc95xx.c:278 check_carrier+0xd1/0x2e0 drivers/net/usb/smsc95xx.c:644 process_one_work+0x777/0xf90 kernel/workqueue.c:2274 worker_thread+0xa8f/0x1430 kernel/workqueue.c:2420 kthread+0x2df/0x300 kernel/kthread.c:255
It looks like that smsc95xx_unbind() is freeing the structures that are still in use by the concurrently running workqueue callback. Thus switch to using cancel_delayed_work_sync() to ensure the work callback really is no longer active.
--- drivers/net/usb/smsc95xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/usb/smsc95xx.c +1 -1
@@ -1338,7 +1338,7 @@ static void smsc95xx_unbind(struct usbnet *dev, struct usb_interface *intf)struct smsc95xx_priv *pdata = (struct smsc95xx_priv *)(dev->data[0 ]);if (pdata) { -cancel_delayed_work (&pdata->carrier_check); +cancel_delayed_work_sync (&pdata->carrier_check);netif_dbg (dev, ifdown, dev->net,"free pdata\n" );kfree (pdata); pdata =NULL ;
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 5/36 mm/slub.c: fix corrupted freechain in deactivate_slab()
In reply to Greg Kroah-HartmanFrom: Dongli Zhang <[email protected]>
[ Upstream commit 52f23478081ae0dcdb95d1650ea1e7d52d586829 ]
The slub_debug is able to fix the corrupted slab freelist/page. However, alloc_debug_processing() only checks the validity of current and next freepointer during allocation path. As a result, once some objects have their freepointers corrupted, deactivate_slab() may lead to page fault.
Below is from a test kernel module when 'slub_debug=PUF,kmalloc-128 slub_nomerge'. The test kernel corrupts the freepointer of one free object on purpose. Unfortunately, deactivate_slab() does not detect it when iterating the freechain.
BUG: unable to handle page fault for address: 00000000123456f8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI ... ... RIP: 0010:deactivate_slab.isra.92+0xed/0x490 ... ... Call Trace: ___slab_alloc+0x536/0x570 __slab_alloc+0x17/0x30 __kmalloc+0x1d9/0x200 ext4_htree_store_dirent+0x30/0xf0 htree_dirblock_to_tree+0xcb/0x1c0 ext4_htree_fill_tree+0x1bc/0x2d0 ext4_readdir+0x54f/0x920 iterate_dir+0x88/0x190 __x64_sys_getdents+0xa6/0x140 do_syscall_64+0x49/0x170 entry_SYSCALL_64_after_hwframe+0x44/0xa9
Therefore, this patch adds extra consistency check in deactivate_slab(). Once an object's freepointer is corrupted, all following objects starting at this object are isolated.
--- mm/slub.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+)
mm/slub.c +27 -0
@@ -645,6 +645,20 @@ static void slab_fix(struct kmem_cache *s, char *fmt, ...)va_end (args); } +static bool freelist_corrupted (struct kmem_cache *s,struct page *page, +void *freelist,void *nextfree) +{ +if ((s->flags &SLAB_CONSISTENCY_CHECKS ) && + !check_valid_pointer (s, page, nextfree)) { +object_err (s, page, freelist,"Freechain corrupt" ); + freelist =NULL ; +slab_fix (s,"Isolate corrupted freechain" ); +return true; + } + +return false; +} +static void print_trailer (struct kmem_cache *s,struct page *page,u8 *p) {unsigned int off;/* Offset of last byte */
@@ -1328,6 +1342,11 @@ static inline void inc_slabs_node(struct kmem_cache *s, int node,static inline void dec_slabs_node (struct kmem_cache *s,int node,int objects) {} +static bool freelist_corrupted (struct kmem_cache *s,struct page *page, +void *freelist,void *nextfree) +{ +return false; +}#endif /* CONFIG_SLUB_DEBUG */ /*
@@ -2013,6 +2032,14 @@ static void deactivate_slab(struct kmem_cache *s, struct page *page,void *prior;unsigned long counters; +/* +* If 'nextfree' is invalid, it is possible that the object at +* 'freelist' is already corrupted. So isolate all objects +* starting at 'freelist'. +*/ +if (freelist_corrupted (s, page, freelist, nextfree)) +break ; + do { prior = page->freelist; counters = page->counters;
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 6/36 mm/slub: fix stack overruns with SLUB_STATS
In reply to Greg Kroah-HartmanFrom: Qian Cai <[email protected]>
[ 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--- mm/slub.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
mm/slub.c +2 -1
@@ -5610,7 +5610,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 );
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 7/36 usb: usbtest: fix missing kfree(dev->buf) in usbtest_disconnect
In reply to Greg Kroah-HartmanFrom: Zqiang <[email protected]>
[ 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--- drivers/usb/misc/usbtest.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/misc/usbtest.c +1 -0
@@ -2853,6 +2853,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); }
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 8/36 s390/debug: avoid kernel warning on too large number of pages
In reply to Greg Kroah-HartmanFrom: Christian Borntraeger <[email protected]>
[ Upstream commit 827c4913923e0b441ba07ba4cc41e01181102303 ]
When specifying insanely large debug buffers a kernel warning is printed. The debug code does handle the error gracefully, though. Instead of duplicating the check let us silence the warning to avoid crashes when panic_on_warn is used.
--- arch/s390/kernel/debug.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/s390/kernel/debug.c +2 -1
@@ -198,9 +198,10 @@ static debug_entry_t ***debug_areas_alloc(int pages_per_area, int nr_areas)if (!areas) goto fail_malloc_areas;for (i =0 ; i < nr_areas; i++) { +/* GFP_NOWARN to avoid user triggerable WARN, we handle fails */ areas[i] =kmalloc_array (pages_per_area,sizeof (debug_entry_t *), -GFP_KERNEL ); +GFP_KERNEL | __GFP_NOWARN);if (!areas[i]) goto fail_malloc_areas2;for (j =0 ; j < pages_per_area; j++) {
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 9/36 nvme-multipath: set bdi capabilities once
In reply to Greg Kroah-HartmanFrom: Keith Busch <[email protected]>
[ Upstream commit b2ce4d90690bd29ce5b554e203cd03682dd59697 ]
The queues' backing device info capabilities don't change with each namespace revalidation. Set it only when each path's request_queue is initially added to a multipath queue.
--- drivers/nvme/host/multipath.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/nvme/host/multipath.c +8 -0
@@ -11,6 +11,7 @@* more details. */ +#include <linux/backing-dev.h> #include <linux/moduleparam.h> #include <trace/events/block.h> #include "nvme.h"
@@ -521,6 +522,13 @@ void nvme_mpath_add_disk(struct nvme_ns *ns, struct nvme_id_ns *id)nvme_mpath_set_live (ns);mutex_unlock (&ns->head->lock); } + +if (bdi_cap_stable_pages_required (ns->queue->backing_dev_info)) { +struct backing_dev_info *info = + ns->head->disk->queue->backing_dev_info; + + info->capabilities |=BDI_CAP_STABLE_WRITES ; + } }void nvme_mpath_remove_disk (struct nvme_ns_head *head)
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 10/36 nvme: fix possible deadlock when I/O is blocked
In reply to Greg Kroah-HartmanFrom: Sagi Grimberg <[email protected]>
[ Upstream commit 3b4b19721ec652ad2c4fe51dfbe5124212b5f581 ]
Revert fab7772bfbcf ("nvme-multipath: revalidate nvme_ns_head gendisk in nvme_validate_ns")
When adding a new namespace to the head disk (via nvme_mpath_set_live) we will see partition scan which triggers I/O on the mpath device node. This process will usually be triggered from the scan_work which holds the scan_lock. If I/O blocks (if we got ana change currently have only available paths but none are accessible) this can deadlock on the head disk bd_mutex as both partition scan I/O takes it, and head disk revalidation takes it to check for resize (also triggered from scan_work on a different path). See trace [1].
The mpath disk revalidation was originally added to detect online disk size change, but this is no longer needed since commit cb224c3af4df ("nvme: Convert to use set_capacity_revalidate_and_notify") which already updates resize info without unnecessarily revalidating the disk (the mpath disk doesn't even implement .revalidate_disk fop).
[1]:
--
kernel: INFO: task kworker/u65:9:494 blocked for more than 241 seconds. kernel: Tainted: G OE 5.3.5-050305-generic #201910071830 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: kworker/u65:9 D 0 494 2 0x80004000 kernel: Workqueue: nvme-wq nvme_scan_work [nvme_core] kernel: Call Trace: kernel: __schedule+0x2b9/0x6c0 kernel: schedule+0x42/0xb0 kernel: schedule_preempt_disabled+0xe/0x10 kernel: __mutex_lock.isra.0+0x182/0x4f0 kernel: __mutex_lock_slowpath+0x13/0x20 kernel: mutex_lock+0x2e/0x40 kernel: revalidate_disk+0x63/0xa0 kernel: __nvme_revalidate_disk+0xfe/0x110 [nvme_core] kernel: nvme_revalidate_disk+0xa4/0x160 [nvme_core] kernel: ? evict+0x14c/0x1b0 kernel: revalidate_disk+0x2b/0xa0 kernel: nvme_validate_ns+0x49/0x940 [nvme_core] kernel: ? blk_mq_free_request+0xd2/0x100 kernel: ? __nvme_submit_sync_cmd+0xbe/0x1e0 [nvme_core] kernel: nvme_scan_work+0x24f/0x380 [nvme_core] kernel: process_one_work+0x1db/0x380 kernel: worker_thread+0x249/0x400 kernel: kthread+0x104/0x140 kernel: ? process_one_work+0x380/0x380 kernel: ? kthread_park+0x80/0x80 kernel: ret_from_fork+0x1f/0x40 ... kernel: INFO: task kworker/u65:1:2630 blocked for more than 241 seconds. kernel: Tainted: G OE 5.3.5-050305-generic #201910071830 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: kworker/u65:1 D 0 2630 2 0x80004000 kernel: Workqueue: nvme-wq nvme_scan_work [nvme_core] kernel: Call Trace: kernel: __schedule+0x2b9/0x6c0 kernel: schedule+0x42/0xb0 kernel: io_schedule+0x16/0x40 kernel: do_read_cache_page+0x438/0x830 kernel: ? __switch_to_asm+0x34/0x70 kernel: ? file_fdatawait_range+0x30/0x30 kernel: read_cache_page+0x12/0x20 kernel: read_dev_sector+0x27/0xc0 kernel: read_lba+0xc1/0x220 kernel: ? kmem_cache_alloc_trace+0x19c/0x230 kernel: efi_partition+0x1e6/0x708 kernel: ? vsnprintf+0x39e/0x4e0 kernel: ? snprintf+0x49/0x60 kernel: check_partition+0x154/0x244 kernel: rescan_partitions+0xae/0x280 kernel: __blkdev_get+0x40f/0x560 kernel: blkdev_get+0x3d/0x140 kernel: __device_add_disk+0x388/0x480 kernel: device_add_disk+0x13/0x20 kernel: nvme_mpath_set_live+0x119/0x140 [nvme_core] kernel: nvme_update_ns_ana_state+0x5c/0x60 [nvme_core] kernel: nvme_set_ns_ana_state+0x1e/0x30 [nvme_core] kernel: nvme_parse_ana_log+0xa1/0x180 [nvme_core] kernel: ? nvme_update_ns_ana_state+0x60/0x60 [nvme_core] kernel: nvme_mpath_add_disk+0x47/0x90 [nvme_core] kernel: nvme_validate_ns+0x396/0x940 [nvme_core] kernel: ? blk_mq_free_request+0xd2/0x100 kernel: nvme_scan_work+0x24f/0x380 [nvme_core] kernel: process_one_work+0x1db/0x380 kernel: worker_thread+0x249/0x400 kernel: kthread+0x104/0x140 kernel: ? process_one_work+0x380/0x380 kernel: ? kthread_park+0x80/0x80 kernel: ret_from_fork+0x1f/0x40
--
in nvme_validate_ns")
--- drivers/nvme/host/core.c | 1 - 1 file changed, 1 deletion(-)
drivers/nvme/host/core.c +0 -1
@@ -1602,7 +1602,6 @@ static void __nvme_revalidate_disk(struct gendisk *disk, struct nvme_id_ns *id)if (ns->head->disk) {nvme_update_disk_info (ns->head->disk, ns, id);blk_queue_stack_limits (ns->head->disk->queue, ns->queue); -revalidate_disk (ns->head->disk); }#endif }
Signature · 1 line
2.25.1
Re: [PATCH 4.19 10/36] nvme: fix possible deadlock when I/O is blocked
Hi!
Quoted 16 lines
From: Sagi Grimberg <[email protected]>
[ Upstream commit
3b4b19721ec652ad2c4fe51dfbe5124212b5f581]Revert
fab7772bfbcf("nvme-multipath: revalidatenvme_ns_headgendisk innvme_validate_ns")When adding a new namespace to the head disk (via
nvme_mpath_set_live) we will see partition scan which triggers I/O on the mpath device node. This process will usually be triggered from thescan_workwhich holds thescan_lock. If I/O blocks (if we got ana change currently have only available paths but none are accessible) this can deadlock on the head diskbd_mutexas both partition scan I/O takes it, and head disk revalidation takes it to check for resize (also triggered fromscan_workon a different path). See trace [1].
Quoted 4 lines
The mpath disk revalidation was originally added to detect online disk size change, but this is no longer needed since commit
cb224c3af4df("nvme: Convert to useset_capacity_revalidate_and_notify") which already
AFAICT cb224c3af4df is not applied to 4.19-stable series, so this is not safe according to the changelog.
cb224c3af4df is simple enough, but AFAICT set_capacity_revalidate_and_notify() is missing in 4.19.132-rc1.
Best regards,
Pavel
Quoted 12 lines
drivers/nvme/host/core.c +0
-1@@ -1602,7 +1602,6 @@ static void __nvme_revalidate_disk(struct gendisk *disk, struct nvme_id_ns *id)if (ns->head->disk) {nvme_update_disk_info (ns->head->disk, ns, id);blk_queue_stack_limits (ns->head->disk->queue, ns->queue); -revalidate_disk (ns->head->disk); }#endif }
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Sasha Levin
maintainerRe: [PATCH 4.19 10/36] nvme: fix possible deadlock when I/O is blocked
Quoted 23 lines · Pavel Machek
Hi!
Quoted 16 lines
From: Sagi Grimberg <[email protected]>
[ Upstream commit
3b4b19721ec652ad2c4fe51dfbe5124212b5f581]Revert
fab7772bfbcf("nvme-multipath: revalidatenvme_ns_headgendisk innvme_validate_ns")When adding a new namespace to the head disk (via
nvme_mpath_set_live) we will see partition scan which triggers I/O on the mpath device node. This process will usually be triggered from thescan_workwhich holds thescan_lock. If I/O blocks (if we got ana change currently have only available paths but none are accessible) this can deadlock on the head diskbd_mutexas both partition scan I/O takes it, and head disk revalidation takes it to check for resize (also triggered fromscan_workon a different path). See trace [1].Quoted 4 lines
The mpath disk revalidation was originally added to detect online disk size change, but this is no longer needed since commit
cb224c3af4df("nvme: Convert to useset_capacity_revalidate_and_notify") which already
Quoted 5 lines
AFAICT
cb224c3af4dfis not applied to 4.19-stable series, so this is not safe according to the changelog.
cb224c3af4dfis simple enough, but AFAICTset_capacity_revalidate_and_notify()is missing in 4.19.132-rc1.
Good point... It might be the case that e598a72faeb5 ("block/genhd:
Notify udev about capacity change") is safe to take along with cb224c3af4df.
I'll look at it once these releases are out, but for now I'll drop this commit. Thanks!
Signature · 2 lines
Thanks, Sasha
Greg Kroah-Hartman
maintainerPATCH 11/36 nvme-multipath: fix deadlock between ana_work and scan_work
In reply to Greg Kroah-HartmanFrom: Anton Eidelman <[email protected]>
[ Upstream commit 489dd102a2c7c94d783a35f9412eb085b8da1aa4 ]
When scan_work calls nvme_mpath_add_disk() this holds ana_lock and invokes nvme_parse_ana_log(), which may issue IO
in device_add_disk() and hang waiting for an accessible path. While nvme_mpath_set_live() only called when nvme_state_is_live(), a transition may cause NVME_SC_ANA_TRANSITION and requeue the IO.
In order to recover and complete the IO ana_work on the same ctrl should be able to update the path state and remove NVME_NS_ANA_PENDING.
The deadlock occurs because scan_work keeps holding ana_lock, so ana_work hangs [1].
Fix:
Now nvme_mpath_add_disk() uses nvme_parse_ana_log() to obtain a copy of the ANA group desc, and then calls nvme_update_ns_ana_state() without holding ana_lock.
[1]:
kernel: Workqueue: nvme-wq nvme_scan_work [nvme_core] kernel: Call Trace: kernel: __schedule+0x2b9/0x6c0 kernel: schedule+0x42/0xb0 kernel: io_schedule+0x16/0x40 kernel: do_read_cache_page+0x438/0x830 kernel: read_cache_page+0x12/0x20 kernel: read_dev_sector+0x27/0xc0 kernel: read_lba+0xc1/0x220 kernel: efi_partition+0x1e6/0x708 kernel: check_partition+0x154/0x244 kernel: rescan_partitions+0xae/0x280 kernel: __blkdev_get+0x40f/0x560 kernel: blkdev_get+0x3d/0x140 kernel: __device_add_disk+0x388/0x480 kernel: device_add_disk+0x13/0x20 kernel: nvme_mpath_set_live+0x119/0x140 [nvme_core] kernel: nvme_update_ns_ana_state+0x5c/0x60 [nvme_core] kernel: nvme_set_ns_ana_state+0x1e/0x30 [nvme_core] kernel: nvme_parse_ana_log+0xa1/0x180 [nvme_core] kernel: nvme_mpath_add_disk+0x47/0x90 [nvme_core] kernel: nvme_validate_ns+0x396/0x940 [nvme_core] kernel: nvme_scan_work+0x24f/0x380 [nvme_core] kernel: process_one_work+0x1db/0x380 kernel: worker_thread+0x249/0x400 kernel: kthread+0x104/0x140
kernel: Workqueue: nvme-wq nvme_ana_work [nvme_core] kernel: Call Trace: kernel: __schedule+0x2b9/0x6c0 kernel: schedule+0x42/0xb0 kernel: schedule_preempt_disabled+0xe/0x10 kernel: __mutex_lock.isra.0+0x182/0x4f0 kernel: ? __switch_to_asm+0x34/0x70 kernel: ? select_task_rq_fair+0x1aa/0x5c0 kernel: ? kvm_sched_clock_read+0x11/0x20 kernel: ? sched_clock+0x9/0x10 kernel: __mutex_lock_slowpath+0x13/0x20 kernel: mutex_lock+0x2e/0x40 kernel: nvme_read_ana_log+0x3a/0x100 [nvme_core] kernel: nvme_ana_work+0x15/0x20 [nvme_core] kernel: process_one_work+0x1db/0x380 kernel: worker_thread+0x4d/0x400 kernel: kthread+0x104/0x140 kernel: ? process_one_work+0x380/0x380 kernel: ? kthread_park+0x80/0x80 kernel: ret_from_fork+0x35/0x40
--- drivers/nvme/host/multipath.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-)
drivers/nvme/host/multipath.c +16 -8
@@ -496,26 +496,34 @@ static ssize_t ana_state_show(struct device *dev, struct device_attribute *attr, }DEVICE_ATTR_RO (ana_state); -static int nvme_set_ns_ana_state (struct nvme_ctrl *ctrl, +static int nvme_lookup_ana_group_desc (struct nvme_ctrl *ctrl,struct nvme_ana_group_desc *desc,void *data) { -struct nvme_ns *ns = data; +struct nvme_ana_group_desc *dst = data; -if (ns->ana_grpid ==le32_to_cpu (desc->grpid)) { -nvme_update_ns_ana_state (desc, ns); -return -ENXIO ;/* just break out of the loop */ - } +if (desc->grpid != dst->grpid) +return 0 ; -return 0 ; + *dst = *desc; +return -ENXIO ;/* just break out of the loop */ }void nvme_mpath_add_disk (struct nvme_ns *ns,struct nvme_id_ns *id) {if (nvme_ctrl_use_ana (ns->ctrl)) { +struct nvme_ana_group_desc desc = { + .grpid = id->anagrpid, + .state =0 , + }; +mutex_lock (&ns->ctrl->ana_lock); ns->ana_grpid =le32_to_cpu (id->anagrpid); -nvme_parse_ana_log (ns->ctrl, ns, nvme_set_ns_ana_state); +nvme_parse_ana_log (ns->ctrl, &desc, nvme_lookup_ana_group_desc);mutex_unlock (&ns->ctrl->ana_lock); +if (desc.state) { +/* found the group desc: update */ +nvme_update_ns_ana_state (&desc, ns); + } }else {mutex_lock (&ns->head->lock); ns->ana_state =NVME_ANA_OPTIMIZED ;
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 12/36 kgdb: Avoid suspicious RCU usage warning
In reply to Greg Kroah-HartmanFrom: Douglas Anderson <[email protected]>
[ 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.
--- kernel/debug/debug_core.c | 4 ++++ 1 file changed, 4 insertions(+)
kernel/debug/debug_core.c +4 -0
@@ -489,6 +489,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.
@@ -545,6 +546,7 @@ return_normal:atomic_dec (&slaves_in_kgdb);dbg_touch_watchdogs ();local_irq_restore (flags); +rcu_read_unlock ();return 0 ; }cpu_relax ();
@@ -563,6 +565,7 @@ return_normal:raw_spin_unlock (&dbg_master_lock);dbg_touch_watchdogs ();local_irq_restore (flags); +rcu_read_unlock (); goto acquirelock; }
@@ -686,6 +689,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; }
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 13/36 crypto: af_alg - fix use-after-free in af_alg_accept() due to bh_lock_sock()
In reply to Greg Kroah-HartmanFrom: Herbert Xu <[email protected]>
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/[email protected]/
--- 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(-)
crypto/af_alg.c +11 -15
@@ -133,21 +133,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);
@@ -192,7 +186,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);
@@ -241,7 +235,7 @@ static int alg_setsockopt(struct socketint err = -EBUSY ;lock_sock (sk); -if (ask->refcnt) +if (atomic_read (&ask->refcnt) !=atomic_read (&ask->nokey_refcnt)) goto unlock; type = ask->type;
@@ -308,12 +302,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 ;
crypto/algif_aead.c +3 -6
@@ -388,7 +388,7 @@ static int aead_check_key(struct socketstruct alg_sock *ask =alg_sk (sk);lock_sock (sk); -if (ask->refcnt) +if (!atomic_read (&ask->nokey_refcnt)) goto unlock_child; psk = ask->parent;
@@ -400,11 +400,8 @@ static int aead_check_key(struct socketif (crypto_aead_get_flags (tfm->aead) &CRYPTO_TFM_NEED_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 ;
crypto/algif_hash.c +3 -6
@@ -306,7 +306,7 @@ static int hash_check_key(struct socketstruct alg_sock *ask =alg_sk (sk);lock_sock (sk); -if (ask->refcnt) +if (!atomic_read (&ask->nokey_refcnt)) goto unlock_child; psk = ask->parent;
@@ -318,11 +318,8 @@ static int hash_check_key(struct socketif (crypto_ahash_get_flags (tfm) &CRYPTO_TFM_NEED_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 ;
crypto/algif_skcipher.c +3 -6
@@ -215,7 +215,7 @@ static int skcipher_check_key(struct socstruct alg_sock *ask =alg_sk (sk);lock_sock (sk); -if (ask->refcnt) +if (!atomic_read (&ask->nokey_refcnt)) goto unlock_child; psk = ask->parent;
@@ -227,11 +227,8 @@ static int skcipher_check_key(struct socif (crypto_skcipher_get_flags (tfm) &CRYPTO_TFM_NEED_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 ;
include/crypto/if_alg.h +2 -2
@@ -34,8 +34,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;
Re: [PATCH 4.19 13/36] crypto: af_alg - fix use-after-free in af_alg_accept() due to bh_lock_sock()
Hi!
Quoted 10 lines
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:
crypto/af_alg.c +0
-0@@ -308,12 +302,14 @@ int af_alg_accept(struct sock *sk, struc
crypto/af_alg.c int af_alg_accept(struct sock *sk, struc · line 310
Quoted 10 lines
crypto/af_alg.c +5
-2sk2->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 ); + }
Should we set the nokey_refcnt to 0 using atomic_set, too? Aternatively, should the nokey_refcnt be initialized using ATOMIC_INIT()?
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH 4.19 13/36] crypto: af_alg - fix use-after-free in af_alg_accept() due to bh_lock_sock()
Quoted 5 lines · Pavel Machek
Quoted 5 lines
crypto/af_alg.c +0
-0@@ -308,12 +302,14 @@ int af_alg_accept(struct sock *sk, struc sk2->sk_family =PF_ALG ;
Quoted 12 lines
crypto/af_alg.c int af_alg_accept(struct sock *sk, struc · line 310
Quoted 8 lines
crypto/af_alg.c +5
-2-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 ); + }Should we set the
nokey_refcntto 0 usingatomic_set, too? Aternatively, should thenokey_refcntbe initialized usingATOMIC_INIT()?
What are you asking for? It's already being set with atomic_set. Or are you asking it to be set to 0 instead of 1? No it needs to be 1 for the socket destructor.
Cheers,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Greg Kroah-Hartman
maintainerPATCH 14/36 drm/msm/dpu: fix error return code in dpu_encoder_init
In reply to Greg Kroah-HartmanFrom: Chen Tao <[email protected]>
[ Upstream commit aa472721c8dbe1713cf510f56ffbc56ae9e14247 ]
Fix to return negative error code -ENOMEM with the use of ERR_PTR from dpu_encoder_init.
--- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c +1 -1
@@ -2412,7 +2412,7 @@ struct drm_encoder *dpu_encoder_init(struct drm_device *dev, dpu_enc =devm_kzalloc (dev->dev,sizeof (*dpu_enc),GFP_KERNEL );if (!dpu_enc) -return ERR_PTR (ENOMEM ); +return ERR_PTR (-ENOMEM ); rc =drm_encoder_init (dev, &dpu_enc->base, &dpu_encoder_funcs, drm_enc_mode,NULL );
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 15/36 cxgb4: use unaligned conversion for fetching timestamp
In reply to Greg Kroah-HartmanFrom: Rahul Lakkireddy <[email protected]>
[ Upstream commit 589b1c9c166dce120e27b32a83a78f55464a7ef9 ]
Use get_unaligned_be64() to fetch the timestamp needed for ns_to_ktime() conversion.
Fixes following sparse warning:
sge.c:3282:43: warning: cast to restricted __be64
--- drivers/net/ethernet/chelsio/cxgb4/sge.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/chelsio/cxgb4/sge.c +1 -1
@@ -2742,7 +2742,7 @@ static noinline int t4_systim_to_hwstamp(struct adapter *adapter, hwtstamps =skb_hwtstamps (skb);memset (hwtstamps,0 ,sizeof (*hwtstamps)); - hwtstamps->hwtstamp =ns_to_ktime (be64_to_cpu (*((u64 *)data))); + hwtstamps->hwtstamp =ns_to_ktime (get_unaligned_be64 (data));return RX_PTP_PKT_SUC ; }
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 16/36 cxgb4: parse TC-U32 key values and masks natively
In reply to Greg Kroah-HartmanFrom: Rahul Lakkireddy <[email protected]>
[ Upstream commit 27f78cb245abdb86735529c13b0a579f57829e71 ]
TC-U32 passes all keys values and masks in __be32 format. The parser already expects this and hence pass the value and masks in __be32 natively to the parser.
Fixes following sparse warnings in several places:
cxgb4_tc_u32.c:57:21: warning: incorrect type in assignment (different base types)
cxgb4_tc_u32.c:57:21: expected unsigned int [usertype] val
cxgb4_tc_u32.c:57:21: got restricted __be32 [usertype] val
cxgb4_tc_u32_parse.h:48:24: warning: cast to restricted __be32
--- .../net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c | 18 +-- .../chelsio/cxgb4/cxgb4_tc_u32_parse.h | 122 ++++++++++++------ 2 files changed, 91 insertions(+), 49 deletions(-)
drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c +9 -9
@@ -47,7 +47,7 @@ static int fill_match_fields(struct adapter *adap, bool next_header) {unsigned int i, j; -u32 val, mask; +__be32 val, mask;int off, err;bool found;
@@ -216,7 +216,7 @@ int cxgb4_config_knode(struct net_device *dev, struct tc_cls_u32_offload *cls)const struct cxgb4_next_header *next;bool found = false;unsigned int i, j; -u32 val, mask; +__be32 val, mask;int off;if (t->table[link_uhtid -1 ].link_handle) {
@@ -230,10 +230,10 @@ int cxgb4_config_knode(struct net_device *dev, struct tc_cls_u32_offload *cls)/* Try to find matches that allow jumps to next header. */ for (i =0 ; next[i].jump; i++) { -if (next[i].offoff != cls->knode.sel->offoff || - next[i].shift != cls->knode.sel->offshift || - next[i].mask != cls->knode.sel->offmask || - next[i].offset != cls->knode.sel->off) +if (next[i].sel.offoff != cls->knode.sel->offoff || + next[i].sel.offshift != cls->knode.sel->offshift || + next[i].sel.offmask != cls->knode.sel->offmask || + next[i].sel.off != cls->knode.sel->off)continue ;/* Found a possible candidate. Find a key that
@@ -245,9 +245,9 @@ int cxgb4_config_knode(struct net_device *dev, struct tc_cls_u32_offload *cls) val = cls->knode.sel->keys[j].val; mask = cls->knode.sel->keys[j].mask; -if (next[i].match_off == off && - next[i].match_val == val && - next[i].match_mask == mask) { +if (next[i].key.off == off && + next[i].key.val == val && + next[i].key.mask == mask) { found = true;break ; }
drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h +82 -40
244 lines not on this page · raw message
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 17/36 cxgb4: use correct type for all-mask IP address comparison
In reply to Greg Kroah-HartmanFrom: Rahul Lakkireddy <[email protected]>
[ Upstream commit f286dd8eaad5a2758750f407ab079298e0bcc8a5 ]
Use correct type to check for all-mask exact match IP addresses.
Fixes following sparse warnings due to big endian value checks against 0xffffffff in is_addr_all_mask():
cxgb4_filter.c:977:25: warning: restricted __be32 degrades to integer cxgb4_filter.c:983:37: warning: restricted __be32 degrades to integer cxgb4_filter.c:984:37: warning: restricted __be32 degrades to integer cxgb4_filter.c:985:37: warning: restricted __be32 degrades to integer cxgb4_filter.c:986:37: warning: restricted __be32 degrades to integer
--- drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c +5 -5
@@ -810,16 +810,16 @@ static bool is_addr_all_mask(u8 *ipmask, int family)struct in_addr *addr; addr = (struct in_addr *)ipmask; -if (addr->s_addr ==0xffffffff ) +if (ntohl (addr->s_addr) ==0xffffffff )return true; }else if (family ==AF_INET6 ) {struct in6_addr *addr6; addr6 = (struct in6_addr *)ipmask; -if (addr6->s6_addr32[0 ] ==0xffffffff && - addr6->s6_addr32[1 ] ==0xffffffff && - addr6->s6_addr32[2 ] ==0xffffffff && - addr6->s6_addr32[3 ] ==0xffffffff ) +if (ntohl (addr6->s6_addr32[0 ]) ==0xffffffff && +ntohl (addr6->s6_addr32[1 ]) ==0xffffffff && +ntohl (addr6->s6_addr32[2 ]) ==0xffffffff && +ntohl (addr6->s6_addr32[3 ]) ==0xffffffff )return true; }return false;
Signature · 1 line
2.25.1
Re: [PATCH 4.19 17/36] cxgb4: use correct type for all-mask IP address comparison
Hi!
Quoted 19 lines
From: Rahul Lakkireddy <[email protected]>
[ Upstream commit
f286dd8eaad5a2758750f407ab079298e0bcc8a5]Use correct type to check for all-mask exact match IP addresses.
Fixes following sparse warnings due to big endian value checks against
0xffffffffinis_addr_all_mask():
cxgb4_filter.c:977:25: warning: restricted__be32degrades to integer cxgb4_filter.c:983:37: warning: restricted__be32degrades to integer cxgb4_filter.c:984:37: warning: restricted__be32degrades to integer cxgb4_filter.c:985:37: warning: restricted__be32degrades to integer cxgb4_filter.c:986:37: warning: restricted__be32degrades to integerdrivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c +0
-0
drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c static bool is_addr_all_mask(u8 *ipmask, int family) · line 813
Quoted 5 lines
drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c +1
-1@@ -810,16 +810,16 @@ static bool is_addr_all_mask(u8 *ipmask, int family)struct in_addr *addr; addr = (struct in_addr *)ipmask; -if (addr->s_addr ==0xffffffff ) +if (ntohl (addr->s_addr) ==0xffffffff )
Endianity does not really matter for ~0, but can compiler figure it out?
would it be better to do these tests as
if (foo == htonl(0xffffffff))
to make it clear to the compiler?
Thanks,
Pavel
Quoted 15 lines
drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c +4
-4}else if (family ==AF_INET6 ) {struct in6_addr *addr6; addr6 = (struct in6_addr *)ipmask; -if (addr6->s6_addr32[0 ] ==0xffffffff && - addr6->s6_addr32[1 ] ==0xffffffff && - addr6->s6_addr32[2 ] ==0xffffffff && - addr6->s6_addr32[3 ] ==0xffffffff ) +if (ntohl (addr6->s6_addr32[0 ]) ==0xffffffff && +ntohl (addr6->s6_addr32[1 ]) ==0xffffffff && +ntohl (addr6->s6_addr32[2 ]) ==0xffffffff && +ntohl (addr6->s6_addr32[3 ]) ==0xffffffff )return true; }return false;
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH 4.19 17/36] cxgb4: use correct type for all-mask IP address comparison
Quoted 30 lines · Pavel Machek
Hi!
Quoted 19 lines
From: Rahul Lakkireddy <[email protected]>
[ Upstream commit
f286dd8eaad5a2758750f407ab079298e0bcc8a5]Use correct type to check for all-mask exact match IP addresses.
Fixes following sparse warnings due to big endian value checks against
0xffffffffinis_addr_all_mask():
cxgb4_filter.c:977:25: warning: restricted__be32degrades to integer cxgb4_filter.c:983:37: warning: restricted__be32degrades to integer cxgb4_filter.c:984:37: warning: restricted__be32degrades to integer cxgb4_filter.c:985:37: warning: restricted__be32degrades to integer cxgb4_filter.c:986:37: warning: restricted__be32degrades to integerdrivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c +0
-0drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c static bool is_addr_all_mask(u8 *ipmask, int family) · line 813
Quoted 5 lines
drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c +1
-1@@ -810,16 +810,16 @@ static bool is_addr_all_mask(u8 *ipmask, int family)struct in_addr *addr; addr = (struct in_addr *)ipmask; -if (addr->s_addr ==0xffffffff ) +if (ntohl (addr->s_addr) ==0xffffffff )Endianity does not really matter for ~0, but can compiler figure it out?
Quoted 6 lines
would it be better to do these tests as
if (foo == htonl(0xffffffff))to make it clear to the compiler?
Sure, I'll update all checks to follow above approach. Will send a patch.
Quoted 4 lines
Quoted 4 lines
drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c +0
-0}else if (family ==AF_INET6 ) {struct in6_addr *addr6;
Quoted 13 lines
drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c static bool is_addr_all_mask(u8 *ipmask, int family) · line 825
Quoted 12 lines
drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c +4
-4addr6 = (struct in6_addr *)ipmask; -if (addr6->s6_addr32[0 ] ==0xffffffff && - addr6->s6_addr32[1 ] ==0xffffffff && - addr6->s6_addr32[2 ] ==0xffffffff && - addr6->s6_addr32[3 ] ==0xffffffff ) +if (ntohl (addr6->s6_addr32[0 ]) ==0xffffffff && +ntohl (addr6->s6_addr32[1 ]) ==0xffffffff && +ntohl (addr6->s6_addr32[2 ]) ==0xffffffff && +ntohl (addr6->s6_addr32[3 ]) ==0xffffffff )return true; }return false;
Thanks,
Rahul
Greg Kroah-Hartman
maintainerPATCH 18/36 cxgb4: fix SGE queue dump destination buffer context
In reply to Greg Kroah-HartmanFrom: Rahul Lakkireddy <[email protected]>
[ Upstream commit 1992ded5d111997877a9a25205976d8d03c46814 ]
The data in destination buffer is expected to be be parsed in big endian. So, use the right context.
Fixes following sparse warning:
cudbg_lib.c:2041:44: warning: incorrect type in assignment (different base types)
cudbg_lib.c:2041:44: expected unsigned long long [usertype]
cudbg_lib.c:2041:44: got restricted __be64 [usertype]
--- drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c +4 -2
@@ -1987,7 +1987,6 @@ int cudbg_collect_dump_context(struct cudbg_init *pdbg_init,u8 mem_type[CTXT_INGRESS +1 ] = {0 };struct cudbg_buffer temp_buff = {0 };struct cudbg_ch_cntxt *buff; -u64 *dst_off, *src_off;u8 *ctx_buf;u8 i, k;int rc;
@@ -2056,8 +2055,11 @@ int cudbg_collect_dump_context(struct cudbg_init *pdbg_init, }for (j =0 ; j < max_ctx_qid; j++) { +__be64 *dst_off; +u64 *src_off; + src_off = (u64 *)(ctx_buf + j *SGE_CTXT_SIZE ); - dst_off = (u64 *)buff->data; + dst_off = (__be64 *)buff->data;/* The data is stored in 64-bit cpu order. Convert it * to big endian before parsing.
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 19/36 hwmon: (max6697) Make sure the OVERT mask is set correctly
In reply to Greg Kroah-HartmanFrom: Chu Lin <[email protected]>
[ 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
--- drivers/hwmon/max6697.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/hwmon/max6697.c +4 -3
@@ -47,8 +47,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))
@@ -587,12 +588,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;
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 20/36 hwmon: (acpi_power_meter) Fix potential memory leak in acpi_power_meter_add()
In reply to Greg Kroah-HartmanFrom: Misono Tomohiro <[email protected]>
[ Upstream commit 8b97f9922211c44a739c5cbd9502ecbb9f17f6d1 ]
Although it rarely happens, we should call free_capabilities() if error happens after read_capabilities() to free allocated strings.
--- drivers/hwmon/acpi_power_meter.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/hwmon/acpi_power_meter.c +3 -1
@@ -896,7 +896,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)) {
@@ -909,6 +909,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:
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 21/36 drm: sun4i: hdmi: Remove extra HPD polling
In reply to Greg Kroah-HartmanFrom: Chen-Yu Tsai <[email protected]>
[ Upstream commit bda8eaa6dee7525f4dac950810a85a88bf6c2ba0 ]
The HPD sense mechanism in Allwinner's old HDMI encoder hardware is more or less an input-only GPIO. Other GPIO-based HPD implementations directly return the current state, instead of polling for a specific state and returning the other if that times out.
Remove the I/O polling from sun4i_hdmi_connector_detect() and directly return a known state based on the current reading. This also gets rid of excessive CPU usage by kworker as reported on Stack Exchange [1] and Armbian forums [2].
[1] https://superuser.com/questions/1515001/debian-10-buster-on-cubietruck-with-bug-in-sun4i-drm-hdmi
[2] https://forum.armbian.com/topic/14282-headless-systems-and-sun4i_drm_hdmi-a10a20/
--- drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c +2 -3
@@ -242,9 +242,8 @@ sun4i_hdmi_connector_detect(struct drm_connector *connector, bool force)struct sun4i_hdmi *hdmi =drm_connector_to_sun4i_hdmi (connector);unsigned long reg; -if (readl_poll_timeout (hdmi->base +SUN4I_HDMI_HPD_REG , reg, - reg &SUN4I_HDMI_HPD_HIGH , -0 ,500000 )) { + reg =readl (hdmi->base +SUN4I_HDMI_HPD_REG ); +if (reg &SUN4I_HDMI_HPD_HIGH ) {cec_phys_addr_invalidate (hdmi->cec_adap);return connector_status_disconnected; }
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 22/36 virtio-blk: free vblk-vqs in error path of virtblk_probe()
In reply to Greg Kroah-HartmanFrom: Hou Tao <[email protected]>
[ Upstream commit e7eea44eefbdd5f0345a0a8b80a3ca1c21030d06 ]
Else there will be memory leak if alloc_disk() fails.
--- drivers/block/virtio_blk.c | 1 + 1 file changed, 1 insertion(+)
drivers/block/virtio_blk.c +1 -0
@@ -882,6 +882,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:
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 23/36 SMB3: Honor posix flag for multiuser mounts
In reply to Greg Kroah-HartmanFrom: Paul Aurich <[email protected]>
[ Upstream commit 5391b8e1b7b7e5cfa2dd4ffdc4b8c6b64dfd1866 ]
The flag from the primary tcon needs to be copied into the volume info so that cifs_get_tcon will try to enable extensions on the per-user tcon. At that point, since posix extensions must have already been enabled on the superblock, don't try to needlessly adjust the mount flags.
--- fs/cifs/connect.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
fs/cifs/connect.c +1 -4
@@ -4602,6 +4602,7 @@ cifs_construct_tcon(struct cifs_sb_info *cifs_sb, kuid_t fsuid) vol_info->nohandlecache = master_tcon->nohandlecache; vol_info->local_lease = master_tcon->local_lease; vol_info->no_linux_ext = !master_tcon->unix_ext; + vol_info->linux_ext = master_tcon->posix_extensions; vol_info->sectype = master_tcon->ses->sectype; vol_info->sign = master_tcon->ses->sign;
@@ -4629,10 +4630,6 @@ cifs_construct_tcon(struct cifs_sb_info *cifs_sb, kuid_t fsuid) goto out; } -/* if new SMB3.11 POSIX extensions are supported do not remap / and \ */ -if (tcon->posix_extensions) - cifs_sb->mnt_cifs_flags |=CIFS_MOUNT_POSIX_PATHS ; -if (cap_unix (ses))reset_cifs_unix_caps (0 , tcon,NULL , vol_info);
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 24/36 nvme: fix a crash in nvme_mpath_add_disk
In reply to Greg Kroah-HartmanFrom: Christoph Hellwig <[email protected]>
[ Upstream commit 72d447113bb751ded97b2e2c38f886e4a4139082 ]
For private namespaces ns->head_disk is NULL, so add a NULL check before updating the BDI capabilities.
--- drivers/nvme/host/multipath.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/nvme/host/multipath.c +4 -3
@@ -532,10 +532,11 @@ void nvme_mpath_add_disk(struct nvme_ns *ns, struct nvme_id_ns *id) }if (bdi_cap_stable_pages_required (ns->queue->backing_dev_info)) { -struct backing_dev_info *info = - ns->head->disk->queue->backing_dev_info; +struct gendisk *disk = ns->head->disk; - info->capabilities |=BDI_CAP_STABLE_WRITES ; +if (disk) + disk->queue->backing_dev_info->capabilities |= +BDI_CAP_STABLE_WRITES ; } }
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 25/36 i2c: algo-pca: Add 0x78 as SCL stuck low status for PCA9665
In reply to Greg Kroah-HartmanFrom: Chris Packham <[email protected]>
[ 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.
--- drivers/i2c/algos/i2c-algo-pca.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/i2c/algos/i2c-algo-pca.c +2 -1
@@ -323,7 +323,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;
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 26/36 i2c: mlxcpld: check correct size of maximum RECV_LEN packet
In reply to Greg Kroah-HartmanFrom: Wolfram Sang <[email protected]>
[ Upstream commit 597911287fcd13c3a4b4aa3e0a52b33d431e0a8e ]
I2C_SMBUS_BLOCK_MAX defines already the maximum number as defined in the SMBus 2.0 specs. I don't see a reason to add 1 here. Also, fix the errno to what is suggested for this error.
--- drivers/i2c/busses/i2c-mlxcpld.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/i2c/busses/i2c-mlxcpld.c +2 -2
@@ -337,9 +337,9 @@ static int mlxcpld_i2c_wait_for_tc(struct mlxcpld_i2c_priv *priv)if (priv->smbus_block && (val &MLXCPLD_I2C_SMBUS_BLK_BIT )) {mlxcpld_i2c_read_comm (priv,MLXCPLD_LPCI2C_NUM_DAT_REG , &datalen,1 ); -if (unlikely (datalen > (I2C_SMBUS_BLOCK_MAX +1 ))) { +if (unlikely (datalen >I2C_SMBUS_BLOCK_MAX )) {dev_err (priv->dev,"Incorrect smbus block read message len\n" ); -return -E2BIG ; +return -EPROTO ; } }else { datalen = priv->xfer.data_len;
Signature · 1 line
2.25.1
Greg Kroah-Hartman
maintainerPATCH 27/36 nfsd: apply umask on fs without ACL support
In reply to Greg Kroah-HartmanFrom: J. Bruce Fields <[email protected]>
commit 22cf8419f1319ff87ec759d0ebdff4cbafaee832 upstream.
The server is failing to apply the umask when creating new objects on filesystems without ACL support.
To reproduce this, you need to use NFSv4.2 and a client and server recent enough to support umask, and you need to export a filesystem that lacks ACL support (for example, ext4 with the "noacl" mount option).
Filesystems with ACL support are expected to take care of the umask themselves (usually by calling posix_acl_create).
For filesystems without ACL support, this is up to the caller of vfs_create(), vfs_mknod(), or vfs_mkdir().
--- fs/nfsd/vfs.c | 6 ++++++ 1 file changed, 6 insertions(+)
fs/nfsd/vfs.c +6 -0
@@ -1206,6 +1206,9 @@ nfsd_create_locked(struct svc_rqst *rqst iap->ia_mode =0 ; iap->ia_mode = (iap->ia_mode &S_IALLUGO ) | type; +if (!IS_POSIXACL (dirp)) + iap->ia_mode &= ~current_umask (); + err =0 ; host_err =0 ;switch (type) {
@@ -1439,6 +1442,9 @@ do_nfsd_create(struct svc_rqst *rqstp, s goto out; } +if (!IS_POSIXACL (dirp)) + iap->ia_mode &= ~current_umask (); + host_err =vfs_create (dirp, dchild, iap->ia_mode, true);if (host_err <0 ) {fh_drop_write (fhp);
Greg Kroah-Hartman
maintainerPATCH 28/36 Revert "ALSA: usb-audio: Improve frames size computation"
In reply to Greg Kroah-HartmanFrom: Greg Kroah-Hartman <[email protected]>
This reverts commit 2d50acd7dbd0682a56968ad9551341d7fc5b6eaf 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.
--- 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(-)
sound/usb/card.h +0 -4
@@ -83,10 +83,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 */
sound/usb/endpoint.c +5 -38
78 lines not on this page · raw message
sound/usb/endpoint.h +0 -1
@@ -28,7 +28,6 @@ void snd_usb_endpoint_release(struct sndvoid 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,
sound/usb/pcm.c +0 -2
@@ -1558,8 +1558,6 @@ static void prepare_playback_urb(structfor (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);
Greg Kroah-Hartman
maintainerPATCH 29/36 SMB3: Honor seal flag for multiuser mounts
In reply to Greg Kroah-HartmanFrom: Paul Aurich <[email protected]>
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.
--- fs/cifs/connect.c | 1 + 1 file changed, 1 insertion(+)
fs/cifs/connect.c +1 -0
@@ -4605,6 +4605,7 @@ cifs_construct_tcon(struct cifs_sb_info vol_info->linux_ext = master_tcon->posix_extensions; 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) {
Greg Kroah-Hartman
maintainerPATCH 30/36 SMB3: Honor persistent/resilient handle flags for multiuser mounts
In reply to Greg Kroah-HartmanFrom: Paul Aurich <[email protected]>
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
--- fs/cifs/connect.c | 2 ++ 1 file changed, 2 insertions(+)
fs/cifs/connect.c +2 -0
@@ -4601,6 +4601,8 @@ cifs_construct_tcon(struct cifs_sb_info vol_info->nocase = master_tcon->nocase; vol_info->nohandlecache = master_tcon->nohandlecache; 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->linux_ext = master_tcon->posix_extensions; vol_info->sectype = master_tcon->ses->sectype;
Greg Kroah-Hartman
maintainerPATCH 31/36 SMB3: Honor lease disabling for multiuser mounts
In reply to Greg Kroah-HartmanFrom: Paul Aurich <[email protected]>
commit ad35f169db6cd5a4c5c0a5a42fb0cad3efeccb83 upstream.
--- fs/cifs/connect.c | 1 + 1 file changed, 1 insertion(+)
fs/cifs/connect.c +1 -0
@@ -4601,6 +4601,7 @@ cifs_construct_tcon(struct cifs_sb_info vol_info->nocase = master_tcon->nocase; vol_info->nohandlecache = master_tcon->nohandlecache; vol_info->local_lease = master_tcon->local_lease; + vol_info->no_lease = master_tcon->no_lease; vol_info->resilient = master_tcon->use_resilient; vol_info->persistent = master_tcon->use_persistent; vol_info->no_linux_ext = !master_tcon->unix_ext;
Greg Kroah-Hartman
maintainerPATCH 32/36 cifs: Fix the target file was deleted when rename failed.
In reply to Greg Kroah-HartmanFrom: Zhang Xiaoxu <[email protected]>
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.
--- fs/cifs/inode.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
fs/cifs/inode.c +8 -2
@@ -1783,6 +1783,7 @@ cifs_rename2(struct inode *source_dir, sFILE_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 ;
@@ -1859,8 +1860,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
Greg Kroah-Hartman
maintainerPATCH 33/36 MIPS: Add missing EHB in mtc0 -> mfc0 sequence for DSPen
In reply to Greg Kroah-HartmanFrom: Hauke Mehrtens <[email protected]>
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.
--- arch/mips/kernel/traps.c | 1 + 1 file changed, 1 insertion(+)
arch/mips/kernel/traps.c +1 -0
@@ -2096,6 +2096,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 (); }unsigned int hwrena;
Greg Kroah-Hartman
maintainerPATCH 34/36 irqchip/gic: Atomically update affinity
In reply to Greg Kroah-HartmanFrom: Marc Zyngier <[email protected]>
commit 005c34ae4b44f085120d7f371121ec7ded677761 upstream.
The GIC driver uses a RMW sequence to update the affinity, and relies on the gic_lock_irqsave/gic_unlock_irqrestore sequences to update it atomically.
But these sequences only expand into anything meaningful if the BL_SWITCHER option is selected, which almost never happens.
It also turns out that using a RMW and locks is just as silly, as the GIC distributor supports byte accesses for the GICD_TARGETRn registers, which when used make the update atomic by definition.
Drop the terminally broken code and replace it by a byte write.
--- drivers/irqchip/irq-gic.c | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-)
drivers/irqchip/irq-gic.c +3 -11
@@ -324,10 +324,8 @@ static int gic_irq_set_vcpu_affinity(strstatic int gic_set_affinity (struct irq_data *d,const struct cpumask *mask_val,bool force) { -void __iomem *reg =gic_dist_base (d) +GIC_DIST_TARGET + (gic_irq (d) & ~3 ); -unsigned int cpu, shift = (gic_irq (d) %4 ) *8 ; -u32 val, mask, bit; -unsigned long flags; +void __iomem *reg =gic_dist_base (d) +GIC_DIST_TARGET +gic_irq (d); +unsigned int cpu;if (!force) cpu =cpumask_any_and (mask_val, cpu_online_mask);
@@ -337,13 +335,7 @@ static int gic_set_affinity(struct irq_dif (cpu >=NR_GIC_CPU_IF || cpu >= nr_cpu_ids)return -EINVAL ; -gic_lock_irqsave (flags); - mask =0xff << shift; - bit = gic_cpu_map[cpu] << shift; - val =readl_relaxed (reg) & ~mask; -writel_relaxed (val | bit, reg); -gic_unlock_irqrestore (flags); - +writeb_relaxed (gic_cpu_map[cpu], reg);irq_data_update_effective_affinity (d,cpumask_of (cpu));return IRQ_SET_MASK_OK_DONE ;
Greg Kroah-Hartman
maintainerPATCH 35/36 dm zoned: assign max_io_len correctly
In reply to Greg Kroah-HartmanFrom: Hou Tao <[email protected]>
commit 7b2377486767503d47265e4d487a63c651f6b55d upstream.
The unit of max_io_len is sector instead of byte (spotted through code review), so fix it.
--- drivers/md/dm-zoned-target.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/dm-zoned-target.c +1 -1
@@ -789,7 +789,7 @@ static int dmz_ctr(struct dm_target *ti, }/* Set target (no write same support) */ - ti->max_io_len = dev->zone_nr_sectors <<9 ; + ti->max_io_len = dev->zone_nr_sectors; ti->num_flush_bios =1 ; ti->num_discard_bios =1 ; ti->num_write_zeroes_bios =1 ;
Greg Kroah-Hartman
maintainerPATCH 36/36 efi: Make it possible to disable efivar_ssdt entirely
In reply to Greg Kroah-HartmanFrom: Peter Jones <[email protected]>
commit 435d1a471598752446a72ad1201b3c980526d869 upstream.
In most cases, such as CONFIG_ACPI_CUSTOM_DSDT and CONFIG_ACPI_TABLE_UPGRADE, boot-time modifications to firmware tables are tied to specific Kconfig options. Currently this is not the case for modifying the ACPI SSDT via the efivar_ssdt kernel command line option and associated EFI variable.
This patch adds CONFIG_EFI_CUSTOM_SSDT_OVERLAYS, which defaults disabled, in order to allow enabling or disabling that feature during the build.
--- drivers/firmware/efi/Kconfig | 11 +++++++++++ drivers/firmware/efi/efi.c | 2 +- 2 files changed, 12 insertions(+), 1 deletion(-)
drivers/firmware/efi/Kconfig +11 -0
@@ -179,6 +179,17 @@ config RESET_ATTACK_MITIGATION have been evicted, since otherwise it will trigger even on clean reboots. +config EFI_CUSTOM_SSDT_OVERLAYS + bool "Load custom ACPI SSDT overlay from an EFI variable" + depends on EFI_VARS && ACPI + default ACPI_TABLE_UPGRADE + help + Allow loading of an ACPI SSDT overlay from an EFI variable specified + by a kernel command line option. + + See Documentation/admin-guide/acpi/ssdt-overlays.rst for more + information. + endmenu config UEFI_CPER
drivers/firmware/efi/efi.c +1 -1
@@ -236,7 +236,7 @@ static void generic_ops_unregister(void)efivars_unregister (&generic_efivars); } -#if IS_ENABLED (CONFIG_ACPI ) +#ifdef CONFIG_EFI_CUSTOM_SSDT_OVERLAYS #define EFIVAR_SSDT_NAME_MAX 16static char efivar_ssdt[EFIVAR_SSDT_NAME_MAX ]__initdata ;static int __init efivar_ssdt_setup (char *str)
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.132 release. There are 36 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:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.132-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.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.19.132-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: 168e2945aaf526364ca3aa3e674490d363c32a33
git describe: v4.19.130-164-g168e2945aaf5
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.130-164-g168e2945aaf5
No regressions (compared to build v4.19.130)
No fixes (compared to build v4.19.130)
Ran 33084 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
- x86-kasan
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* install-android-platform-tools-r2800
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-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
* v4l2-compliance
* kvm-unit-tests
* ltp-controllers-tests
* ltp-dio-tests
* ltp-fs-tests
* ltp-io-tests
* network-basic-tests
* perf
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Jon Hunter
maintainerQuoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.132 release. There are 36 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:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.132-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
All tests are passing for Tegra ...
Test results for stable-v4.19:
11 builds: 11 pass, 0 fail
22 boots: 22 pass, 0 fail
38 tests: 38 pass, 0 failLinux version: 4.19.132-rc1-g168e2945aaf5
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04Cheers
Jon
Signature · 1 line
nvpublic
Hello Greg,
Quoted 11 lines
From: [email protected] <[email protected]> On Behalf Of Greg Kroah-Hartman
Sent: 07 July 2020 16:17This is the start of the stable review cycle for the 4.19.132 release. There are 36 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.19.132-rc1 (168e2945aaf5).
Build/test pipeline/logs: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/164002971
GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.19.y.yml
Relevant LAVA jobs: https://lava.ciplatform.org/scheduler/alljobs?length=25&search=168e29#table
Kind regards, Chris
Quoted 176 lines
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-
review/patch-4.19.132-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.19.y
and the diffstat can be found below.thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:Greg Kroah-Hartman <[email protected]>
Linux 4.19.132-rc1Peter Jones <[email protected]>
efi: Make it possible to disableefivar_ssdtentirelyHou Tao <[email protected]>
dm zoned: assignmax_io_lencorrectlyMarc Zyngier <[email protected]>
irqchip/gic: Atomically update affinityHauke Mehrtens <[email protected]>
MIPS: Add missing EHB in mtc0 -> mfc0 sequence for DSPenZhang Xiaoxu <[email protected]>
cifs: Fix the target file was deleted when rename failed.Paul Aurich <[email protected]>
SMB3: Honor lease disabling for multiuser mountsPaul Aurich <[email protected]>
SMB3: Honor persistent/resilient handle flags for multiuser mountsPaul Aurich <[email protected]>
SMB3: Honor 'seal' flag for multiuser mountsGreg Kroah-Hartman <[email protected]>
Revert "ALSA: usb-audio: Improve frames size computation"J. Bruce Fields <[email protected]>
nfsd: apply umask on fs without ACL supportWolfram Sang <[email protected]>
i2c: mlxcpld: check correct size of maximumRECV_LENpacketChris Packham <[email protected]>
i2c: algo-pca: Add 0x78 as SCL stuck low status for PCA9665Christoph Hellwig <[email protected]>
nvme: fix a crash innvme_mpath_add_diskPaul Aurich <[email protected]>
SMB3: Honor 'posix' flag for multiuser mountsHou Tao <[email protected]>
virtio-blk: free vblk-vqs in error path ofvirtblk_probe()Chen-Yu Tsai <[email protected]>
drm: sun4i: hdmi: Remove extra HPD pollingMisono Tomohiro <[email protected]>
hwmon: (acpi_power_meter) Fix potential memory leak inacpi_power_meter_add()Chu Lin <[email protected]>
hwmon: (max6697) Make sure the OVERT mask is set correctlyRahul Lakkireddy <[email protected]>
cxgb4: fix SGE queue dump destination buffer contextRahul Lakkireddy <[email protected]>
cxgb4: use correct type for all-mask IP address comparisonRahul Lakkireddy <[email protected]>
cxgb4: parse TC-U32 key values and masks nativelyRahul Lakkireddy <[email protected]>
cxgb4: use unaligned conversion for fetching timestampChen Tao <[email protected]>
drm/msm/dpu: fix error return code indpu_encoder_initHerbert Xu <[email protected]>
crypto:af_alg- fix use-after-free inaf_alg_accept()due tobh_lock_sock()Douglas Anderson <[email protected]>
kgdb: Avoid suspicious RCU usage warningAnton Eidelman <[email protected]>
nvme-multipath: fix deadlock betweenana_workandscan_workSagi Grimberg <[email protected]>
nvme: fix possible deadlock when I/O is blockedKeith Busch <[email protected]>
nvme-multipath: set bdi capabilities onceChristian Borntraeger <[email protected]>
s390/debug: avoid kernel warning on too large number of pagesZqiang <[email protected]>
usb: usbtest: fix missing kfree(dev->buf) in usbtest_disconnectQian Cai <[email protected]>
mm/slub: fix stack overruns withSLUB_STATSDongli Zhang <[email protected]>
mm/slub.c: fix corrupted freechain indeactivate_slab()Tuomas Tynkkynen <[email protected]>
usbnet: smsc95xx: Fix use-after-free after removalBorislav Petkov <[email protected]>
EDAC/amd64: Read back the scrub rate PCI register on F15hHugh Dickins <[email protected]>
mm: fix swap cache node allocation maskFilipe Manana <[email protected]>
btrfs: fix a block group ref counter leak after failure to remove block group-------------
Diffstat:
Makefile | 4 +- arch/mips/kernel/traps.c | 1 + arch/s390/kernel/debug.c | 3 +- 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/firmware/efi/Kconfig | 11 ++ drivers/firmware/efi/efi.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +- drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 5 +- drivers/hwmon/acpi_power_meter.c | 4 +- drivers/hwmon/max6697.c | 7 +- drivers/i2c/algos/i2c-algo-pca.c | 3 +- drivers/i2c/busses/i2c-mlxcpld.c | 4 +- drivers/irqchip/irq-gic.c | 14 +-- drivers/md/dm-zoned-target.c | 2 +- drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c | 6 +- drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c | 10 +- drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c | 18 +-- .../ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h | 122 ++++++++++++++------- drivers/net/ethernet/chelsio/cxgb4/sge.c | 2 +- drivers/net/usb/smsc95xx.c | 2 +- drivers/nvme/host/core.c | 1 - drivers/nvme/host/multipath.c | 33 ++++-- drivers/usb/misc/usbtest.c | 1 + fs/btrfs/extent-tree.c | 19 ++-- fs/cifs/connect.c | 9 +- fs/cifs/inode.c | 10 +- fs/nfsd/vfs.c | 6 + include/crypto/if_alg.h | 4 +- kernel/debug/debug_core.c | 4 + mm/slub.c | 30 ++++- mm/swap_state.c | 3 +- sound/usb/card.h | 4 - sound/usb/endpoint.c | 43 +------- sound/usb/endpoint.h | 1 - sound/usb/pcm.c | 2 - 40 files changed, 256 insertions(+), 192 deletions(-)
Greg Kroah-Hartman
maintainerQuoted 11 lines · Chris Paterson
Hello Greg,
Quoted 9 lines
From: [email protected] <[email protected]> On Behalf Of Greg Kroah-Hartman
Sent: 07 July 2020 16:17This is the start of the stable review cycle for the 4.19.132 release. There are 36 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.
Quoted 8 lines
Quoted 2 lines
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.19.132-rc1 (
168e2945aaf5).Build/test pipeline/logs: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/164002971
GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.19.y.yml
Relevant LAVA jobs: https://lava.ciplatform.org/scheduler/alljobs?length=25&search=168e29#table
Thanks for testing two of these and letting me know.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.132 release. There are 36 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:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.132-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.132 release. There are 36 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.
Build results:
total: 155 pass: 155 fail: 0 Qemu test results: total: 420 pass: 420 fail: 0
Guenter