- 03 Jul, 2019 25 commits
-
-
Alastair D'Silva authored
If an OpenCAPI context is to be used directly by a kernel driver, there may not be a suitable mm to use. The patch makes the mm parameter to ocxl_context_attach optional. Signed-off-by:
Alastair D'Silva <alastair@d-silva.org> Acked-by:
Andrew Donnellan <ajd@linux.ibm.com> Acked-by:
Frederic Barrat <fbarrat@linux.ibm.com> Acked-by:
Nicholas Piggin <npiggin@gmail.com> Link: https://lore.kernel.org/r/20190620041203.12274-1-alastair@au1.ibm.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eddie James authored
SBE fifo operations should be allowed while the SBE is in any of the "IPL" states. Operations should succeed in this state. Fixes: 9f4a8a2d fsi/sbefifo: Add driver for the SBE FIFO Reviewed-by:
Joel Stanley <joel@jms.id.au> Tested-by:
Alistair Popple <alistair@popple.id.au> Signed-off-by:
Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/1561575415-3282-1-git-send-email-eajames@linux.ibm.comSigned-off-by:
-
Suzuki K Poulose authored
Based on the following report from Smatch, fix the potential NULL pointer dereference check. The patch 743256e214e8: "coresight: tmc: Clean up device specific data" from May 22, 2019, leads to the following Smatch complaint: drivers/hwtracing/coresight/coresight-tmc-etr.c:625 tmc_etr_free_flat_buf() warn: variable dereferenced before check 'flat_buf' (see line 623) drivers/hwtracing/coresight/coresight-tmc-etr.c 622 struct etr_flat_buf *flat_buf = etr_buf->private; 623 struct device *real_dev = flat_buf->dev->parent; ^^^^^^^^^^ The patch introduces a new NULL check 624 625 if (flat_buf && flat_buf->daddr) ^^^^^^^^ but the existing code assumed it can be NULL. 626 dma_free_coherent(real_dev, flat_buf->size, 627 flat_buf->vaddr, flat_buf->daddr); Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20190621175205.24551-3-mathieu.poirier@linaro.orgSigned-off-by:
-
Suzuki K Poulose authored
Based on the following report from Smatch tool, make sure we have a valid drvdata before we dereference it to find the real dev. The patch 21d26b905c05: "coresight: etm: Clean up device specific data" from May 22, 2019, leads to the following Smatch complaint: ./drivers/hwtracing/coresight/coresight-etm3x.c:460 etm_get_trace_id() warn: variable dereferenced before check 'drvdata' (see line 458) ./drivers/hwtracing/coresight/coresight-etm3x.c 457 int trace_id = -1; 458 struct device *etm_dev = drvdata->csdev->dev.parent; ^^^^^^^^^ New dereference 459 460 if (!drvdata) ^^^^^^^^ Checked too late. Delete the check? 461 goto out; 462 Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: -
Dan Carpenter authored
The "drvdata->atclk" clock is optional, but if it gets set to an error pointer then we're accidentally return an uninitialized variable instead of success. Fixes: 78e6427b ("coresight: funnel: Support static funnel") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Suzuki K Poulose authored
During a perf session we try to allocate buffers on the "node" associated with the CPU the event is bound to. If it is not bound to a CPU, we use the current CPU node, using smp_processor_id(). However this is unsafe in a pre-emptible context and could generate the splats as below : BUG: using smp_processor_id() in preemptible [00000000] code: perf/2544 Use NUMA_NO_NODE hint instead of using the current node for events not bound to CPUs. Fixes: 2997aa40 ("coresight: etb10: implementing AUX API") Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
During a perf session we try to allocate buffers on the "node" associated with the CPU the event is bound to. If it is not bound to a CPU, we use the current CPU node, using smp_processor_id(). However this is unsafe in a pre-emptible context and could generate the splats as below : BUG: using smp_processor_id() in preemptible [00000000] code: perf/2544 caller is tmc_alloc_etf_buffer+0x5c/0x60 CPU: 2 PID: 2544 Comm: perf Not tainted 5.1.0-rc6-147786-g116841e #344 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019 Call trace: dump_backtrace+0x0/0x150 show_stack+0x14/0x20 dump_stack+0x9c/0xc4 debug_smp_processor_id+0x10c/0x110 tmc_alloc_etf_buffer+0x5c/0x60 etm_setup_aux+0x1c4/0x230 rb_alloc_aux+0x1b8/0x2b8 perf_mmap+0x35c/0x478 mmap_region+0x34c/0x4f0 do_mmap+0x2d8/0x418 vm_mmap_pgoff+0xd0/0xf8 ksys_mmap_pgoff+0x88/0xf8 __arm64_sys_mmap+0x28/0x38 el0_svc_handler+0xd8/0x138 el0_svc+0x8/0xc Use NUMA_NO_NODE hint instead of using the current node for events not bound to CPUs. Fixes: 2e499bbc ("coresight: tmc: implementing TMC-ETF AUX space API") Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
During a perf session we try to allocate buffers on the "node" associated with the CPU the event is bound to. If it is not bound to a CPU, we use the current CPU node, using smp_processor_id(). However this is unsafe in a pre-emptible context and could generate the splats as below : BUG: using smp_processor_id() in preemptible [00000000] code: perf/1743 caller is tmc_alloc_etr_buffer+0x1bc/0x1f0 CPU: 1 PID: 1743 Comm: perf Not tainted 5.1.0-rc6-147786-g116841e #344 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019 Call trace: dump_backtrace+0x0/0x150 show_stack+0x14/0x20 dump_stack+0x9c/0xc4 debug_smp_processor_id+0x10c/0x110 tmc_alloc_etr_buffer+0x1bc/0x1f0 etm_setup_aux+0x1c4/0x230 rb_alloc_aux+0x1b8/0x2b8 perf_mmap+0x35c/0x478 mmap_region+0x34c/0x4f0 do_mmap+0x2d8/0x418 vm_mmap_pgoff+0xd0/0xf8 ksys_mmap_pgoff+0x88/0xf8 __arm64_sys_mmap+0x28/0x38 el0_svc_handler+0xd8/0x138 el0_svc+0x8/0xc Use NUMA_NO_NODE hint instead of using the current node for events not bound to CPUs. Fixes: 22f429f1 ("coresight: etm-perf: Add support for ETR backend") Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
During a perf session we try to allocate buffers on the "node" associated with the CPU the event is bound to. If it's not bound to a CPU, we use the current CPU node, using smp_processor_id(). However this is unsafe in a pre-emptible context and could generate the splats as below : BUG: using smp_processor_id() in preemptible [00000000] code: perf/1743 caller is alloc_etr_buf.isra.6+0x80/0xa0 CPU: 1 PID: 1743 Comm: perf Not tainted 5.1.0-rc6-147786-g116841e #344 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019 Call trace: dump_backtrace+0x0/0x150 show_stack+0x14/0x20 dump_stack+0x9c/0xc4 debug_smp_processor_id+0x10c/0x110 alloc_etr_buf.isra.6+0x80/0xa0 tmc_alloc_etr_buffer+0x12c/0x1f0 etm_setup_aux+0x1c4/0x230 rb_alloc_aux+0x1b8/0x2b8 perf_mmap+0x35c/0x478 mmap_region+0x34c/0x4f0 do_mmap+0x2d8/0x418 vm_mmap_pgoff+0xd0/0xf8 ksys_mmap_pgoff+0x88/0xf8 __arm64_sys_mmap+0x28/0x38 el0_svc_handler+0xd8/0x138 el0_svc+0x8/0xc Use NUMA_NO_NODE hint instead of using the current node for events not bound to CPUs. Fixes: 855ab61c ("coresight: tmc-etr: Refactor function tmc_etr_setup_perf_buf()") Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Mauro Carvalho Chehab authored
Those files are also text files. Convert them to ReST and add to the misc-files index.rst. Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Link: https://lore.kernel.org/r/b7dc829809673bd8cffe0e7bbe9c9308681c6fe2.1561756511.git.mchehab+samsung@kernel.orgSigned-off-by:
-
Wu Hao authored
Current driver checks if input bitstream file size is aligned or not per PR data width (default 32bits). It requires one additional step for end user when they generate the bitstream file, padding extra zeros to bitstream file to align its size per PR data width, but they don't have to as hardware will drop extra padding bytes automatically. In order to simplify the user steps, this patch aligns PR buffer size per PR data width in driver, to allow user to pass unaligned size bitstream files to driver. Signed-off-by:
Xu Yilun <yilun.xu@intel.com> Signed-off-by:
Wu Hao <hao.wu@intel.com> Acked-by:
Alan Tull <atull@kernel.org> Acked-by:
Moritz Fischer <mdf@kernel.org> Signed-off-by:
-
Wu Hao authored
This patch removes copy_to_user() code in partial reconfiguration ioctl, as it's useless as user never needs to read the data structure after ioctl. Signed-off-by:
-
Wu Hao authored
FME_PR_INTFC_ID is used as compat_id for fpga manager and region, but high 64 bits and low 64 bits of the compat_id are swapped by mistake. This patch fixes this problem by fixing register address. Signed-off-by:
-
Alexander Shishkin authored
In multi-window mode, the read iterator is supposed to start from the window with the oldest data, which is, chronologically, the next window after the one with the newest data. This, however, fails to take into account the potentially empty windows, so in short trace sessions it's possible to have a lot of zeroes read from the character device first. Fix this by skipping over the empty windows in initialization of the read iterator. Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20190627125152.54905-5-alexander.shishkin@linux.intel.comSigned-off-by:
-
Alexander Shishkin authored
To allow the use of externally allocated SG tables further down the line, change the code to reference the table via a pointer and make it point to the locally allocated table by default. Signed-off-by:
-
Alexander Shishkin authored
Now that the MSU is using scatterlist, we can support multipage blocks. At the moment, the code assumes that all blocks are page-sized, but in larger buffers it may make sense to chunk together larger blocks of memory. One place where one-to-many relationship needs to be handled is the MSU buffer's mmap path. Get rid of the implicit assumption that all blocks are page-sized. Signed-off-by:
-
Alexander Shishkin authored
This adds Ice Lake NNPI support to the Intel(R) Trace Hub. Signed-off-by:
-
Alexander Shishkin authored
Commit 4e0eaf23 ("intel_th: msu: Fix single mode with IOMMU") switched the single mode code to use dma mapping pages obtained from the page allocator, but with IOMMU disabled, that may lead to using SWIOTLB bounce buffers and without additional sync'ing, produces empty trace buffers. Fix this by using a DMA32 GFP flag to the page allocation in single mode, as the device supports full 32-bit DMA addressing. Signed-off-by:
Ammy Yi <ammy.yi@intel.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20190621161930.60785-4-alexander.shishkin@linux.intel.comSigned-off-by:
-
YueHaibing authored
Commit aad14ad3 ("intel_th: msu: Add current window tracking") added the following gcc warning: > drivers/hwtracing/intel_th/msu.c: In function msc_win_switch: > drivers/hwtracing/intel_th/msu.c:1389:21: warning: variable last set but > not used [-Wunused-but-set-variable] Fix it by removing the variable. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Fixes: aad14ad3 ("intel_th: msu: Add current window tracking") Reviewed-by:
-
Shaokun Zhang authored
Commit ba39bd83 ("intel_th: msu: Switch over to scatterlist") introduced the following warnings on non-x86 architectures, as a result of reordering the multi mode buffer allocation sequence: > drivers/hwtracing/intel_th/msu.c: In function ‘msc_buffer_win_alloc’: > drivers/hwtracing/intel_th/msu.c:783:21: warning: unused variable ‘i’ > [-Wunused-variable] > int ret = -ENOMEM, i; > ^ > drivers/hwtracing/intel_th/msu.c: In function ‘msc_buffer_win_free’: > drivers/hwtracing/intel_th/msu.c:863:6: warning: unused variable ‘i’ > [-Wunused-variable] > int i; > ^ Fix this compiler warning by factoring out set_memory sequences and making them x86-only. Suggested-by:
Shaokun Zhang <zhangshaokun@hisilicon.com> Fixes: ba39bd83 ("intel_th: msu: Switch over to scatterlist") Reviewed-by:
-
Linus Walleij authored
The FSA9480 has a new driver more appropriately located in the drivers/extcon subsystem. It is also more complete and includes device tree support. Delete the old misc driver. Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by:
Pawe Chmiel <pawel.mikolaj.chmiel@gmail.com> Link: https://lore.kernel.org/r/20190630140302.16245-1-linus.walleij@linaro.orgSigned-off-by:
-
Greg Kroah-Hartman authored
Merge tag 'fsi-for-5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/fsi into char-misc-next Joel writes: FSI changes for 5.3 - Add MAINTAINERS entry. There is now a git tree and a mailing list/patchwork for collecting FSI patches - Bug fix for error driver registration error paths - Correction for the OCC hwmon driver to meet the spec * tag 'fsi-for-5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/fsi: fsi/core: Fix error paths on CFAM init OCC: FSI and hwmon: Add sequence numbering MAINTAINERS: Add FSI subsystem
-
Jeremy Kerr authored
Change d1dcd678 re-worked the struct fsi_slave initialisation in fsi_slave_init, but introduced a few inconsitencies: the slave->dev is now registered through cdev_device_add, but we may kfree() the device out from underneath the cdev registration. We may also leave an IDA allocated. This change fixes the error paths, so that we kfree() only before the device is registered with the core code. We also move the smode write to before we start creating proper devices, as it's the most likely to fail. We also remove the IDA-allocated minor on error, and properly clean up the of_node. Fixes: d1dcd678 ("fsi: Add cfam char devices") Reported-by:
Lei YU <mine260309@gmail.com> Tested-by:
John Wang <wangzqbj@inspur.com> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org> Signed-off-by:
-
Eddie James authored
Sequence numbering of the commands submitted to the OCC is required by the OCC interface specification. Add sequence numbering and check for the correct sequence number on the response. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
-
Joel Stanley authored
The subsystem was merged some time ago but we did not have a maintainers entry. The mailing list exists to allow our patchwork to slurp up the patches. The tree will be co-maintained by myself and Jeremy. Acked-by:
-
- 01 Jul, 2019 2 commits
-
-
Greg Kroah-Hartman authored
Merge tag 'extcon-next-for-5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-next Chanwoo writes: Update extcon for 5.3 Detailed description for this pull request: 1. Add new extcon-fsa9480 extcon provider driver - It is extcon provide driver for Fairchild Semiconductor FSA9480 microUSB switch and accessory detector chip which detects the kind of external connector like usb, charger, audio, video and so on. 2. - Add the exception handling code for extcon-arizona.c when using the regmap interface. * tag 'extcon-next-for-5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon: extcon: fsa9480: Fix Kconfig warning and build errors extcon: Add fsa9480 extcon driver dt-bindings: extcon: Add support for fsa9480 switch extcon: arizona: Correct error handling on regmap_update_bits_check
-
Todd Kjos authored
The buffer copy functions assumed the caller would ensure correct alignment and that the memory to be copied was completely within the binder buffer. There have been a few cases discovered by syzkallar where a malformed transaction created by a user could violated the assumptions and resulted in a BUG_ON. The fix is to remove the BUG_ON and always return the error to be handled appropriately by the caller. Acked-by:
Martijn Coenen <maco@android.com> Reported-by: syzbot+3ae18325f96190606754@syzkaller.appspotmail.com Fixes: bde4a19f ("binder: use userspace pointer as base of buffer space") Suggested-by:
Todd Kjos <tkjos@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
- 26 Jun, 2019 7 commits
-
-
Bryan O'Donoghue authored
Add compatible for i.MX8MM as per arch/arm64/boot/dts/freescale/imx8mm.dtsi Signed-off-by:
Bryan O'Donoghue <pure.logic@nexus-software.ie> Cc: Rob Herring <robh@kernel.org> Reviewed-by:
Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
-
Leonard Crestez authored
According to NXP Reference Manuals and uboot/atf sources the OCOTP block on imx8m behaves more like imx6 than imx7. - Fuses can be read/written 32bits at a time (no imx7-like banking) - The OCOTP_HW_OCOTP_TIMING register is like imx6 not imx7 Since nvmem doesn't support uboot-style "sense" and "override" this issue only affected "write" which is very rarely used. Fixes: 163c0dbd0cb1 ("nvmem: imx-ocotp: add support for imx8mq") Signed-off-by:Peng Fan <peng.fan@nxp.com> Signed-off-by:
-
Bryan O'Donoghue authored
This patch adds support to burn the fuses on the i.MX8MM. https://www.nxp.com/webapp/Download?colCode=IMX8MMRM The i.MX8MM is similar to i.MX6 processors in terms of addressing and clock setup. The documentation specifies 60 discreet OTP registers but, the fusemap address space encompasses up to 256 registers. We map the entire putative 256 OTP registers. Signed-off-by:
-
Bryan O'Donoghue authored
The RELAX field of the OCOTP block is turning out as a zero on i.MX8MM. This messes up the subsequent re-load of the fuse shadow registers. After some discussion with people @ NXP its clear we have missed a trick here in Linux. The OCOTP fuse programming time has a physical minimum 'burn time' that is not related to the ipg_clk. We need to define the RELAX, STROBE_READ and STROBE_PROG fields in terms of desired timings to allow for the burn-in to safely complete. Right now only the RELAX field is calculated in terms of an absolute time and we are ending up with a value of zero. This patch inherits the u-boot timings for the OCOTP_TIMING calculation on the i.MX6 and i.MX8. Those timings are known to work and critically specify values such as STROBE_PROG as a minimum timing. Fixes: 0642bac7 ("nvmem: imx-ocotp: add write support") Signed-off-by:
-
Bryan O'Donoghue authored
The i.MX6 and i.MX8 both have a bit-field spanning bits 27:22 called the WAIT field. The WAIT field according to the documentation for both parts "specifies time interval between auto read and write access in one time program. It is given in number of ipg_clk periods." This patch ensures that the relevant field is read and written back to the timing register. Fixes: 0642bac7 ("nvmem: imx-ocotp: add write support") Signed-off-by:
-
Bryan O'Donoghue authored
i.MX6 defines OCOTP_CTRLn:ADDR as seven bit address-field with a one bit RSVD0 field, i.MX7 defines OCOTP_CTRLn:ADDR as a four bit address-field with a four bit RSVD0 field. i.MX8 defines the OCOTP_CTRLn:ADDR bit-field as a full range eight bits. i.MX6 and i.MX7 should return zero for their respective RSVD0 bits and ignore a write-back of zero where i.MX8 will make use of the full range. This patch expands the bit-field definition for all users to eight bits, which is safe due to RSVD0 being a no-op for the i.MX6 and i.MX7. Signed-off-by:
-
Randy Dunlap authored
Fix Kconfig dependency warning and subsequent build errors caused by the Kconfig entry for EXTCON-FSA9480. It should not select REGMAP_I2C unless I2C is already set/enabled. WARNING: unmet direct dependencies detected for REGMAP_I2C Depends on [n]: I2C [=n] Selected by [y]: - EXTCON_FSA9480 [=y] && EXTCON [=y] && INPUT [=y] Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> [cw00.choi: adjust the patch title and remove the long warning messages] Signed-off-by:
-
- 23 Jun, 2019 2 commits
-
-
Greg Kroah-Hartman authored
We need the char-misc fixes in here as well. Signed-off-by: -
Kees Cook authored
This adds an x86-specific test for pinned cr4 bits. A successful test will validate pinning and check the ROP-style call-middle-of-function defense, if needed. For example, in the case of native_write_cr4() looking like this: ffffffff8171bce0 <native_write_cr4>: ffffffff8171bce0: 48 8b 35 79 46 f2 00 mov 0xf24679(%rip),%rsi ffffffff8171bce7: 48 09 f7 or %rsi,%rdi ffffffff8171bcea: 0f 22 e7 mov %rdi,%cr4 ... ffffffff8171bd5a: c3 retq The UNSET_SMEP test will jump to ffffffff8171bcea (the mov to cr4) instead of ffffffff8171bce0 (native_write_cr4() entry) to simulate a direct-call bypass attempt. Expected successful results: # echo UNSET_SMEP > /sys/kernel/debug/provoke-crash/DIRECT # dmesg [ 79.594433] lkdtm: Performing direct entry UNSET_SMEP [ 79.596459] lkdtm: trying to clear SMEP normally [ 79.598406] lkdtm: ok: SMEP did not get cleared [ 79.599981] lkdtm: trying to clear SMEP with call gadget [ 79.601810] ------------[ cut here ]------------ [ 79.603421] Attempt to unpin cr4 bits: 100000; bypass attack?! ... [ 79.650170] ---[ end trace 2452ca0f6126242e ]--- [ 79.650937] lkdtm: ok: SMEP removal was reverted Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
- 22 Jun, 2019 4 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommuLinus Torvalds authored
Pull iommu fix from Joerg Roedel: "Revert a commit from the previous pile of fixes which causes new lockdep splats. It is better to revert it for now and work on a better and more well tested fix" * tag 'iommu-fix-v5.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: Revert "iommu/vt-d: Fix lock inversion between iommu->lock and device_domain_lock"
-
Peter Xu authored
This reverts commit 7560cc3c. With 5.2.0-rc5 I can easily trigger this with lockdep and iommu=pt: ====================================================== WARNING: possible circular locking dependency detected 5.2.0-rc5 #78 Not tainted ------------------------------------------------------ swapper/0/1 is trying to acquire lock: 00000000ea2b3beb (&(&iommu->lock)->rlock){+.+.}, at: domain_context_mapping_one+0xa5/0x4e0 but task is already holding lock: 00000000a681907b (device_domain_lock){....}, at: domain_context_mapping_one+0x8d/0x4e0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (device_domain_lock){....}: _raw_spin_lock_irqsave+0x3c/0x50 dmar_insert_one_dev_info+0xbb/0x510 domain_add_dev_info+0x50/0x90 dev_prepare_static_identity_mapping+0x30/0x68 intel_iommu_init+0xddd/0x1422 pci_iommu_init+0x16/0x3f do_one_initcall+0x5d/0x2b4 kernel_init_freeable+0x218/0x2c1 kernel_init+0xa/0x100 ret_from_fork+0x3a/0x50 -> #0 (&(&iommu->lock)->rlock){+.+.}: lock_acquire+0x9e/0x170 _raw_spin_lock+0x25/0x30 domain_context_mapping_one+0xa5/0x4e0 pci_for_each_dma_alias+0x30/0x140 dmar_insert_one_dev_info+0x3b2/0x510 domain_add_dev_info+0x50/0x90 dev_prepare_static_identity_mapping+0x30/0x68 intel_iommu_init+0xddd/0x1422 pci_iommu_init+0x16/0x3f do_one_initcall+0x5d/0x2b4 kernel_init_freeable+0x218/0x2c1 kernel_init+0xa/0x100 ret_from_fork+0x3a/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(device_domain_lock); lock(&(&iommu->lock)->rlock); lock(device_domain_lock); lock(&(&iommu->lock)->rlock); *** DEADLOCK *** 2 locks held by swapper/0/1: #0: 00000000033eb13d (dmar_global_lock){++++}, at: intel_iommu_init+0x1e0/0x1422 #1: 00000000a681907b (device_domain_lock){....}, at: domain_context_mapping_one+0x8d/0x4e0 stack backtrace: CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc5 #78 Hardware name: LENOVO 20KGS35G01/20KGS35G01, BIOS N23ET50W (1.25 ) 06/25/2018 Call Trace: dump_stack+0x85/0xc0 print_circular_bug.cold.57+0x15c/0x195 __lock_acquire+0x152a/0x1710 lock_acquire+0x9e/0x170 ? domain_context_mapping_one+0xa5/0x4e0 _raw_spin_lock+0x25/0x30 ? domain_context_mapping_one+0xa5/0x4e0 domain_context_mapping_one+0xa5/0x4e0 ? domain_context_mapping_one+0x4e0/0x4e0 pci_for_each_dma_alias+0x30/0x140 dmar_insert_one_dev_info+0x3b2/0x510 domain_add_dev_info+0x50/0x90 dev_prepare_static_identity_mapping+0x30/0x68 intel_iommu_init+0xddd/0x1422 ? printk+0x58/0x6f ? lockdep_hardirqs_on+0xf0/0x180 ? do_early_param+0x8e/0x8e ? e820__memblock_setup+0x63/0x63 pci_iommu_init+0x16/0x3f do_one_initcall+0x5d/0x2b4 ? do_early_param+0x8e/0x8e ? rcu_read_lock_sched_held+0x55/0x60 ? do_early_param+0x8e/0x8e kernel_init_freeable+0x218/0x2c1 ? rest_init+0x230/0x230 kernel_init+0xa/0x100 ret_from_fork+0x3a/0x50 domain_context_mapping_one() is taking device_domain_lock first then iommu lock, while dmar_insert_one_dev_info() is doing the reverse. That should be introduced by commit: 7560cc3c ("iommu/vt-d: Fix lock inversion between iommu->lock and device_domain_lock", 2019-05-27) So far I still cannot figure out how the previous deadlock was triggered (I cannot find iommu lock taken before calling of iommu_flush_dev_iotlb()), however I'm pretty sure that that change should be incomplete at least because it does not fix all the places so we're still taking the locks in different orders, while reverting that commit is very clean to me so far that we should always take device_domain_lock first then the iommu lock. We can continue to try to find the real culprit mentioned in 7560cc3c, but for now I think we should revert it to fix current breakage. CC: Joerg Roedel <joro@8bytes.org> CC: Lu Baolu <baolu.lu@linux.intel.com> CC: dave.jiang@intel.com Signed-off-by:
Peter Xu <peterx@redhat.com> Tested-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Joerg Roedel <jroedel@suse.de>
-
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pciLinus Torvalds authored
Pull PCI fix from Bjorn Helgaas: "If an IOMMU is present, ignore the P2PDMA whitelist we added for v5.2 because we don't yet know how to support P2PDMA in that case (Logan Gunthorpe)" * tag 'pci-v5.2-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI/P2PDMA: Ignore root complex whitelist when an IOMMU is present
-
