* [net-next 03/14] docs/networking: fix formatting of Intel drivers documentation
From: Jeff Kirsher @ 2019-02-06 2:04 UTC (permalink / raw)
To: davem; +Cc: Mike Rapoport, netdev, nhorman, sassmann, Jeff Kirsher
In-Reply-To: <20190206020424.12225-1-jeffrey.t.kirsher@intel.com>
From: Mike Rapoport <rppt@linux.ibm.com>
The documentation of Intel drivers is missing the heading adornment for
document titles.
This causes the generated html to have TOC entries from these documents to
appear as top level TOC entries:
* Linux* Base Driver for Intel(R) Ethernet Network Connection
* Contents
* Identifying Your Adapter
* Command Line Parameters
* AutoNeg
* Duplex
...
Add overline heading adornment to document titles.
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
Documentation/networking/device_drivers/intel/e100.rst | 1 +
Documentation/networking/device_drivers/intel/e1000.rst | 1 +
Documentation/networking/device_drivers/intel/e1000e.rst | 1 +
Documentation/networking/device_drivers/intel/fm10k.rst | 1 +
Documentation/networking/device_drivers/intel/i40e.rst | 1 +
Documentation/networking/device_drivers/intel/iavf.rst | 1 +
Documentation/networking/device_drivers/intel/ice.rst | 1 +
Documentation/networking/device_drivers/intel/igb.rst | 1 +
Documentation/networking/device_drivers/intel/igbvf.rst | 1 +
Documentation/networking/device_drivers/intel/ixgb.rst | 1 +
Documentation/networking/device_drivers/intel/ixgbe.rst | 1 +
Documentation/networking/device_drivers/intel/ixgbevf.rst | 1 +
12 files changed, 12 insertions(+)
diff --git a/Documentation/networking/device_drivers/intel/e100.rst b/Documentation/networking/device_drivers/intel/e100.rst
index 5e2839b4ec92..2b9f4887beda 100644
--- a/Documentation/networking/device_drivers/intel/e100.rst
+++ b/Documentation/networking/device_drivers/intel/e100.rst
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0+
+==============================================================
Linux* Base Driver for the Intel(R) PRO/100 Family of Adapters
==============================================================
diff --git a/Documentation/networking/device_drivers/intel/e1000.rst b/Documentation/networking/device_drivers/intel/e1000.rst
index 6379d4d20771..956560b6e745 100644
--- a/Documentation/networking/device_drivers/intel/e1000.rst
+++ b/Documentation/networking/device_drivers/intel/e1000.rst
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0+
+===========================================================
Linux* Base Driver for Intel(R) Ethernet Network Connection
===========================================================
diff --git a/Documentation/networking/device_drivers/intel/e1000e.rst b/Documentation/networking/device_drivers/intel/e1000e.rst
index 33554e5416c5..01999f05509c 100644
--- a/Documentation/networking/device_drivers/intel/e1000e.rst
+++ b/Documentation/networking/device_drivers/intel/e1000e.rst
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0+
+======================================================
Linux* Driver for Intel(R) Ethernet Network Connection
======================================================
diff --git a/Documentation/networking/device_drivers/intel/fm10k.rst b/Documentation/networking/device_drivers/intel/fm10k.rst
index bf5e5942f28d..ac3269e34f55 100644
--- a/Documentation/networking/device_drivers/intel/fm10k.rst
+++ b/Documentation/networking/device_drivers/intel/fm10k.rst
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0+
+==============================================================
Linux* Base Driver for Intel(R) Ethernet Multi-host Controller
==============================================================
diff --git a/Documentation/networking/device_drivers/intel/i40e.rst b/Documentation/networking/device_drivers/intel/i40e.rst
index 0cc16c525d10..848fd388fa6e 100644
--- a/Documentation/networking/device_drivers/intel/i40e.rst
+++ b/Documentation/networking/device_drivers/intel/i40e.rst
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0+
+==================================================================
Linux* Base Driver for the Intel(R) Ethernet Controller 700 Series
==================================================================
diff --git a/Documentation/networking/device_drivers/intel/iavf.rst b/Documentation/networking/device_drivers/intel/iavf.rst
index f8b42b64eb28..2d0c3baa1752 100644
--- a/Documentation/networking/device_drivers/intel/iavf.rst
+++ b/Documentation/networking/device_drivers/intel/iavf.rst
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0+
+==================================================================
Linux* Base Driver for Intel(R) Ethernet Adaptive Virtual Function
==================================================================
diff --git a/Documentation/networking/device_drivers/intel/ice.rst b/Documentation/networking/device_drivers/intel/ice.rst
index 4d118b827bbb..c220aa2711c6 100644
--- a/Documentation/networking/device_drivers/intel/ice.rst
+++ b/Documentation/networking/device_drivers/intel/ice.rst
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0+
+===================================================================
Linux* Base Driver for the Intel(R) Ethernet Connection E800 Series
===================================================================
diff --git a/Documentation/networking/device_drivers/intel/igb.rst b/Documentation/networking/device_drivers/intel/igb.rst
index e87a4a72ea2d..fc8cfaa5dcfa 100644
--- a/Documentation/networking/device_drivers/intel/igb.rst
+++ b/Documentation/networking/device_drivers/intel/igb.rst
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0+
+===========================================================
Linux* Base Driver for Intel(R) Ethernet Network Connection
===========================================================
diff --git a/Documentation/networking/device_drivers/intel/igbvf.rst b/Documentation/networking/device_drivers/intel/igbvf.rst
index a8a9ffa4f8d3..9cddabe8108e 100644
--- a/Documentation/networking/device_drivers/intel/igbvf.rst
+++ b/Documentation/networking/device_drivers/intel/igbvf.rst
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0+
+============================================================
Linux* Base Virtual Function Driver for Intel(R) 1G Ethernet
============================================================
diff --git a/Documentation/networking/device_drivers/intel/ixgb.rst b/Documentation/networking/device_drivers/intel/ixgb.rst
index 8bd80e27843d..945018207a92 100644
--- a/Documentation/networking/device_drivers/intel/ixgb.rst
+++ b/Documentation/networking/device_drivers/intel/ixgb.rst
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0+
+=====================================================================
Linux Base Driver for 10 Gigabit Intel(R) Ethernet Network Connection
=====================================================================
diff --git a/Documentation/networking/device_drivers/intel/ixgbe.rst b/Documentation/networking/device_drivers/intel/ixgbe.rst
index 86d887a63606..c7d25483fedb 100644
--- a/Documentation/networking/device_drivers/intel/ixgbe.rst
+++ b/Documentation/networking/device_drivers/intel/ixgbe.rst
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0+
+=============================================================================
Linux* Base Driver for the Intel(R) Ethernet 10 Gigabit PCI Express Adapters
=============================================================================
diff --git a/Documentation/networking/device_drivers/intel/ixgbevf.rst b/Documentation/networking/device_drivers/intel/ixgbevf.rst
index 56cde6366c2f..5d4977360157 100644
--- a/Documentation/networking/device_drivers/intel/ixgbevf.rst
+++ b/Documentation/networking/device_drivers/intel/ixgbevf.rst
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0+
+=============================================================
Linux* Base Virtual Function Driver for Intel(R) 10G Ethernet
=============================================================
--
2.20.1
^ permalink raw reply related
* [net-next 02/14] igc: Remove unreachable code from igc_phy.c file
From: Jeff Kirsher @ 2019-02-06 2:04 UTC (permalink / raw)
To: davem; +Cc: Sasha Neftin, netdev, nhorman, sassmann, Aaron Brown,
Jeff Kirsher
In-Reply-To: <20190206020424.12225-1-jeffrey.t.kirsher@intel.com>
From: Sasha Neftin <sasha.neftin@intel.com>
Address community comment.
Remove the unreachable code leads to the static checker warning.
PHY functionality will be added later per demand.
Reported by Dan Carpenter.
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igc/igc_phy.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_phy.c b/drivers/net/ethernet/intel/igc/igc_phy.c
index 38e43e6fc1c7..4c8f96a9a148 100644
--- a/drivers/net/ethernet/intel/igc/igc_phy.c
+++ b/drivers/net/ethernet/intel/igc/igc_phy.c
@@ -152,7 +152,6 @@ void igc_power_down_phy_copper(struct igc_hw *hw)
s32 igc_check_downshift(struct igc_hw *hw)
{
struct igc_phy_info *phy = &hw->phy;
- u16 phy_data, offset, mask;
s32 ret_val;
switch (phy->type) {
@@ -161,15 +160,8 @@ s32 igc_check_downshift(struct igc_hw *hw)
/* speed downshift not supported */
phy->speed_downgraded = false;
ret_val = 0;
- goto out;
}
- ret_val = phy->ops.read_reg(hw, offset, &phy_data);
-
- if (!ret_val)
- phy->speed_downgraded = (phy_data & mask) ? true : false;
-
-out:
return ret_val;
}
--
2.20.1
^ permalink raw reply related
* [net-next 09/14] igc: Remove unneeded code
From: Jeff Kirsher @ 2019-02-06 2:04 UTC (permalink / raw)
To: davem; +Cc: Sasha Neftin, netdev, nhorman, sassmann, Aaron Brown,
Jeff Kirsher
In-Reply-To: <20190206020424.12225-1-jeffrey.t.kirsher@intel.com>
From: Sasha Neftin <sasha.neftin@intel.com>
Remove the 'igc_get_link_up_info_base method' from igc_base.c file.
Use the 'igc_get_speed_and_duplex_copper' method directly and reduce
the code redundancy.
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igc/igc_base.c | 22 +---------------------
1 file changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_base.c b/drivers/net/ethernet/intel/igc/igc_base.c
index 19ff987922d2..a31ec1682090 100644
--- a/drivers/net/ethernet/intel/igc/igc_base.c
+++ b/drivers/net/ethernet/intel/igc/igc_base.c
@@ -333,26 +333,6 @@ static void igc_release_phy_base(struct igc_hw *hw)
hw->mac.ops.release_swfw_sync(hw, mask);
}
-/**
- * igc_get_link_up_info_base - Get link speed/duplex info
- * @hw: pointer to the HW structure
- * @speed: stores the current speed
- * @duplex: stores the current duplex
- *
- * This is a wrapper function, if using the serial gigabit media independent
- * interface, use PCS to retrieve the link speed and duplex information.
- * Otherwise, use the generic function to get the link speed and duplex info.
- */
-static s32 igc_get_link_up_info_base(struct igc_hw *hw, u16 *speed,
- u16 *duplex)
-{
- s32 ret_val;
-
- ret_val = igc_get_speed_and_duplex_copper(hw, speed, duplex);
-
- return ret_val;
-}
-
/**
* igc_init_hw_base - Initialize hardware
* @hw: pointer to the HW structure
@@ -499,7 +479,7 @@ static struct igc_mac_operations igc_mac_ops_base = {
.check_for_link = igc_check_for_copper_link,
.rar_set = igc_rar_set,
.read_mac_addr = igc_read_mac_addr_base,
- .get_speed_and_duplex = igc_get_link_up_info_base,
+ .get_speed_and_duplex = igc_get_speed_and_duplex_copper,
};
static const struct igc_phy_operations igc_phy_ops_base = {
--
2.20.1
^ permalink raw reply related
* [net-next 13/14] igb: Bump version number
From: Jeff Kirsher @ 2019-02-06 2:04 UTC (permalink / raw)
To: davem; +Cc: Todd Fujinaka, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190206020424.12225-1-jeffrey.t.kirsher@intel.com>
From: Todd Fujinaka <todd.fujinaka@intel.com>
With recent changes, need to bump the driver version to reflect the
changes.
Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index dfa357b1a9d6..d35cc9697e2d 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -39,7 +39,7 @@
#include "igb.h"
#define MAJ 5
-#define MIN 4
+#define MIN 6
#define BUILD 0
#define DRV_VERSION __stringify(MAJ) "." __stringify(MIN) "." \
__stringify(BUILD) "-k"
--
2.20.1
^ permalink raw reply related
* [net-next 10/14] e1000e: fix cyclic resets at link up with active tx
From: Jeff Kirsher @ 2019-02-06 2:04 UTC (permalink / raw)
To: davem
Cc: Konstantin Khlebnikov, netdev, nhorman, sassmann, Aaron Brown,
Jeff Kirsher
In-Reply-To: <20190206020424.12225-1-jeffrey.t.kirsher@intel.com>
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
I'm seeing series of e1000e resets (sometimes endless) at system boot
if something generates tx traffic at this time. In my case this is
netconsole who sends message "e1000e 0000:02:00.0: Some CPU C-states
have been disabled in order to enable jumbo frames" from e1000e itself.
As result e1000_watchdog_task sees used tx buffer while carrier is off
and start this reset cycle again.
[ 17.794359] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[ 17.794714] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 22.936455] e1000e 0000:02:00.0 eth1: changing MTU from 1500 to 9000
[ 23.033336] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 26.102364] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[ 27.174495] 8021q: 802.1Q VLAN Support v1.8
[ 27.174513] 8021q: adding VLAN 0 to HW filter on device eth1
[ 30.671724] cgroup: cgroup: disabling cgroup2 socket matching due to net_prio or net_cls activation
[ 30.898564] netpoll: netconsole: local port 6666
[ 30.898566] netpoll: netconsole: local IPv6 address 2a02:6b8:0:80b:beae:c5ff:fe28:23f8
[ 30.898567] netpoll: netconsole: interface 'eth1'
[ 30.898568] netpoll: netconsole: remote port 6666
[ 30.898568] netpoll: netconsole: remote IPv6 address 2a02:6b8:b000:605c:e61d:2dff:fe03:3790
[ 30.898569] netpoll: netconsole: remote ethernet address b0:a8:6e:f4:ff:c0
[ 30.917747] console [netcon0] enabled
[ 30.917749] netconsole: network logging started
[ 31.453353] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 34.185730] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 34.321840] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 34.465822] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 34.597423] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 34.745417] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 34.877356] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 35.005441] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 35.157376] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 35.289362] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 35.417441] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
[ 37.790342] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
This patch flushes tx buffers only once when carrier is off
rather than at each watchdog iteration.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index e19e53d97ac5..736fa51878f8 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5309,8 +5309,13 @@ static void e1000_watchdog_task(struct work_struct *work)
/* 8000ES2LAN requires a Rx packet buffer work-around
* on link down event; reset the controller to flush
* the Rx packet buffer.
+ *
+ * If the link is lost the controller stops DMA, but
+ * if there is queued Tx work it cannot be done. So
+ * reset the controller to flush the Tx packet buffers.
*/
- if (adapter->flags & FLAG_RX_NEEDS_RESTART)
+ if ((adapter->flags & FLAG_RX_NEEDS_RESTART) ||
+ e1000_desc_unused(tx_ring) + 1 < tx_ring->count)
adapter->flags |= FLAG_RESTART_NOW;
else
pm_schedule_suspend(netdev->dev.parent,
@@ -5333,14 +5338,6 @@ static void e1000_watchdog_task(struct work_struct *work)
adapter->gotc_old = adapter->stats.gotc;
spin_unlock(&adapter->stats64_lock);
- /* If the link is lost the controller stops DMA, but
- * if there is queued Tx work it cannot be done. So
- * reset the controller to flush the Tx packet buffers.
- */
- if (!netif_carrier_ok(netdev) &&
- (e1000_desc_unused(tx_ring) + 1 < tx_ring->count))
- adapter->flags |= FLAG_RESTART_NOW;
-
/* If reset is necessary, do it outside of interrupt context. */
if (adapter->flags & FLAG_RESTART_NOW) {
schedule_work(&adapter->reset_task);
--
2.20.1
^ permalink raw reply related
* [net-next 06/14] fm10k: TRIVIAL cleanup of extra spacing in function comment
From: Jeff Kirsher @ 2019-02-06 2:04 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190206020424.12225-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
The function comment for fm10k_iov_msg_msix_pf has an extra space in
a sentence, which is unnecessary.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pf.c b/drivers/net/ethernet/intel/fm10k/fm10k_pf.c
index 8f0a99b6a537..cb4d02629b86 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_pf.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_pf.c
@@ -1148,7 +1148,7 @@ static void fm10k_iov_update_stats_pf(struct fm10k_hw *hw,
* @results: Pointer array to message, results[0] is pointer to message
* @mbx: Pointer to mailbox information structure
*
- * This function is a default handler for MSI-X requests from the VF. The
+ * This function is a default handler for MSI-X requests from the VF. The
* assumption is that in this case it is acceptable to just directly
* hand off the message from the VF to the underlying shared code.
**/
--
2.20.1
^ permalink raw reply related
* [net-next 00/14][pull request] Intel Wired LAN Driver Updates 2019-02-05
From: Jeff Kirsher @ 2019-02-06 2:04 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann
This series contains updates to igc, e1000e, ixgbe, fm10k and driver
documentation.
Kai-Heng Feng fixes an e1000e issue where the Wake-On-LAN settings where
being set incorrectly during a system suspend.
Sasha addresses community feedback on the igc driver and provides a
number of code cleanups to remove either unreachable or unused code. In
addition, added basic ethtool support for the igc driver.
Mike Rapoport fixes the formatting of the kernel driver documentation so
that the title is properly formatted and does not get lumped with the
document sections in the HTML kernel documents generated.
Jiri Kosina updates a hard coded RAR entries value with the existing
define IXGBE_82599_RAR_ENTRIES.
Jake fixes up whitespace in the fm10k driver.
Konstantin Khlebnikov fixes an issue where in some cases, the e1000e
driver will continually reset during a system boot because the watchdog
task sees items in the transmit buffer but the carrier is off (trying to
establish link) causing the device reset to flush the buffer. To
resolve, just move this check/flush into the watchdog section for when
the carrier is off.
Todd bumps the igb driver version to reflect the recent driver changes.
The following are changes since commit bf2fa12593c2bb77c7ab84254ac69af429d6719b:
net: marvell: mvpp2: fix lack of link interrupts
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 1GbE
Jacob Keller (1):
fm10k: TRIVIAL cleanup of extra spacing in function comment
Jeff Kirsher (1):
e1000e: fix a missing check for return value
Jiri Kosina (1):
ixgbe: remove magic constant in ixgbe_reset_hw_82599()
Kai-Heng Feng (1):
e1000e: Exclude device from suspend direct complete optimization
Konstantin Khlebnikov (1):
e1000e: fix cyclic resets at link up with active tx
Mike Rapoport (1):
docs/networking: fix formatting of Intel drivers documentation
Sasha Neftin (7):
igc: Remove unreachable code from igc_phy.c file
igc: Fix code redundancy
igc: Remove unused code
igc: Remove unneeded code
igc: Remove the 'igc_read_mac_addr_base' method
igc: Remove the 'igc_get_phy_id_base' method
igc: Add ethtool support
Todd Fujinaka (1):
igb: Bump version number
.../networking/device_drivers/intel/e100.rst | 1 +
.../networking/device_drivers/intel/e1000.rst | 1 +
.../device_drivers/intel/e1000e.rst | 1 +
.../networking/device_drivers/intel/fm10k.rst | 1 +
.../networking/device_drivers/intel/i40e.rst | 1 +
.../networking/device_drivers/intel/iavf.rst | 1 +
.../networking/device_drivers/intel/ice.rst | 1 +
.../networking/device_drivers/intel/igb.rst | 1 +
.../networking/device_drivers/intel/igbvf.rst | 1 +
.../networking/device_drivers/intel/ixgb.rst | 1 +
.../networking/device_drivers/intel/ixgbe.rst | 1 +
.../device_drivers/intel/ixgbevf.rst | 1 +
.../net/ethernet/intel/e1000e/80003es2lan.c | 33 +-
drivers/net/ethernet/intel/e1000e/netdev.c | 17 +-
drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 2 +-
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
drivers/net/ethernet/intel/igc/Makefile | 3 +-
drivers/net/ethernet/intel/igc/igc.h | 34 +-
drivers/net/ethernet/intel/igc/igc_base.c | 76 +-
drivers/net/ethernet/intel/igc/igc_base.h | 25 -
drivers/net/ethernet/intel/igc/igc_defines.h | 4 +
drivers/net/ethernet/intel/igc/igc_ethtool.c | 1032 +++++++++++++++++
drivers/net/ethernet/intel/igc/igc_hw.h | 1 +
drivers/net/ethernet/intel/igc/igc_main.c | 109 +-
drivers/net/ethernet/intel/igc/igc_phy.c | 8 -
drivers/net/ethernet/intel/igc/igc_regs.h | 4 +-
.../net/ethernet/intel/ixgbe/ixgbe_82599.c | 2 +-
27 files changed, 1220 insertions(+), 144 deletions(-)
create mode 100644 drivers/net/ethernet/intel/igc/igc_ethtool.c
--
2.20.1
^ permalink raw reply
* [net-next 01/14] e1000e: Exclude device from suspend direct complete optimization
From: Jeff Kirsher @ 2019-02-06 2:04 UTC (permalink / raw)
To: davem; +Cc: Kai-Heng Feng, netdev, nhorman, sassmann, Aaron Brown,
Jeff Kirsher
In-Reply-To: <20190206020424.12225-1-jeffrey.t.kirsher@intel.com>
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
e1000e sets different WoL settings in system suspend callback and
runtime suspend callback.
The suspend direct complete optimization leaves e1000e in runtime
suspended state with wrong WoL setting during system suspend.
To fix this, we need to disable suspend direct complete optimization to
let e1000e always use suspend callback to set correct WoL during system
suspend.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 189f231075c2..e19e53d97ac5 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -7351,6 +7351,8 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
e1000_print_device_info(adapter);
+ dev_pm_set_driver_flags(&pdev->dev, DPM_FLAG_NEVER_SKIP);
+
if (pci_dev_run_wake(pdev))
pm_runtime_put_noidle(&pdev->dev);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 2/2 net-next] net: phy: make use of new MMD accessors
From: Andrew Lunn @ 2019-02-06 2:10 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Florian Fainelli, David Miller, Russell King,
netdev@vger.kernel.org, Nikita Yushchenko
In-Reply-To: <d26db84c-b7e1-0e3e-7461-db7b0a548500@gmail.com>
On Tue, Feb 05, 2019 at 10:13:07PM +0100, Heiner Kallweit wrote:
> Make use of the new MMD accessors.
>
> Andrew Lunn <andrew@lunn.ch>
This is missing the Signed-off-by: prefix.
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: TC stats / hw offload question
From: Jamal Hadi Salim @ 2019-02-06 2:20 UTC (permalink / raw)
To: Edward Cree, netdev; +Cc: Jiri Pirko, Cong Wang
In-Reply-To: <26f0cfc9-3bef-8579-72cc-aa6c5ccecd43@solarflare.com>
On 2019-02-05 2:41 p.m., Edward Cree wrote:
> Regarding TC_CLSFLOWER_STATS, when a filter rule modifies the length of
> the packet, e.g. by adding a VLAN or encap header, should the bytes
> counter count the length of the packet _before_ edits (i.e. as seen by
> the match), or the length after edits?
Classifier stats - when they exist - should be on
"classified" packets. i.e before edits.
Edits are typically done by actions. And even then we dont
have counters which indicate the post edit resizing.
> If the latter, what is the
> correct behaviour when (say) a packet is mirrored as-is but also
> redirected with encapsulation?
It is that ambiguity that make it hard to maintain a single
counter for post-edit size. packet and byte counts are on
"entry".
> The fact that the stats live in the struct tc_action suggests a per-
> action connection that would imply post-edit length,
The classifiers dont mod the packets. The actions do. And they
maintain stats on the size on "entry" i.e pre-edit.
> but then in
> tcf_exts_dump_stats() we only look at the first action, which seems to
> imply we really want the pre-edit length.
> I can't find any kind of doc or spec defining what behaviour is required.
>
Each action keeps its own counters. If you did something like:
tc match using flower blah \
action vlan push tag ... \
action redirect to egress of eth0
And you submited a packet of size x bytes,
then the "match" would record x bytes.
the "vlan action" would record x bytes.
the "redirect" would record size x+vlaninfo bytes
the egress of eth0 would recorr x+vlaninfo bytes
cheers,
jamal
> -Ed
>
^ permalink raw reply
* Re: [PATCH bpf-next 2/2] tools/bpf: add log_level to bpf_load_program_attr
From: Alexei Starovoitov @ 2019-02-06 2:26 UTC (permalink / raw)
To: Yonghong Song; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20190205194823.1805324-1-yhs@fb.com>
On Tue, Feb 05, 2019 at 11:48:23AM -0800, Yonghong Song wrote:
> The kernel verifier has three levels of logs:
> 0: no logs
> 1: logs mostly useful
> > 1: verbose
>
> Current libbpf API functions bpf_load_program_xattr() and
> bpf_load_program() cannot specify log_level.
> The bcc, however, provides an interface for user to
> specify log_level 2 for verbose output.
>
> This patch added log_level into structure
> bpf_load_program_attr, so users, including bcc, can use
> bpf_load_program_xattr() to change log_level.
>
> The bpf selftest test_sock.c is modified to enable log_level = 2.
> If the "verbose" in test_sock.c is changed to true,
> the test will output logs like below:
> $ ./test_sock
> func#0 @0
> 0: R1=ctx(id=0,off=0,imm=0) R10=fp0,call_-1
> 0: (bf) r6 = r1
> 1: R1=ctx(id=0,off=0,imm=0) R6_w=ctx(id=0,off=0,imm=0) R10=fp0,call_-1
> 1: (61) r7 = *(u32 *)(r6 +28)
> invalid bpf_context access off=28 size=4
>
> Test case: bind4 load with invalid access: src_ip6 .. [PASS]
> ...
> Test case: bind6 allow all .. [PASS]
> Summary: 16 PASSED, 0 FAILED
>
> Some test_sock tests are negative tests and verbose verifier
> log will be printed out as shown in the above.
>
> Signed-off-by: Yonghong Song <yhs@fb.com>
> ---
> tools/lib/bpf/bpf.c | 4 +++-
> tools/lib/bpf/bpf.h | 1 +
> tools/testing/selftests/bpf/test_sock.c | 9 ++++++++-
> 3 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 3defad77dc7a..78aa8c2b1a5c 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -214,6 +214,7 @@ int bpf_load_program_xattr(const struct bpf_load_program_attr *load_attr,
> {
> void *finfo = NULL, *linfo = NULL;
> union bpf_attr attr;
> + __u32 log_level;
> __u32 name_len;
> int fd;
>
> @@ -292,7 +293,8 @@ int bpf_load_program_xattr(const struct bpf_load_program_attr *load_attr,
> /* Try again with log */
> attr.log_buf = ptr_to_u64(log_buf);
> attr.log_size = log_buf_sz;
> - attr.log_level = 1;
> + log_level = load_attr->log_level;
> + attr.log_level = (log_level >= 2) ? log_level : 1;
> log_buf[0] = 0;
> fd = sys_bpf_prog_load(&attr, sizeof(attr));
> done:
> diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
> index ed09eed2dc3b..15a8e22e8eae 100644
> --- a/tools/lib/bpf/bpf.h
> +++ b/tools/lib/bpf/bpf.h
> @@ -76,6 +76,7 @@ struct bpf_load_program_attr {
> const struct bpf_insn *insns;
> size_t insns_cnt;
> const char *license;
> + __u32 log_level;
> __u32 kern_version;
> __u32 prog_ifindex;
> __u32 prog_btf_fd;
this will break binary compatibility in libbpf api.
Please add new fields always to the end of *_attr structs.
Also why not to silence bcc instead?
Let it treat log_level > 1 as log_level=1
I don't think anyone but the most extreme verifier hacker used level=2.
Personally I don't remember when was the last time I used it.
It seem like a niche feature that we can safely remove in bcc.
^ permalink raw reply
* Re: [PATCH bpf-next 1/2] tools/bpf: add const qualifier to btf__get_map_kv_tids() map_name parameter
From: Alexei Starovoitov @ 2019-02-06 2:27 UTC (permalink / raw)
To: Yonghong Song; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20190205194822.1804874-1-yhs@fb.com>
On Tue, Feb 05, 2019 at 11:48:22AM -0800, Yonghong Song wrote:
> Commit 96408c43447a ("tools/bpf: implement libbpf btf__get_map_kv_tids() API function")
> added the API function btf__get_map_kv_tids():
> btf__get_map_kv_tids(const struct btf *btf, char *map_name, ...)
>
> The parameter map_name has type "char *". This is okay inside libbpf library since
> the map_name is from bpf_map->name which also has type "char *".
>
> This will be problematic if the caller for map_name already has attribute "const",
> e.g., from C++ string.c_str(). It will result in either a warning or an error.
>
> /home/yhs/work/bcc/src/cc/btf.cc:166:51:
> error: invalid conversion from ‘const char*’ to ‘char*’ [-fpermissive]
> return btf__get_map_kv_tids(btf_, map_name.c_str()
>
> This patch added "const" attributes to map_name parameter.
>
> Fixes: 96408c43447a ("tools/bpf: implement libbpf btf__get_map_kv_tids() API function")
> Signed-off-by: Yonghong Song <yhs@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [PATCH bpf-next] tools/bpf: fix a selftest test_btf failure
From: Alexei Starovoitov @ 2019-02-06 2:36 UTC (permalink / raw)
To: Yonghong Song
Cc: Andrii Nakryiko, netdev, Alexei Starovoitov, Daniel Borkmann,
kernel-team
In-Reply-To: <20190205222844.2425372-1-yhs@fb.com>
On Tue, Feb 05, 2019 at 02:28:44PM -0800, Yonghong Song wrote:
> Commit 9c651127445c ("selftests/btf: add initial BTF dedup tests")
> added dedup tests in test_btf.c.
> It broke the raw test:
> BTF raw test[71] (func proto (Bad arg name_off)):
> btf_raw_create:2905:FAIL Error getting string #65535, strs_cnt:1
>
> The test itself encodes invalid func_proto parameter name
> offset 0xffffFFFF as a negative test for the kernel.
> The above commit changed the meaning of that offset and
> resulted in a user space error.
> #define NAME_NTH(N) (0xffff0000 | N)
> #define IS_NAME_NTH(X) ((X & 0xffff0000) == 0xffff0000)
> #define GET_NAME_NTH_IDX(X) (X & 0x0000ffff)
>
> Currently, the kernel permits maximum name offset 0xffff.
> Set the test name off as 0x0fffFFFF to trigger the kernel
> verification failure.
>
> Cc: Andrii Nakryiko <andriin@fb.com>
> Fixes: 9c651127445c ("selftests/btf: add initial BTF dedup tests")
> Signed-off-by: Yonghong Song <yhs@fb.com>
Applied, Thanks
Also I see the following new error in test_btf:
BTF libbpf test[2] (test_btf_nokv.o): libbpf: map:btf_map container_name:____btf_map_btf_map cannot be found in BTF. Missing BPF_ANNOTATE_KV_PAIR?
OK
A bunch of similar errors are in test_progs as well.
I suspect it's related to the last few btf changes.
Andrii, Yonghong, Please investigate.
^ permalink raw reply
* Re: [PATCH bpf-next 1/2] tools/bpf: add const qualifier to btf__get_map_kv_tids() map_name parameter
From: Alexei Starovoitov @ 2019-02-06 2:41 UTC (permalink / raw)
To: Yonghong Song
Cc: Network Development, Alexei Starovoitov, Daniel Borkmann,
Kernel Team
In-Reply-To: <20190206022704.eu5dh6a5fxzzxy3i@ast-mbp>
On Tue, Feb 5, 2019 at 6:27 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Feb 05, 2019 at 11:48:22AM -0800, Yonghong Song wrote:
> > Commit 96408c43447a ("tools/bpf: implement libbpf btf__get_map_kv_tids() API function")
> > added the API function btf__get_map_kv_tids():
> > btf__get_map_kv_tids(const struct btf *btf, char *map_name, ...)
> >
> > The parameter map_name has type "char *". This is okay inside libbpf library since
> > the map_name is from bpf_map->name which also has type "char *".
> >
> > This will be problematic if the caller for map_name already has attribute "const",
> > e.g., from C++ string.c_str(). It will result in either a warning or an error.
> >
> > /home/yhs/work/bcc/src/cc/btf.cc:166:51:
> > error: invalid conversion from ‘const char*’ to ‘char*’ [-fpermissive]
> > return btf__get_map_kv_tids(btf_, map_name.c_str()
> >
> > This patch added "const" attributes to map_name parameter.
> >
> > Fixes: 96408c43447a ("tools/bpf: implement libbpf btf__get_map_kv_tids() API function")
> > Signed-off-by: Yonghong Song <yhs@fb.com>
>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Actually just applied this patch alone,
since it's independent from 2nd.
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/2] btf: separate btf creation and loading
From: Alexei Starovoitov @ 2019-02-06 3:03 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: songliubraving, yhs, ast, kafai, netdev, daniel, andrii.nakryiko
In-Reply-To: <20190206002949.1915237-2-andriin@fb.com>
On Tue, Feb 05, 2019 at 04:29:48PM -0800, Andrii Nakryiko wrote:
> This change splits out previous btf__new functionality of constructing
> struct btf and loading it into kernel into two:
> - btf__new() just creates and initializes struct btf
> - btf__load() attempts to load existing struct btf into kernel
>
> btf__free will still close BTF fd, if it was ever loaded successfully
> into kernel.
>
> This change allows users of libbpf to manipulate BTF using its API,
> without the need to unnecessarily load it into kernel.
>
> One of the intended use cases is pahole using libbpf to do DWARF to BTF
> conversion and deduplication using libbpf, while handling ELF sections
> overwrites and other concerns on its own.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> Acked-by: Song Liu <songliubraving@fb.com>
should it be
Fixes: 2d3feca8c44f ("bpf: btf: print map dump and lookup with btf info")
?
Even back then btf__new() was doing the loading.
So that btf support in bpftool was silently double loading btf.
^ permalink raw reply
* Re: [PATCH v2 bpf-next 2/2] btf: expose API to work with raw btf data
From: Alexei Starovoitov @ 2019-02-06 3:07 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: songliubraving, yhs, ast, kafai, netdev, andrii.nakryiko, daniel
In-Reply-To: <20190206002949.1915237-3-andriin@fb.com>
On Tue, Feb 05, 2019 at 04:29:49PM -0800, Andrii Nakryiko wrote:
> This patch exposes two new APIs btf__get_raw_data_size() and
> btf__get_raw_data() that allows to get a copy of raw BTF data out of
> struct btf. This is useful for external programs that need to manipulate
> raw data, e.g., pahole using btf__dedup() to deduplicate BTF type info
> and then writing it back to file.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> Acked-by: Song Liu <songliubraving@fb.com>
> ---
> tools/lib/bpf/btf.c | 10 ++++++++++
> tools/lib/bpf/btf.h | 2 ++
> tools/lib/bpf/libbpf.map | 2 ++
> 3 files changed, 14 insertions(+)
>
> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> index 1c2ba7182400..34bfb3641aac 100644
> --- a/tools/lib/bpf/btf.c
> +++ b/tools/lib/bpf/btf.c
> @@ -437,6 +437,16 @@ int btf__fd(const struct btf *btf)
> return btf->fd;
> }
>
> +__u32 btf__get_raw_data_size(const struct btf *btf)
> +{
> + return btf->data_size;
> +}
> +
> +void btf__get_raw_data(const struct btf *btf, char *data)
> +{
> + memcpy(data, btf->data, btf->data_size);
> +}
I cannot think of any other way to use this api,
but to call btf__get_raw_data_size() first,
then malloc that much memory and then call btf__get_raw_data()
to store btf into it.
If so, may be api should be single call that allocates, copies,
and returns pointer to new mem and its size?
Probably less error prone?
^ permalink raw reply
* Re: [RFC bpf-next 0/7] net: flow_dissector: trigger BPF hook when called from eth_get_headlen
From: Alexei Starovoitov @ 2019-02-06 3:12 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Willem de Bruijn, Stanislav Fomichev, Network Development,
David Miller, Alexei Starovoitov, Daniel Borkmann, simon.horman,
Willem de Bruijn
In-Reply-To: <20190206005931.GF10769@mini-arch>
On Tue, Feb 05, 2019 at 04:59:31PM -0800, Stanislav Fomichev wrote:
> On 02/05, Alexei Starovoitov wrote:
> > On Tue, Feb 05, 2019 at 12:40:03PM -0800, Stanislav Fomichev wrote:
> > > On 02/05, Willem de Bruijn wrote:
> > > > On Tue, Feb 5, 2019 at 12:57 PM Stanislav Fomichev <sdf@google.com> wrote:
> > > > >
> > > > > Currently, when eth_get_headlen calls flow dissector, it doesn't pass any
> > > > > skb. Because we use passed skb to lookup associated networking namespace
> > > > > to find whether we have a BPF program attached or not, we always use
> > > > > C-based flow dissector in this case.
> > > > >
> > > > > The goal of this patch series is to add new networking namespace argument
> > > > > to the eth_get_headlen and make BPF flow dissector programs be able to
> > > > > work in the skb-less case.
> > > > >
> > > > > The series goes like this:
> > > > > 1. introduce __init_skb and __init_skb_shinfo; those will be used to
> > > > > initialize temporary skb
> > > > > 2. introduce skb_net which can be used to get networking namespace
> > > > > associated with an skb
> > > > > 3. add new optional network namespace argument to __skb_flow_dissect and
> > > > > plumb through the callers
> > > > > 4. add new __flow_bpf_dissect which constructs temporary on-stack skb
> > > > > (using __init_skb) and calls BPF flow dissector program
> > > >
> > > > The main concern I see with this series is this cost of skb zeroing
> > > > for every packet in the device driver receive routine, *independent*
> > > > from the real skb allocation and zeroing which will likely happen
> > > > later.
> > > Yes, plus ~200 bytes on the stack for the callers.
> > >
> > > Not sure how visible this zeroing though, I can probably try to get some
> > > numbers from BPF_PROG_TEST_RUN (running current version vs running with
> > > on-stack skb).
> >
> > imo extra 256 byte memset for every packet is non starter.
> We can put pre-allocated/initialized skbs without data into percpu or even
> use pcpu_freelist_pop/pcpu_freelist_push to make sure we don't have to think
> about having multiple percpu for irq/softirq/process contexts.
> Any concerns with that approach?
> Any other possible concerns with the overall series?
I'm missing why the whole thing is needed.
You're saying:
" make BPF flow dissector programs be able to work in the skb-less case".
What does it mean specifically?
The only non-skb case is XDP.
Are you saying you want flow_dissector prog to be run in XDP?
^ permalink raw reply
* Re: [PATCH bpf-next 2/4] bpf: fix lockdep false positive in stackmap
From: Eric Dumazet @ 2019-02-06 3:21 UTC (permalink / raw)
To: Waiman Long, Alexei Starovoitov
Cc: Peter Zijlstra, Alexei Starovoitov, davem, daniel, edumazet,
jannh, netdev, kernel-team
In-Reply-To: <e7748be1-8b0b-6613-159f-1c45f932c617@redhat.com>
On 01/30/2019 06:48 PM, Waiman Long wrote:
> On 01/30/2019 09:01 PM, Alexei Starovoitov wrote:
>> On Wed, Jan 30, 2019 at 04:32:12PM -0500, Waiman Long wrote:
>>> On 01/30/2019 04:11 PM, Waiman Long wrote:
>>>> On 01/30/2019 03:10 PM, Alexei Starovoitov wrote:
>>>>> On Wed, Jan 30, 2019 at 02:42:23PM -0500, Waiman Long wrote:
>>>>>> On 01/30/2019 02:30 PM, Alexei Starovoitov wrote:
>>>>>>> On Wed, Jan 30, 2019 at 11:15:30AM +0100, Peter Zijlstra wrote:
>>>>>>>> On Tue, Jan 29, 2019 at 08:04:56PM -0800, Alexei Starovoitov wrote:
>>>>>>>>> Lockdep warns about false positive:
>>>>>>>> This is not a false positive, and you probably also need to use
>>>>>>>> down_read_non_owner() to match this up_read_non_owner().
>>>>>>>>
>>>>>>>> {up,down}_read() and {up,down}_read_non_owner() are not only different
>>>>>>>> in the lockdep annotation; there is also optimistic spin stuff that
>>>>>>>> relies on 'owner' tracking.
>>>>>>> Can you point out in the code the spin bit?
>>>>>>> As far as I can see sem->owner is debug only feature.
>>>>>>> All owner checks are done under CONFIG_DEBUG_RWSEMS.
>>>>>> No, sem->owner is mainly for performing optimistic spinning which is a
>>>>>> performance feature to make rwsem writer-lock performs similar to mutex.
>>>>>> The debugging part is just an add-on. It is not the reason for the
>>>>>> presence of sem->owner.
>>>>> I see. Got it.
>>>>>
>>>>>>> Also there is no down_read_trylock_non_owner() at the moment.
>>>>>>> We can argue about it for -next, but I'd rather silence lockdep
>>>>>>> with this patch today.
>>>>>>>
>>>>>> We can add down_read_trylock_non_owner() if there is a need for it. It
>>>>>> should be easy to do.
>>>>> Yes, but looking through the code it's not clear to me that it's safe
>>>>> to mix non_owner() versions with regular.
>>>>> bpf/stackmap.c does down_read_trylock + up_read.
>>>>> If we add new down_read_trylock_non_owner that set the owner to
>>>>> NULL | RWSEM_* bits is this safe with conccurent read/write
>>>>> that do regular versions?
>>>>> rwsem_can_spin_on_owner() does:
>>>>> if (owner) {
>>>>> ret = is_rwsem_owner_spinnable(owner) &&
>>>>> owner_on_cpu(owner);
>>>>> that looks correct.
>>>>> For a second I thought there could be fault here due to non_owner.
>>>>> But there could be other places where it's assumed that owner
>>>>> is never null?
>>>> The content of owner is not the cause of the lockdep warning. The
>>>> lockdep code assumes that the task that acquires the lock will release
>>>> it some time later. That is not the case when you need to acquire the
>>>> lock by one task and released by another. In this case, you have to use
>>>> the non_owner version of down/up_read which disable the lockdep
>>>> acquire/release tracking. That will be the only difference between the
>>>> two set of APIs.
>>>>
>>>> Cheers,
>>>> Longman
>>> BTW, you may want to do something like that to make sure that the lock
>>> ownership is probably tracked.
>>>
>>> -Longman
>>>
>>> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
>>> index d43b145..79eef9d 100644
>>> --- a/kernel/bpf/stackmap.c
>>> +++ b/kernel/bpf/stackmap.c
>>> @@ -338,6 +338,13 @@ static void stack_map_get_build_id_offset(struct
>>> bpf_stack_
>>> } else {
>>> work->sem = ¤t->mm->mmap_sem;
>>> irq_work_queue(&work->irq_work);
>>> +
>>> + /*
>>> + * The irq_work will release the mmap_sem with
>>> + * up_read_non_owner(). The rwsem_release() is called
>>> + * here to release the lock from lockdep's perspective.
>>> + */
>>> + rwsem_release(¤t->mm->mmap_sem.dep_map, 1, _RET_IP_);
>> are you saying the above is enough coupled with up_read_non_owner?
>> Looking at how amdgpu is using this api... I think they just use non_owner
>> version when doing things from different task.
>> So I don't think pairing non_owner with non_owner is strictly necessary.
>> It seems fine to use down_read_trylock() with above rwsem_release() hack
>> plus up_read_non_owner().
>> Am I missing something?
>>
> The statement above is to clear the state for the lockdep so that it
> knows that the task no longer owns the lock. Without doing that, there
> is a possibility of some other kind of incorrect lockdep warning may be
> produced because the code will still think the task hold a read-lock on
> the mmap_sem. It is also possible no warning will be reported.
>
> The bpf code is kind of special that it acquires the mmap_sem. Later on,
> it either releases it itself (non-NMI) or request irq_work to release it
> (NMI). So either, you use the _non_owner versions for both acquire and
> release or fake the release like the code segment above.
>
> Peter, please chime in if you have other suggestion.
>
Hi guys
What are the plans to address the issue then ?
Latest net tree exhibits this trace :
Thanks
[ 546.116982] =====================================
[ 546.121688] WARNING: bad unlock balance detected!
[ 546.126393] 5.0.0-dbg-DEV #559 Not tainted
[ 546.130491] -------------------------------------
[ 546.135196] taskset/15409 is trying to release lock (&mm->mmap_sem) at:
[ 546.141844] [<ffffffffb0233246>] do_up_read+0x16/0x30
[ 546.146919] but there are no more locks to release!
[ 546.151790]
other info that might help us debug this:
[ 546.158325] 1 lock held by taskset/15409:
[ 546.162325] #0: 00000000683db857 (&sig->cred_guard_mutex){+.+.}, at: __do_execve_file.isra.38+0x13e/0xbc0
[ 546.171978]
stack backtrace:
[ 546.176327] CPU: 0 PID: 15409 Comm: taskset Not tainted 5.0.0-dbg-DEV #559
[ 546.183214] Hardware name: Intel RML,PCH/Iota_QC_19, BIOS 2.54.0 06/07/2018
[ 546.190182] Call Trace:
[ 546.192633] <IRQ>
[ 546.194672] dump_stack+0x67/0x95
[ 546.198006] ? do_up_read+0x16/0x30
[ 546.201491] print_unlock_imbalance_bug.part.33+0xd0/0xd7
[ 546.206914] ? do_up_read+0x16/0x30
[ 546.210406] lock_release+0x213/0x2d0
[ 546.214088] up_read+0x20/0xa0
[ 546.217138] do_up_read+0x16/0x30
[ 546.220457] irq_work_run_list+0x4a/0x70
[ 546.224408] irq_work_run+0x18/0x40
[ 546.227911] smp_irq_work_interrupt+0x54/0x1d0
[ 546.232362] irq_work_interrupt+0xf/0x20
[ 546.236280] </IRQ>
[ 546.238396] RIP: 0010:release_pages+0x69/0x650
[ 546.242839] Code: 01 4c 8b 2f 4c 8d 67 08 48 8d 44 f7 08 45 31 f6 48 89 04 24 eb 04 49 83 c4 08 48 8b 05 20 fe 31 01 49 39 c5 74 26 4d 8b 7d 08 <4d> 8d 47 ff 41 83 e7 01 4d 0f 44 c5 41 8b 40 34 4d 89 c7 85 c0 0f
[ 546.261615] RSP: 0018:ffffac604732bb00 EFLAGS: 00000287 ORIG_RAX: ffffffffffffff09
[ 546.269190] RAX: ffffe4c9c0ca8000 RBX: 0000000000000020 RCX: 0000000000000006
[ 546.276352] RDX: 0000000000000006 RSI: ffff8cf7facb6aa8 RDI: ffff8cf7facb6240
[ 546.283482] RBP: ffffac604732bb70 R08: ffffe4c9c0ba3d80 R09: 0000000000000000
[ 546.290613] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8cf7db3292d8
[ 546.297752] R13: ffffe4c9c0ba3dc0 R14: 0000000000000000 R15: ffffe4c9c0ba3d88
[ 546.304907] free_pages_and_swap_cache+0xe6/0x100
[ 546.309618] tlb_flush_mmu_free+0x36/0x60
[ 546.313625] arch_tlb_finish_mmu+0x28/0x1e0
[ 546.317801] tlb_finish_mmu+0x23/0x30
[ 546.321459] exit_mmap+0xc9/0x1f0
[ 546.324787] ? __mutex_unlock_slowpath+0x11/0x2e0
[ 546.329502] mmput+0x62/0x130
[ 546.332481] flush_old_exec+0x60e/0x810
[ 546.336314] load_elf_binary+0x830/0x18c0
[ 546.340323] ? search_binary_handler+0x8a/0x200
[ 546.344848] search_binary_handler+0x99/0x200
[ 546.349221] __do_execve_file.isra.38+0x76d/0xbc0
[ 546.353918] __x64_sys_execve+0x39/0x50
[ 546.357757] do_syscall_64+0x5a/0x460
[ 546.361440] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 546.366489] RIP: 0033:0x7fd599e3c067
[ 546.370069] Code: Bad RIP value.
[ 546.373306] RSP: 002b:00007ffcf7092e58 EFLAGS: 00000202 ORIG_RAX: 000000000000003b
[ 546.380880] RAX: ffffffffffffffda RBX: 00007ffcf7093058 RCX: 00007fd599e3c067
[ 546.388010] RDX: 00007ffcf7093070 RSI: 00007ffcf7093058 RDI: 00007ffcf70937c0
[ 546.395132] RBP: 00007ffcf7092ec0 R08: 00000000ffffffff R09: 0000000001b1ae40
[ 546.402265] R10: 00007ffcf7092c80 R11: 0000000000000202 R12: 00007ffcf70937c0
[ 546.409385] R13: 00007ffcf7093070 R14: 0000000000000000 R15: 00007ffcf7093048
^ permalink raw reply
* Re: KASAN: use-after-free Read in __wake_up_common_lock
From: Dmitry Vyukov @ 2019-02-06 3:28 UTC (permalink / raw)
To: syzbot, Eric Dumazet; +Cc: Karsten Keil, LKML, netdev, syzkaller-bugs
In-Reply-To: <000000000000c2e17f0580b3387c@google.com>
On Wed, Jan 30, 2019 at 10:02 PM syzbot
<syzbot+fb065bc06d3d4054be6f@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 62967898789d Merge git://git.kernel.org/pub/scm/linux/kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10f0bf08c00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=4fceea9e2d99ac20
> dashboard link: https://syzkaller.appspot.com/bug?extid=fb065bc06d3d4054be6f
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+fb065bc06d3d4054be6f@syzkaller.appspotmail.com
I assume this is also fixed by:
#syz fix: mISDN: fix a race in dev_expire_timer()
> QAT: Invalid ioctl
> ==================================================================
> BUG: KASAN: use-after-free in debug_spin_lock_before
> kernel/locking/spinlock_debug.c:83 [inline]
> BUG: KASAN: use-after-free in do_raw_spin_lock+0x303/0x360
> kernel/locking/spinlock_debug.c:112
> Read of size 4 at addr ffff88808738e92c by task syz-executor1/8644
>
> CPU: 1 PID: 8644 Comm: syz-executor1 Not tainted 5.0.0-rc4+ #50
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1db/0x2d0 lib/dump_stack.c:113
> print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> __asan_report_load4_noabort+0x14/0x20 mm/kasan/generic_report.c:134
> debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
> do_raw_spin_lock+0x303/0x360 kernel/locking/spinlock_debug.c:112
> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline]
> _raw_spin_lock_irqsave+0x9d/0xcd kernel/locking/spinlock.c:152
> __wake_up_common_lock+0x19b/0x390 kernel/sched/wait.c:120
> __wake_up+0xe/0x10 kernel/sched/wait.c:145
> dev_expire_timer+0x14b/0x570 drivers/isdn/mISDN/timerdev.c:174
> call_timer_fn+0x254/0x900 kernel/time/timer.c:1325
> expire_timers kernel/time/timer.c:1362 [inline]
> __run_timers+0x6fc/0xd50 kernel/time/timer.c:1681
> IPVS: ftp: loaded support on port[0] = 21
> run_timer_softirq+0x52/0xb0 kernel/time/timer.c:1694
> __do_softirq+0x30b/0xb11 kernel/softirq.c:292
> invoke_softirq kernel/softirq.c:373 [inline]
> irq_exit+0x180/0x1d0 kernel/softirq.c:413
> exiting_irq arch/x86/include/asm/apic.h:536 [inline]
> smp_apic_timer_interrupt+0x1b7/0x760 arch/x86/kernel/apic/apic.c:1062
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
> </IRQ>
> RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:766
> [inline]
> RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160
> [inline]
> RIP: 0010:_raw_spin_unlock_irqrestore+0x95/0xe0
> kernel/locking/spinlock.c:184
> Code: 48 c7 c0 30 82 92 89 48 ba 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c
> 10 00 75 39 48 83 3d 12 d0 9d 01 00 74 24 48 89 df 57 9d <0f> 1f 44 00 00
> bf 01 00 00 00 e8 dc 75 63 f9 65 8b 05 95 3b 0d 78
> RSP: 0018:ffff888050a7f360 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13
> RAX: 1ffffffff1325046 RBX: 0000000000000282 RCX: 0000000000000000
> RDX: dffffc0000000000 RSI: 0000000000000001 RDI: 0000000000000282
> RBP: ffff888050a7f370 R08: ffff888088b9e000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff8b72b128
> R13: ffff888088b9e000 R14: 00000000000d7480 R15: ffffffff8b72b128
> __debug_object_init+0x1c0/0x12d0 lib/debugobjects.c:418
> debug_object_init+0x16/0x20 lib/debugobjects.c:431
> __init_work+0x50/0x60 kernel/workqueue.c:504
> call_usermodehelper_setup+0x133/0x410 kernel/umh.c:389
> call_modprobe kernel/kmod.c:94 [inline]
> __request_module+0x4f5/0xeea kernel/kmod.c:171
> crypto_larval_lookup crypto/api.c:237 [inline]
> crypto_alg_mod_lookup+0x54e/0x6d0 crypto/api.c:280
> QAT: Invalid ioctl
> crypto_find_alg crypto/api.c:504 [inline]
> crypto_alloc_tfm+0xd9/0x2f0 crypto/api.c:537
> crypto_alloc_skcipher+0x2d/0x40 crypto/skcipher.c:945
> cryptd_alloc_skcipher+0x121/0x270 crypto/cryptd.c:1226
> IPVS: ftp: loaded support on port[0] = 21
> simd_skcipher_init+0x6c/0x1c0 crypto/simd.c:119
> crypto_skcipher_init_tfm+0x299/0x8c0 crypto/skcipher.c:862
> crypto_create_tfm+0xec/0x310 crypto/api.c:471
> crypto_alloc_tfm+0x104/0x2f0 crypto/api.c:543
> crypto_alloc_skcipher+0x2d/0x40 crypto/skcipher.c:945
> QAT: Invalid ioctl
> skcipher_bind+0x26/0x30 crypto/algif_skcipher.c:310
> alg_bind+0x25d/0x570 crypto/af_alg.c:183
> __sys_bind+0x30b/0x420 net/socket.c:1483
> __do_sys_bind net/socket.c:1494 [inline]
> __se_sys_bind net/socket.c:1492 [inline]
> __x64_sys_bind+0x73/0xb0 net/socket.c:1492
> do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x458089
> Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f7508d5ac78 EFLAGS: 00000246 ORIG_RAX: 0000000000000031
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000458089
> RDX: 0000000000000058 RSI: 0000000020000340 RDI: 000000000000000a
> RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f7508d5b6d4
> R13: 00000000004be0ca R14: 00000000004ce420 R15: 00000000ffffffff
>
> Allocated by task 8647:
> save_stack+0x45/0xd0 mm/kasan/common.c:73
> set_track mm/kasan/common.c:85 [inline]
> __kasan_kmalloc mm/kasan/common.c:496 [inline]
> __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469
> kasan_kmalloc+0x9/0x10 mm/kasan/common.c:504
> kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3609
> kmalloc include/linux/slab.h:545 [inline]
> mISDN_open+0x104/0x3f0 drivers/isdn/mISDN/timerdev.c:59
> misc_open+0x398/0x4c0 drivers/char/misc.c:141
> chrdev_open+0x270/0x7c0 fs/char_dev.c:417
> do_dentry_open+0x48a/0x1210 fs/open.c:771
> vfs_open+0xa0/0xd0 fs/open.c:880
> do_last fs/namei.c:3418 [inline]
> path_openat+0x144f/0x5650 fs/namei.c:3534
> do_filp_open+0x26f/0x370 fs/namei.c:3564
> do_sys_open+0x59a/0x7c0 fs/open.c:1063
> __do_sys_openat fs/open.c:1090 [inline]
> __se_sys_openat fs/open.c:1084 [inline]
> __x64_sys_openat+0x9d/0x100 fs/open.c:1084
> do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 8649:
> save_stack+0x45/0xd0 mm/kasan/common.c:73
> set_track mm/kasan/common.c:85 [inline]
> __kasan_slab_free+0x102/0x150 mm/kasan/common.c:458
> kasan_slab_free+0xe/0x10 mm/kasan/common.c:466
> __cache_free mm/slab.c:3487 [inline]
> kfree+0xcf/0x230 mm/slab.c:3806
> mISDN_close+0x39b/0x530 drivers/isdn/mISDN/timerdev.c:97
> __fput+0x3c5/0xb10 fs/file_table.c:278
> ____fput+0x16/0x20 fs/file_table.c:309
> task_work_run+0x1f4/0x2b0 kernel/task_work.c:113
> tracehook_notify_resume include/linux/tracehook.h:188 [inline]
> exit_to_usermode_loop+0x32a/0x3b0 arch/x86/entry/common.c:166
> prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
> syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
> do_syscall_64+0x696/0x800 arch/x86/entry/common.c:293
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff88808738e900
> which belongs to the cache kmalloc-192 of size 192
> The buggy address is located 44 bytes inside of
> 192-byte region [ffff88808738e900, ffff88808738e9c0)
> The buggy address belongs to the page:
> page:ffffea00021ce380 count:1 mapcount:0 mapping:ffff88812c3f0040 index:0x0
> flags: 0x1fffc0000000200(slab)
> raw: 01fffc0000000200 ffffea0002927088 ffffea000298ecc8 ffff88812c3f0040
> raw: 0000000000000000 ffff88808738e000 0000000100000010 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff88808738e800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff88808738e880: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ffff88808738e900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff88808738e980: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> ffff88808738ea00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/000000000000c2e17f0580b3387c%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH bpf-next 2/4] bpf: fix lockdep false positive in stackmap
From: Alexei Starovoitov @ 2019-02-06 3:30 UTC (permalink / raw)
To: Eric Dumazet
Cc: Waiman Long, Peter Zijlstra, Alexei Starovoitov, davem, daniel,
edumazet, jannh, netdev, kernel-team, songliubraving
In-Reply-To: <510d3bb7-5ec0-e281-aabc-a3d379475d71@gmail.com>
On Tue, Feb 05, 2019 at 07:21:08PM -0800, Eric Dumazet wrote:
> >>>
> >>> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> >>> index d43b145..79eef9d 100644
> >>> --- a/kernel/bpf/stackmap.c
> >>> +++ b/kernel/bpf/stackmap.c
> >>> @@ -338,6 +338,13 @@ static void stack_map_get_build_id_offset(struct
> >>> bpf_stack_
> >>> } else {
> >>> work->sem = ¤t->mm->mmap_sem;
> >>> irq_work_queue(&work->irq_work);
> >>> +
> >>> + /*
> >>> + * The irq_work will release the mmap_sem with
> >>> + * up_read_non_owner(). The rwsem_release() is called
> >>> + * here to release the lock from lockdep's perspective.
> >>> + */
> >>> + rwsem_release(¤t->mm->mmap_sem.dep_map, 1, _RET_IP_);
> >> are you saying the above is enough coupled with up_read_non_owner?
> >> Looking at how amdgpu is using this api... I think they just use non_owner
> >> version when doing things from different task.
> >> So I don't think pairing non_owner with non_owner is strictly necessary.
> >> It seems fine to use down_read_trylock() with above rwsem_release() hack
> >> plus up_read_non_owner().
> >> Am I missing something?
> >>
> > The statement above is to clear the state for the lockdep so that it
> > knows that the task no longer owns the lock. Without doing that, there
> > is a possibility of some other kind of incorrect lockdep warning may be
> > produced because the code will still think the task hold a read-lock on
> > the mmap_sem. It is also possible no warning will be reported.
> >
> > The bpf code is kind of special that it acquires the mmap_sem. Later on,
> > it either releases it itself (non-NMI) or request irq_work to release it
> > (NMI). So either, you use the _non_owner versions for both acquire and
> > release or fake the release like the code segment above.
> >
> > Peter, please chime in if you have other suggestion.
> >
>
> Hi guys
>
> What are the plans to address the issue then ?
> Latest net tree exhibits this trace :
Thanks for the reminder :)
I've been waiting for Peter's direction on this one.
Happy to fix it whichever way.
To recap:
Approach 1:
s/up_read/up_read_non_owner/ from irq_work + rwsem_release as Longman proposed.
Apporach 2:
introduce down_read_trylock_non_owner and pair it with up_read_non_owner
in both irq_work and normal.
My preference is 1. I think Longman's as well.
^ permalink raw reply
* Re: [PATCH v3 2/2] netdev/phy: add MDIO bus multiplexer driven by a regmap
From: Florian Fainelli @ 2019-02-05 5:14 UTC (permalink / raw)
To: Pankaj Bansal, Andrew Lunn; +Cc: netdev@vger.kernel.org
In-Reply-To: <20190205153014.3807-3-pankaj.bansal@nxp.com>
On 2/5/19 2:05 AM, Pankaj Bansal wrote:
> Add support for an MDIO bus multiplexer controlled by a regmap
> device, like an FPGA.
>
> Tested on a NXP LX2160AQDS board which uses the "QIXIS" FPGA
> attached to the i2c bus.
>
> Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
With Andrew's comment fixed:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: Pull patches from tip/perf/core to bpf-next
From: Alexei Starovoitov @ 2019-02-06 3:36 UTC (permalink / raw)
To: Song Liu; +Cc: Daniel Borkmann, Alexei Starovoitov, Kernel Team, Netdev
In-Reply-To: <545C47EB-4D9A-46A5-892B-D4DDB88AFFDD@fb.com>
On Tue, Feb 05, 2019 at 10:47:06PM +0000, Song Liu wrote:
> Hi Alexei and Daniel,
>
> The following patches are required for BPF introspection in perf tools.
> Please pull them to bpf-next, so that we get all the dependencies in one
> tree.
>
> Thanks,
> Song
>
> (from 1/10 to 10/10)
> 76193a94522f perf, bpf: Introduce PERF_RECORD_KSYMBOL
> d764ac646491 tools headers uapi: Sync tools/include/uapi/linux/perf_event.h
> 6ee52e2a3fe4 perf, bpf: Introduce PERF_RECORD_BPF_EVENT
> df063c83aa2c tools headers uapi: Sync tools/include/uapi/linux/perf_event.h
> 9aa0bfa370b2 perf tools: Handle PERF_RECORD_KSYMBOL
> 45178a928a4b perf tools: Handle PERF_RECORD_BPF_EVENT
> 7b612e291a5a perf tools: Synthesize PERF_RECORD_* for loaded BPF programs
> a40b95bcd30c perf top: Synthesize BPF events for pre-existing loaded BPF programs
> 6934058d9fb6 bpf: Add module name [bpf] to ksymbols for bpf programs
> 811184fb6977 perf bpf: Fix synthesized PERF_RECORD_KSYMBOL/BPF_EVENT
yes. we can certainly do that.
Do you have bpf specific patches that depend on that ?
Since it's rc5 already. Are you planning to send them within next week?
^ permalink raw reply
* Re: [PATCH bpf-next 2/4] bpf: fix lockdep false positive in stackmap
From: Eric Dumazet @ 2019-02-06 3:40 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Waiman Long, Peter Zijlstra, Alexei Starovoitov, davem, daniel,
edumazet, jannh, netdev, kernel-team, songliubraving
In-Reply-To: <20190206033001.bkyliw2j3tnxzc3j@ast-mbp>
On 02/05/2019 07:30 PM, Alexei Starovoitov wrote:
> Thanks for the reminder :)
>
> I've been waiting for Peter's direction on this one.
> Happy to fix it whichever way.
>
> To recap:
> Approach 1:
> s/up_read/up_read_non_owner/ from irq_work + rwsem_release as Longman proposed.
>
> Apporach 2:
> introduce down_read_trylock_non_owner and pair it with up_read_non_owner
> in both irq_work and normal.
>
> My preference is 1. I think Longman's as well.
>
Unless we envision other uses for down_read_trylock_non_owner() and up_read_non_owner(),
I agree 1) seems good enough, at least for the short term.
Thanks !
^ permalink raw reply
* Request for Quotation
From: Sasha Kelley @ 2019-02-06 12:33 UTC (permalink / raw)
To: netdev
Nice day to you!
My Names Sasha Kelley from Earthlink, Inc. Moscow Russia
There is an available invitation to tender suitable for your
products and I would like to inquire if your company will be
interested to submit offer for your products in Moscow Russia.
Please confirm interest by sending product catalog/price list
for
our review.
Looking forward to hearing from you.
Best Regards,
Area Manager
Sasha Kelley
Tel: +79017731031
E-mail: earthlink@zoho.com
Earthlink, Inc (Moscow).
^ permalink raw reply
* Re: KASAN: use-after-free Read in __wake_up_common_lock
From: Eric Dumazet @ 2019-02-06 3:42 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot, Eric Dumazet
Cc: Karsten Keil, LKML, netdev, syzkaller-bugs
In-Reply-To: <CACT4Y+YOTSY=ZVw882tfDDPZ6Y5ZSX6HHn2M=Q2uTxjUtjb9=w@mail.gmail.com>
On 02/05/2019 07:28 PM, Dmitry Vyukov wrote:
> On Wed, Jan 30, 2019 at 10:02 PM syzbot
> <syzbot+fb065bc06d3d4054be6f@syzkaller.appspotmail.com> wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: 62967898789d Merge git://git.kernel.org/pub/scm/linux/kern..
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=10f0bf08c00000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=4fceea9e2d99ac20
>> dashboard link: https://syzkaller.appspot.com/bug?extid=fb065bc06d3d4054be6f
>> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>>
>> Unfortunately, I don't have any reproducer for this crash yet.
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+fb065bc06d3d4054be6f@syzkaller.appspotmail.com
>
> I assume this is also fixed by:
>
> #syz fix: mISDN: fix a race in dev_expire_timer()
Yes this looks very probable, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox