kernel/linux.git, branch v5.11.1

Linux 5.11.1

2021-02-23T12:55:57+00:00

Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Tested-by: Jason Self Link: https://lore.kernel.org/r/20210222121013.586597942@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

media: pwc: Use correct device for DMA

2021-02-23T12:55:57+00:00

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

Bluetooth: btusb: Always fallback to alt 1 for WBS

2021-02-23T12:55:57+00:00

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-23T12:55:57+00:00

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-23T12:55:57+00:00

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-23T12:55:57+00:00

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-23T12:55:56+00:00

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-23T12:55:56+00:00

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

xen/arm: don't ignore return errors from set_phys_to_machine

2021-02-23T12:55:56+00:00

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

Xen/gntdev: correct error checking in gntdev_map_grant_pages()

2021-02-23T12:55:56+00:00

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