- 25 Feb, 2018 40 commits
-
-
Dave Young authored
[ Upstream commit 7f6f60a1 ] earlyprintk=efi,keep does not work any more with a warning in mm/early_ioremap.c: WARN_ON(system_state != SYSTEM_BOOTING): Boot just hangs because of the earlyprintk within the earlyprintk implementation code itself. This is caused by a new introduced middle state in: 69a78ff2 ("init: Introduce SYSTEM_SCHEDULING state") early_ioremap() is fine in both SYSTEM_BOOTING and SYSTEM_SCHEDULING states, original condition should be updated accordingly. Signed-off-by:
Dave Young <dyoung@redhat.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: bp@suse.de Cc: linux-efi@vger.kernel.org Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20171209041610.GA3249@dhcp-128-65.nay.redhat.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tobias Jordan authored
[ Upstream commit eb943696 ] in error path of jz4740_dma_probe(), call clk_disable_unprepare() to clean up. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 25ce6c35 MIPS: jz4740: Remove custom DMA API Signed-off-by:
Tobias Jordan <Tobias.Jordan@elektrobit.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Russell King authored
[ Upstream commit 33cd3c07 ] Fix the leak of the CRTC structure in the failure paths of armada_drm_crtc_create(). Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Steffen Klassert authored
[ Upstream commit 732706af ] On policies with a transport mode template, we pass the addresses from the flowi to xfrm_state_find(), assuming that the IP addresses (and address family) don't change during transformation. Unfortunately our policy template validation is not strict enough. It is possible to configure policies with transport mode template where the address family of the template does not match the selectors address family. This lead to stack-out-of-bound reads because we compare arddesses of the wrong family. Fix this by refusing such a configuration, address family can not change on transport mode. We use the assumption that, on transport mode, the first templates address family must match the address family of the policy selector. Subsequent transport mode templates must mach the address family of the previous template. Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Takuo Koguchi authored
[ Upstream commit c810daba ] mclk and hclk need to be disabled. Since pm_runtime_disable does not disable the clocks, use pm_runtime_force_suspend instead. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Takuo Koguchi <takuo.koguchi.sw@hitachi.com> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Stefan Potyra authored
[ Upstream commit c7b92172 ] Disable the clocks in rk_spdif_probe when an error occurs after one of the clocks has been enabled previously. Found by Linux Driver Verification project (linuxtesting.org). Fixes: f874b80e ASoC: rockchip: Add rockchip SPDIF transceiver driver Signed-off-by:
Stefan Potyra <Stefan.Potyra@elektrobit.com> Signed-off-by:
-
Cai Li authored
[ Upstream commit 975b820b ] In some cases the clock parent would be set NULL when doing re-parent, it will cause a NULL pointer accessing if clk_set trace event is enabled. This patch sets the parent as "none" if the input parameter is NULL. Fixes: dfc202ea (clk: Add tracepoints for hardware operations) Signed-off-by:
Cai Li <cai.li@spreadtrum.com> Signed-off-by:
Chunyan Zhang <chunyan.zhang@spreadtrum.com> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Gustavo A. R. Silva authored
[ Upstream commit 62a277d4 ] _xt_ is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after _xt_ has been null checked. This issue was detected with the help of Coccinelle. Fixes: 4483320e ("dmaengine: Use Pointer xt after NULL check.") Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Acked-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 5c9afbda ] If the last test in 'ioat_dma_self_test()' fails, we must release all the allocated resources and not just part of them. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by:
Dave Jiang <dave.jiang@intel.com> Signed-off-by:
-
Eric Biggers authored
[ Upstream commit 8dfd2f22 ] Callers of sprint_oid() do not check its return value before printing the result. In the case where the OID is zero-length, -EBADMSG was being returned without anything being written to the buffer, resulting in uninitialized stack memory being printed. Fix this by writing "(bad)" to the buffer in the cases where -EBADMSG is returned. Fixes: 4f73175d ("X.509: Add utility functions to render OIDs as strings") Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Nikolay Borisov authored
[ Upstream commit c8bcbfbd ] The name char array passed to btrfs_search_path_in_tree is of size BTRFS_INO_LOOKUP_PATH_MAX (4080). So the actual accessible char indexes are in the range of [0, 4079]. Currently the code uses the define but this represents an off-by-one. Implications: Size of btrfs_ioctl_ino_lookup_args is 4096, so the new byte will be written to extra space, not some padding that could be provided by the allocator. btrfs-progs store the arguments on stack, but kernel does own copy of the ioctl buffer and the off-by-one overwrite does not affect userspace, but the ending 0 might be lost. Kernel ioctl buffer is allocated dynamically so we're overwriting somebody else's memory, and the ioctl is privileged if args.objectid is not 256. Which is in most cases, but resolving a subvolume stored in another directory will trigger that path. Before this patch the buffer was one byte larger, but then the -1 was not added. Fixes: ac8e9819 ("Btrfs: add search and inode lookup ioctls") Signed-off-by:
Nikolay Borisov <nborisov@suse.com> Reviewed-by:
David Sterba <dsterba@suse.com> [ added implications ] Signed-off-by:
-
Nogah Frankel authored
[ Upstream commit 8afa10cb ] Check the qmin & qmax values doesn't overflow for the given Wlog value. Check that qmin <= qmax. Fixes: a7834745 ("[PKT_SCHED]: Generic RED layer") Signed-off-by:
Nogah Frankel <nogahf@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Nogah Frankel authored
[ Upstream commit 5c472203 ] Do not allow delta value to be zero since it is used as a divisor. Fixes: 8af2a218 ("sch_red: Adaptative RED AQM") Signed-off-by:
-
Zumeng Chen authored
[ Upstream commit 58117672 ] According to LS1021A RM, the value of PAL can be set so that the start of the IP header in the receive data buffer is aligned to a 32-bit boundary. Normally, setting PAL = 2 provides minimal padding to ensure such alignment of the IP header. However every incoming packet's 8-byte time stamp will be inserted into the packet data buffer as padding alignment bytes when hardware time stamping is enabled. So we set the padding 8+2 here to avoid the flooded alignment faults: root@128:~# cat /proc/cpu/alignment User: 0 System: 17539 (inet_gro_receive+0x114/0x2c0) Skipped: 0 Half: 0 Word: 0 DWord: 0 Multi: 17539 User faults: 2 (fixup) Also shown when exception report enablement CPU: 0 PID: 161 Comm: irq/66-eth1_g0_ Not tainted 4.1.21-rt13-WR8.0.0.0_preempt-rt #16 Hardware name: Freescale LS1021A [<8001b420>] (unwind_backtrace) from [<8001476c>] (show_stack+0x20/0x24) [<8001476c>] (show_stack) from [<807cfb48>] (dump_stack+0x94/0xac) [<807cfb48>] (dump_stack) from [<80025d70>] (do_alignment+0x720/0x958) [<80025d70>] (do_alignment) from [<80009224>] (do_DataAbort+0x40/0xbc) [<80009224>] (do_DataAbort) from [<80015398>] (__dabt_svc+0x38/0x60) Exception stack(0x86ad1cc0 to 0x86ad1d08) 1cc0: f9b3e080 86b3d072 2d78d287 00000000 866816c0 86b3d05e 86e785d0 00000000 1ce0: 00000011 0000000e 80840ab0 86ad1d3c 86ad1d08 86ad1d08 806d7fc0 806d806c 1d00: 40070013 ffffffff [<80015398>] (__dabt_svc) from [<806d806c>] (inet_gro_receive+0x114/0x2c0) [<806d806c>] (inet_gro_receive) from [<80660eec>] (dev_gro_receive+0x21c/0x3c0) [<80660eec>] (dev_gro_receive) from [<8066133c>] (napi_gro_receive+0x44/0x17c) [<8066133c>] (napi_gro_receive) from [<804f0538>] (gfar_clean_rx_ring+0x39c/0x7d4) [<804f0538>] (gfar_clean_rx_ring) from [<804f0bf4>] (gfar_poll_rx_sq+0x58/0xe0) [<804f0bf4>] (gfar_poll_rx_sq) from [<80660b10>] (net_rx_action+0x27c/0x43c) [<80660b10>] (net_rx_action) from [<80033638>] (do_current_softirqs+0x1e0/0x3dc) [<80033638>] (do_current_softirqs) from [<800338c4>] (__local_bh_enable+0x90/0xa8) [<800338c4>] (__local_bh_enable) from [<8008025c>] (irq_forced_thread_fn+0x70/0x84) [<8008025c>] (irq_forced_thread_fn) from [<800805e8>] (irq_thread+0x16c/0x244) [<800805e8>] (irq_thread) from [<8004e490>] (kthread+0xe8/0x104) [<8004e490>] (kthread) from [<8000fda8>] (ret_from_fork+0x14/0x2c) Signed-off-by:
Zumeng Chen <zumeng.chen@gmail.com> Signed-off-by:
-
Stefan Haberland authored
[ Upstream commit da340f92 ] Prevent that a prefix flag is set based on invalid configuration data. The validity.verify_base flag should only be set for alias devices. Usually the unit address type is either one of base, PAV alias or HyperPAV alias. But in cases where the unit address type is not set or any other value the validity.verify_base flag might be set as well. This would lead to follow on errors. Explicitly check for alias devices and set the validity flag only for them. Signed-off-by:
Stefan Haberland <sth@linux.vnet.ibm.com> Reviewed-by:
Jan Hoeppner <hoeppner@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Ravi Bangoria authored
[ Upstream commit 5aa04b3e ] When user tries to group imc (In-Memory Collections) event with normal event, (sometime) kernel crashes with following log: Faulting instruction address: 0x00000000 [link register ] c00000000010ce88 power_check_constraints+0x128/0x980 ... c00000000010e238 power_pmu_event_init+0x268/0x6f0 c0000000002dc60c perf_try_init_event+0xdc/0x1a0 c0000000002dce88 perf_event_alloc+0x7b8/0xac0 c0000000002e92e0 SyS_perf_event_open+0x530/0xda0 c00000000000b004 system_call+0x38/0xe0 'event_base' field of 'struct hw_perf_event' is used as flags for normal hw events and used as memory address for imc events. While grouping these two types of events, collect_events() tries to interpret imc 'event_base' as a flag, which causes a corruption resulting in a crash. Consider only those events which belongs to 'perf_hw_context' in collect_events(). Signed-off-by:
Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> Reviewed-By:
Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Gao Feng authored
[ Upstream commit a98a4ebc ] Current codes don't use skb->mark to assign flowi4_mark, it would make the policy route rule with fwmark doesn't work as expected. Signed-off-by:
Gao Feng <gfree.wind@vip.163.com> Signed-off-by:
-
Will Deacon authored
[ Upstream commit e814bccb ] My bisect scripts starting running into build failures when trying to compile 4.15-rc1 with the builds failing with things like: drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union! The line in question is actually just a #define, but after some digging it turns out that my scripts pass W=1 and since commit 3a025e1d ("Add optional check for bad kernel-doc comments") that results in kernel-doc running on each source file. The file in question has a badly formatted comment immediately before the #define: /** * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for * bus layer usage. */ which causes the regex in dump_struct to fail (lack of braces following struct declaration) and kernel-doc returns 1, which causes the build to fail. Fix the issue by always returning 0 from kernel-doc when invoked with -none. It successfully generates no documentation, and prints out any issues. Cc: Matthew Wilcox <mawilcox@microsoft.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Moni Shoua authored
[ Upstream commit 23a9cd2a ] This patch limits the initial value for PSN to 24 bits as spec requires. Signed-off-by:
Moni Shoua <monis@mellanox.com> Signed-off-by:
Mukesh Kacker <mukesh.kacker@oracle.com> Signed-off-by:
Daniel Jurgens <danielj@mellanox.com> Reviewed-by:
Parav Pandit <parav@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Andre Przywara authored
[ Upstream commit 6ad4cc8d ] On the A80 the pins on port B can trigger interrupts, and those are assigned to the second interrupt bank. Having two pins assigned to the same interrupt bank/pin combination does not look healthy (instead more like a copy&paste bug from pins PA14-PA16), so fix the interrupt bank for pins PB14-PB16, which is actually 1. I don't have any A80 board, so could not test this. Fixes: d5e9fb31 ("pinctrl: sunxi: Add A80 pinctrl muxing options") Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Mauro Carvalho Chehab authored
[ Upstream commit 070250a1 ] as warned: drivers/media/i2c/s5k6aa.c:429: warning: No description found for parameter 's5k6aa' drivers/media/i2c/s5k6aa.c:679: warning: No description found for parameter 's5k6aa' drivers/media/i2c/s5k6aa.c:733: warning: No description found for parameter 's5k6aa' drivers/media/i2c/s5k6aa.c:733: warning: No description found for parameter 'preset' drivers/media/i2c/s5k6aa.c:787: warning: No description found for parameter 'sd' Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Satheesh Rajendran authored
[ Upstream commit 321a7c35 ] Certain systems are designed to have sparse/discontiguous nodes. On such systems, 'perf bench numa' hangs, shows wrong number of nodes and shows values for non-existent nodes. Handle this by only taking nodes that are exposed by kernel to userspace. Signed-off-by:
Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Reviewed-by:
Srikar Dronamraju <srikar@linux.vnet.ibm.com> Acked-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/1edbcd353c009e109e93d78f2f46381930c340fe.1511368645.git.sathnaga@linux.vnet.ibm.comSigned-off-by:
Balamuruhan S <bala24@linux.vnet.ibm.com> Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Jiri Olsa authored
[ Upstream commit 89d0aeab ] The stdio perf top crashes when we change the terminal window size. The reason is that we assumed we get the perf_top pointer as a signal handler argument which is not the case. Changing the SIGWINCH handler logic to change global resize variable, which is checked in the main thread loop. Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Tested-by:
-
Peter Ujfalusi authored
[ Upstream commit 627395a6 ] Fixes the following warnings: arch/arm/boot/dts/am437x-cm-t43.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /ocp@44000000/mcasp@48038000 arch/arm/boot/dts/am437x-cm-t43.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /ocp@44000000/mcasp@4803C000 Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit cf87634c ] There's been a reproducable USB OHCI/EHCI cpuidle related hang on omap4 for a while that happens after about 20 - 40 minutes on an idle system with some data feeding device being connected, like a USB GPS device or a cellular modem. This issue happens in cpuidle states C2 and C3 and does not happen if cpuidle is limited to C1 state only. The symptoms are that the whole system hangs and never wakes up from idle, and if a watchdog is configured the system reboots after a while. Turns out that OHCI/EHCI devices on omap4 are trying to use the GIC interrupt controller directly as a parent instead of the WUGEN. We need to pass the interrupts through WUGEN to GIC to provide the wakeup events for the processor. Let's fix the issue by removing the gic interrupt-parent and use the default interrupt-parent wakeupgen instead. Note that omap5.dtsi had this already fixes earlier by commit 7136d457 ("ARM: omap: convert wakeupgen to stacked domains") but we somehow missed omap4 at that point. Fixes: 7136d457 ("ARM: omap: convert wakeupgen to stacked domains") Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Nishanth Menon <nm@ti.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Reviewed-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
-
Keerthy authored
[ Upstream commit b6d6af72 ] Referring TRM Am335X series: http://www.ti.com/lit/ug/spruh73p/spruh73p.pdf The LastPowerStateEntered bitfield is present only for PM_CEFUSE domain. This is not present in any of the other power domains. Hence remove the generic am33xx_pwrdm_read_prev_pwrst hook which wrongly reads the reserved bit fields for all the other power domains. Reading the reserved bits leads to wrongly interpreting the low power transitions for various power domains that do not have the LastPowerStateEntered field. The pm debug counters values are wrong currently as we are incrementing them based on the reserved bits. Signed-off-by:
Keerthy <j-keerthy@ti.com> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit d09220a8 ] With the CMA changes from Joonsoo Kim <iamjoonsoo.kim@lge.com>, it was noticed that n900 stopped booting. After investigating it turned out that n900 save_secure_ram_context does some whacky virtual to physical address translation for the SRAM data address. As we now only have minimal parts of omap3 idle code copied to SRAM, running save_secure_ram_context() in SRAM is not needed. It only gets called on PM init. And it seems there's no need to ever call this from SRAM idle code. So let's just keep save_secure_ram_context() in DDR, and pass it the physical address of the parameters. We can do everything else in omap-secure.c like we already do for other secure code. And since we don't have any documentation, I still have no clue what the values for 0, 1 and 1 for the parameters might be. If somebody has figured it out, please do send a patch to add some comments. Debugged-by:
Joonsoo Kim <iamjoonsoo.kim@lge.com> Signed-off-by:
-
Randy Dunlap authored
[ Upstream commit c9d24f78 ] PHY drivers can use ULPI interfaces when CONFIG_USB (which is host side support) is not enabled, so also build drivers/usb/ when CONFIG_USB_SUPPORT is enabled so that drivers/usb/common/ is built. ERROR: "ulpi_unregister_driver" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "__ulpi_register_driver" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_read" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_write" [drivers/phy/ti/phy-tusb1210.ko] undefined! ERROR: "ulpi_unregister_driver" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! ERROR: "__ulpi_register_driver" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! ERROR: "ulpi_write" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined! Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Shuah Khan authored
commit 009f41ae upstream. Keep usbip_device sockfd state in sync with tcp_socket. When tcp_socket is reset to null, reset sockfd to -1 to keep it in sync. Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Alexandru Ardelean authored
commit e31b617d upstream. The external clock frequency was set only when selecting the internal clock, which is fixed at 4.9152 Mhz. This is incorrect, since it should be set when any of the external clock or crystal settings is selected. Added range validation for the external (crystal/clock) frequency setting. Valid values are between 2.4576 and 5.12 Mhz. Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Eric Biggers authored
commit f8898267 upstream. If the kzalloc() in binder_get_thread() fails, binder_poll() dereferences the resulting NULL pointer. Fix it by returning POLLERR if the memory allocation failed. This bug was found by syzkaller using fault injection. Reported-by:
syzbot <syzkaller@googlegroups.com> Fixes: 457b9a6f ("Staging: android: add binder driver") Cc: stable@vger.kernel.org Signed-off-by:
-
Ben Hutchings authored
commit ce8a3a9e upstream. ashmem_pin_unpin() reads asma->file and asma->size before taking the ashmem_mutex, so it can race with other operations that modify them. Build-tested only. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Paolo Abeni authored
commit dfec0914 upstream. After commit 3f34cfae ("netfilter: on sockopt() acquire sock lock only in the required scope"), the caller of nf_{get/set}sockopt() must not hold any lock, but, in such changeset, I forgot to cope with DECnet. This commit addresses the issue moving the nf call outside the lock, in the dn_{get,set}sockopt() with the same schema currently used by ipv4 and ipv6. Also moves the unhandled sockopts of the end of the main switch statements, to improve code readability. Reported-by:
Petr Vandrovec <petr@vandrovec.name> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198791#c2 Fixes: 3f34cfae ("netfilter: on sockopt() acquire sock lock only in the required scope") Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Dave Jones authored
commit 9b246841 upstream. commit 911362c7 ("net: add dst_cache support") added a new kconfig option that gets selected by other networking options. It seems the intent wasn't to offer this as a user-selectable option given the lack of help text, so this patch converts it to a silent option. Signed-off-by:
Dave Jones <davej@codemonkey.org.uk> Signed-off-by:
-
Arnd Bergmann authored
commit acbf76ee upstream. dtc complains about the lack of #coolin-cells properties for the CPU nodes that are referred to as "cooling-device": arch/arm64/boot/dts/mediatek/mt8173-evb.dtb: Warning (cooling_device_property): Missing property '#cooling-cells' in node /cpus/cpu@0 or bad phandle (referred from /thermal-zones/cpu_thermal/cooling-maps/map@0:cooling-device[0]) arch/arm64/boot/dts/mediatek/mt8173-evb.dtb: Warning (cooling_device_property): Missing property '#cooling-cells' in node /cpus/cpu@100 or bad phandle (referred from /thermal-zones/cpu_thermal/cooling-maps/map@1:cooling-device[0]) Apparently this property must be '<2>' to match the binding. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Tested-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by:
Olof Johansson <olof@lixom.net> [arnd: backported to 4.15] Signed-off-by:
-
Arnd Bergmann authored
commit c1530ac5 upstream. Kbuild complains about the lack of a license tag in this driver: WARNING: modpost: missing MODULE_LICENSE() in drivers/video/fbdev/mmp/mmp_disp.o This adds the license, author and description tags. Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Arnd Bergmann authored
commit 1783c9d7 upstream. This adds MODULE_LICENSE/AUTHOR/DESCRIPTION tags to the ux500 platform drivers, to avoid these build warnings: WARNING: modpost: missing MODULE_LICENSE() in sound/soc/ux500/snd-soc-ux500-plat-dma.o WARNING: modpost: missing MODULE_LICENSE() in sound/soc/ux500/snd-soc-ux500-mach-mop500.o The company no longer exists, so the email addresses of the authors don't work any more, but I've added them anyway for consistency. Signed-off-by:
-
Willem de Bruijn authored
commit 8d74e9f8 upstream. skb_warn_bad_offload warns when packets enter the GSO stack that require skb_checksum_help or vice versa. Do not warn on arbitrary bad packets. Packet sockets can craft many. Syzkaller was able to demonstrate another one with eth_type games. In particular, suppress the warning when segmentation returns an error, which is for reasons other than checksum offload. See also commit 36c92474 ("net: WARN if skb_checksum_help() is called on skb requiring segmentation") for context on this warning. Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Cong Wang authored
commit 7dc68e98 upstream. rateest_hash is supposed to be protected by xt_rateest_mutex, and, as suggested by Eric, lookup and insert should be atomic, so we should acquire the xt_rateest_mutex once for both. So introduce a non-locking helper for internal use and keep the locking one for external. Reported-by: <syzbot+5cb189720978275e4c75@syzkaller.appspotmail.com> Fixes: 5859034d ("[NETFILTER]: x_tables: add RATEEST target") Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Reviewed-by:
Florian Westphal <fw@strlen.de> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Paolo Abeni authored
commit 3f34cfae upstream. Syzbot reported several deadlocks in the netfilter area caused by rtnl lock and socket lock being acquired with a different order on different code paths, leading to backtraces like the following one: ====================================================== WARNING: possible circular locking dependency detected 4.15.0-rc9+ #212 Not tainted ------------------------------------------------------ syzkaller041579/3682 is trying to acquire lock: (sk_lock-AF_INET6){+.+.}, at: [<000000008775e4dd>] lock_sock include/net/sock.h:1463 [inline] (sk_lock-AF_INET6){+.+.}, at: [<000000008775e4dd>] do_ipv6_setsockopt.isra.8+0x3c5/0x39d0 net/ipv6/ipv6_sockglue.c:167 but task is already holding lock: (rtnl_mutex){+.+.}, at: [<000000004342eaa9>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (rtnl_mutex){+.+.}: __mutex_lock_common kernel/locking/mutex.c:756 [inline] __mutex_lock+0x16f/0x1a80 kernel/locking/mutex.c:893 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908 rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 register_netdevice_notifier+0xad/0x860 net/core/dev.c:1607 tee_tg_check+0x1a0/0x280 net/netfilter/xt_TEE.c:106 xt_check_target+0x22c/0x7d0 net/netfilter/x_tables.c:845 check_target net/ipv6/netfilter/ip6_tables.c:538 [inline] find_check_entry.isra.7+0x935/0xcf0 net/ipv6/netfilter/ip6_tables.c:580 translate_table+0xf52/0x1690 net/ipv6/netfilter/ip6_tables.c:749 do_replace net/ipv6/netfilter/ip6_tables.c:1165 [inline] do_ip6t_set_ctl+0x370/0x5f0 net/ipv6/netfilter/ip6_tables.c:1691 nf_sockopt net/netfilter/nf_sockopt.c:106 [inline] nf_setsockopt+0x67/0xc0 net/netfilter/nf_sockopt.c:115 ipv6_setsockopt+0x115/0x150 net/ipv6/ipv6_sockglue.c:928 udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1422 sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2978 SYSC_setsockopt net/socket.c:1849 [inline] SyS_setsockopt+0x189/0x360 net/socket.c:1828 entry_SYSCALL_64_fastpath+0x29/0xa0 -> #0 (sk_lock-AF_INET6){+.+.}: lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3914 lock_sock_nested+0xc2/0x110 net/core/sock.c:2780 lock_sock include/net/sock.h:1463 [inline] do_ipv6_setsockopt.isra.8+0x3c5/0x39d0 net/ipv6/ipv6_sockglue.c:167 ipv6_setsockopt+0xd7/0x150 net/ipv6/ipv6_sockglue.c:922 udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1422 sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2978 SYSC_setsockopt net/socket.c:1849 [inline] SyS_setsockopt+0x189/0x360 net/socket.c:1828 entry_SYSCALL_64_fastpath+0x29/0xa0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(rtnl_mutex); lock(sk_lock-AF_INET6); lock(rtnl_mutex); lock(sk_lock-AF_INET6); *** DEADLOCK *** 1 lock held by syzkaller041579/3682: #0: (rtnl_mutex){+.+.}, at: [<000000004342eaa9>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 The problem, as Florian noted, is that nf_setsockopt() is always called with the socket held, even if the lock itself is required only for very tight scopes and only for some operation. This patch addresses the issues moving the lock_sock() call only where really needed, namely in ipv*_getorigdst(), so that nf_setsockopt() does not need anymore to acquire both locks. Fixes: 22265a5c ("netfilter: xt_TEE: resolve oif using netdevice notifiers") Reported-by: syzbot+a4c2dc980ac1af699b36@syzkaller.appspotmail.com Suggested-by:
-
