- 30 11月, 2019 1 次提交
-
-
由 Harald Freudenberger 提交于
This patch introduces support for a new architectured reply code 0x8B indicating that a hypervisor layer (if any) has rejected an ap message. Linux may run as a guest on top of a hypervisor like zVM or KVM. So the crypto hardware seen by the ap bus may be restricted by the hypervisor for example only a subset like only clear key crypto requests may be supported. Other requests will be filtered out - rejected by the hypervisor. The new reply code 0x8B will appear in such cases and needs to get recognized by the ap bus and zcrypt device driver zoo. Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com> Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
-
- 23 11月, 2019 2 次提交
-
-
由 Lyude Paul 提交于
This reverts commit 68b9c5066e39af41d3448abfc887c77ce22dd64d. Ugh, I really dropped the ball on this one :\. So as it turns out RMI4 works perfectly fine on the X1 Extreme Gen 2 except for one thing I didn't notice because I usually use the trackpoint: clicking with the touchpad. Somehow this is broken, in fact we don't even seem to indicate BTN_LEFT as a valid event type for the RMI4 touchpad. And, I don't even see any RMI4 events coming from the touchpad when I press down on it. This only seems to work for PS/2 mode. Since that means we have a regression, and PS/2 mode seems to work fine for the time being - revert this for now. We'll have to do a more thorough investigation on this. Signed-off-by: NLyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20191119234534.10725-1-lyude@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hayes Wang 提交于
Call napi_disable() twice would cause dead lock. There are three situations may result in the issue. 1. rtl8152_pre_reset() and set_carrier() are run at the same time. 2. Call rtl8152_set_tunable() after rtl8152_close(). 3. Call rtl8152_set_ringparam() after rtl8152_close(). For #1, use the same solution as commit 84811412 ("r8152: Re-order napi_disable in rtl8152_close"). For #2 and #3, add checking the flag of IFF_UP and using napi_disable/napi_enable during mutex. Signed-off-by: NHayes Wang <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 22 11月, 2019 9 次提交
-
-
由 Pankaj Sharma 提交于
The function m_can_runtime_resume() is getting recursively called from m_can_class_resume(). This results in a lock up. We need not call m_can_class_resume() during m_can_runtime_resume(). Fixes: f524f829 ("can: m_can: Create a m_can platform framework") Signed-off-by: NPankaj Sharma <pankj.sharma@samsung.com> Signed-off-by: NSriram Dash <sriram.dash@samsung.com> Acked-by: NDan Murphy <dmurphy@ti.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Pankaj Sharma 提交于
The current code is failing during clock prepare enable because of not getting proper clock from platform device. [ 0.852089] Call trace: [ 0.854516] 0xffff0000fa22a668 [ 0.857638] clk_prepare+0x20/0x34 [ 0.861019] m_can_runtime_resume+0x2c/0xe4 [ 0.865180] pm_generic_runtime_resume+0x28/0x38 [ 0.869770] __rpm_callback+0x16c/0x1bc [ 0.873583] rpm_callback+0x24/0x78 [ 0.877050] rpm_resume+0x428/0x560 [ 0.880517] __pm_runtime_resume+0x7c/0xa8 [ 0.884593] m_can_clk_start.isra.9.part.10+0x1c/0xa8 [ 0.889618] m_can_class_register+0x138/0x370 [ 0.893950] m_can_plat_probe+0x120/0x170 [ 0.897939] platform_drv_probe+0x4c/0xa0 [ 0.901924] really_probe+0xd8/0x31c [ 0.905477] driver_probe_device+0x58/0xe8 [ 0.909551] device_driver_attach+0x68/0x70 [ 0.913711] __driver_attach+0x9c/0xf8 [ 0.917437] bus_for_each_dev+0x50/0xa0 [ 0.921251] driver_attach+0x20/0x28 [ 0.924804] bus_add_driver+0x148/0x1fc [ 0.928617] driver_register+0x6c/0x124 [ 0.932431] __platform_driver_register+0x48/0x50 [ 0.937113] m_can_plat_driver_init+0x18/0x20 [ 0.941446] do_one_initcall+0x4c/0x19c [ 0.945259] kernel_init_freeable+0x1d0/0x280 [ 0.949591] kernel_init+0x10/0x100 [ 0.953057] ret_from_fork+0x10/0x18 [ 0.956614] Code: 00000000 00000000 00000000 00000000 (fa22a668) [ 0.962681] ---[ end trace 881f71bd609de763 ]--- [ 0.967301] Kernel panic - not syncing: Attempted to kill init! A device driver for CAN controller hardware registers itself with the Linux network layer as a network device. So, the driver data for m_can should ideally be of type net_device. Fixes: f524f829 ("can: m_can: Create a m_can platform framework") Signed-off-by: NPankaj Sharma <pankj.sharma@samsung.com> Signed-off-by: NSriram Dash <sriram.dash@samsung.com> Acked-by: NDan Murphy <dmurphy@ti.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Haiyang Zhang 提交于
If negotiated NVSP version <= NVSP_PROTOCOL_VERSION_6, the offset may be wrong (too small) due to a host bug. This can cause missing the end of the send indirection table, and add multiple zero entries from leading zeros before the data region. This bug adds extra burden on channel 0. So fix the offset by computing it from the data structure sizes. This will ensure netvsc driver runs normally on unfixed hosts, and future fixed hosts. Fixes: 5b54dac8 ("hyperv: Add support for virtual Receive Side Scaling (vRSS)") Signed-off-by: NHaiyang Zhang <haiyangz@microsoft.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Haiyang Zhang 提交于
To reach the data region, the existing code adds offset in struct nvsp_5_send_indirect_table on the beginning of this struct. But the offset should be based on the beginning of its container, struct nvsp_message. This bug causes the first table entry missing, and adds an extra zero from the zero pad after the data region. This can put extra burden on the channel 0. So, correct the offset usage. Also add a boundary check to ensure not reading beyond data region. Fixes: 5b54dac8 ("hyperv: Add support for virtual Receive Side Scaling (vRSS)") Signed-off-by: NHaiyang Zhang <haiyangz@microsoft.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Martin Habets 提交于
The workqueue only exists for the primary PF. For other functions we hit a WARN_ON in kernel/workqueue.c. Fixes: 7c236c43 ("sfc: Add support for IEEE-1588 PTP") Signed-off-by: NMartin Habets <mhabets@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Oliver Neukum 提交于
If starting the transfer of a command suceeds but the transfer for the reply fails, it is not enough to initiate killing the transfer for the command may still be running. You need to wait for the killing to finish before you can reuse URB and buffer. Reported-and-tested-by: syzbot+711468aa5c3a1eabf863@syzkaller.appspotmail.com Signed-off-by: NOliver Neukum <oneukum@suse.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Navid Emamdoost 提交于
In nbd_add_socket when krealloc succeeds, if nsock's allocation fail the reallocted memory is leak. The correct behaviour should be assigning the reallocted memory to config->socks right after success. Reviewed-by: NJosef Bacik <josef@toxicpanda.com> Signed-off-by: NNavid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Akinobu Mita 提交于
This adds a new quirk NVME_QUIRK_NO_TEMP_THRESH_CHANGE to avoid changing the value of the temperature threshold feature for specific devices that show undesirable behavior. Guenter reported: "On my Intel NVME drive (SSDPEKKW512G7), writing any minimum limit on the Composite temperature sensor results in a temperature warning, and that warning is sticky until I reset the controller. It doesn't seem to matter which temperature I write; writing -273000 has the same result." The Intel NVMe has the latest firmware version installed, so this isn't a problem that was ever fixed. Reported-by: NGuenter Roeck <linux@roeck-us.net> Cc: Keith Busch <kbusch@kernel.org> Cc: Jens Axboe <axboe@fb.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Sagi Grimberg <sagi@grimberg.me> Cc: Jean Delvare <jdelvare@suse.com> Reviewed-by: NGuenter Roeck <linux@roeck-us.net> Tested-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com> Signed-off-by: NKeith Busch <kbusch@kernel.org>
-
由 Akinobu Mita 提交于
According to the NVMe specification, the over temperature threshold and under temperature threshold features shall be implemented for Composite Temperature if a non-zero WCTEMP field value is reported in the Identify Controller data structure. The features are also implemented for all implemented temperature sensors (i.e., all Temperature Sensor fields that report a non-zero value). This provides the over temperature threshold and under temperature threshold for each sensor as temperature min and max values of hwmon sysfs attributes. The WCTEMP is already provided as a temperature max value for Composite Temperature, but this change isn't incompatible. Because the default value of the over temperature threshold for Composite Temperature is the WCTEMP. Now the alarm attribute for Composite Temperature indicates one of the temperature is outside of a temperature threshold. Because there is only a single bit in Critical Warning field that indicates a temperature is outside of a threshold. Example output from the "sensors" command: nvme-pci-0100 Adapter: PCI adapter Composite: +33.9°C (low = -273.1°C, high = +69.8°C) (crit = +79.8°C) Sensor 1: +34.9°C (low = -273.1°C, high = +65261.8°C) Sensor 2: +31.9°C (low = -273.1°C, high = +65261.8°C) Sensor 5: +47.9°C (low = -273.1°C, high = +65261.8°C) This also adds helper macros for kelvin from/to milli Celsius conversion, and replaces the repeated code in hwmon.c. Cc: Keith Busch <kbusch@kernel.org> Cc: Jens Axboe <axboe@fb.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Sagi Grimberg <sagi@grimberg.me> Cc: Jean Delvare <jdelvare@suse.com> Reviewed-by: NGuenter Roeck <linux@roeck-us.net> Tested-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com> Signed-off-by: NKeith Busch <kbusch@kernel.org>
-
- 21 11月, 2019 27 次提交
-
-
由 Chris Wilson 提交于
fbdev uses the physical address of our framebuffer for its fb_mmap() routine. While we need to adapt this address for the new io BAR, we have to fix v5.4 first! The simplest fix is to restore the smem back to v5.3 and we will then probably have to implement our fbops->fb_mmap() callback to handle local memory. Reported-by: NNeil MacLeod <freedesktop@nmacleod.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112256 Fixes: 5f889b9a ("drm/i915: Disregard drm_mode_config.fb_base") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Tested-by: NNeil MacLeod <freedesktop@nmacleod.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191113180633.3947-1-chris@chris-wilson.co.uk (cherry picked from commit abc55207) Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit 9faf5fa4) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Alex Deucher 提交于
This reverts commit 1c425915. S/G display is not stable with the IOMMU enabled on some platforms. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205523Acked-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
There are still combinations of sbios and firmware that are not stable. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=204689Acked-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
When gfxoff is enabled, accessing gfx registers via MMIO can lead to a hang. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205497Acked-by: NXiaojie Yuan <xiaojie.yuan@amd.com> Reviewed-by: NEvan Quan <evan.quan@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Evan Quan 提交于
For fine grained dpm, there is only two levels supported. However to reflect correctly the current clock frequency, there is an intermediate level faked. Thus on forcing level setting, we need to treat level 2 correctly as level 1. Signed-off-by: NEvan Quan <evan.quan@amd.com> Reviewed-by: NKevin Wang <kevin1.wang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Evan Quan 提交于
Otherwise, the error message prompted will confuse user. Signed-off-by: NEvan Quan <evan.quan@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
5.4 and newer works fine with navi14. Reviewed-by: NXiaojie Yuan <xiaojie.yuan@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Mike Snitzer 提交于
This reverts commit a1b89132. Revert required hand-patching due to subsequent changes that were applied since commit a1b89132. Requires: ed0302e8 ("dm crypt: make workqueue names device-specific") Cc: stable@vger.kernel.org Bug: https://bugzilla.kernel.org/show_bug.cgi?id=199857Reported-by: NVito Caputo <vcaputo@pengaru.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com>
-
由 Prashant Malani 提交于
Both rtl_work_func_t() and rtl8152_close() call napi_disable(). Since the two calls aren't protected by a lock, if the close function starts executing before the work function, we can get into a situation where the napi_disable() function is called twice in succession (first by rtl8152_close(), then by set_carrier()). In such a situation, the second call would loop indefinitely, since rtl8152_close() doesn't call napi_enable() to clear the NAPI_STATE_SCHED bit. The rtl8152_close() function in turn issues a cancel_delayed_work_sync(), and so it would wait indefinitely for the rtl_work_func_t() to complete. Since rtl8152_close() is called by a process holding rtnl_lock() which is requested by other processes, this eventually leads to a system deadlock and crash. Re-order the napi_disable() call to occur after the work function disabling and urb cancellation calls are issued. Change-Id: I6ef0b703fc214998a037a68f722f784e1d07815e Reported-by: http://crbug.com/1017928Signed-off-by: NPrashant Malani <pmalani@chromium.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Stefan Wahren 提交于
The reset counter is specific for every QCA700x chip. So move this into the private driver struct. Otherwise we get unpredictable reset behavior in setups with multiple QCA700x chips. Fixes: 291ab06e (net: qualcomm: new Ethernet over SPI driver for QCA7000) Signed-off-by: NStefan Wahren <stefan.wahren@in-tech.com> Signed-off-by: NStefan Wahren <wahrenst@gmx.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Heimpold 提交于
When receiving many or larger packets, e.g. when doing a file download, it was observed that the read buffer size register reports up to 4 bytes more than the current define allows in the check. If this is the case, then no data transfer is initiated to receive the packets (and thus to empty the buffer) which results in a stall of the interface. These 4 bytes are a hardware generated frame length which is prepended to the actual frame, thus we have to respect it during our check. Fixes: 026b907d ("net: qca_spi: Add available buffer space verification") Signed-off-by: NMichael Heimpold <michael.heimpold@in-tech.com> Signed-off-by: NStefan Wahren <wahrenst@gmx.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Juliet Kim 提交于
Reversion of commit 11d49ce9 (“net/ibmvnic: Fix EOI when running in XIVE mode.”) leaves us calling H_EOI even in XIVE mode. That will fail with H_FUNCTION because H_EOI is not supported in that mode. That failure is harmless. Ignore it so we can use common code for both XICS and XIVE. Signed-off-by: NJuliet Kim <julietk@linux.vnet.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Juliet Kim 提交于
This reverts commit 11d49ce9 (“net/ibmvnic: Fix EOI when running in XIVE mode.”) since that has the unintended effect of changing the interrupt priority and emits warning when running in legacy XICS mode. Signed-off-by: NJuliet Kim <julietk@linux.vnet.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eran Ben Elisha 提交于
Array mlxfw_fsm_state_err_str contains value to string translation, when values are provided by mlxfw_dev. If value is larger than MLXFW_FSM_STATE_ERR_MAX, return "unknown error" as expected instead of reading an address than exceed array size. Fixes: 410ed13c ("Add the mlxfw module for Mellanox firmware flash process") Signed-off-by: NEran Ben Elisha <eranbe@mellanox.com> Acked-by: NJiri Pirko <jiri@mellanox.com> Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
-
由 Shani Shapp 提交于
Add the upcoming ConnectX-6 LX device ID. Fixes: 85327a9c ("net/mlx5: Update the list of the PCI supported devices") Signed-off-by: NShani Shapp <shanish@mellanox.com> Reviewed-by: NEran Ben Elisha <eranbe@mellanox.com> Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
-
由 Maor Gottlieb 提交于
Once all the large flow groups (defined by the user when the flow table is created - max_num_groups) were created, then all the following new flow groups will have only one flow table entry, even though the flow table has place to larger groups. Fix the condition to prefer large flow group. Fixes: f0d22d18 ("net/mlx5_core: Introduce flow steering autogrouped flow table") Signed-off-by: NMaor Gottlieb <maorg@mellanox.com> Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
-
由 Marina Varshaver 提交于
Device that doesn't support IP-in-IP offloads has to filter csum and gso offload support, otherwise kernel will conclude that device is capable of offloading csum and gso for IP-in-IP tunnels and that might result in IP-in-IP tunnel not functioning. Fixes: 25948b87 ("net/mlx5e: Support TSO and TX checksum offloads for IP-in-IP") Signed-off-by: NMarina Varshaver <marinav@mellanox.com> Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
-
由 Eran Ben Elisha 提交于
On some old Firmwares, connector type value was not supported, and value read from FW was 0. For those, driver used link mode in order to set connector type in link_ksetting. After FW exposed the connector type, driver translated the value to ethtool definitions. However, as 0 is a valid value, before returning PORT_OTHER, driver run the check of link mode in order to maintain backward compatibility. Cited patch added support to EXT mode. With both features (connector type and EXT link modes) ,if connector_type read from FW is 0 and EXT mode is set, driver mistakenly compare EXT link modes to non-EXT link mode. Fixed that by skipping this comparison if we are in EXT mode, as connector type value is valid in this scenario. Fixes: 6a897372 ("net/mlx5: ethtool, Add ethtool support for 50Gbps per lane link modes") Signed-off-by: NEran Ben Elisha <eranbe@mellanox.com> Reviewed-by: NAya Levin <ayal@mellanox.com> Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
-
由 Roi Dayan 提交于
Before this commit the ndo always returned success. Fix that. Fixes: 1ab2068a ("net/mlx5: Implement vports admin state backup/restore") Signed-off-by: NRoi Dayan <roid@mellanox.com> Reviewed-by: NVlad Buslov <vladbu@mellanox.com> Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
-
由 Alex Vesker 提交于
When an ste hash table has too many collision we enlarge it to a bigger hash table (rehash). Rehashing collision improvement depends on the bytemask value. The more 1 bits we have in bytemask means better spreading in the table. Without this fix tables can grow in size without providing any improvement which can lead to memory depletion and failures. This patch will limit table rehash to reduce memory and improve the performance. Fixes: 41d07074 ("net/mlx5: DR, Expose steering rule functionality") Signed-off-by: NAlex Vesker <valex@mellanox.com> Reviewed-by: NErez Shitrit <erezsh@mellanox.com> Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
-
由 Alex Vesker 提交于
The byte mask fields affect on the hash index distribution, when the byte mask is zero, the hash calculation will always be equal to the same index. To avoid unneeded rehash of hash tables mark the table to skip rehash. This is needed by the next patch which will limit table rehash to reduce memory consumption. Fixes: 41d07074 ("net/mlx5: DR, Expose steering rule functionality") Signed-off-by: NAlex Vesker <valex@mellanox.com> Reviewed-by: NErez Shitrit <erezsh@mellanox.com> Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
-
由 Alex Vesker 提交于
When creating a CQ, the CPU id is used for the vector value. This would fail in-case the CPU id was higher than the maximum vector value. Fixes: 297ccceb ("net/mlx5: DR, Expose an internal API to issue RDMA operations") Signed-off-by: NAlex Vesker <valex@mellanox.com> Reviewed-by: NTariq Toukan <tariqt@mellanox.com> Reviewed-by: NErez Shitrit <erezsh@mellanox.com> Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
-
由 Vlad Buslov 提交于
Mirred action parsing code in parse_tc_fdb_actions() first checks if out_dev has same parent id, and only verifies that there is a pending encap action that was parsed before. Recent change in vxlan module made function netdev_port_same_parent_id() to return true when called for mlx5 eswitch representor and vxlan device created explicitly on mlx5 representor device (vxlan devices created with "external" flag without explicitly specifying parent interface are not affected). With call to netdev_port_same_parent_id() returning true, incorrect code path is chosen and encap rules fail to offload because vxlan dev is not a valid eswitch forwarding dev. Dmesg log of error: [ 1784.389797] devices ens1f0_0 vxlan1 not on same switch HW, can't offload forwarding In order to fix the issue, rearrange conditional in parse_tc_fdb_actions() to check for pending encap action before checking if out_dev has the same parent id. Fixes: 0ce1822c ("vxlan: add adjacent link to limit depth level") Signed-off-by: NVlad Buslov <vladbu@mellanox.com> Reviewed-by: NRoi Dayan <roid@mellanox.com> Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
-
由 Eli Cohen 提交于
Current code uses the old method of prio encoding in flow_cls_common_offload. Fix to follow the changes introduced in commit ef01adae ("net: sched: use major priority number as hardware priority"). Fixes: fcb64c0f ("net/mlx5: E-Switch, add ingress rate support") Signed-off-by: NEli Cohen <eli@mellanox.com> Reviewed-by: NRoi Dayan <roid@mellanox.com> Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
-
由 Eli Cohen 提交于
Be sure to release the neighbour in case of failures after successful route lookup. Fixes: 101f4de9 ("net/mlx5e: Move TC tunnel offloading code to separate source file") Signed-off-by: NEli Cohen <eli@mellanox.com> Reviewed-by: NRoi Dayan <roid@mellanox.com> Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
-
由 Julian Wiedmann 提交于
When propagating IO errors back to userspace, one error path in qeth_irq() currently returns '1' instead of a proper errno. Fixes: 54daaca7 ("s390/qeth: cancel cmd on early error") Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Julian Wiedmann 提交于
The L2 bridgeport code uses the coarse 'conf_mutex' for guarding access to its configuration state. This can result in a deadlock when qeth_l2_stop_card() - called under the conf_mutex - blocks on flush_workqueue() to wait for the completion of pending bridgeport workers. Such workers would also need to aquire the conf_mutex, stalling indefinitely. Introduce a lock that specifically guards the bridgeport configuration, so that the workers no longer need the conf_mutex. Wrapping qeth_l2_promisc_to_bridge() in this fine-grained lock then also fixes a theoretical race against a concurrent qeth_bridge_port_role_store() operation. Fixes: c0a2e4d1 ("s390/qeth: conclude all event processing before offlining a card") Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com> Reviewed-by: NAlexandra Winter <wintera@linux.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 20 11月, 2019 1 次提交
-
-
由 Krzysztof Kozlowski 提交于
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org> Signed-off-by: NMike Snitzer <snitzer@redhat.com>
-