aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-10-09Merge branch 's390-qeth-fixes'Jakub Kicinski1-8/+15
Julian Wiedmann says: ==================== s390/qeth: fixes 2019-10-08 Alexandra fixes two issues in the initialization code for vnicc cmds. One is an uninitialized variable when a cmd fails, the other that we wouldn't recover correctly if the device's supported features changed. ==================== Signed-off-by: Jakub Kicinski <[email protected]>
2019-10-09s390/qeth: Fix initialization of vnicc cmd masks during set onlineAlexandra Winter1-4/+8
Without this patch, a command bit in the supported commands mask is only ever set to unsupported during set online. If a command is ever marked as unsupported (e.g. because of error during qeth_l2_vnicc_query_cmds), subsequent successful initialization (offline/online) would not bring it back. Fixes: caa1f0b10d18 ("s390/qeth: add VNICC enable/disable support") Signed-off-by: Alexandra Winter <[email protected]> Signed-off-by: Julian Wiedmann <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2019-10-09s390/qeth: Fix error handling during VNICC initializationAlexandra Winter1-4/+7
Smatch discovered the use of uninitialized variable sup_cmds in error paths. Fixes: caa1f0b10d18 ("s390/qeth: add VNICC enable/disable support") Signed-off-by: Alexandra Winter <[email protected]> Signed-off-by: Julian Wiedmann <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2019-10-09phylink: fix kernel-doc warningsRandy Dunlap1-1/+1
Fix kernel-doc warnings in phylink.c: ../drivers/net/phy/phylink.c:595: warning: Function parameter or member 'config' not described in 'phylink_create' ../drivers/net/phy/phylink.c:595: warning: Excess function parameter 'ndev' description in 'phylink_create' Fixes: 8796c8923d9c ("phylink: add documentation for kernel APIs") Signed-off-by: Randy Dunlap <[email protected]> Cc: Russell King <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2019-10-09RISC-V: entry: Remove unneeded need_resched() loopValentin Schneider1-2/+1
Since the enabling and disabling of IRQs within preempt_schedule_irq() is contained in a need_resched() loop, we don't need the outer arch code loop. Reviewed-by: Palmer Dabbelt <[email protected]> Signed-off-by: Valentin Schneider <[email protected]> Cc: Albert Ou <[email protected]> Cc: [email protected] Signed-off-by: Paul Walmsley <[email protected]>
2019-10-09sctp: add chunks to sk_backlog when the newsk sk_socket is not setXin Long2-3/+14
This patch is to fix a NULL-ptr deref in selinux_socket_connect_helper: [...] kasan: GPF could be caused by NULL-ptr deref or user memory access [...] RIP: 0010:selinux_socket_connect_helper+0x94/0x460 [...] Call Trace: [...] selinux_sctp_bind_connect+0x16a/0x1d0 [...] security_sctp_bind_connect+0x58/0x90 [...] sctp_process_asconf+0xa52/0xfd0 [sctp] [...] sctp_sf_do_asconf+0x785/0x980 [sctp] [...] sctp_do_sm+0x175/0x5a0 [sctp] [...] sctp_assoc_bh_rcv+0x285/0x5b0 [sctp] [...] sctp_backlog_rcv+0x482/0x910 [sctp] [...] __release_sock+0x11e/0x310 [...] release_sock+0x4f/0x180 [...] sctp_accept+0x3f9/0x5a0 [sctp] [...] inet_accept+0xe7/0x720 It was caused by that the 'newsk' sk_socket was not set before going to security sctp hook when processing asconf chunk with SCTP_PARAM_ADD_IP or SCTP_PARAM_SET_PRIMARY: inet_accept()-> sctp_accept(): lock_sock(): lock listening 'sk' do_softirq(): sctp_rcv(): <-- [1] asconf chunk arrives and enqueued in 'sk' backlog sctp_sock_migrate(): set asoc's sk to 'newsk' release_sock(): sctp_backlog_rcv(): lock 'newsk' sctp_process_asconf() <-- [2] unlock 'newsk' sock_graft(): set sk_socket <-- [3] As it shows, at [1] the asconf chunk would be put into the listening 'sk' backlog, as accept() was holding its sock lock. Then at [2] asconf would get processed with 'newsk' as asoc's sk had been set to 'newsk'. However, 'newsk' sk_socket is not set until [3], while selinux_sctp_bind_connect() would deref it, then kernel crashed. Here to fix it by adding the chunk to sk_backlog until newsk sk_socket is set when .accept() is done. Note that sk->sk_socket can be NULL when the sock is closed, so SOCK_DEAD flag is also needed to check in sctp_newsk_ready(). Thanks to Ondrej for reviewing the code. Fixes: d452930fd3b9 ("selinux: Add SCTP support") Reported-by: Ying Xu <[email protected]> Suggested-by: Marcelo Ricardo Leitner <[email protected]> Signed-off-by: Xin Long <[email protected]> Acked-by: Marcelo Ricardo Leitner <[email protected]> Acked-by: Neil Horman <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2019-10-09bonding: fix potential NULL deref in bond_update_slave_arrEric Dumazet1-1/+1
syzbot got a NULL dereference in bond_update_slave_arr() [1], happening after a failure to allocate bond->slave_arr A workqueue (bond_slave_arr_handler) is supposed to retry the allocation later, but if the slave is removed before the workqueue had a chance to complete, bond->slave_arr can still be NULL. [1] Failed to build slave-array. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN PTI Modules linked in: Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:bond_update_slave_arr.cold+0xc6/0x198 drivers/net/bonding/bond_main.c:4039 RSP: 0018:ffff88018fe33678 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc9000290b000 RDX: 0000000000000000 RSI: ffffffff82b63037 RDI: ffff88019745ea20 RBP: ffff88018fe33760 R08: ffff880170754280 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88019745ea00 R14: 0000000000000000 R15: ffff88018fe338b0 FS: 00007febd837d700(0000) GS:ffff8801dad00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004540a0 CR3: 00000001c242e005 CR4: 00000000001626f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: [<ffffffff82b5b45e>] __bond_release_one+0x43e/0x500 drivers/net/bonding/bond_main.c:1923 [<ffffffff82b5b966>] bond_release drivers/net/bonding/bond_main.c:2039 [inline] [<ffffffff82b5b966>] bond_do_ioctl+0x416/0x870 drivers/net/bonding/bond_main.c:3562 [<ffffffff83ae25f4>] dev_ifsioc+0x6f4/0x940 net/core/dev_ioctl.c:328 [<ffffffff83ae2e58>] dev_ioctl+0x1b8/0xc70 net/core/dev_ioctl.c:495 [<ffffffff83995ffd>] sock_do_ioctl+0x1bd/0x300 net/socket.c:1088 [<ffffffff83996a80>] sock_ioctl+0x300/0x5d0 net/socket.c:1196 [<ffffffff81b124db>] vfs_ioctl fs/ioctl.c:47 [inline] [<ffffffff81b124db>] file_ioctl fs/ioctl.c:501 [inline] [<ffffffff81b124db>] do_vfs_ioctl+0xacb/0x1300 fs/ioctl.c:688 [<ffffffff81b12dc6>] SYSC_ioctl fs/ioctl.c:705 [inline] [<ffffffff81b12dc6>] SyS_ioctl+0xb6/0xe0 fs/ioctl.c:696 [<ffffffff8101ccc8>] do_syscall_64+0x528/0x770 arch/x86/entry/common.c:305 [<ffffffff84400091>] entry_SYSCALL_64_after_hwframe+0x42/0xb7 Fixes: ee6377147409 ("bonding: Simplify the xmit function for modes that use xmit_hash") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Cc: Mahesh Bandewar <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2019-10-09net: stmmac: fix disabling flexible PPS outputAntonio Borneo1-0/+1
Accordingly to Synopsys documentation [1] and [2], when bit PPSEN0 in register MAC_PPS_CONTROL is set it selects the functionality command in the same register, otherwise selects the functionality control. Command functionality is required to either enable (command 0x2) and disable (command 0x5) the flexible PPS output, but the bit PPSEN0 is currently set only for enabling. Set the bit PPSEN0 to properly disable flexible PPS output. Tested on STM32MP15x, based on dwmac 4.10a. [1] DWC Ethernet QoS Databook 4.10a October 2014 [2] DWC Ethernet QoS Databook 5.00a September 2017 Signed-off-by: Antonio Borneo <[email protected]> Fixes: 9a8a02c9d46d ("net: stmmac: Add Flexible PPS support") Signed-off-by: Jakub Kicinski <[email protected]>
2019-10-09net: stmmac: fix length of PTP clock's name stringAntonio Borneo1-1/+1
The field "name" in struct ptp_clock_info has a fixed size of 16 chars and is used as zero terminated string by clock_name_show() in drivers/ptp/ptp_sysfs.c The current initialization value requires 17 chars to fit also the null termination, and this causes overflow to the next bytes in the struct when the string is read as null terminated: hexdump -C /sys/class/ptp/ptp0/clock_name 00000000 73 74 6d 6d 61 63 5f 70 74 70 5f 63 6c 6f 63 6b |stmmac_ptp_clock| 00000010 a0 ac b9 03 0a |.....| where the extra 4 bytes (excluding the newline) after the string represent the integer 0x03b9aca0 = 62500000 assigned to the field "max_adj" that follows "name" in the same struct. There is no strict requirement for the "name" content and in the comment in ptp_clock_kernel.h it's reported it should just be 'A short "friendly name" to identify the clock'. Replace it with "stmmac ptp". Signed-off-by: Antonio Borneo <[email protected]> Fixes: 92ba6888510c ("stmmac: add the support for PTP hw clock driver") Signed-off-by: Jakub Kicinski <[email protected]>
2019-10-09drm/i915/gt: execlists->active is serialised by the taskletChris Wilson3-9/+27
The active/pending execlists is no longer protected by the engine->active.lock, but is serialised by the tasklet instead. Update the locking around the debug and stats to follow suit. v2: local_bh_disable() to prevent recursing into the tasklet in case we trigger a softirq (Tvrtko) Fixes: df403069029d ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit c36eebd9ba5d70b84e1e7408ccc7632566f285c4) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-10-09drm/i915/execlists: Protect peeking at execlists->activeChris Wilson1-2/+5
Now that we dropped the engine->active.lock serialisation from around process_csb(), direct submission can run concurrently to the interrupt handler. As such execlists->active may be advanced as we dequeue, dropping the reference to the request. We need to employ our RCU request protection to ensure that the request is not freed too early. Fixes: df403069029d ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit c949ae431467764277cdd88d7c26ff963a9db40a) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-10-09drm/i915: Fixup preempt-to-busy vs reset of a virtual requestChris Wilson2-4/+6
Due to the nature of preempt-to-busy the execlists active tracking and the schedule queue may become temporarily desync'ed (between resubmission to HW and its ack from HW). This means that we may have unwound a request and passed it back to the virtual engine, but it is still inflight on the HW and may even result in a GPU hang. If we detect that GPU hang and try to reset, the hanging request->engine will no longer match the current engine, which means that the request is not on the execlists active list and we should not try to find an older incomplete request. Given that we have deduced this must be a request on a virtual engine, it is the single active request in the context and so must be guilty (as the context is still inflight, it is prevented from being executed on another engine as we process the reset). Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit cb2377a919bbe8107af269c5a31a8d5cfb27d867) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-10-09io_uring: only flush workqueues on fileset removalJens Axboe1-1/+5
We should not remove the workqueue, we just need to ensure that the workqueues are synced. The workqueues are torn down on ctx removal. Cc: [email protected] Fixes: 6b06314c47e1 ("io_uring: add file set registration") Reported-by: Stefan Hajnoczi <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-10-09drm/i915: Only enqueue already completed requestsChris Wilson3-38/+74
If we are asked to submit a completed request, just move it onto the active-list without modifying it's payload. If we try to emit the modified payload of a completed request, we risk racing with the ring->head update during retirement which may advance the head past our breadcrumb and so we generate a warning for the emission being behind the RING_HEAD. v2: Commentary for the sneaky, shared responsibility between functions. v3: Spelling mistakes and bonus assertion Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit c0bb487dc19fc45dbeede7dcf8f513df51a3cd33) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-10-09drm/i915/execlists: Drop redundant list_del_init(&rq->sched.link)Chris Wilson1-1/+0
Since amalgamating the queued and active lists in commit 422d7df4f090 ("drm/i915: Replace engine->timeline with a plain list"), performing a i915_request_submit() will remove the request from the execlists priority queue. References: 422d7df4f090 ("drm/i915: Replace engine->timeline with a plain list") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 3231f8c01121ee1febfd82398ee22f7ff9dc5d76) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-10-09drm/i915/cml: Add second PCH ID for CMPMatt Roper2-0/+2
The CMP PCH ID we have in the driver is correct for the CML-U machines we have in our CI system, but the CML-S and CML-H CI machines appear to use a different PCH ID, leading our driver to detect no PCH for them. Cc: Rodrigo Vivi <[email protected]> Cc: Anusha Srivatsa <[email protected]> References: 729ae330a0f2e2 ("drm/i915/cml: Introduce Comet Lake PCH") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111461 Signed-off-by: Matt Roper <[email protected]> Acked-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Fixes: 729ae330a0f2e2 ("drm/i915/cml: Introduce Comet Lake PCH") (cherry picked from commit 8698ba53cd7173c32320ebbef4d389d41ebb5780) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-10-09MIPS: fw: sni: Fix out of bounds init of o32 stackThomas Bogendoerfer1-1/+1
Use ARRAY_SIZE to caluculate the top of the o32 stack. 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]
2019-10-09MIPS: include: Mark __xchg as __always_inlineThomas Bogendoerfer1-2/+2
Commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING forcibly") allows compiler to uninline functions marked as 'inline'. In cace of __xchg this would cause to reference function __xchg_called_with_bad_pointer, which is an error case for catching bugs and will not happen for correct code, if __xchg is inlined. Signed-off-by: Thomas Bogendoerfer <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[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]
2019-10-09iio: Fix an undefied reference error in noa1305_probezhong jiang1-0/+1
I hit the following error when compile the kernel. drivers/iio/light/noa1305.o: In function `noa1305_probe': noa1305.c:(.text+0x65): undefined reference to `__devm_regmap_init_i2c' make: *** [vmlinux] Error 1 Signed-off-by: zhong jiang <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2019-10-09iio: light: opt3001: fix mutex unlock raceDavid Frey1-1/+5
When an end-of-conversion interrupt is received after performing a single-shot reading of the light sensor, the driver was waking up the result ready queue before checking opt->ok_to_ignore_lock to determine if it should unlock the mutex. The problem occurred in the case where the other thread woke up and changed the value of opt->ok_to_ignore_lock to false prior to the interrupt thread performing its read of the variable. In this case, the mutex would be unlocked twice. Signed-off-by: David Frey <[email protected]> Reviewed-by: Andreas Dannenberg <[email protected]> Fixes: 94a9b7b1809f ("iio: light: add support for TI's opt3001 light sensor") Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2019-10-09iio: adc: ad799x: fix probe error handlingMarco Felsch1-2/+2
Since commit 0f7ddcc1bff1 ("iio:adc:ad799x: Write default config on probe and reset alert status on probe") the error path is wrong since it leaves the vref regulator on. Fix this by disabling both regulators. Fixes: 0f7ddcc1bff1 ("iio:adc:ad799x: Write default config on probe and reset alert status on probe") Signed-off-by: Marco Felsch <[email protected]> Reviewed-by: Alexandru Ardelean <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2019-10-09iio: light: add missing vcnl4040 of_compatibleMarco Felsch1-0/+4
Commit 5a441aade5b3 ("iio: light: vcnl4000 add support for the VCNL4040 proximity and light sensor") added the support for the vcnl4040 but forgot to add the of_compatible. Fix this by adding it now. Signed-off-by: Marco Felsch <[email protected]> Fixes: 5a441aade5b3 ("iio: light: vcnl4000 add support for the VCNL4040 proximity and light sensor") Reviewed-by: Angus Ainslie (Purism) [email protected] Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2019-10-09iio: light: fix vcnl4000 devicetree hooksMarco Felsch1-5/+5
Since commit ebd457d55911 ("iio: light: vcnl4000 add devicetree hooks") the of_match_table is supported but the data shouldn't be a string. Instead it shall be one of 'enum vcnl4000_device_ids'. Also the matching logic for the vcnl4020 was wrong. Since the data retrieve mechanism is still based on the i2c_device_id no failures did appeared till now. Fixes: ebd457d55911 ("iio: light: vcnl4000 add devicetree hooks") Signed-off-by: Marco Felsch <[email protected]> Reviewed-by: Angus Ainslie (Purism) [email protected] Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2019-10-09iio: imu: st_lsm6dsx: fix waitime for st_lsm6dsx i2c controllerLorenzo Bianconi1-1/+3
i2c controller available in st_lsm6dsx series performs i2c slave configuration using accel clock as trigger. st_lsm6dsx_shub_wait_complete routine is used to wait the controller has carried out the requested configuration. However if the accel sensor is not enabled we should not use its configured odr to estimate a proper timeout Fixes: c91c1c844ebd ("iio: imu: st_lsm6dsx: add i2c embedded controller support") Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2019-10-09iio: adc: axp288: Override TS pin bias current for some modelsHans de Goede1-0/+32
Since commit 9bcf15f75cac ("iio: adc: axp288: Fix TS-pin handling") we preserve the bias current set by the firmware at boot. This fixes issues we were seeing on various models, but it seems our old hardcoded 80ųA bias current was working around a firmware bug on at least one model laptop. In order to both have our cake and eat it, this commit adds a dmi based list of models where we need to override the firmware set bias current and adds the one model we now know needs this to it: The Lenovo Ideapad 100S (11 inch version). Fixes: 9bcf15f75cac ("iio: adc: axp288: Fix TS-pin handling") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=203829 Signed-off-by: Hans de Goede <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2019-10-09iio: imu: adis16400: fix memory leakNavid Emamdoost1-1/+4
In adis_update_scan_mode_burst, if adis->buffer allocation fails release the adis->xfer. Signed-off-by: Navid Emamdoost <[email protected]> Reviewed-by: Alexandru Ardelean <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2019-10-09iio: imu: adis16400: release allocated memory on failureNavid Emamdoost1-1/+4
In adis_update_scan_mode, if allocation for adis->buffer fails, previously allocated adis->xfer needs to be released. Signed-off-by: Navid Emamdoost <[email protected]> Reviewed-by: Alexandru Ardelean <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2019-10-09iio: adc: stm32-adc: fix a race when using several adcs with dma and irqFabrice Gasnier2-3/+41
End of conversion may be handled by using IRQ or DMA. There may be a race when two conversions complete at the same time on several ADCs. EOC can be read as 'set' for several ADCs, with: - an ADC configured to use IRQs. EOCIE bit is set. The handler is normally called in this case. - an ADC configured to use DMA. EOCIE bit isn't set. EOC triggers the DMA request instead. It's then automatically cleared by DMA read. But the handler gets called due to status bit is temporarily set (IRQ triggered by the other ADC). So both EOC status bit in CSR and EOCIE control bit must be checked before invoking the interrupt handler (e.g. call ISR only for IRQ-enabled ADCs). Fixes: 2763ea0585c9 ("iio: adc: stm32: add optional dma support") Signed-off-by: Fabrice Gasnier <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2019-10-09iio: adc: stm32-adc: move registers definitionsFabrice Gasnier3-136/+136
Move STM32 ADC registers definitions to common header. This is precursor patch to: - iio: adc: stm32-adc: fix a race when using several adcs with dma and irq It keeps registers definitions as a whole block, to ease readability and allow simple access path to EOC bits (readl) in stm32-adc-core driver. Fixes: 2763ea0585c9 ("iio: adc: stm32: add optional dma support") Signed-off-by: Fabrice Gasnier <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2019-10-09iio: accel: adxl372: Perform a reset at start upStefan Popa1-0/+8
We need to perform a reset a start up to make sure that the chip is in a consistent state. This reset also disables all the interrupts which should only be enabled together with the iio buffer. Not doing this, was sometimes causing unwanted interrupts to trigger. Signed-off-by: Stefan Popa <[email protected]> Fixes: f4f55ce38e5f ("iio:adxl372: Add FIFO and interrupts support") Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2019-10-09iio: accel: adxl372: Fix push to buffers lost samplesStefan Popa1-2/+1
One in two sample sets was lost by multiplying fifo_set_size with sizeof(u16). Also, the double number of available samples were pushed to the iio buffers. Signed-off-by: Stefan Popa <[email protected]> Fixes: f4f55ce38e5f ("iio:adxl372: Add FIFO and interrupts support") Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2019-10-09iio: accel: adxl372: Fix/remove limitation for FIFO samplesStefan Popa1-3/+8
Currently, the driver sets the FIFO_SAMPLES register with the number of sample sets (maximum of 170 for 3 axis data, 256 for 2-axis and 512 for single axis). However, the FIFO_SAMPLES register should store the number of samples, regardless of how the FIFO format is configured. Signed-off-by: Stefan Popa <[email protected]> Fixes: f4f55ce38e5f ("iio:adxl372: Add FIFO and interrupts support") Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2019-10-09iio: adc: hx711: fix bug in sampling of dataAndreas Klinger1-5/+5
Fix bug in sampling function hx711_cycle() when interrupt occures while PD_SCK is high. If PD_SCK is high for at least 60 us power down mode of the sensor is entered which in turn leads to a wrong measurement. Switch off interrupts during a PD_SCK high period and move query of DOUT to the latest point of time which is at the end of PD_SCK low period. This bug exists in the driver since it's initial addition. The more interrupts on the system the higher is the probability that it happens. Fixes: c3b2fdd0ea7e ("iio: adc: hx711: Add IIO driver for AVIA HX711") Signed-off-by: Andreas Klinger <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2019-10-09Merge tag 'iwlwifi-for-kalle-2019-10-09' of ↵Kalle Valo8-181/+229
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes First batch of fixes intended for v5.4 * fix for an ACPI table parsing bug; * a fix for a NULL pointer dereference in the cfg with specific devices; * fix the rb_allocator; * prevent multiple phy configuration with new devices; * fix a race-condition in the rx queue; * prevent a couple of memory leaks; * fix initialization of 3168 devices (the infamous BAD_COMMAND bug); * fix recognition of some newer systems with integrated MAC;
2019-10-09Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdmaLinus Torvalds18-147/+154
Pull rdma fixes from Jason Gunthorpe: "The usual collection of driver bug fixes, and a few regressions from the merge window. Nothing particularly worrisome. - Various missed memory frees and error unwind bugs - Fix regressions in a few iwarp drivers from 5.4 patches - A few regressions added in past kernels - Squash a number of races in mlx5 ODP code" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: RDMA/mlx5: Add missing synchronize_srcu() for MW cases RDMA/mlx5: Put live in the correct place for ODP MRs RDMA/mlx5: Order num_pending_prefetch properly with synchronize_srcu RDMA/odp: Lift umem_mutex out of ib_umem_odp_unmap_dma_pages() RDMA/mlx5: Fix a race with mlx5_ib_update_xlt on an implicit MR RDMA/mlx5: Do not allow rereg of a ODP MR IB/core: Fix wrong iterating on ports RDMA/nldev: Reshuffle the code to avoid need to rebind QP in error path RDMA/cxgb4: Do not dma memory off of the stack RDMA/cm: Fix memory leak in cm_add/remove_one RDMA/core: Fix an error handling path in 'res_get_common_doit()' RDMA/i40iw: Associate ibdev to netdev before IB device registration RDMA/iwcm: Fix a lock inversion issue RDMA/iw_cxgb4: fix SRQ access from dump_qp() RDMA/hfi1: Prevent memory leak in sdma_init RDMA/core: Fix use after free and refcnt leak on ndev in_device in iwarp_query_port RDMA/siw: Fix serialization issue in write_space() RDMA/vmw_pvrdma: Free SRQ only once
2019-10-09drm/amdgpu/powerplay: fix typo in mvdd table setupAlex Deucher2-2/+2
Polaris and vegam use count for the value rather than level. This looks like a copy paste typo from when the code was adapted from previous asics. I'm not sure that the SMU actually uses this value, so I don't know that it actually is a bug per se. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=108609 Reported-by: Robert Strube <[email protected]> Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-09drm/amdgpu: fix memory leakNirmoy Das1-7/+7
cleanup error handling code and make sure temporary info array with the handles are freed by amdgpu_bo_list_put() on idr_replace()'s failure. Signed-off-by: Nirmoy Das <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-09Merge tag 'arm64-fixes' of ↵Linus Torvalds16-104/+98
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "A larger-than-usual batch of arm64 fixes for -rc3. The bulk of the fixes are dealing with a bunch of issues with the build system from the compat vDSO, which unfortunately led to some significant Makefile rework to manage the horrible combinations of toolchains that we can end up needing to drive simultaneously. We came close to disabling the thing entirely, but Vincenzo was quick to spin up some patches and I ended up picking up most of the bits that were left [*]. Future work will look at disentangling the header files properly. Other than that, we have some important fixes all over, including one papering over the miscompilation fallout from forcing CONFIG_OPTIMIZE_INLINING=y, which I'm still unhappy about. Harumph. We've still got a couple of open issues, so I'm expecting to have some more fixes later this cycle. Summary: - Numerous fixes to the compat vDSO build system, especially when combining gcc and clang - Fix parsing of PAR_EL1 in spurious kernel fault detection - Partial workaround for Neoverse-N1 erratum #1542419 - Fix IRQ priority masking on entry from compat syscalls - Fix advertisment of FRINT HWCAP to userspace - Attempt to workaround inlining breakage with '__always_inline' - Fix accidental freeing of parent SVE state on fork() error path - Add some missing NULL pointer checks in instruction emulation init - Some formatting and comment fixes" [*] Will's final fixes were Reviewed-by: Vincenzo Frascino <[email protected]> Tested-by: Vincenzo Frascino <[email protected]> but they were already in linux-next by then and he didn't rebase just to add those. * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (21 commits) arm64: armv8_deprecated: Checking return value for memory allocation arm64: Kconfig: Make CONFIG_COMPAT_VDSO a proper Kconfig option arm64: vdso32: Rename COMPATCC to CC_COMPAT arm64: vdso32: Pass '--target' option to clang via VDSO_CAFLAGS arm64: vdso32: Don't use KBUILD_CPPFLAGS unconditionally arm64: vdso32: Move definition of COMPATCC into vdso32/Makefile arm64: Default to building compat vDSO with clang when CONFIG_CC_IS_CLANG lib: vdso: Remove CROSS_COMPILE_COMPAT_VDSO arm64: vdso32: Remove jump label config option in Makefile arm64: vdso32: Detect binutils support for dmb ishld arm64: vdso: Remove stale files from old assembly implementation arm64: vdso32: Fix broken compat vDSO build warnings arm64: mm: fix spurious fault detection arm64: ftrace: Ensure synchronisation in PLT setup for Neoverse-N1 #1542419 arm64: Fix incorrect irqflag restore for priority masking for compat arm64: mm: avoid virt_to_phys(init_mm.pgd) arm64: cpufeature: Effectively expose FRINT capability to userspace arm64: Mark functions using explicit register variables as '__always_inline' docs: arm64: Fix indentation and doc formatting arm64/sve: Fix wrong free for task->thread.sve_state ...
2019-10-09xfs: move local to extent inode logging into bmap helperBrian Foster4-7/+8
The callers of xfs_bmap_local_to_extents_empty() log the inode external to the function, yet this function is where the on-disk format value is updated. Push the inode logging down into the function itself to help prevent future mistakes. Note that internal bmap callers track the inode logging flags independently and thus may log the inode core twice due to this change. This is harmless, so leave this code around for consistency with the other attr fork conversion functions. Signed-off-by: Brian Foster <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2019-10-09xfs: remove broken error handling on failed attr sf to leaf changeBrian Foster1-17/+2
xfs_attr_shortform_to_leaf() attempts to put the shortform fork back together after a failed attempt to convert from shortform to leaf format. While this code reallocates and copies back the shortform attr fork data, it never resets the inode format field back to local format. Further, now that the inode is properly logged after the initial switch from local format, any error that triggers the recovery code will eventually abort the transaction and shutdown the fs. Therefore, remove the broken and unnecessary error handling code. Signed-off-by: Brian Foster <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2019-10-09xfs: log the inode on directory sf to block format changeBrian Foster2-0/+2
When a directory changes from shortform (sf) to block format, the sf format is copied to a temporary buffer, the inode format is modified and the updated format filled with the dentries from the temporary buffer. If the inode format is modified and attempt to grow the inode fails (due to I/O error, for example), it is possible to return an error while leaving the directory in an inconsistent state and with an otherwise clean transaction. This results in corruption of the associated directory and leads to xfs_dabuf_map() errors as subsequent lookups cannot accurately determine the format of the directory. This problem is reproduced occasionally by generic/475. The fundamental problem is that xfs_dir2_sf_to_block() changes the on-disk inode format without logging the inode. The inode is eventually logged by the bmapi layer in the common case, but error checking introduces the possibility of failing the high level request before this happens. Update both of the dir2 and attr callers of xfs_bmap_local_to_extents_empty() to log the inode core as consistent with the bmap local to extent format change codepath. This ensures that any subsequent errors after the format has changed cause the transaction to abort. Signed-off-by: Brian Foster <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2019-10-09NFS: Remove redundant mirror tracking in O_DIRECTTrond Myklebust1-42/+0
We no longer need the extra mirror length tracking in the O_DIRECT code, as we are able to track the maximum contiguous length in dreq->max_count. Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]>
2019-10-09NFS: Fix O_DIRECT accounting of number of bytes read/writtenTrond Myklebust1-35/+43
When a series of O_DIRECT reads or writes are truncated, either due to eof or due to an error, then we should return the number of contiguous bytes that were received/sent starting at the offset specified by the application. Currently, we are failing to correctly check contiguity, and so we're failing the generic/465 in xfstests when the race between the read and write RPCs causes the file to get extended while the 2 reads are outstanding. If the first read RPC call wins the race and returns with eof set, we should treat the second read RPC as being truncated. Reported-by: Su Yanjun <[email protected]> Fixes: 1ccbad9f9f9bd ("nfs: fix DIO good bytes calculation") Cc: [email protected] # 4.1+ Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]>
2019-10-09perf/x86/amd: Change/fix NMI latency mitigation to use a timestampTom Lendacky1-13/+17
It turns out that the NMI latency workaround from commit: 6d3edaae16c6 ("x86/perf/amd: Resolve NMI latency issues for active PMCs") ends up being too conservative and results in the perf NMI handler claiming NMIs too easily on AMD hardware when the NMI watchdog is active. This has an impact, for example, on the hpwdt (HPE watchdog timer) module. This module can produce an NMI that is used to reset the system. It registers an NMI handler for the NMI_UNKNOWN type and relies on the fact that nothing has claimed an NMI so that its handler will be invoked when the watchdog device produces an NMI. After the referenced commit, the hpwdt module is unable to process its generated NMI if the NMI watchdog is active, because the current NMI latency mitigation results in the NMI being claimed by the perf NMI handler. Update the AMD perf NMI latency mitigation workaround to, instead, use a window of time. Whenever a PMC is handled in the perf NMI handler, set a timestamp which will act as a perf NMI window. Any NMIs arriving within that window will be claimed by perf. Anything outside that window will not be claimed by perf. The value for the NMI window is set to 100 msecs. This is a conservative value that easily covers any NMI latency in the hardware. While this still results in a window in which the hpwdt module will not receive its NMI, the window is now much, much smaller. Signed-off-by: Tom Lendacky <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Jerry Hoemann <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Fixes: 6d3edaae16c6 ("x86/perf/amd: Resolve NMI latency issues for active PMCs") Link: https://lkml.kernel.org/r/Message-ID: Signed-off-by: Ingo Molnar <[email protected]>
2019-10-09perf/core: Fix corner case in perf_rotate_context()Song Liu1-5/+17
In perf_rotate_context(), when the first cpu flexible event fail to schedule, cpu_rotate is 1, while cpu_event is NULL. Since cpu_event is NULL, perf_rotate_context will _NOT_ call cpu_ctx_sched_out(), thus cpuctx->ctx.is_active will have EVENT_FLEXIBLE set. Then, the next perf_event_sched_in() will skip all cpu flexible events because of the EVENT_FLEXIBLE bit. In the next call of perf_rotate_context(), cpu_rotate stays 1, and cpu_event stays NULL, so this process repeats. The end result is, flexible events on this cpu will not be scheduled (until another event being added to the cpuctx). Here is an easy repro of this issue. On Intel CPUs, where ref-cycles could only use one counter, run one pinned event for ref-cycles, one flexible event for ref-cycles, and one flexible event for cycles. The flexible ref-cycles is never scheduled, which is expected. However, because of this issue, the cycles event is never scheduled either. $ perf stat -e ref-cycles:D,ref-cycles,cycles -C 5 -I 1000 time counts unit events 1.000152973 15,412,480 ref-cycles:D 1.000152973 <not counted> ref-cycles (0.00%) 1.000152973 <not counted> cycles (0.00%) 2.000486957 18,263,120 ref-cycles:D 2.000486957 <not counted> ref-cycles (0.00%) 2.000486957 <not counted> cycles (0.00%) To fix this, when the flexible_active list is empty, try rotate the first event in the flexible_groups. Also, rename ctx_first_active() to ctx_event_to_rotate(), which is more accurate. Signed-off-by: Song Liu <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Sasha Levin <[email protected]> Cc: Thomas Gleixner <[email protected]> Fixes: 8d5bce0c37fa ("perf/core: Optimize perf_rotate_context() event scheduling") Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-10-09perf/core: Rework memory accounting in perf_mmap()Song Liu1-2/+15
perf_mmap() always increases user->locked_vm. As a result, "extra" could grow bigger than "user_extra", which doesn't make sense. Here is an example case: (Note: Assume "user_lock_limit" is very small.) | # of perf_mmap calls |vma->vm_mm->pinned_vm|user->locked_vm| | 0 | 0 | 0 | | 1 | user_extra | user_extra | | 2 | 3 * user_extra | 2 * user_extra| | 3 | 6 * user_extra | 3 * user_extra| | 4 | 10 * user_extra | 4 * user_extra| Fix this by maintaining proper user_extra and extra. Reviewed-By: Hechao Li <[email protected]> Reported-by: Hechao Li <[email protected]> Signed-off-by: Song Liu <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: <[email protected]> Cc: Jie Meng <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-10-09sched/vtime: Fix guest/system mis-accounting on task switchFrederic Weisbecker1-3/+3
vtime_account_system() assumes that the target task to account cputime to is always the current task. This is most often true indeed except on task switch where we call: vtime_common_task_switch(prev) vtime_account_system(prev) Here prev is the scheduling-out task where we account the cputime to. It doesn't match current that is already the scheduling-in task at this stage of the context switch. So we end up checking the wrong task flags to determine if we are accounting guest or system time to the previous task. As a result the wrong task is used to check if the target is running in guest mode. We may then spuriously account or leak either system or guest time on task switch. Fix this assumption and also turn vtime_guest_enter/exit() to use the task passed in parameter as well to avoid future similar issues. Signed-off-by: Frederic Weisbecker <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Wanpeng Li <[email protected]> Fixes: 2a42eb9594a1 ("sched/cputime: Accumulate vtime on top of nsec clocksource") Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-10-09sched/fair: Scale bandwidth quota and period without losing quota/period ↵Xuewei Zhang1-14/+22
ratio precision The quota/period ratio is used to ensure a child task group won't get more bandwidth than the parent task group, and is calculated as: normalized_cfs_quota() = [(quota_us << 20) / period_us] If the quota/period ratio was changed during this scaling due to precision loss, it will cause inconsistency between parent and child task groups. See below example: A userspace container manager (kubelet) does three operations: 1) Create a parent cgroup, set quota to 1,000us and period to 10,000us. 2) Create a few children cgroups. 3) Set quota to 1,000us and period to 10,000us on a child cgroup. These operations are expected to succeed. However, if the scaling of 147/128 happens before step 3, quota and period of the parent cgroup will be changed: new_quota: 1148437ns, 1148us new_period: 11484375ns, 11484us And when step 3 comes in, the ratio of the child cgroup will be 104857, which will be larger than the parent cgroup ratio (104821), and will fail. Scaling them by a factor of 2 will fix the problem. Tested-by: Phil Auld <[email protected]> Signed-off-by: Xuewei Zhang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Phil Auld <[email protected]> Cc: Anton Blanchard <[email protected]> Cc: Ben Segall <[email protected]> Cc: Dietmar Eggemann <[email protected]> Cc: Juri Lelli <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vincent Guittot <[email protected]> Fixes: 2e8e19226398 ("sched/fair: Limit sched_cfs_period_timer() loop to avoid hard lockup") Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-10-09iwlwifi: pcie: change qu with jf devices to use qu configurationLuca Coelho1-137/+137
There were a bunch of devices with qu and jf that were loading the configuration with pu and jf, which is wrong. Fix them all accordingly. Additionally, remove 0x1010 and 0x1210 subsytem IDs from the list, since they are obviously wrong, and 0x0044 and 0x0244, which were duplicate. Cc: [email protected] # 5.1+ Signed-off-by: Luca Coelho <[email protected]>
2019-10-09iwlwifi: exclude GEO SAR support for 3168Luca Coelho1-7/+9
We currently support two NICs in FW version 29, namely 7265D and 3168. Out of these, only 7265D supports GEO SAR, so adjust the function that checks for it accordingly. Signed-off-by: Luca Coelho <[email protected]> Fixes: f5a47fae6aa3 ("iwlwifi: mvm: fix version check for GEO_TX_POWER_LIMIT support") Signed-off-by: Luca Coelho <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.