- 22 Mar, 2018 40 commits
-
-
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:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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:
-
Ravi Bangoria authored
[ Upstream commit f0a30dca ] '*ntevs' contains number of elements present in 'tevs' array. If there are no elements in array, 'tevs2' can be directly assigned to 'tevs' without allocating more space. So the condition should be '*ntevs == 0' not 'ntevs == 0'. Signed-off-by:
Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> Acked-by:
-
Arvind Yadav authored
[ Upstream commit 0348aaa3 ] dss_init_ports() is not handling return errors from dpi_init_port() and sdi_init_port(). It is also always returning 0 currently which results in part of error handling code in dss_bind() being unused. Fix dss_init_ports() to handle return errors from dpi_init_port() and sdi_init_port(). Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Cc: tomi.valkeinen@ti.com [b.zolnierkie: fail early on errors, minor fixups] Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Yazen Ghannam authored
[ Upstream commit 5204bf17 ] When the MCA banks in __mcheck_cpu_init_generic() are polled for leftover errors logged during boot or from the previous boot, its required to have CPU features detected sufficiently so that the reading out and handling of those early errors is done correctly. If those features are not available, the decoding may miss some information and get incomplete errors logged. For example, on SMCA systems the MCA_IPID and MCA_SYND registers are not logged and MCA_ADDR is not masked appropriately. To cure that, do a subset of the basic feature detection early while the rest happens in its usual place in __mcheck_cpu_init_vendor(). Signed-off-by:
Yazen Ghannam <Yazen.Ghannam@amd.com> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Cc: x86-ml <x86@kernel.org> Link: http://lkml.kernel.org/r/1489599055-20756-1-git-send-email-Yazen.Ghannam@amd.com [ Massage commit message and simplify. ] Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Nik Unger authored
[ Upstream commit 5080f39e ] I recently reported on the netem list that iperf network benchmarks show unexpected results when a bandwidth throttling rate has been configured for netem. Specifically: 1) The measured link bandwidth *increases* when a higher delay is added 2) The measured link bandwidth appears higher than the specified limit 3) The measured link bandwidth for the same very slow settings varies significantly across machines The issue can be reproduced by using tc to configure netem with a 512kbit rate and various (none, 1us, 50ms, 100ms, 200ms) delays on a veth pair between network namespaces, and then using iperf (or any other network benchmarking tool) to test throughput. Complete detailed instructions are in the original email chain here: https://lists.linuxfoundation.org/pipermail/netem/2017-February/001672.html There appear to be two underlying bugs causing these effects: - The first issue causes long delays when the rate is slow and no delay is configured (e.g., "rate 512kbit"). This is because SKBs are not orphaned when no delay is configured, so orphaning does not occur until *after* the rate-induced delay has been applied. For this reason, adding a tiny delay (e.g., "rate 512kbit delay 1us") dramatically increases the measured bandwidth. - The second issue is that rate-induced delays are not correctly applied, allowing SKB delays to occur in parallel. The indended approach is to compute the delay for an SKB and to add this delay to the end of the current queue. However, the code does not detect existing SKBs in the queue due to improperly testing sch->q.qlen, which is nonzero even when packets exist only in the rbtree. Consequently, new SKBs do not wait for the current queue to empty. When packet delays vary significantly (e.g., if packet sizes are different), then this also causes unintended reordering. I modified the code to expect a delay (and orphan the SKB) when a rate is configured. I also added some defensive tests that correctly find the latest scheduled delivery time, even if it is (unexpectedly) for a packet in sch->q. I have tested these changes on the latest kernel (4.11.0-rc1+) and the iperf / ping test results are as expected. Signed-off-by:
Nik Unger <njunger@uwaterloo.ca> Signed-off-by:
Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
-
Steve Lin authored
[ Upstream commit 2f771399 ] Allows the BCMA version of the bgmac driver to obtain MAC address from the device tree. If no MAC address is specified there, then the previous behavior (obtaining MAC address from SPROM) is used. Signed-off-by:
Steve Lin <steven.lin1@broadcom.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Acked-by:
Jon Mason <jon.mason@broadcom.com> Signed-off-by:
-
Stefan Wahren authored
[ Upstream commit bdd3c254 ] Currently bcm2835_defconfig has CMA disabled which makes the HDMI output on a Raspberry Pi 1 stop working during boot: fb: switching to vc4drmfb from simple Console: switching to colour dummy device 80x30 [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. vc4-drm soc:gpu: failed to allocate buffer with size 9216000 vc4-drm soc:gpu: Failed to set initial hw configuration. So enable CMA and DMA_CMA in bcm2835_defconfig. Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Fixes: 4400d9ac ("ARM: bcm2835: Enable the VC4 graphics driver in the defconfig") Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Oliver Neukum authored
[ Upstream commit c4ba329c ] There is a small window during which the an URB may remain active after disconnect has returned. If in that case already freed memory may be accessed and executed. The fix is to poison the URB befotre the work is flushed. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
-
Mohammed Shafi Shajakhan authored
[ Upstream commit a28f6f27 ] Fetch target operating channel during potential radar detection when the interface is just brought up, but no channel is assigned from userspace. In this scenario rx_channel may not be having a valid pointer hence fetch the target operating channel to avoid warnings as below which can be triggered by the commands with DFS testing over longer run comamnds: iw wlan1 set type mesh ifconfig wlan1 up (valid tgt_oper_chan only) iw wlan1 cac trigger freq 5260 HT20 (valid rx_channel, tgt_oper_chan) iw wlan1 cac trigger freq 5280 HT20 iw wlan1 cac trigger freq 5300 HT20 Once the CAC expires, current channel context will be removed and we are only left with the fallback option of using 'target operating channel' Firmware and driver log: ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5, count_false=4 ath: phy1: DFS: radar found on freq=5260: id=5, pri=3151, count=6, count_false=11 ath: phy1: DFS: radar found on freq=5280: id=1, pri=1351, count=6, count_false=4 ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5, count_false=4 ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse, treating as radar ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse, treating as radar Call trace: WARNING: CPU: 1 PID: 2145 at backports-20161201-3.14.77-9ab3068/net/wireless/chan.c:265 cfg80211_set_dfs_state+0x3c/0x88 [cfg80211]() Workqueue: phy1 ieee80211_dfs_radar_detected_work [mac80211] [<c0320770>] (warn_slowpath_null) from [<bf79b90c>] (cfg80211_set_dfs_state+0x3c/0x88 [cfg80211]) [<bf79b90c>] (cfg80211_set_dfs_state [cfg80211]) from [<bf79697c>] (cfg80211_radar_event+0xc4/0x140 [cfg80211]) [<bf79697c>] (cfg80211_radar_event [cfg80211]) from [<bf83c058>] (ieee80211_dfs_radar_detected_work+0xa8/0xb4 [mac80211]) [<bf83c058>] (ieee80211_dfs_radar_detected_work [mac80211]) from [<c0339518>] (process_one_work+0x298/0x4a4) Signed-off-by:
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.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:
-
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:
-
Iyappan Subramanian authored
[ Upstream commit 0a0400c3 ] This patch fixes Rx checksum validation logic and adds NETIF_F_RXCSUM flag. Signed-off-by:
Iyappan Subramanian <isubramanian@apm.com> Signed-off-by:
-
Quan Nguyen authored
[ Upstream commit 11623fce ] This patch fixes the wrong logical OR operation by changing it to bit-wise OR operation. Fixes: 3bb502f8 ("drivers: net: xgene: fix statistics counters race condition") Signed-off-by:
Quan Nguyen <qnguyen@apm.com> Signed-off-by:
-
Quan Nguyen authored
[ Upstream commit 4b72436d ] This patches fixes a typo in the argument to xgene_enet_wr_mdio_csr(). Signed-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:
-
Al Cooper authored
[ Upstream commit 3c51b9c7 ] Some Host Controller hardware blocks, like the OHCI, EHCI and SDIO controllers, have hardware blocks that are not capable of doing 64 bit DMA. These host controllers fail on boards with >3GB of memory because the memory above 3GB is located physically >= 0x100000000 and can only be accessed using 64 DMA. The way Linux is currently configured for BRCMSTB systems, the memory given to drivers for DMA through functions like dma_alloc_coherent() comes from CMA memory and CMA memory is taken from the top of physical memory. When these drivers get a DMA buffer with an address >=0x100000000, they end up dropping the upper 32 bit of the address causing the hardware to DMA to incorrect memory, typically BMEM (custom memory carveout). This issue was discovered on a BCM97449SSV_DDR4 system with 4GB or memory. The fix is to enable CONFIG_ZONE_DMA. On ARM systems this makes sure that all DMA memory is located within the first 32 bits of address space. Signed-off-by:
Al Cooper <alcooperx@gmail.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:
-
Greg KH authored
[ Upstream commit 6f051e4a ] [resend due to me forgetting to cc: linux-api the first time around I posted these back on Feb 23] From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> When userspace tries to use these defines, it complains that it needs to be an unsigned 1 that is shifted, so libc implementations have to create their own version. Fix this by defining it properly so that libcs can just use the kernel uapi header. Reported-by:
Elliott Hughes <enh@google.com> Signed-off-by:
-
Xunlei Pang authored
[ Upstream commit 5bc32950 ] When we are about to kexec a crash kernel and right then and there a broadcasted MCE fires while we're still in the first kernel and while the other CPUs remain in a holding pattern, the #MC handler of the first kernel will timeout and then panic due to never completing MCE synchronization. Handle this in a similar way as to when the CPUs are offlined when that broadcasted MCE happens. [ Boris: rewrote commit message and comments. ] Suggested-by:
Borislav Petkov <bp@alien8.de> Signed-off-by:
Xunlei Pang <xlpang@redhat.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: kexec@lists.infradead.org Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/1487857012-9059-1-git-send-email-xlpang@redhat.com Link: http://lkml.kernel.org/r/20170313095019.19351-1-bp@alien8.deSigned-off-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:
-
Dmitry Safonov authored
[ Upstream commit 3e6ef9c8 ] mmap(MAP_32BIT) is broken due to the dependency on the TIF_ADDR32 thread flag. For 64bit applications MAP_32BIT will force legacy bottom-up allocations and the 1GB address space restriction even if the application issued a compat syscall, which should not be subject of these restrictions. For 32bit applications, which issue 64bit syscalls the newly introduced mmap base separation into 64-bit and compat bases changed the behaviour because now a 64-bit mapping is returned, but due to the TIF_ADDR32 dependency MAP_32BIT is ignored. Before the separation a 32-bit mapping was returned, so the MAP_32BIT handling was irrelevant. Replace the check for TIF_ADDR32 with a check for the compat syscall. That solves both the 64-bit issuing a compat syscall and the 32-bit issuing a 64-bit syscall problems. [ tglx: Massaged changelog ] Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Cc: 0x7f454c46@gmail.com Cc: linux-mm@kvack.org Cc: Andy Lutomirski <luto@kernel.org> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Borislav Petkov <bp@suse.de> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Link: http://lkml.kernel.org/r/20170306141721.9188-5-dsafonov@virtuozzo.comSigned-off-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:
-
Chen-Yu Tsai authored
[ Upstream commit 4c7f16d1 ] The TCON driver calls sun4i_tcon_init_regmap and sun4i_tcon_init_clocks in its bind function. The former creates a regmap and writes to several register to clear its configuration to a known default. The latter initializes various clocks. This includes enabling the bus clock for register access and creating the dotclock. In order for the first step's writes to work, the bus clock must be enabled which is done in the second step. but the dotclock's ops use the regmap created in the first step. Rearrange the function calls such that the clocks are initialized before the regmap, and split out the dot clock creation to after the regmap is initialized. Fixes: 9026e0d1 ("drm: Add Allwinner A10 Display Engine support") Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.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:
-
Chen-Yu Tsai authored
[ Upstream commit 75448607 ] The way drm_of_find_possible_crtcs works is it tries to match the remote-endpoint of the given node's various endpoints to all the crtc's .port field. Thus we need to set drm_crtc.port to the output port node of the underlying TCON. Signed-off-by:
-
Chen-Yu Tsai authored
[ Upstream commit 9d56defb ] The master bind function calls numerous drm functions which initialize underlying structures. It also tries to bind the various components of the display pipeline, some of which may add additional drm objects. This patch adds proper cleanup functions in the error path of the master bind function. This requires the patch "drm/sun4i: Move drm_mode_config_cleanup call to main driver", which splits out drm_mode_config_cleanup from sun4i_framebuffer_free so we can call it separately. Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 57a4fd42 ] The Cortex-A57 cache controller is an integrated controller, and thus the device node representing it should not have a unit-addresses or reg property. Fixes: 1561f207 ("arm64: dts: r8a7796: Add Renesas R8A7796 SoC support") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 65d0b7ed ] The Cortex-A7 cache controller is an integrated controller, and thus the device node representing it should not have a unit-addresses or reg property. Fixes: 34ea4b4a ("ARM: dts: r8a7794: Fix W=1 dtc warnings") Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit beffa887 ] The Cortex-A15 cache controller is an integrated controller, and thus the device node representing it should not have a unit-addresses or reg property. Fixes: ad53f5f0 ("ARM: dts: r8a7793: Fix W=1 dtc warnings") Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit a0504f08 ] The Cortex-A15 cache controller is an integrated controller, and thus the device node representing it should not have a unit-addresses or reg property. Fixes: 7c4163aa ("ARM: dts: r8a7792: initial SoC device tree") Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 5d6a2165 ] The Cortex-A15 cache controller is an integrated controller, and thus the device node representing it should not have a unit-addresses or reg property. Fixes: 6f9314ce ("ARM: dts: r8a7791: Fix W=1 dtc warnings") 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:
-
