aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-04-10drm/i915/icl: Fix port disable sequence for mipi-dsiVandita Kulkarni2-4/+4
Re-enable clock gating of DDI clocks. v2: Fix the default ddi clk state for mipi-dsi (Imre) Fixes: 1026bea00381 ("drm/i915/icl: Ungate DSI clocks") Signed-off-by: Vandita Kulkarni <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 942d1cf48eae3fcd7e973cfb708d5c4860f0c713) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-04-10drm/i915/icl: Ungate ddi clocks before IO enableVandita Kulkarni1-0/+6
IO enable sequencing needs ddi clocks enabled. These clocks will be gated at a later point in the enable sequence. v2: Fix the commit header (Uma) v3: Remove the redundant read (Ville) Fixes: 949fc52af19e ("drm/i915/icl: add pll mapping for DSI") Signed-off-by: Vandita Kulkarni <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit c5b81a325263a891d5811aabe938c87e03db4c37) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-04-10nvme: cancel request synchronouslyMing Lei1-1/+1
nvme_cancel_request() is used in error handler, and it is always reliable to cancel request synchronously, and avoids possible race in which request may be completed after real hw queue is destroyed. One issue is reported by our customer on NVMe RDMA, in which freed ib queue pair may be used in nvme_rdma_complete_rq(). Cc: Sagi Grimberg <[email protected]> Cc: Bart Van Assche <[email protected]> Cc: James Smart <[email protected]> Cc: [email protected] Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Ming Lei <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-04-10blk-mq: introduce blk_mq_complete_request_sync()Ming Lei2-0/+8
In NVMe's error handler, follows the typical steps of tearing down hardware for recovering controller: 1) stop blk_mq hw queues 2) stop the real hw queues 3) cancel in-flight requests via blk_mq_tagset_busy_iter(tags, cancel_request, ...) cancel_request(): mark the request as abort blk_mq_complete_request(req); 4) destroy real hw queues However, there may be race between #3 and #4, because blk_mq_complete_request() may run q->mq_ops->complete(rq) remotelly and asynchronously, and ->complete(rq) may be run after #4. This patch introduces blk_mq_complete_request_sync() for fixing the above race. Cc: Sagi Grimberg <[email protected]> Cc: Bart Van Assche <[email protected]> Cc: James Smart <[email protected]> Cc: [email protected] Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Ming Lei <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-04-10scsi: virtio_scsi: limit number of hw queues by nr_cpu_idsDongli Zhang1-0/+1
When tag_set->nr_maps is 1, the block layer limits the number of hw queues by nr_cpu_ids. No matter how many hw queues are used by virtio-scsi, as it has (tag_set->nr_maps == 1), it can use at most nr_cpu_ids hw queues. In addition, specifically for pci scenario, when the 'num_queues' specified by qemu is more than maxcpus, virtio-scsi would not be able to allocate more than maxcpus vectors in order to have a vector for each queue. As a result, it falls back into MSI-X with one vector for config and one shared for queues. Considering above reasons, this patch limits the number of hw queues used by virtio-scsi by nr_cpu_ids. Reviewed-by: Stefan Hajnoczi <[email protected]> Signed-off-by: Dongli Zhang <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-04-10virtio-blk: limit number of hw queues by nr_cpu_idsDongli Zhang1-0/+2
When tag_set->nr_maps is 1, the block layer limits the number of hw queues by nr_cpu_ids. No matter how many hw queues are used by virtio-blk, as it has (tag_set->nr_maps == 1), it can use at most nr_cpu_ids hw queues. In addition, specifically for pci scenario, when the 'num-queues' specified by qemu is more than maxcpus, virtio-blk would not be able to allocate more than maxcpus vectors in order to have a vector for each queue. As a result, it falls back into MSI-X with one vector for config and one shared for queues. Considering above reasons, this patch limits the number of hw queues used by virtio-blk by nr_cpu_ids. Reviewed-by: Stefan Hajnoczi <[email protected]> Signed-off-by: Dongli Zhang <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-04-10block, bfq: fix use after free in bfq_bfqq_expirePaolo Valente3-11/+23
The function bfq_bfqq_expire() invokes the function __bfq_bfqq_expire(), and the latter may free the in-service bfq-queue. If this happens, then no other instruction of bfq_bfqq_expire() must be executed, or a use-after-free will occur. Basing on the assumption that __bfq_bfqq_expire() invokes bfq_put_queue() on the in-service bfq-queue exactly once, the queue is assumed to be freed if its refcounter is equal to one right before invoking __bfq_bfqq_expire(). But, since commit 9dee8b3b057e ("block, bfq: fix queue removal from weights tree") this assumption is false. __bfq_bfqq_expire() may also invoke bfq_weights_tree_remove() and, since commit 9dee8b3b057e ("block, bfq: fix queue removal from weights tree"), also the latter function may invoke bfq_put_queue(). So __bfq_bfqq_expire() may invoke bfq_put_queue() twice, and this is the actual case where the in-service queue may happen to be freed. To address this issue, this commit moves the check on the refcounter of the queue right around the last bfq_put_queue() that may be invoked on the queue. Fixes: 9dee8b3b057e ("block, bfq: fix queue removal from weights tree") Reported-by: Dmitrii Tcvetkov <[email protected]> Reported-by: Douglas Anderson <[email protected]> Tested-by: Dmitrii Tcvetkov <[email protected]> Tested-by: Douglas Anderson <[email protected]> Signed-off-by: Paolo Valente <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-04-10ALSA: hda: Fix racy display power accessTakashi Iwai3-2/+6
snd_hdac_display_power() doesn't handle the concurrent calls carefully enough, and it may lead to the doubly get_power or put_power calls, when a runtime PM and an async work get called in racy way. This patch addresses it by reusing the bus->lock mutex that has been used for protecting the link state change in ext bus code, so that it can protect against racy display state changes. The initialization of bus->lock was moved from snd_hdac_ext_bus_init() to snd_hdac_bus_init() as well accordingly. Testcase: igt/i915_pm_rpm/module-reload #glk-dsi Reported-by: Chris Wilson <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Cc: Imre Deak <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2019-04-10alarmtimer: Return correct remaining timeAndrei Vagin1-1/+1
To calculate a remaining time, it's required to subtract the current time from the expiration time. In alarm_timer_remaining() the arguments of ktime_sub are swapped. Fixes: d653d8457c76 ("alarmtimer: Implement remaining callback") Signed-off-by: Andrei Vagin <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Mukesh Ojha <[email protected]> Cc: Stephen Boyd <[email protected]> Cc: John Stultz <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2019-04-10locking/lockdep: Zap lock classes even with lock debugging disabledBart Van Assche1-17/+12
The following commit: a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer in use") changed the behavior of lockdep_free_key_range() from unconditionally zapping lock classes into only zapping lock classes if debug_lock == true. Not zapping lock classes if debug_lock == false leaves dangling pointers in several lockdep datastructures, e.g. lock_class::name in the all_lock_classes list. The shell command "cat /proc/lockdep" causes the kernel to iterate the all_lock_classes list. Hence the "unable to handle kernel paging request" cash that Shenghui encountered by running cat /proc/lockdep. Since the new behavior can cause cat /proc/lockdep to crash, restore the pre-v5.1 behavior. This patch avoids that cat /proc/lockdep triggers the following crash with debug_lock == false: BUG: unable to handle kernel paging request at fffffbfff40ca448 RIP: 0010:__asan_load1+0x28/0x50 Call Trace: string+0xac/0x180 vsnprintf+0x23e/0x820 seq_vprintf+0x82/0xc0 seq_printf+0x92/0xb0 print_name+0x34/0xb0 l_show+0x184/0x200 seq_read+0x59e/0x6c0 proc_reg_read+0x11f/0x170 __vfs_read+0x4d/0x90 vfs_read+0xc5/0x1f0 ksys_read+0xab/0x130 __x64_sys_read+0x43/0x50 do_syscall_64+0x71/0x210 entry_SYSCALL_64_after_hwframe+0x49/0xbe Reported-by: shenghui <[email protected]> Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Waiman Long <[email protected]> Cc: Will Deacon <[email protected]> Fixes: a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer in use") # v5.1-rc1. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-04-10ASoC: pcm: fix error handling when try_module_get() fails.Ranjani Sridharan1-3/+5
Handle error before returning when try_module_get() fails to prevent inconsistent mutex lock/unlock. Fixes: 52034add7 (ASoC: pcm: update module refcount if module_get_upon_open is set) Signed-off-by: Ranjani Sridharan <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-04-10apparmor: Restore Y/N in /sys for apparmor's "enabled"Kees Cook1-1/+48
Before commit c5459b829b71 ("LSM: Plumb visibility into optional "enabled" state"), /sys/module/apparmor/parameters/enabled would show "Y" or "N" since it was using the "bool" handler. After being changed to "int", this switched to "1" or "0", breaking the userspace AppArmor detection of dbus-broker. This restores the Y/N output while keeping the LSM infrastructure happy. Before: $ cat /sys/module/apparmor/parameters/enabled 1 After: $ cat /sys/module/apparmor/parameters/enabled Y Reported-by: David Rheinsberg <[email protected]> Reviewed-by: David Rheinsberg <[email protected]> Link: https://lkml.kernel.org/r/CADyDSO6k8vYb1eryT4g6+EHrLCvb68GAbHVWuULkYjcZcYNhhw@mail.gmail.com Fixes: c5459b829b71 ("LSM: Plumb visibility into optional "enabled" state") Signed-off-by: Kees Cook <[email protected]> Signed-off-by: John Johansen <[email protected]>
2019-04-10ASoC: stm32: sai: fix master clock managementOlivier Moysan1-17/+47
When master clock is used, master clock rate is set exclusively. Parent clocks of master clock cannot be changed after a call to clk_set_rate_exclusive(). So the parent clock of SAI kernel clock must be set before. Ensure also that exclusive rate operations are balanced in STM32 SAI driver. Signed-off-by: Olivier Moysan <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-04-10ASoC: Intel: kbl: fix wrong number of channelsTzung-Bi Shih1-1/+1
Fix wrong setting on number of channels. The context wants to set constraint to 2 channels instead of 4. Signed-off-by: Tzung-Bi Shih <[email protected]> Acked-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-04-10x86/perf/amd: Remove need to check "running" bit in NMI handlerLendacky, Thomas2-12/+22
Spurious interrupt support was added to perf in the following commit, almost a decade ago: 63e6be6d98e1 ("perf, x86: Catch spurious interrupts after disabling counters") The two previous patches (resolving the race condition when disabling a PMC and NMI latency mitigation) allow for the removal of this older spurious interrupt support. Currently in x86_pmu_stop(), the bit for the PMC in the active_mask bitmap is cleared before disabling the PMC, which sets up a race condition. This race condition was mitigated by introducing the running bitmap. That race condition can be eliminated by first disabling the PMC, waiting for PMC reset on overflow and then clearing the bit for the PMC in the active_mask bitmap. The NMI handler will not re-enable a disabled counter. If x86_pmu_stop() is called from the perf NMI handler, the NMI latency mitigation support will guard against any unhandled NMI messages. Signed-off-by: Tom Lendacky <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: <[email protected]> # 4.14.x- Cc: Alexander Shishkin <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vince Weaver <[email protected]> Link: https://lkml.kernel.org/r/Message-ID: Signed-off-by: Ingo Molnar <[email protected]>
2019-04-10powerpc/mm: Define MAX_PHYSMEM_BITS for all 64-bit configsMichael Ellerman1-1/+1
The recent commit 8bc086899816 ("powerpc/mm: Only define MAX_PHYSMEM_BITS in SPARSEMEM configurations") removed our definition of MAX_PHYSMEM_BITS when SPARSEMEM is disabled. This inadvertently broke some 64-bit FLATMEM using configs with eg: arch/powerpc/include/asm/book3s/64/mmu-hash.h:584:6: error: "MAX_PHYSMEM_BITS" is not defined, evaluates to 0 #if (MAX_PHYSMEM_BITS > MAX_EA_BITS_PER_CONTEXT) ^~~~~~~~~~~~~~~~ Fix it by making sure we define MAX_PHYSMEM_BITS for all 64-bit configs regardless of SPARSEMEM. Fixes: 8bc086899816 ("powerpc/mm: Only define MAX_PHYSMEM_BITS in SPARSEMEM configurations") Reported-by: Andreas Schwab <[email protected]> Reported-by: Hugh Dickins <[email protected]> Reviewed-by: Aneesh Kumar K.V <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2019-04-09Bluetooth: btusb: request wake pin with NOAUTOENBrian Norris1-1/+1
Badly-designed systems might have (for example) active-high wake pins that default to high (e.g., because of external pull ups) until they have an active firmware which starts driving it low. This can cause an interrupt storm in the time between request_irq() and disable_irq(). We don't support shared interrupts here, so let's just pre-configure the interrupt to avoid auto-enabling it. Fixes: fd913ef7ce61 ("Bluetooth: btusb: Add out-of-band wakeup support") Fixes: 5364a0b4f4be ("arm64: dts: rockchip: move QCA6174A wakeup pin into its USB node") Signed-off-by: Brian Norris <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-09Merge tag 'mips_fixes_5.1_2' of ↵Linus Torvalds3-3/+11
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux Pull MIPS fixes from Paul Burton: "A few minor MIPS fixes: - Provide struct pt_regs * from get_irq_regs() to kgdb_nmicallback() when handling an IPI triggered by kgdb_roundup_cpus(), matching the behavior of other architectures & resolving kgdb issues for SMP systems. - Defer a pointer dereference until after a NULL check in the irq_shutdown callback for SGI IP27 HUB interrupts. - A defconfig update for the MSCC Ocelot to enable some necessary drivers" * tag 'mips_fixes_5.1_2' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: MIPS: generic: Add switchdev, pinctrl and fit to ocelot_defconfig MIPS: SGI-IP27: Fix use of unchecked pointer in shutdown_bridge_irq MIPS: KGDB: fix kgdb support for SMP platforms.
2019-04-09Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds2-2/+6
Pull misc fixes from Al Viro: "A few regression fixes from this cycle" * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: aio: use kmem_cache_free() instead of kfree() iov_iter: Fix build error without CONFIG_CRYPTO aio: Fix an error code in __io_submit_one()
2019-04-09drm/mediatek: no change parent rate in round_rate() for MT2701 hdmi phyWangyan Wang4-16/+20
This is the third step to make MT2701 HDMI stable. We should not change the rate of parent for hdmi phy when doing round_rate for this clock. The parent clock of hdmi phy must be the same as it. We change it when doing set_rate only. Signed-off-by: Wangyan Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
2019-04-09drm/mediatek: using new factor for tvdpll for MT2701 hdmi phyWangyan Wang1-5/+3
This is the second step to make MT2701 HDMI stable. The factor depends on the divider of DPI in MT2701, therefore, we should fix this factor to the right and new one. Test: search ok Signed-off-by: Wangyan Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
2019-04-09drm/mediatek: remove flag CLK_SET_RATE_PARENT for MT2701 hdmi phyWangyan Wang4-8/+8
This is the first step to make MT2701 hdmi stable. The parent rate of hdmi phy had set by DPI driver. We should not set or change the parent rate of MT2701 hdmi phy, as a result we should remove the flags of "CLK_SET_RATE_PARENT" from the clock of MT2701 hdmi phy. Signed-off-by: Wangyan Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
2019-04-09drm/mediatek: make implementation of recalc_rate() for MT2701 hdmi phyWangyan Wang4-14/+42
Recalculate the rate of this clock, by querying hardware to make implementation of recalc_rate() to match the definition. Signed-off-by: Wangyan Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
2019-04-09drm/mediatek: fix the rate and divder of hdmi phy for MT2701Wangyan Wang1-2/+2
Due to a clerical error,there is one zero less for 12800000. Fix it for 128000000 Fixes: 0fc721b2968e ("drm/mediatek: add hdmi driver for MT2701 and MT7623") Signed-off-by: Wangyan Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
2019-04-09ACPICA: Namespace: remove address node from global list after method terminationErik Schmauss1-0/+4
ACPICA commit b233720031a480abd438f2e9c643080929d144c3 ASL operation_regions declare a range of addresses that it uses. In a perfect world, the range of addresses should be used exclusively by the AML interpreter. The OS can use this information to decide which drivers to load so that the AML interpreter and device drivers use different regions of memory. During table load, the address information is added to a global address range list. Each node in this list contains an address range as well as a namespace node of the operation_region. This list is deleted at ACPI shutdown. Unfortunately, ASL operation_regions can be declared inside of control methods. Although this is not recommended, modern firmware contains such code. New module level code changes unintentionally removed the functionality of adding and removing nodes to the global address range list. A few months ago, support for adding addresses has been re- implemented. However, the removal of the address range list was missed and resulted in some systems to crash due to the address list containing bogus namespace nodes from operation_regions declared in control methods. In order to fix the crash, this change removes dynamic operation_regions after control method termination. Link: https://github.com/acpica/acpica/commit/b2337200 Link: https://bugzilla.kernel.org/show_bug.cgi?id=202475 Fixes: 4abb951b73ff ("ACPICA: AML interpreter: add region addresses in global list during initialization") Reported-by: Michael J Gruber <[email protected]> Signed-off-by: Erik Schmauss <[email protected]> Signed-off-by: Bob Moore <[email protected]> Cc: 4.20+ <[email protected]> # 4.20+ Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-04-09drm/mediatek: fix possible object reference leakWen Yang1-0/+1
The call to of_parse_phandle returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/gpu/drm/mediatek/mtk_hdmi.c:1521:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1509, but without a corresponding object release within this function. drivers/gpu/drm/mediatek/mtk_hdmi.c:1524:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1509, but without a corresponding object release within this function. Signed-off-by: Wen Yang <[email protected]> Cc: CK Hu <[email protected]> Cc: Philipp Zabel <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: CK Hu <[email protected]>
2019-04-08drm/i915: Get power refs in encoder->get_power_domains()Imre Deak4-38/+35
Push getting the reference for the encoders' power domains into the encoder get_power_domains() hook instead of doing this from the caller. This way the encoder can store away the corresponding wakerefs. This fixes the DSI encoder disabling, which didn't release these power references it acquired during HW state readout. Note that longtime ownership for the corresponding wakerefs can be thus acquired / released in two ways. Nevertheless there is always only one owner for them: After HW readout (booting/system resume): - encoder->get_power_domains() acquires - encoder->disable*() releases After a modeset (calling intel_atomic_commit()): - encoder->enable*() acquires - encoder->disable*() releases * can be any of the encoder enable/disable hooks. v2: - Check that the DSI io_wakerefs are unset both during encoder HW readout and enabling. (Chris) Fixes: 0e6e0be4c9523 ("drm/i915: Markup paired operations on display power domains") Cc: Vandita Kulkarni <[email protected]> Cc: Chris Wilson <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 3a52fb7e7953f0b13df8c05d0d74b56a66888f30) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-04-08Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds14-28/+89
Pull networking fixes from David Miller: 1) Off by one and bounds checking fixes in NFC, from Dan Carpenter. 2) There have been many weird regressions in r8169 since we turned ASPM support on, some are still not understood nor completely resolved. Let's turn this back off for now. From Heiner Kallweit. 3) Signess fixes for ethtool speed value handling, from Michael Zhivich. 4) Handle timestamps properly in macb driver, from Paul Thomas. 5) Two erspan fixes, it's the usual "skb ->data potentially reallocated and we're holding a stale protocol header pointer". From Lorenzo Bianconi. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: bnxt_en: Reset device on RX buffer errors. bnxt_en: Improve RX consumer index validity check. net: macb driver, check for SKBTX_HW_TSTAMP qlogic: qlcnic: fix use of SPEED_UNKNOWN ethtool constant broadcom: tg3: fix use of SPEED_UNKNOWN ethtool constant ethtool: avoid signed-unsigned comparison in ethtool_validate_speed() net: ip6_gre: fix possible use-after-free in ip6erspan_rcv net: ip_gre: fix possible use-after-free in erspan_rcv r8169: disable ASPM again MAINTAINERS: ieee802154: update documentation file pattern net: vrf: Fix ping failed when vrf mtu is set to 0 selftests: add a tc matchall test case nfc: nci: Potential off by one in ->pipes[] array NFC: nci: Add some bounds checking in nci_hci_cmd_received()
2019-04-08Merge branch 'fixes-v5.1' of ↵Linus Torvalds7-21/+108
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security Pull TPM fixes from James Morris: "From Jarkko: These are critical fixes for v5.1. Contains also couple of new selftests for v5.1 features (partial reads in /dev/tpm0)" * 'fixes-v5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: selftests/tpm2: Open tpm dev in unbuffered mode selftests/tpm2: Extend tests to cover partial reads KEYS: trusted: fix -Wvarags warning tpm: Fix the type of the return value in calc_tpm2_event_size() KEYS: trusted: allow trusted.ko to initialize w/o a TPM tpm: fix an invalid condition in tpm_common_poll tpm: turn on TPM on suspend for TPM 1.x
2019-04-08Merge tag 'xtensa-20190408' of git://github.com/jcmvbkbc/linux-xtensaLinus Torvalds4-11/+24
Pull xtensa fixes from Max Filippov: - fix syscall number passed to trace_sys_exit - fix syscall number initialization in start_thread - fix level interpretation in the return_address - fix format string warning in init_pmd * tag 'xtensa-20190408' of git://github.com/jcmvbkbc/linux-xtensa: xtensa: fix format string warning in init_pmd xtensa: fix return_address xtensa: fix initialization of pt_regs::syscall in start_thread xtensa: use actual syscall number in do_syscall_trace_leave
2019-04-08scsi: csiostor: fix missing data copy in csio_scsi_err_handler()Varun Prakash1-1/+4
If scsi cmd sglist is not suitable for DDP then csiostor driver uses preallocated buffers for DDP, because of this data copy is required from DDP buffer to scsi cmd sglist before calling ->scsi_done(). Signed-off-by: Varun Prakash <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-04-08Merge branch 'bnxt_en-fixes'David S. Miller1-3/+13
Michael Chan says: ==================== bnxt_en: 2 bug fixes. The first patch prevents possible driver crash if we get a bad RX index from the hardware. The second patch resets the device when the hardware reports buffer error to recover from the error. Please queue these for -stable also. Thanks. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-04-08bnxt_en: Reset device on RX buffer errors.Michael Chan1-0/+6
If the RX completion indicates RX buffers errors, the RX ring will be disabled by firmware and no packets will be received on that ring from that point on. Recover by resetting the device. Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-04-08bnxt_en: Improve RX consumer index validity check.Michael Chan1-3/+7
There is logic to check that the RX/TPA consumer index is the expected index to work around a hardware problem. However, the potentially bad consumer index is first used to index into an array to reference an entry. This can potentially crash if the bad consumer index is beyond legal range. Improve the logic to use the consumer index for dereferencing after the validity check and log an error message. Fixes: fa7e28127a5a ("bnxt_en: Add workaround to detect bad opaque in rx completion (part 2)") Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-04-08net: macb driver, check for SKBTX_HW_TSTAMPPaul Thomas1-1/+3
Make sure SKBTX_HW_TSTAMP (i.e. SOF_TIMESTAMPING_TX_HARDWARE) has been enabled for this skb. It does fix the issue where normal socks that aren't expecting a timestamp will not wake up on select, but when a user does want a SOF_TIMESTAMPING_TX_HARDWARE it does work. Signed-off-by: Paul Thomas <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-04-08Merge branch 'ethtool-fix-use-of-SPEED_UNKNOWN-constant'David S. Miller4-8/+8
Michael Zhivich says: ==================== ethtool: fix use of SPEED_UNKNOWN constant This patch series addresses 2 related issues: 1. ethtool_validate_speed() triggers a "signed-unsigned comparison" warning due to type difference of SPEED_UNKNOWN constant (int) and argument to ethtool_validate_speed (__u32). 2. some drivers use u16 storage for SPEED_UNKNOWN constant, resulting in value truncation and thus failure to test against SPEED_UNKNOWN correctly. This revised series addresses several feedback comments: - split up the patch in to series - do not unnecessarily change drivers that use "int" storage for speed values ==================== Signed-off-by: David S. Miller <[email protected]>
2019-04-08qlogic: qlcnic: fix use of SPEED_UNKNOWN ethtool constantMichael Zhivich1-1/+1
qlcnic driver uses u16 to store SPEED_UKNOWN ethtool constant, which is defined as -1, resulting in value truncation and thus incorrect test results against SPEED_UNKNOWN. For example, the following test will print "False": u16 speed = SPEED_UNKNOWN; if (speed == SPEED_UNKNOWN) printf("True"); else printf("False"); Change storage of speed to use u32 to avoid this issue. Signed-off-by: Michael Zhivich <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-04-08broadcom: tg3: fix use of SPEED_UNKNOWN ethtool constantMichael Zhivich2-6/+6
tg3 driver uses u16 to store SPEED_UKNOWN ethtool constant, which is defined as -1, resulting in value truncation and thus incorrect test results against SPEED_UNKNOWN. For example, the following test will print "False": u16 speed = SPEED_UNKNOWN; if (speed == SPEED_UNKNOWN) printf("True"); else printf("False"); Change storage of speed to use u32 to avoid this issue. Signed-off-by: Michael Zhivich <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-04-08ethtool: avoid signed-unsigned comparison in ethtool_validate_speed()Michael Zhivich1-1/+1
When building C++ userspace code that includes ethtool.h with "-Werror -Wall", g++ complains about signed-unsigned comparison in ethtool_validate_speed() due to definition of SPEED_UNKNOWN as -1. Explicitly cast SPEED_UNKNOWN to __u32 to match type of ethtool_validate_speed() argument. Signed-off-by: Michael Zhivich <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-04-08Merge branch 'erspan-use-after-free'David S. Miller2-12/+23
Lorenzo Bianconi says: ==================== fix possible use-after-free in erspan_v{4,6} Similar to what I did in commit bb9bd814ebf0 ("ipv6: sit: reset ip header pointer in ipip6_rcv"), fix possible use-after-free in erspan_rcv and ip6erspan_rcv extracting tunnel metadata since the packet can be 'uncloned' running __iptunnel_pull_header ==================== Signed-off-by: David S. Miller <[email protected]>
2019-04-08net: ip6_gre: fix possible use-after-free in ip6erspan_rcvLorenzo Bianconi1-7/+13
erspan_v6 tunnels run __iptunnel_pull_header on received skbs to remove erspan header. This can determine a possible use-after-free accessing pkt_md pointer in ip6erspan_rcv since the packet will be 'uncloned' running pskb_expand_head if it is a cloned gso skb (e.g if the packet has been sent though a veth device). Fix it resetting pkt_md pointer after __iptunnel_pull_header Fixes: 1d7e2ed22f8d ("net: erspan: refactor existing erspan code") Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-04-08net: ip_gre: fix possible use-after-free in erspan_rcvLorenzo Bianconi1-5/+10
erspan tunnels run __iptunnel_pull_header on received skbs to remove gre and erspan headers. This can determine a possible use-after-free accessing pkt_md pointer in erspan_rcv since the packet will be 'uncloned' running pskb_expand_head if it is a cloned gso skb (e.g if the packet has been sent though a veth device). Fix it resetting pkt_md pointer after __iptunnel_pull_header Fixes: 1d7e2ed22f8d ("net: erspan: refactor existing erspan code") Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-04-08selftests/tpm2: Open tpm dev in unbuffered modeTadeusz Struk1-2/+2
In order to have control over how many bytes are read or written the device needs to be opened in unbuffered mode. Signed-off-by: Tadeusz Struk <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: James Morris <[email protected]>
2019-04-08selftests/tpm2: Extend tests to cover partial readsTadeusz Struk2-0/+64
Three new tests added: 1. Send get random cmd, read header in 1st read, read the rest in second read - expect success 2. Send get random cmd, read only part of the response, send another get random command, read the response - expect success 3. Send get random cmd followed by another get random cmd, without reading the first response - expect the second cmd to fail with -EBUSY Signed-off-by: Tadeusz Struk <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: James Morris <[email protected]>
2019-04-08KEYS: trusted: fix -Wvarags warning[email protected]2-3/+3
Fixes the warning reported by Clang: security/keys/trusted.c:146:17: warning: passing an object that undergoes default argument promotion to 'va_start' has undefined behavior [-Wvarargs] va_start(argp, h3); ^ security/keys/trusted.c:126:37: note: parameter of type 'unsigned char' is declared here unsigned char *h2, unsigned char h3, ...) ^ Specifically, it seems that both the C90 (4.8.1.1) and C11 (7.16.1.4) standards explicitly call this out as undefined behavior: The parameter parmN is the identifier of the rightmost parameter in the variable parameter list in the function definition (the one just before the ...). If the parameter parmN is declared with ... or with a type that is not compatible with the type that results after application of the default argument promotions, the behavior is undefined. Link: https://github.com/ClangBuiltLinux/linux/issues/41 Link: https://www.eskimo.com/~scs/cclass/int/sx11c.html Suggested-by: David Laight <[email protected]> Suggested-by: Denis Kenzior <[email protected]> Suggested-by: James Bottomley <[email protected]> Suggested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: James Morris <[email protected]>
2019-04-08tpm: Fix the type of the return value in calc_tpm2_event_size()Yue Haibing1-2/+2
calc_tpm2_event_size() has an invalid signature because it returns a 'size_t' where as its signature says that it returns 'int'. Cc: <[email protected]> Fixes: 4d23cc323cdb ("tpm: add securityfs support for TPM 2.0 firmware event log") Suggested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Yue Haibing <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: James Morris <[email protected]>
2019-04-08KEYS: trusted: allow trusted.ko to initialize w/o a TPMJarkko Sakkinen1-5/+23
Allow trusted.ko to initialize w/o a TPM. This commit also adds checks to the exported functions to fail when a TPM is not available. Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure...") Cc: James Morris <[email protected]> Reported-by: Dan Williams <[email protected]> Tested-by: Dan Williams <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: James Morris <[email protected]>
2019-04-08tpm: fix an invalid condition in tpm_common_pollTadeusz Struk1-1/+8
The poll condition should only check response_length, because reads should only be issued if there is data to read. The response_read flag only prevents double writes. The problem was that the write set the response_read to false, enqued a tpm job, and returned. Then application called poll which checked the response_read flag and returned EPOLLIN. Then the application called read, but got nothing. After all that the async_work kicked in. Added also mutex_lock around the poll check to prevent other possible race conditions. Fixes: 9488585b21bef0df12 ("tpm: add support for partial reads") Reported-by: Mantas Mikulėnas <[email protected]> Tested-by: Mantas Mikulėnas <[email protected]> Signed-off-by: Tadeusz Struk <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: James Morris <[email protected]>
2019-04-08tpm: turn on TPM on suspend for TPM 1.xJarkko Sakkinen1-8/+6
tpm_chip_start/stop() should be also called for TPM 1.x devices on suspend. Add that functionality back. Do not lock the chip because it is unnecessary as there are no multiple threads using it when doing the suspend. Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") Reported-by: Paul Zimmerman <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Tested-by: Domenico Andreoli <[email protected]> Signed-off-by: James Morris <[email protected]>
2019-04-08r8169: disable ASPM againHeiner Kallweit1-0/+6
There's a significant number of reports that re-enabling ASPM causes different issues, ranging from decreased performance to system not booting at all. This affects only a minority of users, but the number of affected users is big enough that we better switch off ASPM again. This will hurt notebook users who are not affected by the issues, they may see decreased battery runtime w/o ASPM. With the PCI core folks is being discussed to add generic sysfs attributes to control ASPM. Once this is in place brave enough users can re-enable ASPM on their system. Fixes: a99790bf5c7f ("r8169: Reinstate ASPM Support") Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.