summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-05-15x86: Fix early boot crash on gcc-10, third tryBorislav Petkov
... or the odyssey of trying to disable the stack protector for the function which generates the stack canary value. The whole story started with Sergei reporting a boot crash with a kernel built with gcc-10: Kernel panic — not syncing: stack-protector: Kernel stack is corrupted in: start_secondary CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.6.0-rc5—00235—gfffb08b37df9 #139 Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./H77M—D3H, BIOS F12 11/14/2013 Call Trace: dump_stack panic ? start_secondary __stack_chk_fail start_secondary secondary_startup_64 -—-[ end Kernel panic — not syncing: stack—protector: Kernel stack is corrupted in: start_secondary This happens because gcc-10 tail-call optimizes the last function call in start_secondary() - cpu_startup_entry() - and thus emits a stack canary check which fails because the canary value changes after the boot_init_stack_canary() call. To fix that, the initial attempt was to mark the one function which generates the stack canary with: __attribute__((optimize("-fno-stack-protector"))) ... start_secondary(void *unused) however, using the optimize attribute doesn't work cumulatively as the attribute does not add to but rather replaces previously supplied optimization options - roughly all -fxxx options. The key one among them being -fno-omit-frame-pointer and thus leading to not present frame pointer - frame pointer which the kernel needs. The next attempt to prevent compilers from tail-call optimizing the last function call cpu_startup_entry(), shy of carving out start_secondary() into a separate compilation unit and building it with -fno-stack-protector, was to add an empty asm(""). This current solution was short and sweet, and reportedly, is supported by both compilers but we didn't get very far this time: future (LTO?) optimization passes could potentially eliminate this, which leads us to the third attempt: having an actual memory barrier there which the compiler cannot ignore or move around etc. That should hold for a long time, but hey we said that about the other two solutions too so... Reported-by: Sergei Trofimovich <slyfox@gentoo.org> Signed-off-by: Borislav Petkov <bp@suse.de> Tested-by: Kalle Valo <kvalo@codeaurora.org> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20200314164451.346497-1-slyfox@gentoo.org
2020-05-15MAINTAINERS: add maintainer for mediatek i2c controller driverQii Wang
Add Qii Wang as maintainer for mediatek i2c controller driver. Signed-off-by: Qii Wang <qii.wang@mediatek.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2020-05-15i2c: mux: Replace zero-length array with flexible-arrayGustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2020-05-15i2c: mux: demux-pinctrl: Fix an error handling path in ↵Christophe JAILLET
'i2c_demux_pinctrl_probe()' A call to 'i2c_demux_deactivate_master()' is missing in the error handling path, as already done in the remove function. Fixes: 50a5ba876908 ("i2c: mux: demux-pinctrl: add driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2020-05-15i2c: altera: Fix race between xfer_msg and isr threadAtsushi Nemoto
Use a mutex to protect access to idev->msg_len, idev->buf, etc. which are modified by both altr_i2c_xfer_msg() and altr_i2c_isr(). This is the minimal fix for easy backporting. A cleanup to remove the spinlock will be added later. Signed-off-by: Atsushi Nemoto <atsushi.nemoto@sord.co.jp> Acked-by: Thor Thayer <thor.thayer@linux.intel.com> [wsa: updated commit message] Signed-off-by: Wolfram Sang <wsa@kernel.org>
2020-05-15i2c: algo-pca: update contact emailWolfram Sang
The 'pengutronix' address is defunct for years. Use the proper contact address. Signed-off-by: Wolfram Sang <wsa@kernel.org>
2020-05-15i2c: at91: Fix pinmux after devm_gpiod_get() for bus recoveryCodrin Ciubotariu
devm_gpiod_get() usually calls gpio_request_enable() for non-strict pinmux drivers. These puts the pins in GPIO mode, whithout notifying the pinctrl driver. At this point, the I2C bus no longer owns the pins. To mux the pins back to the I2C bus, we use the pinctrl driver to change the state of the pins to GPIO, before using devm_gpiod_get(). After the pins are received as GPIOs, we switch theer pinctrl state back to the default one, Fixes: d3d3fdcc4c90 ("i2c: at91: implement i2c bus recovery") Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2020-05-15ARM: dts: iwg20d-q7-dbcm-ca: Remove unneeded properties in hdmi@39Ricardo Cañuelo
Remove the adi,input-style and adi,input-justification properties of hdmi@39 to make it compliant with the "adi,adv7511w" DT binding. Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20200511110611.3142-6-ricardo.canuelo@collabora.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-05-15ARM: dts: renesas: Make hdmi encoder nodes compliant with DT bindingsRicardo Cañuelo
Small fixes to make these DTs compliant with the adi,adv7511w and adi,adv7513 bindings: r8a7745-iwg22d-sodimm-dbhd-ca.dts r8a7790-lager.dts r8a7790-stout.dts r8a7791-koelsch.dts r8a7791-porter.dts r8a7792-blanche.dts r8a7793-gose.dts r8a7794-silk.dts: Remove the adi,input-style and adi,input-justification properties. r8a7792-wheat.dts: Reorder the I2C slave addresses of hdmi@3d and hdmi@39 and remove the adi,input-style and adi,input-justification properties. Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20200511110611.3142-3-ricardo.canuelo@collabora.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-05-15arm64: dts: renesas: Make hdmi encoder nodes compliant with DT bindingsRicardo Cañuelo
Small fixes to make these DTs compliant with the adi,adv7511w binding. r8a77970-eagle.dts, r8a77970-v3msk.dts, r8a77980-condor.dts, r8a77980-v3hsk.dts, r8a77990-ebisu.dts: Remove the adi,input-style and adi,input-justification properties. r8a77995-draak.dts: Reorder the I2C slave addresses of the hdmi-encoder@39 node and remove the adi,input-style and adi,input-justification properties. Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20200511110611.3142-2-ricardo.canuelo@collabora.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-05-15objtool: optimize add_dead_ends for split sectionsSami Tolvanen
Instead of iterating through all instructions to find the last instruction each time .rela.discard.(un)reachable points beyond the section, use find_insn to locate the last instruction by looking at the last bytes of the section instead. Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20200421220843.188260-3-samitolvanen@google.com
2020-05-15objtool: use gelf_getsymshndx to handle >64k sectionsSami Tolvanen
Currently, objtool fails to load the correct section for symbols when the index is greater than SHN_LORESERVE. Use gelf_getsymshndx instead of gelf_getsym to handle >64k sections. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lkml.kernel.org/r/20200421220843.188260-2-samitolvanen@google.com
2020-05-15objtool: Allow no-op CFI ops in alternativesPeter Zijlstra
Randy reported a false-positive: arch/x86/hyperv/hv_apic.o: warning: objtool: hv_apic_write()+0x25: alternative modifies stack What happens is that: alternative_io("movl %0, %P1", "xchgl %0, %P1", X86_BUG_11AP, 13d: 89 9d 00 d0 7f ff mov %ebx,-0x803000(%rbp) decodes to an instruction with CFI-ops because it modifies RBP. However, due to this being a !frame-pointer build, that should not in fact change the CFI state. So instead of dis-allowing any CFI-op, verify the op would've actually changed the CFI state. Fixes: 7117f16bf460 ("objtool: Fix ORC vs alternatives") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org>
2020-05-15x86/unwind/orc: Fix error handling in __unwind_start()Josh Poimboeuf
The unwind_state 'error' field is used to inform the reliable unwinding code that the stack trace can't be trusted. Set this field for all errors in __unwind_start(). Also, move the zeroing out of the unwind_state struct to before the ORC table initialization check, to prevent the caller from reading uninitialized data if the ORC table is corrupted. Fixes: af085d9084b4 ("stacktrace/x86: add function for detecting reliable stack traces") Fixes: d3a09104018c ("x86/unwinder/orc: Dont bail on stack overflow") Fixes: 98d0c8ebf77e ("x86/unwind/orc: Prevent unwinding before ORC initialization") Reported-by: Pavel Machek <pavel@denx.de> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/d6ac7215a84ca92b895fdd2e1aa546729417e6e6.1589487277.git.jpoimboe@redhat.com
2020-05-15crypto: hisilicon/zip - Use temporary sqe when doing workZhou Wang
Currently zip sqe is stored in hisi_zip_qp_ctx, which will bring corruption with multiple parallel users of the crypto tfm. This patch removes the zip_sqe in hisi_zip_qp_ctx and uses a temporary sqe instead. Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Shukun Tan <tanshukun1@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15crypto: hisilicon - add device error report through abnormal irqShukun Tan
By configuring the device error in firmware to report through abnormal interruption, process all NFE errors in irq handler. Signed-off-by: Shukun Tan <tanshukun1@huawei.com> Reviewed-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15crypto: hisilicon - remove codes of directly report device errors through MSIShukun Tan
The hardware device can be configured to report directly through MSI, but this method will not go through RAS, configure all hardware errors that should be processed by driver to NFE. Signed-off-by: Shukun Tan <tanshukun1@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15crypto: hisilicon - QM memory management optimizationWeili Qian
Put all the code for the memory allocation into the QM initialization process. Before, The qp memory was allocated when the qp was created, and released when the qp was released, It is now changed to allocate all the qp memory once. Signed-off-by: Weili Qian <qianweili@huawei.com> Signed-off-by: Shukun Tan <tanshukun1@huawei.com> Reviewed-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15crypto: hisilicon - unify initial value assignment into QMWeili Qian
Some initial value assignment of struct hisi_qm could put into QM. Signed-off-by: Weili Qian <qianweili@huawei.com> Signed-off-by: Shukun Tan <tanshukun1@huawei.com> Reviewed-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15crypto: hisilicon - remove use_dma_api related codesShukun Tan
The codes related use_dma_api is useless which should be removed. Signed-off-by: Shukun Tan <tanshukun1@huawei.com> Reviewed-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15crypto: hisilicon - add FLR supportShukun Tan
Add callback reset_prepare and reset_done in QM, The callback reset_prepare will uninit device error configuration and stop the QM, the callback reset_done will init the device error configuration and restart the QM. Uninit the error configuration will disable device block master OOO when Multi-bit ECC error occurs to avoid the request of FLR will not return. Signed-off-by: Shukun Tan <tanshukun1@huawei.com> Reviewed-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15crypto: hisilicon/qm - add state machine for QMZhou Wang
Add specific states for qm and qp, every state change under critical region to prevent from race condition. Meanwhile, qp state change will also depend on qm state. Due to the introduction of these states, it is necessary to pay attention to the calls of public logic, such as concurrent scenarios resetting and releasing queue will call hisi_qm_stop, which needs to add additional status to distinguish and process. Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Shukun Tan <tanshukun1@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15crypto: hisilicon - refactor module parameter pf_q_num related codeShukun Tan
put q_num_set similar code into qm to reduce the redundancy. Signed-off-by: Shukun Tan <tanshukun1@huawei.com> Reviewed-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15crypto: hisilicon/zip - modify the ZIP probe processLongfang Liu
Misc fixes on coding style: 1.Merge QM initialization code into a function 2.Merge QM's PF and VF initialization into a function Signed-off-by: Longfang Liu <liulongfang@huawei.com> Signed-off-by: Zaibo Xu <xuzaibo@huawei.com> Signed-off-by: Shukun Tan <tanshukun1@huawei.com> Reviewed-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15crypto: hisilicon/hpre - modify the HPRE probe processLongfang Liu
Misc fixes on coding style: 1.Merge pre-initialization and initialization of QM 2.Package the initialization of QM's PF and VF into a function Signed-off-by: Longfang Liu <liulongfang@huawei.com> Signed-off-by: Zaibo Xu <xuzaibo@huawei.com> Signed-off-by: Shukun Tan <tanshukun1@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15crypto: hisilicon/sec2 - modify the SEC probe processLongfang Liu
Adjust the position of SMMU status check and SEC queue initialization in SEC probe Signed-off-by: Longfang Liu <liulongfang@huawei.com> Signed-off-by: Zaibo Xu <xuzaibo@huawei.com> Signed-off-by: Shukun Tan <tanshukun1@huawei.com> Reviewed-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15crypto: hisilicon/sec2 - constify sec_dfx_regsRikard Falkeborn
sec_dfx_regs is never changed and can therefore be made const. This allows the compiler to put it in the text section instead of the data section. Before: text data bss dec hex filename 17982 7312 480 25774 64ae drivers/crypto/hisilicon/sec2/sec_main.o After: text data bss dec hex filename 18366 6928 480 25774 64ae drivers/crypto/hisilicon/sec2/sec_main.o Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15crypto: hisilicon/zip - constify struct debugfs_reg32Rikard Falkeborn
hzip_dfx_regs is never changed and can be made const. This allows the compiler to put it in the text section instead of the data section. Before: text data bss dec hex filename 15236 6160 480 21876 5574 drivers/crypto/hisilicon/zip/zip_main.o After: text data bss dec hex filename 15620 5776 480 21876 5574 drivers/crypto/hisilicon/zip/zip_main.o Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Reviewed-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15crypto: hisilicon/hpre - constify struct debugfs_reg32Rikard Falkeborn
hpre_cluster_dfx_regs and hpre_com_dfx_regs are never changed and can therefore be made const. This allows the compiler to put it in the text section instead of the data section. Before: text data bss dec hex filename 16455 6288 480 23223 5ab7 drivers/crypto/hisilicon/hpre/hpre_main.o After: text data bss dec hex filename 16839 5904 480 23223 5ab7 drivers/crypto/hisilicon/hpre/hpre_main.o Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15crypto: ccree - constify struct debugfs_reg32Rikard Falkeborn
pid_cd_regs and debug_regs are never changed and can therefore be made const. This allows the compiler to put it in the text section instead of the data section. Before: text data bss dec hex filename 2871 2320 64 5255 1487 drivers/crypto/ccree/cc_debugfs.o After: text data bss dec hex filename 3255 1936 64 5255 1487 drivers/crypto/ccree/cc_debugfs.o Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15crypto: blake2b - Fix clang optimization for ARMv7-MArnd Bergmann
When building for ARMv7-M, clang-9 or higher tries to unroll some loops, which ends up confusing the register allocator to the point of generating rather bad code and using more than the warning limit for stack frames: warning: stack frame size of 1200 bytes in function 'blake2b_compress' [-Wframe-larger-than=] Forcing it to not unroll the final loop avoids this problem. Fixes: 91d689337fe8 ("crypto: blake2b - add blake2b generic implementation") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15Merge tag 'drm-misc-fixes-2020-05-14' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Just one meson patch this time to propagate an error code Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200514073538.wvdtv5s2mt4wdrdj@gilmour.lan
2020-05-15dmaengine: ti: k3-udma: Fix TR mode flags for slave_sg and memcpyPeter Ujfalusi
cppi5_tr_csf_set() clears previously set Configuration Specific Flags. Setting the EOP flag clears the SUPR_EVT flag for the last TR which is not desirable as we do not want to have events from the TR. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20200512134531.5742-1-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-05-15dmaengine: zynqmp_dma: Move list_del inside zynqmp_dma_free_descriptor.Rafał Hibner
List elements are not formally removed from list during zynqmp_dma_reset. Signed-off-by: Rafal Hibner <rafal.hibner@secom.com.pl> Link: https://lore.kernel.org/r/20200506102844.2259-1-rafal.hibner@secom.com.pl Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-05-15Revert "ASoC: cros_ec_codec: use crypto_shash_tfm_digest()"Herbert Xu
This reverts commit 85fc78b80f15d723db3aa8f368b414ee70a1937c as a different fix has already been applied in the sound-asoc tree and this patch is no longer required. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: Mark Brown <broonie@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-15Merge tag 'drm-intel-fixes-2020-05-13-1' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Handle idling during i915_gem_evict_something busy loops (Chris) - Mark current submissions with a weak-dependency (Chris) - Propagate errror from completed fences (Chris) - Fixes on execlist to avoid GPU hang situation (Chris) - Fixes couple deadlocks (Chris) - Timeslice preemption fixes (Chris) - Fix Display Port interrupt handling on Tiger Lake (Imre) - Reduce debug noise around Frame Buffer Compression +(Peter) - Fix logic around IPC W/a for Coffee Lake and Kaby Lake +(Sultan) - Avoid dereferencing a dead context (Chris) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200514040235.GA2164266@intel.com
2020-05-14MAINTAINERS: Mark networking drivers as Maintained.David S. Miller
Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14ipmr: Add lockdep expression to ipmr_for_each_table macroAmol Grover
During the initialization process, ipmr_new_table() is called to create new tables which in turn calls ipmr_get_table() which traverses net->ipv4.mr_tables without holding the writer lock. However, this is safe to do so as no tables exist at this time. Hence add a suitable lockdep expression to silence the following false-positive warning: ============================= WARNING: suspicious RCU usage 5.7.0-rc3-next-20200428-syzkaller #0 Not tainted ----------------------------- net/ipv4/ipmr.c:136 RCU-list traversed in non-reader section!! ipmr_get_table+0x130/0x160 net/ipv4/ipmr.c:136 ipmr_new_table net/ipv4/ipmr.c:403 [inline] ipmr_rules_init net/ipv4/ipmr.c:248 [inline] ipmr_net_init+0x133/0x430 net/ipv4/ipmr.c:3089 Fixes: f0ad0860d01e ("ipv4: ipmr: support multiple tables") Reported-by: syzbot+1519f497f2f9f08183c6@syzkaller.appspotmail.com Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Amol Grover <frextrite@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14ipmr: Fix RCU list debugging warningAmol Grover
ipmr_for_each_table() macro uses list_for_each_entry_rcu() for traversing outside of an RCU read side critical section but under the protection of rtnl_mutex. Hence, add the corresponding lockdep expression to silence the following false-positive warning at boot: [ 4.319347] ============================= [ 4.319349] WARNING: suspicious RCU usage [ 4.319351] 5.5.4-stable #17 Tainted: G E [ 4.319352] ----------------------------- [ 4.319354] net/ipv4/ipmr.c:1757 RCU-list traversed in non-reader section!! Fixes: f0ad0860d01e ("ipv4: ipmr: support multiple tables") Signed-off-by: Amol Grover <frextrite@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14drivers: net: hamradio: Fix suspicious RCU usage warning in bpqether.cMadhuparna Bhowmik
This patch fixes the following warning: ============================= WARNING: suspicious RCU usage 5.7.0-rc5-next-20200514-syzkaller #0 Not tainted ----------------------------- drivers/net/hamradio/bpqether.c:149 RCU-list traversed in non-reader section!! Since rtnl lock is held, pass this cond in list_for_each_entry_rcu(). Reported-by: syzbot+bb82cafc737c002d11ca@syzkaller.appspotmail.com Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: phy: broadcom: fix BCM54XX_SHD_SCR3_TRDDAPD value for BCM54810Kevin Lo
Set the correct bit when checking for PHY_BRCM_DIS_TXCRXC_NOENRGY on the BCM54810 PHY. Fixes: 0ececcfc9267 ("net: phy: broadcom: Allow BCM54810 to use bcm54xx_adjust_rxrefclk()") Signed-off-by: Kevin Lo <kevlo@kevlo.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14scsi: target: Put lun_ref at end of tmr processingBodo Stroesser
Testing with Loopback I found that, after a Loopback LUN has executed a TMR, I can no longer unlink the LUN. The rm command hangs in transport_clear_lun_ref() at wait_for_completion(&lun->lun_shutdown_comp) The reason is, that transport_lun_remove_cmd() is not called at the end of target_tmr_work(). It seems, that in other fabrics this call happens implicitly when the fabric drivers call transport_generic_free_cmd() during their ->queue_tm_rsp(). Unfortunately Loopback seems to not comply to the common way of calling transport_generic_free_cmd() from ->queue_*(). Instead it calls transport_generic_free_cmd() from its ->check_stop_free() only. But the ->check_stop_free() is called by transport_cmd_check_stop_to_fabric() after it has reset the se_cmd->se_lun pointer. Therefore the following transport_generic_free_cmd() skips the transport_lun_remove_cmd(). So this patch re-adds the transport_lun_remove_cmd() at the end of target_tmr_work(), which was removed during commit 2c9fa49e100f ("scsi: target/core: Make ABORT and LUN RESET handling synchronous"). For fabrics using transport_generic_free_cmd() in the usual way the double call to transport_lun_remove_cmd() doesn't harm, as transport_lun_remove_cmd() checks for this situation and does not release lun_ref twice. Link: https://lore.kernel.org/r/20200513153443.3554-1-bstroesser@ts.fujitsu.com Fixes: 2c9fa49e100f ("scsi: target/core: Make ABORT and LUN RESET handling synchronous") Cc: stable@vger.kernel.org Tested-by: Bryant G. Ly <bryangly@gmail.com> Reviewed-by: Bart van Assche <bvanassche@acm.org> Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-05-14evm: Fix a small race in init_desc()Dan Carpenter
The IS_ERR_OR_NULL() function has two conditions and if we got really unlucky we could hit a race where "ptr" started as an error pointer and then was set to NULL. Both conditions would be false even though the pointer at the end was NULL. This patch fixes the problem by ensuring that "*tfm" can only be NULL or valid. I have introduced a "tmp_tfm" variable to make that work. I also reversed a condition and pulled the code in one tab. Reported-by: Roberto Sassu <roberto.sassu@huawei.com> Fixes: 53de3b080d5e ("evm: Check also if *tfm is an error pointer in init_desc()") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Roberto Sassu <roberto.sassu@huawei.com> Acked-by: Krzysztof Struczynski <krzysztof.struczynski@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2020-05-14cifs: fix leaked reference on requeued writeAdam McCoy
Failed async writes that are requeued may not clean up a refcount on the file, which can result in a leaked open. This scenario arises very reliably when using persistent handles and a reconnect occurs while writing. cifs_writev_requeue only releases the reference if the write fails (rc != 0). The server->ops->async_writev operation will take its own reference, so the initial reference can always be released. Signed-off-by: Adam McCoy <adam@forsedomani.com> Signed-off-by: Steve French <stfrench@microsoft.com> CC: Stable <stable@vger.kernel.org> Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
2020-05-14NFSv3: fix rpc receive buffer size for MOUNT callOlga Kornievskaia
Prior to commit e3d3ab64dd66 ("SUNRPC: Use au_rslack when computing reply buffer size"), there was enough slack in the reply buffer to commodate filehandles of size 60bytes. However, the real problem was that the reply buffer size for the MOUNT operation was not correctly calculated. Received buffer size used the filehandle size for NFSv2 (32bytes) which is much smaller than the allowed filehandle size for the v3 mounts. Fix the reply buffer size (decode arguments size) for the MNT command. Fixes: 2c94b8eca1a2 ("SUNRPC: Use au_rslack when computing reply buffer size") Signed-off-by: Olga Kornievskaia <kolga@netapp.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2020-05-14tcp: fix error recovery in tcp_zerocopy_receive()Eric Dumazet
If user provides wrong virtual address in TCP_ZEROCOPY_RECEIVE operation we want to return -EINVAL error. But depending on zc->recv_skip_hint content, we might return -EIO error if the socket has SOCK_DONE set. Make sure to return -EINVAL in this case. BUG: KMSAN: uninit-value in tcp_zerocopy_receive net/ipv4/tcp.c:1833 [inline] BUG: KMSAN: uninit-value in do_tcp_getsockopt+0x4494/0x6320 net/ipv4/tcp.c:3685 CPU: 1 PID: 625 Comm: syz-executor.0 Not tainted 5.7.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x220 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 tcp_zerocopy_receive net/ipv4/tcp.c:1833 [inline] do_tcp_getsockopt+0x4494/0x6320 net/ipv4/tcp.c:3685 tcp_getsockopt+0xf8/0x1f0 net/ipv4/tcp.c:3728 sock_common_getsockopt+0x13f/0x180 net/core/sock.c:3131 __sys_getsockopt+0x533/0x7b0 net/socket.c:2177 __do_sys_getsockopt net/socket.c:2192 [inline] __se_sys_getsockopt+0xe1/0x100 net/socket.c:2189 __x64_sys_getsockopt+0x62/0x80 net/socket.c:2189 do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:297 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45c829 Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f1deeb72c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000037 RAX: ffffffffffffffda RBX: 00000000004e01e0 RCX: 000000000045c829 RDX: 0000000000000023 RSI: 0000000000000006 RDI: 0000000000000009 RBP: 000000000078bf00 R08: 0000000020000200 R09: 0000000000000000 R10: 00000000200001c0 R11: 0000000000000246 R12: 00000000ffffffff R13: 00000000000001d8 R14: 00000000004d3038 R15: 00007f1deeb736d4 Local variable ----zc@do_tcp_getsockopt created at: do_tcp_getsockopt+0x1a74/0x6320 net/ipv4/tcp.c:3670 do_tcp_getsockopt+0x1a74/0x6320 net/ipv4/tcp.c:3670 Fixes: 05255b823a61 ("tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14ARC: show_regs: avoid extra line of outputVineet Gupta
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
2020-05-14s390/kexec_file: fix initrd location for kdump kernelPhilipp Rudo
initrd_start must not point at the location the initrd is loaded into the crashkernel memory but at the location it will be after the crashkernel memory is swapped with the memory at 0. Fixes: ee337f5469fd ("s390/kexec_file: Add crash support to image loader") Reported-by: Lianbo Jiang <lijiang@redhat.com> Signed-off-by: Philipp Rudo <prudo@linux.ibm.com> Tested-by: Lianbo Jiang <lijiang@redhat.com> Link: https://lore.kernel.org/r/20200512193956.15ae3f23@laptop2-ibm.local Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2020-05-14s390/pci: Fix s390_mmio_read/write with MIONiklas Schnelle
The s390_mmio_read/write syscalls are currently broken when running with MIO. The new pcistb_mio/pcstg_mio/pcilg_mio instructions are executed similiarly to normal load/store instructions and do address translation in the current address space. That means inside the kernel they are aware of mappings into kernel address space while outside the kernel they use user space mappings (usually created through mmap'ing a PCI device file). Now when existing user space applications use the s390_pci_mmio_write and s390_pci_mmio_read syscalls, they pass I/O addresses that are mapped into user space so as to be usable with the new instructions without needing a syscall. Accessing these addresses with the old instructions as done currently leads to a kernel panic. Also, for such a user space mapping there may not exist an equivalent kernel space mapping which means we can't just use the new instructions in kernel space. Instead of replicating user mappings in the kernel which then might collide with other mappings, we can conceptually execute the new instructions as if executed by the user space application using the secondary address space. This even allows us to directly store to the user pointer without the need for copy_to/from_user(). Cc: stable@vger.kernel.org Fixes: 71ba41c9b1d9 ("s390/pci: provide support for MIO instructions") Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2020-05-14char: ipmi: convert to use i2c_new_client_device()Wolfram Sang
Move away from the deprecated API. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Message-Id: <20200326210958.13051-2-wsa+renesas@sang-engineering.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
generated by cgit (git 2.34.1) at 2025-09-24 12:49:59 +0000