aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-03-09x86/cpufeature: Add 5-level paging detectionKirill A. Shutemov1-1/+2
Look for 'la57' in /proc/cpuinfo to see if your machine supports 5-level paging. Signed-off-by: Kirill A. Shutemov <[email protected]> Acked-by: Michal Hocko <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-03-09md/raid1/10: fix potential deadlockShaohua Li2-2/+41
Neil Brown pointed out a potential deadlock in raid 10 code with bio_split/chain. The raid1 code could have the same issue, but recent barrier rework makes it less likely to happen. The deadlock happens in below sequence: 1. generic_make_request(bio), this will set current->bio_list 2. raid10_make_request will split bio to bio1 and bio2 3. __make_request(bio1), wait_barrer, add underlayer disk bio to current->bio_list 4. __make_request(bio2), wait_barrer If raise_barrier happens between 3 & 4, since wait_barrier runs at 3, raise_barrier waits for IO completion from 3. And since raise_barrier sets barrier, 4 waits for raise_barrier. But IO from 3 can't be dispatched because raid10_make_request() doesn't finished yet. The solution is to adjust the IO ordering. Quotes from Neil: " It is much safer to: if (need to split) { split = bio_split(bio, ...) bio_chain(...) make_request_fn(split); generic_make_request(bio); } else make_request_fn(mddev, bio); This way we first process the initial section of the bio (in 'split') which will queue some requests to the underlying devices. These requests will be queued in generic_make_request. Then we queue the remainder of the bio, which will be added to the end of the generic_make_request queue. Then we return. generic_make_request() will pop the lower-level device requests off the queue and handle them first. Then it will process the remainder of the original bio once the first section has been fully processed. " Note, this only happens in read path. In write path, the bio is flushed to underlaying disks either by blk flush (from schedule) or offladed to raid1/10d. It's queued in current->bio_list. Cc: Coly Li <[email protected]> Cc: [email protected] (v3.14+, only the raid10 part) Suggested-by: NeilBrown <[email protected]> Reviewed-by: Jack Wang <[email protected]> Signed-off-by: Shaohua Li <[email protected]>
2017-03-09md: don't impose the MD_SB_DISKS limit on arrays without metadata.NeilBrown1-4/+3
These arrays, created with "mdadm --build" don't benefit from a limit. The default will be used, which is '0' and is interpreted as "don't impose a limit". Reported-by: [email protected] Signed-off-by: NeilBrown <[email protected]> Signed-off-by: Shaohua Li <[email protected]>
2017-03-09md: move funcs from pers->resize to update_sizeGuoqing Jiang4-10/+6
raid1_resize and raid5_resize should also check the mddev->queue if run underneath dm-raid. And both set_capacity and revalidate_disk are used in pers->resize such as raid1, raid10 and raid5. So move them from personality file to common code. Reviewed-by: NeilBrown <[email protected]> Signed-off-by: Guoqing Jiang <[email protected]> Signed-off-by: Shaohua Li <[email protected]>
2017-03-09md-cluster: remove useless memset from gather_all_resync_infoGuoqing Jiang1-1/+0
This memset is not needed. The lvb is already zeroed because it was recently allocated by lockres_init, which uses kzalloc(), and read_resync_info() doesn't need it to be zero anyway. Reviewed-by: NeilBrown <[email protected]> Signed-off-by: Guoqing Jiang <[email protected]> Signed-off-by: Shaohua Li <[email protected]>
2017-03-09md-cluster: free md_cluster_info if node leave clusterGuoqing Jiang1-0/+1
To avoid memory leak, we need to free the cinfo which is allocated when node join cluster. Reviewed-by: NeilBrown <[email protected]> Signed-off-by: Guoqing Jiang <[email protected]> Signed-off-by: Shaohua Li <[email protected]>
2017-03-09md: delete dead codeShaohua Li2-14/+0
Nobody is using mddev_check_plugged(), so delete the dead code Signed-off-by: Shaohua Li <[email protected]>
2017-03-09md/raid10: submit bio directly to replacement diskShaohua Li1-3/+16
Commit 57c67df(md/raid10: submit IO from originating thread instead of md thread) submits bio directly for normal disks but not for replacement disks. There is no point we shouldn't do this for replacement disks. Cc: NeilBrown <[email protected]> Signed-off-by: Shaohua Li <[email protected]>
2017-03-09usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci controllersGuenter Roeck1-0/+2
Upstream commit 98d74f9ceaef ("xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers") fixes a problem with hot pluggable PCI xhci controllers which can result in excessive timeouts, to the point where the system reports a deadlock. The same problem is seen with hot pluggable xhci controllers using the xhci-plat driver, such as the driver used for Type-C ports on rk3399. Similar to hot-pluggable PCI controllers, the driver for this chip removes the xhci controller from the system when the Type-C cable is disconnected. The solution for PCI devices works just as well for non-PCI devices and avoids the problem. Signed-off-by: Guenter Roeck <[email protected]> Cc: stable <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-03-09usb: host: xhci-dbg: HCIVERSION should be a binary numberPeter Chen1-1/+1
According to xHCI spec, HCIVERSION containing a BCD encoding of the xHCI specification revision number, 0100h corresponds to xHCI version 1.0. Change "100" as "0x100". Cc: Lu Baolu <[email protected]> Cc: stable <[email protected]> Fixes: 04abb6de2825 ("xhci: Read and parse new xhci 1.1 capability register") Signed-off-by: Peter Chen <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-03-09usb: xhci: remove dummy extra_priv_size for size of xhci_hcd structChunfeng Yun2-2/+0
because hcd_priv_size is already size of xhci_hcd struct, extra_priv_size is not needed anymore for MTK and tegra drivers. Signed-off-by: Chunfeng Yun <[email protected]> Tested-by: Thierry Reding <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-03-09usb: xhci-mtk: check hcc_params after adding primary hcdChunfeng Yun1-3/+3
hcc_params is set in xhci_gen_setup() called from usb_add_hcd(), so checks the Maximum Primary Stream Array Size in the hcc_params register after adding primary hcd. Signed-off-by: Chunfeng Yun <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-03-09ahci: qoriq: correct the sata ecc setting errorYuantian Tang1-2/+4
Sata ecc is controlled by only 1 bit which is 24bit in big-endian in ecc register. So only setting 24bit to disable sata ecc prevents other bits from being overwritten in ecc register. Signed-off-by: Tang Yuantian <[email protected]> Signed-off-by: Tejun Heo <[email protected]>
2017-03-09Revert "i2c: copy device properties when using i2c_register_board_info()"Wolfram Sang1-10/+0
This reverts commit b0c1e95ab44feaad8831f2c06a3473c974003b49. It contains a flaw and the next version has more features added which makes me want to move it to the next cycle. Signed-off-by: Wolfram Sang <[email protected]>
2017-03-09Merge branch 'i2c-mux/for-current' of https://github.com/peda-r/i2c-mux into ↵Wolfram Sang1-0/+2
i2c/for-current
2017-03-09Revert "i2c: add missing of_node_put in i2c_mux_del_adapters"Wolfram Sang1-2/+0
This reverts commit 02dbfa5e5583523035f05636c614a0eca77f1aab. I grabbed the wrong version from the list and will pull the proper one from Peter Rosin's mux tree. Signed-off-by: Wolfram Sang <[email protected]>
2017-03-09i2c: exynos5: Avoid transaction timeouts due TRANSFER_DONE_AUTO not setJavier Martinez Canillas1-1/+2
After commit 7999eecb7e56 ("i2c: exynos5: fix arbitration lost handling"), some I2C transactions are failing because the TRANSFER_DONE_AUTO field is not set in the I2C_TRANS_STATUS register so the i2c->status value is left to -EINVAL causing the i2c->msg_complete completion to never be signaled. For example, when reading the time of an I2C rtc on an Exynos5800 machine: $ cat /sys/class/rtc/rtc0/time [ 25.924594] exynos5-hsi2c 12e10000.i2c: rx timeout [ 65.028365] max77686-rtc max77802-rtc: Fail to read time reg(-22) cat: /sys/class/rtc/rtc0/time: Invalid argument The Exynos5422 manual states clearly that most I2C_TRANS_STATUS reg bits (including TRANSFER_DONE_AUTO) are cleared after the register is read. So reading has side effects and should only be done if HSI2C_INT_I2C was set. Fixes: 7999eecb7e56 ("i2c: exynos5: fix arbitration lost handling") Signed-off-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2017-03-09Merge tag 'kvm-arm-for-4.11-rc2' of ↵Radim Krčmář12-79/+183
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm KVM/ARM updates for v4.11-rc2 vgic updates: - Honour disabling the ITS - Don't deadlock when deactivating own interrupts via MMIO - Correctly expose the lact of IRQ/FIQ bypass on GICv3 I/O virtualization: - Make KVM_CAP_NR_MEMSLOTS big enough for large guests with many PCIe devices General bug fixes: - Gracefully handle exception generated with syndroms that the host doesn't understand - Properly invalidate TLBs on VHE systems
2017-03-09KVM: nVMX: do not warn when MSR bitmap address is not backedRadim Krčmář1-3/+1
Before trying to do nested_get_page() in nested_vmx_merge_msr_bitmap(), we have already checked that the MSR bitmap address is valid (4k aligned and within physical limits). SDM doesn't specify what happens if the there is no memory mapped at the valid address, but Intel CPUs treat the situation as if the bitmap was configured to trap all MSRs. KVM already does that by returning false and a correct handling doesn't need the guest-trigerrable warning that was reported by syzkaller: (The warning was originally there to catch some possible bugs in nVMX.) ------------[ cut here ]------------ WARNING: CPU: 0 PID: 7832 at arch/x86/kvm/vmx.c:9709 nested_vmx_merge_msr_bitmap arch/x86/kvm/vmx.c:9709 [inline] WARNING: CPU: 0 PID: 7832 at arch/x86/kvm/vmx.c:9709 nested_get_vmcs12_pages+0xfb6/0x15c0 arch/x86/kvm/vmx.c:9640 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 7832 Comm: syz-executor1 Not tainted 4.10.0+ #229 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:15 [inline] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51 panic+0x1fb/0x412 kernel/panic.c:179 __warn+0x1c4/0x1e0 kernel/panic.c:540 warn_slowpath_null+0x2c/0x40 kernel/panic.c:583 nested_vmx_merge_msr_bitmap arch/x86/kvm/vmx.c:9709 [inline] nested_get_vmcs12_pages+0xfb6/0x15c0 arch/x86/kvm/vmx.c:9640 enter_vmx_non_root_mode arch/x86/kvm/vmx.c:10471 [inline] nested_vmx_run+0x6186/0xaab0 arch/x86/kvm/vmx.c:10561 handle_vmlaunch+0x1a/0x20 arch/x86/kvm/vmx.c:7312 vmx_handle_exit+0xfc0/0x3f00 arch/x86/kvm/vmx.c:8526 vcpu_enter_guest arch/x86/kvm/x86.c:6982 [inline] vcpu_run arch/x86/kvm/x86.c:7044 [inline] kvm_arch_vcpu_ioctl_run+0x1418/0x4840 arch/x86/kvm/x86.c:7205 kvm_vcpu_ioctl+0x673/0x1120 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2570 Reported-by: Dmitry Vyukov <[email protected]> Reviewed-by: Jim Mattson <[email protected]> [Jim Mattson explained the bare metal behavior: "I believe this behavior would be documented in the chipset data sheet rather than the SDM, since the chipset returns all 1s for an unclaimed read."] Signed-off-by: Radim Krčmář <[email protected]>
2017-03-09Merge branch 'pm-cpufreq-sched'Rafael J. Wysocki1-10/+9
* pm-cpufreq-sched: cpufreq: schedutil: Pass sg_policy to get_next_freq() cpufreq: schedutil: move cached_raw_freq to struct sugov_policy
2017-03-09Merge branch 'pm-cpufreq'Rafael J. Wysocki3-36/+35
* pm-cpufreq: cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy cpufreq: intel_pstate: Fix intel_pstate_verify_policy() cpufreq: intel_pstate: Fix global settings in active mode cpufreq: Add the "cpufreq.off=1" cmdline option cpufreq: intel_pstate: Avoid triggering cpu_frequency tracepoint unnecessarily cpufreq: intel_pstate: Fix intel_cpufreq_verify_policy() cpufreq: intel_pstate: Do not use performance_limits in passive mode
2017-03-09Merge tag 'irq-fixes-4.11-rc2' of ↵Thomas Gleixner2159-24786/+57596
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent Pull irqchip/irqdomain updates for 4.11-rc2 from Marc Zyngier - irqchip/crossbar: Some type tidying up - irqchip/gicv3-its: Workaround for a Qualcomm erratum - irqdomain: Compile for for systems that don't use CONFIG_IRQ_DOMAIN Fixed up minor conflict in the crossbar driver.
2017-03-09crypto: s5p-sss - Fix spinlock recursion on LRW(AES)Krzysztof Kozlowski1-45/+82
Running TCRYPT with LRW compiled causes spinlock recursion: testing speed of async lrw(aes) (lrw(ecb-aes-s5p)) encryption tcrypt: test 0 (256 bit key, 16 byte blocks): 19007 operations in 1 seconds (304112 bytes) tcrypt: test 1 (256 bit key, 64 byte blocks): 15753 operations in 1 seconds (1008192 bytes) tcrypt: test 2 (256 bit key, 256 byte blocks): 14293 operations in 1 seconds (3659008 bytes) tcrypt: test 3 (256 bit key, 1024 byte blocks): 11906 operations in 1 seconds (12191744 bytes) tcrypt: test 4 (256 bit key, 8192 byte blocks): BUG: spinlock recursion on CPU#1, irq/84-10830000/89  lock: 0xeea99a68, .magic: dead4ead, .owner: irq/84-10830000/89, .owner_cpu: 1 CPU: 1 PID: 89 Comm: irq/84-10830000 Not tainted 4.11.0-rc1-00001-g897ca6d0800d #559 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14) [<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c) [<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120) [<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28) [<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4) [<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw]) [<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw]) [<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc) [<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0) [<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54) [<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0) [<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138) [<c0136a28>] (kthread) from [<c0107778>] (ret_from_fork+0x14/0x3c) Interrupt handling routine was calling req->base.complete() under spinlock. In most cases this wasn't fatal but when combined with some of the cipher modes (like LRW) this caused recursion - starting the new encryption (s5p_aes_crypt()) while still holding the spinlock from previous round (s5p_aes_complete()). Beside that, the s5p_aes_interrupt() error handling path could execute two completions in case of error for RX and TX blocks. Rewrite the interrupt handling routine and the completion by: 1. Splitting the operations on scatterlist copies from s5p_aes_complete() into separate s5p_sg_done(). This still should be done under lock. The s5p_aes_complete() now only calls req->base.complete() and it has to be called outside of lock. 2. Moving the s5p_aes_complete() out of spinlock critical sections. In interrupt service routine s5p_aes_interrupts(), it appeared in few places, including error paths inside other functions called from ISR. This code was not so obvious to read so simplify it by putting the s5p_aes_complete() only within ISR level. Reported-by: Nathan Royce <[email protected]> Cc: <[email protected]> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing Cc: <[email protected]> # v4.10.x Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2017-03-09Merge tag 'usb-serial-4.11-rc2' of ↵Greg Kroah-Hartman3-14/+12
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial fixes for v4.11-rc2 Here's a fix for a digi_acceleport regression in -rc1, and some fixes for long-standing issues in three other drivers, including a NULL-pointer dereference and a couple of information leaks that could be triggered by a malicious device. Signed-off-by: Johan Hovold <[email protected]>
2017-03-09USB: serial: digi_acceleport: fix OOB-event processingJohan Hovold1-1/+1
A recent change claimed to fix an off-by-one error in the OOB-port completion handler, but instead introduced such an error. This could specifically led to modem-status changes going unnoticed, effectively breaking TIOCMGET. Note that the offending commit fixes a loop-condition underflow and is marked for stable, but should not be backported without this fix. Reported-by: Ben Hutchings <[email protected]> Fixes: 2d380889215f ("USB: serial: digi_acceleport: fix OOB data sanity check") Cc: stable <[email protected]> # v2.6.30 Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-03-09MAINTAINERS: usb251xb: remove reference inexistent fileRichard Leitner1-1/+0
The platform_data header file was dropped in the merged version of the USB251xB driver. Therefore remove its reference from the MAINTAINERS file. Signed-off-by: Richard Leitner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-03-09doc: dt-bindings: usb251xb: mark reg as requiredRichard Leitner1-11/+12
Mark the reg property as required and furthermore fix some typos and spellings in the documentation. Signed-off-by: Richard Leitner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-03-09usb: usb251xb: dt: add unit suffix to oc-delay and power-on-timeRichard Leitner2-19/+26
Rename oc-delay-* to oc-delay-us and make it expect a time value. Furthermore add -ms suffix to power-on-time. There changes were suggested by Rob Herring in https://lkml.org/lkml/2017/2/15/1283. Signed-off-by: Richard Leitner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-03-09usb: usb251xb: remove max_{power,current}_{sp,bp} propertiesRichard Leitner2-40/+4
Remove the max_{power,current}_{sp,bp} properties of the usb251xb driver from devicetree. This is done to simplify the dt bindings as requested by Rob Herring in https://lkml.org/lkml/2017/2/15/1283. If those properties are ever needed by somebody they can be enabled again easily. Signed-off-by: Richard Leitner <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-03-09usb-storage: Add ignore-residue quirk for Initio INIC-3619Tobias Jakobi1-0/+14
This USB-SATA bridge chip is used in a StarTech enclosure for optical drives. Without the quirk MakeMKV fails during the key exchange with an installed BluRay drive: > Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - KEY NOT ESTABLISHED' > occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:2' Signed-off-by: Tobias Jakobi <[email protected]> Acked-by: Alan Stern <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-03-09USB: iowarrior: fix NULL-deref in writeJohan Hovold1-0/+8
Make sure to verify that we have the required interrupt-out endpoint for IOWarrior56 devices to avoid dereferencing a NULL-pointer in write should a malicious device lack such an endpoint. Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.") Cc: stable <[email protected]> # 2.6.21 Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-03-09USB: iowarrior: fix NULL-deref at probeJohan Hovold1-6/+7
Make sure to check for the required interrupt-in endpoint to avoid dereferencing a NULL-pointer should a malicious device lack such an endpoint. Note that a fairly recent change purported to fix this issue, but added an insufficient test on the number of endpoints only, a test which can now be removed. Fixes: 4ec0ef3a8212 ("USB: iowarrior: fix oops with malicious USB descriptors") Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.") Cc: stable <[email protected]> # 2.6.21 Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-03-09usb: phy: isp1301: Add OF device ID tableJavier Martinez Canillas1-0/+7
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-03-09usb: ohci-at91: Do not drop unhandled USB suspend control requestsJelle Martijn Kok1-2/+2
In patch 2e2aa1bc7eff90ecm, USB suspend and wakeup control requests are passed to SFR_OHCIICR register. If a processor does not have such a register, this hub control request will be dropped. If no such a SFR register is available, all USB suspend control requests will now be processed using ohci_hub_control() (like before patch 2e2aa1bc7eff90ecm.) Tested on an Atmel AT91SAM9G20 with an on-board TI TUSB2046B hub chip If the last USB device is unplugged from the USB hub, the hub goes into sleep and will not wakeup when an USB devices is inserted. Fixes: 2e2aa1bc7eff90ec ("usb: ohci-at91: Forcibly suspend ports while USB suspend") Signed-off-by: Jelle Martijn Kok <[email protected]> Tested-by: Wenyou Yang <[email protected]> Cc: Wenyou Yang <[email protected]> Cc: Alan Stern <[email protected]> Cc: stable <[email protected]> Acked-by: Nicolas Ferre <[email protected]> Reviewed-by: Alexandre Belloni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-03-09powerpc/powernv/ioda2: Update iommu table base on ownership changeAlexey Kardashevskiy1-5/+12
On POWERNV platform, in order to do DMA via IOMMU (i.e. 32bit DMA in our case), a device needs an iommu_table pointer set via set_iommu_table_base(). The codeflow is: - pnv_pci_ioda2_setup_dma_pe() - pnv_pci_ioda2_setup_default_config() - pnv_ioda_setup_bus_dma() [1] pnv_pci_ioda2_setup_dma_pe() creates IOMMU groups, pnv_pci_ioda2_setup_default_config() does default DMA setup, pnv_ioda_setup_bus_dma() takes a bus PE (on IODA2, all physical function PEs as bus PEs except NPU), walks through all underlying buses and devices, adds all devices to an IOMMU group and sets iommu_table. On IODA2, when VFIO is used, it takes ownership over a PE which means it removes all tables and creates new ones (with a possibility of sharing them among PEs). So when the ownership is returned from VFIO to the kernel, the iommu_table pointer written to a device at [1] is stale and needs an update. This adds an "add_to_group" parameter to pnv_ioda_setup_bus_dma() (in fact re-adds as it used to be there a while ago for different reasons) to tell the helper if a device needs to be added to an IOMMU group with an iommu_table update or just the latter. This calls pnv_ioda_setup_bus_dma(..., false) from pnv_ioda2_release_ownership() so when the ownership is restored, 32bit DMA can work again for a device. This does the same thing on obtaining ownership as the iommu_table point is stale at this point anyway and it is safer to have NULL there. We did not hit this earlier as all tested devices in recent years were only using 64bit DMA; the rare exception for this is MPT3 SAS adapter which uses both 32bit and 64bit DMA access and it has not been tested with VFIO much. Signed-off-by: Alexey Kardashevskiy <[email protected]> Acked-by: Gavin Shan <[email protected]> Reviewed-by: David Gibson <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2017-03-09KVM: arm64: Increase number of user memslots to 512Linu Cherian1-1/+1
Having only 32 memslots is a real constraint for the maximum number of PCI devices that can be assigned to a single guest. Assuming each PCI device/virtual function having two memory BAR regions, we could assign only 15 devices/virtual functions to a guest. Hence increase KVM_USER_MEM_SLOTS to 512 as done in other archs like powerpc. Reviewed-by: Christoffer Dall <[email protected]> Signed-off-by: Linu Cherian <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2017-03-09KVM: arm/arm64: Remove KVM_PRIVATE_MEM_SLOTS definition that are unusedLinu Cherian2-2/+0
arm/arm64 architecture doesnt use private memslots, hence removing KVM_PRIVATE_MEM_SLOTS macro definition. Reviewed-by: Christoffer Dall <[email protected]> Signed-off-by: Linu Cherian <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2017-03-09KVM: arm/arm64: Enable KVM_CAP_NR_MEMSLOTS on arm/arm64Linu Cherian1-0/+3
Return KVM_USER_MEM_SLOTS for userspace capability query on NR_MEMSLOTS. Reviewed-by: Christoffer Dall <[email protected]> Signed-off-by: Linu Cherian <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2017-03-09KVM: Add documentation for KVM_CAP_NR_MEMSLOTSLinu Cherian1-0/+4
Add documentation for KVM_CAP_NR_MEMSLOTS capability. Reviewed-by: Christoffer Dall <[email protected]> Signed-off-by: Linu Cherian <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2017-03-09Merge tag 'fixes-for-v4.11-rc2' of ↵Greg Kroah-Hartman11-44/+114
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus Felipe writes: usb: fixes for v4.11-rc2 dwc3 got a few fixes this time around: Fixed an old bug where a broken endpoint descriptor passed in via userspace through f_fs could prevent dwc3 from working because when calculating max bursts, we could overwrite top 16 bits of a register. Also fixed a bug on dwc3's ep_dequeue implementation which wasn't properly incrementing our TRB dequeue pointer. dwc3 on omap got two fixes: one for system suspend/resume and another added a missing break statement on dwc3_omap_set_mailbox(). Apart from these, we have a set of smaller fixes including memory leak in configfs, build warning fix in atmel udc and a revert of a broken patch that went in during the merge window
2017-03-09drm/i915: Drain the freed state from the tail of the next commitChris Wilson1-13/+21
If we have any residual freed atomic state from earlier commits, flush the freed list after performing the current modeset. This prevents the freed list from ever-growing if userspace manages to starve the kernel threads (i.e. we are never able to run our free state worker and eventually the system may even oom). Fixes: 6f0f02dc56f1 ("drm/i915: Move atomic state free from out of fence release") Testcase: igt/kms_cursor/legacy/all-pipes-single-bo Reported-by: Maarten Lankhorst <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Maarten Lankhorst <[email protected]> (cherry picked from commit ba318c61a9719577b6f451c055f364e4116874b2) Signed-off-by: Jani Nikula <[email protected]>
2017-03-09drm/i915: Nuke debug messages from the pipe update critical sectionVille Syrjälä1-11/+1
printks are slow so we should not be doing them from the vblank evade critical section. These could explain why we sometimes seem to blow past our 100 usec deadline. The problem has been there ever since commit bfd16b2a23dc ("drm/i915: Make updating pipe without modeset atomic.") but it may not have been readily visible until commit e1edbd44e23b ("drm/i915: Complain if we take too long under vblank evasion.") increased our chances of noticing it. Cc: [email protected] Cc: Maarten Lankhorst <[email protected]> Fixes: bfd16b2a23dc ("drm/i915: Make updating pipe without modeset atomic.") Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Maarten Lankhorst <[email protected]> (cherry picked from commit c3f8ad57a01a31397e5a0349a226a32f35ddc19c) Signed-off-by: Jani Nikula <[email protected]>
2017-03-09drm/i915: Use pagecache write to prepopulate shmemfs from pwrite-ioctlChris Wilson2-0/+81
Before we instantiate/pin the backing store for our use, we can prepopulate the shmemfs filp efficiently using a write into the pagecache. We avoid the penalty of instantiating all the pages, important if the user is just writing to a few and never uses the object on the GPU, and using a direct write into shmemfs allows it to avoid the cost of retrieving a page (mostly the clear-before-use, but in theory we could curtail swapin) before it is overwritten. This can be extended later to provide additional specialisation for other backends (other than shmemfs). For now it provides a defense against very large write-only allocations from exhausting all of system memory. v2: Smelling fixes. Fixes: fe115628d567 ("drm/i915: Implement pwrite without struct-mutex") References: https://bugs.freedesktop.org/show_bug.cgi?id=99107 Signed-off-by: Chris Wilson <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: <[email protected]> # v4.10+ Reviewed-by: Joonas Lahtinen <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 7c55e2c5772dcf3cbacd0fa2bcfeefae416b73f7) Signed-off-by: Jani Nikula <[email protected]>
2017-03-09drm/i915: Store a permanent error in obj->mm.pagesChris Wilson1-3/+6
Once the object has been truncated, it is unrecoverable. To facilitate detection of this state store the error in obj->mm.pages. This is required for the next patch which should be applied to v4.10 (via stable), so we also need to mark this patch for backporting. In that regard, let's consider this to be a fix/improvement too. v2: Avoid dereferencing the ERR_PTR when freeing the object. Fixes: 1233e2db199d ("drm/i915: Move object backing storage manipulation to its own locking") Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: <[email protected]> # v4.10+ Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Joonas Lahtinen <[email protected]> (cherry picked from commit 4e5462ee843c883790e9609cf560d88960ea4227) Signed-off-by: Jani Nikula <[email protected]>
2017-03-09drm/i915: Move updating color management to before vblank evasionMaarten Lankhorst1-5/+7
This cannot be done reliably during vblank evasasion since the color management registers are not double buffered. The original commit that moved it always during vblank evasion was wrong, so revert it to before vblank evasion again. Signed-off-by: Maarten Lankhorst <[email protected]> Fixes: 20a34e78f0d7 ("drm/i915: Update color management during vblank evasion.") Cc: [email protected] # v4.7+ Link: http://patchwork.freedesktop.org/patch/msgid/1488292128-14540-1-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <[email protected]> (cherry picked from commit 567f0792a6ad11c0c2620944b8eeb777359fb85a) Signed-off-by: Jani Nikula <[email protected]>
2017-03-09drm/i915/gen9: Increase PCODE request timeout to 50msImre Deak1-5/+6
After commit 2c7d0602c815277f7cb7c932b091288710d8aba7 Author: Imre Deak <[email protected]> Date: Mon Dec 5 18:27:37 2016 +0200 drm/i915/gen9: Fix PCODE polling during CDCLK change notification there is still one report of the CDCLK-change request timing out on a KBL machine, see the Reference link. On that machine the maximum time the request took to succeed was 34ms, so increase the timeout to 50ms. v2: - Change timeout from 100 to 50 ms to maintain the current 50 ms limit for atomic waits in the driver. (Chris, Tvrtko) Reference: https://bugs.freedesktop.org/show_bug.cgi?id=99345 Cc: Ville Syrjälä <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: <[email protected]> Signed-off-by: Imre Deak <[email protected]> Acked-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 0129936ddda26afd5d9d207c4e86b2425952579f) Signed-off-by: Jani Nikula <[email protected]>
2017-03-09drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3Mika Kuoppala1-0/+7
Certain Baytrails, namely the 4 cpu core variants, have been plaqued by spurious system hangs, mostly occurring with light loads. Multiple bisects by various people point to a commit which changes the reclocking strategy for Baytrail to follow its bigger brethen: commit 8fb55197e64d ("drm/i915: Agressive downclocking on Baytrail") There is also a review comment attached to this commit from Deepak S on avoiding punit access on Cherryview and thus it was excluded on common reclocking path. By taking the same approach and omitting the punit access by not tweaking the thresholds when the hardware has been asked to move into different frequency, considerable gains in stability have been observed. With J1900 box, light render/video load would end up in system hang in usually less than 12 hours. With this patch applied, the cumulative uptime has now been 34 days without issues. To provoke system hang, light loads on both render and bsd engines in parallel have been used: glxgears >/dev/null 2>/dev/null & mpv --vo=vaapi --hwdec=vaapi --loop=inf vid.mp4 So far, author has not witnessed system hang with above load and this patch applied. Reports from the tenacious people at kernel bugzilla are also promising. Considering that the punit access frequency with this patch is considerably less, there is a possibility that this will push the, still unknown, root cause past the triggering point on most loads. But as we now can reliably reproduce the hang independently, we can reduce the pain that users are having and use a static thresholds until a root cause is found. v3: don't break debugfs and simplification (Chris Wilson) References: https://bugzilla.kernel.org/show_bug.cgi?id=109051 Cc: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Len Brown <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Ezequiel Garcia <[email protected]> CC: Michal Feix <[email protected]> Cc: Hans de Goede <[email protected]> Cc: Deepak S <[email protected]> Cc: Jarkko Nikula <[email protected]> Cc: <[email protected]> # v4.2+ Acked-by: Daniel Vetter <[email protected]> Acked-by: Chris Wilson <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 6067a27d1f0184596d51decbac1c1fdc4acb012f) Signed-off-by: Jani Nikula <[email protected]>
2017-03-09drm/i915: Remove the vma from the drm_mm if binding failsChris Wilson1-20/+37
As we track whether a vma has been inserted into the drm_mm using the vma->flags, if we fail to bind the vma into the GTT we do not update those bits and will attempt to reinsert the vma into the drm_mm on future passes. To prevent that, we want to unwind i915_vma_insert() if we fail in our attempt to bind. Fixes: 59bfa1248e22 ("drm/i915: Start passing around i915_vma from execbuffer") Testcase: igt/drv_selftest/live_gtt Signed-off-by: Chris Wilson <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: <[email protected]> # v4.9+ Reviewed-by: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 31c7effa39f21f0fea1b3250ae9ff32b9c7e1ae5) Signed-off-by: Jani Nikula <[email protected]>
2017-03-09drm/i915/fbdev: Stop repeating tile configuration on stagnationChris Wilson1-6/+4
If we cease making progress in finding matching outputs for a tiled configuration, stop looping over the remaining unconfigured outputs. v2: Use conn_seq (instead of pass) to only apply tile configuration on first pass. Fixes: b0ee9e7fa5b4 ("drm/fb: add support for tiled monitor configurations. (v2)") Signed-off-by: Chris Wilson <[email protected]> Cc: Tomasz Lis <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Sean Paul <[email protected]> Cc: <[email protected]> # v3.19+ Reviewed-by: Tomasz Lis <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 754a76591b12c88f57ad8b4ca533a5c9566a1922) Signed-off-by: Jani Nikula <[email protected]>
2017-03-09drm/i915/glk: Fix watermark computations for third sprite planeAnder Conselvan de Oliveira1-0/+1
Geminilake has a third sprite plane (or fourth universal plane) that is independent from the cursor. Make sure that for_each_plane_id_on_crtc() is aware of that extra plane so that the watermark code takes it into account. Fixes: e9c9882556fc ("drm/i915/glk: Configure number of sprite planes properly") Cc: Ander Conselvan de Oliveira <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Cc: [email protected] Cc: <[email protected]> Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 19c3164db457e0fc65d4501fd354506228576241) Signed-off-by: Jani Nikula <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.