aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-02-28drm/virtio: implement prime exportGerd Hoffmann3-0/+15
Just run drm_prime_pages_to_sg() on the ttm pages list to get an sg_table for export. The pages list is created at object initialization time, so there should be no need to handle an unpopulated page list. Add a sanity check nevertheless. Signed-off-by: Gerd Hoffmann <[email protected]> Acked-by: Noralf Trønnes <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-02-28drm/virtio: remove prime pin/unpin callbacks.Gerd Hoffmann3-15/+0
virtio-gpu objects never move around, so effectively they are pinned all the time. Therefore we don't need the (optional) pin/unpin callbacks. Remove them. Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Noralf Trønnes <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-02-28drm/virtio: implement prime mmapGerd Hoffmann1-2/+5
Sync gem vm_node.start with ttm vm_node.start, then we can just call drm_gem_prime_mmap(). Signed-off-by: Gerd Hoffmann <[email protected]> Acked-by: Noralf Trønnes <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-02-28crypto: arm64/chacha - fix hchacha_block_neon() for big endianEric Biggers1-2/+2
On big endian arm64 kernels, the xchacha20-neon and xchacha12-neon self-tests fail because hchacha_block_neon() outputs little endian words but the C code expects native endianness. Fix it to output the words in native endianness (which also makes it match the arm32 version). Fixes: cc7cf991e9eb ("crypto: arm64/chacha20 - add XChaCha20 support") Signed-off-by: Eric Biggers <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-02-28crypto: arm64/chacha - fix chacha_4block_xor_neon() for big endianEric Biggers1-0/+16
The change to encrypt a fifth ChaCha block using scalar instructions caused the chacha20-neon, xchacha20-neon, and xchacha12-neon self-tests to start failing on big endian arm64 kernels. The bug is that the keystream block produced in 32-bit scalar registers is directly XOR'd with the data words, which are loaded and stored in native endianness. Thus in big endian mode the data bytes end up XOR'd with the wrong bytes. Fix it by byte-swapping the keystream words in big endian mode. Fixes: 2fe55987b262 ("crypto: arm64/chacha - use combined SIMD/ALU routine for more speed") Signed-off-by: Eric Biggers <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-02-27netlabel: fix out-of-bounds memory accessesPaul Moore2-2/+4
There are two array out-of-bounds memory accesses, one in cipso_v4_map_lvl_valid(), the other in netlbl_bitmap_walk(). Both errors are embarassingly simple, and the fixes are straightforward. As a FYI for anyone backporting this patch to kernels prior to v4.8, you'll want to apply the netlbl_bitmap_walk() patch to cipso_v4_bitmap_walk() as netlbl_bitmap_walk() doesn't exist before Linux v4.8. Reported-by: Jann Horn <[email protected]> Fixes: 446fda4f2682 ("[NetLabel]: CIPSOv4 engine") Fixes: 3faa8f982f95 ("netlabel: Move bitmap manipulation functions to the NetLabel core.") Signed-off-by: Paul Moore <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-27ipv4: Pass original device to ip_rcv_finish_coreDavid Ahern1-4/+5
ip_route_input_rcu expects the original ingress device (e.g., for proper multicast handling). The skb->dev can be changed by l3mdev_ip_rcv, so dev needs to be saved prior to calling it. This was the behavior prior to the listify changes. Fixes: 5fa12739a53d0 ("net: ipv4: listify ip_rcv_finish") Cc: Edward Cree <[email protected]> Signed-off-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-27Merge branch 'pmtu-selftest-fixes'David S. Miller1-16/+80
Paolo Abeni says: ==================== selftests: pmtu: fix and increase coverage This series includes a fixup for the pmtu.sh test script, related to IPv6 address management, and adds coverage for the recently reported and fixed PMTU exception issue v2 -> v3: - more cleanups v1 -> v2: - several script cleanups ==================== Signed-off-by: David S. Miller <[email protected]>
2019-02-27selftests: pmtu: add explicit tests for PMTU exceptions cleanupPaolo Abeni1-1/+67
Add a couple of new tests, explicitly checking that the kernel timely releases PMTU exceptions on related device removal. This is mostly a regression test vs the issue fixed by commit f5b51fe804ec ("ipv6: route: purge exception on removal") Only 2 new test cases have been added, instead of extending all the existing ones, because the reproducer requires executing several commands and would slow down too much the tests otherwise. v2 -> v3: - more cleanup, still from Stefano v1 -> v2: - several script cleanups, as suggested by Stefano Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-27selftests: pmtu: disable DAD in all namespacesPaolo Abeni1-15/+13
Otherwise, the configured IPv6 address could be still "tentative" at test time, possibly causing tests failures. We can also drop some sleep along the code and decrease the timeout for most commands so that the test runtime decreases. v1 -> v2: - fix comment (Stefano) Fixes: d1f1b9cbf34c ("selftests: net: Introduce first PMTU test") Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-27net: phy: dp83867: add soft reset delayMax Uvarov1-0/+3
Similar to dp83640 delay after soft reset is needed to set up registers correctly. Signed-off-by: Max Uvarov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-28drm/bochs: Fix the ID mismatch errorAlistair Francis1-0/+4
When running RISC-V QEMU with the Bochs device attached via PCIe the probe of the Bochs device fails with: [drm:bochs_hw_init] *ERROR* ID mismatch This was introduced by this commit: 7780eb9ce8 bochs: convert to drm_dev_register To fix the error we ensure that pci_enable_device() is called before bochs_load(). Fixes: 7780eb9ce80f ("bochs: convert to drm_dev_register") Signed-off-by: Alistair Francis <[email protected]> Reported-by: David Abdurachmanov <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Gerd Hoffmann <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2019-02-28drm: Block fb changes for async plane updatesNicholas Kazlauskas1-0/+9
The prepare_fb call always happens on new_plane_state. The drm_atomic_helper_cleanup_planes checks to see if plane state pointer has changed when deciding to call cleanup_fb on either the new_plane_state or the old_plane_state. For a non-async atomic commit the state pointer is swapped, so this helper calls prepare_fb on the new_plane_state and cleanup_fb on the old_plane_state. This makes sense, since we want to prepare the framebuffer we are going to use and cleanup the the framebuffer we are no longer using. For the async atomic update helpers this differs. The async atomic update helpers perform in-place updates on the existing state. They call drm_atomic_helper_cleanup_planes but the state pointer is not swapped. This means that prepare_fb is called on the new_plane_state and cleanup_fb is called on the new_plane_state (not the old). In the case where old_plane_state->fb == new_plane_state->fb then there should be no behavioral difference between an async update and a non-async commit. But there are issues that arise when old_plane_state->fb != new_plane_state->fb. The first is that the new_plane_state->fb is immediately cleaned up after it has been prepared, so we're using a fb that we shouldn't be. The second occurs during a sequence of async atomic updates and non-async regular atomic commits. Suppose there are two framebuffers being interleaved in a double-buffering scenario, fb1 and fb2: - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1 - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2 - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 We call cleanup_fb on fb2 twice in this example scenario, and any further use will result in use-after-free. The simple fix to this problem is to block framebuffer changes in the drm_atomic_helper_async_check function for now. v2: Move check by itself, add a FIXME (Daniel) Cc: Daniel Vetter <[email protected]> Cc: Harry Wentland <[email protected]> Cc: Andrey Grodzovsky <[email protected]> Cc: <[email protected]> # v4.14+ Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane update") Signed-off-by: Nicholas Kazlauskas <[email protected]> Acked-by: Andrey Grodzovsky <[email protected]> Acked-by: Harry Wentland <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Harry Wentland <[email protected]> Link: https://patchwork.freedesktop.org/patch/275364/ Signed-off-by: Dave Airlie <[email protected]>
2019-02-28Merge tag 'imx-drm-next-2019-02-22' of git://git.pengutronix.de/pza/linux ↵Dave Airlie9-33/+109
into drm-next drm/imx: handle pending updates better, add plane zpos property support - Add a mechanism to only send commit done events once all pending updates have been applied. This closes a small race window where already armed events could fire even though the double buffered hardware update just missed the update window. - Add plane zpos property support to allow placing the overlay plane behind the primary plane. - Allow building imx-drm on all platforms under COMPILE_TEST. Signed-off-by: Dave Airlie <[email protected]> From: Philipp Zabel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-02-27MIPS: fix memory setup for platforms with PHYS_OFFSET != 0Thomas Bogendoerfer1-1/+2
For platforms, which use a PHYS_OFFSET != 0, symbol _end also contains that offset. So when calling memblock_reserve() for reserving kernel the size argument needs to be adjusted. Fixes: bcec54bf3118 ("mips: switch to NO_BOOTMEM") Acked-by: Mike Rapoport <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Paul Burton <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: James Hogan <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Mike Rapoport <[email protected]> Cc: [email protected] # v4.20+
2019-02-28Merge branch 'drm-fixes-5.0' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2-4/+24
into drm-fixes Fix for variable refresh rate stuttering Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-02-27mm: enforce min addr even if capable() in expand_downwards()Jann Horn1-4/+3
security_mmap_addr() does a capability check with current_cred(), but we can reach this code from contexts like a VFS write handler where current_cred() must not be used. This can be abused on systems without SMAP to make NULL pointer dereferences exploitable again. Fixes: 8869477a49c3 ("security: protect from stack expansion into low vm addresses") Cc: [email protected] Signed-off-by: Jann Horn <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-02-27dma-buf: clarify locking documentation for reservation_object_get_exclLucas Stach1-1/+2
The documentation was misleading, as for a lot of use-cases holding the RCU read side lock is sufficient. Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-02-27dma-buf: add some lockdep asserts to the reservation object implementationLucas Stach1-0/+8
This adds lockdep asserts to the reservation functions which state in their documentation that obj->lock must be held. Allows builds with PROVE_LOCKING enabled to check that the locking requirements are met. Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-02-27drm: Wake up next in drm_read() chain if we are forced to putback the eventChris Wilson1-0/+1
After an event is sent, we try to copy it into the user buffer of the first waiter in drm_read() and if the user buffer doesn't have enough room we put it back onto the list. However, we didn't wake up any subsequent waiter, so that event may sit on the list until either a new vblank event is sent or a new waiter appears. Rare, but in the worst case may lead to a stuck process. Testcase: igt/drm_read/short-buffer-wakeup Signed-off-by: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-02-27net: nfc: Fix NULL dereference on nfc_llcp_build_tlv failsYueHaibing2-4/+40
KASAN report this: BUG: KASAN: null-ptr-deref in nfc_llcp_build_gb+0x37f/0x540 [nfc] Read of size 3 at addr 0000000000000000 by task syz-executor.0/5401 CPU: 0 PID: 5401 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xfa/0x1ce lib/dump_stack.c:113 kasan_report+0x171/0x18d mm/kasan/report.c:321 memcpy+0x1f/0x50 mm/kasan/common.c:130 nfc_llcp_build_gb+0x37f/0x540 [nfc] nfc_llcp_register_device+0x6eb/0xb50 [nfc] nfc_register_device+0x50/0x1d0 [nfc] nfcsim_device_new+0x394/0x67d [nfcsim] ? 0xffffffffc1080000 nfcsim_init+0x6b/0x1000 [nfcsim] do_one_initcall+0xfa/0x5ca init/main.c:887 do_init_module+0x204/0x5f6 kernel/module.c:3460 load_module+0x66b2/0x8570 kernel/module.c:3808 __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x462e99 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f9cb79dcc58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99 RDX: 0000000000000000 RSI: 0000000020000280 RDI: 0000000000000003 RBP: 00007f9cb79dcc70 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9cb79dd6bc R13: 00000000004bcefb R14: 00000000006f7030 R15: 0000000000000004 nfc_llcp_build_tlv will return NULL on fails, caller should check it, otherwise will trigger a NULL dereference. Reported-by: Hulk Robot <[email protected]> Fixes: eda21f16a5ed ("NFC: Set MIU and RW values from CONNECT and CC LLCP frames") Fixes: d646960f7986 ("NFC: Initial LLCP support") Signed-off-by: YueHaibing <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-27drm/amd/display: Use vrr friendly pageflip throttling in DC.Mario Kleiner2-4/+24
In VRR mode, keep track of the vblank count of the last completed pageflip in amdgpu_crtc->last_flip_vblank, as recorded in the pageflip completion handler after each completed flip. Use that count to prevent mmio programming a new pageflip within the same vblank in which the last pageflip completed, iow. to throttle pageflips to at most one flip per video frame, while at the same time allowing to request a flip not only before start of vblank, but also anywhere within vblank. The old logic did the same, and made sense for regular fixed refresh rate flipping, but in vrr mode it prevents requesting a flip anywhere inside the possibly huge vblank, thereby reducing framerate in vrr mode instead of improving it, by delaying a slightly delayed flip requests up to a maximum vblank duration + 1 scanout duration. This would limit VRR usefulness to only help applications with a very high GPU demand, which can submit the flip request before start of vblank, but then have to wait long for fences to complete. With this method a flip can be both requested and - after fences have completed - executed, ie. it doesn't matter if the request (amdgpu_dm_do_flip()) gets delayed until deep into the extended vblank due to cpu execution delays. This also allows clients which want to regulate framerate within the vrr range a much more fine-grained control of flip timing, a feature that might be useful for video playback, and is very useful for neuroscience/vision research applications. In regular non-VRR mode, retain the old flip submission behavior. This to keep flip scheduling for fullscreen X11/GLX OpenGL clients intact, if they use the GLX_OML_sync_control extensions glXSwapBufferMscOML(, ..., target_msc,...) function with a specific target_msc target vblank count. glXSwapBuffersMscOML() or DRI3/Present PresentPixmap() will not flip at the proper target_msc for a non-zero target_msc if VRR mode is active with this patch. They'd often flip one frame too early. However, this limitation should not matter much in VRR mode, as scheduling based on vblank counts is pretty futile/unusable under variable refresh duration anyway, so no real extra harm is done. Signed-off-by: Mario Kleiner <[email protected]> Cc: Nicholas Kazlauskas <[email protected]> Cc: Harry Wentland <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-02-27net: phy: Micrel KSZ8061: link failure after cable connectRajasingh Thavamani1-1/+12
With Micrel KSZ8061 PHY, the link may occasionally not come up after Ethernet cable connect. The vendor's (Microchip, former Micrel) errata sheet 80000688A.pdf descripes the problem and possible workarounds in detail, see below. The batch implements workaround 1, which permanently fixes the issue. DESCRIPTION Link-up may not occur properly when the Ethernet cable is initially connected. This issue occurs more commonly when the cable is connected slowly, but it may occur any time a cable is connected. This issue occurs in the auto-negotiation circuit, and will not occur if auto-negotiation is disabled (which requires that the two link partners be set to the same speed and duplex). END USER IMPLICATIONS When this issue occurs, link is not established. Subsequent cable plug/unplaug cycle will not correct the issue. WORk AROUND There are four approaches to work around this issue: 1. This issue can be prevented by setting bit 15 in MMD device address 1, register 2, prior to connecting the cable or prior to setting the Restart Auto-negotiation bit in register 0h. The MMD registers are accessed via the indirect access registers Dh and Eh, or via the Micrel EthUtil utility as shown here: . if using the EthUtil utility (usually with a Micrel KSZ8061 Evaluation Board), type the following commands: > address 1 > mmd 1 > iw 2 b61a . Alternatively, write the following registers to write to the indirect MMD register: Write register Dh, data 0001h Write register Eh, data 0002h Write register Dh, data 4001h Write register Eh, data B61Ah 2. The issue can be avoided by disabling auto-negotiation in the KSZ8061, either by the strapping option, or by clearing bit 12 in register 0h. Care must be taken to ensure that the KSZ8061 and the link partner will link with the same speed and duplex. Note that the KSZ8061 defaults to full-duplex when auto-negotiation is off, but other devices may default to half-duplex in the event of failed auto-negotiation. 3. The issue can be avoided by connecting the cable prior to powering-up or resetting the KSZ8061, and leaving it plugged in thereafter. 4. If the above measures are not taken and the problem occurs, link can be recovered by setting the Restart Auto-Negotiation bit in register 0h, or by resetting or power cycling the device. Reset may be either hardware reset or software reset (register 0h, bit 15). PLAN This errata will not be corrected in the future revision. Fixes: 7ab59dc15e2f ("drivers/net/phy/micrel_phy: Add support for new PHYs") Signed-off-by: Alexander Onnasch <[email protected]> Signed-off-by: Rajasingh Thavamani <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-27enc28j60: Correct description of debug module parameterAndy Shevchenko1-1/+1
The netif_msg_init() API takes on input the amount of bits to be set. The description of debug parameter in the enc28j60 module is misleading in this sense and passing 0xffff does not give an expected behaviour. Fix the description of debug module parameter to show what exactly is expected. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-27net: dev: Use unsigned integer as an argument to left-shiftAndy Shevchenko1-1/+1
1 << 31 is Undefined Behaviour according to the C standard. Use U type modifier to avoid theoretical overflow. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-27bnxt_en: Drop oversize TX packets to prevent errors.Michael Chan1-0/+6
There have been reports of oversize UDP packets being sent to the driver to be transmitted, causing error conditions. The issue is likely caused by the dst of the SKB switching between 'lo' with 64K MTU and the hardware device with a smaller MTU. Patches are being proposed by Mahesh Bandewar <[email protected]> to fix the issue. In the meantime, add a quick length check in the driver to prevent the error. The driver uses the TX packet size as index to look up an array to setup the TX BD. The array is large enough to support all MTU sizes supported by the driver. The oversize TX packet causes the driver to index beyond the array and put garbage values into the TX BD. Add a simple check to prevent this. Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-27mmc: core: align max segment size with logical block sizeMing Lei2-7/+8
Logical block size is the lowest possible block size that the storage device can address. Max segment size is often related with controller's DMA capability. And it is reasonable to align max segment size with logical block size. SDHCI sets un-aligned max segment size, and causes ADMA error, so fix it by aligning max segment size with logical block size. Reported-by: Naresh Kamboju <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Naresh Kamboju <[email protected]> Cc: Faiz Abbas <[email protected]> Cc: [email protected] Signed-off-by: Ming Lei <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2019-02-27mmc: cqhci: Fix a tiny potential memory leak on error conditionAlamy Liu1-1/+10
Free up the allocated memory in the case of error return The value of mmc_host->cqe_enabled stays 'false'. Thus, cqhci_disable (mmc_cqe_ops->cqe_disable) won't be called to free the memory. Also, cqhci_disable() seems to be designed to disable and free all resources, not suitable to handle this corner case. Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host") Signed-off-by: Alamy Liu <[email protected]> Acked-by: Adrian Hunter <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]>
2019-02-27mmc: cqhci: fix space allocated for transfer descriptorAlamy Liu1-1/+1
There is not enough space being allocated when DCMD is disabled. CQE_DCMD is not necessary to be enabled when CQE is enabled. (Software could halt CQE to send command) In the case that CQE_DCMD is not enabled, it still needs to allocate space for data transfer. For instance: CQE_DCMD is enabled: 31 slots space (one slot used by DCMD) CQE_DCMD is disabled: 32 slots space Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host") Signed-off-by: Alamy Liu <[email protected]> Acked-by: Adrian Hunter <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]>
2019-02-27scsi: core: Avoid that system resume triggers a kernel warningBart Van Assche1-1/+0
scsi_device_quiesce() and scsi_device_resume() are called during system-wide suspend and resume. scsi_device_quiesce() only succeeds for SCSI devices that are in one of the RUNNING, OFFLINE or TRANSPORT_OFFLINE states (see also scsi_set_device_state()). This patch avoids that the following warning is triggered when resuming a system for which quiescing a SCSI device failed: WARNING: CPU: 2 PID: 11303 at drivers/scsi/scsi_lib.c:2600 scsi_device_resume+0x4f/0x58 CPU: 2 PID: 11303 Comm: kworker/u8:70 Not tainted 5.0.0-rc1+ #50 Hardware name: LENOVO 80E3/Lancer 5B2, BIOS A2CN45WW(V2.13) 08/04/2016 Workqueue: events_unbound async_run_entry_fn Call Trace: scsi_dev_type_resume+0x2e/0x60 async_run_entry_fn+0x32/0xd8 process_one_work+0x1f4/0x420 worker_thread+0x28/0x3c0 kthread+0x118/0x130 ret_from_fork+0x22/0x40 Cc: Przemek Socha <[email protected]> Reported-by: Przemek Socha <[email protected]> Fixes: 3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work reliably") # v4.15 Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-02-27mmc: core: Fix NULL ptr crash from mmc_should_fail_requestRitesh Harjani1-1/+1
In case of CQHCI, mrq->cmd may be NULL for data requests (non DCMD). In such case mmc_should_fail_request is directly dereferencing mrq->cmd while cmd is NULL. Fix this by checking for mrq->cmd pointer. Fixes: 72a5af554df8 ("mmc: core: Add support for handling CQE requests") Signed-off-by: Ritesh Harjani <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]>
2019-02-26arm64: dts: qcom: msm8998: Extend TZ reserved memory areaMarc Gonzalez1-1/+1
My console locks up as soon as Linux writes to [88800000,88f00000[ AFAIU, that memory area is reserved for trustzone. Extend TZ reserved memory range, to prevent Linux from stepping on trustzone's toes. Cc: [email protected] # 4.20+ Reviewed-by: Sibi Sankar <[email protected]> Fixes: c7833949564ec ("arm64: dts: qcom: msm8998: Add smem related nodes") Signed-off-by: Marc Gonzalez <[email protected]> Signed-off-by: Andy Gross <[email protected]>
2019-02-26Merge tag 'qcom-fixes-for-5.0-rc3' into fixes-for-5.0-rc8Andy Gross1-1/+1
Qualcomm ARM64 Fixes for 5.0-rc3 * Fix irq controller compatible for the MSM8996 platforms
2019-02-26tipc: fix race condition causing hung sendtoTung Nguyen1-1/+5
When sending multicast messages via blocking socket, if sending link is congested (tsk->cong_link_cnt is set to 1), the sending thread will be put into sleeping state. However, tipc_sk_filter_rcv() is called under socket spin lock but tipc_wait_for_cond() is not. So, there is no guarantee that the setting of tsk->cong_link_cnt to 0 in tipc_sk_proto_rcv() in CPU-1 will be perceived by CPU-0. If that is the case, the sending thread in CPU-0 after being waken up, will continue to see tsk->cong_link_cnt as 1 and put the sending thread into sleeping state again. The sending thread will sleep forever. CPU-0 | CPU-1 tipc_wait_for_cond() | { | // condition_ = !tsk->cong_link_cnt | while ((rc_ = !(condition_))) { | ... | release_sock(sk_); | wait_woken(); | | if (!sock_owned_by_user(sk)) | tipc_sk_filter_rcv() | { | ... | tipc_sk_proto_rcv() | { | ... | tsk->cong_link_cnt--; | ... | sk->sk_write_space(sk); | ... | } | ... | } sched_annotate_sleep(); | lock_sock(sk_); | remove_wait_queue(); | } | } | This commit fixes it by adding memory barrier to tipc_sk_proto_rcv() and tipc_wait_for_cond(). Acked-by: Jon Maloy <[email protected]> Signed-off-by: Tung Nguyen <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-26hv_netvsc: Fix IP header checksum for coalesced packetsHaiyang Zhang1-3/+19
Incoming packets may have IP header checksum verified by the host. They may not have IP header checksum computed after coalescing. This patch re-compute the checksum when necessary, otherwise the packets may be dropped, because Linux network stack always checks it. Signed-off-by: Haiyang Zhang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-26Merge branch 'net-fail-route'David S. Miller3-0/+11
David Ahern says: ==================== net: Fail route add with unsupported nexthop attribute RTA_VIA was added for MPLS as a way of specifying a gateway from a different address family. IPv4 and IPv6 do not currently support RTA_VIA so using it leads to routes that are not what the user intended. Catch and fail - returning a proper error message. MPLS on the other hand does not support RTA_GATEWAY since it does not make sense to have a nexthop from the MPLS address family. Similarly, catch and fail - returning a proper error message. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-02-26mpls: Return error for RTA_GATEWAY attributeDavid Ahern1-0/+3
MPLS does not support nexthops with an MPLS address family. Specifically, it does not handle RTA_GATEWAY attribute. Make it clear by returning an error. Fixes: 03c0566542f4c ("mpls: Netlink commands to add, remove, and dump routes") Signed-off-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-26ipv6: Return error for RTA_VIA attributeDavid Ahern1-0/+4
IPv6 currently does not support nexthops outside of the AF_INET6 family. Specifically, it does not handle RTA_VIA attribute. If it is passed in a route add request, the actual route added only uses the device which is clearly not what the user intended: $ ip -6 ro add 2001:db8:2::/64 via inet 172.16.1.1 dev eth0 $ ip ro ls ... 2001:db8:2::/64 dev eth0 metric 1024 pref medium Catch this and fail the route add: $ ip -6 ro add 2001:db8:2::/64 via inet 172.16.1.1 dev eth0 Error: IPv6 does not support RTA_VIA attribute. Fixes: 03c0566542f4c ("mpls: Netlink commands to add, remove, and dump routes") Signed-off-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-26ipv4: Return error for RTA_VIA attributeDavid Ahern1-0/+4
IPv4 currently does not support nexthops outside of the AF_INET family. Specifically, it does not handle RTA_VIA attribute. If it is passed in a route add request, the actual route added only uses the device which is clearly not what the user intended: $ ip ro add 172.16.1.0/24 via inet6 2001:db8:1::1 dev eth0 $ ip ro ls ... 172.16.1.0/24 dev eth0 Catch this and fail the route add: $ ip ro add 172.16.1.0/24 via inet6 2001:db8:1::1 dev eth0 Error: IPv4 does not support RTA_VIA attribute. Fixes: 03c0566542f4c ("mpls: Netlink commands to add, remove, and dump routes") Signed-off-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-26bpf: decrease usercnt if bpf_map_new_fd() fails in bpf_map_get_fd_by_id()Peng Sun1-1/+1
In bpf/syscall.c, bpf_map_get_fd_by_id() use bpf_map_inc_not_zero() to increase the refcount, both map->refcnt and map->usercnt. Then, if bpf_map_new_fd() fails, should handle map->usercnt too. Fixes: bd5f5f4ecb78 ("bpf: Add BPF_MAP_GET_FD_BY_ID") Signed-off-by: Peng Sun <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]>
2019-02-26drm/panel: Add Ronbo RB070D30 panelKonstantin Sudakov3-0/+268
The Ronbo RB070D30 panel is a MIPI-DSI panel based on a Fitipower EK79007 controller and a 1024x600 panel. Reviewed-by: Paul Kocialkowski <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Konstantin Sudakov <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/3cc43c6051e89a52434053a38a36621acab7236e.1550650810.git-series.maxime.ripard@bootlin.com
2019-02-26dt-bindings: panel: Add YAML schemas for the Ronbo RB070D30 panelMaxime Ripard1-0/+51
The Ronbo RB070D30 panel is a 1024x600 MIPI-DSI panel. Reviewed-by: Paul Kocialkowski <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/c05b961302ec4a2af32ea6c215ec0749b1a9cff7.1550650810.git-series.maxime.ripard@bootlin.com
2019-02-26dt-bindings: Add vendor prefix for Ronbo ElectronicsKonstantin Sudakov1-0/+1
Ronbo Electronics manufactures display panels. Reviewed-by: Paul Kocialkowski <[email protected]> Signed-off-by: Konstantin Sudakov <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/a7ab8bd59ad673f88e2c39cf6cb21bd959cf4db4.1550650810.git-series.maxime.ripard@bootlin.com
2019-02-26iommu/dmar: Fix buffer overflow during PCI bus notificationJulia Cartwright1-1/+1
Commit 57384592c433 ("iommu/vt-d: Store bus information in RMRR PCI device path") changed the type of the path data, however, the change in path type was not reflected in size calculations. Update to use the correct type and prevent a buffer overflow. This bug manifests in systems with deep PCI hierarchies, and can lead to an overflow of the static allocated buffer (dmar_pci_notify_info_buf), or can lead to overflow of slab-allocated data. BUG: KASAN: global-out-of-bounds in dmar_alloc_pci_notify_info+0x1d5/0x2e0 Write of size 1 at addr ffffffff90445d80 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.14.87-rt49-02406-gd0a0e96 #1 Call Trace: ? dump_stack+0x46/0x59 ? print_address_description+0x1df/0x290 ? dmar_alloc_pci_notify_info+0x1d5/0x2e0 ? kasan_report+0x256/0x340 ? dmar_alloc_pci_notify_info+0x1d5/0x2e0 ? e820__memblock_setup+0xb0/0xb0 ? dmar_dev_scope_init+0x424/0x48f ? __down_write_common+0x1ec/0x230 ? dmar_dev_scope_init+0x48f/0x48f ? dmar_free_unused_resources+0x109/0x109 ? cpumask_next+0x16/0x20 ? __kmem_cache_create+0x392/0x430 ? kmem_cache_create+0x135/0x2f0 ? e820__memblock_setup+0xb0/0xb0 ? intel_iommu_init+0x170/0x1848 ? _raw_spin_unlock_irqrestore+0x32/0x60 ? migrate_enable+0x27a/0x5b0 ? sched_setattr+0x20/0x20 ? migrate_disable+0x1fc/0x380 ? task_rq_lock+0x170/0x170 ? try_to_run_init_process+0x40/0x40 ? locks_remove_file+0x85/0x2f0 ? dev_prepare_static_identity_mapping+0x78/0x78 ? rt_spin_unlock+0x39/0x50 ? lockref_put_or_lock+0x2a/0x40 ? dput+0x128/0x2f0 ? __rcu_read_unlock+0x66/0x80 ? __fput+0x250/0x300 ? __rcu_read_lock+0x1b/0x30 ? mntput_no_expire+0x38/0x290 ? e820__memblock_setup+0xb0/0xb0 ? pci_iommu_init+0x25/0x63 ? pci_iommu_init+0x25/0x63 ? do_one_initcall+0x7e/0x1c0 ? initcall_blacklisted+0x120/0x120 ? kernel_init_freeable+0x27b/0x307 ? rest_init+0xd0/0xd0 ? kernel_init+0xf/0x120 ? rest_init+0xd0/0xd0 ? ret_from_fork+0x1f/0x40 The buggy address belongs to the variable: dmar_pci_notify_info_buf+0x40/0x60 Fixes: 57384592c433 ("iommu/vt-d: Store bus information in RMRR PCI device path") Signed-off-by: Julia Cartwright <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2019-02-26mmc: tmio: fix access width of Block Count RegisterTakeshi Saito3-1/+11
In R-Car Gen2 or later, the maximum number of transfer blocks are changed from 0xFFFF to 0xFFFFFFFF. Therefore, Block Count Register should use iowrite32(). If another system (U-boot, Hypervisor OS, etc) uses bit[31:16], this value will not be cleared. So, SD/MMC card initialization fails. So, check for the bigger register and use apropriate write. Also, mark the register as extended on Gen2. Signed-off-by: Takeshi Saito <[email protected]> [wsa: use max_blk_count in if(), add Gen2, update commit message] Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected] Reviewed-by: Simon Horman <[email protected]> [Ulf: Fixed build error] Signed-off-by: Ulf Hansson <[email protected]>
2019-02-25scsi: hptiop: fix calls to dma_set_mask()Hannes Reinecke1-3/+7
The change to use dma_set_mask() incorrectly made a second call with the 32 bit DMA mask value when the call with the 64 bit DMA mask value succeeded. Fixes: 453cd3700ca3 ("scsi: hptiop: use dma_set_mask") Cc: <[email protected]> Suggested-by: Ewan D. Milne <[email protected]> Signed-off-by: Hannes Reinecke <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Ewan D. Milne <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-02-25scsi: hisi_sas: fix calls to dma_set_mask_and_coherent()Hannes Reinecke2-5/+11
The change to use dma_set_mask_and_coherent() incorrectly made a second call with the 32 bit DMA mask value when the call with the 64 bit DMA mask value succeeded. [mkp: fixed commit message] Fixes: e4db40e7a1a2 ("scsi: hisi_sas: use dma_set_mask_and_coherent") Cc: <[email protected]> Suggested-by: Ewan D. Milne <[email protected]> Signed-off-by: Hannes Reinecke <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Hannes Reinecke <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-02-25scsi: csiostor: fix calls to dma_set_mask_and_coherent()Hannes Reinecke1-2/+5
The change to use dma_set_mask_and_coherent() incorrectly made a second call with the 32 bit DMA mask value when the call with the 64 bit DMA mask value succeeded. Fixes: c22b332d811b ("scsi: csiostor: switch to generic DMA API") Cc: <[email protected]> Signed-off-by: Hannes Reinecke <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Ewan D. Milne <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-02-25scsi: bfa: fix calls to dma_set_mask_and_coherent()Hannes Reinecke1-5/+13
The change to use dma_set_mask_and_coherent() incorrectly made a second call with the 32 bit DMA mask value when the call with the 64 bit DMA mask value succeeded. [mkp: fixed commit message] Fixes: a69b080025ea ("scsi: bfa: use dma_set_mask_and_coherent") Cc: <[email protected]> Suggested-by: Ewan D. Milne <[email protected]> Signed-off-by: Hannes Reinecke <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Ewan D. Milne <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-02-25scsi: aic94xx: fix calls to dma_set_mask_and_coherent()Hannes Reinecke1-3/+5
The change to use dma_set_mask_and_coherent() incorrectly made a second call with the 32 bit DMA mask value when the call with the 64 bit DMA mask value succeeded. [mkp: fixed subject] Fixes: 3a21986f1a59 ("scsi: aic94xx: fully convert to the generic DMA API") Cc: <[email protected]> Signed-off-by: Hannes Reinecke <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Ewan D. Milne <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.