summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-10-02block: pg: add header include guardMasahiro Yamada
Add a header include guard just in case. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-10-02net: stmmac: Avoid deadlock on suspend/resumeThierry Reding
The stmmac driver will try to acquire its private mutex during suspend via phylink_resolve() -> stmmac_mac_link_down() -> stmmac_eee_init(). However, the phylink configuration is updated with the private mutex held already, which causes a deadlock during suspend. Fix this by moving the phylink configuration updates out of the region of code protected by the private mutex. Fixes: 19e13cb27b99 ("net: stmmac: Hold rtnl lock in suspend/resume callbacks") Suggested-by: Bitan Biswas <bbiswas@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-02timer-of: don't use conditional expression with mixed 'void' typesLinus Torvalds
Randy Dunlap reports on the sparse list that sparse warns about this expression: of_irq->percpu ? free_percpu_irq(of_irq->irq, clkevt) : free_irq(of_irq->irq, clkevt); and honestly, sparse is correct to warn. The return type of free_percpu_irq() is 'void', while free_irq() returns a 'const void *' that is the devname argument passed in to the request_irq(). You can't mix a void type with a non-void types in a conditional expression according to the C standard. It so happens that gcc seems to accept it - and the resulting type of the expression is void - but there's really no reason for the kernel to have this kind of non-standard expression with no real upside. The natural way to write that expression is with an if-statement: if (of_irq->percpu) free_percpu_irq(of_irq->irq, clkevt); else free_irq(of_irq->irq, clkevt); which is more legible anyway. I'm not sure why that timer-of code seems to have this odd pattern. It does the same at allocation time, but at least there the types match, and it makes sense as an expression. Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-10-02Merge branch 'timers-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fix from Ingo Molnar: "Fix a broadcast-timer handling race that can result in spuriously and indefinitely delayed hrtimers and even RCU stalls if the system is otherwise quiet" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: tick: broadcast-hrtimer: Fix a race in bc_set_next
2019-10-02Merge branch 'sched-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull membarrier fix from Ingo Molnar: "Fix broken locking within membarrier_private_expedited()" * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: membarrier: Fix RCU locking bug caused by faulty merge
2019-10-02net: hisilicon: Fix usage of uninitialized variable in function ↵Yizhuo
mdio_sc_cfg_reg_write() In function mdio_sc_cfg_reg_write(), variable "reg_value" could be uninitialized if regmap_read() fails. However, "reg_value" is used to decide the control flow later in the if statement, which is potentially unsafe. Signed-off-by: Yizhuo <yzhai003@ucr.edu> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-02mips: Loongson: Fix the link time qualifier of 'serial_exit()'Christophe JAILLET
'exit' functions should be marked as __exit, not __init. Fixes: 85cc028817ef ("mips: make loongsoon serial driver explicitly modular") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: chenhc@lemote.com Cc: ralf@linux-mips.org Cc: jhogan@kernel.org Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: kernel-janitors@vger.kernel.org
2019-10-02MIPS: init: Prevent adding memory before PHYS_OFFSETThomas Bogendoerfer
On some SGI machines (IP28 and IP30) a small region of memory is mirrored to pyhsical address 0 for exception vectors while rest of the memory is reachable at a higher physical address. ARC PROM marks this region as reserved, but with commit a94e4f24ec83 ("MIPS: init: Drop boot_mem_map") this chunk is used, when searching for start of ram, which breaks at least IP28 and IP30 machines. To fix this add_region_memory() checks for start address < PHYS_OFFSET and ignores these chunks. Fixes: a94e4f24ec83 ("MIPS: init: Drop boot_mem_map") Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org
2019-10-02MIPS: init: Fix reservation of memory between PHYS_OFFSET and mem startThomas Bogendoerfer
Fix calculation of the size for reserving memory between PHYS_OFFSET and real memory start. Fixes: a94e4f24ec83 ("MIPS: init: Drop boot_mem_map") Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org
2019-10-02MIPS: VDSO: Fix build for binutils < 2.25Paul Burton
Versions of binutils prior to 2.25 are unable to link our VDSO due to an unsupported R_MIPS_PC32 relocation generated by the ".word _start - ." line of the inline asm in get_vdso_base(). As such, the intent is that when building with binutils older than 2.25 we don't build code for gettimeofday() & friends in the VDSO that rely upon get_vdso_base(). Commit 24640f233b46 ("mips: Add support for generic vDSO") converted us to using generic VDSO infrastructure, and as part of that the gettimeofday() functionality moved to a new vgettimeofday.c file. The check for binutils < 2.25 wasn't updated to handle this new filename, and so it continues trying to remove the old unused filename from the build. The end result is that we try to include the gettimeofday() code in builds that will fail to link. Fix this by updating the binutils < 2.25 case to remove vgettimeofday.c from obj-vdso-y, rather than gettimeofday.c. Signed-off-by: Paul Burton <paul.burton@mips.com> Fixes: 24640f233b46 ("mips: Add support for generic vDSO") Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: linux-mips@vger.kernel.org
2019-10-02MIPS: VDSO: Remove unused gettimeofday.cPaul Burton
arch/mips/vdso/gettimeofday.c has been unused since commit 24640f233b46 ("mips: Add support for generic vDSO"). Remove the dead code. Signed-off-by: Paul Burton <paul.burton@mips.com> Fixes: 24640f233b46 ("mips: Add support for generic vDSO") Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: linux-mips@vger.kernel.org
2019-10-02MIPS: Wire up clone3 syscallPaul Burton
Wire up the new clone3 syscall for MIPS, using save_static_function() to generate a wrapper that saves registers $s0-$s7 prior to invoking the generic sys_clone3 function just like we do for plain old clone. Tested atop 64r6el_defconfig using o32, n32 & n64 builds of the simple test program from: https://lore.kernel.org/lkml/20190716130631.tohj4ub54md25dys@brauner.io/ Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: Christian Brauner <christian@brauner.io> Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: linux-mips@vger.kernel.org
2019-10-02Merge tag 'erofs-for-5.4-rc2-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs Pull erofs fixes from Gao Xiang: "Three patches to address regressions due to recent cleanups, mainly found by stress test on latest mainline kernel (no more regression out compared with older kernels for more than a week) One additional patch updates sub-entries in MAINTAINERS. Summary: - Fix error handling in erofs_read_superblock - Fix locking in erofs_get_meta_page - Fix inplace behavior due to decompression frontend cleanup - Update sub-entries in MAINTAINERS in order to better blame" * tag 'erofs-for-5.4-rc2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs: erofs: fix mis-inplace determination related with noio chain erofs: fix erofs_get_meta_page locking due to a cleanup MAINTAINERS: erofs: complete sub-entries for erofs erofs: fix return value check in erofs_read_superblock()
2019-10-02char/random: Add a newline at the end of the fileBorislav Petkov
On Tue, Oct 01, 2019 at 10:14:40AM -0700, Linus Torvalds wrote: > The previous state of the file didn't have that 0xa at the end, so you get that > > > -EXPORT_SYMBOL_GPL(add_bootloader_randomness); > \ No newline at end of file > +EXPORT_SYMBOL_GPL(add_bootloader_randomness); > > which is "the '-' line doesn't have a newline, the '+' line does" marker. Aaha, that makes total sense, thanks for explaining. Oh well, let's fix it then so that people don't scratch heads like me. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-10-02xen/xenbus: fix self-deadlock after killing user processJuergen Gross
In case a user process using xenbus has open transactions and is killed e.g. via ctrl-C the following cleanup of the allocated resources might result in a deadlock due to trying to end a transaction in the xenbus worker thread: [ 2551.474706] INFO: task xenbus:37 blocked for more than 120 seconds. [ 2551.492215] Tainted: P OE 5.0.0-29-generic #5 [ 2551.510263] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 2551.528585] xenbus D 0 37 2 0x80000080 [ 2551.528590] Call Trace: [ 2551.528603] __schedule+0x2c0/0x870 [ 2551.528606] ? _cond_resched+0x19/0x40 [ 2551.528632] schedule+0x2c/0x70 [ 2551.528637] xs_talkv+0x1ec/0x2b0 [ 2551.528642] ? wait_woken+0x80/0x80 [ 2551.528645] xs_single+0x53/0x80 [ 2551.528648] xenbus_transaction_end+0x3b/0x70 [ 2551.528651] xenbus_file_free+0x5a/0x160 [ 2551.528654] xenbus_dev_queue_reply+0xc4/0x220 [ 2551.528657] xenbus_thread+0x7de/0x880 [ 2551.528660] ? wait_woken+0x80/0x80 [ 2551.528665] kthread+0x121/0x140 [ 2551.528667] ? xb_read+0x1d0/0x1d0 [ 2551.528670] ? kthread_park+0x90/0x90 [ 2551.528673] ret_from_fork+0x35/0x40 Fix this by doing the cleanup via a workqueue instead. Reported-by: James Dingwall <james@dingwall.me.uk> Fixes: fd8aa9095a95c ("xen: optimize xenbus driver for multiple concurrent xenstore accesses") Cc: <stable@vger.kernel.org> # 4.11 Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2019-10-02Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter fixes for net: 1) Remove the skb_ext_del from nf_reset, and renames it to a more fitting nf_reset_ct(). Patch from Florian Westphal. 2) Fix deadlock in nft_connlimit between packet path updates and the garbage collector. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-02dt-bindings: phy: lantiq: Fix Property NameMaxime Ripard
The binding has a typo where resets-names should read reset-names, which in turn leads to a warning when the example is validated, since reset-names is being used, and the binding prevent the usage of any property that isn't described. Fixes: 088e88be5a38 ("dt-bindings: phy: add binding for the Lantiq VRX200 and ARX300 PCIe PHYs") Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org>
2019-10-02dt-bindings: iio: ad7192: Fix DTC warning in the exampleMaxime Ripard
The example contains an SPI bus and device, but doesn't have the appropriate size and address cells size. This creates a DTC warning when the example is compiled since the default ones will not match what the device uses. Let's add them to remove that warning. Fixes: f7356e47032c ("dt-bindings: iio: adc: ad7192: Add binding documentation for AD7192") Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org>
2019-10-02dt-bindings: iio: ad7192: Fix Regulator PropertiesMaxime Ripard
The AD7192 binding describes two regulator properties, avdd-supply and dvdd-supply, but describes it as a constant string that must be avdd and dvdd. This is wrong since a *-supply property is actually a phandle, and results in warnings when the example is validated (or any device tree using that device, for that matter). Let's remove that requirement. Fixes: f7356e47032c ("dt-bindings: iio: adc: ad7192: Add binding documentation for AD7192") Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org>
2019-10-02dt-bindings: media: rc: Fix redundant stringMaxime Ripard
The linux,rc-map-name property is described using an enum, yet a value has been put in that enum twice, resulting in a warning. Let's fix that. Fixes: 7c31b9d67342 ("media: dt-bindings: media: Add YAML schemas for the generic RC bindings") Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org>
2019-10-02dt-bindings: dsp: Fix fsl,dsp exampleMaxime Ripard
The fsl,dsp binding requires a memory-region, yet its example doesn't have one which results in a warning. Let's add a memory-region phandle to the example. Fixes: 7db2f2dfc701 ("dt-bindings: dsp: fsl: Add DSP core binding support") Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Rob Herring <robh@kernel.org>
2019-10-02drm/amd/display: fix dcn21 Makefile for clangArnd Bergmann
Just like all the other variants, this one passes invalid compile-time options with clang after the new code got merged: clang: error: unknown argument: '-mpreferred-stack-boundary=4' scripts/Makefile.build:265: recipe for target 'drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.o' failed Use the same variant that we have for dcn20 to fix compilation. Fixes: eced51f9babb ("drm/amd/display: Add hubp block for Renoir (v2)") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-02drm/amd/display: hide an unused variableArnd Bergmann
Without CONFIG_DEBUG_FS, we get a warning for an unused variable: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6020:33: error: unused variable 'source' [-Werror,-Wunused-variable] Hide the variable in an #ifdef like its only users. Fixes: 14b2584636c6 ("drm/amd/display: add functionality to grab DPRX CRC entries.") Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-02drm/amdgpu: display_mode_vba_21: remove uint typedefArnd Bergmann
The type definition for 'uint' clashes with the generic kernel headers: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_mode_vba_21.c:43:22: error: redefinition of typedef 'uint' is a C11 feature [-Werror,-Wtypedef-redefinition] include/linux/types.h:92:23: note: previous definition is here Just remove this type and use plain 'unsigned int' consistently, as it is already use almost everywhere in this file. Fixes: b04641a3f4c5 ("drm/amd/display: Add Renoir DML") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-02drm/amdgpu: hide another #warningArnd Bergmann
An earlier patch of mine disabled some #warning statements that get in the way of build testing, but then another instance was added around the same time. Remove that as well. Fixes: b5203d16aef4 ("drm/amd/amdgpu: hide #warning for missing DC config") Fixes: e1c14c43395c ("drm/amdgpu: Enable DC on Renoir") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-02drm/amdgpu: make pmu support optional, againArnd Bergmann
When CONFIG_PERF_EVENTS is disabled, we cannot compile the pmu portion of the amdgpu driver: drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:48:38: error: no member named 'hw' in 'struct perf_event' struct hw_perf_event *hwc = &event->hw; ~~~~~ ^ drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:51:13: error: no member named 'attr' in 'struct perf_event' if (event->attr.type != event->pmu->type) ~~~~~ ^ ... The same bug was already fixed by commit d155bef0636e ("amdgpu: make pmu support optional") but broken again by what looks like an incorrectly rebased patch. Fixes: 64f55e629237 ("drm/amdgpu: Add RAS EEPROM table.") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-02drm/amd/display: memory leakNavid Emamdoost
In dcn*_clock_source_create when dcn20_clk_src_construct fails allocated clk_src needs release. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-02drm/amdgpu: fix multiple memory leaks in acp_hw_initNavid Emamdoost
In acp_hw_init there are some allocations that needs to be released in case of failure: 1- adev->acp.acp_genpd should be released if any allocation attemp for adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails. 2- all of those allocations should be released if mfd_add_hotplug_devices or pm_genpd_add_device fail. 3- Release is needed in case of time out values expire. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-02drm/amdgpu: return tcc_disabled_mask to userspaceMarek Olšák
UMDs need this for correct programming of harvested chips. Signed-off-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-02drm/amdgpu: don't increment vram lost if we are in hibernationAlex Deucher
We reset the GPU as part of our hibernation sequence so we need to make sure we don't mark vram as lost in that case. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111879 Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-02Revert "drm/amdgpu: disable stutter mode for renoir"Aaron Liu
This reverts commit 5813f97a5969bf1e7e723397a74e00b5de7278d6. Since SBIOS WCD9925N, NMI printing disappeared. Hence enable stutter mode. Signed-off-by: Aaron Liu <aaron.liu@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-02drm/amd/powerplay: add sensor lock support for smuKevin Wang
when multithreading access sysfs of amdgpu_pm_info at the sametime. the swsmu driver cause smu firmware hang. eg: single thread access: Message A + Param A ==> right Message B + Param B ==> right Message C + Param C ==> right multithreading access: Message A + Param B ==> error Message B + Param A ==> error Message C + Param C ==> right the patch will add sensor lock(mutex) to avoid this error. Signed-off-by: Kevin Wang <kevin1.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.3.x
2019-10-02drm/amd/powerplay: change metrics update period from 1ms to 100msKevin Wang
v2: change period from 10ms to 100ms (typo error) too high frequence to update mertrics table will cause smu firmware error,so change mertrics table update period from 1ms to 100ms (navi10, 12, 14) Signed-off-by: Kevin Wang <kevin1.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.3.x
2019-10-02drm/amdgpu: revert "disable bulk moves for now"Christian König
This reverts commit a213c2c7e235cfc0e0a161a558f7fdf2fb3a624a. The changes to fix this should have landed in 5.1. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Zhou, David(ChunMing) <David1.Zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-02MIPS: octeon: Include required header; fix octeon ethernet buildPaul Burton
Commit 171a9bae68c7 ("staging/octeon: Allow test build on !MIPS") moved the inclusion of a bunch of headers by various files in the Octeon ethernet driver into a common header, but in doing so it changed the order in which those headers are included. Prior to the referenced commit drivers/staging/octeon/ethernet.c included asm/octeon/cvmx-pip.h before asm/octeon/cvmx-ipd.h, which makes use of the CVMX_PIP_SFT_RST definition pulled in by the former. After commit 171a9bae68c7 ("staging/octeon: Allow test build on !MIPS") we pull in asm/octeon/cvmx-ipd.h first & builds fail with: In file included from drivers/staging/octeon/octeon-ethernet.h:27, from drivers/staging/octeon/ethernet.c:22: arch/mips/include/asm/octeon/cvmx-ipd.h: In function 'cvmx_ipd_free_ptr': arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: error: storage size of 'pip_sft_rst' isn't known union cvmx_pip_sft_rst pip_sft_rst; ^~~~~~~~~~~ arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: error: 'CVMX_PIP_SFT_RST' undeclared (first use in this function); did you mean 'CVMX_CIU_SOFT_RST'? pip_sft_rst.u64 = cvmx_read_csr(CVMX_PIP_SFT_RST); ^~~~~~~~~~~~~~~~ CVMX_CIU_SOFT_RST arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: note: each undeclared identifier is reported only once for each function it appears in arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: warning: unused variable 'pip_sft_rst' [-Wunused-variable] union cvmx_pip_sft_rst pip_sft_rst; ^~~~~~~~~~~ make[4]: *** [scripts/Makefile.build:266: drivers/staging/octeon/ethernet.o] Error 1 make[3]: *** [scripts/Makefile.build:509: drivers/staging/octeon] Error 2 Fix this by having asm/octeon/cvmx-ipd.h include the asm/octeon/cvmx-pip-defs.h header that it is reliant upon, rather than requiring its users to pull in that header before it. Signed-off-by: Paul Burton <paul.burton@mips.com> Fixes: 171a9bae68c7 ("staging/octeon: Allow test build on !MIPS") Cc: David S. Miller <davem@davemloft.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: linux-mips@vger.kernel.org Cc: David S . Miller <davem@davemloft.net> Cc: Matthew Wilcox <willy@infradead.org>
2019-10-02ptp_qoriq: Initialize the registers' spinlock before calling ptp_qoriq_settimeVladimir Oltean
Because ptp_qoriq_settime is being called prior to spin_lock_init, the following stack trace can be seen at driver probe time: [ 2.269117] the code is fine but needs lockdep annotation. [ 2.274569] turning off the locking correctness validator. [ 2.280027] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc7-01478-g01eaa67a4797 #263 [ 2.288073] Hardware name: Freescale LS1021A [ 2.292337] [<c0313cb4>] (unwind_backtrace) from [<c030e11c>] (show_stack+0x10/0x14) [ 2.300045] [<c030e11c>] (show_stack) from [<c1219440>] (dump_stack+0xcc/0xf8) [ 2.307235] [<c1219440>] (dump_stack) from [<c03b9b44>] (register_lock_class+0x730/0x73c) [ 2.315372] [<c03b9b44>] (register_lock_class) from [<c03b6190>] (__lock_acquire+0x78/0x270c) [ 2.323856] [<c03b6190>] (__lock_acquire) from [<c03b90cc>] (lock_acquire+0xe0/0x22c) [ 2.331649] [<c03b90cc>] (lock_acquire) from [<c123c310>] (_raw_spin_lock_irqsave+0x54/0x68) [ 2.340048] [<c123c310>] (_raw_spin_lock_irqsave) from [<c0e73fe4>] (ptp_qoriq_settime+0x38/0x80) [ 2.348878] [<c0e73fe4>] (ptp_qoriq_settime) from [<c0e746d4>] (ptp_qoriq_init+0x1f8/0x484) [ 2.357189] [<c0e746d4>] (ptp_qoriq_init) from [<c0e74aac>] (ptp_qoriq_probe+0xd0/0x184) [ 2.365243] [<c0e74aac>] (ptp_qoriq_probe) from [<c0b0a07c>] (platform_drv_probe+0x48/0x9c) [ 2.373555] [<c0b0a07c>] (platform_drv_probe) from [<c0b07a14>] (really_probe+0x1c4/0x400) [ 2.381779] [<c0b07a14>] (really_probe) from [<c0b07e28>] (driver_probe_device+0x78/0x1b8) [ 2.390003] [<c0b07e28>] (driver_probe_device) from [<c0b081d0>] (device_driver_attach+0x58/0x60) [ 2.398832] [<c0b081d0>] (device_driver_attach) from [<c0b082d4>] (__driver_attach+0xfc/0x160) [ 2.407402] [<c0b082d4>] (__driver_attach) from [<c0b05a84>] (bus_for_each_dev+0x68/0xb4) [ 2.415539] [<c0b05a84>] (bus_for_each_dev) from [<c0b06b68>] (bus_add_driver+0x104/0x20c) [ 2.423763] [<c0b06b68>] (bus_add_driver) from [<c0b0909c>] (driver_register+0x78/0x10c) [ 2.431815] [<c0b0909c>] (driver_register) from [<c030313c>] (do_one_initcall+0x8c/0x3ac) [ 2.439954] [<c030313c>] (do_one_initcall) from [<c1f013f4>] (kernel_init_freeable+0x468/0x548) [ 2.448610] [<c1f013f4>] (kernel_init_freeable) from [<c12344d8>] (kernel_init+0x8/0x10c) [ 2.456745] [<c12344d8>] (kernel_init) from [<c03010b4>] (ret_from_fork+0x14/0x20) [ 2.464273] Exception stack(0xea89ffb0 to 0xea89fff8) [ 2.469297] ffa0: 00000000 00000000 00000000 00000000 [ 2.477432] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 2.485566] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 Fixes: ff54571a747b ("ptp_qoriq: convert to use ptp_qoriq_init/free") Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-02Merge branch 'SJA1105-DSA-locking-fixes-for-PTP'David S. Miller
Vladimir Oltean says: ==================== SJA1105 DSA locking fixes for PTP This series fixes the locking API usage problems spotted when compiling the kernel with CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_DEBUG_SPINLOCK=y. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-02net: dsa: sja1105: Fix sleeping while atomic in .port_hwtstamp_setVladimir Oltean
Currently this stack trace can be seen with CONFIG_DEBUG_ATOMIC_SLEEP=y: [ 41.568348] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:909 [ 41.576757] in_atomic(): 1, irqs_disabled(): 0, pid: 208, name: ptp4l [ 41.583212] INFO: lockdep is turned off. [ 41.587123] CPU: 1 PID: 208 Comm: ptp4l Not tainted 5.3.0-rc6-01445-ge950f2d4bc7f-dirty #1827 [ 41.599873] [<c0313d7c>] (unwind_backtrace) from [<c030e13c>] (show_stack+0x10/0x14) [ 41.607584] [<c030e13c>] (show_stack) from [<c1212d50>] (dump_stack+0xd4/0x100) [ 41.614863] [<c1212d50>] (dump_stack) from [<c037dfc8>] (___might_sleep+0x1c8/0x2b4) [ 41.622574] [<c037dfc8>] (___might_sleep) from [<c122ea90>] (__mutex_lock+0x48/0xab8) [ 41.630368] [<c122ea90>] (__mutex_lock) from [<c122f51c>] (mutex_lock_nested+0x1c/0x24) [ 41.638340] [<c122f51c>] (mutex_lock_nested) from [<c0c6fe08>] (sja1105_static_config_reload+0x30/0x27c) [ 41.647779] [<c0c6fe08>] (sja1105_static_config_reload) from [<c0c7015c>] (sja1105_hwtstamp_set+0x108/0x1cc) [ 41.657562] [<c0c7015c>] (sja1105_hwtstamp_set) from [<c0feb650>] (dev_ifsioc+0x18c/0x330) [ 41.665788] [<c0feb650>] (dev_ifsioc) from [<c0febbd8>] (dev_ioctl+0x320/0x6e8) [ 41.673064] [<c0febbd8>] (dev_ioctl) from [<c0f8b1f4>] (sock_ioctl+0x334/0x5e8) [ 41.680340] [<c0f8b1f4>] (sock_ioctl) from [<c05404a8>] (do_vfs_ioctl+0xb0/0xa10) [ 41.687789] [<c05404a8>] (do_vfs_ioctl) from [<c0540e3c>] (ksys_ioctl+0x34/0x58) [ 41.695151] [<c0540e3c>] (ksys_ioctl) from [<c0301000>] (ret_fast_syscall+0x0/0x28) [ 41.702768] Exception stack(0xe8495fa8 to 0xe8495ff0) [ 41.707796] 5fa0: beff4a8c 00000001 00000011 000089b0 beff4a8c beff4a80 [ 41.715933] 5fc0: beff4a8c 00000001 0000000c 00000036 b6fa98c8 004e19c1 00000001 00000000 [ 41.724069] 5fe0: 004dcedc beff4a6c 004c0738 b6e7af4c [ 41.729860] BUG: scheduling while atomic: ptp4l/208/0x00000002 [ 41.735682] INFO: lockdep is turned off. Enabling RX timestamping will logically disturb the fastpath (processing of meta frames). Replace bool hwts_rx_en with a bit that is checked atomically from the fastpath and temporarily unset from the sleepable context during a change of the RX timestamping process (a destructive operation anyways, requires switch reset). If found unset, the fastpath (net/dsa/tag_sja1105.c) will just drop any received meta frame and not take the meta_lock at all. Fixes: a602afd200f5 ("net: dsa: sja1105: Expose PTP timestamping ioctls to userspace") Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-02net: dsa: sja1105: Initialize the meta_lockVladimir Oltean
Otherwise, with CONFIG_DEBUG_SPINLOCK=y, this stack trace gets printed when enabling RX timestamping and receiving a PTP frame: [ 318.537078] INFO: trying to register non-static key. [ 318.542040] the code is fine but needs lockdep annotation. [ 318.547500] turning off the locking correctness validator. [ 318.552972] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.0-13257-g0825b0669811-dirty #1962 [ 318.561283] Hardware name: Freescale LS1021A [ 318.565566] [<c03144bc>] (unwind_backtrace) from [<c030e164>] (show_stack+0x10/0x14) [ 318.573289] [<c030e164>] (show_stack) from [<c11b9f50>] (dump_stack+0xd4/0x100) [ 318.580579] [<c11b9f50>] (dump_stack) from [<c03b9b40>] (register_lock_class+0x728/0x734) [ 318.588731] [<c03b9b40>] (register_lock_class) from [<c03b60c4>] (__lock_acquire+0x78/0x25cc) [ 318.597227] [<c03b60c4>] (__lock_acquire) from [<c03b8ef8>] (lock_acquire+0xd8/0x234) [ 318.605033] [<c03b8ef8>] (lock_acquire) from [<c11db934>] (_raw_spin_lock+0x44/0x54) [ 318.612755] [<c11db934>] (_raw_spin_lock) from [<c1164370>] (sja1105_rcv+0x1f8/0x4e8) [ 318.620561] [<c1164370>] (sja1105_rcv) from [<c115d7cc>] (dsa_switch_rcv+0x80/0x204) [ 318.628283] [<c115d7cc>] (dsa_switch_rcv) from [<c0f58c80>] (__netif_receive_skb_one_core+0x50/0x6c) [ 318.637386] [<c0f58c80>] (__netif_receive_skb_one_core) from [<c0f58f04>] (netif_receive_skb_internal+0xac/0x264) [ 318.647611] [<c0f58f04>] (netif_receive_skb_internal) from [<c0f59e98>] (napi_gro_receive+0x1d8/0x338) [ 318.656887] [<c0f59e98>] (napi_gro_receive) from [<c0c298a4>] (gfar_clean_rx_ring+0x328/0x724) [ 318.665472] [<c0c298a4>] (gfar_clean_rx_ring) from [<c0c29e60>] (gfar_poll_rx_sq+0x34/0x94) [ 318.673795] [<c0c29e60>] (gfar_poll_rx_sq) from [<c0f5b40c>] (net_rx_action+0x128/0x4f8) [ 318.681860] [<c0f5b40c>] (net_rx_action) from [<c03022f0>] (__do_softirq+0x148/0x5ac) [ 318.689666] [<c03022f0>] (__do_softirq) from [<c0355af4>] (irq_exit+0x160/0x170) [ 318.697040] [<c0355af4>] (irq_exit) from [<c03c6818>] (__handle_domain_irq+0x60/0xb4) [ 318.704847] [<c03c6818>] (__handle_domain_irq) from [<c07e9440>] (gic_handle_irq+0x58/0x9c) [ 318.713172] [<c07e9440>] (gic_handle_irq) from [<c0301a70>] (__irq_svc+0x70/0x98) [ 318.720622] Exception stack(0xc2001f18 to 0xc2001f60) [ 318.725656] 1f00: 00000001 00000006 [ 318.733805] 1f20: 00000000 c20165c0 ffffe000 c2010cac c2010cf4 00000001 00000000 c2010c88 [ 318.741955] 1f40: c1f7a5a8 00000000 00000000 c2001f68 c03ba140 c030a288 200e0013 ffffffff [ 318.750110] [<c0301a70>] (__irq_svc) from [<c030a288>] (arch_cpu_idle+0x24/0x3c) [ 318.757486] [<c030a288>] (arch_cpu_idle) from [<c038a480>] (do_idle+0x1b8/0x2a4) [ 318.764859] [<c038a480>] (do_idle) from [<c038a94c>] (cpu_startup_entry+0x18/0x1c) [ 318.772407] [<c038a94c>] (cpu_startup_entry) from [<c1e00f10>] (start_kernel+0x4cc/0x4fc) Fixes: 844d7edc6a34 ("net: dsa: sja1105: Add a global sja1105_tagger_data structure") Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-02net/rds: Fix error handling in rds_ib_add_one()Dotan Barak
rds_ibdev:ipaddr_list and rds_ibdev:conn_list are initialized after allocation some resources such as protection domain. If allocation of such resources fail, then these uninitialized variables are accessed in rds_ib_dev_free() in failure path. This can potentially crash the system. The code has been updated to initialize these variables very early in the function. Signed-off-by: Dotan Barak <dotanb@dev.mellanox.co.il> Signed-off-by: Sudhakar Dindukurti <sudhakar.dindukurti@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-02net: dsa: rtl8366: Check VLAN ID and not portsLinus Walleij
There has been some confusion between the port number and the VLAN ID in this driver. What we need to check for validity is the VLAN ID, nothing else. The current confusion came from assigning a few default VLANs for default routing and we need to rewrite that properly. Instead of checking if the port number is a valid VLAN ID, check the actual VLAN IDs passed in to the callback one by one as expected. Fixes: d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-02mlx5: avoid 64-bit division in dr_icm_pool_mr_create()Michal Kubecek
Recently added code introduces 64-bit division in dr_icm_pool_mr_create() so that build on 32-bit architectures fails with ERROR: "__umoddi3" [drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko] undefined! As the divisor is always a power of 2, we can use bitwise operation instead. Fixes: 29cf8febd185 ("net/mlx5: DR, ICM pool memory allocator") Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Michal Kubecek <mkubecek@suse.cz> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-02tipc: fix unlimited bundling of small messagesTuong Lien
We have identified a problem with the "oversubscription" policy in the link transmission code. When small messages are transmitted, and the sending link has reached the transmit window limit, those messages will be bundled and put into the link backlog queue. However, bundles of data messages are counted at the 'CRITICAL' level, so that the counter for that level, instead of the counter for the real, bundled message's level is the one being increased. Subsequent, to-be-bundled data messages at non-CRITICAL levels continue to be tested against the unchanged counter for their own level, while contributing to an unrestrained increase at the CRITICAL backlog level. This leaves a gap in congestion control algorithm for small messages that can result in starvation for other users or a "real" CRITICAL user. Even that eventually can lead to buffer exhaustion & link reset. We fix this by keeping a 'target_bskb' buffer pointer at each levels, then when bundling, we only bundle messages at the same importance level only. This way, we know exactly how many slots a certain level have occupied in the queue, so can manage level congestion accurately. By bundling messages at the same level, we even have more benefits. Let consider this: - One socket sends 64-byte messages at the 'CRITICAL' level; - Another sends 4096-byte messages at the 'LOW' level; When a 64-byte message comes and is bundled the first time, we put the overhead of message bundle to it (+ 40-byte header, data copy, etc.) for later use, but the next message can be a 4096-byte one that cannot be bundled to the previous one. This means the last bundle carries only one payload message which is totally inefficient, as for the receiver also! Later on, another 64-byte message comes, now we make a new bundle and the same story repeats... With the new bundling algorithm, this will not happen, the 64-byte messages will be bundled together even when the 4096-byte message(s) comes in between. However, if the 4096-byte messages are sent at the same level i.e. 'CRITICAL', the bundling algorithm will again cause the same overhead. Also, the same will happen even with only one socket sending small messages at a rate close to the link transmit's one, so that, when one message is bundled, it's transmitted shortly. Then, another message comes, a new bundle is created and so on... We will solve this issue radically by another patch. Fixes: 365ad353c256 ("tipc: reduce risk of user starvation during link congestion") Reported-by: Hoang Le <hoang.h.le@dektech.com.au> Acked-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-02xen/efi: have a common runtime setup functionJuergen Gross
Today the EFI runtime functions are setup in architecture specific code (x86 and arm), with the functions themselves living in drivers/xen as they are not architecture dependent. As the setup is exactly the same for arm and x86 move the setup to drivers/xen, too. This at once removes the need to make the single functions global visible. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> [boris: "Dropped EXPORT_SYMBOL_GPL(xen_efi_runtime_setup)"] Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2019-10-01arm: xen: mm: use __GPF_DMA32 for arm64Peng Fan
arm64 shares some code under arch/arm/xen, including mm.c. However ZONE_DMA is removed by commit ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32"). So add a check if CONFIG_ZONE_DMA32 is enabled use __GFP_DMA32. Signed-off-by: Peng Fan <peng.fan@nxp.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
2019-10-01xen-netfront: do not use ~0U as error return value for xennet_fill_frags()Dongli Zhang
xennet_fill_frags() uses ~0U as return value when the sk_buff is not able to cache extra fragments. This is incorrect because the return type of xennet_fill_frags() is RING_IDX and 0xffffffff is an expected value for ring buffer index. In the situation when the rsp_cons is approaching 0xffffffff, the return value of xennet_fill_frags() may become 0xffffffff which xennet_poll() (the caller) would regard as error. As a result, queue->rx.rsp_cons is set incorrectly because it is updated only when there is error. If there is no error, xennet_poll() would be responsible to update queue->rx.rsp_cons. Finally, queue->rx.rsp_cons would point to the rx ring buffer entries whose queue->rx_skbs[i] and queue->grant_rx_ref[i] are already cleared to NULL. This leads to NULL pointer access in the next iteration to process rx ring buffer entries. The symptom is similar to the one fixed in commit 00b368502d18 ("xen-netfront: do not assume sk_buff_head list is empty in error handling"). This patch changes the return type of xennet_fill_frags() to indicate whether it is successful or failed. The queue->rx.rsp_cons will be always updated inside this function. Fixes: ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags") Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-01ipv6: Handle race in addrconf_dad_workDavid Ahern
Rajendra reported a kernel panic when a link was taken down: [ 6870.263084] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 [ 6870.271856] IP: [<ffffffff8efc5764>] __ipv6_ifa_notify+0x154/0x290 <snip> [ 6870.570501] Call Trace: [ 6870.573238] [<ffffffff8efc58c6>] ? ipv6_ifa_notify+0x26/0x40 [ 6870.579665] [<ffffffff8efc98ec>] ? addrconf_dad_completed+0x4c/0x2c0 [ 6870.586869] [<ffffffff8efe70c6>] ? ipv6_dev_mc_inc+0x196/0x260 [ 6870.593491] [<ffffffff8efc9c6a>] ? addrconf_dad_work+0x10a/0x430 [ 6870.600305] [<ffffffff8f01ade4>] ? __switch_to_asm+0x34/0x70 [ 6870.606732] [<ffffffff8ea93a7a>] ? process_one_work+0x18a/0x430 [ 6870.613449] [<ffffffff8ea93d6d>] ? worker_thread+0x4d/0x490 [ 6870.619778] [<ffffffff8ea93d20>] ? process_one_work+0x430/0x430 [ 6870.626495] [<ffffffff8ea99dd9>] ? kthread+0xd9/0xf0 [ 6870.632145] [<ffffffff8f01ade4>] ? __switch_to_asm+0x34/0x70 [ 6870.638573] [<ffffffff8ea99d00>] ? kthread_park+0x60/0x60 [ 6870.644707] [<ffffffff8f01ae77>] ? ret_from_fork+0x57/0x70 [ 6870.650936] Code: 31 c0 31 d2 41 b9 20 00 08 02 b9 09 00 00 0 addrconf_dad_work is kicked to be scheduled when a device is brought up. There is a race between addrcond_dad_work getting scheduled and taking the rtnl lock and a process taking the link down (under rtnl). The latter removes the host route from the inet6_addr as part of addrconf_ifdown which is run for NETDEV_DOWN. The former attempts to use the host route in ipv6_ifa_notify. If the down event removes the host route due to the race to the rtnl, then the BUG listed above occurs. This scenario does not occur when the ipv6 address is not kept (net.ipv6.conf.all.keep_addr_on_down = 0) as addrconf_ifdown sets the state of the ifp to DEAD. Handle when the addresses are kept by checking IF_READY which is reset by addrconf_ifdown. The 'dead' flag for an inet6_addr is set only under rtnl, in addrconf_ifdown and it means the device is getting removed (or IPv6 is disabled). The interesting cases for changing the idev flag are addrconf_notify (NETDEV_UP and NETDEV_CHANGE) and addrconf_ifdown (reset the flag). The former does not have the idev lock - only rtnl; the latter has both. Based on that the existing dead + IF_READY check can be moved to right after the rtnl_lock in addrconf_dad_work. Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional") Reported-by: Rajendra Dendukuri <rajendra.dendukuri@broadcom.com> Signed-off-by: David Ahern <dsahern@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-01tcp: adjust rto_base in retransmits_timed_out()Eric Dumazet
The cited commit exposed an old retransmits_timed_out() bug which assumed it could call tcp_model_timeout() with TCP_RTO_MIN as rto_base for all states. But flows in SYN_SENT or SYN_RECV state uses a different RTO base (1 sec instead of 200 ms, unless BPF choses another value) This caused a reduction of SYN retransmits from 6 to 4 with the default /proc/sys/net/ipv4/tcp_syn_retries value. Fixes: a41e8a88b06e ("tcp: better handle TCP_USER_TIMEOUT in SYN_SENT state") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Marek Majkowski <marek@cloudflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-01vsock: Fix a lockdep warning in __vsock_release()Dexuan Cui
Lockdep is unhappy if two locks from the same class are held. Fix the below warning for hyperv and virtio sockets (vmci socket code doesn't have the issue) by using lock_sock_nested() when __vsock_release() is called recursively: ============================================ WARNING: possible recursive locking detected 5.3.0+ #1 Not tainted -------------------------------------------- server/1795 is trying to acquire lock: ffff8880c5158990 (sk_lock-AF_VSOCK){+.+.}, at: hvs_release+0x10/0x120 [hv_sock] but task is already holding lock: ffff8880c5158150 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x2e/0xf0 [vsock] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(sk_lock-AF_VSOCK); lock(sk_lock-AF_VSOCK); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by server/1795: #0: ffff8880c5d05ff8 (&sb->s_type->i_mutex_key#10){+.+.}, at: __sock_release+0x2d/0xa0 #1: ffff8880c5158150 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x2e/0xf0 [vsock] stack backtrace: CPU: 5 PID: 1795 Comm: server Not tainted 5.3.0+ #1 Call Trace: dump_stack+0x67/0x90 __lock_acquire.cold.67+0xd2/0x20b lock_acquire+0xb5/0x1c0 lock_sock_nested+0x6d/0x90 hvs_release+0x10/0x120 [hv_sock] __vsock_release+0x24/0xf0 [vsock] __vsock_release+0xa0/0xf0 [vsock] vsock_release+0x12/0x30 [vsock] __sock_release+0x37/0xa0 sock_close+0x14/0x20 __fput+0xc1/0x250 task_work_run+0x98/0xc0 do_exit+0x344/0xc60 do_group_exit+0x47/0xb0 get_signal+0x15c/0xc50 do_signal+0x30/0x720 exit_to_usermode_loop+0x50/0xa0 do_syscall_64+0x24e/0x270 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f4184e85f31 Tested-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-01hso: fix NULL-deref on tty openJohan Hovold
Fix NULL-pointer dereference on tty open due to a failure to handle a missing interrupt-in endpoint when probing modem ports: BUG: kernel NULL pointer dereference, address: 0000000000000006 ... RIP: 0010:tiocmget_submit_urb+0x1c/0xe0 [hso] ... Call Trace: hso_start_serial_device+0xdc/0x140 [hso] hso_serial_open+0x118/0x1b0 [hso] tty_open+0xf1/0x490 Fixes: 542f54823614 ("tty: Modem functions for the HSO driver") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>