commit 012f78dadb7186c479343b77e97df2925caf681e Author: Greg Kroah-Hartman Date: Sun Mar 7 12:34:17 2021 +0100 Linux 5.10.21 Tested-by: Jon Hunter Tested-by: Jason Self Tested-by: Florian Fainelli Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20210305120903.276489876@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 2064bba25ac55d02dbec85c66fc20cff22e09f2d Author: Pali Rohár Date: Mon Jan 25 16:02:27 2021 +0100 net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips [ Upstream commit 426c6cbc409cbda9ab1a9dbf15d3c2ef947eb8c1 ] The workaround for VSOL V2801F brand based GPON SFP modules added in commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") works only for IDs added explicitly to the list. Since there are rebranded modules where OEM vendors put different strings into the vendor name field, we cannot base workaround on IDs only. Moreover the issue which the above mentioned commit tried to work around is generic not only to VSOL based modules, but rather to all GPON modules based on Realtek RTL8672 and RTL9601C chips. These include at least the following GPON modules: * V-SOL V2801F * C-Data FD511GX-RM0 * OPTON GP801R * BAUDCOM BD-1234-SFM * CPGOS03-0490 v2.0 * Ubiquiti U-Fiber Instant * EXOT EGS1 These Realtek chips have broken EEPROM emulator which for N-byte read operation returns just the first byte of EEPROM data, followed by N-1 zeros. Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM reading operation. Function sfp_i2c_read() now always uses single byte reading when it is required and when function sfp_hwmon_probe() detects single byte access, it disables registration of hwmon device, because in this case we cannot reliably and atomically read 2 bytes as is required by the standard for retrieving values from diagnostic area. (These Realtek chips are broken in a way that violates SFP standards for diagnostic interface. Kernel in this case simply cannot do anything less of skipping registration of the hwmon interface.) This patch fixes reading of EEPROM content from SFP modules based on Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays broken and cannot be fixed. Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Co-developed-by: Russell King Signed-off-by: Russell King Signed-off-by: Pali Rohár Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 113bcb8f65d47c8a143a15035d8865117778e288 Author: Russell King Date: Wed Dec 9 11:22:49 2020 +0000 net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround [ Upstream commit 0d035bed2a4a6c4878518749348be61bf082d12a ] Add a workaround for the detection of VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single byte I2C reads to the EEPROM. Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module, which reports a manufacturer of "OEM". This manufacturer can't be matched as it appears in many different modules, so also match the part number too. Reported-by: Thomas Schreiber Reported-by: Pali Rohár Tested-by: Pali Rohár Reviewed-by: Andrew Lunn Signed-off-by: Russell King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d0fcadd6b9a3549bb4e48b17b1ff458c6e8ef658 Author: Takashi Iwai Date: Wed Mar 3 15:23:46 2021 +0100 ALSA: hda/realtek: Apply dual codec quirks for MSI Godlike X570 board commit 26af17722a07597d3e556eda92c6fce8d528bc9f upstream. There is another MSI board (1462:cc34) that has dual Realtek codecs, and we need to apply the existing quirk for fixing the conflicts of Master control. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211743 Cc: Link: https://lore.kernel.org/r/20210303142346.28182-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6bba54d9bacaa065cdbfa31f4402de4c1b38893d Author: Werner Sembach Date: Tue Mar 2 19:04:14 2021 +0100 ALSA: hda/realtek: Add quirk for Intel NUC 10 commit 73e7161eab5dee98114987239ec9c87fe8034ddb upstream. This adds a new SND_PCI_QUIRK(...) and applies it to the Intel NUC 10 devices. This fixes the issue of the devices not having audio input and output on the headset jack because the kernel does not recognize when something is plugged in. The new quirk was inspired by the quirk for the Intel NUC 8 devices, but it turned out that the NUC 10 uses another pin. This information was acquired by black box testing likely pins. Co-developed-by: Eckhart Mohr Signed-off-by: Eckhart Mohr Signed-off-by: Werner Sembach Cc: Link: https://lore.kernel.org/r/20210302180414.23194-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cfb46824165825ca2a0a9df985fc4015a0e7a8cf Author: Eckhart Mohr Date: Tue Mar 2 17:25:22 2021 +0100 ALSA: hda/realtek: Add quirk for Clevo NH55RZQ commit 48698c973e6b4dde94d87cd1ded56d9436e9c97d upstream. This applies a SND_PCI_QUIRK(...) to the Clevo NH55RZQ barebone. This fixes the issue of the device not recognizing a pluged in microphone. The device has both, a microphone only jack, and a speaker + microphone combo jack. The combo jack already works. The microphone-only jack does not recognize when a device is pluged in without this patch. Signed-off-by: Eckhart Mohr Co-developed-by: Werner Sembach Signed-off-by: Werner Sembach Cc: Link: https://lore.kernel.org/r/0eee6545-5169-ef08-6cfa-5def8cd48c86@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5400770e31e8b80efc25b4c1d619361255174d11 Author: Sakari Ailus Date: Sat Dec 19 23:29:58 2020 +0100 media: v4l: ioctl: Fix memory leak in video_usercopy commit fb18802a338b36f675a388fc03d2aa504a0d0899 upstream. When an IOCTL with argument size larger than 128 that also used array arguments were handled, two memory allocations were made but alas, only the latter one of them was released. This happened because there was only a single local variable to hold such a temporary allocation. Fix this by adding separate variables to hold the pointers to the temporary allocations. Reported-by: Arnd Bergmann Reported-by: syzbot+1115e79c8df6472c612b@syzkaller.appspotmail.com Fixes: d14e6d76ebf7 ("[media] v4l: Add multi-planar ioctl handling code") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Acked-by: Arnd Bergmann Acked-by: Hans Verkuil Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c7ff2d25bce3ce820ee537d07f9c73ca1ac00704 Author: Linus Torvalds Date: Wed Jan 20 15:43:38 2021 -0800 tty: teach the n_tty ICANON case about the new "cookie continuations" too commit d7fe75cbc23c7d225eee2ef04def239b6603dce7 upstream. The ICANON case is a bit messy, since it has to look for the line ending, and has special code to then suppress line ending characters if they match the __DISABLED_CHAR. So it actually looks up the line ending even past the point where it knows it won't copy it to the result buffer. That said, apart from all those odd legacy N_TTY ICANON cases, the actual "should we continue copying" logic isn't really all that complicated or different from the non-canon case. In fact, the lack of "wait for at least N characters" arguably makes the repeat case slightly simpler. It really just boils down to "there's more of the line to be copied". So add the necessarily trivial logic, and now the N_TTY case will give long result lines even when in canon mode. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0c78bf9c55f1b7e5301cc79a6cc0514bc0d60c99 Author: Linus Torvalds Date: Tue Jan 19 18:14:20 2021 -0800 tty: teach n_tty line discipline about the new "cookie continuations" commit 15ea8ae8e03fdb845ed3ff5d9f11dd5f4f60252c upstream. With the conversion to do the tty ldisc read operations in small chunks, the n_tty line discipline became noticeably slower for throughput oriented loads, because rather than read things in up to 2kB chunks, it would return at most 64 bytes per read() system call. The cost is mainly all in the "do system calls over and over", not really in the new "copy to an extra kernel buffer". This can be fixed by teaching the n_tty line discipline about the "cookie continuation" model, which the chunking code supports because things like hdlc need to be able to handle packets up to 64kB in size. Doing that doesn't just get us back to the old performace, but to much better performance: my stupid "copy 10MB of data over a pty" test program is now almost twice as fast as it used to be (going down from 0.1s to 0.054s). This is entirely because it now creates maximal chunks (which happens to be "one byte less than one page" due to how we do the circular tty buffers). NOTE! This case only handles the simpler non-icanon case, which is the one where people may care about throughput. I'm going to do the icanon case later too, because while performance isn't a major issue for that, there may be programs that think they'll always get a full line and don't like the 64-byte chunking for that reason. Such programs are arguably buggy (signals etc can cause random partial results from tty reads anyway), and good programs will handle such partial reads, but expecting everybody to write "good programs" has never been a winning policy for the kernel.. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e761cd8a7853a69fcb01aea9e0cce1982ca2c264 Author: Linus Torvalds Date: Tue Jan 19 13:46:28 2021 -0800 tty: clean up legacy leftovers from n_tty line discipline commit 64a69892afadd6fffaeadc65427bb7601161139d upstream. Back when the line disciplines did their own direct user accesses, they had to deal with the data copy possibly failing in the middle. Now that the user copy is done by the tty_io.c code, that failure case no longer exists. Remove the left-over error handling code that cannot trigger. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 98480f5c79819768390d4ecfb05b81a6c1e972ee Author: Linus Torvalds Date: Thu Jan 21 10:08:15 2021 -0800 tty: fix up hung_up_tty_read() conversion commit ddc5fda7456178e2cbc87675b370920d98360daf upstream. In commit "tty: implement read_iter", I left the read_iter conversion of the hung up tty case alone, because I incorrectly thought it didn't matter. Jiri showed me the errors of my ways, and pointed out the problems with that incomplete conversion. Fix it all up. Reported-by: Jiri Slaby Signed-off-by: Linus Torvalds Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/CAHk-=wh+-rGsa=xruEWdg_fJViFG8rN9bpLrfLz=_yBYh2tBhA@mail.gmail.com Signed-off-by: Greg Kroah-Hartman commit ef67e445e962f7d5b9a851780ab2df388a5abc01 Author: Linus Torvalds Date: Thu Jan 21 10:17:25 2021 -0800 tty: fix up iterate_tty_read() EOVERFLOW handling commit e71a8d5cf4b4f274740e31b601216071e2a11afa upstream. When I converted the tty_ldisc_ops 'read()' function to take a kernel pointer, I was a bit too aggressive about the ldisc returning EOVERFLOW. Yes, we want to have EOVERFLOW override any partially read data (because the whole point is that the buffer was too small for the whole packet, and we don't want to see partial packets), but it shouldn't override a previous EFAULT. And in fact, it really is just EOVERFLOW that is special and should throw away any partially read data, not "any error". Admittedly EOVERFLOW is currently the only one that can happen for a continuation read - and if the first read iteration returns an error we won't have this issue. So this is more of a technicality, but let's just make the intent very explicit, and re-organize the error handling a bit so that this is all clearer. Reported-by: Jiri Slaby Signed-off-by: Linus Torvalds Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/CAHk-=wh+-rGsa=xruEWdg_fJViFG8rN9bpLrfLz=_yBYh2tBhA@mail.gmail.com Signed-off-by: Greg Kroah-Hartman commit 686fa5a0c647721f24721a53e9d78972eb673e02 Author: Ananth N Mavinakayanahalli Date: Mon Jan 25 18:36:43 2021 +0530 powerpc/sstep: Fix incorrect return from analyze_instr() commit 718aae916fa6619c57c348beaedd675835cf1aa1 upstream. We currently just percolate the return value from analyze_instr() to the caller of emulate_step(), especially if it is a -1. For one particular case (opcode = 4) for instructions that aren't currently emulated, we are returning 'should not be single-stepped' while we should have returned 0 which says 'did not emulate, may have to single-step'. Fixes: 930d6288a26787 ("powerpc: sstep: Add support for maddhd, maddhdu, maddld instructions") Signed-off-by: Ananth N Mavinakayanahalli Suggested-by: Michael Ellerman Tested-by: Naveen N. Rao Reviewed-by: Sandipan Das Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/161157999039.64773.14950289716779364766.stgit@thinktux.local Signed-off-by: Naveen N. Rao Signed-off-by: Greg Kroah-Hartman commit 20d323c8cf5730eb1693ef3fcf0919b35a20e6ad Author: Ananth N Mavinakayanahalli Date: Mon Jan 25 18:36:22 2021 +0530 powerpc/sstep: Check instruction validity against ISA version before emulation commit 8813ff49607eab3caaf40fe8929b0ce7dc68e85f upstream. We currently unconditionally try to emulate newer instructions on older Power versions that could cause issues. Gate it. Fixes: 350779a29f11 ("powerpc: Handle most loads and stores in instruction emulation code") Signed-off-by: Ananth N Mavinakayanahalli Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/161157995977.64773.13794501093457185080.stgit@thinktux.local [Dropped a few missing hunks for the backport to v5.10] Signed-off-by: Naveen N. Rao Signed-off-by: Greg Kroah-Hartman commit 04b049ac9cb4eb425998f690fbd416757a7c9b15 Author: Jens Axboe Date: Tue Mar 2 14:53:21 2021 -0700 swap: fix swapfile read/write offset commit caf6912f3f4af7232340d500a4a2008f81b93f14 upstream. We're not factoring in the start of the file for where to write and read the swapfile, which leads to very unfortunate side effects of writing where we should not be... Fixes: dd6bd0d9c7db ("swap: use bdev_read_page() / bdev_write_page()") Signed-off-by: Jens Axboe Cc: Anthony Iliopoulos Signed-off-by: Greg Kroah-Hartman commit ba1230b49acbf01a47baa804eb8df7c547cbdcf8 Author: Souptick Joarder Date: Sat Nov 28 03:20:55 2020 +0530 remoteproc/mediatek: Fix kernel test robot warning commit cca21000261b2364991ecdb0d9e66b26ad9c4b4e upstream. Kernel test robot throws below warning -> >> drivers/remoteproc/mtk_scp.c:755:37: warning: unused variable >> 'mt8183_of_data' [-Wunused-const-variable] static const struct mtk_scp_of_data mt8183_of_data = { ^ >> drivers/remoteproc/mtk_scp.c:765:37: warning: unused variable >> 'mt8192_of_data' [-Wunused-const-variable] static const struct mtk_scp_of_data mt8192_of_data = { ^ As suggested by Bjorn, there's no harm in just dropping the of_match_ptr() wrapping of mtk_scp_of_match in the definition of mtk_scp_driver and we avoid this whole problem. Reported-by: kernel test robot Suggested-by: Bjorn Andersson Signed-off-by: Souptick Joarder Link: https://lore.kernel.org/r/1606513855-21130-1-git-send-email-jrdr.linux@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 02f768edb9d302c9e6af952c7e40c57b76ed0fb0 Author: Rokudo Yan Date: Thu Feb 25 17:18:31 2021 -0800 zsmalloc: account the number of compacted pages correctly commit 2395928158059b8f9858365fce7713ce7fef62e4 upstream. There exists multiple path may do zram compaction concurrently. 1. auto-compaction triggered during memory reclaim 2. userspace utils write zram/compaction node So, multiple threads may call zs_shrinker_scan/zs_compact concurrently. But pages_compacted is a per zsmalloc pool variable and modification of the variable is not serialized(through under class->lock). There are two issues here: 1. the pages_compacted may not equal to total number of pages freed(due to concurrently add). 2. zs_shrinker_scan may not return the correct number of pages freed(issued by current shrinker). The fix is simple: 1. account the number of pages freed in zs_compact locally. 2. use actomic variable pages_compacted to accumulate total number. Link: https://lkml.kernel.org/r/20210202122235.26885-1-wu-yan@tcl.com Fixes: 860c707dca155a56 ("zsmalloc: account the number of compacted pages") Signed-off-by: Rokudo Yan Cc: Minchan Kim Cc: Sergey Senozhatsky Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9c62adb6e2fda38dc6045a853a6e50b2bbc75d2a Author: Juergen Gross Date: Wed Feb 24 16:03:08 2021 +0100 xen: fix p2m size in dom0 for disabled memory hotplug case commit 882213990d32fd224340a4533f6318dd152be4b2 upstream. Since commit 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory") foreign mappings are using guest physical addresses allocated via ZONE_DEVICE functionality. This will result in problems for the case of no balloon memory hotplug being configured, as the p2m list will only cover the initial memory size of the domain. Any ZONE_DEVICE allocated address will be outside the p2m range and thus a mapping can't be established with that memory address. Fix that by extending the p2m size for that case. At the same time add a check for a to be created mapping to be within the p2m limits in order to detect errors early. While changing a comment, remove some 32-bit leftovers. This is XSA-369. Fixes: 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory") Cc: # 5.9 Reported-by: Marek Marczykowski-Górecki Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit fa00c0c826ddea48e0dc9c7944506dd67a7be6d2 Author: Jan Beulich Date: Thu Feb 25 16:35:15 2021 +0100 xen-netback: respect gnttab_map_refs()'s return value commit 2991397d23ec597405b116d96de3813420bdcbc3 upstream. Commit 3194a1746e8a ("xen-netback: don't "handle" error by BUG()") dropped respective a BUG_ON() without noticing that with this the variable's value wouldn't be consumed anymore. With gnttab_set_map_op() setting all status fields to a non-zero value, in case of an error no slot should have a status of GNTST_okay (zero). This is part of XSA-367. Cc: Reported-by: kernel test robot Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/d933f495-619a-0086-5fb4-1ec3cf81a8fc@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 545c837d6789afcb23da5494a22e459952fb823f Author: Jan Beulich Date: Thu Feb 25 16:34:43 2021 +0100 Xen/gnttab: handle p2m update errors on a per-slot basis commit 8310b77b48c5558c140e7a57a702e7819e62f04e upstream. Bailing immediately from set_foreign_p2m_mapping() upon a p2m updating error leaves the full batch in an ambiguous state as far as the caller is concerned. Instead flags respective slots as bad, unmapping what was mapped there right away. HYPERVISOR_grant_table_op()'s return value and the individual unmap slots' status fields get used only for a one-time - there's not much we can do in case of a failure. Note that there's no GNTST_enomem or alike, so GNTST_general_error gets used. The map ops' handle fields get overwritten just to be on the safe side. This is part of XSA-367. Cc: Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/96cccf5d-e756-5f53-b91a-ea269bfb9be0@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit f40bbcb68131f1c17ed22a1e8a471776b4e57bd3 Author: Chris Leech Date: Tue Feb 23 21:39:01 2021 -0800 scsi: iscsi: Verify lengths on passthrough PDUs commit f9dbdf97a5bd92b1a49cee3d591b55b11fd7a6d5 upstream. Open-iSCSI sends passthrough PDUs over netlink, but the kernel should be verifying that the provided PDU header and data lengths fall within the netlink message to prevent accessing beyond that in memory. Cc: stable@vger.kernel.org Reported-by: Adam Nichols Reviewed-by: Lee Duncan Reviewed-by: Mike Christie Signed-off-by: Chris Leech Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 76d92bf293c36a52ea5552919ac645ef2edee55d Author: Chris Leech Date: Tue Feb 23 18:00:17 2021 -0800 scsi: iscsi: Ensure sysfs attributes are limited to PAGE_SIZE commit ec98ea7070e94cc25a422ec97d1421e28d97b7ee upstream. As the iSCSI parameters are exported back through sysfs, it should be enforcing that they never are more than PAGE_SIZE (which should be more than enough) before accepting updates through netlink. Change all iSCSI sysfs attributes to use sysfs_emit(). Cc: stable@vger.kernel.org Reported-by: Adam Nichols Reviewed-by: Lee Duncan Reviewed-by: Greg Kroah-Hartman Reviewed-by: Mike Christie Signed-off-by: Chris Leech Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit c71edc5d2480774ec2fec62bb84064aed6d582bd Author: Lee Duncan Date: Tue Feb 23 13:06:24 2021 -0800 scsi: iscsi: Restrict sessions and handles to admin capabilities commit 688e8128b7a92df982709a4137ea4588d16f24aa upstream. Protect the iSCSI transport handle, available in sysfs, by requiring CAP_SYS_ADMIN to read it. Also protect the netlink socket by restricting reception of messages to ones sent with CAP_SYS_ADMIN. This disables normal users from being able to end arbitrary iSCSI sessions. Cc: stable@vger.kernel.org Reported-by: Adam Nichols Reviewed-by: Chris Leech Reviewed-by: Mike Christie Signed-off-by: Lee Duncan Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d8a380105699b6189b4419af2b9be99ebf6aaf42 Author: Hans de Goede Date: Tue Feb 16 22:35:55 2021 +0100 ASoC: Intel: bytcr_rt5640: Add quirk for the Acer One S1002 tablet [ Upstream commit c58947af08aedbdee0fce5ea6e6bf3e488ae0e2c ] The Acer One S1002 tablet is using an analog mic on IN1 and has its jack-detect connected to JD2_IN4N, instead of using the default IN3 for its internal mic and JD1_IN4P for jack-detect. Note it is also using AIF2 instead of AIF1 which is somewhat unusual, this is correctly advertised in the ACPI CHAN package, so the speakers do work without the quirk. Add a quirk for the mic and jack-detect settings. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210216213555.36555-5-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 15c84277be64ac1e7789887e696c748235201eba Author: Hans de Goede Date: Tue Feb 16 22:35:54 2021 +0100 ASoC: Intel: bytcr_rt5651: Add quirk for the Jumper EZpad 7 tablet [ Upstream commit df8359c512fa770ffa6b0b0309807d9b9825a47f ] Add a DMI quirk for the Jumper EZpad 7 tablet, this tablet has a jack-detect switch which reads 1/high when a jack is inserted, rather then using the standard active-low setup which most jack-detect switches use. All other settings are using the defaults. Add a DMI-quirk setting the defaults + the BYT_RT5651_JD_NOT_INV flags for this. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210216213555.36555-4-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 078526cbf027240c05d13d6b2ada1e914139487e Author: Hans de Goede Date: Tue Feb 16 22:35:53 2021 +0100 ASoC: Intel: bytcr_rt5640: Add quirk for the Voyo Winpad A15 tablet [ Upstream commit e1317cc9ca4ac20262895fddb065ffda4fc29cfb ] The Voyo Winpad A15 tablet uses a Bay Trail (non CR) SoC, so it is using SSP2 (AIF1) and it mostly works with the defaults. But instead of using DMIC1 it is using an analog mic on IN1, add a quirk for this. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210216213555.36555-3-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 530d0426a9bc03d3c64b82581cff8f1806a0a165 Author: Hans de Goede Date: Tue Feb 16 22:35:52 2021 +0100 ASoC: Intel: bytcr_rt5640: Add quirk for the Estar Beauty HD MID 7316R tablet [ Upstream commit bdea43fc0436c9e98fdfe151c2ed8a3fc7277404 ] The Estar Beauty HD MID 7316R tablet almost fully works with out default settings. The only problem is that it has only 1 speaker so any sounds only playing on the right channel get lost. Add a quirk for this model using the default settings + MONO_SPEAKER. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210216213555.36555-2-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9a68fa0ebb288370be3f74819e1d8c8f401c4e71 Author: Juri Lelli Date: Mon Feb 8 08:35:53 2021 +0100 sched/features: Fix hrtick reprogramming [ Upstream commit 156ec6f42b8d300dbbf382738ff35c8bad8f4c3a ] Hung tasks and RCU stall cases were reported on systems which were not 100% busy. Investigation of such unexpected cases (no sign of potential starvation caused by tasks hogging the system) pointed out that the periodic sched tick timer wasn't serviced anymore after a certain point and that caused all machinery that depends on it (timers, RCU, etc.) to stop working as well. This issues was however only reproducible if HRTICK was enabled. Looking at core dumps it was found that the rbtree of the hrtimer base used also for the hrtick was corrupted (i.e. next as seen from the base root and actual leftmost obtained by traversing the tree are different). Same base is also used for periodic tick hrtimer, which might get "lost" if the rbtree gets corrupted. Much alike what described in commit 1f71addd34f4c ("tick/sched: Do not mess with an enqueued hrtimer") there is a race window between hrtimer_set_expires() in hrtick_start and hrtimer_start_expires() in __hrtick_restart() in which the former might be operating on an already queued hrtick hrtimer, which might lead to corruption of the base. Use hrtick_start() (which removes the timer before enqueuing it back) to ensure hrtick hrtimer reprogramming is entirely guarded by the base lock, so that no race conditions can occur. Signed-off-by: Juri Lelli Signed-off-by: Luis Claudio R. Goncalves Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lkml.kernel.org/r/20210208073554.14629-2-juri.lelli@redhat.com Signed-off-by: Sasha Levin commit 25ceaadccbcef271b848956182dda48a0de14040 Author: John David Anglin Date: Thu Jan 28 18:12:30 2021 -0500 parisc: Bump 64-bit IRQ stack size to 64 KB [ Upstream commit 31680c1d1595a59e17c14ec036b192a95f8e5f4a ] Bump 64-bit IRQ stack size to 64 KB. I had a kernel IRQ stack overflow on the mx3210 debian buildd machine. This patch increases the 64-bit IRQ stack size to 64 KB. The 64-bit stack size needs to be larger than the 32-bit stack size since registers are twice as big. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 5883a3bb309c5d8ebc09747976a6e903147e81db Author: Rander Wang Date: Mon Feb 8 17:33:30 2021 -0600 ASoC: Intel: sof_sdw: detect DMIC number based on mach params [ Upstream commit f88dcb9b98d3f86ead04d2453475267910448bb8 ] Current driver create DMIC dai based on quirk for each platforms, so we need to add quirk for new platforms. Now driver reports DMIC number to machine driver and machine driver can create DMIC dai based on this information. The old check is reserved for some platforms may be failed to set the DMIC number in BIOS. Reviewed-by: Bard Liao Signed-off-by: Rander Wang Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210208233336.59449-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 18de10ef48059c1f9103446ee56e4f8ad827c915 Author: Pierre-Louis Bossart Date: Mon Feb 8 17:33:27 2021 -0600 ASoC: Intel: sof-sdw: indent and add quirks consistently [ Upstream commit 8caf37e2be761688c396c609880936a807af490f ] Use the same style for all quirks to avoid misses and errors Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Kai Vehmanen Link: https://lore.kernel.org/r/20210208233336.59449-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7e7596ea1a4681f39299b7b8d17a568d4fe05491 Author: Jim Mattson Date: Fri Feb 5 11:13:24 2021 -0800 perf/x86/kvm: Add Cascade Lake Xeon steppings to isolation_ucodes[] [ Upstream commit b3c3361fe325074d4144c29d46daae4fc5a268d5 ] Cascade Lake Xeon parts have the same model number as Skylake Xeon parts, so they are tagged with the intel_pebs_isolation quirk. However, as with Skylake Xeon H0 stepping parts, the PEBS isolation issue is fixed in all microcode versions. Add the Cascade Lake Xeon steppings (5, 6, and 7) to the isolation_ucodes[] table so that these parts benefit from Andi's optimization in commit 9b545c04abd4f ("perf/x86/kvm: Avoid unnecessary work in guest filtering"). Signed-off-by: Jim Mattson Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Andi Kleen Link: https://lkml.kernel.org/r/20210205191324.2889006-1-jmattson@google.com Signed-off-by: Sasha Levin commit 5aa2717b6b8db29d12964b14cbba36787cb8dc21 Author: Josef Bacik Date: Tue Dec 1 09:53:23 2020 -0500 btrfs: fix error handling in commit_fs_roots [ Upstream commit 4f4317c13a40194940acf4a71670179c4faca2b5 ] While doing error injection I would sometimes get a corrupt file system. This is because I was injecting errors at btrfs_search_slot, but would only do it one time per stack. This uncovered a problem in commit_fs_roots, where if we get an error we would just break. However we're in a nested loop, the first loop being a loop to find all the dirty fs roots, and then subsequent root updates would succeed clearing the error value. This isn't likely to happen in real scenarios, however we could potentially get a random ENOMEM once and then not again, and we'd end up with a corrupted file system. Fix this by moving the error checking around a bit to the main loop, as this is the only place where something will fail, and return the error as soon as it occurs. With this patch my reproducer no longer corrupts the file system. Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e8ad7fac69389ec630306a5b523ce8a528b3cba4 Author: Hans de Goede Date: Wed Jan 20 22:49:56 2021 +0100 ASoC: Intel: Add DMI quirk table to soc_intel_is_byt_cr() [ Upstream commit 8ade6d8b02b1ead741bd4f6c42921035caab6560 ] Some Bay Trail systems: 1. Use a non CR version of the Bay Trail SoC 2. Contain at least 6 interrupt resources so that the platform_get_resource(pdev, IORESOURCE_IRQ, 5) check to workaround non CR systems which list their IPC IRQ at index 0 despite being non CR does not work 3. Despite 1. and 2. still have their IPC IRQ at index 0 rather then 5 Add a DMI quirk table to check for the few known models with this issue, so that the right IPC IRQ index is used on these systems. Reviewed-by: Andy Shevchenko Acked-by: Pierre-Louis Bossart Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210120214957.140232-5-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1fdde02e5f34925944fcd00b7a88ce7f7ff4d3a1 Author: Chao Leng Date: Thu Jan 21 11:32:38 2021 +0800 nvme-tcp: add clean action for failed reconnection [ Upstream commit 70a99574a79f1cd4dc7ad56ea37be40844bfb97b ] If reconnect failed after start io queues, the queues will be unquiesced and new requests continue to be delivered. Reconnection error handling process directly free queues without cancel suspend requests. The suppend request will time out, and then crash due to use the queue after free. Add sync queues and cancel suppend requests for reconnection error handling. Signed-off-by: Chao Leng Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 7da81eaf8710130a9e63d7429627183be5a93787 Author: Chao Leng Date: Thu Jan 21 11:32:37 2021 +0800 nvme-rdma: add clean action for failed reconnection [ Upstream commit 958dc1d32c80566f58d18f05ef1f05bd32d172c1 ] A crash happens when inject failed reconnection. If reconnect failed after start io queues, the queues will be unquiesced and new requests continue to be delivered. Reconnection error handling process directly free queues without cancel suspend requests. The suppend request will time out, and then crash due to use the queue after free. Add sync queues and cancel suppend requests for reconnection error handling. Signed-off-by: Chao Leng Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 74c4f7aed603033c507d5ddc3f9918e34cbb8948 Author: Chao Leng Date: Thu Jan 21 11:32:36 2021 +0800 nvme-core: add cancel tagset helpers [ Upstream commit 2547906982e2e6a0d42f8957f55af5bb51a7e55f ] Add nvme_cancel_tagset and nvme_cancel_admin_tagset for tear down and reconnection error handling. Signed-off-by: Chao Leng Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 0d2d6857dbb9d964160fd888db68a6d0d2d93ec7 Author: Chao Yu Date: Tue Jan 12 09:55:09 2021 +0800 f2fs: fix to set/clear I_LINKABLE under i_lock [ Upstream commit 46085f37fc9e12d5c3539fb768b5ad7951e72acf ] fsstress + fault injection test case reports a warning message as below: WARNING: CPU: 13 PID: 6226 at fs/inode.c:361 inc_nlink+0x32/0x40 Call Trace: f2fs_init_inode_metadata+0x25c/0x4a0 [f2fs] f2fs_add_inline_entry+0x153/0x3b0 [f2fs] f2fs_add_dentry+0x75/0x80 [f2fs] f2fs_do_add_link+0x108/0x160 [f2fs] f2fs_rename2+0x6ab/0x14f0 [f2fs] vfs_rename+0x70c/0x940 do_renameat2+0x4d8/0x4f0 __x64_sys_renameat2+0x4b/0x60 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Following race case can cause this: Thread A Kworker - f2fs_rename - f2fs_create_whiteout - __f2fs_tmpfile - f2fs_i_links_write - f2fs_mark_inode_dirty_sync - mark_inode_dirty_sync - writeback_single_inode - __writeback_single_inode - spin_lock(&inode->i_lock) - inode->i_state |= I_LINKABLE - inode->i_state &= ~dirty - spin_unlock(&inode->i_lock) - f2fs_add_link - f2fs_do_add_link - f2fs_add_dentry - f2fs_add_inline_entry - f2fs_init_inode_metadata - f2fs_i_links_write - inc_nlink - WARN_ON(!(inode->i_state & I_LINKABLE)) Fix to add i_lock to avoid i_state update race condition. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit c86df2b84bea483818d960eef58a69eafca4e588 Author: Jaegeuk Kim Date: Wed Dec 23 11:44:25 2020 -0800 f2fs: handle unallocated section and zone on pinned/atgc [ Upstream commit 632faca72938f9f63049e48a8c438913828ac7a9 ] If we have large section/zone, unallocated segment makes them corrupted. E.g., - Pinned file: -1 119304647 119304647 - ATGC data: -1 119304647 119304647 Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit cc52ed14f5ca849ef81e6a6bc4beea6dc43514d0 Author: Ricardo Ribalda Date: Wed Dec 23 14:35:19 2020 +0100 media: uvcvideo: Allow entities with no pads [ Upstream commit 7532dad6634031d083df7af606fac655b8d08b5c ] Avoid an underflow while calculating the number of inputs for entities with zero pads. Signed-off-by: Ricardo Ribalda Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 4b73f01d5ebde3409df1206727fb2fd20fefe7cf Author: Jingwen Chen Date: Tue Jan 19 16:54:50 2021 +0800 drm/amd/amdgpu: add error handling to amdgpu_virt_read_pf2vf_data [ Upstream commit 64dcf2f01d59cf9fad19b1a387bd39736a8f4d69 ] [Why] when vram lost happened in guest, try to write vram can lead to kernel stuck. [How] When the readback data is invalid, don't do write work, directly reschedule a new work. Signed-off-by: Jingwen Chen Reviewed-by: Monk Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a986f9345467b8d39f0aff39d80207e4e91aae0c Author: Nicholas Kazlauskas Date: Fri Dec 18 12:14:00 2020 -0500 drm/amd/display: Guard against NULL pointer deref when get_i2c_info fails [ Upstream commit 44a09e3d95bd2b7b0c224100f78f335859c4e193 ] [Why] If the BIOS table is invalid or corrupt then get_i2c_info can fail and we dereference a NULL pointer. [How] Check that ddc_pin is not NULL before using it and log an error if it is because this is unexpected. Tested-by: Daniel Wheeler Signed-off-by: Nicholas Kazlauskas Reviewed-by: Eric Yang Acked-by: Anson Jacob Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3418abd7c66f2221395067aa50677bab9be391a3 Author: Hans de Goede Date: Sat Jan 9 22:01:17 2021 +0100 ASoC: Intel: bytcr_rt5640: Add new BYT_RT5640_NO_SPEAKERS quirk-flag [ Upstream commit 1851ccf9e155b2a6f6cca1a7bd49325f5efbd5d2 ] Some devices, like mini PCs/media/top-set boxes do not have any speakers at all, an example of the is the Mele PCG03 Mini PC. Add a new BYT_RT5640_NO_SPEAKERS quirk-flag which when sets does not add speaker routes and modifies the components and the (optional) long_name strings to reflect that there are no speakers. Cc: Rasmus Porsager Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210109210119.159032-2-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0b6383a9a80acb08768da7d15370f4ad6456baba Author: Nirmoy Das Date: Thu Jan 7 12:26:55 2021 +0100 PCI: Add a REBAR size quirk for Sapphire RX 5600 XT Pulse [ Upstream commit 907830b0fc9e374d00f3c83de5e426157b482c01 ] RX 5600 XT Pulse advertises support for BAR 0 being 256MB, 512MB, or 1GB, but it also supports 2GB, 4GB, and 8GB. Add a rebar size quirk so that the BAR 0 is big enough to cover complete VARM. Signed-off-by: Christian König Signed-off-by: Nirmoy Das Acked-by: Bjorn Helgaas Link: https://patchwork.kernel.org/project/dri-devel/patch/20210107175017.15893-5-nirmoy.das@amd.com Signed-off-by: Sasha Levin commit b9b1648ac9473337bd41ccad86a2bab5ffc73f1c Author: Defang Bo Date: Wed Jan 6 00:06:39 2021 +0800 drm/amdgpu: Add check to prevent IH overflow [ Upstream commit e4180c4253f3f2da09047f5139959227f5cf1173 ] Similar to commit ("drm/amdgpu: fix IH overflow on Vega10 v2"). When an ring buffer overflow happens the appropriate bit is set in the WPTR register which is also written back to memory. But clearing the bit in the WPTR doesn't trigger another memory writeback. So what can happen is that we end up processing the buffer overflow over and over again because the bit is never cleared. Resulting in a random system lockup because of an infinite loop in an interrupt handler. Reviewed-by: Christian König Signed-off-by: Defang Bo Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 01fd84a436b501243a8031d19041efcd7fe80ba9 Author: Jens Axboe Date: Thu Dec 17 09:19:08 2020 -0700 fs: make unlazy_walk() error handling consistent [ Upstream commit e36cffed20a324e116f329a94061ae30dd26fb51 ] Most callers check for non-zero return, and assume it's -ECHILD (which it always will be). One caller uses the actual error return. Clean this up and make it fully consistent, by having unlazy_walk() return a bool instead. Rename it to try_to_unlazy() and return true on success, and failure on error. That's easier to read. No functional changes in this patch. Cc: Al Viro Signed-off-by: Jens Axboe Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit ed51ffe96abcdd5c39fb55ac0e1b2242b097d7e4 Author: Ard Biesheuvel Date: Tue Dec 8 15:34:41 2020 +0100 crypto: tcrypt - avoid signed overflow in byte count [ Upstream commit 303fd3e1c771077e32e96e5788817f025f0067e2 ] The signed long type used for printing the number of bytes processed in tcrypt benchmarks limits the range to -/+ 2 GiB, which is not sufficient to cover the performance of common accelerated ciphers such as AES-NI when benchmarked with sec=1. So switch to u64 instead. While at it, fix up a missing printk->pr_cont conversion in the AEAD benchmark. Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bb5e204b6b9818c2e2ff8f28a941cf537d5bdf4d Author: Tian Tao Date: Mon Dec 14 18:32:53 2020 +0800 drm/hisilicon: Fix use-after-free [ Upstream commit c855af2f9c5c60760fd1bed7889a81bc37d2591d ] Fix the problem of dev being released twice. ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 75 PID: 15700 at lib/refcount.c:28 refcount_warn_saturate+0xd4/0x150 CPU: 75 PID: 15700 Comm: rmmod Tainted: G E 5.10.0-rc3+ #3 Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDDA, BIOS 0.88 07/24/2019 pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--) pc : refcount_warn_saturate+0xd4/0x150 lr : refcount_warn_saturate+0xd4/0x150 sp : ffff2028150cbc00 x29: ffff2028150cbc00 x28: ffff2028150121c0 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000003 x23: 0000000000000000 x22: ffff2028150cbc90 x21: ffff2020038a30a8 x20: ffff2028150cbc90 x19: ffff0020cd938020 x18: 0000000000000010 x17: 0000000000000000 x16: 0000000000000000 x15: ffffffffffffffff x14: ffff2028950cb88f x13: ffff2028150cb89d x12: 0000000000000000 x11: 0000000005f5e0ff x10: ffff2028150cb800 x9 : 00000000ffffffd0 x8 : 75203b776f6c6672 x7 : ffff800011a6f7c8 x6 : 0000000000000001 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff202ffe2f9dc0 x1 : ffffa02fecf40000 x0 : 0000000000000026 Call trace: refcount_warn_saturate+0xd4/0x150 devm_drm_dev_init_release+0x50/0x70 devm_action_release+0x20/0x30 release_nodes+0x13c/0x218 devres_release_all+0x80/0x170 device_release_driver_internal+0x128/0x1f0 driver_detach+0x6c/0xe0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x60 pci_unregister_driver+0x24/0xd8 hibmc_pci_driver_exit+0x14/0xe858 [hibmc_drm] __arm64_sys_delete_module+0x1fc/0x2d0 el0_svc_common.constprop.3+0xa8/0x188 do_el0_svc+0x80/0xa0 el0_sync_handler+0x8c/0xb0 el0_sync+0x15c/0x180 CPU: 75 PID: 15700 Comm: rmmod Tainted: G E 5.10.0-rc3+ #3 Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDDA, BIOS 0.88 07/24/2019 Call trace: dump_backtrace+0x0/0x208 show_stack+0x2c/0x40 dump_stack+0xd8/0x10c __warn+0xac/0x128 report_bug+0xcc/0x180 bug_handler+0x24/0x78 call_break_hook+0x80/0xa0 brk_handler+0x28/0x68 do_debug_exception+0x9c/0x148 el1_sync_handler+0x7c/0x128 el1_sync+0x80/0x100 refcount_warn_saturate+0xd4/0x150 devm_drm_dev_init_release+0x50/0x70 devm_action_release+0x20/0x30 release_nodes+0x13c/0x218 devres_release_all+0x80/0x170 device_release_driver_internal+0x128/0x1f0 driver_detach+0x6c/0xe0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x60 pci_unregister_driver+0x24/0xd8 hibmc_pci_driver_exit+0x14/0xe858 [hibmc_drm] __arm64_sys_delete_module+0x1fc/0x2d0 el0_svc_common.constprop.3+0xa8/0x188 do_el0_svc+0x80/0xa0 el0_sync_handler+0x8c/0xb0 el0_sync+0x15c/0x180 ---[ end trace 00718630d6e5ff18 ]--- Signed-off-by: Tian Tao Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/1607941973-32287-1-git-send-email-tiantao6@hisilicon.com Signed-off-by: Sasha Levin commit 2eb7eacf4e0031b3e7f00037a73e4d4792eb45e1 Author: Hans de Goede Date: Fri Jan 29 18:14:13 2021 +0100 brcmfmac: Add DMI nvram filename quirk for Voyo winpad A15 tablet [ Upstream commit a338c874d3d9d2463f031e89ae14942929b93db6 ] The Voyo winpad A15 tablet contains quite generic names in the sys_vendor and product_name DMI strings, without this patch brcmfmac will try to load: rcmfmac4330-sdio.To be filled by O.E.M.-To be filled by O.E.M..txt as nvram file which is a bit too generic. Add a DMI quirk so that a unique and clearly identifiable nvram file name is used on the Voyo winpad A15 tablet. While preparing a matching linux-firmware update I noticed that the nvram is identical to the nvram used on the Prowise-PT301 tablet, so the new DMI quirk entry simply points to the already existing Prowise-PT301 nvram file. Signed-off-by: Hans de Goede Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210129171413.139880-2-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 4649950f32e86067ecf5aea7bf9311d79b8a2d6b Author: Hans de Goede Date: Fri Jan 29 18:14:12 2021 +0100 brcmfmac: Add DMI nvram filename quirk for Predia Basic tablet [ Upstream commit af4b3a6f36d6c2fc5fca026bccf45e0fdcabddd9 ] The Predia Basic tablet contains quite generic names in the sys_vendor and product_name DMI strings, without this patch brcmfmac will try to load: brcmfmac43340-sdio.Insyde-CherryTrail.txt as nvram file which is a bit too generic. Add a DMI quirk so that a unique and clearly identifiable nvram file name is used on the Predia Basic tablet. Signed-off-by: Hans de Goede Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210129171413.139880-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit a1eda21a2cb1e52fe63869af35f269f98d7b329b Author: Juerg Haefliger Date: Fri Feb 5 08:25:02 2021 +0100 staging: bcm2835-audio: Replace unsafe strcpy() with strscpy() [ Upstream commit 4964a4300660d27907ceb655f219ac47e5941534 ] Replace strcpy() with strscpy() in bcm2835-audio/bcm2835.c to prevent the following when loading snd-bcm2835: [ 58.480634] ------------[ cut here ]------------ [ 58.485321] kernel BUG at lib/string.c:1149! [ 58.489650] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 58.495214] Modules linked in: snd_bcm2835(COE+) snd_pcm snd_timer snd dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua btsdio bluetooth ecdh_generic ecc bcm2835_v4l2(CE) bcm2835_codec(CE) brcmfmac bcm2835_isp(CE) bcm2835_mmal_vchiq(CE) brcmutil cfg80211 v4l2_mem2mem videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops raspberrypi_hwmon videobuf2_v4l2 videobuf2_common videodev bcm2835_gpiomem mc vc_sm_cma(CE) rpivid_mem uio_pdrv_genirq uio sch_fq_codel drm ip_tables x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq libcrc32c raid1 raid0 multipath linear dwc2 roles spidev udc_core crct10dif_ce xhci_pci xhci_pci_renesas phy_generic aes_neon_bs aes_neon_blk crypto_simd cryptd [ 58.563787] CPU: 3 PID: 1959 Comm: insmod Tainted: G C OE 5.11.0-1001-raspi #1 [ 58.572172] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT) [ 58.578086] pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 58.584178] pc : fortify_panic+0x20/0x24 [ 58.588161] lr : fortify_panic+0x20/0x24 [ 58.592136] sp : ffff800010a83990 [ 58.595491] x29: ffff800010a83990 x28: 0000000000000002 [ 58.600879] x27: ffffb0b07cb72928 x26: 0000000000000000 [ 58.606268] x25: ffff39e884973838 x24: ffffb0b07cb74190 [ 58.611655] x23: ffffb0b07cb72030 x22: 0000000000000000 [ 58.617042] x21: ffff39e884973014 x20: ffff39e88b793010 [ 58.622428] x19: ffffb0b07cb72670 x18: 0000000000000030 [ 58.627814] x17: 0000000000000000 x16: ffffb0b092ce2c1c [ 58.633200] x15: ffff39e88b901500 x14: 0720072007200720 [ 58.638588] x13: 0720072007200720 x12: 0720072007200720 [ 58.643979] x11: ffffb0b0936cbdf0 x10: 00000000fffff000 [ 58.649366] x9 : ffffb0b09220cfa8 x8 : 0000000000000000 [ 58.654752] x7 : ffffb0b093673df0 x6 : ffffb0b09364e000 [ 58.660140] x5 : 0000000000000000 x4 : ffff39e93b7db948 [ 58.665526] x3 : ffff39e93b7ebcf0 x2 : 0000000000000000 [ 58.670913] x1 : 0000000000000000 x0 : 0000000000000022 [ 58.676299] Call trace: [ 58.678775] fortify_panic+0x20/0x24 [ 58.682402] snd_bcm2835_alsa_probe+0x5b8/0x7d8 [snd_bcm2835] [ 58.688247] platform_probe+0x74/0xe4 [ 58.691963] really_probe+0xf0/0x510 [ 58.695585] driver_probe_device+0xe0/0x100 [ 58.699826] device_driver_attach+0xcc/0xd4 [ 58.704068] __driver_attach+0xb0/0x17c [ 58.707956] bus_for_each_dev+0x7c/0xd4 [ 58.711843] driver_attach+0x30/0x40 [ 58.715467] bus_add_driver+0x154/0x250 [ 58.719354] driver_register+0x84/0x140 [ 58.723242] __platform_driver_register+0x34/0x40 [ 58.728013] bcm2835_alsa_driver_init+0x30/0x1000 [snd_bcm2835] [ 58.734024] do_one_initcall+0x54/0x300 [ 58.737914] do_init_module+0x60/0x280 [ 58.741719] load_module+0x680/0x770 [ 58.745344] __do_sys_finit_module+0xbc/0x130 [ 58.749761] __arm64_sys_finit_module+0x2c/0x40 [ 58.754356] el0_svc_common.constprop.0+0x88/0x220 [ 58.759216] do_el0_svc+0x30/0xa0 [ 58.762575] el0_svc+0x28/0x70 [ 58.765669] el0_sync_handler+0x1a4/0x1b0 [ 58.769732] el0_sync+0x178/0x180 [ 58.773095] Code: aa0003e1 91366040 910003fd 97ffee21 (d4210000) [ 58.779275] ---[ end trace 29be5b17497bd898 ]--- [ 58.783955] note: insmod[1959] exited with preempt_count 1 [ 58.791921] ------------[ cut here ]------------ For the sake of it, replace all the other occurences of strcpy() under bcm2835-audio/ as well. Signed-off-by: Juerg Haefliger Link: https://lore.kernel.org/r/20210205072502.10907-1-juergh@canonical.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0cac694c2c05506fd84660be26225f0b2a2276c7 Author: Christian Gromm Date: Tue Feb 2 17:21:05 2021 +0100 staging: most: sound: add sanity check for function argument [ Upstream commit 45b754ae5b82949dca2b6e74fa680313cefdc813 ] This patch checks the function parameter 'bytes' before doing the subtraction to prevent memory corruption. Signed-off-by: Christian Gromm Reported-by: Dan Carpenter Link: https://lore.kernel.org/r/1612282865-21846-1-git-send-email-christian.gromm@microchip.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 15c56b8f2ce1b09b71f8ec4a1a977af3846d00a7 Author: Gopal Tiwari Date: Tue Feb 2 15:12:30 2021 +0530 Bluetooth: Fix null pointer dereference in amp_read_loc_assoc_final_data [ Upstream commit e8bd76ede155fd54d8c41d045dda43cd3174d506 ] kernel panic trace looks like: #5 [ffffb9e08698fc80] do_page_fault at ffffffffb666e0d7 #6 [ffffb9e08698fcb0] page_fault at ffffffffb70010fe [exception RIP: amp_read_loc_assoc_final_data+63] RIP: ffffffffc06ab54f RSP: ffffb9e08698fd68 RFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8c8845a5a000 RCX: 0000000000000004 RDX: 0000000000000000 RSI: ffff8c8b9153d000 RDI: ffff8c8845a5a000 RBP: ffffb9e08698fe40 R8: 00000000000330e0 R9: ffffffffc0675c94 R10: ffffb9e08698fe58 R11: 0000000000000001 R12: ffff8c8b9cbf6200 R13: 0000000000000000 R14: 0000000000000000 R15: ffff8c8b2026da0b ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb9e08698fda8] hci_event_packet at ffffffffc0676904 [bluetooth] #8 [ffffb9e08698fe50] hci_rx_work at ffffffffc06629ac [bluetooth] #9 [ffffb9e08698fe98] process_one_work at ffffffffb66f95e7 hcon->amp_mgr seems NULL triggered kernel panic in following line inside function amp_read_loc_assoc_final_data set_bit(READ_LOC_AMP_ASSOC_FINAL, &mgr->state); Fixed by checking NULL for mgr. Signed-off-by: Gopal Tiwari Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 05a524b97dd1471c98e18ce9301d64b7b18f4208 Author: Hans de Goede Date: Thu Jan 28 17:33:12 2021 +0100 Bluetooth: Add new HCI_QUIRK_NO_SUSPEND_NOTIFIER quirk [ Upstream commit 219991e6be7f4a31d471611e265b72f75b2d0538 ] Some devices, e.g. the RTL8723BS bluetooth part, some USB attached devices, completely drop from the bus on a system-suspend. These devices will have their driver unbound and rebound on resume (when the dropping of the bus gets detected) and will show up as a new HCI after resume. These devices do not benefit from the suspend / resume handling work done by the hci_suspend_notifier. At best this unnecessarily adds some time to the suspend/resume time. But this may also actually cause problems, if the code doing the driver unbinding runs after the pm-notifier then the hci_suspend_notifier code will try to talk to a device which is now in an uninitialized state. This commit adds a new HCI_QUIRK_NO_SUSPEND_NOTIFIER quirk which allows drivers to opt-out of the hci_suspend_notifier when they know beforehand that their device will be fully re-initialized / reprobed on resume. Signed-off-by: Hans de Goede Reviewed-by: Abhishek Pandit-Subedi Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 6c15e41dc4ac38ad0d4a5790ebdf582c98f88d74 Author: Pali Rohár Date: Mon Jan 25 16:02:28 2021 +0100 net: sfp: add mode quirk for GPON module Ubiquiti U-Fiber Instant [ Upstream commit f0b4f847673299577c29b71d3f3acd3c313d81b7 ] The Ubiquiti U-Fiber Instant SFP GPON module has nonsensical information stored in its EEPROM. It claims to support all transceiver types including 10G Ethernet. Clear all claimed modes and set only 1000baseX_Full, which is the only one supported. This module has also phys_id set to SFF, and the SFP subsystem currently does not allow to use SFP modules detected as SFFs. Add exception for this module so it can be detected as supported. This change finally allows to detect and use SFP GPON module Ubiquiti U-Fiber Instant on Linux system. EEPROM content of this SFP module is (where XX is serial number): 00: 02 04 0b ff ff ff ff ff ff ff ff 03 0c 00 14 c8 ???........??.?? 10: 00 00 00 00 55 42 4e 54 20 20 20 20 20 20 20 20 ....UBNT 20: 20 20 20 20 00 18 e8 29 55 46 2d 49 4e 53 54 41 .??)UF-INSTA 30: 4e 54 20 20 20 20 20 20 34 20 20 20 05 1e 00 36 NT 4 ??.6 40: 00 06 00 00 55 42 4e 54 XX XX XX XX XX XX XX XX .?..UBNTXXXXXXXX 50: 20 20 20 20 31 34 30 31 32 33 20 20 60 80 02 41 140123 `??A Signed-off-by: Pali Rohár Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0b5d22c770bf81e5a9cb1d4b4e120a6108b6fcbb Author: Miaoqing Pan Date: Tue Dec 22 14:34:47 2020 +0800 ath10k: fix wmi mgmt tx queue full due to race condition [ Upstream commit b55379e343a3472c35f4a1245906db5158cab453 ] Failed to transmit wmi management frames: [84977.840894] ath10k_snoc a000000.wifi: wmi mgmt tx queue is full [84977.840913] ath10k_snoc a000000.wifi: failed to transmit packet, dropping: -28 [84977.840924] ath10k_snoc a000000.wifi: failed to submit frame: -28 [84977.840932] ath10k_snoc a000000.wifi: failed to transmit frame: -28 This issue is caused by race condition between skb_dequeue and __skb_queue_tail. The queue of ‘wmi_mgmt_tx_queue’ is protected by a different lock: ar->data_lock vs list->lock, the result is no protection. So when ath10k_mgmt_over_wmi_tx_work() and ath10k_mac_tx_wmi_mgmt() running concurrently on different CPUs, there appear to be a rare corner cases when the queue length is 1, CPUx (skb_deuque) CPUy (__skb_queue_tail) next=list prev=list struct sk_buff *skb = skb_peek(list); WRITE_ONCE(newsk->next, next); WRITE_ONCE(list->qlen, list->qlen - 1);WRITE_ONCE(newsk->prev, prev); next = skb->next; WRITE_ONCE(next->prev, newsk); prev = skb->prev; WRITE_ONCE(prev->next, newsk); skb->next = skb->prev = NULL; list->qlen++; WRITE_ONCE(next->prev, prev); WRITE_ONCE(prev->next, next); If the instruction ‘next = skb->next’ is executed before ‘WRITE_ONCE(prev->next, newsk)’, newsk will be lost, as CPUx get the old ‘next’ pointer, but the length is still added by one. The final result is the length of the queue will reach the maximum value but the queue is empty. So remove ar->data_lock, and use 'skb_queue_tail' instead of '__skb_queue_tail' to prevent the potential race condition. Also switch to use skb_queue_len_lockless, in case we queue a few SKBs simultaneously. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1.c2-00033-QCAHLSWMTPLZ-1 Signed-off-by: Miaoqing Pan Reviewed-by: Brian Norris Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1608618887-8857-1-git-send-email-miaoqing@codeaurora.org Signed-off-by: Sasha Levin commit aee0cc0d7a3476dbb8e90591726d8362ff2cc0ba Author: Di Zhu Date: Mon Jan 25 20:42:29 2021 +0800 pktgen: fix misuse of BUG_ON() in pktgen_thread_worker() [ Upstream commit 275b1e88cabb34dbcbe99756b67e9939d34a99b6 ] pktgen create threads for all online cpus and bond these threads to relevant cpu repecivtily. when this thread firstly be woken up, it will compare cpu currently running with the cpu specified at the time of creation and if the two cpus are not equal, BUG_ON() will take effect causing panic on the system. Notice that these threads could be migrated to other cpus before start running because of the cpu hotplug after these threads have created. so the BUG_ON() used here seems unreasonable and we can replace it with WARN_ON() to just printf a warning other than panic the system. Signed-off-by: Di Zhu Link: https://lore.kernel.org/r/20210125124229.19334-1-zhudi21@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit aec5719681405af21102c2407b01f83ed19e9833 Author: Ryder Lee Date: Fri Dec 11 02:51:38 2020 +0800 mt76: mt7615: reset token when mac_reset happens [ Upstream commit a6275e934605646ef81b02d8d1164f21343149c9 ] Reset token in mt7615_mac_reset_work() to avoid possible leakege. Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b9afcdcddff68eee8d04b0cfa30e08e156e6839e Author: Vamshi K Sthambamkadi Date: Thu Jan 14 16:51:47 2021 +0530 Bluetooth: btusb: fix memory leak on suspend and resume [ Upstream commit 5ff20cbe6752a5bc06ff58fee8aa11a0d5075819 ] kmemleak report: unreferenced object 0xffff9b1127f00500 (size 208): comm "kworker/u17:2", pid 500, jiffies 4294937470 (age 580.136s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 60 ed 05 11 9b ff ff 00 00 00 00 00 00 00 00 .`.............. backtrace: [<000000006ab3fd59>] kmem_cache_alloc_node+0x17a/0x480 [<0000000051a5f6f9>] __alloc_skb+0x5b/0x1d0 [<0000000037e2d252>] hci_prepare_cmd+0x32/0xc0 [bluetooth] [<0000000010b586d5>] hci_req_add_ev+0x84/0xe0 [bluetooth] [<00000000d2deb520>] hci_req_clear_event_filter+0x42/0x70 [bluetooth] [<00000000f864bd8c>] hci_req_prepare_suspend+0x84/0x470 [bluetooth] [<000000001deb2cc4>] hci_prepare_suspend+0x31/0x40 [bluetooth] [<000000002677dd79>] process_one_work+0x209/0x3b0 [<00000000aaa62b07>] worker_thread+0x34/0x400 [<00000000826d176c>] kthread+0x126/0x140 [<000000002305e558>] ret_from_fork+0x22/0x30 unreferenced object 0xffff9b1125c6ee00 (size 512): comm "kworker/u17:2", pid 500, jiffies 4294937470 (age 580.136s) hex dump (first 32 bytes): 04 00 00 00 0d 00 00 00 05 0c 01 00 11 9b ff ff ................ 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ backtrace: [<000000009f07c0cc>] slab_post_alloc_hook+0x59/0x270 [<0000000049431dc2>] __kmalloc_node_track_caller+0x15f/0x330 [<00000000027a42f6>] __kmalloc_reserve.isra.70+0x31/0x90 [<00000000e8e3e76a>] __alloc_skb+0x87/0x1d0 [<0000000037e2d252>] hci_prepare_cmd+0x32/0xc0 [bluetooth] [<0000000010b586d5>] hci_req_add_ev+0x84/0xe0 [bluetooth] [<00000000d2deb520>] hci_req_clear_event_filter+0x42/0x70 [bluetooth] [<00000000f864bd8c>] hci_req_prepare_suspend+0x84/0x470 [bluetooth] [<000000001deb2cc4>] hci_prepare_suspend+0x31/0x40 [bluetooth] [<000000002677dd79>] process_one_work+0x209/0x3b0 [<00000000aaa62b07>] worker_thread+0x34/0x400 [<00000000826d176c>] kthread+0x126/0x140 [<000000002305e558>] ret_from_fork+0x22/0x30 unreferenced object 0xffff9b112b395788 (size 8): comm "kworker/u17:2", pid 500, jiffies 4294937470 (age 580.136s) hex dump (first 8 bytes): 20 00 00 00 00 00 04 00 ....... backtrace: [<0000000052dc28d2>] kmem_cache_alloc_trace+0x15e/0x460 [<0000000046147591>] alloc_ctrl_urb+0x52/0xe0 [btusb] [<00000000a2ed3e9e>] btusb_send_frame+0x91/0x100 [btusb] [<000000001e66030e>] hci_send_frame+0x7e/0xf0 [bluetooth] [<00000000bf6b7269>] hci_cmd_work+0xc5/0x130 [bluetooth] [<000000002677dd79>] process_one_work+0x209/0x3b0 [<00000000aaa62b07>] worker_thread+0x34/0x400 [<00000000826d176c>] kthread+0x126/0x140 [<000000002305e558>] ret_from_fork+0x22/0x30 In pm sleep-resume context, while the btusb device rebinds, it enters hci_unregister_dev(), whilst there is a possibility of hdev receiving PM_POST_SUSPEND suspend_notifier event, leading to generation of msg frames. When hci_unregister_dev() completes, i.e. hdev context is destroyed/freed, those intermittently sent msg frames cause memory leak. BUG details: Below is stack trace of thread that enters hci_unregister_dev(), marks the hdev flag HCI_UNREGISTER to 1, and then goes onto to wait on notifier lock - refer unregister_pm_notifier(). hci_unregister_dev+0xa5/0x320 [bluetoot] btusb_disconnect+0x68/0x150 [btusb] usb_unbind_interface+0x77/0x250 ? kernfs_remove_by_name_ns+0x75/0xa0 device_release_driver_internal+0xfe/0x1 device_release_driver+0x12/0x20 bus_remove_device+0xe1/0x150 device_del+0x192/0x3e0 ? usb_remove_ep_devs+0x1f/0x30 usb_disable_device+0x92/0x1b0 usb_disconnect+0xc2/0x270 hub_event+0x9f6/0x15d0 ? rpm_idle+0x23/0x360 ? rpm_idle+0x26b/0x360 process_one_work+0x209/0x3b0 worker_thread+0x34/0x400 ? process_one_work+0x3b0/0x3b0 kthread+0x126/0x140 ? kthread_park+0x90/0x90 ret_from_fork+0x22/0x30 Below is stack trace of thread executing hci_suspend_notifier() which processes the PM_POST_SUSPEND event, while the unbinding thread is waiting on lock. hci_suspend_notifier.cold.39+0x5/0x2b [bluetooth] blocking_notifier_call_chain+0x69/0x90 pm_notifier_call_chain+0x1a/0x20 pm_suspend.cold.9+0x334/0x352 state_store+0x84/0xf0 kobj_attr_store+0x12/0x20 sysfs_kf_write+0x3b/0x40 kernfs_fop_write+0xda/0x1c0 vfs_write+0xbb/0x250 ksys_write+0x61/0xe0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x37/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix hci_suspend_notifer(), not to act on events when flag HCI_UNREGISTER is set. Signed-off-by: Vamshi K Sthambamkadi Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit baae70ce0bb7ac390e1a986d958559a685b432b7 Author: Claire Chang Date: Tue Jan 19 19:47:00 2021 +0800 Bluetooth: hci_h5: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for btrtl [ Upstream commit 7f9f2c3f7d99b8ae773459c74ac5e99a0dd46db9 ] Realtek Bluetooth controllers can do both LE scan and BR/EDR inquiry at once, need to set HCI_QUIRK_SIMULTANEOUS_DISCOVERY quirk. Signed-off-by: Claire Chang Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 2ce5e0a5480c24c0a4416dc20e922043fe5c3e13 Author: Tony Lindgren Date: Fri Jan 15 08:56:13 2021 +0200 wlcore: Fix command execute failure 19 for wl12xx [ Upstream commit cb88d01b67383a095e3f7caeb4cdade5a6cf0417 ] We can currently get a "command execute failure 19" error on beacon loss if the signal is weak: wlcore: Beacon loss detected. roles:0xff wlcore: Connection loss work (role_id: 0). ... wlcore: ERROR command execute failure 19 ... WARNING: CPU: 0 PID: 1552 at drivers/net/wireless/ti/wlcore/main.c:803 ... (wl12xx_queue_recovery_work.part.0 [wlcore]) (wl12xx_cmd_role_start_sta [wlcore]) (wl1271_op_bss_info_changed [wlcore]) (ieee80211_prep_connection [mac80211]) Error 19 is defined as CMD_STATUS_WRONG_NESTING from the wlcore firmware, and seems to mean that the firmware no longer wants to see the quirk handling for WLCORE_QUIRK_START_STA_FAILS done. This quirk got added with commit 18eab430700d ("wlcore: workaround start_sta problem in wl12xx fw"), and it seems that this already got fixed in the firmware long time ago back in 2012 as wl18xx never had this quirk in place to start with. As we no longer even support firmware that early, to me it seems that it's safe to just drop WLCORE_QUIRK_START_STA_FAILS to fix the error. Looks like earlier firmware got disabled back in 2013 with commit 0e284c074ef9 ("wl12xx: increase minimum singlerole firmware version required"). If it turns out we still need WLCORE_QUIRK_START_STA_FAILS with any firmware that the driver works with, we can simply revert this patch and add extra checks for firmware version used. With this fix wlcore reconnects properly after a beacon loss. Cc: Raz Bouganim Signed-off-by: Tony Lindgren Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210115065613.7731-1-tony@atomide.com Signed-off-by: Sasha Levin commit 136f009b2a1b7caf9eda7a82883f57ae36c3201b Author: Jiri Slaby Date: Tue Jan 5 13:02:34 2021 +0100 vt/consolemap: do font sum unsigned [ Upstream commit 9777f8e60e718f7b022a94f2524f967d8def1931 ] The constant 20 makes the font sum computation signed which can lead to sign extensions and signed wraps. It's not much of a problem as we build with -fno-strict-overflow. But if we ever decide not to, be ready, so switch the constant to unsigned. Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210105120239.28031-7-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e0c29b368ded7a5dae0c119280345ed9788f7600 Author: Heiner Kallweit Date: Tue Dec 1 12:39:57 2020 +0100 x86/reboot: Add Zotac ZBOX CI327 nano PCI reboot quirk [ Upstream commit 4b2d8ca9208be636b30e924b1cbcb267b0740c93 ] On this system the M.2 PCIe WiFi card isn't detected after reboot, only after cold boot. reboot=pci fixes this behavior. In [0] the same issue is described, although on another system and with another Intel WiFi card. In case it's relevant, both systems have Celeron CPUs. Add a PCI reboot quirk on affected systems until a more generic fix is available. [0] https://bugzilla.kernel.org/show_bug.cgi?id=202399 [ bp: Massage commit message. ] Signed-off-by: Heiner Kallweit Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/1524eafd-f89c-cfa4-ed70-0bde9e45eec9@gmail.com Signed-off-by: Sasha Levin commit b3854d1550f09e7616d915d9a540a88e1d269c66 Author: Dinghao Liu Date: Mon Dec 21 20:24:35 2020 +0800 staging: fwserial: Fix error handling in fwserial_create [ Upstream commit f31559af97a0eabd467e4719253675b7dccb8a46 ] When fw_core_add_address_handler() fails, we need to destroy the port by tty_port_destroy(). Also we need to unregister the address handler by fw_core_remove_address_handler() on failure. Signed-off-by: Dinghao Liu Link: https://lore.kernel.org/r/20201221122437.10274-1-dinghao.liu@zju.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a03583775a5f3e0171e15692159cdbf7816ddf6f Author: Borislav Petkov Date: Sat Dec 12 15:20:28 2020 +0100 EDAC/amd64: Do not load on family 0x15, model 0x13 [ Upstream commit 6c13d7ff81e6d2f01f62ccbfa49d1b8d87f274d0 ] Those were only laptops and are very very unlikely to have ECC memory. Currently, when the driver attempts to load, it issues: EDAC amd64: Error: F1 not found: device 0x1601 (broken BIOS?) because the PCI device is the wrong one (it uses the F15h default one). So do not load the driver on them as that is pointless. Reported-by: Don Curtis Signed-off-by: Borislav Petkov Tested-by: Don Curtis Link: http://bugzilla.opensuse.org/show_bug.cgi?id=1179763 Link: https://lkml.kernel.org/r/20201218160622.20146-1-bp@alien8.de Signed-off-by: Sasha Levin commit ef690e3f622b1ee785a6bf6f987ee5a4e3056525 Author: Marek Vasut Date: Tue Nov 3 19:09:40 2020 +0100 rsi: Move card interrupt handling to RX thread [ Upstream commit 287431463e786766e05e4dc26d0a11d5f8ac8815 ] The interrupt handling of the RS911x is particularly heavy. For each RX packet, the card does three SDIO transactions, one to read interrupt status register, one to RX buffer length, one to read the RX packet(s). This translates to ~330 uS per one cycle of interrupt handler. In case there is more incoming traffic, this will be more. The drivers/mmc/core/sdio_irq.c has the following comment, quote "Just like traditional hard IRQ handlers, we expect SDIO IRQ handlers to be quick and to the point, so that the holding of the host lock does not cover too much work that doesn't require that lock to be held." The RS911x interrupt handler does not fit that. This patch therefore changes it such that the entire IRQ handler is moved to the RX thread instead, and the interrupt handler only wakes the RX thread. This is OK, because the interrupt handler only does things which can also be done in the RX thread, that is, it checks for firmware loading error(s), it checks buffer status, it checks whether a packet arrived and if so, reads out the packet and passes it to network stack. Moreover, this change permits removal of a code which allocated an skbuff only to get 4-byte-aligned buffer, read up to 8kiB of data into the skbuff, queue this skbuff into local private queue, then in RX thread, this buffer is dequeued, the data in the skbuff as passed to the RSI driver core, and the skbuff is deallocated. All this is replaced by directly calling the RSI driver core with local buffer. Signed-off-by: Marek Vasut Cc: Angus Ainslie Cc: David S. Miller Cc: Jakub Kicinski Cc: Kalle Valo Cc: Lee Jones Cc: Martin Kepplinger Cc: Sebastian Krzyszkowiak Cc: Siva Rebbagondla Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Tested-by: Martin Kepplinger Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201103180941.443528-1-marex@denx.de Signed-off-by: Sasha Levin commit ec52458902b8fbf93db446bed292519bb4139a22 Author: Marek Vasut Date: Thu Oct 15 13:16:16 2020 +0200 rsi: Fix TX EAPOL packet handling against iwlwifi AP [ Upstream commit 65277100caa2f2c62b6f3c4648b90d6f0435f3bc ] In case RSI9116 SDIO WiFi operates in STA mode against Intel 9260 in AP mode, the association fails. The former is using wpa_supplicant during association, the later is set up using hostapd: iwl$ cat hostapd.conf interface=wlp1s0 ssid=test country_code=DE hw_mode=g channel=1 wpa=2 wpa_passphrase=test wpa_key_mgmt=WPA-PSK iwl$ hostapd -d hostapd.conf rsi$ wpa_supplicant -i wlan0 -c <(wpa_passphrase test test) The problem is that the TX EAPOL data descriptor RSI_DESC_REQUIRE_CFM_TO_HOST flag and extended descriptor EAPOL4_CONFIRM frame type are not set in case the AP is iwlwifi, because in that case the TX EAPOL packet is 2 bytes shorter. The downstream vendor driver has this change in place already [1], however there is no explanation for it, neither is there any commit history from which such explanation could be obtained. [1] https://github.com/SiliconLabs/RS911X-nLink-OSD/blob/master/rsi/rsi_91x_hal.c#L238 Signed-off-by: Marek Vasut Cc: Angus Ainslie Cc: David S. Miller Cc: Jakub Kicinski Cc: Kalle Valo Cc: Lee Jones Cc: Martin Kepplinger Cc: Sebastian Krzyszkowiak Cc: Siva Rebbagondla Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201015111616.429220-1-marex@denx.de Signed-off-by: Sasha Levin commit b3186a3a0d894a3a91d766f5c487f49006267f54 Author: Stephen Boyd Date: Thu Jan 14 19:43:24 2021 -0800 ASoC: qcom: Remove useless debug print commit 16117beb16f01a470d40339960ffae1e287c03be upstream. This looks like a left over debug print that tells us that HDMI is enabled. Let's remove it as that's definitely not an error to have HDMI enabled. Cc: V Sujith Kumar Reddy Cc: Srinivasa Rao Cc: Srinivas Kandagatla Cc: Cheng-Yi Chiang Fixes: 7cb37b7bd0d3 ("ASoC: qcom: Add support for lpass hdmi driver") Signed-off-by: Stephen Boyd Reviewed-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210115034327.617223-2-swboyd@chromium.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5c671e4a4c39a1a74274d4da1698e40e570a1883 Author: Geert Uytterhoeven Date: Thu Jan 14 14:13:33 2021 +0100 dt-bindings: net: btusb: DT fix s/interrupt-name/interrupt-names/ commit f288988930e93857e0375bdf88bb670c312b82eb upstream. The standard DT property name is "interrupt-names". Fixes: fd913ef7ce619467 ("Bluetooth: btusb: Add out-of-band wakeup support") Signed-off-by: Geert Uytterhoeven Acked-by: Rob Herring Reviewed-by: Brian Norris Acked-by: Rajat Jain Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 33dbc6759de36ce6c95e1d2d325e663b87e13ef0 Author: Russell King Date: Mon Feb 1 10:02:20 2021 +0000 dt-bindings: ethernet-controller: fix fixed-link specification commit 322322d15b9b912bc8710c367a95a7de62220a72 upstream. The original fixed-link.txt allowed a pause property for fixed link. This has been missed in the conversion to yaml format. Fixes: 9d3de3c58347 ("dt-bindings: net: Add YAML schemas for the generic Ethernet options") Signed-off-by: Russell King Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/E1l6W2G-0002Ga-0O@rmk-PC.armlinux.org.uk Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 1fc205d9e400f069ebf30d3faa6ec2bab2cbd7b4 Author: Cong Wang Date: Thu Feb 11 11:34:10 2021 -0800 net: fix dev_ifsioc_locked() race condition commit 3b23a32a63219f51a5298bc55a65ecee866e79d0 upstream. dev_ifsioc_locked() is called with only RCU read lock, so when there is a parallel writer changing the mac address, it could get a partially updated mac address, as shown below: Thread 1 Thread 2 // eth_commit_mac_addr_change() memcpy(dev->dev_addr, addr->sa_data, ETH_ALEN); // dev_ifsioc_locked() memcpy(ifr->ifr_hwaddr.sa_data, dev->dev_addr,...); Close this race condition by guarding them with a RW semaphore, like netdev_get_name(). We can not use seqlock here as it does not allow blocking. The writers already take RTNL anyway, so this does not affect the slow path. To avoid bothering existing dev_set_mac_address() callers in drivers, introduce a new wrapper just for user-facing callers on ioctl and rtnetlink paths. Note, bonding also changes slave mac addresses but that requires a separate patch due to the complexity of bonding code. Fixes: 3710becf8a58 ("net: RCU locking for simple ioctl()") Reported-by: "Gong, Sishuai" Cc: Eric Dumazet Cc: Jakub Kicinski Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 57b8c5bf2dd0f6171e0dff4ddb5f91af563534b3 Author: Chris Mi Date: Thu Feb 25 15:51:45 2021 +0800 net: psample: Fix netlink skb length with tunnel info commit a93dcaada2ddb58dbc72652b42548adedd646d7a upstream. Currently, the psample netlink skb is allocated with a size that does not account for the nested 'PSAMPLE_ATTR_TUNNEL' attribute and the padding required for the 64-bit attribute 'PSAMPLE_TUNNEL_KEY_ATTR_ID'. This can result in failure to add attributes to the netlink skb due to insufficient tail room. The following error message is printed to the kernel log: "Could not create psample log message". Fix this by adjusting the allocation size to take into account the nested attribute and the padding. Fixes: d8bed686ab96 ("net: psample: Add tunnel support") CC: Yotam Gigi Reviewed-by: Ido Schimmel Reviewed-by: Jiri Pirko Signed-off-by: Chris Mi Link: https://lore.kernel.org/r/20210225075145.184314-1-cmi@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit daea77234623f2d44f23cc0821b4422a83f8a277 Author: Marco Wenzel Date: Wed Feb 24 10:46:49 2021 +0100 net: hsr: add support for EntryForgetTime commit f176411401127a07a9360dec14eca448eb2e9d45 upstream. In IEC 62439-3 EntryForgetTime is defined with a value of 400 ms. When a node does not send any frame within this time, the sequence number check for can be ignored. This solves communication issues with Cisco IE 2000 in Redbox mode. Fixes: f421436a591d ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)") Signed-off-by: Marco Wenzel Reviewed-by: George McCollister Tested-by: George McCollister Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20210224094653.1440-1-marco.wenzel@a-eberle.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a31cb3072d11411e3fdf2d93ab3daded5b69d18b Author: DENG Qingfang Date: Thu Feb 18 11:45:14 2021 +0800 net: ag71xx: remove unnecessary MTU reservation commit 04b385f325080157ab1b5f8ce1b1de07ce0d9e27 upstream. 2 bytes of the MTU are reserved for Atheros DSA tag, but DSA core has already handled that since commit dc0fe7d47f9f. Remove the unnecessary reservation. Fixes: d51b6ce441d3 ("net: ethernet: add ag71xx driver") Signed-off-by: DENG Qingfang Reviewed-by: Oleksij Rempel Link: https://lore.kernel.org/r/20210218034514.3421-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 10b55a0a7f4be197623f90958d9e6004c8fc987a Author: Linus Walleij Date: Wed Feb 17 00:55:42 2021 +0100 net: dsa: tag_rtl4_a: Support also egress tags commit 86dd9868b8788a9063893a97649594af93cd5aa6 upstream. Support also transmitting frames using the custom "8899 A" 4 byte tag. Qingfang came up with the solution: we need to pad the ethernet frame to 60 bytes using eth_skb_pad(), then the switch will happily accept frames with custom tags. Cc: Mauri Sandberg Reported-by: DENG Qingfang Fixes: efd7fe68f0c6 ("net: dsa: tag_rtl4_a: Implement Realtek 4 byte A tag") Signed-off-by: Linus Walleij Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7b23cad0308ad12bb1c228ff103d7e2ad836156d Author: wenxu Date: Tue Feb 9 14:37:49 2021 +0800 net/sched: cls_flower: Reject invalid ct_state flags rules commit 1bcc51ac0731aab1b109b2cd5c3d495f1884e5ca upstream. Reject the unsupported and invalid ct_state flags of cls flower rules. Fixes: e0ace68af2ac ("net/sched: cls_flower: Add matching on conntrack info") Signed-off-by: wenxu Reviewed-by: Marcelo Ricardo Leitner Reviewed-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b74206091e291509cc4724c0cfeaf52c89abf2b3 Author: Vladimir Oltean Date: Sun Feb 7 21:47:33 2021 +0200 net: bridge: use switchdev for port flags set through sysfs too commit 8043c845b63a2dd88daf2d2d268a33e1872800f0 upstream. Looking through patchwork I don't see that there was any consensus to use switchdev notifiers only in case of netlink provided port flags but not sysfs (as a sort of deprecation, punishment or anything like that), so we should probably keep the user interface consistent in terms of functionality. http://patchwork.ozlabs.org/project/netdev/patch/20170605092043.3523-3-jiri@resnulli.us/ http://patchwork.ozlabs.org/project/netdev/patch/20170608064428.4785-3-jiri@resnulli.us/ Fixes: 3922285d96e7 ("net: bridge: Add support for offloading port attributes") Signed-off-by: Vladimir Oltean Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5ab779a68e37f01994fedacf2843200dfcd2cfce Author: Paolo Abeni Date: Fri Feb 19 18:35:40 2021 +0100 mptcp: do not wakeup listener for MPJ subflows commit 52557dbc7538ecceb27ef2206719a47a8039a335 upstream. MPJ subflows are not exposed as fds to user spaces. As such, incoming MPJ subflows are removed from the accept queue by tcp_check_req()/tcp_get_cookie_sock(). Later tcp_child_process() invokes subflow_data_ready() on the parent socket regardless of the subflow kind, leading to poll wakeups even if the later accept will block. Address the issue by double-checking the queue state before waking the user-space. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/164 Reported-by: Dr. David Alan Gilbert Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN requests") Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9adbc25b0e309500f8fb139adfb397b762952230 Author: Eric Dumazet Date: Wed Feb 10 09:13:33 2021 -0800 tcp: fix tcp_rmem documentation commit 1d1be91254bbdd189796041561fd430f7553bb88 upstream. tcp_rmem[1] has been changed to 131072, we should update the documentation to reflect this. Fixes: a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB") Signed-off-by: Eric Dumazet Reported-by: Zhibin Liu Cc: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 73a4bde5e5808d5c4c8b37416e77e205bf34428a Author: Jack Wang Date: Thu Dec 17 15:19:13 2020 +0100 RDMA/rtrs-srv: Do not signal REG_MR commit e8ae7ddb48a1b81fd1e67da34a0cb59daf0445d6 upstream. We do not need to wait for REG_MR completion, so remove the SIGNAL flag. Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Link: https://lore.kernel.org/r/20201217141915.56989-18-jinpu.wang@cloud.ionos.com Signed-off-by: Jack Wang Signed-off-by: Gioh Kim Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 70123d9989df9571c07fd15491cd9ec09ec12180 Author: Jack Wang Date: Thu Dec 17 15:19:12 2020 +0100 RDMA/rtrs-clt: Use bitmask to check sess->flags commit aaed465f761700dace9ab39521013cddaae4f5a3 upstream. We may want to add new flags, so it's better to use bitmask to check flags. Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality") Link: https://lore.kernel.org/r/20201217141915.56989-17-jinpu.wang@cloud.ionos.com Signed-off-by: Jack Wang Signed-off-by: Gioh Kim Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 482157ed2060a79fff83735bb5afa1a962500bc1 Author: Jack Wang Date: Thu Dec 17 15:19:11 2020 +0100 RDMA/rtrs: Do not signal for heatbeat commit b38041d50add1c881fbc60eb2be93b58fc58ea21 upstream. For HB, there is no need to generate signal for completion. Also remove a comment accordingly. Fixes: c0894b3ea69d ("RDMA/rtrs: core: lib functions shared between client and server modules") Link: https://lore.kernel.org/r/20201217141915.56989-16-jinpu.wang@cloud.ionos.com Signed-off-by: Jack Wang Reported-by: Gioh Kim Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit e335952d8645dce4ee0eea01c69d041d59c5c545 Author: Li Xinhai Date: Wed Feb 24 12:06:54 2021 -0800 mm/hugetlb.c: fix unnecessary address expansion of pmd sharing commit a1ba9da8f0f9a37d900ff7eff66482cf7de8015e upstream. The current code would unnecessarily expand the address range. Consider one example, (start, end) = (1G-2M, 3G+2M), and (vm_start, vm_end) = (1G-4M, 3G+4M), the expected adjustment should be keep (1G-2M, 3G+2M) without expand. But the current result will be (1G-4M, 3G+4M). Actually, the range (1G-4M, 1G) and (3G, 3G+4M) would never been involved in pmd sharing. After this patch, we will check that the vma span at least one PUD aligned size and the start,end range overlap the aligned range of vma. With above example, the aligned vma range is (1G, 3G), so if (start, end) range is within (1G-4M, 1G), or within (3G, 3G+4M), then no adjustment to both start and end. Otherwise, we will have chance to adjust start downwards or end upwards without exceeding (vm_start, vm_end). Mike: : The 'adjusted range' is used for calls to mmu notifiers and cache(tlb) : flushing. Since the current code unnecessarily expands the range in some : cases, more entries than necessary would be flushed. This would/could : result in performance degradation. However, this is highly dependent on : the user runtime. Is there a combination of vma layout and calls to : actually hit this issue? If the issue is hit, will those entries : unnecessarily flushed be used again and need to be unnecessarily reloaded? Link: https://lkml.kernel.org/r/20210104081631.2921415-1-lixinhai.lxh@gmail.com Fixes: 75802ca66354 ("mm/hugetlb: fix calculation of adjust_range_if_pmd_sharing_possible") Signed-off-by: Li Xinhai Suggested-by: Mike Kravetz Reviewed-by: Mike Kravetz Cc: Peter Xu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit dc2b77642e5da83ce65e9d3b7febe5634f8ff32e Author: Josef Bacik Date: Mon Feb 22 15:09:53 2021 -0500 nbd: handle device refs for DESTROY_ON_DISCONNECT properly commit c9a2f90f4d6b9d42b9912f7aaf68e8d748acfffd upstream. There exists a race where we can be attempting to create a new nbd configuration while a previous configuration is going down, both configured with DESTROY_ON_DISCONNECT. Normally devices all have a reference of 1, as they won't be cleaned up until the module is torn down. However with DESTROY_ON_DISCONNECT we'll make sure that there is only 1 reference (generally) on the device for the config itself, and then once the config is dropped, the device is torn down. The race that exists looks like this TASK1 TASK2 nbd_genl_connect() idr_find() refcount_inc_not_zero(nbd) * count is 2 here ^^ nbd_config_put() nbd_put(nbd) (count is 1) setup new config check DESTROY_ON_DISCONNECT put_dev = true if (put_dev) nbd_put(nbd) * free'd here ^^ In nbd_genl_connect() we assume that the nbd ref count will be 2, however clearly that won't be true if the nbd device had been setup as DESTROY_ON_DISCONNECT with its prior configuration. Fix this by getting rid of the runtime flag to check if we need to mess with the nbd device refcount, and use the device NBD_DESTROY_ON_DISCONNECT flag to check if we need to adjust the ref counts. This was reported by syzkaller with the following kasan dump BUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:71 [inline] BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:27 [inline] BUG: KASAN: use-after-free in refcount_dec_not_one+0x71/0x1e0 lib/refcount.c:76 Read of size 4 at addr ffff888143bf71a0 by task systemd-udevd/8451 CPU: 0 PID: 8451 Comm: systemd-udevd Not tainted 5.11.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:230 __kasan_report mm/kasan/report.c:396 [inline] kasan_report.cold+0x79/0xd5 mm/kasan/report.c:413 check_memory_region_inline mm/kasan/generic.c:179 [inline] check_memory_region+0x13d/0x180 mm/kasan/generic.c:185 instrument_atomic_read include/linux/instrumented.h:71 [inline] atomic_read include/asm-generic/atomic-instrumented.h:27 [inline] refcount_dec_not_one+0x71/0x1e0 lib/refcount.c:76 refcount_dec_and_mutex_lock+0x19/0x140 lib/refcount.c:115 nbd_put drivers/block/nbd.c:248 [inline] nbd_release+0x116/0x190 drivers/block/nbd.c:1508 __blkdev_put+0x548/0x800 fs/block_dev.c:1579 blkdev_put+0x92/0x570 fs/block_dev.c:1632 blkdev_close+0x8c/0xb0 fs/block_dev.c:1640 __fput+0x283/0x920 fs/file_table.c:280 task_work_run+0xdd/0x190 kernel/task_work.c:140 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop kernel/entry/common.c:174 [inline] exit_to_user_mode_prepare+0x249/0x250 kernel/entry/common.c:201 __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fc1e92b5270 Code: 73 01 c3 48 8b 0d 38 7d 20 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 59 c1 20 00 00 75 10 b8 03 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ee fb ff ff 48 89 04 24 RSP: 002b:00007ffe8beb2d18 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000000000000007 RCX: 00007fc1e92b5270 RDX: 000000000aba9500 RSI: 0000000000000000 RDI: 0000000000000007 RBP: 00007fc1ea16f710 R08: 000000000000004a R09: 0000000000000008 R10: 0000562f8cb0b2a8 R11: 0000000000000246 R12: 0000000000000000 R13: 0000562f8cb0afd0 R14: 0000000000000003 R15: 000000000000000e Allocated by task 1: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:46 [inline] set_alloc_info mm/kasan/common.c:401 [inline] ____kasan_kmalloc.constprop.0+0x82/0xa0 mm/kasan/common.c:429 kmalloc include/linux/slab.h:552 [inline] kzalloc include/linux/slab.h:682 [inline] nbd_dev_add+0x44/0x8e0 drivers/block/nbd.c:1673 nbd_init+0x250/0x271 drivers/block/nbd.c:2394 do_one_initcall+0x103/0x650 init/main.c:1223 do_initcall_level init/main.c:1296 [inline] do_initcalls init/main.c:1312 [inline] do_basic_setup init/main.c:1332 [inline] kernel_init_freeable+0x605/0x689 init/main.c:1533 kernel_init+0xd/0x1b8 init/main.c:1421 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 Freed by task 8451: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_set_track+0x1c/0x30 mm/kasan/common.c:46 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:356 ____kasan_slab_free+0xe1/0x110 mm/kasan/common.c:362 kasan_slab_free include/linux/kasan.h:192 [inline] slab_free_hook mm/slub.c:1547 [inline] slab_free_freelist_hook+0x5d/0x150 mm/slub.c:1580 slab_free mm/slub.c:3143 [inline] kfree+0xdb/0x3b0 mm/slub.c:4139 nbd_dev_remove drivers/block/nbd.c:243 [inline] nbd_put.part.0+0x180/0x1d0 drivers/block/nbd.c:251 nbd_put drivers/block/nbd.c:295 [inline] nbd_config_put+0x6dd/0x8c0 drivers/block/nbd.c:1242 nbd_release+0x103/0x190 drivers/block/nbd.c:1507 __blkdev_put+0x548/0x800 fs/block_dev.c:1579 blkdev_put+0x92/0x570 fs/block_dev.c:1632 blkdev_close+0x8c/0xb0 fs/block_dev.c:1640 __fput+0x283/0x920 fs/file_table.c:280 task_work_run+0xdd/0x190 kernel/task_work.c:140 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop kernel/entry/common.c:174 [inline] exit_to_user_mode_prepare+0x249/0x250 kernel/entry/common.c:201 __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at ffff888143bf7000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 416 bytes inside of 1024-byte region [ffff888143bf7000, ffff888143bf7400) The buggy address belongs to the page: page:000000005238f4ce refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x143bf0 head:000000005238f4ce order:3 compound_mapcount:0 compound_pincount:0 flags: 0x57ff00000010200(slab|head) raw: 057ff00000010200 ffffea00004b1400 0000000300000003 ffff888010c41140 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888143bf7080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888143bf7100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888143bf7180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888143bf7200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Reported-and-tested-by: syzbot+429d3f82d757c211bff3@syzkaller.appspotmail.com Signed-off-by: Josef Bacik Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit bd9f7dc079f1b754447563acf952a4620b32575f Author: Alexandre Ghiti Date: Sun Feb 21 09:22:33 2021 -0500 riscv: Get rid of MAX_EARLY_MAPPING_SIZE commit 0f02de4481da684aad6589aed0ea47bd1ab391c9 upstream. At early boot stage, we have a whole PGDIR to map the kernel, so there is no need to restrict the early mapping size to 128MB. Removing this define also allows us to simplify some compile time logic. This fixes large kernel mappings with a size greater than 128MB, as it is the case for syzbot kernels whose size was just ~130MB. Note that on rv64, for now, we are then limited to PGDIR size for early mapping as we can't use PGD mappings (see [1]). That should be enough given the relative small size of syzbot kernels compared to PGDIR_SIZE which is 1GB. [1] https://lore.kernel.org/lkml/20200603153608.30056-1-alex@ghiti.fr/ Reported-by: Dmitry Vyukov Signed-off-by: Alexandre Ghiti Tested-by: Dmitry Vyukov Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 97ff09a7ed484fef2b1bbc103857444b7332fca8 Author: Marco Elver Date: Mon Feb 1 17:04:20 2021 +0100 net: fix up truesize of cloned skb in skb_prepare_for_shift() commit 097b9146c0e26aabaa6ff3e5ea536a53f5254a79 upstream. Avoid the assumption that ksize(kmalloc(S)) == ksize(kmalloc(S)): when cloning an skb, save and restore truesize after pskb_expand_head(). This can occur if the allocator decides to service an allocation of the same size differently (e.g. use a different size class, or pass the allocation on to KFENCE). Because truesize is used for bookkeeping (such as sk_wmem_queued), a modified truesize of a cloned skb may result in corrupt bookkeeping and relevant warnings (such as in sk_stream_kill_queues()). Link: https://lkml.kernel.org/r/X9JR/J6dMMOy1obu@elver.google.com Reported-by: syzbot+7b99aafdcc2eedea6178@syzkaller.appspotmail.com Suggested-by: Eric Dumazet Signed-off-by: Marco Elver Signed-off-by: Eric Dumazet Link: https://lore.kernel.org/r/20210201160420.2826895-1-elver@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e00420943aef3cd07311a968cf0a8cfad24fe8d9 Author: Tetsuo Handa Date: Mon Feb 1 11:52:11 2021 +0900 tomoyo: ignore data race while checking quota commit 5797e861e402fff2bedce4ec8b7c89f4248b6073 upstream. syzbot is reporting that tomoyo's quota check is racy [1]. But this check is tolerant of some degree of inaccuracy. Thus, teach KCSAN to ignore this data race. [1] https://syzkaller.appspot.com/bug?id=999533deec7ba6337f8aa25d8bd1a4d5f7e50476 Reported-by: syzbot Signed-off-by: Tetsuo Handa Signed-off-by: Greg Kroah-Hartman commit fa5b65609256fee27199c81368e984e48cb5dcfe Author: Sabyrzhan Tasbolatov Date: Thu Jan 28 17:58:01 2021 +0600 smackfs: restrict bytes count in smackfs write functions commit 7ef4c19d245f3dc233fd4be5acea436edd1d83d8 upstream. syzbot found WARNINGs in several smackfs write operations where bytes count is passed to memdup_user_nul which exceeds GFP MAX_ORDER. Check count size if bigger than PAGE_SIZE. Per smackfs doc, smk_write_net4addr accepts any label or -CIPSO, smk_write_net6addr accepts any label or -DELETE. I couldn't find any general rule for other label lengths except SMK_LABELLEN, SMK_LONGLABEL, SMK_CIPSOMAX which are documented. Let's constrain, in general, smackfs label lengths for PAGE_SIZE. Although fuzzer crashes write to smackfs/netlabel on 0x400000 length. Here is a quick way to reproduce the WARNING: python -c "print('A' * 0x400000)" > /sys/fs/smackfs/netlabel Reported-by: syzbot+a71a442385a0b2815497@syzkaller.appspotmail.com Signed-off-by: Sabyrzhan Tasbolatov Signed-off-by: Casey Schaufler Signed-off-by: Greg Kroah-Hartman commit 23a523ef400de62e47df37564620ce53a2fb943e Author: Alexander Egorenkov Date: Thu Jan 28 12:41:04 2021 +0100 net/af_iucv: remove WARN_ONCE on malformed RX packets commit 27e9c1de529919d8dd7d072415d3bcae77709300 upstream. syzbot reported the following finding: AF_IUCV failed to receive skb, len=0 WARNING: CPU: 0 PID: 522 at net/iucv/af_iucv.c:2039 afiucv_hs_rcv+0x174/0x190 net/iucv/af_iucv.c:2039 CPU: 0 PID: 522 Comm: syz-executor091 Not tainted 5.10.0-rc1-syzkaller-07082-g55027a88ec9f #0 Hardware name: IBM 3906 M04 701 (KVM/Linux) Call Trace: [<00000000b87ea538>] afiucv_hs_rcv+0x178/0x190 net/iucv/af_iucv.c:2039 ([<00000000b87ea534>] afiucv_hs_rcv+0x174/0x190 net/iucv/af_iucv.c:2039) [<00000000b796533e>] __netif_receive_skb_one_core+0x13e/0x188 net/core/dev.c:5315 [<00000000b79653ce>] __netif_receive_skb+0x46/0x1c0 net/core/dev.c:5429 [<00000000b79655fe>] netif_receive_skb_internal+0xb6/0x220 net/core/dev.c:5534 [<00000000b796ac3a>] netif_receive_skb+0x42/0x318 net/core/dev.c:5593 [<00000000b6fd45f4>] tun_rx_batched.isra.0+0x6fc/0x860 drivers/net/tun.c:1485 [<00000000b6fddc4e>] tun_get_user+0x1c26/0x27f0 drivers/net/tun.c:1939 [<00000000b6fe0f00>] tun_chr_write_iter+0x158/0x248 drivers/net/tun.c:1968 [<00000000b4f22bfa>] call_write_iter include/linux/fs.h:1887 [inline] [<00000000b4f22bfa>] new_sync_write+0x442/0x648 fs/read_write.c:518 [<00000000b4f238fe>] vfs_write.part.0+0x36e/0x5d8 fs/read_write.c:605 [<00000000b4f2984e>] vfs_write+0x10e/0x148 fs/read_write.c:615 [<00000000b4f29d0e>] ksys_write+0x166/0x290 fs/read_write.c:658 [<00000000b8dc4ab4>] system_call+0xe0/0x28c arch/s390/kernel/entry.S:415 Last Breaking-Event-Address: [<00000000b8dc64d4>] __s390_indirect_jump_r14+0x0/0xc Malformed RX packets shouldn't generate any warnings because debugging info already flows to dropmon via the kfree_skb(). Signed-off-by: Alexander Egorenkov Reviewed-by: Julian Wiedmann Signed-off-by: Julian Wiedmann Acked-by: Willem de Bruijn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c57ba68e730c55bbb225f882a28e590f01e0670a Author: Yumei Huang Date: Fri Jan 22 16:48:19 2021 -0800 xfs: Fix assert failure in xfs_setattr_size() commit 88a9e03beef22cc5fabea344f54b9a0dfe63de08 upstream. An assert failure is triggered by syzkaller test due to ATTR_KILL_PRIV is not cleared before xfs_setattr_size. As ATTR_KILL_PRIV is not checked/used by xfs_setattr_size, just remove it from the assert. Signed-off-by: Yumei Huang Reviewed-by: Brian Foster Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit c55db99fd8c0b1b21ae28d4819a2233fc50b63ce Author: Hans Verkuil Date: Wed Jan 20 09:28:02 2021 +0100 media: v4l2-ctrls.c: fix shift-out-of-bounds in std_validate commit 048c96e28674f15c0403deba2104ffba64544a06 upstream. If a menu has more than 64 items, then don't check menu_skip_mask for items 65 and up. Signed-off-by: Hans Verkuil Reported-by: syzbot+42d8c7c3d3e594b34346@syzkaller.appspotmail.com Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 5e0068a4fb107af27230441c1e38b8dee1bfdc9d Author: Gao Xiang Date: Wed Jan 20 09:30:16 2021 +0800 erofs: fix shift-out-of-bounds of blkszbits commit bde545295b710bdd13a0fcd4b9fddd2383eeeb3a upstream. syzbot generated a crafted bitszbits which can be shifted out-of-bounds[1]. So directly print unsupported blkszbits instead of blksize. [1] https://lore.kernel.org/r/000000000000c72ddd05b9444d2f@google.com Link: https://lore.kernel.org/r/20210120013016.14071-1-hsiangkao@aol.com Reported-by: syzbot+c68f467cd7c45860e8d4@syzkaller.appspotmail.com Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit 1aeaa0ea7df5dc03a8dc6b4bfd8ea13ce5c85f66 Author: Sean Young Date: Tue Jan 19 14:53:50 2021 +0100 media: mceusb: sanity check for prescaler value commit 9dec0f48a75e0dadca498002d25ef4e143e60194 upstream. prescaler larger than 8 would mean the carrier is at most 152Hz, which does not make sense for IR carriers. Reported-by: syzbot+6d31bf169a8265204b8d@syzkaller.appspotmail.com Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 17a6e850e5faebc33f62685ea32de95d8ba98300 Author: Zqiang Date: Tue Dec 15 14:30:22 2020 +0800 udlfb: Fix memory leak in dlfb_usb_probe commit 5c0e4110f751934e748a66887c61f8e73805f0f9 upstream. The dlfb_alloc_urb_list function is called in dlfb_usb_probe function, after that if an error occurs, the dlfb_free_urb_list function need to be called. BUG: memory leak unreferenced object 0xffff88810adde100 (size 32): comm "kworker/1:0", pid 17, jiffies 4294947788 (age 19.520s) hex dump (first 32 bytes): 10 30 c3 0d 81 88 ff ff c0 fa 63 12 81 88 ff ff .0........c..... 00 30 c3 0d 81 88 ff ff 80 d1 3a 08 81 88 ff ff .0........:..... backtrace: [<0000000019512953>] kmalloc include/linux/slab.h:552 [inline] [<0000000019512953>] kzalloc include/linux/slab.h:664 [inline] [<0000000019512953>] dlfb_alloc_urb_list drivers/video/fbdev/udlfb.c:1892 [inline] [<0000000019512953>] dlfb_usb_probe.cold+0x289/0x988 drivers/video/fbdev/udlfb.c:1704 [<0000000072160152>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<00000000a8d6726f>] really_probe+0x159/0x480 drivers/base/dd.c:554 [<00000000c3ce4b0e>] driver_probe_device+0x84/0x100 drivers/base/dd.c:738 [<00000000e942e01c>] __device_attach_driver+0xee/0x110 drivers/base/dd.c:844 [<00000000de0a5a5c>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431 [<00000000463fbcb4>] __device_attach+0x122/0x250 drivers/base/dd.c:912 [<00000000b881a711>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491 [<00000000364bbda5>] device_add+0x5ac/0xc30 drivers/base/core.c:2936 [<00000000eecca418>] usb_set_configuration+0x9de/0xb90 drivers/usb/core/message.c:2159 [<00000000edfeca2d>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [<000000001830872b>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [<00000000a8d6726f>] really_probe+0x159/0x480 drivers/base/dd.c:554 [<00000000c3ce4b0e>] driver_probe_device+0x84/0x100 drivers/base/dd.c:738 [<00000000e942e01c>] __device_attach_driver+0xee/0x110 drivers/base/dd.c:844 [<00000000de0a5a5c>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431 Reported-by: syzbot+c9e365d7f450e8aa615d@syzkaller.appspotmail.com Signed-off-by: Zqiang Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20201215063022.16746-1-qiang.zhang@windriver.com Signed-off-by: Greg Kroah-Hartman commit 6816509065b9d895a287ec01d3da81a6904b1467 Author: Peter Zijlstra Date: Sat Aug 29 10:22:24 2020 -0700 sched/core: Allow try_invoke_on_locked_down_task() with irqs disabled commit 1b7af295541d75535374325fd617944534853919 upstream. The try_invoke_on_locked_down_task() function currently requires that interrupts be enabled, but it is called with interrupts disabled from rcu_print_task_stall(), resulting in an "IRQs not enabled as expected" diagnostic. This commit therefore updates try_invoke_on_locked_down_task() to use raw_spin_lock_irqsave() instead of raw_spin_lock_irq(), thus allowing use from either context. Link: https://lore.kernel.org/lkml/000000000000903d5805ab908fc4@google.com/ Link: https://lore.kernel.org/lkml/20200928075729.GC2611@hirez.programming.kicks-ass.net/ Reported-by: syzbot+cb3b69ae80afd6535b0e@syzkaller.appspotmail.com Signed-off-by: Peter Zijlstra Signed-off-by: Paul E. McKenney Signed-off-by: Greg Kroah-Hartman commit 40f6090d6ea0ba33c76942e5b7d5dbbc406f1465 Author: Randy Dunlap Date: Fri Dec 18 12:17:16 2020 -0800 JFS: more checks for invalid superblock commit 3bef198f1b17d1bb89260bad947ef084c0a2d1a6 upstream. syzbot is feeding invalid superblock data to JFS for mount testing. JFS does not check several of the fields -- just assumes that they are good since the JFS_MAGIC and version fields are good. In this case (syzbot reproducer), we have s_l2bsize == 0xda0c, pad == 0xf045, and s_state == 0x50, all of which are invalid IMO. Having s_l2bsize == 0xda0c causes this UBSAN warning: UBSAN: shift-out-of-bounds in fs/jfs/jfs_mount.c:373:25 shift exponent -9716 is negative s_l2bsize can be tested for correctness. pad can be tested for non-0 and punted. s_state can be tested for its valid values and punted. Do those 3 tests and if any of them fails, report the superblock as invalid/corrupt and let fsck handle it. With this patch, chkSuper() says this when JFS_DEBUG is enabled: jfs_mount: Mount Failure: superblock is corrupt! Mount JFS Failure: -22 jfs_mount failed w/return code = -22 The obvious problem with this method is that next week there could be another syzbot test that uses different fields for invalid values, this making this like a game of whack-a-mole. syzkaller link: https://syzkaller.appspot.com/bug?extid=36315852ece4132ec193 Reported-by: syzbot+36315852ece4132ec193@syzkaller.appspotmail.com Reported-by: kernel test robot # v2 Signed-off-by: Randy Dunlap Signed-off-by: Dave Kleikamp Cc: jfs-discussion@lists.sourceforge.net Signed-off-by: Greg Kroah-Hartman commit b3d0f1c3a671916e95dc56f6cc0134bfb5c7b7a2 Author: Fangrui Song Date: Wed Jan 27 12:56:00 2021 -0800 x86/build: Treat R_386_PLT32 relocation as R_386_PC32 commit bb73d07148c405c293e576b40af37737faf23a6a upstream. This is similar to commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") but for i386. As far as the kernel is concerned, R_386_PLT32 can be treated the same as R_386_PC32. R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types which can only be used by branches. If the referenced symbol is defined externally, a PLT will be used. R_386_PC32/R_X86_64_PC32 are PC-relative relocation types which can be used by address taking operations and branches. If the referenced symbol is defined externally, a copy relocation/canonical PLT entry will be created in the executable. On x86-64, there is no PIC vs non-PIC PLT distinction and an R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and `call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler. This avoids canonical PLT entries (st_shndx=0, st_value!=0). On i386, there are 2 types of PLTs, PIC and non-PIC. Currently, the GCC/GNU as convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC PLT. Copy relocations/canonical PLT entries are possible ABI issues but GCC/GNU as will likely keep the status quo because (1) the ABI is legacy (2) the change will drop a GNU ld diagnostic for non-default visibility ifunc in shared objects. clang-12 -fno-pic (since [1]) can emit R_386_PLT32 for compiler generated function declarations, because preventing canonical PLT entries is weighed over the rare ifunc diagnostic. Further info for the more interested: https://github.com/ClangBuiltLinux/linux/issues/1210 https://sourceware.org/bugzilla/show_bug.cgi?id=27169 https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de0083333232da3f1d6 [1] [ bp: Massage commit message. ] Reported-by: Arnd Bergmann Signed-off-by: Fangrui Song Signed-off-by: Borislav Petkov Reviewed-by: Nick Desaulniers Reviewed-by: Nathan Chancellor Tested-by: Nick Desaulniers Tested-by: Nathan Chancellor Tested-by: Sedat Dilek Link: https://lkml.kernel.org/r/20210127205600.1227437-1-maskray@google.com Signed-off-by: Greg Kroah-Hartman commit 63d0afae74c4335b7ede9de92a3f8687ab987378 Author: Sergey Senozhatsky Date: Thu Nov 5 10:47:44 2020 +0900 drm/virtio: use kvmalloc for large allocations commit ea86f3defd55f141a44146e66cbf8ffb683d60da upstream. We observed that some of virtio_gpu_object_shmem_init() allocations can be rather costly - order 6 - which can be difficult to fulfill under memory pressure conditions. Switch to kvmalloc_array() in virtio_gpu_object_shmem_init() and let the kernel vmalloc the entries array. Signed-off-by: Sergey Senozhatsky Link: http://patchwork.freedesktop.org/patch/msgid/20201105014744.1662226-1-senozhatsky@chromium.org Signed-off-by: Gerd Hoffmann Signed-off-by: Doug Horn Signed-off-by: Greg Kroah-Hartman commit a4b0bfbe4b9914a897511c4aee5c5fe36ad7f2a2 Author: Jingle Wu Date: Thu Dec 10 23:40:09 2020 -0800 Input: elan_i2c - add new trackpoint report type 0x5F commit 056115daede8d01f71732bc7d778fb85acee8eb6 upstream. The 0x5F is a new trackpoint report type used by some modules. Signed-off-by: Jingle Wu Link: https://lore.kernel.org/r/20201211071511.32349-1-jingle.wu@emc.com.tw Signed-off-by: Dmitry Torokhov Cc: Nikolai Kostrigin Signed-off-by: Greg Kroah-Hartman commit dde807b4a44273fa5f62c0cb308295e6d6642550 Author: jingle.wu Date: Thu Dec 10 23:49:16 2020 -0800 Input: elantech - fix protocol errors for some trackpoints in SMBus mode commit e4c9062717feda88900b566463228d1c4910af6d upstream. There are some version of Elan trackpads that send incorrect data when in SMbus mode, unless they are switched to use 0x5f reports instead of standard 0x5e. This patch implements querying device to retrieve chips identifying data, and switching it, when needed to the alternative report. Signed-off-by: Jingle Wu Link: https://lore.kernel.org/r/20201211071531.32413-1-jingle.wu@emc.com.tw Signed-off-by: Dmitry Torokhov Cc: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit d00a97dddce6df248e4d00246a29288958d7dc12 Author: Lech Perczak Date: Tue Feb 23 19:34:56 2021 +0100 net: usb: qmi_wwan: support ZTE P685M modem commit 88eee9b7b42e69fb622ddb3ff6f37e8e4347f5b2 upstream. Now that interface 3 in "option" driver is no longer mapped, add device ID matching it to qmi_wwan. The modem is used inside ZTE MF283+ router and carriers identify it as such. Interface mapping is: 0: QCDM, 1: AT (PCUI), 2: AT (Modem), 3: QMI, 4: ADB T: Bus=02 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=19d2 ProdID=1275 Rev=f0.00 S: Manufacturer=ZTE,Incorporated S: Product=ZTE Technologies MSM S: SerialNumber=P685M510ZTED0000CP&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&0 C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=87(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Acked-by: Bjørn Mork Signed-off-by: Lech Perczak Link: https://lore.kernel.org/r/20210223183456.6377-1-lech.perczak@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman