aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-05-24arm64: insn: Fix ldadd instruction encodingJean-Philippe Brucker1-1/+1
GCC 8.1.0 reports that the ldadd instruction encoding, recently added to insn.c, doesn't match the mask and couldn't possibly be identified: linux/arch/arm64/include/asm/insn.h: In function 'aarch64_insn_is_ldadd': linux/arch/arm64/include/asm/insn.h:280:257: warning: bitwise comparison always evaluates to false [-Wtautological-compare] Bits [31:30] normally encode the size of the instruction (1 to 8 bytes) and the current instruction value only encodes the 4- and 8-byte variants. At the moment only the BPF JIT needs this instruction, and doesn't require the 1- and 2-byte variants, but to be consistent with our other ldr and str instruction encodings, clear the size field in the insn value. Fixes: 34b8ab091f9ef57a ("bpf, arm64: use more scalable stadd over ldxr / stxr loop in xadd") Acked-by: Daniel Borkmann <[email protected]> Reported-by: Kuninori Morimoto <[email protected]> Signed-off-by: Yoshihiro Shimoda <[email protected]> Signed-off-by: Jean-Philippe Brucker <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-05-24arm64: Kconfig: Make ARM64_PSEUDO_NMI depend on BROKEN for nowWill Deacon1-0/+1
Although we merged support for pseudo-nmi using interrupt priority masking in 5.1, we've since uncovered a number of non-trivial issues with the implementation. Although there are patches pending to address these problems, we're facing issues that prevent us from merging them at this current time: https://lkml.kernel.org/r/[email protected] For now, simply mark this optional feature as BROKEN in the hope that we can fix things properly in the near future. Cc: <[email protected]> # 5.1 Cc: Julien Thierry <[email protected]> Acked-by: Marc Zyngier <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-05-24KVM: arm/arm64: Move cc/it checks under hyp's Makefile to avoid instrumentationJames Morse4-121/+138
KVM has helpers to handle the condition codes of trapped aarch32 instructions. These are marked __hyp_text and used from HYP, but they aren't built by the 'hyp' Makefile, which has all the runes to avoid ASAN and KCOV instrumentation. Move this code to a new hyp/aarch32.c to avoid a hyp-panic when starting an aarch32 guest on a host built with the ASAN/KCOV debug options. Fixes: 021234ef3752f ("KVM: arm64: Make kvm_condition_valid32() accessible from EL2") Fixes: 8cebe750c4d9a ("arm64: KVM: Make kvm_skip_instr32 available to HYP") Signed-off-by: James Morse <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2019-05-24KVM: arm64: Move pmu hyp code under hyp's Makefile to avoid instrumentationJames Morse3-41/+39
KVM's pmu.c contains the __hyp_text needed to switch the pmu registers between host and guest. Because this isn't covered by the 'hyp' Makefile, it can be built with kasan and friends when these are enabled in Kconfig. When starting a guest, this results in: | Kernel panic - not syncing: HYP panic: | PS:a00003c9 PC:000083000028ada0 ESR:86000007 | FAR:000083000028ada0 HPFAR:0000000029df5300 PAR:0000000000000000 | VCPU:000000004e10b7d6 | CPU: 0 PID: 3088 Comm: qemu-system-aar Not tainted 5.2.0-rc1 #11026 | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Plat | Call trace: | dump_backtrace+0x0/0x200 | show_stack+0x20/0x30 | dump_stack+0xec/0x158 | panic+0x1ec/0x420 | panic+0x0/0x420 | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x002,25006082 | Memory Limit: none | ---[ end Kernel panic - not syncing: HYP panic: This is caused by functions in pmu.c calling the instrumented code, which isn't mapped to hyp. From objdump -r: | RELOCATION RECORDS FOR [.hyp.text]: | OFFSET TYPE VALUE | 0000000000000010 R_AARCH64_CALL26 __sanitizer_cov_trace_pc | 0000000000000018 R_AARCH64_CALL26 __asan_load4_noabort | 0000000000000024 R_AARCH64_CALL26 __asan_load4_noabort Move the affected code to a new file under 'hyp's Makefile. Fixes: 3d91befbb3a0 ("arm64: KVM: Enable !VHE support for :G/:H perf event modifiers") Cc: Andrew Murray <[email protected]> Signed-off-by: James Morse <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2019-05-24MAINTAINERS: KVM: arm/arm64: Remove myself as maintainerChristoffer Dall1-2/+0
I no longer have time to actively review patches and manage the tree and it's time to make that official. Huge thanks to the incredible Linux community and all the contributors who have put up with me over the past years. I also take this opportunity to remove the website link to the Columbia web page, as that information is no longer up to date and I don't know who manages that anymore. Signed-off-by: Christoffer Dall <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2019-05-24Revert "drm/amd/display: Don't load DMCU for Raven 1"Dave Airlie1-10/+2
This reverts commit 55143dc23ca4792868ea8c17bce65ca7b3d3e8c4. This causes build breakags with some Kconfigs so revert for now. Fixes: 55143dc23ca4 ("drm/amd/display: Don't load DMCU for Raven 1") Signed-off-by: Dave Airlie <[email protected]>
2019-05-24gpio: fix gpio-adp5588 build errorsRandy Dunlap1-0/+1
The gpio-adp5588 driver uses interfaces that are provided by GPIOLIB_IRQCHIP, so select that symbol in its Kconfig entry. Fixes these build errors: ../drivers/gpio/gpio-adp5588.c: In function ‘adp5588_irq_handler’: ../drivers/gpio/gpio-adp5588.c:266:26: error: ‘struct gpio_chip’ has no member named ‘irq’ dev->gpio_chip.irq.domain, gpio)); ^ ../drivers/gpio/gpio-adp5588.c: In function ‘adp5588_irq_setup’: ../drivers/gpio/gpio-adp5588.c:298:2: error: implicit declaration of function ‘gpiochip_irqchip_add_nested’ [-Werror=implicit-function-declaration] ret = gpiochip_irqchip_add_nested(&dev->gpio_chip, ^ ../drivers/gpio/gpio-adp5588.c:307:2: error: implicit declaration of function ‘gpiochip_set_nested_irqchip’ [-Werror=implicit-function-declaration] gpiochip_set_nested_irqchip(&dev->gpio_chip, ^ Fixes: 459773ae8dbb ("gpio: adp5588-gpio: support interrupt controller") Reported-by: kbuild test robot <[email protected]> Signed-off-by: Randy Dunlap <[email protected]> Cc: [email protected] Reviewed-by: Bartosz Golaszewski <[email protected]> Acked-by: Michael Hennerich <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2019-05-24pinctrl: stmfx: Fix compile issue when CONFIG_OF_GPIO is not definedAmelie Delaunay1-1/+1
When CONFIG_GPIO_OF is not defined, struct gpio_chip 'of_node' member does not exist: drivers/pinctrl/pinctrl-stmfx.c: In function 'stmfx_pinctrl_probe': drivers/pinctrl/pinctrl-stmfx.c:652:17: error: 'struct gpio_chip' has no member named 'of_node' pctl->gpio_chip.of_node = np; Fixes: 1490d9f841b1 ("pinctrl: Add STMFX GPIO expander Pinctrl/GPIO driver") Reported-by: kbuild test robot <[email protected]> Signed-off-by: Amelie Delaunay <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2019-05-24staging: kpc2000: Add dependency on MFD_CORE to kconfig symbol 'KPC2000'Geordan Neukum1-0/+1
The kpc2000 core makes calls against functions conditionally exported upon selection of the kconfig symbol MFD_CORE. Therefore, the kpc2000 core depends upon the mfd_core, and that dependency must be tracked in Kconfig to avoid potential build issues. Signed-off-by: Geordan Neukum <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-05-24ALSA: hda/realtek - Enable micmute LED for Huawei laptopsAyman Bagabas1-5/+4
Since this LED is found on all Huawei laptops, we can hook it to huawei-wmi platform driver to control it. Also, some renames have been made to use product name instead of common name to avoid confusions. Fixes: 8ac51bbc4cfe ("ALSA: hda: fix front speakers on Huawei MBXP") Signed-off-by: Ayman Bagabas <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2019-05-23thermal: rcar_gen3_thermal: Update temperature conversion methodYoshihiro Kaneko1-10/+18
Update the formula to calculate temperature: Currently, current TEMP is calculated as average of val1 (is calculated by formula 1) and val2 (is calculated by formula 2). But, as description in HWM (chapter 10A.3.1.2 Normal Mode.) If (TEMP_CODE < THCODE2[11:0]) CTEMP value should be val1. If (TEMP_CODE > THCODE2[11:0]) CTEMP value should be val2. Signed-off-by: Yoshihiro Kaneko <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2019-05-23thermal: rcar_gen3_thermal: Update calculation formula of IRQTEMPYoshihiro Kaneko1-16/+17
Update the formula to calculate CTEMP: Currently, the CTEMP is average of val1 (is calculated by formula 1) and val2 (is calculated by formula 2). But, as description in HWM (chapter 10A.3.1.1 Setting of Normal Mode) If (STEMP < Tj_T) CTEMP value should be val1. If (STEMP > Tj_T) CTEMP value should be val2. Signed-off-by: Yoshihiro Kaneko <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2019-05-23thermal: rcar_gen3_thermal: Update value of Tj_1Yoshihiro Kaneko1-11/+30
As evaluation of hardware team, temperature calculation formula of M3-W is difference from all other SoCs as below: - M3-W: Tj_1: 116 (so Tj_1 - Tj_3 = 157) - Others: Tj_1: 126 (so Tj_1 - Tj_3 = 167) Signed-off-by: Yoshihiro Kaneko <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2019-05-23thermal: tegra: Make tegra210_tsensor_thermtrips staticYueHaibing1-1/+1
Fix sparse warning: drivers/thermal/tegra/tegra210-soctherm.c:211:33: warning: symbol 'tegra210_tsensor_thermtrips' was not declared. Should it be static? Reported-by: Hulk Robot <[email protected]> Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2019-05-23Revert "thermal: rockchip: fix up the tsadc pinctrl setting error"Heiko Stuebner1-33/+3
This reverts commit 28694e009e512451ead5519dd801f9869acb1f60. The commit causes multiple issues in that: - the added call to ->control does potentially run unclocked causing a hang of the machine - the added pinctrl-states are undocumented in the binding - the added pinctrl-states are not backwards compatible, breaking old devicetrees. Fixes: 28694e009e51 ("thermal: rockchip: fix up the tsadc pinctrl setting error") Signed-off-by: Heiko Stuebner <[email protected]> Reported-by: kernelci.org bot <[email protected]> Reported-by: Enric Balletbo Serra <[email protected]> Reported-by: Vicente Bergas <[email protected]> Reported-by: Jack Mitchell <[email protected]> Reported-by: Douglas Anderson <[email protected]> Tested-by: Douglas Anderson <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2019-05-24Merge tag 'drm-intel-fixes-2019-05-23' of ↵Dave Airlie11-196/+202
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fix boosting of new client to be non-preemptive - Fix to actually bump ready tasks ahead of busywaits - Includes gvt-fixes-2019-05-21 Signed-off-by: Dave Airlie <[email protected]> From: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-23ext4: do not delete unlinked inode from orphan list on failed truncateJan Kara1-1/+1
It is possible that unlinked inode enters ext4_setattr() (e.g. if somebody calls ftruncate(2) on unlinked but still open file). In such case we should not delete the inode from the orphan list if truncate fails. Note that this is mostly a theoretical concern as filesystem is corrupted if we reach this path anyway but let's be consistent in our orphan handling. Reviewed-by: Ira Weiny <[email protected]> Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected]
2019-05-23ext4: wait for outstanding dio during truncate in nojournal modeJan Kara1-12/+9
We didn't wait for outstanding direct IO during truncate in nojournal mode (as we skip orphan handling in that case). This can lead to fs corruption or stale data exposure if truncate ends up freeing blocks and these get reallocated before direct IO finishes. Fix the condition determining whether the wait is necessary. CC: [email protected] Fixes: 1c9114f9c0f1 ("ext4: serialize unlocked dio reads with truncate") Reviewed-by: Ira Weiny <[email protected]> Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]>
2019-05-23Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller13-63/+375
Pablo Neira Ayuso says: ==================== Netfilter/IPVS fixes for net The following patchset contains Netfilter/IPVS fixes for your net tree: 1) Fix crash when dumping rules after conversion to RCU, from Florian Westphal. 2) Fix incorrect hook reinjection from nf_queue in case NF_REPEAT, from Jagdish Motwani. 3) Fix check for route existence in fib extension, from Phil Sutter. 4) Fix use after free in ip_vs_in() hook, from YueHaibing. 5) Check for veth existence from netfilter selftests, from Jeffrin Jose T. 6) Checksum corruption in UDP NAT helpers due to typo, from Florian Westphal. 7) Pass up packets to classic forwarding path regardless of IPv4 DF bit, patch for the flowtable infrastructure from Florian. 8) Set liberal TCP tracking for flows that are placed in the flowtable, in case they need to go back to classic forwarding path, also from Florian. 9) Don't add flow with sequence adjustment to flowtable, from Florian. 10) Skip IPv4 options from IPv6 datapath in flowtable, from Florian. 11) Add selftest for the flowtable infrastructure, from Florian. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-05-23Merge tag 'xfs-5.2-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds3-0/+27
Pull xfs fix from Darrick Wong: "Fix an accounting mistake where we included the log space when calculating the reserve space for metadata expansion" * tag 'xfs-5.2-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: don't reserve per-AG space for an internal log
2019-05-23cxgb4: offload VLAN flows regardless of VLAN ethtypeRaju Rangoju1-2/+3
VLAN flows never get offloaded unless ivlan_vld is set in filter spec. It's not compulsory for vlan_ethtype to be set. So, always enable ivlan_vld bit for offloading VLAN flows regardless of vlan_ethtype is set or not. Fixes: ad9af3e09c (cxgb4: add tc flower match support for vlan) Signed-off-by: Raju Rangoju <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-23hsr: fix don't prune the master node from the node_dbAndreas Oetken1-0/+8
Don't prune the master node in the hsr_prune_nodes function. Neither time_in[HSR_PT_SLAVE_A] nor time_in[HSR_PT_SLAVE_B] will ever be updated by hsr_register_frame_in for the master port. Thus, the master node will be repeatedly pruned leading to repeated packet loss. This bug never appeared because the hsr_prune_nodes function was only called once. Since commit 5150b45fd355 ("net: hsr: Fix node prune function for forget time expiry") this issue is fixed unveiling the issue described above. Fixes: 5150b45fd355 ("net: hsr: Fix node prune function for forget time expiry") Signed-off-by: Andreas Oetken <[email protected]> Tested-by: Murali Karicheri <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-23Merge branch 'nvme-5.2-rc2' of git://git.infradead.org/nvme into for-linusJens Axboe4-42/+77
Pull NVMe changes from Keith. * 'nvme-5.2-rc2' of git://git.infradead.org/nvme: nvme-pci: use blk-mq mapping for unmanaged irqs nvme: update MAINTAINERS nvme: copy MTFA field from identify controller nvme: fix memory leak for power latency tolerance nvme: release namespace SRCU protection before performing controller ioctls nvme: merge nvme_ns_ioctl into nvme_ioctl nvme: remove the ifdef around nvme_nvm_ioctl nvme: fix srcu locking on error return in nvme_get_ns_from_disk nvme: Fix known effects nvme-pci: Sync queues on reset nvme-pci: Unblock reset_work on IO failure nvme-pci: Don't disable on timeout in reset state nvme-pci: Fix controller freeze wait disabling
2019-05-23tools/io_uring: sync with liburingJens Axboe5-61/+118
Various fixes and changes have been applied to liburing since we copied some select bits to the kernel testing/examples part, sync up with liburing to get those changes. Most notable is the change that split the CQE reading into the peek and seen event, instead of being just a single function. Also fixes an unsigned wrap issue in io_uring_submit(), leak of 'fd' in setup if we fail, and various other little issues. Signed-off-by: Jens Axboe <[email protected]>
2019-05-23tools/io_uring: fix Makefile for pthread library linkJens Axboe1-1/+1
Currently fails with: io_uring-bench.o: In function `main': /home/axboe/git/linux-block/tools/io_uring/io_uring-bench.c:560: undefined reference to `pthread_create' /home/axboe/git/linux-block/tools/io_uring/io_uring-bench.c:588: undefined reference to `pthread_join' collect2: error: ld returned 1 exit status Makefile:11: recipe for target 'io_uring-bench' failed make: *** [io_uring-bench] Error 1 Move -lpthread to the end. Signed-off-by: Jens Axboe <[email protected]>
2019-05-23blk-mq: fix hang caused by freeze/unfreeze sequenceBob Liu3-11/+18
The following is a description of a hang in blk_mq_freeze_queue_wait(). The hang happens on attempt to freeze a queue while another task does queue unfreeze. The root cause is an incorrect sequence of percpu_ref_resurrect() and percpu_ref_kill() and as a result those two can be swapped: CPU#0 CPU#1 ---------------- ----------------- q1 = blk_mq_init_queue(shared_tags) q2 = blk_mq_init_queue(shared_tags): blk_mq_add_queue_tag_set(shared_tags): blk_mq_update_tag_set_depth(shared_tags): list_for_each_entry() blk_mq_freeze_queue(q1) > percpu_ref_kill() > blk_mq_freeze_queue_wait() blk_cleanup_queue(q1) blk_mq_freeze_queue(q1) > percpu_ref_kill() ^^^^^^ freeze_depth can't guarantee the order blk_mq_unfreeze_queue() > percpu_ref_resurrect() > blk_mq_freeze_queue_wait() ^^^^^^ Hang here!!!! This wrong sequence raises kernel warning: percpu_ref_kill_and_confirm called more than once on blk_queue_usage_counter_release! WARNING: CPU: 0 PID: 11854 at lib/percpu-refcount.c:336 percpu_ref_kill_and_confirm+0x99/0xb0 But the most unpleasant effect is a hang of a blk_mq_freeze_queue_wait(), which waits for a zero of a q_usage_counter, which never happens because percpu-ref was reinited (instead of being killed) and stays in PERCPU state forever. How to reproduce: - "insmod null_blk.ko shared_tags=1 nr_devices=0 queue_mode=2" - cpu0: python Script.py 0; taskset the corresponding process running on cpu0 - cpu1: python Script.py 1; taskset the corresponding process running on cpu1 Script.py: ------ #!/usr/bin/python3 import os import sys while True: on = "echo 1 > /sys/kernel/config/nullb/%s/power" % sys.argv[1] off = "echo 0 > /sys/kernel/config/nullb/%s/power" % sys.argv[1] os.system(on) os.system(off) ------ This bug was first reported and fixed by Roman, previous discussion: [1] Message id: [email protected] [2] Message id: [email protected] [3] https://patchwork.kernel.org/patch/9268199/ Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Roman Pen <[email protected]> Signed-off-by: Bob Liu <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-23block: remove the bi_seg_{front,back}_size fields in struct bioChristoph Hellwig2-89/+12
At this point these fields aren't used for anything, so we can remove them. Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-23block: remove the segment size check in bio_will_gapChristoph Hellwig1-18/+1
We fundamentally do not have a maximum segement size for devices with a virt boundary. So don't bother checking it, especially given that the existing checks didn't properly work to start with as we never fully update the front/back segment size and miss the bi_seg_front_size that wuld have been required for some cases. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-23block: force an unlimited segment size on queues with a virt boundaryChristoph Hellwig1-0/+11
We currently fail to update the front/back segment size in the bio when deciding to allow an otherwise gappy segement to a device with a virt boundary. The reason why this did not cause problems is that devices with a virt boundary fundamentally don't use segments as we know it and thus don't care. Make that assumption formal by forcing an unlimited segement size in this case. Fixes: f6970f83ef79 ("block: don't check if adjacent bvecs in one bio can be mergeable") Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-23block: don't decrement nr_phys_segments for physically contigous segmentsChristoph Hellwig1-22/+1
Currently ll_merge_requests_fn, unlike all other merge functions, reduces nr_phys_segments by one if the last segment of the previous, and the first segment of the next segement are contigous. While this seems like a nice solution to avoid building smaller than possible requests it causes a mismatch between the segments actually present in the request and those iterated over by the bvec iterators, including __rq_for_each_bio. This can for example mistrigger the single segment optimization in the nvme-pci driver, and might lead to mismatching nr_phys_segments number when recalculating the number of request when inserting a cloned request. We could possibly work around this by making the bvec iterators take the front and back segment size into account, but that would require moving them from the bio to the bio_iter and spreading this mess over all users of bvecs. Or we could simply remove this optimization under the assumption that most users already build good enough bvecs, and that the bio merge patch never cared about this optimization either. The latter is what this patch does. dff824b2aadb ("nvme-pci: optimize mapping of small single segment requests"). Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-23sbitmap: fix improper use of smp_mb__before_atomic()Andrea Parri1-1/+1
This barrier only applies to the read-modify-write operations; in particular, it does not apply to the atomic_set() primitive. Replace the barrier with an smp_mb(). Fixes: 6c0ca7ae292ad ("sbitmap: fix wakeup hang after sbq resize") Cc: [email protected] Reported-by: "Paul E. McKenney" <[email protected]> Reported-by: Peter Zijlstra <[email protected]> Signed-off-by: Andrea Parri <[email protected]> Reviewed-by: Ming Lei <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Omar Sandoval <[email protected]> Cc: Ming Lei <[email protected]> Cc: [email protected] Cc: "Paul E. McKenney" <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-23bio: fix improper use of smp_mb__before_atomic()Andrea Parri1-1/+1
This barrier only applies to the read-modify-write operations; in particular, it does not apply to the atomic_set() primitive. Replace the barrier with an smp_mb(). Fixes: dac56212e8127 ("bio: skip atomic inc/dec of ->bi_cnt for most use cases") Cc: [email protected] Reported-by: "Paul E. McKenney" <[email protected]> Reported-by: Peter Zijlstra <[email protected]> Signed-off-by: Andrea Parri <[email protected]> Reviewed-by: Ming Lei <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Ming Lei <[email protected]> Cc: [email protected] Cc: "Paul E. McKenney" <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-23aoe: list new maintainer for aoe driverEd Cashin1-1/+1
Justin Sanders, who has extensive experience with ATA over Ethernet in general and AoE SCSI and block-device drivers in particular, is ready to take on the role of aoe maintainer. The driver needs a more active maintainer. Signed-off-by: Ed Cashin <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-23net: mvpp2: cls: Fix leaked ethtool_rx_flow_ruleMaxime Chevallier1-0/+3
The flow_rule is only used when configuring the classification tables, and should be free'd once we're done using it. The current code only frees it in the error path. Fixes: 90b509b39ac9 ("net: mvpp2: cls: Add Classification offload support") Signed-off-by: Maxime Chevallier <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-23docs: fix multiple doc build warnings in enumeration.rstJonathan Corbet1-1/+1
The conversion of acpi/enumeration.txt to RST included one markup error, leading to many warnings like: .../firmware-guide/acpi/enumeration.rst:430: WARNING: Unexpected indentation. Add the missing colon and create some peace. Fixes: c24bc66e8157 ("Documentation: ACPI: move enumeration.txt to firmware-guide/acpi and convert to reST") Cc: Changbin Du <[email protected]> Signed-off-by: Jonathan Corbet <[email protected]>
2019-05-23lib/list_sort: fix kerneldoc build errorJonathan Corbet1-1/+2
Commit 043b3f7b6388 ("lib/list_sort: simplify and remove MAX_LIST_LENGTH_BITS") added some useful kerneldoc info, but also broke the docs build: ./lib/list_sort.c:128: WARNING: Definition list ends without a blank line; unexpected unindent. ./lib/list_sort.c:161: WARNING: Unexpected indentation. ./lib/list_sort.c:162: WARNING: Block quote ends without a blank line; unexpected unindent. Fix the offending literal block and make the error go away. Fixes: 043b3f7b6388 ("lib/list_sort: simplify and remove MAX_LIST_LENGTH_BITS") Cc: George Spelvin <[email protected]> Signed-off-by: Jonathan Corbet <[email protected]>
2019-05-23docs: fix numaperf.rst and add it to the doc treeJonathan Corbet2-1/+2
Commit 13bac55ef7ae ("doc/mm: New documentation for memory performance") added numaperf.rst, but did not add it to the TOC tree. There was also an incorrectly marked literal block leading to this warning sequence: numaperf.rst:24: WARNING: Unexpected indentation. numaperf.rst:24: WARNING: Inline substitution_reference start-string without end-string. numaperf.rst:25: WARNING: Block quote ends without a blank line; unexpected unindent. Fix the block and add the file to the document tree. Fixes: 13bac55ef7ae ("doc/mm: New documentation for memory performance") Cc: Keith Busch <[email protected]> Reviewed-by: Mike Rapoport <[email protected]> Signed-off-by: Jonathan Corbet <[email protected]>
2019-05-23doc: Cope with the deprecation of AutoReporterJonathan Corbet1-8/+26
AutoReporter is going away; recent versions of sphinx emit a warning like: Documentation/sphinx/kerneldoc.py:125: RemovedInSphinx20Warning: AutodocReporter is now deprecated. Use sphinx.util.docutils.switch_source_input() instead. Make the switch. But switch_source_input() only showed up in 1.7, so we have to do ugly version checks to keep things working in older versions. Cc: [email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2019-05-23doc: Cope with Sphinx logging deprecationsJonathan Corbet3-21/+59
Recent versions of sphinx will emit messages like: Documentation/sphinx/kerneldoc.py:103: RemovedInSphinx20Warning: app.warning() is now deprecated. Use sphinx.util.logging instead. Switch to sphinx.util.logging to make this unsightly message go away. Alas, that interface was only added in version 1.6, so we have to add a version check to keep things working with older sphinxes. Cc: [email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2019-05-23Merge tag 'docs-5.2-fixes' of git://git.lwn.net/linuxLinus Torvalds3-3/+3
Pull documentation fixes from Jonathan Corbet: "A handful of fixes for a docs build problem, along with catching the spdxcheck.py script up with the current state of affairs" * tag 'docs-5.2-fixes' of git://git.lwn.net/linux: Documentation: kdump: fix minor typo scripts/spdxcheck.py: Add dual license subdirectory scripts/spdxcheck.py: Fix path to deprecated licenses counter: fix Documentation build error due to incorrect source file name
2019-05-23arm64: Handle erratum 1418040 as a superset of erratum 1188873Marc Zyngier5-21/+24
We already mitigate erratum 1188873 affecting Cortex-A76 and Neoverse-N1 r0p0 to r2p0. It turns out that revisions r0p0 to r3p1 of the same cores are affected by erratum 1418040, which has the same workaround as 1188873. Let's expand the range of affected revisions to match 1418040, and repaint all occurences of 1188873 to 1418040. Whilst we're there, do a bit of reformating in silicon-errata.txt and drop a now unnecessary dependency on ARM_ARCH_TIMER_OOL_WORKAROUND. Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-05-23arm64/module: deal with ambiguity in PRELxx relocation rangesArd Biesheuvel1-2/+14
The R_AARCH64_PREL16 and R_AARCH64_PREL32 relocations are documented as permitting a range of [-2^15 .. 2^16), resp. [-2^31 .. 2^32). It is also documented that this means we cannot detect overflow in some cases, which is bad. Since we always interpret the targets of these relocations as signed quantities (e.g., in the ksymtab handling code), let's tighten the overflow checks so that targets that are out of range for our signed interpretation of the relocated quantity get flagged. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-05-23ACPI/IORT: Fix build error when IOMMU_SUPPORT is disabledLorenzo Pieralisi1-118/+120
If IOMMU_SUPPORT is not enabled (and therefore IOMMU_API is not selected), struct iommu_fwspec is an empty struct and IOMMU_FWSPEC_PCI_RC_ATS is not defined, resulting in the following compilation errors: drivers/acpi/arm64/iort.c: In function iort_iommu_configure: drivers/acpi/arm64/iort.c:1079:21: error: struct iommu_fwspec has no member named flag: dev->iommu_fwspec->flags |= IOMMU_FWSPEC_PCI_RC_ATS; ^~ drivers/acpi/arm64/iort.c:1079:32: error: IOMMU_FWSPEC_PCI_RC_ATS undeclared (first use in this function) dev->iommu_fwspec->flags |= IOMMU_FWSPEC_PCI_RC_ATS; ^~~~~~~~~~~~~~~~~~~~~~~ drivers/acpi/arm64/iort.c:1079:32: note: each undeclared identifier is reported only once for each function it appears in Move iort_iommu_configure() (and the helpers functions it relies on) into CONFIG_IOMMU_API preprocessor guarded code so that when CONFIG_IOMMU_SUPPORT is not enabled we prevent compiling code that is basically equivalent to no-OP, fixing the build errors. Cc: Jean-Philippe Brucker <[email protected]> Cc: Will Deacon <[email protected]> Cc: Robin Murphy <[email protected]> Link: https://lore.kernel.org/linux-arm-kernel/[email protected]/ Fixes: 5702ee24182f ("ACPI/IORT: Check ATS capability in root complex nodes") Signed-off-by: Lorenzo Pieralisi <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-05-23arm64/kernel: kaslr: reduce module randomization range to 2 GBArd Biesheuvel2-4/+4
The following commit 7290d5809571 ("module: use relative references for __ksymtab entries") updated the ksymtab handling of some KASLR capable architectures so that ksymtab entries are emitted as pairs of 32-bit relative references. This reduces the size of the entries, but more importantly, it gets rid of statically assigned absolute addresses, which require fixing up at boot time if the kernel is self relocating (which takes a 24 byte RELA entry for each member of the ksymtab struct). Since ksymtab entries are always part of the same module as the symbol they export, it was assumed at the time that a 32-bit relative reference is always sufficient to capture the offset between a ksymtab entry and its target symbol. Unfortunately, this is not always true: in the case of per-CPU variables, a per-CPU variable's base address (which usually differs from the actual address of any of its per-CPU copies) is allocated in the vicinity of the ..data.percpu section in the core kernel (i.e., in the per-CPU reserved region which follows the section containing the core kernel's statically allocated per-CPU variables). Since we randomize the module space over a 4 GB window covering the core kernel (based on the -/+ 4 GB range of an ADRP/ADD pair), we may end up putting the core kernel out of the -/+ 2 GB range of 32-bit relative references of module ksymtab entries that refer to per-CPU variables. So reduce the module randomization range a bit further. We lose 1 bit of randomization this way, but this is something we can tolerate. Cc: <[email protected]> # v4.19+ Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-05-23arm64: errata: Add workaround for Cortex-A76 erratum #1463225Will Deacon6-1/+109
Revisions of the Cortex-A76 CPU prior to r4p0 are affected by an erratum that can prevent interrupts from being taken when single-stepping. This patch implements a software workaround to prevent userspace from effectively being able to disable interrupts. Cc: <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Catalin Marinas <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-05-23arm64: Remove useless message during oopsWill Deacon1-4/+0
During an oops, we print the name of the current task and its pid twice. We also helpfully advertise its stack limit as "0x(____ptrval____)". Drop these useless messages. Signed-off-by: Will Deacon <[email protected]>
2019-05-23ALSA: hda/realtek - Set default power save node to 0Kailang Yang1-1/+1
I measured power consumption between power_save_node=1 and power_save_node=0. It's almost the same. Codec will enter to runtime suspend and suspend. That pin also will enter to D3. Don't need to enter to D3 by single pin. So, Disable power_save_node as default. It will avoid more issues. Windows Driver also has not this option at runtime PM. Signed-off-by: Kailang Yang <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2019-05-22ipv4/igmp: fix build error if !CONFIG_IP_MULTICASTEric Dumazet1-11/+11
ip_sf_list_clear_all() needs to be defined even if !CONFIG_IP_MULTICAST Fixes: 3580d04aa674 ("ipv4/igmp: fix another memory leak in igmpv3_del_delrec()") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: kbuild test robot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-23powerpc/kexec: Fix loading of kernel + initramfs with kexec_file_load()Thiago Jung Bauermann1-1/+5
Commit b6664ba42f14 ("s390, kexec_file: drop arch_kexec_mem_walk()") changed kexec_add_buffer() to skip searching for a memory location if kexec_buf.mem is already set, and use the address that is there. In powerpc code we reuse a kexec_buf variable for loading both the kernel and the initramfs by resetting some of the fields between those uses, but not mem. This causes kexec_add_buffer() to try to load the kernel at the same address where initramfs will be loaded, which is naturally rejected: # kexec -s -l --initrd initramfs vmlinuz kexec_file_load failed: Invalid argument Setting the mem field before every call to kexec_add_buffer() fixes this regression. Fixes: b6664ba42f14 ("s390, kexec_file: drop arch_kexec_mem_walk()") Cc: [email protected] # v5.0+ Signed-off-by: Thiago Jung Bauermann <[email protected]> Reviewed-by: Dave Young <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2019-05-23Merge branch 'drm-fixes-5.2' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie9-19/+70
into drm-fixes Fixes for 5.2: - Fix for DMCU firmware issues for stable - Add missing polaris10 pci id to kfd - Screen corruption fix on picasso - Fix for driver reload on vega10 - SR-IOV fixes - Locking fix in new SMU code - Compute profile switching fix for KFD Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.