aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-10-28docs: userspace-api: add iommu.rst to the index fileMauro Carvalho Chehab1-0/+1
There's a new uAPI doc for IOMMU. Add it to the index file. Should address this warning: .../Documentation/userspace-api/iommu.rst: WARNING: document isn't included in any toctree Fixes: d0023e3ee28d ("docs: IOMMU user API") Signed-off-by: Mauro Carvalho Chehab <[email protected]> Link: https://lore.kernel.org/r/cc55219a551e29848e2282cd8939a4115067234c.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <[email protected]>
2020-10-28docs: hwmon: mp2975.rst: address some html build warningsMauro Carvalho Chehab2-1/+14
.../Documentation/hwmon/mp2975.rst:25: WARNING: Unexpected indentation. .../Documentation/hwmon/mp2975.rst:27: WARNING: Block quote ends without a blank line; unexpected unindent. .../Documentation/hwmon/mp2975.rst:69: WARNING: Unexpected indentation. .../Documentation/hwmon/mp2975.rst:70: WARNING: Block quote ends without a blank line; unexpected unindent. .../Documentation/hwmon/mp2975.rst:72: WARNING: Bullet list ends without a blank line; unexpected unindent. .../Documentation/hwmon/mp2975.rst: WARNING: document isn't included in any toctree List blocks should have blank lines before and after them, in order to be properly parsed. Fixes: 4beb7a028e9f ("hwmon: (pmbus) Add support for MPS Multi-phase mp2975 controller") Signed-off-by: Mauro Carvalho Chehab <[email protected]> Acked-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/b02f98d886ab1f5af233f8999c7a15529fc52cdc.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <[email protected]>
2020-10-28docs: net: statistics.rst: remove a duplicated kernel-docMauro Carvalho Chehab1-2/+1
include/linux/ethtool.h is included twice with kernel-doc, both to document ethtool_pause_stats(). The first one is at statistics.rst, and the second one at ethtool-netlink.rst. Replace one of the references to use the name of the function. The automarkup.py extension should create the cross-references. Solves this warning: ../Documentation/networking/ethtool-netlink.rst: WARNING: Duplicate C declaration, also defined in 'networking/statistics'. Declaration is 'ethtool_pause_stats'. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Acked-by: David S. Miller <[email protected]> Link: https://lore.kernel.org/r/fdbf853bbdaf3bc1d38f32744b739d175c5c31f5.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <[email protected]>
2020-10-28docs: kasan.rst: add two missing blank linesMauro Carvalho Chehab1-0/+2
literal blocks should start and end with a blank line, as otherwise the parser complains and may do the wrong thing, as warned by Sphinx: Documentation/dev-tools/kasan.rst:298: WARNING: Literal block ends without a blank line; unexpected unindent. Documentation/dev-tools/kasan.rst:303: WARNING: Literal block ends without a blank line; unexpected unindent. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Reviewed-by: Andrey Konovalov <[email protected]> Link: https://lore.kernel.org/r/cd6c4280fe26b07f2c5e5ed2918e17e88bb03419.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <[email protected]>
2020-10-28docs: admin-guide: net.rst: add a missing blank lineMauro Carvalho Chehab1-0/+1
There's a missing blank line after a literal block, which causes this warning: Documentation/admin-guide/sysctl/net.rst:303: WARNING: Literal block ends without a blank line; unexpected unindent. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Link: https://lore.kernel.org/r/b2545be4a4c71269d10278b5990c3e06c4b65f84.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <[email protected]>
2020-10-28docs: hwmon: adm1266.rst: fix a broken referenceMauro Carvalho Chehab1-1/+1
The reference was missing the extension, causing the check script to complain. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Acked-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/3d64372dabcdcea144cdc9972c245812ea2a84cb.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <[email protected]>
2020-10-28sphinx: conf.py: properly handle Sphinx 4.0Mauro Carvalho Chehab1-1/+1
One of the checks for Sphinx 3+ is broken, causing some C warnings to return back with Sphinx 4.0.x. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Link: https://lore.kernel.org/r/d5abc30056dafeec0778a46263a45401bdc7f11e.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <[email protected]>
2020-10-28scripts: kernel-doc: use :c:union when neededMauro Carvalho Chehab1-1/+5
Sphinx C domain code after 3.2.1 will start complaning if :c:struct would be used for an union type: .../Documentation/gpu/drm-kms-helpers:352: ../drivers/video/hdmi.c:851: WARNING: C 'identifier' cross-reference uses wrong tag: reference name is 'union hdmi_infoframe' but found name is 'struct hdmi_infoframe'. Full reference name is 'union hdmi_infoframe'. Full found name is 'struct hdmi_infoframe'. So, let's address this issue too in advance, in order to avoid future issues. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Link: https://lore.kernel.org/r/6e4ec3eec914df62389a299797a3880ae4490f35.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <[email protected]>
2020-10-28documentation: arm: sunxi: add Allwinner H6 documentsWilken Gottwalt1-0/+10
Add the current Allwinner H6 datasheet and user manual. Signed-off-by: Wilken Gottwalt <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2020-10-28drm/i915: Fix encoder lookup during PSR atomic checkImre Deak1-1/+1
The atomic check hooks must look up the encoder to be used with a connector from the connector's atomic state, and not assume that it's the connector's current attached encoder. The latter one can change under the atomic check func, or can be unset yet as in the case of MST connectors. This fixes [ 7.940719] Oops: 0000 [#1] SMP NOPTI [ 7.944407] CPU: 2 PID: 143 Comm: kworker/2:2 Not tainted 5.6.0-1023-oem #23-Ubuntu [ 7.952102] Hardware name: Dell Inc. Latitude 7320/, BIOS 88.87.11 09/07/2020 [ 7.959278] Workqueue: events output_poll_execute [drm_kms_helper] [ 7.965511] RIP: 0010:intel_psr_atomic_check+0x37/0xa0 [i915] [ 7.971327] Code: 80 2d 06 00 00 20 74 42 80 b8 34 71 00 00 00 74 39 48 8b 72 08 48 85 f6 74 30 80 b8 f8 71 00 00 00 74 27 4c 8b 87 80 04 00 00 <41> 8b 78 78 83 ff 08 77 19 31 c9 83 ff 05 77 19 48 81 c1 20 01 00 [ 7.977541] input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/input/input5 [ 7.990154] RSP: 0018:ffffb864c073fac8 EFLAGS: 00010202 [ 7.990155] RAX: ffff8c5d55ce0000 RBX: ffff8c5d54519000 RCX: 0000000000000000 [ 7.990155] RDX: ffff8c5d55cb30c0 RSI: ffff8c5d89a0c800 RDI: ffff8c5d55fcf800 [ 7.990156] RBP: ffffb864c073fac8 R08: 0000000000000000 R09: ffff8c5d55d9f3a0 [ 7.990156] R10: ffff8c5d55cb30c0 R11: 0000000000000009 R12: ffff8c5d55fcf800 [ 7.990156] R13: ffff8c5d55cb30c0 R14: ffff8c5d56989cc0 R15: ffff8c5d56989cc0 [ 7.990158] FS: 0000000000000000(0000) GS:ffff8c5d8e480000(0000) knlGS:0000000000000000 [ 8.047193] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.052970] CR2: 0000000000000078 CR3: 0000000856500005 CR4: 0000000000760ee0 [ 8.060137] PKRU: 55555554 [ 8.062867] Call Trace: [ 8.065361] intel_digital_connector_atomic_check+0x53/0x130 [i915] [ 8.071703] intel_dp_mst_atomic_check+0x5b/0x200 [i915] [ 8.077074] drm_atomic_helper_check_modeset+0x1db/0x790 [drm_kms_helper] [ 8.083942] intel_atomic_check+0x92/0xc50 [i915] [ 8.088705] ? drm_plane_check_pixel_format+0x4f/0xb0 [drm] [ 8.094345] ? drm_atomic_plane_check+0x7a/0x3a0 [drm] [ 8.099548] drm_atomic_check_only+0x2b1/0x450 [drm] [ 8.104573] drm_atomic_commit+0x18/0x50 [drm] [ 8.109070] drm_client_modeset_commit_atomic+0x1c9/0x200 [drm] [ 8.115056] drm_client_modeset_commit_force+0x55/0x160 [drm] [ 8.120866] drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xb0 [drm_kms_helper] [ 8.128415] drm_fb_helper_set_par+0x34/0x50 [drm_kms_helper] [ 8.134225] drm_fb_helper_hotplug_event.part.0+0xb4/0xe0 [drm_kms_helper] [ 8.141150] drm_fb_helper_hotplug_event+0x1c/0x30 [drm_kms_helper] [ 8.147481] intel_fbdev_output_poll_changed+0x6f/0xa0 [i915] [ 8.153287] drm_kms_helper_hotplug_event+0x2c/0x40 [drm_kms_helper] [ 8.159709] output_poll_execute+0x1aa/0x1c0 [drm_kms_helper] [ 8.165506] process_one_work+0x1e8/0x3b0 [ 8.169561] worker_thread+0x4d/0x400 [ 8.173249] kthread+0x104/0x140 [ 8.176515] ? process_one_work+0x3b0/0x3b0 [ 8.180726] ? kthread_park+0x90/0x90 [ 8.184416] ret_from_fork+0x1f/0x40 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2361 References: https://gitlab.freedesktop.org/drm/intel/-/issues/2486 Reported-by: William Tseng <[email protected]> Reported-by: Cooper Chiou <[email protected]> Cc: <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Anshuman Gupta <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-28scripts: kernel-doc: split typedef complex regexMauro Carvalho Chehab1-5/+9
The typedef regex for function prototypes are very complex. Split them into 3 separate regex and then join them using qr. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Link: https://lore.kernel.org/r/3a4af999a0d62d4ab9dfae1cdefdfcad93383356.1603792384.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <[email protected]>
2020-10-28scripts: kernel-doc: fix typedef parsingMauro Carvalho Chehab1-2/+3
The include/linux/genalloc.h file defined this typedef: typedef unsigned long (*genpool_algo_t)(unsigned long *map,unsigned long size,unsigned long start,unsigned int nr,void *data, struct gen_pool *pool, unsigned long start_addr); Because it has a type composite of two words (unsigned long), the parser gets the typedef name wrong: .. c:macro:: long **Typedef**: Allocation callback function type definition Fix the regex in order to accept composite types when defining a typedef for a function pointer. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Link: https://lore.kernel.org/r/328e8018041cc44f7a1684e57f8d111230761c4f.1603792384.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <[email protected]>
2020-10-28mtd: spi-nor: Fix address width on flash chips > 16MBBert Vermeulen1-3/+5
If a flash chip has more than 16MB capacity but its BFPT reports BFPT_DWORD1_ADDRESS_BYTES_3_OR_4, the spi-nor framework defaults to 3. The check in spi_nor_set_addr_width() doesn't catch it because addr_width did get set. This fixes that check. Fixes: f9acd7fa80be ("mtd: spi-nor: sfdp: default to addr_width of 3 for configurable widths") Signed-off-by: Bert Vermeulen <[email protected]> Signed-off-by: Vignesh Raghavendra <[email protected]> Reviewed-by: Tudor Ambarus <[email protected]> Reviewed-by: Pratyush Yadav <[email protected]> Reviewed-by: Joel Stanley <[email protected]> Reviewed-by: Cédric Le Goater <[email protected]> Tested-by: Joel Stanley <[email protected]> Tested-by: Cédric Le Goater <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-28docs: Makefile: honor V=0 for docs buildingMauro Carvalho Chehab1-0/+4
Reduce the number of displayed mesages when building the docs with V=0. Suggested-by: Stephen Rothwell <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Link: https://lore.kernel.org/r/478c114a2399b68a18de94ee5f98649304f3903b.1603796153.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <[email protected]>
2020-10-28mtd: spi-nor: Don't copy self-pointing struct aroundAlexander Sverdlin1-3/+2
spi_nor_parse_sfdp() modifies the passed structure so that it points to itself (params.erase_map.regions to params.erase_map.uniform_region). This makes it impossible to copy the local struct anywhere else. Therefore only use memcpy() in backup-restore scenario. The bug may show up like below: BUG: unable to handle page fault for address: ffffc90000b377f8 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 3500 Comm: flashcp Tainted: G O 5.4.53-... #1 ... RIP: 0010:spi_nor_erase+0x8e/0x5c0 Code: 64 24 18 89 db 4d 8b b5 d0 04 00 00 4c 89 64 24 18 4c 89 64 24 20 eb 12 a8 10 0f 85 59 02 00 00 49 83 c6 10 0f 84 4f 02 00 00 <49> 8b 06 48 89 c2 48 83 e2 c0 48 89 d1 49 03 4e 08 48 39 cb 73 d8 RSP: 0018:ffffc9000217fc48 EFLAGS: 00010206 RAX: 0000000000740000 RBX: 0000000000000000 RCX: 0000000000740000 RDX: ffff8884550c9980 RSI: ffff88844f9c0bc0 RDI: ffff88844ede7bb8 RBP: 0000000000740000 R08: ffffffff815bfbe0 R09: ffff88844f9c0bc0 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000217fc60 R13: ffff88844ede7818 R14: ffffc90000b377f8 R15: 0000000000000000 FS: 00007f4699780500(0000) GS:ffff88846ff00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc90000b377f8 CR3: 00000004538ee000 CR4: 0000000000340fe0 Call Trace: part_erase+0x27/0x50 mtdchar_ioctl+0x831/0xba0 ? filemap_map_pages+0x186/0x3d0 ? do_filp_open+0xad/0x110 ? _copy_to_user+0x22/0x30 ? cp_new_stat+0x150/0x180 mtdchar_unlocked_ioctl+0x2a/0x40 do_vfs_ioctl+0xa0/0x630 ? __do_sys_newfstat+0x3c/0x60 ksys_ioctl+0x70/0x80 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x6a/0x200 ? prepare_exit_to_usermode+0x50/0xd0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f46996b6817 Cc: [email protected] Fixes: c46872170a54 ("mtd: spi-nor: Move erase_map to 'struct spi_nor_flash_parameter'") Co-developed-by: Matija Glavinic Pecotic <[email protected]> Signed-off-by: Matija Glavinic Pecotic <[email protected]> Signed-off-by: Alexander Sverdlin <[email protected]> Signed-off-by: Vignesh Raghavendra <[email protected]> Tested-by: Baurzhan Ismagulov <[email protected]> Reviewed-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-28cpufreq: speedstep: remove unneeded semicolonTom Rix1-1/+1
A semicolon is not needed after a switch statement. Signed-off-by: Tom Rix <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-10-28ASoC: codecs: wcd9335: Set digital gain range correctlySrinivas Kandagatla1-1/+1
digital gain range is -84dB min to 40dB max, however this was not correctly specified in the range. Fix this by with correct range! Fixes: 8c4f021d806a ("ASoC: wcd9335: add basic controls") Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-28Merge tag 'stm32-dt-for-v5.10-fixes-1' of ↵Arnd Bergmann2-0/+32
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into arm/fixes STM32 DT fixes for v5.10, round 1 Highlights: ----------- -On STM32MP157 DK & ED boards: Add Vin supply description to avoid random kernel crash due to vref_ddr regulator issue. * tag 'stm32-dt-for-v5.10-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: ARM: dts: stm32: Describe Vin power supply on stm32mp157c-edx board ARM: dts: stm32: Describe Vin power supply on stm32mp15xx-dkx board Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2020-10-28ASoC: codecs: wcd934x: Set digital gain range correctlySrinivas Kandagatla1-1/+1
digital gain range is -84dB min to 40dB max, however this was not correctly specified in the range. Fix this by with correct range! Fixes: 1cde8b822332 ("ASoC: wcd934x: add basic controls") Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-28futex: Fix incorrect should_fail_futex() handlingMateusz Nosek1-1/+3
If should_futex_fail() returns true in futex_wake_pi(), then the 'ret' variable is set to -EFAULT and then immediately overwritten. So the failure injection is non-functional. Fix it by actually leaving the function and returning -EFAULT. The Fixes tag is kinda blury because the initial commit which introduced failure injection was already sloppy, but the below mentioned commit broke it completely. [ tglx: Massaged changelog ] Fixes: 6b4f4bc9cb22 ("locking/futex: Allow low-level atomic operations to return -EAGAIN") Signed-off-by: Mateusz Nosek <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-28module: use hidden visibility for weak symbol referencesArd Biesheuvel1-1/+1
Geert reports that commit be2881824ae9eb92 ("arm64/build: Assert for unwanted sections") results in build errors on arm64 for configurations that have CONFIG_MODULES disabled. The commit in question added ASSERT()s to the arm64 linker script to ensure that linker generated sections such as .got.plt etc are empty, but as it turns out, there are corner cases where the linker does emit content into those sections. More specifically, weak references to function symbols (which can remain unsatisfied, and can therefore not be emitted as relative references) will be emitted as GOT and PLT entries when linking the kernel in PIE mode (which is the case when CONFIG_RELOCATABLE is enabled, which is on by default). What happens is that code such as struct device *(*fn)(struct device *dev); struct device *iommu_device; fn = symbol_get(mdev_get_iommu_device); if (fn) { iommu_device = fn(dev); essentially gets converted into the following when CONFIG_MODULES is off: struct device *iommu_device; if (&mdev_get_iommu_device) { iommu_device = mdev_get_iommu_device(dev); where mdev_get_iommu_device is emitted as a weak symbol reference into the object file. The first reference is decorated with an ordinary ABS64 data relocation (which yields 0x0 if the reference remains unsatisfied). However, the indirect call is turned into a direct call covered by a R_AARCH64_CALL26 relocation, which is converted into a call via a PLT entry taking the target address from the associated GOT entry. Given that such GOT and PLT entries are unnecessary for fully linked binaries such as the kernel, let's give these weak symbol references hidden visibility, so that the linker knows that the weak reference via R_AARCH64_CALL26 can simply remain unsatisfied. Signed-off-by: Ard Biesheuvel <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Fangrui Song <[email protected]> Acked-by: Jessica Yu <[email protected]> Cc: Jessica Yu <[email protected]> Cc: Kees Cook <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Nick Desaulniers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-28ARM: dts: stm32: Describe Vin power supply on stm32mp157c-edx boardPascal Paillet1-0/+15
Add description for Vin power supply and for peripherals that are supplied by Vin. Signed-off-by: Pascal Paillet <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]>
2020-10-28ARM: dts: stm32: Describe Vin power supply on stm32mp15xx-dkx boardPascal Paillet1-0/+17
Add description for Vin power supply and for peripherals that are supplied by Vin. Signed-off-by: Pascal Paillet <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]>
2020-10-28arm64: efi: increase EFI PE/COFF header padding to 64 KBArd Biesheuvel1-1/+1
Commit 76085aff29f5 ("efi/libstub/arm64: align PE/COFF sections to segment alignment") increased the PE/COFF section alignment to match the minimum segment alignment of the kernel image, which ensures that the kernel does not need to be moved around in memory by the EFI stub if it was built as relocatable. However, the first PE/COFF section starts at _stext, which is only 4 KB aligned, and so the section layout is inconsistent. Existing EFI loaders seem to care little about this, but it is better to clean this up. So let's pad the header to 64 KB to match the PE/COFF section alignment. Fixes: 76085aff29f5 ("efi/libstub/arm64: align PE/COFF sections to segment alignment") Signed-off-by: Ard Biesheuvel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-28ata: sata_nv: Fix retrieving of active qcsSascha Hauer1-1/+1
ata_qc_complete_multiple() has to be called with the tags physically active, that is the hw tag is at bit 0. ap->qc_active has the same tag at bit ATA_TAG_INTERNAL instead, so call ata_qc_get_active() to fix that up. This is done in the vein of 8385d756e114 ("libata: Fix retrieving of active qcs"). Fixes: 28361c403683 ("libata: add extra internal command") Tested-by: Pali Rohár <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-10-28block: advance iov_iter on bio_add_hw_page failureNaohiro Aota1-4/+7
When the bio's size reaches max_append_sectors, bio_add_hw_page returns 0 then __bio_iov_append_get_pages returns -EINVAL. This is an expected result of building a small enough bio not to be split in the IO path. However, iov_iter is not advanced in this case, causing the same pages are filled for the bio again and again. Fix the case by properly advancing the iov_iter for already processed pages. Fixes: 0512a75b98f8 ("block: Introduce REQ_OP_ZONE_APPEND") Cc: [email protected] # 5.8+ Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-10-28arm64: vmlinux.lds: account for spurious empty .igot.plt sectionsArd Biesheuvel1-1/+1
Now that we started making the linker warn about orphan sections (input sections that are not explicitly consumed by an output section), some configurations produce the following warning: aarch64-linux-gnu-ld: warning: orphan section `.igot.plt' from `arch/arm64/kernel/head.o' being placed in section `.igot.plt' It could be any file that triggers this - head.o is simply the first input file in the link - and the resulting .igot.plt section never actually appears in vmlinux as it turns out to be empty. So let's add .igot.plt to our collection of input sections to disregard unless they are empty. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Jessica Yu <[email protected]> Cc: Kees Cook <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Nick Desaulniers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-28kselftest/arm64: Fix check_user_mem testVincenzo Frascino1-0/+4
The check_user_mem test reports the error below because the test plan is not declared correctly: # Planned tests != run tests (0 != 4) Fix the test adding the correct test plan declaration. Fixes: 4dafc08d0ba4 ("kselftest/arm64: Check mte tagged user address in kernel") Signed-off-by: Vincenzo Frascino <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Gabor Kertesz <[email protected]> Cc: Amit Daniel Kachhap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-28kselftest/arm64: Fix check_ksm_options testVincenzo Frascino1-0/+4
The check_ksm_options test reports the error below because the test plan is not declared correctly: # Planned tests != run tests (0 != 4) Fix the test adding the correct test plan declaration. Fixes: f981d8fa2646 ("kselftest/arm64: Verify KSM page merge for MTE pages") Signed-off-by: Vincenzo Frascino <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Gabor Kertesz <[email protected]> Cc: Amit Daniel Kachhap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-28kselftest/arm64: Fix check_mmap_options testVincenzo Frascino1-0/+4
The check_mmap_options test reports the error below because the test plan is not declared correctly: # Planned tests != run tests (0 != 22) Fix the test adding the correct test plan declaration. Fixes: 53ec81d23213 ("kselftest/arm64: Verify all different mmap MTE options") Signed-off-by: Vincenzo Frascino <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Gabor Kertesz <[email protected]> Cc: Amit Daniel Kachhap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-28kselftest/arm64: Fix check_child_memory testVincenzo Frascino1-0/+3
The check_child_memory test reports the error below because the test plan is not declared correctly: # Planned tests != run tests (0 != 12) Fix the test adding the correct test plan declaration. Fixes: dfe537cf4718 ("kselftest/arm64: Check forked child mte memory accessibility") Signed-off-by: Vincenzo Frascino <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Gabor Kertesz <[email protected]> Cc: Amit Daniel Kachhap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-28kselftest/arm64: Fix check_tags_inclusion testVincenzo Frascino1-0/+3
The check_tags_inclusion test reports the error below because the test plan is not declared correctly: # Planned tests != run tests (0 != 4) Fix the test adding the correct test plan declaration. Fixes: f3b2a26ca78d ("kselftest/arm64: Verify mte tag inclusion via prctl") Signed-off-by: Vincenzo Frascino <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Gabor Kertesz <[email protected]> Cc: Amit Daniel Kachhap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-28kselftest/arm64: Fix check_buffer_fill testVincenzo Frascino1-0/+3
The check_buffer_fill test reports the error below because the test plan is not declared correctly: # Planned tests != run tests (0 != 20) Fix the test adding the correct test plan declaration. Fixes: e9b60476bea0 ("kselftest/arm64: Add utilities and a test to validate mte memory") Signed-off-by: Vincenzo Frascino <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Gabor Kertesz <[email protected]> Cc: Amit Daniel Kachhap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-28arm64: avoid -Woverride-init warningArnd Bergmann2-3/+5
The icache_policy_str[] definition causes a warning when extra warning flags are enabled: arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field overwritten [-Woverride-init] 38 | [ICACHE_POLICY_VIPT] = "VIPT", | ^~~~~~ arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for 'icache_policy_str[2]') arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field overwritten [-Woverride-init] 39 | [ICACHE_POLICY_PIPT] = "PIPT", | ^~~~~~ arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for 'icache_policy_str[3]') arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field overwritten [-Woverride-init] 40 | [ICACHE_POLICY_VPIPT] = "VPIPT", | ^~~~~~~ arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for 'icache_policy_str[0]') There is no real need for the default initializer here, as printing a NULL string is harmless. Rewrite the logic to have an explicit reserved value for the only one that uses the default value. This partially reverts the commit that removed ICACHE_POLICY_AIVIVT. Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches") Signed-off-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-28ACPI: button: Drop no longer necessary Acer SW5-012 lid_init_state quirkHans de Goede1-13/+0
Commit 78a5b53e9fb4 ("Input: soc_button_array - work around DSDTs which modify the irqflags") adds a workaround for DSDTs with a _LID method which play tricks with the irqflags, assuming that the OS is using an irq-type of IRQ_TYPE_LEVEL_LOW. Now that this workaround is in place, we no longer need to disable the lid functionality on the Acer SW5-012. Fixes: 78a5b53e9fb4 ("Input: soc_button_array - work around DSDTs which modify the irqflags") Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-10-28RDMA/qedr: Fix memory leak in iWARP CMAlok Prasad1-0/+1
Fixes memory leak in iWARP CM Fixes: e411e0587e0d ("RDMA/qedr: Add iWARP connection management functions") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Kalderon <[email protected]> Signed-off-by: Igor Russkikh <[email protected]> Signed-off-by: Alok Prasad <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-10-28vt_ioctl: fix GIO_UNIMAP regressionJiri Slaby1-6/+5
In commit 5ba127878722, we shuffled with the check of 'perm'. But my brain somehow inverted the condition in 'do_unimap_ioctl' (I thought it is ||, not &&), so GIO_UNIMAP stopped working completely. Move the 'perm' checks back to do_unimap_ioctl and do them right again. In fact, this reverts this part of code to the pre-5ba127878722 state. Except 'perm' is now a bool. Fixes: 5ba127878722 ("vt_ioctl: move perm checks level up") Cc: [email protected] Reported-by: Fabian Vogt <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28vt: keyboard, extend func_buf_lock to readersJiri Slaby1-4/+13
Both read-side users of func_table/func_buf need locking. Without that, one can easily confuse the code by repeatedly setting altering strings like: while (1) for (a = 0; a < 2; a++) { struct kbsentry kbs = {}; strcpy((char *)kbs.kb_string, a ? ".\n" : "88888\n"); ioctl(fd, KDSKBSENT, &kbs); } When that program runs, one can get unexpected output by holding F1 (note the unxpected period on the last line): . 88888 .8888 So protect all accesses to 'func_table' (and func_buf) by preexisting 'func_buf_lock'. It is easy in 'k_fn' handler as 'puts_queue' is expected not to sleep. On the other hand, KDGKBSENT needs a local (atomic) copy of the string because copy_to_user can sleep. Use already allocated, but unused 'kbs->kb_string' for that purpose. Note that the program above needs at least CAP_SYS_TTY_CONFIG. This depends on the previous patch and on the func_buf_lock lock added in commit 46ca3f735f34 (tty/vt: fix write/write race in ioctl(KDSKBSENT) handler) in 5.2. Likely fixes CVE-2020-25656. Cc: <[email protected]> Reported-by: Minh Yuan <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28vt: keyboard, simplify vt_kdgkbsentJiri Slaby1-19/+9
Use 'strlen' of the string, add one for NUL terminator and simply do 'copy_to_user' instead of the explicit 'for' loop. This makes the KDGKBSENT case more compact. The only thing we need to take care about is NULL 'func_table[i]'. Use an empty string in that case. The original check for overflow could never trigger as the func_buf strings are always shorter or equal to 'struct kbsentry's. Cc: <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28tty: serial: fsl_lpuart: LS1021A has a FIFO size of 16 words, like LS1028AVladimir Oltean1-6/+7
Prior to the commit that this one fixes, the FIFO size was derived from the read-only register LPUARTx_FIFO[TXFIFOSIZE] using the following formula: TX FIFO size = 2 ^ (LPUARTx_FIFO[TXFIFOSIZE] - 1) The documentation for LS1021A is a mess. Under chapter 26.1.3 LS1021A LPUART module special consideration, it mentions TXFIFO_SZ and RXFIFO_SZ being equal to 4, and in the register description for LPUARTx_FIFO, it shows the out-of-reset value of TXFIFOSIZE and RXFIFOSIZE fields as "011", even though these registers read as "101" in reality. And when LPUART on LS1021A was working, the "101" value did correspond to "16 datawords", by applying the formula above, even though the documentation is wrong again (!!!!) and says that "101" means 64 datawords (hint: it doesn't). So the "new" formula created by commit f77ebb241ce0 has all the premises of being wrong for LS1021A, because it relied only on false data and no actual experimentation. Interestingly, in commit c2f448cff22a ("tty: serial: fsl_lpuart: add LS1028A support"), Michael Walle applied a workaround to this by manually setting the FIFO widths for LS1028A. It looks like the same values are used by LS1021A as well, in fact. When the driver thinks that it has a deeper FIFO than it really has, getty (user space) output gets truncated. Many thanks to Michael for pointing out where to look. Fixes: f77ebb241ce0 ("tty: serial: fsl_lpuart: correct the FIFO depth size") Suggested-by: Michael Walle <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by：Fugang Duan <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28tty: serial: 21285: fix lockup on openRussell King1-6/+6
Commit 293f89959483 ("tty: serial: 21285: stop using the unused[] variable from struct uart_port") introduced a bug which stops the transmit interrupt being disabled when there are no characters to transmit - disabling the transmit interrupt at the interrupt controller is the only way to stop an interrupt storm. If this interrupt is not disabled when there are no transmit characters, we end up with an interrupt storm which prevents the machine making forward progress. Fixes: 293f89959483 ("tty: serial: 21285: stop using the unused[] variable from struct uart_port") Signed-off-by: Russell King <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28USB: apple-mfi-fastcharge: don't probe unhandled devicesBastien Nocera1-5/+12
From: Bastien Nocera <[email protected]> Contrary to the comment above the id table, we didn't implement a match function. This meant that every single Apple device that was already plugged in to the computer would have its device driver reprobed when the apple-mfi-fastcharge driver was loaded, eg. the SD card reader could be reprobed when the apple-mfi-fastcharge after pivoting root during boot up and the module became available. Make sure that the driver probe isn't being run for unsupported devices by adding a match function that checks the product ID, in addition to the id_table checking the vendor ID. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1878347 Link: https://lore.kernel.org/linux-usb/CAE3RAxt0WhBEz8zkHrVO5RiyEOasayy1QUAjsv-pB0fAbY1GSw@mail.gmail.com/ Fixes: 249fa8217b84 ("USB: Add driver to control USB fast charge for iOS devices") Cc: <[email protected]> # 5.8 Cc: Greg Kroah-Hartman <[email protected]> Cc: Alan Stern <[email protected]> [m.v.b: Add Link and Reported-by tags to the commit message] Reported-by: Pany <[email protected]> Tested-by: Pan (Pany) YUAN <[email protected]> Tested-by: Bastien Nocera <[email protected]> Signed-off-by: Bastien Nocera <[email protected]> Signed-off-by: M. Vefa Bicakci <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28usbcore: Check both id_table and match() when both availableBastien Nocera3-12/+24
From: Bastien Nocera <[email protected]> When a USB device driver has both an id_table and a match() function, make sure to check both to find a match, first matching the id_table, then checking the match() function. This makes it possible to have module autoloading done through the id_table when devices are plugged in, before checking for further device eligibility in the match() function. Cc: <[email protected]> # 5.8 Cc: Greg Kroah-Hartman <[email protected]> Cc: Alan Stern <[email protected]> Co-developed-by: M. Vefa Bicakci <[email protected]> Tested-by: Bastien Nocera <[email protected]> Signed-off-by: Bastien Nocera <[email protected]> Signed-off-by: M. Vefa Bicakci <[email protected]> Tested-by: Pan (Pany) YUAN <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28usb: host: ehci-tegra: Fix error handling in tegra_ehci_probe()Tang Bin1-2/+2
If the function platform_get_irq() failed, the negative value returned will not be detected here. So fix error handling in tegra_ehci_probe(). Fixes: 79ad3b5add4a ("usb: host: Add EHCI driver for NVIDIA Tegra SoCs") Acked-by: Alan Stern <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Tang Bin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28usb: typec: stusb160x: fix an IS_ERR() vs NULL check in probeDan Carpenter1-2/+2
The typec_register_port() function doesn't return NULL, it returns error pointers. Fixes: da0cb6310094 ("usb: typec: add support for STUSB160x Type-C controller family") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/20201023114017.GE18329@kadam Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28usb: typec: tcpm: reset hard_reset_count for any disconnectLi Jun1-3/+3
Current tcpm_detach() only reset hard_reset_count if port->attached is true, this may cause this counter clear is missed if the CC disconnect event is generated after tcpm_port_reset() is done by other events, e.g. VBUS off comes first before CC disconect for a power sink, in that case the first tcpm_detach() will only clear port->attached flag but leave hard_reset_count there because tcpm_port_is_disconnected() is still false, then later tcpm_detach() by CC disconnect will directly return due to port->attached is cleared, finally this will result tcpm will not try hard reset or error recovery for later attach. ChiYuan reported this issue on his platform with below tcpm trace: After power sink session setup after hard reset 2 times, detach from the power source and then attach: [ 4848.046358] VBUS off [ 4848.046384] state change SNK_READY -> SNK_UNATTACHED [ 4848.050908] Setting voltage/current limit 0 mV 0 mA [ 4848.050936] polarity 0 [ 4848.052593] Requesting mux state 0, usb-role 0, orientation 0 [ 4848.053222] Start toggling [ 4848.086500] state change SNK_UNATTACHED -> TOGGLING [ 4848.089983] CC1: 0 -> 0, CC2: 3 -> 3 [state TOGGLING, polarity 0, connected] [ 4848.089993] state change TOGGLING -> SNK_ATTACH_WAIT [ 4848.090031] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @200 ms [ 4848.141162] CC1: 0 -> 0, CC2: 3 -> 0 [state SNK_ATTACH_WAIT, polarity 0, disconnected] [ 4848.141170] state change SNK_ATTACH_WAIT -> SNK_ATTACH_WAIT [ 4848.141184] pending state change SNK_ATTACH_WAIT -> SNK_UNATTACHED @20 ms [ 4848.163156] state change SNK_ATTACH_WAIT -> SNK_UNATTACHED [delayed 20 ms] [ 4848.163162] Start toggling [ 4848.216918] CC1: 0 -> 0, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected] [ 4848.216954] state change TOGGLING -> SNK_ATTACH_WAIT [ 4848.217080] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @200 ms [ 4848.231771] CC1: 0 -> 0, CC2: 3 -> 0 [state SNK_ATTACH_WAIT, polarity 0, disconnected] [ 4848.231800] state change SNK_ATTACH_WAIT -> SNK_ATTACH_WAIT [ 4848.231857] pending state change SNK_ATTACH_WAIT -> SNK_UNATTACHED @20 ms [ 4848.256022] state change SNK_ATTACH_WAIT -> SNK_UNATTACHED [delayed20 ms] [ 4848.256049] Start toggling [ 4848.871148] VBUS on [ 4848.885324] CC1: 0 -> 0, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected] [ 4848.885372] state change TOGGLING -> SNK_ATTACH_WAIT [ 4848.885548] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @200 ms [ 4849.088240] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed200 ms] [ 4849.088284] state change SNK_DEBOUNCED -> SNK_ATTACHED [ 4849.088291] polarity 1 [ 4849.088769] Requesting mux state 1, usb-role 2, orientation 2 [ 4849.088895] state change SNK_ATTACHED -> SNK_STARTUP [ 4849.088907] state change SNK_STARTUP -> SNK_DISCOVERY [ 4849.088915] Setting voltage/current limit 5000 mV 0 mA [ 4849.088927] vbus=0 charge:=1 [ 4849.090505] state change SNK_DISCOVERY -> SNK_WAIT_CAPABILITIES [ 4849.090828] pending state change SNK_WAIT_CAPABILITIES -> SNK_READY @240 ms [ 4849.335878] state change SNK_WAIT_CAPABILITIES -> SNK_READY [delayed240 ms] this patch fix this issue by clear hard_reset_count at any cases of cc disconnect, í.e. don't check port->attached flag. Fixes: 4b4e02c83167 ("typec: tcpm: Move out of staging") Cc: [email protected] Reported-and-tested-by: ChiYuan Huang <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Signed-off-by: Li Jun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28usb: cdc-acm: fix cooldown mechanismJerome Brunet2-9/+6
Commit a4e7279cd1d1 ("cdc-acm: introduce a cool down") is causing regression if there is some USB error, such as -EPROTO. This has been reported on some samples of the Odroid-N2 using the Combee II Zibgee USB dongle. > struct acm *acm = container_of(work, struct acm, work) is incorrect in case of a delayed work and causes warnings, usually from the workqueue: > WARNING: CPU: 0 PID: 0 at kernel/workqueue.c:1474 __queue_work+0x480/0x528. When this happens, USB eventually stops working completely after a while. Also the ACM_ERROR_DELAY bit is never set, so the cooldown mechanism previously introduced cannot be triggered and acm_submit_read_urb() is never called. This changes makes the cdc-acm driver use a single delayed work, fixing the pointer arithmetic in acm_softint() and set the ACM_ERROR_DELAY when the cooldown mechanism appear to be needed. Fixes: a4e7279cd1d1 ("cdc-acm: introduce a cool down") Cc: Oliver Neukum <[email protected]> Reported-by: Pascal Vizeli <[email protected]> Acked-by: Oliver Neukum <[email protected]> Signed-off-by: Jerome Brunet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28usb: host: fsl-mph-dr-of: check return of dma_set_mask()Ran Wang1-3/+6
fsl_usb2_device_register() should stop init if dma_set_mask() return error. Fixes: cae058610465 ("drivers/usb/host: fsl: Set DMA_MASK of usb platform device") Reviewed-by: Peter Chen <[email protected]> Signed-off-by: Ran Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28usb: fix kernel-doc markupsMauro Carvalho Chehab5-5/+5
There is a common comment marked, instead, with kernel-doc notation. Also, some identifiers have different names between their prototypes and the kernel-doc markup. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Acked-by: Felipe Balbi <[email protected]> Link: https://lore.kernel.org/r/0b964be3884def04fcd20ea5c12cb90d0014871c.1603469755.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28RDMA: Add rdma_connect_locked()Jason Gunthorpe6-29/+48
There are two flows for handling RDMA_CM_EVENT_ROUTE_RESOLVED, either the handler triggers a completion and another thread does rdma_connect() or the handler directly calls rdma_connect(). In all cases rdma_connect() needs to hold the handler_mutex, but when handler's are invoked this is already held by the core code. This causes ULPs using the 2nd method to deadlock. Provide a rdma_connect_locked() and have all ULPs call it from their handlers. Link: https://lore.kernel.org/r/[email protected] Reported-and-tested-by: Guoqing Jiang <[email protected]> Fixes: 2a7cec538169 ("RDMA/cma: Fix locking for the RDMA_CM_CONNECT state") Acked-by: Santosh Shilimkar <[email protected]> Acked-by: Jack Wang <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Max Gurtovoy <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.