commit 63b9d2e001fd7ceae418ee124ae228f63f921323 Author: Greg Kroah-Hartman Date: Tue Feb 23 15:53:25 2021 +0100 Linux 5.10.18 Tested-by: Florian Fainelli Tested-by: Pavel Machek (CIP) Tested-by: Guenter Roeck Tested-by: Igor Matheus Andrade Torrente Tested-by: Jason Self Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20210222121019.444399883@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit c6152fd3ac2b92e0ab798a2f9d852ced06e87a4a Author: Matwey V. Kornilov Date: Mon Jan 4 18:00:07 2021 +0100 media: pwc: Use correct device for DMA commit 69c9e825e812ec6d663e64ebf14bd3bc7f37e2c7 upstream. This fixes the following newly introduced warning: [ 15.518253] ------------[ cut here ]------------ [ 15.518941] WARNING: CPU: 0 PID: 246 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x1a8/0x1d0 [ 15.520634] Modules linked in: pwc videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc efivarfs [ 15.522335] CPU: 0 PID: 246 Comm: v4l2-test Not tainted 5.11.0-rc1+ #1 [ 15.523281] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [ 15.524438] RIP: 0010:dma_map_page_attrs+0x1a8/0x1d0 [ 15.525135] Code: 10 5b 5d 41 5c 41 5d c3 4d 89 d0 eb d7 4d 89 c8 89 e9 48 89 da e8 68 29 00 00 eb d1 48 89 f2 48 2b 50 18 48 89 d0 eb 83 0f 0b <0f> 0b 48 c7 c0 ff ff ff ff eb b8 48 89 d9 48 8b 40 40 e8 61 69 d2 [ 15.527938] RSP: 0018:ffffa2694047bca8 EFLAGS: 00010246 [ 15.528716] RAX: 0000000000000000 RBX: 0000000000002580 RCX: 0000000000000000 [ 15.529782] RDX: 0000000000000000 RSI: ffffcdce000ecc00 RDI: ffffa0b4bdb888a0 [ 15.530849] RBP: 0000000000000002 R08: 0000000000000002 R09: 0000000000000000 [ 15.531881] R10: 0000000000000004 R11: 000000000002d8c0 R12: 0000000000000000 [ 15.532911] R13: ffffa0b4bdb88800 R14: ffffa0b483820000 R15: ffffa0b4bdb888a0 [ 15.533942] FS: 00007fc5fbb5e4c0(0000) GS:ffffa0b4fc000000(0000) knlGS:0000000000000000 [ 15.535141] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 15.535988] CR2: 00007fc5fb6ea138 CR3: 0000000003812000 CR4: 00000000001506f0 [ 15.537025] Call Trace: [ 15.537425] start_streaming+0x2e9/0x4b0 [pwc] [ 15.538143] vb2_start_streaming+0x5e/0x110 [videobuf2_common] [ 15.538989] vb2_core_streamon+0x107/0x140 [videobuf2_common] [ 15.539831] __video_do_ioctl+0x18f/0x4a0 [videodev] [ 15.540670] video_usercopy+0x13a/0x5b0 [videodev] [ 15.541349] ? video_put_user+0x230/0x230 [videodev] [ 15.542096] ? selinux_file_ioctl+0x143/0x200 [ 15.542752] v4l2_ioctl+0x40/0x50 [videodev] [ 15.543360] __x64_sys_ioctl+0x89/0xc0 [ 15.543930] do_syscall_64+0x33/0x40 [ 15.544448] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 15.545236] RIP: 0033:0x7fc5fb671587 [ 15.545780] Code: b3 66 90 48 8b 05 11 49 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e1 48 2c 00 f7 d8 64 89 01 48 [ 15.548486] RSP: 002b:00007fff0f71f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 15.549578] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fc5fb671587 [ 15.550664] RDX: 00007fff0f71f060 RSI: 0000000040045612 RDI: 0000000000000003 [ 15.551706] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 15.552738] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff0f71f060 [ 15.553817] R13: 00007fff0f71f1d0 R14: 0000000000de1270 R15: 0000000000000000 [ 15.554914] ---[ end trace 7be03122966c2486 ]--- Fixes: 1161db6776bd ("media: usb: pwc: Don't use coherent DMA buffers for ISO transfer") Signed-off-by: Matwey V. Kornilov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit a6703c71153438d3ebdf58a75d53dd5e57b33095 Author: Filipe Manana Date: Tue Feb 16 14:40:31 2021 +0000 btrfs: fix crash after non-aligned direct IO write with O_DSYNC Whenever we attempt to do a non-aligned direct IO write with O_DSYNC, we end up triggering an assertion and crashing. Example reproducer: $ cat test.sh #!/bin/bash DEV=/dev/sdj MNT=/mnt/sdj mkfs.btrfs -f $DEV > /dev/null mount $DEV $MNT # Do a direct IO write with O_DSYNC into a non-aligned range... xfs_io -f -d -s -c "pwrite -S 0xab -b 64K 1111 64K" $MNT/foobar umount $MNT When running the reproducer an assertion fails and produces the following trace: [ 2418.403134] assertion failed: !current->journal_info || flush != BTRFS_RESERVE_FLUSH_DATA, in fs/btrfs/space-info.c:1467 [ 2418.403745] ------------[ cut here ]------------ [ 2418.404306] kernel BUG at fs/btrfs/ctree.h:3286! [ 2418.404862] invalid opcode: 0000 [#2] PREEMPT SMP DEBUG_PAGEALLOC PTI [ 2418.405451] CPU: 1 PID: 64705 Comm: xfs_io Tainted: G D 5.10.15-btrfs-next-87 #1 [ 2418.406026] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 2418.407228] RIP: 0010:assertfail.constprop.0+0x18/0x26 [btrfs] [ 2418.407835] Code: e6 48 c7 (...) [ 2418.409078] RSP: 0018:ffffb06080d13c98 EFLAGS: 00010246 [ 2418.409696] RAX: 000000000000006c RBX: ffff994c1debbf08 RCX: 0000000000000000 [ 2418.410302] RDX: 0000000000000000 RSI: 0000000000000027 RDI: 00000000ffffffff [ 2418.410904] RBP: ffff994c21770000 R08: 0000000000000000 R09: 0000000000000000 [ 2418.411504] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000010000 [ 2418.412111] R13: ffff994c22198400 R14: ffff994c21770000 R15: 0000000000000000 [ 2418.412713] FS: 00007f54fd7aff00(0000) GS:ffff994d35200000(0000) knlGS:0000000000000000 [ 2418.413326] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2418.413933] CR2: 000056549596d000 CR3: 000000010b928003 CR4: 0000000000370ee0 [ 2418.414528] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2418.415109] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2418.415669] Call Trace: [ 2418.416254] btrfs_reserve_data_bytes.cold+0x22/0x22 [btrfs] [ 2418.416812] btrfs_check_data_free_space+0x4c/0xa0 [btrfs] [ 2418.417380] btrfs_buffered_write+0x1b0/0x7f0 [btrfs] [ 2418.418315] btrfs_file_write_iter+0x2a9/0x770 [btrfs] [ 2418.418920] new_sync_write+0x11f/0x1c0 [ 2418.419430] vfs_write+0x2bb/0x3b0 [ 2418.419972] __x64_sys_pwrite64+0x90/0xc0 [ 2418.420486] do_syscall_64+0x33/0x80 [ 2418.420979] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 2418.421486] RIP: 0033:0x7f54fda0b986 [ 2418.421981] Code: 48 c7 c0 (...) [ 2418.423019] RSP: 002b:00007ffc40569c38 EFLAGS: 00000246 ORIG_RAX: 0000000000000012 [ 2418.423547] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f54fda0b986 [ 2418.424075] RDX: 0000000000010000 RSI: 000056549595e000 RDI: 0000000000000003 [ 2418.424596] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000400 [ 2418.425119] R10: 0000000000000400 R11: 0000000000000246 R12: 00000000ffffffff [ 2418.425644] R13: 0000000000000400 R14: 0000000000010000 R15: 0000000000000000 [ 2418.426148] Modules linked in: btrfs blake2b_generic (...) [ 2418.429540] ---[ end trace ef2aeb44dc0afa34 ]--- 1) At btrfs_file_write_iter() we set current->journal_info to BTRFS_DIO_SYNC_STUB; 2) We then call __btrfs_direct_write(), which calls btrfs_direct_IO(); 3) We can't do the direct IO write because it starts at a non-aligned offset (1111). So at btrfs_direct_IO() we return -EINVAL (coming from check_direct_IO() which does the alignment check), but we leave current->journal_info set to BTRFS_DIO_SYNC_STUB - we only clear it at btrfs_dio_iomap_begin(), because we assume we always get there; 4) Then at __btrfs_direct_write() we see that the attempt to do the direct IO write was not successful, 0 bytes written, so we fallback to a buffered write by calling btrfs_buffered_write(); 5) There we call btrfs_check_data_free_space() which in turn calls btrfs_alloc_data_chunk_ondemand() and that calls btrfs_reserve_data_bytes() with flush == BTRFS_RESERVE_FLUSH_DATA; 6) Then at btrfs_reserve_data_bytes() we have current->journal_info set to BTRFS_DIO_SYNC_STUB, therefore not NULL, and flush has the value BTRFS_RESERVE_FLUSH_DATA, triggering the second assertion: int btrfs_reserve_data_bytes(struct btrfs_fs_info *fs_info, u64 bytes, enum btrfs_reserve_flush_enum flush) { struct btrfs_space_info *data_sinfo = fs_info->data_sinfo; int ret; ASSERT(flush == BTRFS_RESERVE_FLUSH_DATA || flush == BTRFS_RESERVE_FLUSH_FREE_SPACE_INODE); ASSERT(!current->journal_info || flush != BTRFS_RESERVE_FLUSH_DATA); (...) So fix that by setting the journal to NULL whenever check_direct_IO() returns a failure. This bug only affects 5.10 kernels, and the regression was introduced in 5.10-rc1 by commit 0eb79294dbe328 ("btrfs: dio iomap DSYNC workaround"). The bug does not exist in 5.11 kernels due to commit ecfdc08b8cc65d ("btrfs: remove dio iomap DSYNC workaround"), which depends on a large patchset that went into the merge window for 5.11. So this is a fix only for 5.10.x stable kernels, as there are people hitting this bug. Fixes: 0eb79294dbe328 ("btrfs: dio iomap DSYNC workaround") CC: stable@vger.kernel.org # 5.10 (and only 5.10) Acked-by: David Sterba Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1181605 Signed-off-by: Filipe Manana Signed-off-by: Greg Kroah-Hartman commit aa0fd921d2079dd5fd87466f087a44eae8844217 Author: David Sterba Date: Fri Feb 19 19:00:16 2021 +0100 btrfs: fix backport of 2175bf57dc952 in 5.10.13 There's a mistake in backport of upstream commit 2175bf57dc95 ("btrfs: fix possible free space tree corruption with online conversion") as 5.10.13 commit 2175bf57dc95. The enum value BTRFS_FS_FREE_SPACE_TREE_UNTRUSTED has been added to the wrong enum set, colliding with value of BTRFS_FS_QUOTA_ENABLE. This could cause problems during the tree conversion, where the quotas wouldn't be set up properly but the related code executed anyway due to the bit set. Link: https://lore.kernel.org/linux-btrfs/20210219111741.95DD.409509F4@e16-tech.com Reported-by: Wang Yugui CC: stable@vger.kernel.org # 5.10.13+ Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit df443aad518d788ac1df3af02ec97b733aabc364 Author: Trent Piepho Date: Wed Dec 9 17:20:03 2020 -0800 Bluetooth: btusb: Always fallback to alt 1 for WBS commit 517b693351a2d04f3af1fc0e506ac7e1346094de upstream. When alt mode 6 is not available, fallback to the kernel <= 5.7 behavior of always using alt mode 1. Prior to kernel 5.8, btusb would always use alt mode 1 for WBS (Wide Band Speech aka mSBC aka transparent SCO). In commit baac6276c0a9 ("Bluetooth: btusb: handle mSBC audio over USB Endpoints") this was changed to use alt mode 6, which is the recommended mode in the Bluetooth spec (Specifications of the Bluetooth System, v5.0, Vol 4.B ยง2.2.1). However, many if not most BT USB adapters do not support alt mode 6. In fact, I have been unable to find any which do. In kernel 5.8, this was changed to use alt mode 6, and if not available, use alt mode 0. But mode 0 has a zero byte max packet length and can not possibly work. It is just there as a zero-bandwidth dummy mode to work around a USB flaw that would prevent device enumeration if insufficient bandwidth were available for the lowest isoc mode supported. In effect, WBS was broken for all USB-BT adapters that do not support alt 6, which appears to nearly all of them. Then in commit 461f95f04f19 ("Bluetooth: btusb: USB alternate setting 1 for WBS") the 5.7 behavior was restored, but only for Realtek adapters. I've tested a Broadcom BRCM20702A and CSR 8510 adapter, both work with the 5.7 behavior and do not with the 5.8. So get rid of the Realtek specific flag and use the 5.7 behavior for all adapters as a fallback when alt 6 is not available. This was the kernel's behavior prior to 5.8 and I can find no adapters for which it is not correct. And even if there is an adapter for which this does not work, the current behavior would be to fall back to alt 0, which can not possibly work either, and so is no better. Signed-off-by: Trent Piepho Signed-off-by: Marcel Holtmann Cc: Salvatore Bonaccorso Cc: Sjoerd Simons Cc: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit ffec7ee21809c9c284042875b8d76b0d70a42585 Author: Linus Torvalds Date: Sat Feb 20 21:15:00 2021 -0800 tty: protect tty_write from odd low-level tty disciplines commit 3342ff2698e9720f4040cc458a2744b2b32f5c3a upstream. Al root-caused a new warning from syzbot to the ttyprintk tty driver returning a write count larger than the data the tty layer actually gave it. Which confused the tty write code mightily, and with the new iov_iter based code, caused a WARNING in iov_iter_revert(). syzbot correctly bisected the source of the new warning to commit 9bb48c82aced ("tty: implement write_iter"), but the oddity goes back much further, it just didn't get caught by anything before. Reported-by: syzbot+3d2c27c2b7dc2a94814d@syzkaller.appspotmail.com Fixes: 9bb48c82aced ("tty: implement write_iter") Debugged-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 00805af45a21729e2901a37914992786a0d32c46 Author: Jan Beulich Date: Mon Feb 15 08:56:44 2021 +0100 xen-blkback: fix error handling in xen_blkbk_map() commit 871997bc9e423f05c7da7c9178e62dde5df2a7f8 upstream. The function uses a goto-based loop, which may lead to an earlier error getting discarded by a later iteration. Exit this ad-hoc loop when an error was encountered. The out-of-memory error path additionally fails to fill a structure field looked at by xen_blkbk_unmap_prepare() before inspecting the handle which does get properly set (to BLKBACK_INVALID_HANDLE). Since the earlier exiting from the ad-hoc loop requires the same field filling (invalidation) as that on the out-of-memory path, fold both paths. While doing so, drop the pr_alert(), as extra log messages aren't going to help the situation (the kernel will log oom conditions already anyway). This is XSA-365. Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Reviewed-by: Julien Grall Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 9bea436fc3fc9a820b8b34e83708971c1813b892 Author: Jan Beulich Date: Mon Feb 15 08:55:57 2021 +0100 xen-scsiback: don't "handle" error by BUG() commit 7c77474b2d22176d2bfb592ec74e0f2cb71352c9 upstream. In particular -ENOMEM may come back here, from set_foreign_p2m_mapping(). Don't make problems worse, the more that handling elsewhere (together with map's status fields now indicating whether a mapping wasn't even attempted, and hence has to be considered failed) doesn't require this odd way of dealing with errors. This is part of XSA-362. Signed-off-by: Jan Beulich Cc: stable@vger.kernel.org Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 2814b3aa38a679c63aa535355b02a5bd0f681a83 Author: Jan Beulich Date: Mon Feb 15 08:55:31 2021 +0100 xen-netback: don't "handle" error by BUG() commit 3194a1746e8aabe86075fd3c5e7cf1f4632d7f16 upstream. In particular -ENOMEM may come back here, from set_foreign_p2m_mapping(). Don't make problems worse, the more that handling elsewhere (together with map's status fields now indicating whether a mapping wasn't even attempted, and hence has to be considered failed) doesn't require this odd way of dealing with errors. This is part of XSA-362. Signed-off-by: Jan Beulich Cc: stable@vger.kernel.org Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 8f8ebd6b1cb5cff96a11cd336027e745d48c2cab Author: Jan Beulich Date: Mon Feb 15 08:54:51 2021 +0100 xen-blkback: don't "handle" error by BUG() commit 5a264285ed1cd32e26d9de4f3c8c6855e467fd63 upstream. In particular -ENOMEM may come back here, from set_foreign_p2m_mapping(). Don't make problems worse, the more that handling elsewhere (together with map's status fields now indicating whether a mapping wasn't even attempted, and hence has to be considered failed) doesn't require this odd way of dealing with errors. This is part of XSA-362. Signed-off-by: Jan Beulich Cc: stable@vger.kernel.org Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 0462dbbe2cab43528f943575b510625cf422921a Author: Stefano Stabellini Date: Mon Feb 15 08:53:44 2021 +0100 xen/arm: don't ignore return errors from set_phys_to_machine commit 36bf1dfb8b266e089afa9b7b984217f17027bf35 upstream. set_phys_to_machine can fail due to lack of memory, see the kzalloc call in arch/arm/xen/p2m.c:__set_phys_to_machine_multi. Don't ignore the potential return error in set_foreign_p2m_mapping, returning it to the caller instead. This is part of XSA-361. Signed-off-by: Stefano Stabellini Cc: stable@vger.kernel.org Reviewed-by: Julien Grall Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit be89a0300a58c273b6f48bb8db01c807e203098b Author: Jan Beulich Date: Mon Feb 15 08:52:27 2021 +0100 Xen/gntdev: correct error checking in gntdev_map_grant_pages() commit ebee0eab08594b2bd5db716288a4f1ae5936e9bc upstream. Failure of the kernel part of the mapping operation should also be indicated as an error to the caller, or else it may assume the respective kernel VA is okay to access. Furthermore gnttab_map_refs() failing still requires recording successfully mapped handles, so they can be unmapped subsequently. This in turn requires there to be a way to tell full hypercall failure from partial success - preset map_op status fields such that they won't "happen" to look as if the operation succeeded. Also again use GNTST_okay instead of implying its value (zero). This is part of XSA-361. Signed-off-by: Jan Beulich Cc: stable@vger.kernel.org Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 1a5c2274349f5b6f3b6bbdf43247e71a50ae6e2f Author: Jan Beulich Date: Mon Feb 15 08:51:07 2021 +0100 Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages() commit dbe5283605b3bc12ca45def09cc721a0a5c853a2 upstream. We may not skip setting the field in the unmap structure when GNTMAP_device_map is in use - such an unmap would fail to release the respective resources (a page ref in the hypervisor). Otoh the field doesn't need setting at all when GNTMAP_device_map is not in use. To record the value for unmapping, we also better don't use our local p2m: In particular after a subsequent change it may not have got updated for all the batch elements. Instead it can simply be taken from the respective map's results. We can additionally avoid playing this game altogether for the kernel part of the mappings in (x86) PV mode. This is part of XSA-361. Signed-off-by: Jan Beulich Cc: stable@vger.kernel.org Reviewed-by: Stefano Stabellini Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 0c08037b56a77219a6ec67c2cb19abf38722a525 Author: Jan Beulich Date: Mon Feb 15 08:50:08 2021 +0100 Xen/x86: also check kernel mapping in set_foreign_p2m_mapping() commit b512e1b077e5ccdbd6e225b15d934ab12453b70a upstream. We should not set up further state if either mapping failed; paying attention to just the user mapping's status isn't enough. Also use GNTST_okay instead of implying its value (zero). This is part of XSA-361. Signed-off-by: Jan Beulich Cc: stable@vger.kernel.org Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 740f4d9d0c34ea99279acf2fc99ae33c0142265a Author: Jan Beulich Date: Mon Feb 15 08:49:34 2021 +0100 Xen/x86: don't bail early from clear_foreign_p2m_mapping() commit a35f2ef3b7376bfd0a57f7844bd7454389aae1fc upstream. Its sibling (set_foreign_p2m_mapping()) as well as the sibling of its only caller (gnttab_map_refs()) don't clean up after themselves in case of error. Higher level callers are expected to do so. However, in order for that to really clean up any partially set up state, the operation should not terminate upon encountering an entry in unexpected state. It is particularly relevant to notice here that set_foreign_p2m_mapping() would skip setting up a p2m entry if its grant mapping failed, but it would continue to set up further p2m entries as long as their mappings succeeded. Arguably down the road set_foreign_p2m_mapping() may want its page state related WARN_ON() also converted to an error return. This is part of XSA-361. Signed-off-by: Jan Beulich Cc: stable@vger.kernel.org Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 06ab1e63ec5c72255fae316c59ea9c0475eadac8 Author: Yonatan Linik Date: Mon Dec 14 22:25:50 2020 +0200 net: fix proc_fs init handling in af_packet and tls [ Upstream commit a268e0f2455c32653140775662b40c2b1f1b2efa ] proc_fs was used, in af_packet, without a surrounding #ifdef, although there is no hard dependency on proc_fs. That caused the initialization of the af_packet module to fail when CONFIG_PROC_FS=n. Specifically, proc_create_net() was used in af_packet.c, and when it fails, packet_net_init() returns -ENOMEM. It will always fail when the kernel is compiled without proc_fs, because, proc_create_net() for example always returns NULL. The calling order that starts in af_packet.c is as follows: packet_init() register_pernet_subsys() register_pernet_operations() __register_pernet_operations() ops_init() ops->init() (packet_net_ops.init=packet_net_init()) proc_create_net() It worked in the past because register_pernet_subsys()'s return value wasn't checked before this Commit 36096f2f4fa0 ("packet: Fix error path in packet_init."). It always returned an error, but was not checked before, so everything was working even when CONFIG_PROC_FS=n. The fix here is simply to add the necessary #ifdef. This also fixes a similar error in tls_proc.c, that was found by Jakub Kicinski. Fixes: d26b698dd3cd ("net/tls: add skeleton of MIB statistics") Fixes: 36096f2f4fa0 ("packet: Fix error path in packet_init") Signed-off-by: Yonatan Linik Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ba2582cd7f20cec3d4c32bcc7a5a6f9645d3a654 Author: Wang Hai Date: Fri Dec 11 20:29:21 2020 +0800 net: bridge: Fix a warning when del bridge sysfs [ Upstream commit 989a1db06eb18ff605377eec87e18d795e0ec74b ] I got a warining report: br_sysfs_addbr: can't create group bridge4/bridge ------------[ cut here ]------------ sysfs group 'bridge' not found for kobject 'bridge4' WARNING: CPU: 2 PID: 9004 at fs/sysfs/group.c:279 sysfs_remove_group fs/sysfs/group.c:279 [inline] WARNING: CPU: 2 PID: 9004 at fs/sysfs/group.c:279 sysfs_remove_group+0x153/0x1b0 fs/sysfs/group.c:270 Modules linked in: iptable_nat ... Call Trace: br_dev_delete+0x112/0x190 net/bridge/br_if.c:384 br_dev_newlink net/bridge/br_netlink.c:1381 [inline] br_dev_newlink+0xdb/0x100 net/bridge/br_netlink.c:1362 __rtnl_newlink+0xe11/0x13f0 net/core/rtnetlink.c:3441 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3500 rtnetlink_rcv_msg+0x385/0x980 net/core/rtnetlink.c:5562 netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2494 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x793/0xc80 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg+0x139/0x170 net/socket.c:671 ____sys_sendmsg+0x658/0x7d0 net/socket.c:2353 ___sys_sendmsg+0xf8/0x170 net/socket.c:2407 __sys_sendmsg+0xd3/0x190 net/socket.c:2440 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 In br_device_event(), if the bridge sysfs fails to be added, br_device_event() should return error. This can prevent warining when removing bridge sysfs that do not exist. Fixes: bb900b27a2f4 ("bridge: allow creating bridge devices with netlink") Reported-by: Hulk Robot Signed-off-by: Wang Hai Tested-by: Nikolay Aleksandrov Acked-by: Nikolay Aleksandrov Link: https://lore.kernel.org/r/20201211122921.40386-1-wanghai38@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2bce178c254c5df3df353962b891d2cc63c4afed Author: Eelco Chaudron Date: Mon Dec 7 05:08:39 2020 -0500 net: openvswitch: fix TTL decrement exception action execution [ Upstream commit 09d6217254c004f6237cc2c2bfe604af58e9a8c5 ] Currently, the exception actions are not processed correctly as the wrong dataset is passed. This change fixes this, including the misleading comment. In addition, a check was added to make sure we work on an IPv4 packet, and not just assume if it's not IPv6 it's IPv4. This was all tested using OVS with patch, https://patchwork.ozlabs.org/project/openvswitch/list/?series=21639, applied and sending packets with a TTL of 1 (and 0), both with IPv4 and IPv6. Fixes: 69929d4c49e1 ("net: openvswitch: fix TTL decrement action netlink message format") Signed-off-by: Eelco Chaudron Link: https://lore.kernel.org/r/160733569860.3007.12938188180387116741.stgit@wsfd-netdev64.ntdv.lab.eng.bos.redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 78b12034d4c394a9d7c9fa47c6b738fb0571b218 Author: Pablo Neira Ayuso Date: Tue Dec 8 21:47:07 2020 +0100 net: sched: incorrect Kconfig dependencies on Netfilter modules [ Upstream commit 102e2c07239c07144d9c7338ec09b9d47f2e5f79 ] - NET_ACT_CONNMARK and NET_ACT_CTINFO only require conntrack support. - NET_ACT_IPT only requires NETFILTER_XTABLES symbols, not IP_NF_IPTABLES. After this patch, NET_ACT_IPT becomes consistent with NET_EMATCH_IPT. NET_ACT_IPT dependency on IP_NF_IPTABLES predates Linux-2.6.12-rc2 (initial git repository build). Fixes: 22a5dc0e5e3e ("net: sched: Introduce connmark action") Fixes: 24ec483cec98 ("net: sched: Introduce act_ctinfo action") Signed-off-by: Pablo Neira Ayuso Link: https://lore.kernel.org/r/20201208204707.11268-1-pablo@netfilter.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f9d6533d18fd80412dc0450cf751ad144e698a23 Author: Lorenzo Bianconi Date: Wed Nov 18 00:18:18 2020 +0100 mt76: mt7615: fix rdd mcu cmd endianness [ Upstream commit 0211c282bc8aaa15343aadbc6e23043e7057f77d ] Similar to mt7915 driver, fix mt7615 radar mcu command endianness Fixes: 2ce73efe0f8e5 ("mt76: mt7615: initialize radar specs from host driver") Fixes: 70911d9638069 ("mt76: mt7615: add radar pattern test knob to debugfs") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 977060d4ec5be132b8ec87713b7aa66a12a03089 Author: Felix Fietkau Date: Thu Nov 12 15:23:28 2020 +0100 mt76: mt7915: fix endian issues [ Upstream commit cee236e1489ecca9d23d6ce6f60d126cc651a5ba ] Multiple MCU messages were using u16/u32 fields without endian annotations or conversions Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Fixes: 5517f78b0063 ("mt76: mt7915: enable firmware module debug support") Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 496ef46dbf6dcc432597f53af7be92c6a41dabec Author: wenxu Date: Wed Nov 25 12:01:21 2020 +0800 net/sched: fix miss init the mru in qdisc_skb_cb [ Upstream commit aadaca9e7c392dbf877af8cefb156199f1a67bbe ] The mru in the qdisc_skb_cb should be init as 0. Only defrag packets in the act_ct will set the value. Fixes: 038ebb1a713d ("net/sched: act_ct: fix miss set mru for ovs after defrag in act_ct") Signed-off-by: wenxu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 40bf5450ba6fb587b54a9e19abc41412c8f8b825 Author: Florian Westphal Date: Thu Nov 19 11:45:56 2020 -0800 mptcp: skip to next candidate if subflow has unacked data [ Upstream commit 860975c6f80adae9d2c7654bde04a99dd28bc94f ] In case a subflow path is blocked, MPTCP-level retransmit may not take place anymore because such subflow is likely to have unacked data left in its write queue. Ignore subflows that have experienced loss and test next candidate. Fixes: 3b1d6210a95773691 ("mptcp: implement and use MPTCP-level retransmission") Signed-off-by: Florian Westphal Signed-off-by: Mat Martineau Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 36e4b93838906cf5bdc20bf08b3da077404f3bf5 Author: Loic Poulain Date: Fri Nov 6 18:33:26 2020 +0100 net: qrtr: Fix port ID for control messages [ Upstream commit ae068f561baa003d260475c3e441ca454b186726 ] The port ID for control messages was uncorrectly set with broadcast node ID value, causing message to be dropped on remote side since not passing packet filtering (cb->dst_port != QRTR_PORT_CTRL). Fixes: d27e77a3de28 ("net: qrtr: Reset the node and port ID of broadcast messages") Signed-off-by: Loic Poulain Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c313e91b97ebbe347235f4367324039a7e678a4b Author: Max Gurtovoy Date: Mon Oct 19 12:46:28 2020 +0300 IB/isert: add module param to set sg_tablesize for IO cmd [ Upstream commit dae7a75f1f19bffb579daf148f8d8addd2726772 ] Currently, iser target support max IO size of 16MiB by default. For some adapters, allocating this amount of resources might reduce the total number of possible connections that can be created. For those adapters, it's preferred to reduce the max IO size to be able to create more connections. Since there is no handshake procedure for max IO size in iser protocol, set the default max IO size to 1MiB and add a module parameter for enabling the option to control it for suitable adapters. Fixes: 317000b926b0 ("IB/isert: allocate RW ctxs according to max IO size") Link: https://lore.kernel.org/r/20201019094628.17202-1-mgurtovoy@nvidia.com Reported-by: Krishnamraju Eraparaju Reviewed-by: Sagi Grimberg Signed-off-by: Max Gurtovoy Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 5840f8687fdfa77052f3f67d6cedc815032f669e Author: Stefano Garzarella Date: Tue Dec 15 15:42:50 2020 +0100 vdpa_sim: add get_config callback in vdpasim_dev_attr commit 65b709586e222fa6ffd4166ac7fdb5d5dad113ee upstream. The get_config callback can be used by the device to fill the config structure. The callback will be invoked in vdpasim_get_config() before copying bytes into caller buffer. Move vDPA-net config updates from vdpasim_set_features() in the new vdpasim_net_get_config() callback. This is safe since in vdpa_get_config() we already check that .set_features() callback is called before .get_config(). Signed-off-by: Stefano Garzarella Link: https://lore.kernel.org/r/20201215144256.155342-13-sgarzare@redhat.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Stefano Garzarella Signed-off-by: Greg Kroah-Hartman commit 8faf3ea12225337d07623f61349cba9b6d78500b Author: Stefano Garzarella Date: Tue Dec 15 15:42:49 2020 +0100 vdpa_sim: make 'config' generic and usable for any device type commit f37cbbc65178e0a45823d281d290c4c02da9631c upstream. Add new 'config_size' attribute in 'vdpasim_dev_attr' and allocates 'config' dynamically to support any device types. Acked-by: Jason Wang Signed-off-by: Stefano Garzarella Link: https://lore.kernel.org/r/20201215144256.155342-12-sgarzare@redhat.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Stefano Garzarella Signed-off-by: Greg Kroah-Hartman commit 0fb67eda6a9c67e206d87d5a68f424d4316fa74d Author: Stefano Garzarella Date: Tue Dec 15 15:42:48 2020 +0100 vdpa_sim: store parsed MAC address in a buffer commit cf1a3b35382c10ce315c32bd2b3d7789897fbe13 upstream. As preparation for the next patches, we store the MAC address, parsed during the vdpasim_create(), in a buffer that will be used to fill 'config' together with other configurations. Acked-by: Jason Wang Signed-off-by: Stefano Garzarella Link: https://lore.kernel.org/r/20201215144256.155342-11-sgarzare@redhat.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Stefano Garzarella Signed-off-by: Greg Kroah-Hartman commit 0ed8181561be3c335778e14cf46ed2d7a4f7d742 Author: Stefano Garzarella Date: Tue Dec 15 15:42:44 2020 +0100 vdpa_sim: add struct vdpasim_dev_attr for device attributes commit 6c6e28fe45794054410ad8cd2770af69fbe0338d upstream. vdpasim_dev_attr will contain device specific attributes. We starting moving the number of virtqueues (i.e. nvqs) to vdpasim_dev_attr. vdpasim_create() creates a new vDPA simulator following the device attributes defined in the vdpasim_dev_attr parameter. Co-developed-by: Max Gurtovoy Signed-off-by: Max Gurtovoy Acked-by: Jason Wang Signed-off-by: Stefano Garzarella Link: https://lore.kernel.org/r/20201215144256.155342-7-sgarzare@redhat.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Stefano Garzarella Signed-off-by: Greg Kroah-Hartman commit c721898723bc1478c7293fd5b8abcca670cbc536 Author: Max Gurtovoy Date: Tue Dec 15 15:42:41 2020 +0100 vdpa_sim: remove hard-coded virtq count commit 423248d60d2b655321fc49eca1545f95a1bc9d6c upstream. Add a new attribute that will define the number of virt queues to be created for the vdpasim device. Signed-off-by: Max Gurtovoy [sgarzare: replace kmalloc_array() with kcalloc()] Acked-by: Jason Wang Signed-off-by: Stefano Garzarella Link: https://lore.kernel.org/r/20201215144256.155342-4-sgarzare@redhat.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Stefano Garzarella Signed-off-by: Greg Kroah-Hartman