- 25 May, 2019 40 commits
-
-
ZhangXiaoxu authored
commit f02f3755 upstream. stat command with soft mount never return after server is stopped. When alloc a new client, the state of the client will be set to NFS4CLNT_LEASE_EXPIRED. When the server is stopped, the state manager will work, and accord the state to recover. But the state is NFS4CLNT_LEASE_EXPIRED, it will drain the slot table and lead other task to wait queue, until the client recovered. Then the stat command is hung. When discover server trunking, the client will renew the lease, but check the client state, it lead the client state corruption. So, we need to call state manager to recover it when detect server ip trunking. Signed-off-by:
ZhangXiaoxu <zhangxiaoxu5@huawei.com> Cc: stable@vger.kernel.org Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Leon Romanovsky authored
commit b79656ed upstream. Systemd triggers the following warning during IPoIB device load: mlx5_core 0000:00:0c.0 ib0: "systemd-udevd" wants to know my dev_id. Should it look at dev_port instead? See Documentation/ABI/testing/sysfs-class-net for more info. This is caused due to user space attempt to differentiate old systems without dev_port and new systems with dev_port. In case dev_port will be zero, the systemd will try to read dev_id instead. There is no need to print a warning in such case, because it is valid situation and it is needed to ensure systemd compatibility with old kernels. Link: https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L358 Cc: <stable@vger.kernel.org> # 4.19 Fixes: f6350da4 ("IB/ipoib: Log sysfs 'dev_id' accesses from userspace") Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Jason Gunthorpe authored
commit ddcdc368 upstream. get_zeroed_page() returns a virtual address for the page which is better than allocating a struct page and doing a permanent kmap on it. Cc: stable@vger.kernel.org Signed-off-by:
Haggai Eran <haggaie@mellanox.com> Signed-off-by:
-
Steve Longerbeam authored
commit dee747f8 upstream. The second IPU internal sub-devices were being registered and links to them created even when the second IPU is not present. This is wrong for i.MX6 S/DL and i.MX53 which have only a single IPU. Fixes: e1302912 ("[media] media: Add i.MX media core driver") Signed-off-by:
Steve Longerbeam <slongerbeam@gmail.com> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Cc: stable@vger.kernel.org Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Steve Longerbeam authored
commit 085b26da upstream. For the functions that add and remove the internal IPU subdevice descriptors, rename them to make clear they are the subdevs internal to the IPU. Also rename the platform data structure for the internal IPU subdevices. No functional changes. Signed-off-by:
-
Steve Longerbeam authored
commit 107927fa upstream. In imx_media_create_csi_of_links(), the 'struct v4l2_fwnode_link' must be cleared for each endpoint iteration, otherwise if the remote port has no "reg" property, link.remote_port will not be reset to zero. This was discovered on the i.MX53 SMD board, since the OV5642 connects directly to ipu1_csi0 and has a single source port with no "reg" property. Fixes: 621b08ea ("media: staging/imx: remove static media link arrays") Signed-off-by:
-
Steve Longerbeam authored
commit 904371f9 upstream. On i.MX6, the nearest upstream entity to the CSI can only be the CSI video muxes or the Synopsys DW MIPI CSI-2 receiver. However the i.MX53 has no CSI video muxes or a MIPI CSI-2 receiver. So allow for the nearest upstream entity to the CSI to be something other than those. Fixes: bf3cfaa7 ("media: staging/imx: get CSI bus type from nearest upstream entity") Signed-off-by:
-
Arnd Bergmann authored
commit 63604a14 upstream. I previously added an RC_CORE dependency here, but missed the corner case of CONFIG_VIDEO_SECO_CEC=y with CONFIG_RC_CORE=m, which still causes a link error: drivers/media/platform/seco-cec/seco-cec.o: In function `secocec_probe': seco-cec.c:(.text+0x1b8): undefined reference to `devm_rc_allocate_device' seco-cec.c:(.text+0x2e8): undefined reference to `devm_rc_register_device' drivers/media/platform/seco-cec/seco-cec.o: In function `secocec_irq_handler': seco-cec.c:(.text+0xa2c): undefined reference to `rc_keydown' Refine the dependency to disallow building the RC subdriver in this case. This is the same logic we apply in other drivers like it. Fixes: f27dd0ad ("media: seco-cec: fix RC_CORE dependency") Cc: <stable@vger.kernel.org> # 5.1 Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Janusz Krzysztofik authored
commit 933c1320 upstream. After removal of clock_start() from before soc_camera_init_i2c() in soc_camera_probe() by commit 9aea470b ("[media] soc-camera: switch I2C subdevice drivers to use v4l2-clk") introduced in v3.11, the ov6650 driver could no longer probe the sensor successfully because its clock was no longer turned on in advance. The issue was initially worked around by adding that missing clock_start() equivalent to OMAP1 camera interface driver - the only user of this sensor - but a propoer fix should be rather implemented in the sensor driver code itself. Fix the issue by inserting a delay between the clock is turned on and the sensor I2C registers are read for the first time. Tested on Amstrad Delta with now out of tree but still locally maintained omap1_camera host driver. Fixes: 9aea470b ("[media] soc-camera: switch I2C subdevice drivers to use v4l2-clk") Signed-off-by:
Janusz Krzysztofik <jmkrzyszt@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Colin Ian King authored
commit e6577cb5 upstream. There seems to be a missing bit-wise or operator when setting val, fix this by adding it in. Fixes: 2796ceb0 ("phy: ti-pipe3: Update pcie phy settings") Cc: stable@vger.kernel.org # v4.19+ Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
Christoph Probst authored
commit 6a54b2e0 upstream. Change strcat to strncpy in the "None" case to fix a buffer overflow when cinode->oplock is reset to 0 by another thread accessing the same cinode. It is never valid to append "None" to any other message. Consolidate multiple writes to cinode->oplock to reduce raciness. Signed-off-by:
Christoph Probst <kernel@probst.it> Reviewed-by:
Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
Steve French <stfrench@microsoft.com> CC: Stable <stable@vger.kernel.org> Signed-off-by:
-
Ronnie Sahlberg authored
commit d69cb728 upstream. For SMB1 oplock breaks we would grab one credit while sending the PDU but we would never relese the credit back since we will never receive a response to this from the server. Eventuallt this would lead to a hang once all credits are leaked. Fix this by defining a new flag CIFS_NO_SRV_RSP which indicates that there is no server response to this command and thus we need to add any credits back immediately after sending the PDU. CC: Stable <stable@vger.kernel.org> #v5.0+ Signed-off-by:
Ronnie Sahlberg <lsahlber@redhat.com> Reviewed-by:
-
Hans de Goede authored
commit b1a0ba8f upstream. The ACEPC T8 and T11 mini PCs contain quite generic names in the sys_vendor and product_name DMI strings, without this patch brcmfmac will try to load: "brcmfmac43455-sdio.Default string-Default string.txt" as nvram file which is way too generic. The DMI strings on which we are matching are somewhat generic too, but "To be filled by O.E.M." is less common then "Default string" and the system-sku and bios-version strings are pretty unique. Beside the DMI strings we also check the wifi-module chip-id and revision. I'm confident that the combination of all this is unique. Both the T8 and T11 use the same wifi-module, this commit adds DMI quirks for both mini PCs pointing to brcmfmac43455-sdio.acepc-t8.txt . BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1690852 Cc: stable@vger.kernel.org Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Phong Tran authored
commit 44086866 upstream. Now, make the loop explicit to avoid clang warning. ./include/linux/of.h:238:37: warning: multiple unsequenced modifications to 'cell' [-Wunsequenced] r = (r << 32) | be32_to_cpu(*(cell++)); ^~ ./include/linux/byteorder/generic.h:95:21: note: expanded from macro 'be32_to_cpu' ^ ./include/uapi/linux/byteorder/little_endian.h:40:59: note: expanded from macro '__be32_to_cpu' ^ ./include/uapi/linux/swab.h:118:21: note: expanded from macro '__swab32' ___constant_swab32(x) : \ ^ ./include/uapi/linux/swab.h:18:12: note: expanded from macro '___constant_swab32' (((__u32)(x) & (__u32)0x000000ffUL) << 24) | \ ^ Signed-off-by:
Phong Tran <tranmanphong@gmail.com> Reported-by:
Nick Desaulniers <ndesaulniers@google.com> Link: https://github.com/ClangBuiltLinux/linux/issues/460Suggested-by:
David Laight <David.Laight@ACULAB.COM> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Pan Bian authored
commit 8149069d upstream. The function p54p_probe takes an extra reference count of the PCI device. However, the extra reference count is not dropped when it fails to enable the PCI device. This patch fixes the bug. Cc: stable@vger.kernel.org Signed-off-by:
Pan Bian <bianpan2016@163.com> Acked-by:
Christian Lamparter <chunkeey@gmail.com> Signed-off-by:
-
Alexander Shishkin authored
commit 4e0eaf23 upstream. Currently, the pages that are allocated for the single mode of MSC are not mapped into the device's dma space and the code is incorrectly using *_to_phys() in place of a dma address. This fails with IOMMU enabled and is otherwise bad practice. Fix the single mode buffer allocation to map the pages into the device's DMA space. Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Fixes: ba82664c ("intel_th: Add Memory Storage Unit driver") Cc: stable@vger.kernel.org # v4.4+ Signed-off-by:
-
Al Viro authored
commit 5467a68c upstream. For lockless accesses to dentries we don't have pinned we rely (among other things) upon having an RCU delay between dropping the last reference and actually freeing the memory. On the other hand, for things like pipes and sockets we neither do that kind of lockless access, nor want to deal with the overhead of an RCU delay every time a socket gets closed. So delay was made optional - setting DCACHE_RCUACCESS in ->d_flags made sure it would happen. We tried to avoid setting it unless we knew we need it. Unfortunately, that had led to recurring class of bugs, in which we missed the need to set it. We only really need it for dentries that are created by d_alloc_pseudo(), so let's not bother with trying to be smart - just make having an RCU delay the default. The ones that do *not* get it set the replacement flag (DCACHE_NORCU) and we'd better use that sparingly. d_alloc_pseudo() is the only such user right now. FWIW, the race that finally prompted that switch had been between __lock_parent() of immediate subdirectory of what's currently the root of a disconnected tree (e.g. from open-by-handle in progress) racing with d_splice_alias() elsewhere picking another alias for the same inode, either on outright corrupted fs image, or (in case of open-by-handle on NFS) that subdirectory having been just moved on server. It's not easy to hit, so the sky is not falling, but that's not the first race on similar missed cases and the logics for settinf DCACHE_RCUACCESS has gotten ridiculously convoluted. Cc: stable@vger.kernel.org Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Christoph Hellwig authored
commit ed4d0a4e upstream. The on-disk value is little endian and we need to convert it to native endian before storing the value in the in-core structure. Fixes: 7564beda ("md-cluster/raid10: support add disk under grow mode") Cc: <stable@vger.kernel.org> # 4.20+ Acked-by:
Guoqing Jiang <gqjiang@suse.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
-
Yufen Yu authored
commit ee37e621 upstream. When doing re-add, we need to ensure rdev->mddev->pers is not NULL, which can avoid potential NULL pointer derefence in fallowing add_bound_rdev(). Fixes: a6da4ef8 ("md: re-add a failed disk") Cc: Xiao Ni <xni@redhat.com> Cc: NeilBrown <neilb@suse.com> Cc: <stable@vger.kernel.org> # 4.4+ Reviewed-by:
NeilBrown <neilb@suse.com> Signed-off-by:
Yufen Yu <yuyufen@huawei.com> Signed-off-by:
-
NeilBrown authored
commit 2bc13b83 upstream. Currently if many flush requests are submitted to an md device is quick succession, they are serialized and can take a long to process them all. We don't really need to call flush all those times - a single flush call can satisfy all requests submitted before it started. So keep track of when the current flush started and when it finished, allow any pending flush that was requested before the flush started to complete without waiting any more. Test results from Xiao: Test is done on a raid10 device which is created by 4 SSDs. The tool is dbench. 1. The latest linux stable kernel Operation Count AvgLat MaxLat -------------------------------------------------- Deltree 768 10.509 78.305 Flush 2078376 0.013 10.094 Close 21787697 0.019 18.821 LockX 96580 0.007 3.184 Mkdir 384 0.008 0.062 Rename 1255883 0.191 23.534 ReadX 46495589 0.020 14.230 WriteX 14790591 7.123 60.706 Unlink 5989118 0.440 54.551 UnlockX 96580 0.005 2.736 FIND_FIRST 10393845 0.042 12.079 SET_FILE_INFORMATION 2415558 0.129 10.088 QUERY_FILE_INFORMATION 4711725 0.005 8.462 QUERY_PATH_INFORMATION 26883327 0.032 21.715 QUERY_FS_INFORMATION 4929409b 0.010 8.238 NTCreateX 29660080 0.100 53.268 Throughput 1034.88 MB/sec (sync open) 128 clients 128 procs max_latency=60.712 ms 2. With patch1 "Revert "MD: fix lock contention for flush bios"" Operation Count AvgLat MaxLat -------------------------------------------------- Deltree 256 8.326 36.761 Flush 693291 3.974 180.269 Close 7266404 0.009 36.929 LockX 32160 0.006 0.840 Mkdir 128 0.008 0.021 Rename 418755 0.063 29.945 ReadX 15498708 0.007 7.216 WriteX 4932310 22.482 267.928 Unlink 1997557 0.109 47.553 UnlockX 32160 0.004 1.110 FIND_FIRST 3465791 0.036 7.320 SET_FILE_INFORMATION 805825 0.015 1.561 QUERY_FILE_INFORMATION 1570950 0.005 2.403 QUERY_PATH_INFORMATION 8965483 0.013 14.277 QUERY_FS_INFORMATION 1643626 0.009 3.314 NTCreateX 9892174 0.061 41.278 Throughput 345.009 MB/sec (sync open) 128 clients 128 procs max_latency=267.939 m 3. With patch1 and patch2 Operation Count AvgLat MaxLat -------------------------------------------------- Deltree 768 9.570 54.588 Flush 2061354 0.666 15.102 Close 21604811 0.012 25.697 LockX 95770 0.007 1.424 Mkdir 384 0.008 0.053 Rename 1245411 0.096 12.263 ReadX 46103198 0.011 12.116 WriteX 14667988 7.375 60.069 Unlink 5938936 0.173 30.905 UnlockX 95770 0.005 4.147 FIND_FIRST 10306407 0.041 11.715 SET_FILE_INFORMATION 2395987 0.048 7.640 QUERY_FILE_INFORMATION 4672371 0.005 9.291 QUERY_PATH_INFORMATION 26656735 0.018 19.719 QUERY_FS_INFORMATION 4887940 0.010 7.654 NTCreateX 29410811 0.059 28.551 Throughput 1026.21 MB/sec (sync open) 128 clients 128 procs max_latency=60.075 ms Cc: <stable@vger.kernel.org> # v4.19+ Tested-by:
Xiao Ni <xni@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
NeilBrown authored
commit 4bc034d3 upstream. This reverts commit 5a409b4f. This patch has two problems. 1/ it make multiple calls to submit_bio() from inside a make_request_fn. The bios thus submitted will be queued on current->bio_list and not submitted immediately. As the bios are allocated from a mempool, this can theoretically result in a deadlock - all the pool of requests could be in various ->bio_list queues and a subsequent mempool_alloc could block waiting for one of them to be released. 2/ It aims to handle a case when there are many concurrent flush requests. It handles this by submitting many requests in parallel - all of which are identical and so most of which do nothing useful. It would be more efficient to just send one lower-level request, but allow that to satisfy multiple upper-level requests. Fixes: 5a409b4f ("MD: fix lock contention for flush bios") Cc: <stable@vger.kernel.org> # v4.19+ Tested-by:
-
Paul Moore authored
commit 35a196be upstream. Prevent userspace from changing the the /proc/PID/attr values if the task's credentials are currently overriden. This not only makes sense conceptually, it also prevents some really bizarre error cases caused when trying to commit credentials to a task with overridden credentials. Cc: <stable@vger.kernel.org> Reported-by:
"chengjian (D)" <cj.chengjian@huawei.com> Signed-off-by:
Paul Moore <paul@paul-moore.com> Acked-by:
John Johansen <john.johansen@canonical.com> Acked-by:
James Morris <james.morris@microsoft.com> Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
-
Hou Tao authored
commit f6b50160 upstream. __GFP_HIGHMEM is disabled if dax is enabled on brd, however dax support for brd has been removed since commit (7a862fbb "brd: remove dax support"), so restore __GFP_HIGHMEM in brd_insert_page(). Also remove the no longer applicable comments about DAX and highmem. Cc: stable@vger.kernel.org Fixes: 7a862fbb ("brd: remove dax support") Signed-off-by:
Hou Tao <houtao1@huawei.com> Signed-off-by:
-
Alexander Shishkin authored
commit 51e0f227 upstream. Commit 7bd1d409 ("stm class: Introduce an abstraction for System Trace Module devices") naively calculates the channel bitmap size in 64-bit chunks regardless of the size of underlying unsigned long, making the bitmap half as big on a 32-bit system. This leads to an out of bounds access with the upper half of the bitmap. Fix this by using BITS_TO_LONGS. While at it, convert to using struct_size() for the total size calculation of the master struct. Signed-off-by:
Mulu He <muluhe@codeaurora.org> Cc: stable@vger.kernel.org # v4.4+ Signed-off-by:
-
Tingwei Zhang authored
commit ee496da4 upstream. Number of free masters is not set correctly in stm free path. Fix this by properly adding the number of output channels before setting them to 0 in stm_output_disclaim(). Currently it is equivalent to doing nothing since master->nr_free is incremented by 0. Fixes: 7bd1d409 ("stm class: Introduce an abstraction for System Trace Module devices") Signed-off-by:
Tingwei Zhang <tingwei@codeaurora.org> Signed-off-by:
Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Cc: stable@vger.kernel.org # v4.4 Signed-off-by:
-
Helge Deller authored
commit 1829dda0 upstream. LEVEL is a very common word, and now after many years it suddenly clashed with another LEVEL define in the DRBD code. Rename it to PA_ASM_LEVEL instead. Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Helge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Helge Deller authored
commit bdca5d64 upstream. The LEVEL define clashed with the DRBD code. Reported-by:
-
Helge Deller authored
commit d19a1290 upstream. When making the text sections writeable with set_kernel_text_rw(1), include all text sections including those in the __init section. Otherwise functions marked with __meminit will stay read-only. Signed-off-by:
-
Helge Deller authored
commit 2d94a832 upstream. Add compiler memory barriers to ensure the compiler doesn't reorder memory operations around these instructions. Cc: stable@vger.kernel.org # v4.20+ Fixes: 3847dab7 ("parisc: Add alternative coding infrastructure") Signed-off-by:
-
Helge Deller authored
commit b4387490 upstream. No need to spend CPU cycles when we run on QEMU. Signed-off-by:
-
John David Anglin authored
commit 44224bdb upstream. The pdtlb and pitlb instructions are strongly ordered. The asms invoking these instructions should be compiler memory barriers to ensure the compiler doesn't reorder memory operations around these instructions. Signed-off-by:
John David Anglin <dave.anglin@bell.net> CC: stable@vger.kernel.org # v4.20+ Fixes: 3847dab7 ("parisc: Add alternative coding infrastructure") Signed-off-by:
-
Helge Deller authored
commit 3e1120f4 upstream. Signed-off-by:
-
Steve Twiss authored
commit 70b46491 upstream. During several error paths in the function regulator_set_voltage_unlocked() the value of 'ret' can take on negative error values. However, in calls that go through the 'goto out' statement, this return value is lost and return 0 is used instead, indicating a 'pass'. There are several cases where this function should legitimately return a fail instead of a pass: one such case includes constraints check during voltage selection in the call to regulator_check_voltage(), which can have -EINVAL for the case when an unsupported voltage is incorrectly requested. In that case, -22 is expected as the return value, not 0. Fixes: 9243a195 ("regulator: core: Change voltage setting path") Cc: stable <stable@vger.kernel.org> Signed-off-by:
Steve Twiss <stwiss.opensource@diasemi.com> Reviewed-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Ming Lei authored
commit c7e2d94b upstream. Once blk_cleanup_queue() returns, tags shouldn't be used any more, because blk_mq_free_tag_set() may be called. Commit 45a9c9d9 ("blk-mq: Fix a use-after-free") fixes this issue exactly. However, that commit introduces another issue. Before 45a9c9d9, we are allowed to run queue during cleaning up queue if the queue's kobj refcount is held. After that commit, queue can't be run during queue cleaning up, otherwise oops can be triggered easily because some fields of hctx are freed by blk_mq_free_queue() in blk_cleanup_queue(). We have invented ways for addressing this kind of issue before, such as: 8dc765d4 ("SCSI: fix queue cleanup race before queue initialization is done") c2856ae2 ("blk-mq: quiesce queue before freeing queue") But still can't cover all cases, recently James reports another such kind of issue: https://marc.info/?l=linux-scsi&m=155389088124782&w=2 This issue can be quite hard to address by previous way, given scsi_run_queue() may run requeues for other LUNs. Fixes the above issue by freeing hctx's resources in its release handler, and this way is safe becasue tags isn't needed for freeing such hctx resource. This approach follows typical design pattern wrt. kobject's release handler. Cc: Dongli Zhang <dongli.zhang@oracle.com> Cc: James Smart <james.smart@broadcom.com> Cc: Bart Van Assche <bart.vanassche@wdc.com> Cc: linux-scsi@vger.kernel.org, Cc: Martin K . Petersen <martin.petersen@oracle.com>, Cc: Christoph Hellwig <hch@lst.de>, Cc: James E . J . Bottomley <jejb@linux.vnet.ibm.com>, Reported-by:
James Smart <james.smart@broadcom.com> Fixes: 45a9c9d9 ("blk-mq: Fix a use-after-free") Cc: stable@vger.kernel.org Reviewed-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Ming Lei <ming.lei@redhat.com> Signed-off-by:
-
Saeed Mahameed authored
[ Upstream commit 8f0916c6 ] ethtool user spaces needs to know ring count via ETHTOOL_GRXRINGS when executing (ethtool -x) which is retrieved via ethtool get_rxnfc callback, in mlx5 this callback is disabled when CONFIG_MLX5_EN_RXNFC=n. This patch allows only ETHTOOL_GRXRINGS command on mlx5e_get_rxnfc() when CONFIG_MLX5_EN_RXNFC is disabled, so ethtool -x will continue working. Fixes: fe6d86b3 ("net/mlx5e: Add CONFIG_MLX5_EN_RXNFC for ethtool rx nfc") Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Saeed Mahameed authored
[ Upstream commit bad861f3 ] mlxfw can be compiled as external module while mlx5_core can be builtin, in such case mlx5 will act like mlxfw is disabled. Since mlxfw is just a service library for mlx* drivers, imply it in mlx5_core to make it always reachable if it was enabled. Fixes: 3ffaabec ("net/mlx5e: Support the flash device ethtool callback") Signed-off-by:
-
Dmytro Linkin authored
[ Upstream commit c979c445 ] Flow destination comparison has an inaccuracy: code see no difference between same vf ports, which belong to different pfs. Example: If start ping from VF0 (PF1) to VF1 (PF1) and mirror all traffic to VF0 (PF2), icmp reply to VF0 (PF1) and mirrored flow to VF0 (PF2) would be determined as same destination. It lead to creating flow handler with rule nodes, which not added to node tree. When later driver try to delete this flow rules we got kernel crash. Add comparison of vhca_id field to avoid this. Fixes: 1228e912 ("net/mlx5: Consider encapsulation properties when comparing destinations") Signed-off-by:
Dmytro Linkin <dmitrolin@mellanox.com> Reviewed-by:
Roi Dayan <roid@mellanox.com> Reviewed-by:
Vlad Buslov <vladbu@mellanox.com> Signed-off-by:
-
Dmytro Linkin authored
[ Upstream commit cf83c8fd ] For all representors added firmware version info to show in ethtool driver info. For uplink representor, because only it is tied to the pci device sysfs, added pci bus info. Fixes: ff9b85de ("net/mlx5e: Add some ethtool port control entries to the uplink rep netdev") Signed-off-by:
Gavi Teitz <gavi@mellanox.com> Reviewed-by:
-
Jorge E. Moreira authored
[ Upstream commit ba95e5df ] Avoid a race in which static variables in net/vmw_vsock/af_vsock.c are accessed (while handling interrupts) before they are initialized. [ 4.201410] BUG: unable to handle kernel paging request at ffffffffffffffe8 [ 4.207829] IP: vsock_addr_equals_addr+0x3/0x20 [ 4.211379] PGD 28210067 P4D 28210067 PUD 28212067 PMD 0 [ 4.211379] Oops: 0000 [#1] PREEMPT SMP PTI [ 4.211379] Modules linked in: [ 4.211379] CPU: 1 PID: 30 Comm: kworker/1:1 Not tainted 4.14.106-419297-gd7e28cc1f241 #1 [ 4.211379] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 4.211379] Workqueue: virtio_vsock virtio_transport_rx_work [ 4.211379] task: ffffa3273d175280 task.stack: ffffaea1800e8000 [ 4.211379] RIP: 0010:vsock_addr_equals_addr+0x3/0x20 [ 4.211379] RSP: 0000:ffffaea1800ebd28 EFLAGS: 00010286 [ 4.211379] RAX: 0000000000000002 RBX: 0000000000000000 RCX: ffffffffb94e42f0 [ 4.211379] RDX: 0000000000000400 RSI: ffffffffffffffe0 RDI: ffffaea1800ebdd0 [ 4.211379] RBP: ffffaea1800ebd58 R08: 0000000000000001 R09: 0000000000000001 [ 4.211379] R10: 0000000000000000 R11: ffffffffb89d5d60 R12: ffffaea1800ebdd0 [ 4.211379] R13: 00000000828cbfbf R14: 0000000000000000 R15: ffffaea1800ebdc0 [ 4.211379] FS: 0000000000000000(0000) GS:ffffa3273fd00000(0000) knlGS:0000000000000000 [ 4.211379] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4.211379] CR2: ffffffffffffffe8 CR3: 000000002820e001 CR4: 00000000001606e0 [ 4.211379] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4.211379] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4.211379] Call Trace: [ 4.211379] ? vsock_find_connected_socket+0x6c/0xe0 [ 4.211379] virtio_transport_recv_pkt+0x15f/0x740 [ 4.211379] ? detach_buf+0x1b5/0x210 [ 4.211379] virtio_transport_rx_work+0xb7/0x140 [ 4.211379] process_one_work+0x1ef/0x480 [ 4.211379] worker_thread+0x312/0x460 [ 4.211379] kthread+0x132/0x140 [ 4.211379] ? process_one_work+0x480/0x480 [ 4.211379] ? kthread_destroy_worker+0xd0/0xd0 [ 4.211379] ret_from_fork+0x35/0x40 [ 4.211379] Code: c7 47 08 00 00 00 00 66 c7 07 28 00 c7 47 08 ff ff ff ff c7 47 04 ff ff ff ff c3 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 8b 47 08 <3b> 46 08 75 0a 8b 47 04 3b 46 04 0f 94 c0 c3 31 c0 c3 90 66 2e [ 4.211379] RIP: vsock_addr_equals_addr+0x3/0x20 RSP: ffffaea1800ebd28 [ 4.211379] CR2: ffffffffffffffe8 [ 4.211379] ---[ end trace f31cc4a2e6df3689 ]--- [ 4.211379] Kernel panic - not syncing: Fatal exception in interrupt [ 4.211379] Kernel Offset: 0x37000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 4.211379] Rebooting in 5 seconds.. Fixes: 22b5c0b6 ("vsock/virtio: fix kernel panic after device hot-unplug") Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Stefano Garzarella <sgarzare@redhat.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: kvm@vger.kernel.org Cc: virtualization@lists.linux-foundation.org Cc: netdev@vger.kernel.org Cc: kernel-team@android.com Cc: stable@vger.kernel.org [4.9+] Signed-off-by:
Jorge E. Moreira <jemoreira@google.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com> Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Bodong Wang authored
[ Upstream commit dd064867 ] The command was mistakenly using enable_hca in embedded CPU field. Fixes: 22e939a9 (net/mlx5: Update enable HCA dependency) Signed-off-by:
Bodong Wang <bodong@mellanox.com> Reported-by:
Alex Rosenbaum <alexr@mellanox.com> Signed-off-by:
Daniel Jurgens <danielj@mellanox.com> Signed-off-by:
-
