- 22 Mar, 2018 27 commits
-
-
Tom Hromatka authored
[ Upstream commit 01070427 ] On systems with a large number of CPUs, running sysrq-<q> can cause watchdog timeouts. There are two slow sections of code in the sysrq-<q> path in timer_list.c. 1. print_active_timers() - This function is called by print_cpu() and contains a slow goto loop. On a machine with hundreds of CPUs, this loop took approximately 100ms for the first CPU in a NUMA node. (Subsequent CPUs in the same node ran much quicker.) The total time to print all of the CPUs is ultimately long enough to trigger the soft lockup watchdog. 2. print_tickdevice() - This function outputs a large amount of textual information. This function also took approximately 100ms per CPU. Since sysrq-<q> is not a performance critical path, there should be no harm in touching the nmi watchdog in both slow sections above. Touching it in just one location was insufficient on systems with hundreds of CPUs as occasional timeouts were still observed during testing. This issue was observed on an Oracle T7 machine with 128 CPUs, but I anticipate it may affect other systems with similarly large numbers of CPUs. Signed-off-by:
Tom Hromatka <tom.hromatka@oracle.com> Reviewed-by:
Rob Gardner <rob.gardner@oracle.com> Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
David Engraf authored
[ Upstream commit 1b8955bc ] The scheduler clock framework may not use the correct timeout for the clock wrap. This happens when a new clock driver calls sched_clock_register() after the kernel called sched_clock_postinit(). In this case the clock wrap timeout is too long thus sched_clock_poll() is called too late and the clock already wrapped. On my ARM system the scheduler was no longer scheduling any other task than the idle task because the sched_clock() wrapped. Signed-off-by:
David Engraf <david.engraf@sysgo.com> Signed-off-by:
-
Janusz Krzysztofik authored
[ Upstream commit 54449af0 ] After changes to v4l2_clk API introduced in v4.1 by commits a37462b9 '[media] V4L: remove clock name from v4l2_clk API' and 4f528afc '[media] V4L: add CCF support to the v4l2_clk API', ov6650 sensor stopped responding because v4l2_clk_get(), still called with depreciated V4L2 clock name "mclk", started to return respective CCF clock instead of the V4l2 one registered by soc_camera. Fix it by calling v4l2_clk_get() with NULL clock name. Created and tested on Amstrad Delta against Linux-4.7-rc3 with omap1_camera fixes. Signed-off-by:
Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Brian King authored
[ Upstream commit 66a0d59c ] Following a command abort or device reset, ipr's EH handlers wait for the commands getting aborted to get sent back from the adapter prior to returning from the EH handler. This fixes up some cases where the completion handler was not getting called, which would have resulted in the EH thread waiting until it timed out, greatly extending EH time. Signed-off-by:
Brian King <brking@linux.vnet.ibm.com> Reviewed-by:
Wendy Xiong <wenxiong@linux.vnet.ibm.com> Tested-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Anton Sviridenko authored
[ Upstream commit 6e4c8480 ] Fixes warning that appears in dmesg after closing V4L2 userspace application that plays video from the display device (first device from V4L2 device nodes provided by solo, usually /dev/video0 when no other V4L2 devices are present). Encoder device nodes are not affected. Can be reproduced by starting and closing ffplay -f video4linux2 /dev/video0 [ 8130.281251] ------------[ cut here ]------------ [ 8130.281256] WARNING: CPU: 1 PID: 20414 at drivers/media/v4l2-core/videobuf2-core.c:1651 __vb2_queue_cancel+0x14b/0x230 [ 8130.281257] Modules linked in: ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat solo6x10 x86_pkg_temp_thermal vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) [ 8130.281264] CPU: 1 PID: 20414 Comm: ffplay Tainted: G O 4.10.0-gentoo #1 [ 8130.281264] Hardware name: ASUS All Series/B85M-E, BIOS 2301 03/30/2015 [ 8130.281265] Call Trace: [ 8130.281267] dump_stack+0x4f/0x72 [ 8130.281270] __warn+0xc7/0xf0 [ 8130.281271] warn_slowpath_null+0x18/0x20 [ 8130.281272] __vb2_queue_cancel+0x14b/0x230 [ 8130.281273] vb2_core_streamoff+0x23/0x90 [ 8130.281275] vb2_streamoff+0x24/0x50 [ 8130.281276] vb2_ioctl_streamoff+0x3d/0x50 [ 8130.281278] v4l_streamoff+0x15/0x20 [ 8130.281279] __video_do_ioctl+0x25e/0x2f0 [ 8130.281280] video_usercopy+0x279/0x520 [ 8130.281282] ? v4l_enum_fmt+0x1330/0x1330 [ 8130.281285] ? unmap_region+0xdf/0x110 [ 8130.281285] video_ioctl2+0x10/0x20 [ 8130.281286] v4l2_ioctl+0xce/0xe0 [ 8130.281289] do_vfs_ioctl+0x8b/0x5b0 [ 8130.281290] ? __fget+0x72/0xa0 [ 8130.281291] SyS_ioctl+0x74/0x80 [ 8130.281294] entry_SYSCALL_64_fastpath+0x13/0x94 [ 8130.281295] RIP: 0033:0x7ff86fee6b27 [ 8130.281296] RSP: 002b:00007ffe467f6a08 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 8130.281297] RAX: ffffffffffffffda RBX: 00000000d1a4d788 RCX: 00007ff86fee6b27 [ 8130.281297] RDX: 00007ffe467f6a14 RSI: 0000000040045613 RDI: 0000000000000006 [ 8130.281298] RBP: 000000000373f8d0 R08: 00000000ffffffff R09: 00007ff860001140 [ 8130.281298] R10: 0000000000000243 R11: 0000000000000246 R12: 0000000000000000 [ 8130.281299] R13: 00000000000000a0 R14: 00007ffe467f6530 R15: 0000000001f32228 [ 8130.281300] ---[ end trace 00695dc96be646e7 ]--- Signed-off-by:
Anton Sviridenko <anton@corp.bluecherry.net> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Rob Herring authored
[ Upstream commit bcf54d53 ] If the length of the modalias is greater than the buffer size, then the modalias is truncated. However the untruncated length is returned which will cause an error. Fix this to return the truncated length. If an error in the case was desired, then then we should just return -ENOMEM. The reality is no device will ever have 4KB of compatible strings to hit this case. Signed-off-by:
Rob Herring <robh@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Signed-off-by:
-
Andreas Pape authored
[ Upstream commit a3a5129e ] Consider the following situation which has been found in a test setup: Gateway B has claimed client C and gateway A has the same backbone network as B. C sends a broad- or multicast to B and directly after this packet decides to send another packet to A due to a better TQ value. B will forward the broad-/multicast into the backbone as it is the responsible gw and after that A will claim C as it has been chosen by C as the best gateway. If it now happens that A claims C before it has received the broad-/multicast forwarded by B (due to backbone topology or due to some delay in B when forwarding the packet) we get a critical situation: in the current code A will immediately unclaim C when receiving the multicast due to the roaming client scenario although the position of C has not changed in the mesh. If this happens the multi-/broadcast forwarded by B will be sent back into the mesh by A and we have looping packets until one of the gateways claims C again. In order to prevent this, unclaiming of a client due to the roaming client scenario is only done after a certain time is expired after the last claim of the client. 100 ms are used here, which should be slow enough for big backbones and slow gateways but fast enough not to break the roaming client use case. Acked-by:
Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by:
Andreas Pape <apape@phoenixcontact.com> [sven@narfation.org: fix conflicts with current version] Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
-
Linus Walleij authored
[ Upstream commit c2a736b6 ] The moxart interrupt line flags were not respected in previous driver: instead of assigning them per-consumer, a fixes mask was set in the controller. With the migration to a standard Faraday driver we need to set up and handle the consumer flags correctly. Also remove the Moxart-specific flags when switching to using real consumer flags. Extend the register window to 0x100 bytes as we may have a few more registers in there and it doesn't hurt. Tested-by:
Jonas Jensen <jonas.jensen@gmail.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Andrey Vagin authored
[ Upstream commit 88997e42 ] wanted_features is a set of features which have to be enabled if a hardware allows that. Currently when a vlan device is created, its wanted_features is set to current features of its base device. The problem is that the base device can get new features and they are not propagated to vlan-s of this device. If we look at bonding devices, they doesn't have this problem and this patch suggests to fix this issue by the same way how it works for bonding devices. We meet this problem, when we try to create a vlan device over a bonding device. When a system are booting, real devices require time to be initialized, so bonding devices created without slaves, then vlan devices are created and only then ethernet devices are added to the bonding device. As a result we have vlan devices with disabled scatter-gather. * create a bonding device $ ip link add bond0 type bond $ ethtool -k bond0 | grep scatter scatter-gather: off tx-scatter-gather: off [requested on] tx-scatter-gather-fraglist: off [requested on] * create a vlan device $ ip link add link bond0 name bond0.10 type vlan id 10 $ ethtool -k bond0.10 | grep scatter scatter-gather: off tx-scatter-gather: off tx-scatter-gather-fraglist: off * Add a slave device to bond0 $ ip link set dev eth0 master bond0 And now we can see that the bond0 device has got the scatter-gather feature, but the bond0.10 hasn't got it. [root@laptop linux-task-diag]# ethtool -k bond0 | grep scatter scatter-gather: on tx-scatter-gather: on tx-scatter-gather-fraglist: on [root@laptop linux-task-diag]# ethtool -k bond0.10 | grep scatter scatter-gather: off tx-scatter-gather: off tx-scatter-gather-fraglist: off With this patch the vlan device will get all new features from the bonding device. Here is a call trace how features which are set in this patch reach dev->wanted_features. register_netdevice vlan_dev_init ... dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_GSO_SOFTWARE | NETIF_F_HIGHDMA | NETIF_F_SCTP_CRC | NETIF_F_ALL_FCOE; dev->features |= dev->hw_features; ... dev->wanted_features = dev->features & dev->hw_features; __netdev_update_features(dev); vlan_dev_fix_features ... Cc: Alexey Kuznetsov <kuznet@virtuozzo.com> Cc: Patrick McHardy <kaber@trash.net> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
Andrei Vagin <avagin@openvz.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Tomasz Kramkowski authored
[ Upstream commit c3883fe0 ] This patch fixes an issue in drivers/hid/hid-input.c where values outside of the logical range are not clamped when "null state" bit of the input control is not set. This was discussed on the lists [1] and this change stems from the fact due to the ambiguity of the HID specification it might be appropriate to follow Microsoft's own interpretation of the specification. As noted in Microsoft's documentation [2] in the section titled "Required HID usages for digitizers" it is noted that values reported outside the logical range "will be considered as invalid data and the value will be changed to the nearest boundary value (logical min/max)." This patch fixes an issue where the (1292:4745) Innomedia INNEX GENESIS/ATARI reports out of range values for its X and Y axis of the DPad which, due to the null state bit being unset, are forwarded to userspace as is. Now these values will get clamped to the logical range before being forwarded to userspace. This device was also used to test this patch. This patch expands on commit 3f375270 ("HID: reject input outside logical range only if null state is set"). [1]: http://lkml.kernel.org/r/20170307131036.GA853@gaia.local [2]: https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85).aspSigned-off-by:
Tomasz Kramkowski <tk@the-tk.com> Acked-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Kefeng Wang authored
[ Upstream commit 70946723 ] On old perf, when using 'perf probe -d' to delete an inexistent event, it returns errno, eg, -bash-4.3# perf probe -d xxx || echo $? Info: Event "*:xxx" does not exist. Error: Failed to delete events. 255 But now perf_del_probe_events() will always set ret = 0, different from previous del_perf_probe_events(). After this, it returns errno again, eg, -bash-4.3# ./perf probe -d xxx || echo $? "xxx" does not hit any event. Error: Failed to delete events. 254 And it is more appropriate to return -ENOENT instead of -EPERM. Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Acked-by:
Masami Hiramatsu <mhiramat@kernel.org> Cc: Hanjun Guo <guohanjun@huawei.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Wang Nan <wangnan0@huawei.com> Fixes: dddc7ee3 ("perf probe: Fix an error when deleting probes successfully") Link: http://lkml.kernel.org/r/1489738592-61011-1-git-send-email-wangkefeng.wang@huawei.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Mohammed Shafi Shajakhan authored
[ Upstream commit ca07baab ] If DFS is not enabled in hostapd (ieee80211h=0) DFS channels shall not be available for use even though the hardware may have the capability to support DFS. With this configuration (DFS disabled in hostapd) trying to bring up ath10k device in DFS channel for AP mode fails and trying to simulate DFS in ath10k debugfs results in a warning in cfg80211 complaining invalid channel and this should be avoided in the driver itself rather than false propogating RADAR detection to mac80211/cfg80211. Fix this by checking for the first vif 'is_started' state(should work for client mode as well) as all the vifs shall be configured for the same channel sys/kernel/debug/ieee80211/phy1/ath10k# echo 1 > dfs_simulate_radar WARNING: at net/wireless/chan.c:265 cfg80211_radar_event+0x24/0x60 Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211] [<c022f2d4>] (warn_slowpath_null) from [<bf72dab8>] (cfg80211_radar_event+0x24/0x60 [cfg80211]) [<bf72dab8>] (cfg80211_radar_event [cfg80211]) from [<bf7813e0>] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211]) [<bf7813e0>] (ieee80211_dfs_radar_detected_work [mac80211]) from [<c0242320>] (process_one_work+0x20c/0x32c) WARNING: at net/wireless/nl80211.c:2488 nl80211_get_mpath+0x13c/0x4cc Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211] [<c022f2d4>] (warn_slowpath_null) from [<bf72dab8>] (cfg80211_radar_event+0x24/0x60 [cfg80211]) [<bf72dab8>] (cfg80211_radar_event [cfg80211]) from [<bf7813e0>] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211]) [<bf7813e0>] (ieee80211_dfs_radar_detected_work [mac80211]) from [<c0242320>] (process_one_work+0x20c/0x32c) Signed-off-by:
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Chris Wilson authored
[ Upstream commit 608b2050 ] On vblank instant-off systems, we can get into a situation where the cost of enabling and disabling the vblank IRQ around a drmWaitVblank query dominates. And with the advent of even deeper hardware sleep state, touching registers becomes ever more expensive. However, we know that if the user wants the current vblank counter, they are also very likely to immediately queue a vblank wait and so we can keep the interrupt around and only turn it off if we have no further vblank requests queued within the interrupt interval. After vblank event delivery, this patch adds a shadow of one vblank where the interrupt is kept alive for the user to query and queue another vblank event. Similarly, if the user is using blocking drmWaitVblanks, the interrupt will be disabled on the IRQ following the wait completion. However, if the user is simply querying the current vblank counter and timestamp, the interrupt will be disabled after every IRQ and the user will enabled it again on the first query following the IRQ. v2: Mario Kleiner - After testing this, one more thing that would make sense is to move the disable block at the end of drm_handle_vblank() instead of at the top. Turns out that if high precision timestaming is disabled or doesn't work for some reason (as can be simulated by echo 0 > /sys/module/drm/parameters/timestamp_precision_usec), then with your delayed disable code at its current place, the vblank counter won't increment anymore at all for instant queries, ie. with your other "instant query" patches. Clients which repeatedly query the counter and wait for it to progress will simply hang, spinning in an endless query loop. There's that comment in vblank_disable_and_save: "* Skip this step if there isn't any high precision timestamp * available. In that case we can't account for this and just * hope for the best. */ With the disable happening after leading edge of vblank (== hw counter increment already happened) but before the vblank counter/timestamp handling in drm_handle_vblank, that step is needed to keep the counter progressing, so skipping it is bad. Now without high precision timestamping support, a kms driver must not set dev->vblank_disable_immediate = true, as this would cause problems for clients, so this shouldn't matter, but it would be good to still make this robust against a future kms driver which might have unreliable high precision timestamping, e.g., high precision timestamping that intermittently doesn't work. v3: Patch before coffee needs extra coffee. Testcase: igt/kms_vblank Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Michel Dänzer <michel@daenzer.net> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Dave Airlie <airlied@redhat.com>, Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-1-chris@chris-wilson.co.ukSigned-off-by:
-
Quan Nguyen authored
[ Upstream commit e026e700 ] This patch fixes the hardware checksum settings by properly program the classifier. Otherwise, packet may be received with checksum error on X-Gene1 SoC. Signed-off-by:
Quan Nguyen <qnguyen@apm.com> Signed-off-by:
Iyappan Subramanian <isubramanian@apm.com> Signed-off-by:
-
Stephane Eranian authored
[ Upstream commit 88b897a3 ] This patch significantly improves the execution time of perf_event__synthesize_mmap_events() when running perf record on systems where processes have lots of threads. It just happens that cat /proc/pid/maps support uses a O(N^2) algorithm to generate each map line in the maps file. If you have 1000 threads, then you have necessarily 1000 stacks. For each vma, you need to check if it corresponds to a thread's stack. With a large number of threads, this can take a very long time. I have seen latencies >> 10mn. As of today, perf does not use the fact that a mapping is a stack, therefore we can work around the issue by using /proc/pid/tasks/pid/maps. This entry does not try to map a vma to stack and is thus much faster with no loss of functonality. The proc-map-timeout logic is kept in case users still want some upper limit. In V2, we fix the file path from /proc/pid/tasks/pid/maps to actual /proc/pid/task/pid/maps, tasks -> task. Thanks Arnaldo for catching this. Committer note: This problem seems to have been elliminated in the kernel since commit : b18cb64e ("fs/proc: Stop trying to report thread stacks"). Signed-off-by:
Stephane Eranian <eranian@google.com> Acked-by:
Jiri Olsa <jolsa@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20170315135059.GC2177@redhat.com Link: http://lkml.kernel.org/r/1489598233-25586-1-git-send-email-eranian@google.comSigned-off-by:
-
Lihong Yang authored
[ Upstream commit c271dd6c ] Currently ethtool -e will error out with a X722 interface as its EEPROM has a scope limit at offset 0x5B9FFF. This patch fixes the issue by setting the EEPROM length to the scope limit to avoid NVM read failure beyond that. Change-ID: I0b7d4dd6c7f2a57cace438af5dffa0f44c229372 Signed-off-by:
Lihong Yang <lihong.yang@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Aaron Salter authored
[ Upstream commit 96a39aed ] Acquire NVM lock before reads on all devices. Previously, locks were only used for X722 and later. Fixes an issue where simultaneous X710 NVM accesses were interfering with each other. Change-ID: If570bb7acf958cef58725ec2a2011cead6f80638 Signed-off-by:
Aaron Salter <aaron.k.salter@intel.com> Tested-by:
-
Changbin Du authored
[ Upstream commit 4b0b3aa6 ] Skip the sample which doesn't have branch_info to avoid segmentation fault: The fault can be reproduced by: perf record -a perf report -F cycles Signed-off-by:
Changbin Du <changbin.du@intel.com> Tested-by:
-
Alexander Potapenko authored
[ Upstream commit e2f586bd ] KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of uninitialized memory in selinux_socket_bind(): ================================================================== BUG: KMSAN: use of unitialized memory inter: 0 CPU: 3 PID: 1074 Comm: packet2 Tainted: G B 4.8.0-rc6+ #1916 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 0000000000000000 ffff8800882ffb08 ffffffff825759c8 ffff8800882ffa48 ffffffff818bf551 ffffffff85bab870 0000000000000092 ffffffff85bab550 0000000000000000 0000000000000092 00000000bb0009bb 0000000000000002 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff825759c8>] dump_stack+0x238/0x290 lib/dump_stack.c:51 [<ffffffff818bdee6>] kmsan_report+0x276/0x2e0 mm/kmsan/kmsan.c:1008 [<ffffffff818bf0fb>] __msan_warning+0x5b/0xb0 mm/kmsan/kmsan_instr.c:424 [<ffffffff822dae71>] selinux_socket_bind+0xf41/0x1080 security/selinux/hooks.c:4288 [<ffffffff8229357c>] security_socket_bind+0x1ec/0x240 security/security.c:1240 [<ffffffff84265d98>] SYSC_bind+0x358/0x5f0 net/socket.c:1366 [<ffffffff84265a22>] SyS_bind+0x82/0xa0 net/socket.c:1356 [<ffffffff81005678>] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292 [<ffffffff8518217c>] entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.o:? chained origin: 00000000ba6009bb [<ffffffff810bb7a7>] save_stack_trace+0x27/0x50 arch/x86/kernel/stacktrace.c:67 [< inline >] kmsan_save_stack_with_flags mm/kmsan/kmsan.c:322 [< inline >] kmsan_save_stack mm/kmsan/kmsan.c:337 [<ffffffff818bd2b8>] kmsan_internal_chain_origin+0x118/0x1e0 mm/kmsan/kmsan.c:530 [<ffffffff818bf033>] __msan_set_alloca_origin4+0xc3/0x130 mm/kmsan/kmsan_instr.c:380 [<ffffffff84265b69>] SYSC_bind+0x129/0x5f0 net/socket.c:1356 [<ffffffff84265a22>] SyS_bind+0x82/0xa0 net/socket.c:1356 [<ffffffff81005678>] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292 [<ffffffff8518217c>] return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.o:? origin description: ----address@SYSC_bind (origin=00000000b8c00900) ================================================================== (the line numbers are relative to 4.8-rc6, but the bug persists upstream) , when I run the following program as root: ======================================================= #include <string.h> #include <sys/socket.h> #include <netinet/in.h> int main(int argc, char *argv[]) { struct sockaddr addr; int size = 0; if (argc > 1) { size = atoi(argv[1]); } memset(&addr, 0, sizeof(addr)); int fd = socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP); bind(fd, &addr, size); return 0; } ======================================================= (for different values of |size| other error reports are printed). This happens because bind() unconditionally copies |size| bytes of |addr| to the kernel, leaving the rest uninitialized. Then security_socket_bind() reads the IP address bytes, including the uninitialized ones, to determine the port, or e.g. pass them further to sel_netnode_find(), which uses them to calculate a hash. Signed-off-by:
Alexander Potapenko <glider@google.com> Acked-by:
Eric Dumazet <edumazet@google.com> [PM: fixed some whitespace damage] Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Prarit Bhargava authored
[ Upstream commit fda78d7a ] The pci_bus_type .shutdown method, pci_device_shutdown(), is called from device_shutdown() in the kernel restart and shutdown paths. Previously, pci_device_shutdown() called pci_msi_shutdown() and pci_msix_shutdown(). This disables MSI and MSI-X, which causes the device to fall back to raising interrupts via INTx. But the driver is still bound to the device, it doesn't know about this change, and it likely doesn't have an INTx handler, so these INTx interrupts cause "nobody cared" warnings like this: irq 16: nobody cared (try booting with the "irqpoll" option) CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.2-1.el7_UNSUPPORTED.x86_64 #1 Hardware name: Hewlett-Packard HP Z820 Workstation/158B, BIOS J63 v03.90 06/ ... The MSI disabling code was added by d52877c7 ("pci/irq: let pci_device_shutdown to call pci_msi_shutdown v2") because a driver left MSI enabled and kdump failed because the kexeced kernel wasn't prepared to receive the MSI interrupts. Subsequent commits 1851617c ("PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI") and e80e7edc ("PCI/MSI: Initialize MSI capability for all architectures") changed the kexeced kernel to disable all MSIs itself so it no longer depends on the crashed kernel to clean up after itself. Stop disabling MSI/MSI-X in pci_device_shutdown(). This resolves the "nobody cared" unhandled IRQ issue above. It also allows PCI serial devices, which may rely on the MSI interrupts, to continue outputting messages during reboot/shutdown. [bhelgaas: changelog, drop pci_msi_shutdown() and pci_msix_shutdown() calls altogether] Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=187351Signed-off-by:
Prarit Bhargava <prarit@redhat.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: Alex Williamson <alex.williamson@redhat.com> CC: David Arcari <darcari@redhat.com> CC: Myron Stowe <mstowe@redhat.com> CC: Lukas Wunner <lukas@wunner.de> CC: Keith Busch <keith.busch@intel.com> CC: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Mohammed Shafi Shajakhan authored
[ Upstream commit c73f8c00 ] Doing a channel switch via hostapd_cli seems to update the new channel context for each VAP's appropriately as below in 'ath10k_mac_update_vif_chan', hence we can safely suppress the warning that shows up during this operation and dump the warning only if no vaps are available for channel switch hostapd_cli -i wlan0 chan_switch 5 5200 OK ath10k_pci : mac chanctx switch n_vifs 3 mode 1 ath10k_pci : mac chanctx switch vdev_id 2 freq 5180->5200 width 0->0 ath10k_pci : mac chanctx switch vdev_id 1 freq 5180->5200 width 0->0 ath10k_pci : mac chanctx switch vdev_id 0 freq 5180->5200 width 0->0 Call Trace: WARNING: backports-20161201-3.14.77-9ab3068/drivers/net/wireless/ath/ath10k/mac.c:7126 [<c022f2d4>] (warn_slowpath_null) from [<bf7f150c>] (ath10k_reconfig_complete+0xe4/0x25c [ath10k_core]) [<bf7f150c>] (ath10k_reconfig_complete [ath10k_core]) [<bf7f35f0>] (ath10k_mac_vif_ap_csa_work+0x214/0x370 [ath10k_core]) [<bf7f38b8>] (ath10k_mac_op_change_chanctx+0x108/0x128 [ath10k_core]) [<bf782ac0>] (ieee80211_recalc_chanctx_min_def+0x30c/0x430 [mac80211]) [<bf7830a4>] (ieee80211_recalc_smps_chanctx+0x2ec/0x840 [mac80211]) [<bf7843e8>] (ieee80211_vif_use_reserved_context+0x7c/0xf8 [mac80211]) [<bf7843e8>] (ieee80211_vif_use_reserved_context [mac80211]) [<bf76e5d4>] (ieee80211_csa_finalize_work+0x5c/0x88 [mac80211]) Fixes: d7bf4b4a ("ath10k: fix ar->rx_channel updating logic") Signed-off-by:
-
Gabriel Krisman Bertazi authored
[ Upstream commit 86107838 ] If fbdev emulation is disabled, the QXL shutdown path will try to clean a framebuffer that wasn't initialized, hitting the Oops below. The problem is that even when FBDEV_EMULATION is disabled we allocate the qfbdev strutucture, but we don't initialize it. The fix is to stop allocating the memory, since it won't be used. This allows the existing verification in the cleanup hook to do it's job preventing the oops. Now that we don't allocate the unused fbdev structure, we need to be careful when dereferencing it in the PM suspend hook. [ 24.284684] BUG: unable to handle kernel NULL pointer dereference at 00000000000002e0 [ 24.285627] IP: mutex_lock+0x18/0x30 [ 24.286049] PGD 78cdf067 [ 24.286050] PUD 7940f067 [ 24.286344] PMD 0 [ 24.286649] [ 24.287072] Oops: 0002 [#1] SMP [ 24.287422] Modules linked in: qxl [ 24.287806] CPU: 0 PID: 2328 Comm: bash Not tainted 4.10.0-rc5+ #97 [ 24.288515] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014 [ 24.289681] task: ffff88007c4c0000 task.stack: ffffc90001b58000 [ 24.290354] RIP: 0010:mutex_lock+0x18/0x30 [ 24.290812] RSP: 0018:ffffc90001b5bcb0 EFLAGS: 00010246 [ 24.291401] RAX: 0000000000000000 RBX: 00000000000002e0 RCX: 0000000000000000 [ 24.292209] RDX: ffff88007c4c0000 RSI: 0000000000000001 RDI: 00000000000002e0 [ 24.292987] RBP: ffffc90001b5bcb8 R08: fffffffffffffffe R09: 0000000000000001 [ 24.293797] R10: ffff880078d80b80 R11: 0000000000011400 R12: 0000000000000000 [ 24.294601] R13: 00000000000002e0 R14: ffffffffa0009c28 R15: 0000000000000060 [ 24.295439] FS: 00007f30e3acbb40(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000 [ 24.296364] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 24.296997] CR2: 00000000000002e0 CR3: 0000000078c7b000 CR4: 00000000000006f0 [ 24.297813] Call Trace: [ 24.298097] drm_framebuffer_cleanup+0x1f/0x70 [ 24.298612] qxl_fbdev_fini+0x68/0x90 [qxl] [ 24.299074] qxl_modeset_fini+0xd/0x30 [qxl] [ 24.299562] qxl_pci_remove+0x22/0x50 [qxl] [ 24.300025] pci_device_remove+0x34/0xb0 [ 24.300507] device_release_driver_internal+0x150/0x200 [ 24.301082] device_release_driver+0xd/0x10 [ 24.301587] unbind_store+0x108/0x150 [ 24.301993] drv_attr_store+0x20/0x30 [ 24.302402] sysfs_kf_write+0x32/0x40 [ 24.302827] kernfs_fop_write+0x108/0x190 [ 24.303269] __vfs_write+0x23/0x120 [ 24.303678] ? security_file_permission+0x36/0xb0 [ 24.304193] ? rw_verify_area+0x49/0xb0 [ 24.304636] vfs_write+0xb0/0x190 [ 24.305004] SyS_write+0x41/0xa0 [ 24.305362] entry_SYSCALL_64_fastpath+0x1a/0xa9 [ 24.305887] RIP: 0033:0x7f30e31d9620 [ 24.306285] RSP: 002b:00007ffc54b47e68 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 24.307128] RAX: ffffffffffffffda RBX: 00007f30e3497600 RCX: 00007f30e31d9620 [ 24.307928] RDX: 000000000000000d RSI: 0000000000da2008 RDI: 0000000000000001 [ 24.308727] RBP: 000000000070bc60 R08: 00007f30e3498760 R09: 00007f30e3acbb40 [ 24.309504] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000001 [ 24.310295] R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffc54b47f34 [ 24.311095] Code: 0e 01 e9 7b fe ff ff 66 90 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 53 48 89 fb e8 83 e8 ff ff 65 48 8b 14 25 40 c4 00 00 31 c0 <3e> 48 0f b1 13 48 85 c0 74 08 48 89 df e8 66 fd ff ff 5b 5d c3 [ 24.313182] RIP: mutex_lock+0x18/0x30 RSP: ffffc90001b5bcb0 [ 24.313811] CR2: 00000000000002e0 [ 24.314208] ---[ end trace 29669c1593cae14b ]--- Signed-off-by:
Gabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170227203330.18542-1-krisman@collabora.co.ukSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Valtteri Heikkilä authored
[ Upstream commit 3f375270 ] This patch fixes an issue in drivers/hid/hid-input.c where USB HID control null state flag is not checked upon rejecting inputs outside logical minimum-maximum range. The check should be made according to USB HID specification 1.11, section 6.2.2.5, p.31. The fix will resolve issues with some game controllers, such as: https://bugzilla.kernel.org/show_bug.cgi?id=68621 [tk@the-tk.com: shortened and fixed spelling in commit message] Signed-off-by:
Valtteri Heikkilä <rnd@nic.fi> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 6cc0c259 ] Add a sanity check that wid.val has been allocated, fixes a null pointer deference on stamac when calling ether_add_copy. Detected by CoverityScan, CID#1369537 ("Dereference null return value") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Varsha Rao authored
[ Upstream commit d351c2db ] BUG_ON() is replaced with WARN_ON() and EINVAL is returned, when WARN_ON() is true. This fixes the following checkpatch issue: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON(). Signed-off-by:
Varsha Rao <rvarsha016@gmail.com> Reviewed-by:
Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by:
-
H. Nikolaus Schaller authored
[ Upstream commit 934df231 ] 1. check if chip is really present and don't succeed if it isn't. 2. if it succeeds, power down the chip until accessed Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Hou Tao authored
commit 9b54d816 upstream. If blkg_create fails, new_blkg passed as an argument will be freed by blkg_create, so there is no need to free it again. Signed-off-by:
Hou Tao <houtao1@huawei.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
- 18 Mar, 2018 13 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
Ben writes: > > + int chunklen; > > + > > + chunklen = sizeof(*chunk_hdr) + paylen; > > I think this length still needs to be rounded up (with WORD_ROUND here, > instead of SCTP_PAD4 upstream). So here's a fix for this problem. Reported-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
-
Nikola Ciprich authored
commit 9f2068f3 upstream. Add PCI ids for two variants of Brainboxes UC-260 quad port PCI serial cards. Suggested-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Nikola Ciprich <nikola.ciprich@linuxbox.cz> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Xinyong authored
commit 1a087f03 upstream. When I debug a kernel crash issue in funcitonfs, found ffs_data.ref overflowed, While functionfs is unmounting, ffs_data is put twice. Commit 43938613 ("drivers, usb: convert ffs_data.ref from atomic_t to refcount_t") can avoid refcount overflow, but that is risk some situations. So no need put ffs data in ffs_fs_kill_sb, already put in ffs_data_closed. The issue can be reproduced in Mediatek mt6763 SoC, ffs for ADB device. KASAN enabled configuration reports use-after-free errro. BUG: KASAN: use-after-free in refcount_dec_and_test+0x14/0xe0 at addr ffffffc0579386a0 Read of size 4 by task umount/4650 ==================================================== BUG kmalloc-512 (Tainted: P W O ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in ffs_fs_mount+0x194/0x844 age=22856 cpu=2 pid=566 alloc_debug_processing+0x1ac/0x1e8 ___slab_alloc.constprop.63+0x640/0x648 __slab_alloc.isra.57.constprop.62+0x24/0x34 kmem_cache_alloc_trace+0x1a8/0x2bc ffs_fs_mount+0x194/0x844 mount_fs+0x6c/0x1d0 vfs_kern_mount+0x50/0x1b4 do_mount+0x258/0x1034 INFO: Freed in ffs_data_put+0x25c/0x320 age=0 cpu=3 pid=4650 free_debug_processing+0x22c/0x434 __slab_free+0x2d8/0x3a0 kfree+0x254/0x264 ffs_data_put+0x25c/0x320 ffs_data_closed+0x124/0x15c ffs_fs_kill_sb+0xb8/0x110 deactivate_locked_super+0x6c/0x98 deactivate_super+0xb0/0xbc INFO: Object 0xffffffc057938600 @offset=1536 fp=0x (null) ...... Call trace: [<ffffff900808cf5c>] dump_backtrace+0x0/0x250 [<ffffff900808d3a0>] show_stack+0x14/0x1c [<ffffff90084a8c04>] dump_stack+0xa0/0xc8 [<ffffff900826c2b4>] print_trailer+0x158/0x260 [<ffffff900826d9d8>] object_err+0x3c/0x40 [<ffffff90082745f0>] kasan_report_error+0x2a8/0x754 [<ffffff9008274f84>] kasan_report+0x5c/0x60 [<ffffff9008273208>] __asan_load4+0x70/0x88 [<ffffff90084cd81c>] refcount_dec_and_test+0x14/0xe0 [<ffffff9008d98f9c>] ffs_data_put+0x80/0x320 [<ffffff9008d9d904>] ffs_fs_kill_sb+0xc8/0x110 [<ffffff90082852a0>] deactivate_locked_super+0x6c/0x98 [<ffffff900828537c>] deactivate_super+0xb0/0xbc [<ffffff90082af0c0>] cleanup_mnt+0x64/0xec [<ffffff90082af1b0>] __cleanup_mnt+0x10/0x18 [<ffffff90080d9e68>] task_work_run+0xcc/0x124 [<ffffff900808c8c0>] do_notify_resume+0x60/0x70 [<ffffff90080866e4>] work_pending+0x10/0x14 Cc: stable@vger.kernel.org Signed-off-by:
Xinyong <xinyong.fang@linux.alibaba.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Pete Zaitcev authored
commit a5f59683 upstream. This change fixes buffer overflows and silent data corruption with the usbmon device driver text file read operations. Signed-off-by:
Fredrik Noring <noring@nocrew.org> Signed-off-by:
Pete Zaitcev <zaitcev@redhat.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Julia Lawall authored
commit 46c236dc upstream. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression e1,e2; statement S1,S2; @@ +e1 = e2; if (IS_ERR( e1 - = e2 )) S1 else S2 // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Danilo Krummrich authored
commit cb88a058 upstream. Corsair Strafe RGB keyboard does not respond to usb control messages sometimes and hence generates timeouts. Commit de3af5bf ("usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard") tried to fix those timeouts by adding USB_QUIRK_DELAY_INIT. Unfortunately, even with this quirk timeouts of usb_control_msg() can still be seen, but with a lower frequency (approx. 1 out of 15): [ 29.103520] usb 1-8: string descriptor 0 read error: -110 [ 34.363097] usb 1-8: can't set config #1, error -110 Adding further delays to different locations where usb control messages are issued just moves the timeouts to other locations, e.g.: [ 35.400533] usbhid 1-8:1.0: can't add hid device: -110 [ 35.401014] usbhid: probe of 1-8:1.0 failed with error -110 The only way to reliably avoid those issues is having a pause after each usb control message. In approx. 200 boot cycles no more timeouts were seen. Addionaly, keep USB_QUIRK_DELAY_INIT as it turned out to be necessary to have the delay in hub_port_connect() after hub_port_init(). The overall boot time seems not to be influenced by these additional delays, even on fast machines and lightweight distributions. Fixes: de3af5bf ("usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard") Cc: stable@vger.kernel.org Signed-off-by:
Danilo Krummrich <danilokrummrich@dk-develop.de> Signed-off-by:
-
Teijo Kinnunen authored
commit 5126a504 upstream. This USB-SATA controller seems to be similar with JMicron bridge 152d:2566 already on the list. Adding it here fixes "Invalid field in cdb" errors. Signed-off-by:
Teijo Kinnunen <teijo.kinnunen@code-q.fi> Cc: stable@vger.kernel.org Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Joel Fernandes authored
commit cb57469c upstream. ashmem_mutex create a chain of dependencies like so: (1) mmap syscall -> mmap_sem -> (acquired) ashmem_mmap ashmem_mutex (try to acquire) (block) (2) llseek syscall -> ashmem_llseek -> ashmem_mutex -> (acquired) inode_lock -> inode->i_rwsem (try to acquire) (block) (3) getdents -> iterate_dir -> inode_lock -> inode->i_rwsem (acquired) copy_to_user -> mmap_sem (try to acquire) There is a lock ordering created between mmap_sem and inode->i_rwsem causing a lockdep splat [2] during a syzcaller test, this patch fixes the issue by unlocking the mutex earlier. Functionally that's Ok since we don't need to protect vfs_llseek. [1] https://patchwork.kernel.org/patch/10185031/ [2] https://lkml.org/lkml/2018/1/10/48Acked-by:
Todd Kjos <tkjos@google.com> Cc: Arve Hjonnevag <arve@android.com> Cc: stable@vger.kernel.org Reported-by: syzbot+8ec30bb7bf1a981a2012@syzkaller.appspotmail.com Signed-off-by:
Joel Fernandes <joelaf@google.com> Acked-by:
Greg Hackmann <ghackmann@google.com> Signed-off-by:
-
Frank Mori Hess authored
commit a42ae590 upstream. A rounding error was causing comedi_nsamples_left to return the wrong value when nsamples was not a multiple of the scan length. Cc: <stable@vger.kernel.org> # v4.4+ Signed-off-by:
Frank Mori Hess <fmh6jj@gmail.com> Reviewed-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Oliver Neukum authored
commit 9a513c90 upstream. A typo broke the comparison. Fixes: cbeef22f ("usb: uas: unconditionally bring back host after reset") Signed-off-by:
Oliver Neukum <oneukum@suse.com> CC: stable@kernel.org Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Jonas Danielsson authored
commit fd63a890 upstream. On our at91sam9260 based board the usart0 and usart1 ports report their versions (ATMEL_US_VERSION) as 0x10302. This version is not included in the current checks in the driver. Signed-off-by:
Jonas Danielsson <jonas@orbital-systems.com> Acked-by:
Richard Genoud <richard.genoud@gmail.com> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Ulrich Hecht authored
commit 7842055b upstream. When the TTY buffers fill up to the configured maximum, a system lockup occurs: [ 598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 598.825796] 0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1 [ 598.832577] (detected by 3, t=62517 jiffies, g=296, c=295, q=126) [ 598.838755] Task dump for CPU 0: [ 598.841977] swapper/0 R running task 0 0 0 0x00000022 [ 598.849023] Call trace: [ 598.851476] __switch_to+0x98/0xb0 [ 598.854870] (null) This can be prevented by doing a dummy read of the RX data register. This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0; reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms as well. Reported-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Ulrich Hecht <ulrich.hecht+renesas@gmail.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Cc: stable <stable@vger.kernel.org> Tested-by:
Nguyen Viet Dung <dung.nguyen.aj@renesas.com> Signed-off-by:
-
