user/sven/linux.git, branch v5.10.18

Linux 5.10.18

2021-02-23T14:53:25Z

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

media: pwc: Use correct device for DMA

2021-02-23T14:53:25Z

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

btrfs: fix crash after non-aligned direct IO write with O_DSYNC

2021-02-23T14:53:25Z

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

btrfs: fix backport of 2175bf57dc952 in 5.10.13

2021-02-23T14:53:25Z

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

Bluetooth: btusb: Always fallback to alt 1 for WBS

2021-02-23T14:53:25Z

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

tty: protect tty_write from odd low-level tty disciplines

2021-02-23T14:53:24Z

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

xen-blkback: fix error handling in xen_blkbk_map()

2021-02-23T14:53:24Z

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

xen-scsiback: don't "handle" error by BUG()

2021-02-23T14:53:24Z

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

xen-netback: don't "handle" error by BUG()

2021-02-23T14:53:24Z

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

xen-blkback: don't "handle" error by BUG()

2021-02-23T14:53:24Z

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