* [PATCH net-next] Implement a rtnetlink device which simulates wifi.
From: Cody Schuffelen @ 2018-07-25 0:10 UTC (permalink / raw)
To: Kalle Valo, David S. Miller, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, kernel-team-z5hGa2qSFaRBDgjK7y7TUQ
The device added here is used through "ip link add ... type virt_wifi"
The intention is to take over an existing network device and produce a
new one that appears like a wireless connection, returning enough canned
responses to nl80211 to satisfy a standard network manager. If
necessary, it can also be set up one step removed from an existing
network device, such as through a vlan/80211Q or macvlan connection to
not disrupt the existing network interface.
This is being used for Google's Remote Android Virtual Device project,
which runs Android devices in virtual machines. The standard network
interfaces provided inside the virtual machines are all ethernet.
However, Android is not interested in ethernet devices and would rather
connect to a wireless interface. This patch allows the virtual machine
guest to treat one of its network connections as wireless rather than
ethernet, satisfying Android's network connection requirements.
We believe this is a generally useful driver for simulating wireless
network connections in other environments where a wireless connection is
desired by some userspace process but is not available. Future work can
also include exporting the wireless control plane to userspace, so the
device can configure the behavior of the simulated wireless network
itself.
This is distinct from other testing efforts such as mac80211_hwsim by
being a cfg80211 device instead of mac80211 device, allowing straight
pass-through on the data plane instead of forcing packaging of ethernet
data into mac80211 frames.
Signed-off-by: A. Cody Schuffelen <schuffelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Acked-by: Alistair Strachan <astrachan-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Acked-by: Greg Hartman <ghartman-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
Resending this patch, because the To: line was missing in the original
email.
drivers/net/wireless/Kconfig | 7 +
drivers/net/wireless/Makefile | 2 +
drivers/net/wireless/virt_wifi.c | 544 +++++++++++++++++++++++++++++++
3 files changed, 553 insertions(+)
create mode 100644 drivers/net/wireless/virt_wifi.c
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index 166920ae23f8..1781d8a7f05a 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -114,4 +114,11 @@ config USB_NET_RNDIS_WLAN
If you choose to build a module, it'll be called rndis_wlan.
+config VIRT_WIFI
+ tristate "Wifi wrapper for ethernet drivers"
+ default n
+ ---help---
+ This option adds support for ethernet connections to appear as if they
+ are wifi connections through a special rtnetlink device.
+
endif # WLAN
diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index 7fc96306712a..6cfe74515c95 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -27,3 +27,5 @@ obj-$(CONFIG_PCMCIA_WL3501) += wl3501_cs.o
obj-$(CONFIG_USB_NET_RNDIS_WLAN) += rndis_wlan.o
obj-$(CONFIG_MAC80211_HWSIM) += mac80211_hwsim.o
+
+obj-$(CONFIG_VIRT_WIFI) += virt_wifi.o
diff --git a/drivers/net/wireless/virt_wifi.c b/drivers/net/wireless/virt_wifi.c
new file mode 100644
index 000000000000..602bf462b444
--- /dev/null
+++ b/drivers/net/wireless/virt_wifi.c
@@ -0,0 +1,544 @@
+// SPDX-License-Identifier: GPL-2.0
+/* drivers/net/wireless/virt_wifi.c
+ *
+ * A fake implementation of cfg80211_ops that can be tacked on to an ethernet
+ * net_device to make it appear as a wireless connection.
+ *
+ * Copyright (C) 2018 Google, Inc.
+ *
+ * Author: schuffelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
+ */
+
+#include <net/cfg80211.h>
+#include <net/rtnetlink.h>
+#include <linux/etherdevice.h>
+#include <linux/module.h>
+
+struct virt_wifi_priv {
+ bool being_deleted;
+ struct cfg80211_scan_request *scan_request;
+ struct delayed_work scan_result;
+ struct delayed_work scan_complete;
+};
+
+static struct ieee80211_channel channel = {
+ .band = NL80211_BAND_5GHZ,
+ .center_freq = 5500,
+ .hw_value = 5500,
+
+ .flags = 0, /* ieee80211_channel_flags */
+ .max_antenna_gain = 20,
+ .max_power = 5500,
+ .max_reg_power = 9999,
+};
+
+static struct ieee80211_rate bitrate = {
+ .flags = IEEE80211_RATE_SHORT_PREAMBLE, /* ieee80211_rate_flags */
+ .bitrate = 1000,
+};
+
+static struct ieee80211_supported_band band_5ghz = {
+ .channels = &channel,
+ .bitrates = &bitrate,
+ .band = NL80211_BAND_5GHZ,
+ .n_channels = 1,
+ .n_bitrates = 1,
+};
+
+static struct cfg80211_inform_bss mock_inform_bss = {
+ /* ieee80211_channel* */ .chan = &channel,
+ /* nl80211_bss_scan_width */ .scan_width = NL80211_BSS_CHAN_WIDTH_20,
+ /* s32 */ .signal = 99,
+};
+
+static u8 fake_router_bssid[] = {4, 4, 4, 4, 4, 4};
+
+static int virt_wifi_scan(struct wiphy *wiphy,
+ struct cfg80211_scan_request *request)
+{
+ struct virt_wifi_priv *priv = wiphy_priv(wiphy);
+
+ wiphy_debug(wiphy, "scan\n");
+
+ if (priv->scan_request || priv->being_deleted)
+ return -EBUSY;
+
+ if (request->ie_len > 0)
+ wiphy_debug(wiphy, "scan: first ie: %d\n", (int)request->ie[0]);
+
+ if (request->n_ssids > 0) {
+ int i;
+ u8 request_ssid_copy[IEEE80211_MAX_SSID_LEN + 1];
+
+ for (i = 0; i < request->n_ssids; i++) {
+ strncpy(request_ssid_copy, request->ssids[i].ssid,
+ request->ssids[i].ssid_len);
+ request_ssid_copy[request->ssids[i].ssid_len] = 0;
+ wiphy_debug(wiphy, "scan: ssid: %s\n",
+ request_ssid_copy);
+ }
+ }
+
+ priv->scan_request = request;
+ schedule_delayed_work(&priv->scan_result, HZ / 100);
+
+ return 0;
+}
+
+static void virt_wifi_scan_result(struct work_struct *work)
+{
+ struct virt_wifi_priv *priv =
+ container_of(work, struct virt_wifi_priv,
+ scan_result.work);
+ struct wiphy *wiphy = priv_to_wiphy(priv);
+ char ssid[] = "__VirtWifi";
+ struct cfg80211_bss *informed_bss;
+
+ mock_inform_bss.boottime_ns = ktime_get_boot_ns();
+
+ ssid[0] = WLAN_EID_SSID;
+ /* size of the array minus null terminator, length byte, tag byte */
+ ssid[1] = sizeof(ssid) - 3;
+
+ informed_bss =
+ cfg80211_inform_bss_data(wiphy, &mock_inform_bss,
+ CFG80211_BSS_FTYPE_PRESP,
+ fake_router_bssid,
+ mock_inform_bss.boottime_ns,
+ WLAN_CAPABILITY_ESS, 0, ssid,
+ /* Truncate before the terminator. */
+ sizeof(ssid) - 1, GFP_KERNEL);
+ cfg80211_put_bss(wiphy, informed_bss);
+
+ informed_bss =
+ cfg80211_inform_bss_data(wiphy, &mock_inform_bss,
+ CFG80211_BSS_FTYPE_BEACON,
+ fake_router_bssid,
+ mock_inform_bss.boottime_ns,
+ WLAN_CAPABILITY_ESS, 0, ssid,
+ /* Truncate before the terminator. */
+ sizeof(ssid) - 1, GFP_KERNEL);
+ cfg80211_put_bss(wiphy, informed_bss);
+
+ schedule_delayed_work(&priv->scan_complete, HZ / 100);
+}
+
+static void virt_wifi_scan_complete(struct work_struct *work)
+{
+ struct virt_wifi_priv *priv =
+ container_of(work, struct virt_wifi_priv,
+ scan_complete.work);
+ struct cfg80211_scan_info scan_info = {
+ .aborted = false,
+ };
+
+ cfg80211_scan_done(priv->scan_request, &scan_info);
+ priv->scan_request = NULL;
+}
+
+static struct ieee80211_mgmt auth_mgmt_frame = {
+ .frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT
+ | IEEE80211_STYPE_AUTH),
+ .duration = cpu_to_le16(1), /* ??? */
+ .u = {
+ .auth = {
+ .auth_alg = WLAN_AUTH_OPEN,
+ /* auth request has 1, auth response has 2 */
+ .auth_transaction = cpu_to_le16(2),
+ },
+ },
+};
+
+static int virt_wifi_auth(struct wiphy *wiphy, struct net_device *dev,
+ struct cfg80211_auth_request *req)
+{
+ wiphy_debug(wiphy, "auth\n");
+ memcpy(auth_mgmt_frame.da, dev->dev_addr, dev->addr_len);
+ memcpy(auth_mgmt_frame.sa, fake_router_bssid,
+ sizeof(fake_router_bssid));
+ memcpy(auth_mgmt_frame.bssid, fake_router_bssid,
+ sizeof(fake_router_bssid));
+ /* Must call cfg80211_rx_mlme_mgmt to notify about the response to this.
+ * This must hold the mutex for the wedev while calling the function.
+ * Luckily the nl80211 code invoking this already holds that mutex.
+ */
+ cfg80211_rx_mlme_mgmt(dev, (const u8 *)&auth_mgmt_frame,
+ sizeof(auth_mgmt_frame));
+ return 0;
+}
+
+static struct ieee80211_mgmt assoc_mgmt_frame = {
+ .frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT
+ | IEEE80211_STYPE_ASSOC_RESP),
+ .duration = cpu_to_le16(1), /* ??? */
+ .u = {
+ .assoc_resp = {
+ .capab_info = cpu_to_le16(1),
+ .status_code = cpu_to_le16(0),
+ .aid = cpu_to_le16(2), /* "association id" */
+ },
+ },
+};
+
+static int virt_wifi_assoc(struct wiphy *wiphy, struct net_device *dev,
+ struct cfg80211_assoc_request *req)
+{
+ wiphy_debug(wiphy, "assoc\n");
+ memcpy(assoc_mgmt_frame.da, dev->dev_addr, dev->addr_len);
+ memcpy(assoc_mgmt_frame.sa, fake_router_bssid,
+ sizeof(fake_router_bssid));
+ memcpy(assoc_mgmt_frame.bssid, fake_router_bssid,
+ sizeof(fake_router_bssid));
+ /* Must call cfg80211_rx_assoc_resp to notify about the response to
+ * this. This must hold the mutex for the wedev while calling the
+ * function. Luckily the nl80211 code invoking this already holds that
+ * mutex.
+ */
+ cfg80211_rx_assoc_resp(dev, req->bss, (const u8 *)&assoc_mgmt_frame,
+ sizeof(assoc_mgmt_frame), -1);
+ return 0;
+}
+
+static struct ieee80211_mgmt deauth_mgmt_frame = {
+ .frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT
+ | IEEE80211_STYPE_DEAUTH),
+ .duration = cpu_to_le16(1), /* ??? */
+};
+
+static int virt_wifi_deauth(struct wiphy *wiphy, struct net_device *dev,
+ struct cfg80211_deauth_request *req)
+{
+ wiphy_debug(wiphy, "deauth\n");
+ memcpy(deauth_mgmt_frame.da, dev->dev_addr, dev->addr_len);
+ memcpy(deauth_mgmt_frame.sa, fake_router_bssid,
+ sizeof(fake_router_bssid));
+ memcpy(deauth_mgmt_frame.bssid, fake_router_bssid,
+ sizeof(fake_router_bssid));
+ deauth_mgmt_frame.u.deauth.reason_code = cpu_to_le16(req->reason_code);
+ /* Must call cfg80211_rx_mlme_mgmt to notify about the response to this.
+ * This must hold the mutex for the wedev while calling the function.
+ * Luckily the nl80211 code invoking this already holds that mutex.
+ */
+ cfg80211_rx_mlme_mgmt(dev, (const u8 *)&deauth_mgmt_frame,
+ sizeof(auth_mgmt_frame));
+ return 0;
+}
+
+static struct ieee80211_mgmt disassoc_mgmt_frame = {
+ .frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT
+ | IEEE80211_STYPE_DISASSOC),
+ .duration = cpu_to_le16(1), /* ??? */
+};
+
+static int virt_wifi_disassoc(struct wiphy *wiphy, struct net_device *dev,
+ struct cfg80211_disassoc_request *req)
+{
+ wiphy_debug(wiphy, "disassoc\n");
+ memcpy(disassoc_mgmt_frame.da, dev->dev_addr, dev->addr_len);
+ memcpy(disassoc_mgmt_frame.sa, fake_router_bssid,
+ sizeof(fake_router_bssid));
+ memcpy(disassoc_mgmt_frame.bssid, fake_router_bssid,
+ sizeof(fake_router_bssid));
+ disassoc_mgmt_frame.u.disassoc.reason_code =
+ cpu_to_le16(req->reason_code);
+ /* Must call cfg80211_rx_mlme_mgmt to notify about the response to this.
+ * This must hold the mutex for the wedev while calling the function.
+ * Luckily the nl80211 code invoking this already holds that mutex.
+ */
+ cfg80211_rx_mlme_mgmt(dev, (const u8 *)&disassoc_mgmt_frame,
+ sizeof(auth_mgmt_frame));
+ return 0;
+}
+
+static int virt_wifi_get_station(struct wiphy *wiphy, struct net_device *dev,
+ const u8 *mac, struct station_info *sinfo)
+{
+ wiphy_debug(wiphy, "get_station\n");
+ /* Only the values used by netlink_utils.cpp. */
+ sinfo->filled = BIT(NL80211_STA_INFO_TX_PACKETS) |
+ BIT(NL80211_STA_INFO_TX_FAILED) | BIT(NL80211_STA_INFO_SIGNAL) |
+ BIT(NL80211_STA_INFO_TX_BITRATE);
+ sinfo->tx_packets = 1;
+ sinfo->tx_failed = 0;
+ sinfo->signal = -1; /* -1 is the maximum signal strength, somehow. */
+ sinfo->txrate = (struct rate_info) {
+ .legacy = 10000, /* units are 100kbit/s */
+ };
+ return 0;
+}
+
+static const struct cfg80211_ops virt_wifi_cfg80211_ops = {
+ .scan = virt_wifi_scan,
+
+ .auth = virt_wifi_auth,
+ .assoc = virt_wifi_assoc,
+ .deauth = virt_wifi_deauth,
+ .disassoc = virt_wifi_disassoc,
+
+ .get_station = virt_wifi_get_station,
+};
+
+static struct wireless_dev *virt_wireless_dev(struct device *device)
+{
+ struct wireless_dev *wdev;
+ struct wiphy *wiphy;
+ struct virt_wifi_priv *priv;
+
+ wdev = kzalloc(sizeof(*wdev), GFP_KERNEL);
+
+ if (!wdev)
+ return ERR_PTR(-ENOMEM);
+
+ wdev->iftype = NL80211_IFTYPE_STATION;
+ wiphy = wiphy_new(&virt_wifi_cfg80211_ops,
+ sizeof(struct virt_wifi_priv));
+
+ if (!wiphy) {
+ kfree(wdev);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ wdev->wiphy = wiphy;
+
+ /* 100 SSIDs should be enough for anyone! */
+ wiphy->max_scan_ssids = 101;
+ wiphy->max_scan_ie_len = 1000;
+ wiphy->signal_type = CFG80211_SIGNAL_TYPE_MBM;
+
+ wiphy->bands[NL80211_BAND_2GHZ] = NULL;
+ wiphy->bands[NL80211_BAND_5GHZ] = &band_5ghz;
+ wiphy->bands[NL80211_BAND_60GHZ] = NULL;
+
+ /* Don't worry about frequency regulations. */
+ wiphy->regulatory_flags = REGULATORY_WIPHY_SELF_MANAGED;
+ wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
+ BIT(NL80211_IFTYPE_AP) |
+ BIT(NL80211_IFTYPE_P2P_CLIENT) |
+ BIT(NL80211_IFTYPE_P2P_GO) |
+ BIT(NL80211_IFTYPE_ADHOC) |
+ BIT(NL80211_IFTYPE_MESH_POINT) |
+ BIT(NL80211_IFTYPE_MONITOR);
+ wiphy->flags |= WIPHY_FLAG_SUPPORTS_TDLS |
+ WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL |
+ WIPHY_FLAG_AP_UAPSD |
+ WIPHY_FLAG_HAS_CHANNEL_SWITCH;
+ wiphy->features |= NL80211_FEATURE_ACTIVE_MONITOR |
+ NL80211_FEATURE_AP_MODE_CHAN_WIDTH_CHANGE |
+ NL80211_FEATURE_STATIC_SMPS |
+ NL80211_FEATURE_DYNAMIC_SMPS |
+ NL80211_FEATURE_AP_SCAN |
+ NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR;
+ set_wiphy_dev(wiphy, device);
+
+ priv = wiphy_priv(wiphy);
+ priv->being_deleted = false;
+ priv->scan_request = NULL;
+ INIT_DELAYED_WORK(&priv->scan_result, virt_wifi_scan_result);
+ INIT_DELAYED_WORK(&priv->scan_complete, virt_wifi_scan_complete);
+
+ return wdev;
+}
+
+struct virt_wifi_netdev_priv {
+ struct net_device *lowerdev;
+ struct net_device *upperdev;
+ struct work_struct register_wiphy_work;
+};
+
+static netdev_tx_t virt_wifi_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
+{
+ struct virt_wifi_netdev_priv *priv = netdev_priv(dev);
+
+ skb->dev = priv->lowerdev;
+ return dev_queue_xmit(skb);
+}
+
+static const struct net_device_ops wifi_vlan_ops = {
+ .ndo_start_xmit = virt_wifi_start_xmit,
+};
+
+static void free_wiphy(struct net_device *dev)
+{
+ struct virt_wifi_netdev_priv *priv = netdev_priv(dev);
+ struct virt_wifi_priv *w_priv;
+
+ flush_work(&priv->register_wiphy_work);
+ if (dev->ieee80211_ptr && !IS_ERR(dev->ieee80211_ptr)) {
+ w_priv = wiphy_priv(dev->ieee80211_ptr->wiphy);
+ w_priv->being_deleted = true;
+ flush_delayed_work(&w_priv->scan_result);
+ flush_delayed_work(&w_priv->scan_complete);
+
+ if (dev->ieee80211_ptr->wiphy->registered)
+ wiphy_unregister(dev->ieee80211_ptr->wiphy);
+ wiphy_free(dev->ieee80211_ptr->wiphy);
+ kfree(dev->ieee80211_ptr);
+ }
+}
+
+static void virt_wifi_setup(struct net_device *dev)
+{
+ ether_setup(dev);
+ dev->netdev_ops = &wifi_vlan_ops;
+ dev->needs_free_netdev = true;
+ dev->priv_destructor = free_wiphy;
+}
+
+/* Called under rcu_read_lock() from netif_receive_skb */
+static rx_handler_result_t virt_wifi_rx_handler(struct sk_buff **pskb)
+{
+ struct sk_buff *skb = *pskb;
+ struct virt_wifi_netdev_priv *priv =
+ rcu_dereference(skb->dev->rx_handler_data);
+
+ /* macvlan uses GFP_ATOMIC here. */
+ skb = skb_share_check(skb, GFP_ATOMIC);
+ if (!skb) {
+ dev_err(&priv->upperdev->dev, "can't skb_share_check\n");
+ return RX_HANDLER_CONSUMED;
+ }
+
+ *pskb = skb;
+ skb->dev = priv->upperdev;
+ skb->pkt_type = PACKET_HOST;
+ return RX_HANDLER_ANOTHER;
+}
+
+static void virt_wifi_register_wiphy(struct work_struct *work)
+{
+ struct virt_wifi_netdev_priv *priv =
+ container_of(work, struct virt_wifi_netdev_priv,
+ register_wiphy_work);
+ struct wireless_dev *wdev = priv->upperdev->ieee80211_ptr;
+ int err;
+
+ err = wiphy_register(wdev->wiphy);
+ if (err < 0) {
+ dev_err(&priv->upperdev->dev, "can't wiphy_register (%d)\n",
+ err);
+
+ /* Roll back the net_device, it's not going to do wifi. */
+ rtnl_lock();
+ err = rtnl_delete_link(priv->upperdev);
+ rtnl_unlock();
+
+ /* rtnl_delete_link should only throw errors if it's not a
+ * netlink device, but we know here it is already a virt_wifi
+ * device.
+ */
+ WARN_ONCE(err, "rtnl_delete_link failed on a virt_wifi device");
+ }
+}
+
+/* Called with rtnl lock held. */
+static int virt_wifi_newlink(struct net *src_net, struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[],
+ struct netlink_ext_ack *extack)
+{
+ struct virt_wifi_netdev_priv *priv = netdev_priv(dev);
+ int err;
+
+ if (!tb[IFLA_LINK])
+ return -EINVAL;
+
+ priv->upperdev = dev;
+ priv->lowerdev = __dev_get_by_index(src_net,
+ nla_get_u32(tb[IFLA_LINK]));
+
+ if (!priv->lowerdev)
+ return -ENODEV;
+ if (!tb[IFLA_MTU])
+ dev->mtu = priv->lowerdev->mtu;
+ else if (dev->mtu > priv->lowerdev->mtu)
+ return -EINVAL;
+
+ err = netdev_rx_handler_register(priv->lowerdev, virt_wifi_rx_handler,
+ priv);
+ if (err != 0) {
+ dev_err(&priv->lowerdev->dev,
+ "can't netdev_rx_handler_register: %ld\n",
+ PTR_ERR(dev->ieee80211_ptr));
+ return err;
+ }
+
+ eth_hw_addr_inherit(dev, priv->lowerdev);
+ netif_stacked_transfer_operstate(priv->lowerdev, dev);
+
+ SET_NETDEV_DEV(dev, &priv->lowerdev->dev);
+ dev->ieee80211_ptr = virt_wireless_dev(&priv->lowerdev->dev);
+
+ if (IS_ERR(dev->ieee80211_ptr)) {
+ dev_err(&priv->lowerdev->dev, "can't init wireless: %ld\n",
+ PTR_ERR(dev->ieee80211_ptr));
+ return PTR_ERR(dev->ieee80211_ptr);
+ }
+
+ err = register_netdevice(dev);
+ if (err) {
+ dev_err(&priv->lowerdev->dev, "can't register_netdevice: %d\n",
+ err);
+ goto remove_handler;
+ }
+
+ err = netdev_upper_dev_link(priv->lowerdev, dev, extack);
+ if (err) {
+ dev_err(&priv->lowerdev->dev, "can't netdev_upper_dev_link: %d\n",
+ err);
+ goto unregister_netdev;
+ }
+
+ /* The newlink callback is invoked while holding the rtnl lock, but
+ * register_wiphy wants to claim the rtnl lock itself.
+ */
+ INIT_WORK(&priv->register_wiphy_work, virt_wifi_register_wiphy);
+ schedule_work(&priv->register_wiphy_work);
+
+ return 0;
+remove_handler:
+ netdev_rx_handler_unregister(priv->lowerdev);
+unregister_netdev:
+ unregister_netdevice(dev);
+
+ return err;
+}
+
+/** Called with rtnl lock held. */
+static void virt_wifi_dellink(struct net_device *dev,
+ struct list_head *head)
+{
+ struct virt_wifi_netdev_priv *priv = netdev_priv(dev);
+
+ netdev_rx_handler_unregister(priv->lowerdev);
+ netdev_upper_dev_unlink(priv->lowerdev, dev);
+
+ unregister_netdevice_queue(dev, head);
+
+ /* Deleting the wiphy is handled in the netdev destructor. */
+}
+
+static struct rtnl_link_ops virt_wifi_link_ops = {
+ .kind = "virt_wifi",
+ .setup = virt_wifi_setup,
+ .newlink = virt_wifi_newlink,
+ .dellink = virt_wifi_dellink,
+ .priv_size = sizeof(struct virt_wifi_netdev_priv),
+};
+
+static int __init virt_wifi_init_module(void)
+{
+ return rtnl_link_register(&virt_wifi_link_ops);
+}
+
+static void __exit virt_wifi_cleanup_module(void)
+{
+ rtnl_link_unregister(&virt_wifi_link_ops);
+}
+
+module_init(virt_wifi_init_module);
+module_exit(virt_wifi_cleanup_module);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("A. Cody Schuffelen <schuffelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>");
+MODULE_DESCRIPTION("Driver for a wireless wrapper of ethernet devices");
+MODULE_ALIAS_RTNL_LINK("virt_wifi");
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply related
* Re: [PATCH 2/5] rhashtable: don't hold lock on first table throughout insertion.
From: Paul E. McKenney @ 2018-07-24 22:58 UTC (permalink / raw)
To: NeilBrown; +Cc: Herbert Xu, Thomas Graf, netdev, linux-kernel
In-Reply-To: <87r2jtpqm4.fsf@notabene.neil.brown.name>
On Tue, Jul 24, 2018 at 07:52:03AM +1000, NeilBrown wrote:
> On Mon, Jul 23 2018, Paul E. McKenney wrote:
>
> > On Mon, Jul 23, 2018 at 09:13:43AM +1000, NeilBrown wrote:
> >> On Sun, Jul 22 2018, Paul E. McKenney wrote:
> >> >
> >> > One issue is that the ->func pointer can legitimately be NULL while on
> >> > RCU's callback lists. This happens when someone invokes kfree_rcu()
> >> > with the rcu_head structure at the beginning of the enclosing structure.
> >> > I could add an offset to avoid this, or perhaps the kmalloc() folks
> >> > could be persuaded Rao Shoaib's patch moving kfree_rcu() handling to
> >> > the slab allocators, so that RCU only ever sees function pointers in
> >> > the ->func field.
> >> >
> >> > Either way, this should be hidden behind an API to allow adjustments
> >> > to be made if needed. Maybe something like is_after_call_rcu()?
> >> > This would (for example) allow debug-object checks to be used to catch
> >> > check-after-free bugs.
> >> >
> >> > Would something of that sort work for you?
> >>
> >> Yes, if you could provide an is_after_call_rcu() API, that would
> >> perfectly suit my use-case.
> >
> > After beating my head against the object-debug code a bit, I have to ask
> > if it would be OK for you if the is_after_call_rcu() API also takes the
> > function that was passed to RCU.
>
> Sure. It feels a bit clumsy, but I can see it could be easier to make
> robust.
> So yes: I'm fine with pass the same function and rcu_head to both
> call_rcu() and is_after_call_rcu(). Actually, when I say it like that,
> it seems less clumsy :-)
How about like this? (It needs refinements, like lockdep, but should
get the gist.)
Thanx, Paul
------------------------------------------------------------------------
commit 5aa0ebf4799b8bddbbd0124db1c008526e99fc7c
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Tue Jul 24 15:28:09 2018 -0700
rcu: Provide functions for determining if call_rcu() has been invoked
This commit adds is_after_call_rcu() and is_after_call_rcu_init()
functions to help RCU users detect when another CPU has passed
the specified rcu_head structure and function to call_rcu().
The is_after_call_rcu_init() should be invoked before making the
structure visible to RCU readers, and then the is_after_call_rcu() may
be invoked from within an RCU read-side critical section on an rcu_head
structure that was obtained during a traversal of the data structure
in question. The is_after_call_rcu() function will return true if the
rcu_head structure has already been passed (with the specified function)
to call_rcu(), otherwise it will return false.
If is_after_call_rcu_init() has not been invoked on the rcu_head
structure or if the rcu_head (AKA callback) has already been invoked,
then is_after_call_rcu() will do WARN_ON_ONCE().
Reported-by: NeilBrown <neilb@suse.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index e4f821165d0b..82e5a91539b5 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -857,6 +857,45 @@ static inline notrace void rcu_read_unlock_sched_notrace(void)
#endif /* #else #ifdef CONFIG_ARCH_WEAK_RELEASE_ACQUIRE */
+/* Has the specified rcu_head structure been handed to call_rcu()? */
+
+/*
+ * is_after_call_rcu_init - Initialize rcu_head for is_after_call_rcu()
+ * @rhp: The rcu_head structure to initialize.
+ *
+ * If you intend to invoke is_after_call_rcu() to test whether a given
+ * rcu_head structure has already been passed to call_rcu(), then you must
+ * also invoke this is_after_call_rcu_init() function on it just after
+ * allocating that structure. Calls to this function must not race with
+ * calls to call_rcu(), is_after_call_rcu(), or callback invocation.
+ */
+static inline void is_after_call_rcu_init(struct rcu_head *rhp)
+{
+ rhp->func = (rcu_callback_t)~0L;
+}
+
+/*
+ * is_after_call_rcu - Has this rcu_head been passed to call_rcu()?
+ * @rhp: The rcu_head structure to test.
+ * @func: The function passed to call_rcu() along with @rhp.
+ *
+ * Returns @true if the @rhp has been passed to call_rcu() with @func, and
+ * @false otherwise. Emits a warning in any other case, including the
+ * case where @rhp has already been invoked after a grace period.
+ * Calls to this function must not race with callback invocation. One
+ * way to avoid such races is to enclose the call to is_after_call_rcu()
+ * in an RCU read-side critical section that includes a read-side fetch
+ * of the pointer to the structure containing @rhp.
+ */
+static inline bool is_after_call_rcu(struct rcu_head *rhp, rcu_callback_t f)
+{
+ if (READ_ONCE(rhp->func) == f)
+ return true;
+ WARN_ON_ONCE(READ_ONCE(rhp->func) != (rcu_callback_t)~0L);
+ return false;
+}
+
+
/* Transitional pre-consolidation compatibility definitions. */
static inline void synchronize_rcu_bh(void)
diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
index 5dec94509a7e..4c56c1d98fb3 100644
--- a/kernel/rcu/rcu.h
+++ b/kernel/rcu/rcu.h
@@ -224,6 +224,7 @@ void kfree(const void *);
*/
static inline bool __rcu_reclaim(const char *rn, struct rcu_head *head)
{
+ rcu_callback_t f;
unsigned long offset = (unsigned long)head->func;
rcu_lock_acquire(&rcu_callback_map);
@@ -234,7 +235,9 @@ static inline bool __rcu_reclaim(const char *rn, struct rcu_head *head)
return true;
} else {
RCU_TRACE(trace_rcu_invoke_callback(rn, head);)
- head->func(head);
+ f = head->func;
+ WRITE_ONCE(head->func, (rcu_callback_t)0L);
+ f(head);
rcu_lock_release(&rcu_callback_map);
return false;
}
^ permalink raw reply related
* Re: [PATCH net-next] virtio_net: force_napi_tx module param.
From: Michael S. Tsirkin @ 2018-07-24 22:46 UTC (permalink / raw)
To: Willem de Bruijn
Cc: caleb.raitto, Jason Wang, David Miller, Network Development,
Caleb Raitto
In-Reply-To: <CAF=yD-J4kS5SiEum-d7SfY7wF+go746QMkoer49G+knVSXtVGg@mail.gmail.com>
On Tue, Jul 24, 2018 at 06:31:54PM -0400, Willem de Bruijn wrote:
> On Tue, Jul 24, 2018 at 6:23 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Tue, Jul 24, 2018 at 04:52:53PM -0400, Willem de Bruijn wrote:
> > > >From the above linked patch, I understand that there are yet
> > > other special cases in production, such as a hard cap on #tx queues to
> > > 32 regardless of number of vcpus.
> >
> > I don't think upstream kernels have this limit - we can
> > now use vmalloc for higher number of queues.
>
> Yes. that patch* mentioned it as a google compute engine imposed
> limit. It is exactly such cloud provider imposed rules that I'm
> concerned about working around in upstream drivers.
>
> * for reference, I mean https://patchwork.ozlabs.org/patch/725249/
Yea. Why does GCE do it btw?
--
MST
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2018-07-24 23:51 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Handle stations tiest to AP_VLANs properly during mac80211 hw
reconfig. From Manikanta Pubbisetty.
2) Fix jump stack depth validation in nf_tables, from Taehee Yoo.
3) Fix quota handling in aRFS flow expiration of mlx5 driver, from
Eran Ben Elisha.
4) Exit path handling fix in powerpc64 BPF JIT, from Daniel Borkmann.
5) Use ptr_ring_consume_bh() in page pool code, from Tariq Toukan.
6) Fix cached netdev name leak in nf_tables, from Florian Westphal.
7) Fix memory leaks on chain rename, also from Florian Westphal.
8) Several fixes to DCTCP congestion control ACK handling, from
Yuchunk Cheng.
9) Missing rcu_read_unlock() in CAIF protocol code, from Yue Haibing.
10) Fix link local address handling with VRF, from David Ahern.
11) Don't clobber 'err' on a successful call to __skb_linearize()
in skb_segment(). From Eric Dumazet.
12) Fix vxlan fdb notification races, from Roopa Prabhu.
13) Hash UDP framgnets consistently, from Paolo Abeni.
14) If TCP receives lots of out of order tiny packets, we do really
silly stuff. Make the out-of-order queue ending more robust to
this kind of behavior, from Eric Dumazet.
15) Don't leak netlink dump state in nf_tables, from Florian Westphal.
Please pull, thanks a lot!
The following changes since commit f39f28ff82c14b4f628973d9bba835195a71d437:
Merge tag 'sound-4.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound (2018-07-19 07:43:17 -0700)
are available in the Git repository at:
gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 03bc7cab7d7218088412a75e141696a89059ab00:
net: axienet: Fix double deregister of mdio (2018-07-24 16:38:01 -0700)
----------------------------------------------------------------
Aleksander Morgado (1):
qmi_wwan: fix interface number for DW5821e production firmware
Alexei Starovoitov (1):
Merge branch 'ppc-fix'
Amar Singhal (1):
cfg80211: never ignore user regulatory hint
Anssi Hannula (7):
can: xilinx_can: fix device dropping off bus on RX overrun
can: xilinx_can: fix RX loop if RXNEMP is asserted without RXOK
can: xilinx_can: fix recovery from error states not being propagated
can: xilinx_can: keep only 1-2 frames in TX FIFO to fix TX accounting
can: xilinx_can: fix RX overflow interrupt not being enabled
can: xilinx_can: fix incorrect clear of non-processed interrupts
can: xilinx_can: fix power management handling
Ariel Levkovich (1):
net/mlx5: Adjust clock overflow work period
Bernd Edlinger (1):
nl80211: Add a missing break in parse_station_flags
Daniel Borkmann (3):
bpf, ppc64: fix unexpected r0=0 exit path inside bpf_xadd
bpf: test case to check whether src/dst regs got mangled by xadd
sock: fix sg page frag coalescing in sk_alloc_sg
David Ahern (1):
net/ipv6: Fix linklocal to global address with VRF
David S. Miller (9):
Merge branch 'tcp-fix-DCTCP-ECE-Ack-series'
Merge git://git.kernel.org/.../bpf/bpf
Merge tag 'mlx5-fixes-2018-07-18' of git://git.kernel.org/.../saeed/linux
Merge branch 'qed-Fix-series-II'
Merge branch 'vxlan-fix-default-fdb-entry-user-space-notify-ordering-race'
Merge tag 'linux-can-fixes-for-4.18-20180723' of ssh://gitolite.kernel.org/.../mkl/linux-can
Merge branch 'tcp-robust-ooo'
Merge tag 'mac80211-for-davem-2018-07-24' of git://git.kernel.org/.../jberg/mac80211
Merge git://git.kernel.org/.../pablo/nf
Denis Kenzior (1):
nl80211/mac80211: allow non-linear skb in rx_control_port
Doron Roberts-Kedes (1):
tls: check RCV_SHUTDOWN in tls_wait_data
Eran Ben Elisha (2):
net/mlx5e: Fix quota counting in aRFS expire flow
net/mlx5e: Don't allow aRFS for encapsulated packets
Eric Dumazet (6):
net: skb_segment() should not return NULL
tcp: free batches of packets in tcp_prune_ofo_queue()
tcp: avoid collapses in tcp_prune_queue() if possible
tcp: detect malicious patterns in tcp_collapse_ofo_queue()
tcp: call tcp_drop() from tcp_data_queue_ofo()
tcp: add tcp_ooo_try_coalesce() helper
Faiz Abbas (2):
can: m_can: Fix runtime resume call
can: m_can: Move accessing of message ram to after clocks are enabled
Florian Westphal (7):
netfilter: nf_tables: use dev->name directly
netfilter: nf_tables: free flow table struct too
netfilter: nf_tables: fix memory leaks on chain rename
netfilter: nf_tables: don't allow to rename to already-pending name
netfilter: conntrack: dccp: treat SYNC/SYNCACK as invalid if no prior state
atl1c: reserve min skb headroom
netfilter: nf_tables: move dumper state allocation into ->start
Hangbin Liu (1):
multicast: do not restore deleted record source filter mode to new one
Heiner Kallweit (2):
net: phy: consider PHY_IGNORE_INTERRUPT in phy_start_aneg_priv
r8169: restore previous behavior to accept BIOS WoL settings
Jack Morgenstein (1):
net/mlx4_core: Save the qpn from the input modifier in RST2INIT wrapper
Jarod Wilson (1):
bonding: set default miimon value for non-arp modes if not set
John Hurley (1):
nfp: flower: ensure dead neighbour entries are not offloaded
Martin KaFai Lau (2):
bpf: btf: Clean up BTF_INT_BITS() in uapi btf.h
bpf: Use option "help" in the llvm-objcopy test
Nicholas Mc Guire (1):
can: mpc5xxx_can: check of_iomap return before use
Paolo Abeni (1):
ip: hash fragments consistently
Raed Salem (1):
net/mlx5: Fix 'DON'T_TRAP' functionality
Randy Dunlap (1):
net: prevent ISA drivers from building on PPC32
Roi Dayan (1):
net/mlx5e: Only allow offloading decap egress (egdev) flows
Roman Fietze (1):
can: m_can.c: fix setup of CCCR register: clear CCCR NISO bit before checking can.ctrlmode
Roopa Prabhu (4):
rtnetlink: add rtnl_link_state check in rtnl_configure_link
vxlan: add new fdb alloc and create helpers
vxlan: make netlink notify in vxlan_fdb_destroy optional
vxlan: fix default fdb entry netlink notify ordering during netdev create
Saeed Mahameed (1):
net/mlx5: E-Switch, UBSAN fix undefined behavior in mlx5_eswitch_mode
Shay Agroskin (1):
net/mlx5e: Refine ets validation function
Shubhrajyoti Datta (1):
net: axienet: Fix double deregister of mdio
Stephane Grosjean (1):
can: peak_canfd: fix firmware < v3.3.0: limit allocation to 32-bit DMA addr only
Sudarsana Reddy Kalluru (4):
qed: Fix link flap issue due to mismatching EEE capabilities.
qed: Fix possible race for the link state value.
qed: Correct Multicast API to reflect existence of 256 approximate buckets.
bnx2x: Fix invalid memory access in rss hash config path.
Taehee Yoo (3):
netfilter: nf_tables: fix jumpstack depth validation
netfilter: nft_set_hash: add rcu_barrier() in the nft_rhash_destroy()
netfilter: nft_set_rbtree: fix panic when destroying set by GC
Taeung Song (1):
tools/bpftool: Fix segfault case regarding 'pin' arguments
Tariq Toukan (2):
net/mlx5: Fix QP fragmented buffer allocation
net/page_pool: Fix inconsistent lock state warning
Uwe Kleine-König (1):
net: dsa: mv88e6xxx: fix races between lock and irq freeing
Wei Wang (1):
ipv6: use fib6_info_hold_safe() when necessary
Willem de Bruijn (1):
ip: in cmsg IP(V6)_ORIGDSTADDR call pskb_may_pull
Yuchung Cheng (3):
tcp: helpers to send special DCTCP ack
tcp: do not cancel delay-AcK on DCTCP special ACK
tcp: do not delay ACK in DCTCP upon CE status change
YueHaibing (2):
net: caif: Add a missing rcu_read_unlock() in caif_flow_cb
bpfilter: Fix mismatch in function argument types
Zhao Chen (1):
net-next/hinic: fix a problem in hinic_xmit_frame()
mpubbise@codeaurora.org (1):
mac80211: add stations tied to AP_VLANs during hw reconfig
arch/powerpc/net/bpf_jit_comp64.c | 29 ++-----
drivers/net/bonding/bond_options.c | 23 +++---
drivers/net/can/m_can/m_can.c | 18 ++---
drivers/net/can/mscan/mpc5xxx_can.c | 5 ++
drivers/net/can/peak_canfd/peak_pciefd_main.c | 19 +++++
drivers/net/can/xilinx_can.c | 392 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------
drivers/net/dsa/mv88e6xxx/chip.c | 21 +++--
drivers/net/ethernet/3com/Kconfig | 2 +-
drivers/net/ethernet/amd/Kconfig | 4 +-
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 13 +++-
drivers/net/ethernet/cirrus/Kconfig | 1 +
drivers/net/ethernet/huawei/hinic/hinic_tx.c | 1 +
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/alloc.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c | 7 +-
drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 17 ++---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 4 +
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c | 12 ++-
drivers/net/ethernet/mellanox/mlx5/core/wq.c | 34 ++++++---
drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c | 2 +-
drivers/net/ethernet/qlogic/qed/qed_l2.c | 15 ++--
drivers/net/ethernet/qlogic/qed/qed_l2.h | 2 +-
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 13 +++-
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 2 +-
drivers/net/ethernet/qlogic/qed/qed_vf.c | 4 +-
drivers/net/ethernet/qlogic/qed/qed_vf.h | 7 +-
drivers/net/ethernet/realtek/r8169.c | 3 +-
drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c | 1 +
drivers/net/phy/phy.c | 2 +-
drivers/net/usb/qmi_wwan.c | 2 +-
drivers/net/vxlan.c | 126 ++++++++++++++++++++----------
include/linux/bpfilter.h | 6 +-
include/linux/mlx5/driver.h | 18 ++++-
include/net/cfg80211.h | 12 +--
include/net/ip6_fib.h | 5 ++
include/net/netfilter/nf_tables.h | 5 +-
include/net/tcp.h | 7 ++
include/uapi/linux/btf.h | 2 +-
kernel/bpf/btf.c | 16 ++--
net/caif/caif_dev.c | 4 +-
net/core/page_pool.c | 2 +-
net/core/rtnetlink.c | 9 ++-
net/core/skbuff.c | 10 +--
net/core/sock.c | 6 +-
net/ipv4/igmp.c | 3 +-
net/ipv4/ip_output.c | 2 +
net/ipv4/ip_sockglue.c | 7 +-
net/ipv4/tcp_dctcp.c | 52 ++++---------
net/ipv4/tcp_input.c | 65 ++++++++++++----
net/ipv4/tcp_output.c | 32 ++++++--
net/ipv6/addrconf.c | 3 +-
net/ipv6/datagram.c | 7 +-
net/ipv6/icmp.c | 5 +-
net/ipv6/ip6_output.c | 2 +
net/ipv6/mcast.c | 3 +-
net/ipv6/route.c | 41 +++++++---
net/ipv6/tcp_ipv6.c | 6 +-
net/mac80211/rx.c | 5 +-
net/mac80211/util.c | 3 +-
net/netfilter/nf_conntrack_proto_dccp.c | 8 +-
net/netfilter/nf_tables_api.c | 304 ++++++++++++++++++++++++++++++++++++++++---------------------------------
net/netfilter/nft_immediate.c | 3 +
net/netfilter/nft_lookup.c | 13 +++-
net/netfilter/nft_set_hash.c | 1 +
net/netfilter/nft_set_rbtree.c | 7 +-
net/tls/tls_sw.c | 3 +
net/wireless/nl80211.c | 25 +++---
net/wireless/reg.c | 28 +------
net/wireless/trace.h | 18 +++--
tools/bpf/bpftool/common.c | 11 ++-
tools/testing/selftests/bpf/Makefile | 2 +-
tools/testing/selftests/bpf/test_verifier.c | 40 ++++++++++
75 files changed, 1029 insertions(+), 562 deletions(-)
^ permalink raw reply
* Re: selftests/bpf test_sockmap failure
From: John Fastabend @ 2018-07-24 22:40 UTC (permalink / raw)
To: Yonghong Song, netdev; +Cc: Martin Lau
In-Reply-To: <fa8e6a0c-beee-a38b-dac9-d41c712f7345@fb.com>
On 07/24/2018 08:45 AM, Yonghong Song wrote:
> In one of our production machines, tools/testing/selftests/bpf
> test_sockmap failed randomly like below:
>
> ...
> [TEST 78]: (512, 1, 1, sendmsg, pass,apply 1,): rx thread exited with
> err 1. FAILED
> ...
>
> ...
> [TEST 80]: (2, 1024, 256, sendmsg, pass,apply 1,): rx thread exited with
> err 1. FAILED
> ...
>
> ...
> [TEST 83]: (100, 1, 5, sendpage, pass,apply 1,): rx thread exited with
> err 1. FAILED
> ...
>
> ...
> [TEST 79]: (512, 1, 1, sendpage, pass,apply 1,): rx thread exited with
> err 1. FAILED
> ...
>
> The command line is just `test_sockmap`. The machine has 80 cpus, 256G
> memory. The kernel is based on 4.16 but backported with latest bpf-next
> bpf changes.
>
> The failed test number (78, 79, 80, or 83) is random. But they all share
> similar characteristics:
> . the option rate is greater than one, i.e., more than one
> sendmsg/sendpage in the sender forked process.
> . The txmsg_apply is not 0
>
> I debugged a little bit. It happens in msg_loop() function below
> "unexpected timeout" path.
>
> ...
> slct = select(max_fd + 1, &w, NULL, NULL,
> &timeout);
> if (slct == -1) {
> perror("select()");
> clock_gettime(CLOCK_MONOTONIC, &s->end);
> goto out_errno;
> } else if (!slct) {
> if (opt->verbose)
> fprintf(stderr, "unexpected
> timeout\n");
> errno = -EIO;
> clock_gettime(CLOCK_MONOTONIC, &s->end);
> goto out_errno;
> }
> ...
>
> It appears that when the error happens, the receive process does not
> receive all bytes sent from the send process and eventually times out.
>
> Has anybody seen this issue as well?
> John, any comments on this failure?
Can you run the test with verbose enabled so we can determine if the tx
side is even sending the message? Sample patch below. This will allow
us to see the tx bytes and rx bytes, although it will be a bit noisy.
I notice that the test program is not smart enough to (re)send bytes if
the sendmsg call doesn't consume all bytes. This is a valid error if
we get a enomem or other normal error on the tx side. With apply this
is more likely because every byte (in apply = 1 case) is being sent
through BPF prog.
If this is not the case I can do some more digging but I've not seen
this before.
Thanks!
John
--- a/tools/testing/selftests/bpf/test_sockmap.c
+++ b/tools/testing/selftests/bpf/test_sockmap.c
@@ -1031,6 +1031,7 @@ static int test_exec(int cgrp, struct
sockmap_options *opt)
if (err)
goto out;
+ opt->verbose = true;
err = __test_exec(cgrp, SENDPAGE, opt);
out:
return err;
>
> Thanks,
>
> Yonghong
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: force_napi_tx module param.
From: Willem de Bruijn @ 2018-07-24 22:31 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: caleb.raitto, Jason Wang, David Miller, Network Development,
Caleb Raitto
In-Reply-To: <20180725012205-mutt-send-email-mst@kernel.org>
On Tue, Jul 24, 2018 at 6:23 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Tue, Jul 24, 2018 at 04:52:53PM -0400, Willem de Bruijn wrote:
> > >From the above linked patch, I understand that there are yet
> > other special cases in production, such as a hard cap on #tx queues to
> > 32 regardless of number of vcpus.
>
> I don't think upstream kernels have this limit - we can
> now use vmalloc for higher number of queues.
Yes. that patch* mentioned it as a google compute engine imposed
limit. It is exactly such cloud provider imposed rules that I'm
concerned about working around in upstream drivers.
* for reference, I mean https://patchwork.ozlabs.org/patch/725249/
^ permalink raw reply
* Re: [patch net-next v4 03/12] net: sched: introduce chain object to uapi
From: Cong Wang @ 2018-07-24 22:30 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Jakub Kicinski, Simon Horman, john.hurley, David Ahern, mlxsw,
sridhar.samudrala
In-Reply-To: <20180723072312.4153-4-jiri@resnulli.us>
On Mon, Jul 23, 2018 at 12:25 AM Jiri Pirko <jiri@resnulli.us> wrote:
> + switch (n->nlmsg_type) {
> + case RTM_NEWCHAIN:
> + /* In case the chain was successfully added, take a reference
> + * to the chain. This ensures that an empty chain
> + * does not disappear at the end of this function.
> + */
> + tcf_chain_hold(chain);
> + chain->explicitly_created = true;
> + tc_chain_notify(chain, NULL, 0, NLM_F_CREATE | NLM_F_EXCL,
> + RTM_NEWCHAIN, false);
> + break;
> + case RTM_DELCHAIN:
> + /* Flush the chain first as the user requested chain removal. */
> + tcf_chain_flush(chain);
> + /* In case the chain was successfully deleted, put a reference
> + * to the chain previously taken during addition.
> + */
> + tcf_chain_put_explicitly_created(chain);
> + break;
I don't see you send notification to user-space when deleting a chain,
am I missing anything?
^ permalink raw reply
* Re: [PATCH] net: axienet: Fix double deregister of mdio
From: David Miller @ 2018-07-24 23:38 UTC (permalink / raw)
To: shubhrajyoti.datta; +Cc: netdev, michal.simek, linux-kernel, shubhrajyoti.datta
In-Reply-To: <1532407193-21637-1-git-send-email-shubhrajyoti.datta@gmail.com>
From: <shubhrajyoti.datta@gmail.com>
Date: Tue, 24 Jul 2018 10:09:53 +0530
> From: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
>
> If the registration fails then mdio_unregister is called.
> However at unbind the unregister ia attempted again resulting
> in the below crash
...
> Fix the same by making the bus NULL on unregister.
>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] qmi_wwan: fix interface number for DW5821e production firmware
From: David Miller @ 2018-07-24 23:37 UTC (permalink / raw)
To: aleksander; +Cc: bjorn, netdev, linux-usb, stable
In-Reply-To: <20180723233107.15268-1-aleksander@aleksander.es>
From: Aleksander Morgado <aleksander@aleksander.es>
Date: Tue, 24 Jul 2018 01:31:07 +0200
> The original mapping for the DW5821e was done using a development
> version of the firmware. Confirmed with the vendor that the final
> USB layout ends up exposing the QMI control/data ports in USB
> config #1, interface #0, not in interface #1 (which is now a HID
> interface).
>
> T: Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 16 Spd=480 MxCh= 0
> D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 2
> P: Vendor=413c ProdID=81d7 Rev=03.18
> S: Manufacturer=DELL
> S: Product=DW5821e Snapdragon X20 LTE
> S: SerialNumber=0123456789ABCDEF
> C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
> I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
> I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
> I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
> I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
> I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
> I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
>
> Fixes: e7e197edd09c25 ("qmi_wwan: add support for the Dell Wireless 5821e module")
> Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: force_napi_tx module param.
From: Michael S. Tsirkin @ 2018-07-24 22:23 UTC (permalink / raw)
To: Willem de Bruijn
Cc: caleb.raitto, Jason Wang, David Miller, Network Development,
Caleb Raitto
In-Reply-To: <CAF=yD-KT4_yLq2OehHhdFc=9R0eRrKMHq2ae9NndJWqc+8h=LA@mail.gmail.com>
On Tue, Jul 24, 2018 at 04:52:53PM -0400, Willem de Bruijn wrote:
> >From the above linked patch, I understand that there are yet
> other special cases in production, such as a hard cap on #tx queues to
> 32 regardless of number of vcpus.
I don't think upstream kernels have this limit - we can
now use vmalloc for higher number of queues.
--
MST
^ permalink raw reply
* Re: [RFC PATCH ghak90 (was ghak32) V3 04/10] audit: add support for non-syscall auxiliary records
From: Paul Moore @ 2018-07-24 21:57 UTC (permalink / raw)
To: rgb
Cc: cgroups, containers, linux-api, linux-audit, linux-fsdevel,
linux-kernel, netdev, ebiederm, luto, jlayton, carlos, dhowells,
viro, simo, Eric Paris, serge
In-Reply-To: <20180724193725.k27la4ubg2g2n4qm@madcap2.tricolour.ca>
On Tue, Jul 24, 2018 at 3:40 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2018-07-20 18:14, Paul Moore wrote:
> > On Wed, Jun 6, 2018 at 1:01 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> > > Standalone audit records have the timestamp and serial number generated
> > > on the fly and as such are unique, making them standalone. This new
> > > function audit_alloc_local() generates a local audit context that will
> > > be used only for a standalone record and its auxiliary record(s). The
> > > context is discarded immediately after the local associated records are
> > > produced.
> > >
> > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > > ---
> > > include/linux/audit.h | 8 ++++++++
> > > kernel/auditsc.c | 25 +++++++++++++++++++++++--
> > > 2 files changed, 31 insertions(+), 2 deletions(-)
...
> > > + struct audit_context *context;
> > > +
> > > + if (!audit_ever_enabled)
> > > + return NULL; /* Return if not auditing. */
> > > +
> > > + context = audit_alloc_context(AUDIT_RECORD_CONTEXT);
> > > + if (!context)
> > > + return NULL;
> > > + context->serial = audit_serial();
> > > + context->ctime = current_kernel_time64();
> > > + context->in_syscall = 1;
> >
> > Setting in_syscall is both interesting and a bit troubling, if for no
> > other reason than I expect most (all?) callers to be in an interrupt
> > context when audit_alloc_local() is called. Setting in_syscall would
> > appear to be conceptually in this case. Can you help explain why this
> > is the right thing to do, or necessary to ensure things are handled
> > correctly?
>
> I'll admit this is cheating a bit, but seemed harmless. It is needed so
> that auditsc_get_stamp() from audit_get_stamp() from audit_log_start()
> doesn't bail on me without giving me its already assigned time and
> serial values rather than generating a new one. I did look to see if
> there were any other undesireable side effects and found none, so I'm
> tmepted to rename the ->in_syscall to something a bit more helpful. I
> could add a new audit_context structure member to make
> auditsc_get_stamp() co-operative, but this seems wasteful and
> unnecessary.
That's what I suspected.
Let's look into renaming the "in_syscall" field, it borderline
confusing now, and hijacking it for something which is very obviously
not "in syscall" is A Very Bad Thing.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH ghak90 (was ghak32) V3 01/10] audit: add container id
From: Paul Moore @ 2018-07-24 21:54 UTC (permalink / raw)
To: rgb
Cc: cgroups, containers, linux-api, linux-audit, linux-fsdevel,
linux-kernel, netdev, ebiederm, luto, jlayton, carlos, dhowells,
viro, simo, Eric Paris, serge
In-Reply-To: <20180724190613.ww6yhsqpa7n4s62k@madcap2.tricolour.ca>
On Tue, Jul 24, 2018 at 3:09 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2018-07-20 18:13, Paul Moore wrote:
> > On Wed, Jun 6, 2018 at 1:00 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> > > Implement the proc fs write to set the audit container identifier of a
> > > process, emitting an AUDIT_CONTAINER_ID record to document the event.
> > >
> > > This is a write from the container orchestrator task to a proc entry of
> > > the form /proc/PID/audit_containerid where PID is the process ID of the
> > > newly created task that is to become the first task in a container, or
> > > an additional task added to a container.
> > >
> > > The write expects up to a u64 value (unset: 18446744073709551615).
> > >
> > > The writer must have capability CAP_AUDIT_CONTROL.
> > >
> > > This will produce a record such as this:
> > > type=CONTAINER_ID msg=audit(2018-06-06 12:39:29.636:26949) : op=set opid=2209 old-contid=18446744073709551615 contid=123456 pid=628 auid=root uid=root tty=ttyS0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 comm=bash exe=/usr/bin/bash res=yes
> > >
> > > The "op" field indicates an initial set. The "pid" to "ses" fields are
> > > the orchestrator while the "opid" field is the object's PID, the process
> > > being "contained". Old and new audit container identifier values are
> > > given in the "contid" fields, while res indicates its success.
> > >
> > > It is not permitted to unset or re-set the audit container identifier.
> > > A child inherits its parent's audit container identifier, but then can
> > > be set only once after.
> > >
> > > See: https://github.com/linux-audit/audit-kernel/issues/90
> > > See: https://github.com/linux-audit/audit-userspace/issues/51
> > > See: https://github.com/linux-audit/audit-testsuite/issues/64
> > > See: https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID
> > >
> > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > > ---
> > > fs/proc/base.c | 37 ++++++++++++++++++++++++
> > > include/linux/audit.h | 25 ++++++++++++++++
> > > include/uapi/linux/audit.h | 2 ++
> > > kernel/auditsc.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++
> > > 4 files changed, 135 insertions(+)
...
> > > @@ -2112,6 +2116,73 @@ int audit_set_loginuid(kuid_t loginuid)
> > > }
> > >
> > > /**
> > > + * audit_set_contid - set current task's audit_context contid
> > > + * @contid: contid value
> > > + *
> > > + * Returns 0 on success, -EPERM on permission failure.
> > > + *
> > > + * Called (set) from fs/proc/base.c::proc_contid_write().
> > > + */
> > > +int audit_set_contid(struct task_struct *task, u64 contid)
> > > +{
> > > + u64 oldcontid;
> > > + int rc = 0;
> > > + struct audit_buffer *ab;
> > > + uid_t uid;
> > > + struct tty_struct *tty;
> > > + char comm[sizeof(current->comm)];
> > > +
> > > + /* Can't set if audit disabled */
> > > + if (!task->audit)
> > > + return -ENOPROTOOPT;
> > > + oldcontid = audit_get_contid(task);
> > > + /* Don't allow the audit containerid to be unset */
> > > + if (!cid_valid(contid))
> > > + rc = -EINVAL;
> > > + /* if we don't have caps, reject */
> > > + else if (!capable(CAP_AUDIT_CONTROL))
> > > + rc = -EPERM;
> > > + /* if task has children or is not single-threaded, deny */
> > > + else if (!list_empty(&task->children))
> > > + rc = -EBUSY;
> >
> > Is this safe without holding tasklist_lock? I worry we might be
> > vulnerable to a race with fork().
> >
> > > + else if (!(thread_group_leader(task) && thread_group_empty(task)))
> > > + rc = -EALREADY;
> >
> > Similar concern here as well, although related to threads.
>
> I think you are correct here and tasklist_lock should cover both. Do we
> also want rcu_read_lock() immediately preceeding it?
You'll need to take a closer look and determine the locking scheme. I
simply took a quick look while reviewing this patch to see what of the
existing locks, if any, would be most applicable here; tasklist_lock
seemed like a good starting point.
It looks like tasklist_lock is defined as a rwlock_t so I'm not sure
it would make sense to use it with a RCU protected structure
(typically it's RCU+spinlock), but maybe that is the case with a
task_struct, you'll need to check.
> > > + /* it is already set, and not inherited from the parent, reject */
> > > + else if (cid_valid(oldcontid) && !task->audit->inherited)
> > > + rc = -EEXIST;
> >
> > Maybe I'm missing something, but why do we care about preventing
> > reassigning the audit container ID in this case? The task is single
> > threaded and has no descendants at this point so it should be safe,
> > yes? So long as the task changing the audit container ID has
> > capable(CAP_AUDIT_CONTOL) it shouldn't matter, right?
>
> Because we hammered out this idea 6 months ago in the design phase and I
> thought we all firmly agreed that the audit container identifier could
> only be set once. Has any significant discussion happenned since then
> to change that wisdom? I just wonder why this is coming up now.
Implementation, and time, can change how one looks at an earlier
design. I believe this is why most well reasoned specifications have
a reference design.
Remind me why the design had the restriction of write once for the
audit container ID? At this point given the CAP_AUDIT_CONTROL and the
single-thread, no-children restrictions I'm not sure what harm there
is in allowing the value to be written multiple times (so long as the
changes are audited of course).
> > Related, I'm questioning if we would ever care if the audit container
> > ID was inherited or not?
>
> We do since that is the only way we can tell if the value has been set
> once already or inherited unless we check if the parent's audit
> container identifier is identical (which tells us it was inherited).
Tied to the above question. If we don't care about multiple changes,
given the other constraints, we probably don't need the inherited
flag.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH net-next] bnxt_en: Fix logic of forward the VF MAC address to PF in bnxt_vf_validate_set_mac
From: Michael Chan @ 2018-07-24 21:48 UTC (permalink / raw)
To: Vasundhara Volam; +Cc: YueHaibing, David Miller, open list, Netdev
In-Reply-To: <CAACQVJrS9_fCNG3g51q7kZnTt5wy1X-SrvXTsFq=zqZEUvVS5Q@mail.gmail.com>
On Tue, Jul 24, 2018 at 9:01 AM, Vasundhara Volam
<vasundhara-v.volam@broadcom.com> wrote:
> On Tue, Jul 24, 2018 at 1:01 PM, Michael Chan <michael.chan@broadcom.com> wrote:
>>
>> On Mon, Jul 23, 2018 at 10:24 PM, YueHaibing <yuehaibing@huawei.com> wrote:
>> > Based on the comments,req->l2addr must match the VF MAC address
>> > if firmware spec >= 1.2.2, mac_ok can be true.
>> >
>> > Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>> > ---
>> > drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 7 ++-----
>> > 1 file changed, 2 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
>> > index a649108..7925964 100644
>> > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
>> > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
>> > @@ -954,12 +954,9 @@ static int bnxt_vf_validate_set_mac(struct bnxt *bp, struct bnxt_vf_info *vf)
>> > if (ether_addr_equal((const u8 *)req->l2_addr, vf->mac_addr))
>> > mac_ok = true;
>> > } else if (is_valid_ether_addr(vf->vf_mac_addr)) {
>> > - if (ether_addr_equal((const u8 *)req->l2_addr, vf->vf_mac_addr))
>> > + if (ether_addr_equal((const u8 *)req->l2_addr, vf->vf_mac_addr) &&
>> > + bp->hwrm_spec_code >= 0x10202)
>> > mac_ok = true;
>>
>> I'm not sure if this is correct. If firmware spec < 0x10202, the VF
>> MAC address is not forwarded to the PF and so it doesn't have to match
>> and mac_ok should still be true. I think we are missing that
>> condition with this patch.
>>
>> I need to let my colleague Vasundhara comment on this. She is more
>> familiar with this logic.
> Yes Michael, you are right. Also, the plain else condition is to cover
> a special case to allow VF to modify
> it's own MAC when PF has not assigned a valid MAC address and HWRM
> spec code > 0x10202.
We should combine the "else if" and "else" below into a plain else and
add some comments to explain the conditions.
>>
>> > - } else if (bp->hwrm_spec_code < 0x10202) {
>> > - mac_ok = true;
>> > - } else {
>> > - mac_ok = true;
>> > }
>> > if (mac_ok)
>> > return bnxt_hwrm_exec_fwd_resp(bp, vf, msg_size);
>> > --
>> > 2.7.0
>> >
>> >
^ permalink raw reply
* Re: [PATCH v5 net-next] net/sched: add skbprio scheduler
From: David Miller @ 2018-07-24 21:43 UTC (permalink / raw)
To: ndev2021; +Cc: xiyou.wangcong, jhs, jiri, netdev, doucette, michel
In-Reply-To: <20180723140735.GA6935@gmail.com>
From: Nishanth Devarajan <ndev2021@gmail.com>
Date: Mon, 23 Jul 2018 19:37:41 +0530
> net/sched: add skbprio scheduler
Applied to net-next, thank you.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: phy: add GBit master / slave error detection
From: David Miller @ 2018-07-24 21:41 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <83ad664d-6a0b-9da8-49c0-e464908b441d@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat, 21 Jul 2018 15:48:47 +0200
> Certain PHY's have issues when operating in GBit slave mode and can
> be forced to master mode. Examples are RTL8211C, also the Micrel PHY
> driver has a DT setting to force master mode.
> If two such chips are link partners the autonegotiation will fail.
> Standard defines a self-clearing on read, latched-high bit to
> indicate this error. Check this bit to inform the user.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> v2:
> - Use different error messages depending on whether local PHY uses
> manual master/slave configuration.
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] tls: Skip zerocopy path for ITER_KVEC
From: David Miller @ 2018-07-24 21:40 UTC (permalink / raw)
To: doronrk; +Cc: davejwatson, netdev
In-Reply-To: <20180724.143802.309217898930041106.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 24 Jul 2018 14:38:02 -0700 (PDT)
> From: Doron Roberts-Kedes <doronrk@fb.com>
> Date: Fri, 20 Jul 2018 11:19:00 -0700
>
>> The zerocopy path ultimately calls iov_iter_get_pages, which defines the
>> step function for ITER_KVECs as simply, return -EFAULT. Taking the
>> non-zerocopy path for ITER_KVECs avoids the unnecessary fallback.
>>
>> See https://lore.kernel.org/lkml/20150401023311.GL29656@ZenIV.linux.org.uk/T/#u
>> for a discussion of why zerocopy for vmalloc data is not a good idea.
>>
>> Discovered while testing NBD traffic encrypted with ktls.
>>
>> Fixes: c46234ebb4d1 ("tls: RX path for ktls")
>> Signed-off-by: Doron Roberts-Kedes <doronrk@fb.com>
>
> Applied to net-next, thanks.
Actually, I reverted. Please fix this warning:
net/tls/tls_sw.c: In function ‘tls_sw_sendmsg’:
net/tls/tls_sw.c:414:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
bool iskvec = msg->msg_iter.type & ITER_KVEC;
^~~~
net/tls/tls_sw.c: In function ‘tls_sw_recvmsg’:
net/tls/tls_sw.c:823:4: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
bool iskvec = msg->msg_iter.type & ITER_KVEC;
^~~~
^ permalink raw reply
* Re: [PATCH net-next] tls: Skip zerocopy path for ITER_KVEC
From: David Miller @ 2018-07-24 21:38 UTC (permalink / raw)
To: doronrk; +Cc: davejwatson, netdev
In-Reply-To: <20180720181900.1073485-1-doronrk@fb.com>
From: Doron Roberts-Kedes <doronrk@fb.com>
Date: Fri, 20 Jul 2018 11:19:00 -0700
> The zerocopy path ultimately calls iov_iter_get_pages, which defines the
> step function for ITER_KVECs as simply, return -EFAULT. Taking the
> non-zerocopy path for ITER_KVECs avoids the unnecessary fallback.
>
> See https://lore.kernel.org/lkml/20150401023311.GL29656@ZenIV.linux.org.uk/T/#u
> for a discussion of why zerocopy for vmalloc data is not a good idea.
>
> Discovered while testing NBD traffic encrypted with ktls.
>
> Fixes: c46234ebb4d1 ("tls: RX path for ktls")
> Signed-off-by: Doron Roberts-Kedes <doronrk@fb.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next v3 5/5] act_mirred: use TC_ACT_REINJECT when possible
From: Cong Wang @ 2018-07-24 21:15 UTC (permalink / raw)
To: Paolo Abeni
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
Daniel Borkmann, Marcelo Ricardo Leitner, Eyal Birger,
David Miller
In-Reply-To: <612f6fb5b0cdddcbbc2d99f65b148b7f3b8b9a27.1532437050.git.pabeni@redhat.com>
On Tue, Jul 24, 2018 at 1:07 PM Paolo Abeni <pabeni@redhat.com> wrote:
> +
> + /* let's the caller reinject the packet, if possible */
> + if (skb_at_tc_ingress(skb)) {
> + res->ingress = want_ingress;
> + res->qstats = this_cpu_ptr(m->common.cpu_qstats);
> + return TC_ACT_REINJECT;
> + }
Looks good to me, but here we no longer return user-specified
return value here, I am sure it is safe for TC_ACT_STOLEN, but
I am not sure if it is safe for other values, like TC_ACT_RECLASSIFY.
Jamal, is there any use case of returning !TC_ACT_STOLEN for
ingress redirections?
Thanks.
^ permalink raw reply
* Re: [PATCH PATCH net-next 00/18] net whitespace cleanups
From: David Miller @ 2018-07-24 21:11 UTC (permalink / raw)
To: stephen
Cc: ericvh, rminnich, lucho, ralf, jreuter, pablo, kadlec, fw,
alex.aring, stefan, kuznet, yoshfuji, johannes, jhs,
xiyou.wangcong, jiri, vyasevich, nhorman, marcelo.leitner,
trond.myklebust, anna.schumaker, steffen.klassert, herbert,
netdev, v9fs-developer, linux-hams, ceph-devel, linux-decnet-user,
netfilter-devel, coreteam, linux-wpan, linux-s3
In-Reply-To: <20180724192918.31165-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 24 Jul 2018 12:29:00 -0700
> Ran script that I use to check for trailing whitespace and
> blank lines at end of files across all files in net/ directory.
> These are errors that checkpatch reports and git flags.
>
> These are the resulting fixes broken up mostly by subsystem.
I skipped 9p, ceph, and sunrpc since those don't go via my tree.
I applied the rest because it's mostly small and won't cause too
many conflicts in the future.
Thanks.
^ permalink raw reply
* Re: [PATCH net] r8169: restore previous behavior to accept BIOS WoL settings
From: David Miller @ 2018-07-24 21:07 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev, aacid
In-Reply-To: <a989358e-154b-86e4-ec9d-197454350f58@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Tue, 24 Jul 2018 22:21:04 +0200
> Commit 7edf6d314cd0 tried to resolve an inconsistency (BIOS WoL
> settings are accepted, but device isn't wakeup-enabled) resulting
> from a previous broken-BIOS workaround by making disabled WoL the
> default.
> This however had some side effects, most likely due to a broken BIOS
> some systems don't properly resume from suspend when the MagicPacket
> WoL bit isn't set in the chip, see
> https://bugzilla.kernel.org/show_bug.cgi?id=200195
> Therefore restore the WoL behavior from 4.16.
>
> Reported-by: Albert Astals Cid <aacid@kde.org>
> Fixes: 7edf6d314cd0 ("r8169: disable WOL per default")
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied and queued up for -stable.
> This patch will cause a trivial merge conflict when merging net
> to net-next.
Thanks for the heads up.
^ permalink raw reply
* your photos
From: Roland @ 2018-07-24 10:34 UTC (permalink / raw)
To: netdev
I would like to speak with the person that managing photos for your
company?
We provide image editing like – photos cutting out and retouching.
Enhancing your images is just a part of what we can do for your business.
Whether you’re an ecommerce
store or portrait photographer, real estate professional, or an e-Retailer,
we are your personal team
of photo editors that integrate seamlessly with your business.
Our mainly services are:
. Cut out, masking, clipping path, deep etching, transparent background
. Colour correction, black and white, light and shadows etc.
. Dust cleaning, spot cleaning
. Beauty retouching, skin retouching, face retouching, body retouching
. Fashion/Beauty Image Retouching
. Product image Retouching
. Real estate image Retouching
. Wedding & Event Album Design.
. Restoration and repair old images
. Vector Conversion
. Portrait image Retouching
We can provide you editing test on your photos.
Please reply if you are interested.
Thanks,
Roland
^ permalink raw reply
* Re: [PATCH 1/4] treewide: convert ISO_8859-1 text comments to utf-8
From: Jonathan Cameron @ 2018-07-24 21:04 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Morton, Joe Perches, Samuel Ortiz, David S. Miller,
Rob Herring, Michael Ellerman, linux-wireless, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux-crypto, linuxppc-dev,
linux-iio, linux-pm, lvs-devel, netfilter-devel, coreteam
In-Reply-To: <20180724111600.4158975-1-arnd@arndb.de>
On Tue, 24 Jul 2018 13:13:25 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> Almost all files in the kernel are either plain text or UTF-8
> encoded. A couple however are ISO_8859-1, usually just a few
> characters in a C comments, for historic reasons.
>
> This converts them all to UTF-8 for consistency.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
For IIO, Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Thanks for tidying this up.
Jonathan
> ---
> .../devicetree/bindings/net/nfc/pn544.txt | 2 +-
> arch/arm/boot/dts/sun4i-a10-inet97fv2.dts | 2 +-
> arch/arm/crypto/sha256_glue.c | 2 +-
> arch/arm/crypto/sha256_neon_glue.c | 4 +-
> drivers/crypto/vmx/ghashp8-ppc.pl | 12 +-
> drivers/iio/dac/ltc2632.c | 2 +-
> drivers/power/reset/ltc2952-poweroff.c | 4 +-
> kernel/events/callchain.c | 2 +-
> net/netfilter/ipvs/Kconfig | 8 +-
> net/netfilter/ipvs/ip_vs_mh.c | 4 +-
> tools/power/cpupower/po/de.po | 44 +++----
> tools/power/cpupower/po/fr.po | 120 +++++++++---------
> 12 files changed, 103 insertions(+), 103 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/nfc/pn544.txt b/Documentation/devicetree/bindings/net/nfc/pn544.txt
> index 538a86f7b2b0..72593f056b75 100644
> --- a/Documentation/devicetree/bindings/net/nfc/pn544.txt
> +++ b/Documentation/devicetree/bindings/net/nfc/pn544.txt
> @@ -2,7 +2,7 @@
>
> Required properties:
> - compatible: Should be "nxp,pn544-i2c".
> -- clock-frequency: I_C work frequency.
> +- clock-frequency: I²C work frequency.
> - reg: address on the bus
> - interrupt-parent: phandle for the interrupt gpio controller
> - interrupts: GPIO interrupt to which the chip is connected
> diff --git a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> index 5d096528e75a..71c27ea0b53e 100644
> --- a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> @@ -1,7 +1,7 @@
> /*
> * Copyright 2014 Open Source Support GmbH
> *
> - * David Lanzend_rfer <david.lanzendoerfer@o2s.ch>
> + * David Lanzendörfer <david.lanzendoerfer@o2s.ch>
> *
> * This file is dual-licensed: you can use it either under the terms
> * of the GPL or the X11 license, at your option. Note that this dual
> diff --git a/arch/arm/crypto/sha256_glue.c b/arch/arm/crypto/sha256_glue.c
> index bf8ccff2c9d0..0ae900e778f3 100644
> --- a/arch/arm/crypto/sha256_glue.c
> +++ b/arch/arm/crypto/sha256_glue.c
> @@ -2,7 +2,7 @@
> * Glue code for the SHA256 Secure Hash Algorithm assembly implementation
> * using optimized ARM assembler and NEON instructions.
> *
> - * Copyright _ 2015 Google Inc.
> + * Copyright © 2015 Google Inc.
> *
> * This file is based on sha256_ssse3_glue.c:
> * Copyright (C) 2013 Intel Corporation
> diff --git a/arch/arm/crypto/sha256_neon_glue.c b/arch/arm/crypto/sha256_neon_glue.c
> index 9bbee56fbdc8..1d82c6cd31a4 100644
> --- a/arch/arm/crypto/sha256_neon_glue.c
> +++ b/arch/arm/crypto/sha256_neon_glue.c
> @@ -2,10 +2,10 @@
> * Glue code for the SHA256 Secure Hash Algorithm assembly implementation
> * using NEON instructions.
> *
> - * Copyright _ 2015 Google Inc.
> + * Copyright © 2015 Google Inc.
> *
> * This file is based on sha512_neon_glue.c:
> - * Copyright _ 2014 Jussi Kivilinna <jussi.kivilinna@iki.fi>
> + * Copyright © 2014 Jussi Kivilinna <jussi.kivilinna@iki.fi>
> *
> * This program is free software; you can redistribute it and/or modify it
> * under the terms of the GNU General Public License as published by the Free
> diff --git a/drivers/crypto/vmx/ghashp8-ppc.pl b/drivers/crypto/vmx/ghashp8-ppc.pl
> index f746af271460..38b06503ede0 100644
> --- a/drivers/crypto/vmx/ghashp8-ppc.pl
> +++ b/drivers/crypto/vmx/ghashp8-ppc.pl
> @@ -129,9 +129,9 @@ $code=<<___;
> le?vperm $IN,$IN,$IN,$lemask
> vxor $zero,$zero,$zero
>
> - vpmsumd $Xl,$IN,$Hl # H.lo_Xi.lo
> - vpmsumd $Xm,$IN,$H # H.hi_Xi.lo+H.lo_Xi.hi
> - vpmsumd $Xh,$IN,$Hh # H.hi_Xi.hi
> + vpmsumd $Xl,$IN,$Hl # H.lo·Xi.lo
> + vpmsumd $Xm,$IN,$H # H.hi·Xi.lo+H.lo·Xi.hi
> + vpmsumd $Xh,$IN,$Hh # H.hi·Xi.hi
>
> vpmsumd $t2,$Xl,$xC2 # 1st phase
>
> @@ -187,11 +187,11 @@ $code=<<___;
> .align 5
> Loop:
> subic $len,$len,16
> - vpmsumd $Xl,$IN,$Hl # H.lo_Xi.lo
> + vpmsumd $Xl,$IN,$Hl # H.lo·Xi.lo
> subfe. r0,r0,r0 # borrow?-1:0
> - vpmsumd $Xm,$IN,$H # H.hi_Xi.lo+H.lo_Xi.hi
> + vpmsumd $Xm,$IN,$H # H.hi·Xi.lo+H.lo·Xi.hi
> and r0,r0,$len
> - vpmsumd $Xh,$IN,$Hh # H.hi_Xi.hi
> + vpmsumd $Xh,$IN,$Hh # H.hi·Xi.hi
> add $inp,$inp,r0
>
> vpmsumd $t2,$Xl,$xC2 # 1st phase
> diff --git a/drivers/iio/dac/ltc2632.c b/drivers/iio/dac/ltc2632.c
> index cca278eaa138..885105135580 100644
> --- a/drivers/iio/dac/ltc2632.c
> +++ b/drivers/iio/dac/ltc2632.c
> @@ -1,7 +1,7 @@
> /*
> * LTC2632 Digital to analog convertors spi driver
> *
> - * Copyright 2017 Maxime Roussin-B_langer
> + * Copyright 2017 Maxime Roussin-Bélanger
> * expanded by Silvan Murer <silvan.murer@gmail.com>
> *
> * Licensed under the GPL-2.
> diff --git a/drivers/power/reset/ltc2952-poweroff.c b/drivers/power/reset/ltc2952-poweroff.c
> index 6b911b6b10a6..c484584745bc 100644
> --- a/drivers/power/reset/ltc2952-poweroff.c
> +++ b/drivers/power/reset/ltc2952-poweroff.c
> @@ -2,7 +2,7 @@
> * LTC2952 (PowerPath) driver
> *
> * Copyright (C) 2014, Xsens Technologies BV <info@xsens.com>
> - * Maintainer: Ren_ Moll <linux@r-moll.nl>
> + * Maintainer: René Moll <linux@r-moll.nl>
> *
> * This program is free software; you can redistribute it and/or
> * modify it under the terms of the GNU General Public License
> @@ -319,6 +319,6 @@ static struct platform_driver ltc2952_poweroff_driver = {
>
> module_platform_driver(ltc2952_poweroff_driver);
>
> -MODULE_AUTHOR("Ren_ Moll <rene.moll@xsens.com>");
> +MODULE_AUTHOR("René Moll <rene.moll@xsens.com>");
> MODULE_DESCRIPTION("LTC PowerPath power-off driver");
> MODULE_LICENSE("GPL v2");
> diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
> index c187aa3df3c8..24a77c34e9ad 100644
> --- a/kernel/events/callchain.c
> +++ b/kernel/events/callchain.c
> @@ -4,7 +4,7 @@
> * Copyright (C) 2008 Thomas Gleixner <tglx@linutronix.de>
> * Copyright (C) 2008-2011 Red Hat, Inc., Ingo Molnar
> * Copyright (C) 2008-2011 Red Hat, Inc., Peter Zijlstra
> - * Copyright _ 2009 Paul Mackerras, IBM Corp. <paulus@au1.ibm.com>
> + * Copyright © 2009 Paul Mackerras, IBM Corp. <paulus@au1.ibm.com>
> *
> * For licensing details see kernel-base/COPYING
> */
> diff --git a/net/netfilter/ipvs/Kconfig b/net/netfilter/ipvs/Kconfig
> index 05dc1b77e466..cad48d07c818 100644
> --- a/net/netfilter/ipvs/Kconfig
> +++ b/net/netfilter/ipvs/Kconfig
> @@ -296,10 +296,10 @@ config IP_VS_MH_TAB_INDEX
> stored in a hash table. This table is assigned by a preference
> list of the positions to each destination until all slots in
> the table are filled. The index determines the prime for size of
> - the table as_251, 509, 1021, 2039, 4093, 8191, 16381, 32749,
> - 65521 or 131071._When using weights to allow destinations to
> - receive more connections,_the table is assigned an amount
> - proportional to the weights specified._The table needs to be large
> + the table as 251, 509, 1021, 2039, 4093, 8191, 16381, 32749,
> + 65521 or 131071. When using weights to allow destinations to
> + receive more connections, the table is assigned an amount
> + proportional to the weights specified. The table needs to be large
> enough to effectively fit all the destinations multiplied by their
> respective weights.
>
> diff --git a/net/netfilter/ipvs/ip_vs_mh.c b/net/netfilter/ipvs/ip_vs_mh.c
> index 0f795b186eb3..94d9d349ebb0 100644
> --- a/net/netfilter/ipvs/ip_vs_mh.c
> +++ b/net/netfilter/ipvs/ip_vs_mh.c
> @@ -5,10 +5,10 @@
> *
> */
>
> -/* The mh algorithm is to assign_a preference list of all the lookup
> +/* The mh algorithm is to assign a preference list of all the lookup
> * table positions to each destination and populate the table with
> * the most-preferred position of destinations. Then it is to select
> - * destination with the hash key of source IP address_through looking
> + * destination with the hash key of source IP address through looking
> * up a the lookup table.
> *
> * The algorithm is detailed in:
> diff --git a/tools/power/cpupower/po/de.po b/tools/power/cpupower/po/de.po
> index 78c09e51663a..840c17cc450a 100644
> --- a/tools/power/cpupower/po/de.po
> +++ b/tools/power/cpupower/po/de.po
> @@ -323,12 +323,12 @@ msgstr " Hardwarebedingte Grenzen der Taktfrequenz: "
> #: utils/cpufreq-info.c:256
> #, c-format
> msgid " available frequency steps: "
> -msgstr " m_gliche Taktfrequenzen: "
> +msgstr " mögliche Taktfrequenzen: "
>
> #: utils/cpufreq-info.c:269
> #, c-format
> msgid " available cpufreq governors: "
> -msgstr " m_gliche Regler: "
> +msgstr " mögliche Regler: "
>
> #: utils/cpufreq-info.c:280
> #, c-format
> @@ -381,7 +381,7 @@ msgstr "Optionen:\n"
> msgid " -e, --debug Prints out debug information [default]\n"
> msgstr ""
> " -e, --debug Erzeugt detaillierte Informationen, hilfreich\n"
> -" zum Aufsp_ren von Fehlern\n"
> +" zum Aufspüren von Fehlern\n"
>
> #: utils/cpufreq-info.c:475
> #, c-format
> @@ -424,7 +424,7 @@ msgstr " -p, --policy Findet die momentane Taktik heraus *\n"
> #: utils/cpufreq-info.c:482
> #, c-format
> msgid " -g, --governors Determines available cpufreq governors *\n"
> -msgstr " -g, --governors Erzeugt eine Liste mit verf_gbaren Reglern *\n"
> +msgstr " -g, --governors Erzeugt eine Liste mit verfügbaren Reglern *\n"
>
> #: utils/cpufreq-info.c:483
> #, c-format
> @@ -450,7 +450,7 @@ msgstr ""
> #, c-format
> msgid " -s, --stats Shows cpufreq statistics if available\n"
> msgstr ""
> -" -s, --stats Zeigt, sofern m_glich, Statistiken _ber cpufreq an.\n"
> +" -s, --stats Zeigt, sofern möglich, Statistiken über cpufreq an.\n"
>
> #: utils/cpufreq-info.c:487
> #, c-format
> @@ -473,9 +473,9 @@ msgid ""
> "cpufreq\n"
> " interface in 2.4. and early 2.6. kernels\n"
> msgstr ""
> -" -o, --proc Erzeugt Informationen in einem _hnlichem Format zu "
> +" -o, --proc Erzeugt Informationen in einem ähnlichem Format zu "
> "dem\n"
> -" der /proc/cpufreq-Datei in 2.4. und fr_hen 2.6.\n"
> +" der /proc/cpufreq-Datei in 2.4. und frühen 2.6.\n"
> " Kernel-Versionen\n"
>
> #: utils/cpufreq-info.c:491
> @@ -491,7 +491,7 @@ msgstr ""
> #: utils/cpufreq-info.c:492 utils/cpuidle-info.c:152
> #, c-format
> msgid " -h, --help Prints out this screen\n"
> -msgstr " -h, --help Gibt diese Kurz_bersicht aus\n"
> +msgstr " -h, --help Gibt diese Kurzübersicht aus\n"
>
> #: utils/cpufreq-info.c:495
> #, c-format
> @@ -501,7 +501,7 @@ msgid ""
> msgstr ""
> "Sofern kein anderer Parameter als '-c, --cpu' angegeben wird, liefert "
> "dieses\n"
> -"Programm Informationen, die z.B. zum Berichten von Fehlern n_tzlich sind.\n"
> +"Programm Informationen, die z.B. zum Berichten von Fehlern nützlich sind.\n"
>
> #: utils/cpufreq-info.c:497
> #, c-format
> @@ -557,7 +557,7 @@ msgid ""
> "select\n"
> msgstr ""
> " -d FREQ, --min FREQ neue minimale Taktfrequenz, die der Regler\n"
> -" ausw_hlen darf\n"
> +" auswählen darf\n"
>
> #: utils/cpufreq-set.c:28
> #, c-format
> @@ -566,7 +566,7 @@ msgid ""
> "select\n"
> msgstr ""
> " -u FREQ, --max FREQ neue maximale Taktfrequenz, die der Regler\n"
> -" ausw_hlen darf\n"
> +" auswählen darf\n"
>
> #: utils/cpufreq-set.c:29
> #, c-format
> @@ -579,20 +579,20 @@ msgid ""
> " -f FREQ, --freq FREQ specific frequency to be set. Requires userspace\n"
> " governor to be available and loaded\n"
> msgstr ""
> -" -f FREQ, --freq FREQ setze exakte Taktfrequenz. Ben_tigt den Regler\n"
> +" -f FREQ, --freq FREQ setze exakte Taktfrequenz. Benötigt den Regler\n"
> " 'userspace'.\n"
>
> #: utils/cpufreq-set.c:32
> #, c-format
> msgid " -r, --related Switches all hardware-related CPUs\n"
> msgstr ""
> -" -r, --related Setze Werte f_r alle CPUs, deren Taktfrequenz\n"
> +" -r, --related Setze Werte für alle CPUs, deren Taktfrequenz\n"
> " hardwarebedingt identisch ist.\n"
>
> #: utils/cpufreq-set.c:33 utils/cpupower-set.c:28 utils/cpupower-info.c:27
> #, c-format
> msgid " -h, --help Prints out this screen\n"
> -msgstr " -h, --help Gibt diese Kurz_bersicht aus\n"
> +msgstr " -h, --help Gibt diese Kurzübersicht aus\n"
>
> #: utils/cpufreq-set.c:35
> #, fuzzy, c-format
> @@ -618,8 +618,8 @@ msgstr ""
> " angenommen\n"
> "2. Der Parameter -f bzw. --freq kann mit keinem anderen als dem Parameter\n"
> " -c bzw. --cpu kombiniert werden\n"
> -"3. FREQuenzen k_nnen in Hz, kHz (Standard), MHz, GHz oder THz eingegeben\n"
> -" werden, indem der Wert und unmittelbar anschlie_end (ohne Leerzeichen!)\n"
> +"3. FREQuenzen können in Hz, kHz (Standard), MHz, GHz oder THz eingegeben\n"
> +" werden, indem der Wert und unmittelbar anschließend (ohne Leerzeichen!)\n"
> " die Einheit angegeben werden. (Bsp: 1GHz )\n"
> " (FREQuenz in kHz =^ MHz * 1000 =^ GHz * 1000000).\n"
>
> @@ -638,7 +638,7 @@ msgid ""
> msgstr ""
> "Beim Einstellen ist ein Fehler aufgetreten. Typische Fehlerquellen sind:\n"
> "- nicht ausreichende Rechte (Administrator)\n"
> -"- der Regler ist nicht verf_gbar bzw. nicht geladen\n"
> +"- der Regler ist nicht verfügbar bzw. nicht geladen\n"
> "- die angegebene Taktik ist inkorrekt\n"
> "- eine spezifische Frequenz wurde angegeben, aber der Regler 'userspace'\n"
> " kann entweder hardwarebedingt nicht genutzt werden oder ist nicht geladen\n"
> @@ -821,7 +821,7 @@ msgstr ""
> #: utils/cpuidle-info.c:48
> #, fuzzy, c-format
> msgid "Available idle states:"
> -msgstr " m_gliche Taktfrequenzen: "
> +msgstr " mögliche Taktfrequenzen: "
>
> #: utils/cpuidle-info.c:71
> #, c-format
> @@ -924,7 +924,7 @@ msgstr "Aufruf: cpufreq-info [Optionen]\n"
> msgid " -s, --silent Only show general C-state information\n"
> msgstr ""
> " -e, --debug Erzeugt detaillierte Informationen, hilfreich\n"
> -" zum Aufsp_ren von Fehlern\n"
> +" zum Aufspüren von Fehlern\n"
>
> #: utils/cpuidle-info.c:150
> #, fuzzy, c-format
> @@ -933,9 +933,9 @@ msgid ""
> "acpi/processor/*/power\n"
> " interface in older kernels\n"
> msgstr ""
> -" -o, --proc Erzeugt Informationen in einem _hnlichem Format zu "
> +" -o, --proc Erzeugt Informationen in einem ähnlichem Format zu "
> "dem\n"
> -" der /proc/cpufreq-Datei in 2.4. und fr_hen 2.6.\n"
> +" der /proc/cpufreq-Datei in 2.4. und frühen 2.6.\n"
> " Kernel-Versionen\n"
>
> #: utils/cpuidle-info.c:209
> @@ -949,7 +949,7 @@ msgstr ""
> #~ " -c CPU, --cpu CPU CPU number which information shall be determined "
> #~ "about\n"
> #~ msgstr ""
> -#~ " -c CPU, --cpu CPU Nummer der CPU, _ber die Informationen "
> +#~ " -c CPU, --cpu CPU Nummer der CPU, über die Informationen "
> #~ "herausgefunden werden sollen\n"
>
> #~ msgid ""
> diff --git a/tools/power/cpupower/po/fr.po b/tools/power/cpupower/po/fr.po
> index 245ad20a9bf9..b46ca2548f86 100644
> --- a/tools/power/cpupower/po/fr.po
> +++ b/tools/power/cpupower/po/fr.po
> @@ -212,7 +212,7 @@ msgstr ""
> #: utils/cpupower.c:91
> #, c-format
> msgid "Report errors and bugs to %s, please.\n"
> -msgstr "Veuillez rapportez les erreurs et les bogues _ %s, s'il vous plait.\n"
> +msgstr "Veuillez rapportez les erreurs et les bogues à %s, s'il vous plait.\n"
>
> #: utils/cpupower.c:114
> #, c-format
> @@ -227,14 +227,14 @@ msgstr ""
> #: utils/cpufreq-info.c:31
> #, c-format
> msgid "Couldn't count the number of CPUs (%s: %s), assuming 1\n"
> -msgstr "D_termination du nombre de CPUs (%s : %s) impossible. Assume 1\n"
> +msgstr "Détermination du nombre de CPUs (%s : %s) impossible. Assume 1\n"
>
> #: utils/cpufreq-info.c:63
> #, c-format
> msgid ""
> " minimum CPU frequency - maximum CPU frequency - governor\n"
> msgstr ""
> -" Fr_quence CPU minimale - Fr_quence CPU maximale - r_gulateur\n"
> +" Fréquence CPU minimale - Fréquence CPU maximale - régulateur\n"
>
> #: utils/cpufreq-info.c:151
> #, c-format
> @@ -302,12 +302,12 @@ msgstr " pilote : %s\n"
> #: utils/cpufreq-info.c:219
> #, fuzzy, c-format
> msgid " CPUs which run at the same hardware frequency: "
> -msgstr " CPUs qui doivent changer de fr_quences en m_me temps : "
> +msgstr " CPUs qui doivent changer de fréquences en même temps : "
>
> #: utils/cpufreq-info.c:230
> #, fuzzy, c-format
> msgid " CPUs which need to have their frequency coordinated by software: "
> -msgstr " CPUs qui doivent changer de fr_quences en m_me temps : "
> +msgstr " CPUs qui doivent changer de fréquences en même temps : "
>
> #: utils/cpufreq-info.c:241
> #, c-format
> @@ -317,22 +317,22 @@ msgstr ""
> #: utils/cpufreq-info.c:247
> #, c-format
> msgid " hardware limits: "
> -msgstr " limitation mat_rielle : "
> +msgstr " limitation matérielle : "
>
> #: utils/cpufreq-info.c:256
> #, c-format
> msgid " available frequency steps: "
> -msgstr " plage de fr_quence : "
> +msgstr " plage de fréquence : "
>
> #: utils/cpufreq-info.c:269
> #, c-format
> msgid " available cpufreq governors: "
> -msgstr " r_gulateurs disponibles : "
> +msgstr " régulateurs disponibles : "
>
> #: utils/cpufreq-info.c:280
> #, c-format
> msgid " current policy: frequency should be within "
> -msgstr " tactique actuelle : la fr_quence doit _tre comprise entre "
> +msgstr " tactique actuelle : la fréquence doit être comprise entre "
>
> #: utils/cpufreq-info.c:282
> #, c-format
> @@ -345,18 +345,18 @@ msgid ""
> "The governor \"%s\" may decide which speed to use\n"
> " within this range.\n"
> msgstr ""
> -"Le r_gulateur \"%s\" est libre de choisir la vitesse\n"
> -" dans cette plage de fr_quences.\n"
> +"Le régulateur \"%s\" est libre de choisir la vitesse\n"
> +" dans cette plage de fréquences.\n"
>
> #: utils/cpufreq-info.c:293
> #, c-format
> msgid " current CPU frequency is "
> -msgstr " la fr_quence actuelle de ce CPU est "
> +msgstr " la fréquence actuelle de ce CPU est "
>
> #: utils/cpufreq-info.c:296
> #, c-format
> msgid " (asserted by call to hardware)"
> -msgstr " (v_rifi_ par un appel direct du mat_riel)"
> +msgstr " (vérifié par un appel direct du matériel)"
>
> #: utils/cpufreq-info.c:304
> #, c-format
> @@ -377,7 +377,7 @@ msgstr "Options :\n"
> #: utils/cpufreq-info.c:474
> #, fuzzy, c-format
> msgid " -e, --debug Prints out debug information [default]\n"
> -msgstr " -e, --debug Afficher les informations de d_boguage\n"
> +msgstr " -e, --debug Afficher les informations de déboguage\n"
>
> #: utils/cpufreq-info.c:475
> #, c-format
> @@ -385,8 +385,8 @@ msgid ""
> " -f, --freq Get frequency the CPU currently runs at, according\n"
> " to the cpufreq core *\n"
> msgstr ""
> -" -f, --freq Obtenir la fr_quence actuelle du CPU selon le point\n"
> -" de vue du coeur du syst_me de cpufreq *\n"
> +" -f, --freq Obtenir la fréquence actuelle du CPU selon le point\n"
> +" de vue du coeur du système de cpufreq *\n"
>
> #: utils/cpufreq-info.c:477
> #, c-format
> @@ -394,8 +394,8 @@ msgid ""
> " -w, --hwfreq Get frequency the CPU currently runs at, by reading\n"
> " it from hardware (only available to root) *\n"
> msgstr ""
> -" -w, --hwfreq Obtenir la fr_quence actuelle du CPU directement par\n"
> -" le mat_riel (doit _tre root) *\n"
> +" -w, --hwfreq Obtenir la fréquence actuelle du CPU directement par\n"
> +" le matériel (doit être root) *\n"
>
> #: utils/cpufreq-info.c:479
> #, c-format
> @@ -403,13 +403,13 @@ msgid ""
> " -l, --hwlimits Determine the minimum and maximum CPU frequency "
> "allowed *\n"
> msgstr ""
> -" -l, --hwlimits Affiche les fr_quences minimales et maximales du CPU "
> +" -l, --hwlimits Affiche les fréquences minimales et maximales du CPU "
> "*\n"
>
> #: utils/cpufreq-info.c:480
> #, c-format
> msgid " -d, --driver Determines the used cpufreq kernel driver *\n"
> -msgstr " -d, --driver Affiche le pilote cpufreq utilis_ *\n"
> +msgstr " -d, --driver Affiche le pilote cpufreq utilisé *\n"
>
> #: utils/cpufreq-info.c:481
> #, c-format
> @@ -420,7 +420,7 @@ msgstr " -p, --policy Affiche la tactique actuelle de cpufreq *\n"
> #, c-format
> msgid " -g, --governors Determines available cpufreq governors *\n"
> msgstr ""
> -" -g, --governors Affiche les r_gulateurs disponibles de cpufreq *\n"
> +" -g, --governors Affiche les régulateurs disponibles de cpufreq *\n"
>
> #: utils/cpufreq-info.c:483
> #, fuzzy, c-format
> @@ -429,7 +429,7 @@ msgid ""
> "frequency *\n"
> msgstr ""
> " -a, --affected-cpus Affiche quels sont les CPUs qui doivent changer de\n"
> -" fr_quences en m_me temps *\n"
> +" fréquences en même temps *\n"
>
> #: utils/cpufreq-info.c:484
> #, fuzzy, c-format
> @@ -438,7 +438,7 @@ msgid ""
> " coordinated by software *\n"
> msgstr ""
> " -a, --affected-cpus Affiche quels sont les CPUs qui doivent changer de\n"
> -" fr_quences en m_me temps *\n"
> +" fréquences en même temps *\n"
>
> #: utils/cpufreq-info.c:486
> #, c-format
> @@ -453,7 +453,7 @@ msgid ""
> " -y, --latency Determines the maximum latency on CPU frequency "
> "changes *\n"
> msgstr ""
> -" -l, --hwlimits Affiche les fr_quences minimales et maximales du CPU "
> +" -l, --hwlimits Affiche les fréquences minimales et maximales du CPU "
> "*\n"
>
> #: utils/cpufreq-info.c:488
> @@ -469,7 +469,7 @@ msgid ""
> " interface in 2.4. and early 2.6. kernels\n"
> msgstr ""
> " -o, --proc Affiche les informations en utilisant l'interface\n"
> -" fournie par /proc/cpufreq, pr_sente dans les "
> +" fournie par /proc/cpufreq, présente dans les "
> "versions\n"
> " 2.4 et les anciennes versions 2.6 du noyau\n"
>
> @@ -485,7 +485,7 @@ msgstr ""
> #: utils/cpufreq-info.c:492 utils/cpuidle-info.c:152
> #, c-format
> msgid " -h, --help Prints out this screen\n"
> -msgstr " -h, --help affiche l'aide-m_moire\n"
> +msgstr " -h, --help affiche l'aide-mémoire\n"
>
> #: utils/cpufreq-info.c:495
> #, c-format
> @@ -493,8 +493,8 @@ msgid ""
> "If no argument or only the -c, --cpu parameter is given, debug output about\n"
> "cpufreq is printed which is useful e.g. for reporting bugs.\n"
> msgstr ""
> -"Par d_faut, les informations de d_boguage seront affich_es si aucun\n"
> -"argument, ou bien si seulement l'argument -c (--cpu) est donn_, afin de\n"
> +"Par défaut, les informations de déboguage seront affichées si aucun\n"
> +"argument, ou bien si seulement l'argument -c (--cpu) est donné, afin de\n"
> "faciliter les rapports de bogues par exemple\n"
>
> #: utils/cpufreq-info.c:497
> @@ -517,8 +517,8 @@ msgid ""
> "You can't specify more than one --cpu parameter and/or\n"
> "more than one output-specific argument\n"
> msgstr ""
> -"On ne peut indiquer plus d'un param_tre --cpu, tout comme l'on ne peut\n"
> -"sp_cifier plus d'un argument de formatage\n"
> +"On ne peut indiquer plus d'un paramètre --cpu, tout comme l'on ne peut\n"
> +"spécifier plus d'un argument de formatage\n"
>
> #: utils/cpufreq-info.c:600 utils/cpufreq-set.c:82 utils/cpupower-set.c:42
> #: utils/cpupower-info.c:42 utils/cpuidle-info.c:213
> @@ -529,7 +529,7 @@ msgstr "option invalide\n"
> #: utils/cpufreq-info.c:617
> #, c-format
> msgid "couldn't analyze CPU %d as it doesn't seem to be present\n"
> -msgstr "analyse du CPU %d impossible puisqu'il ne semble pas _tre pr_sent\n"
> +msgstr "analyse du CPU %d impossible puisqu'il ne semble pas être présent\n"
>
> #: utils/cpufreq-info.c:620 utils/cpupower-info.c:142
> #, c-format
> @@ -547,8 +547,8 @@ msgid ""
> " -d FREQ, --min FREQ new minimum CPU frequency the governor may "
> "select\n"
> msgstr ""
> -" -d FREQ, --min FREQ nouvelle fr_quence minimale du CPU _ utiliser\n"
> -" par le r_gulateur\n"
> +" -d FREQ, --min FREQ nouvelle fréquence minimale du CPU à utiliser\n"
> +" par le régulateur\n"
>
> #: utils/cpufreq-set.c:28
> #, c-format
> @@ -556,13 +556,13 @@ msgid ""
> " -u FREQ, --max FREQ new maximum CPU frequency the governor may "
> "select\n"
> msgstr ""
> -" -u FREQ, --max FREQ nouvelle fr_quence maximale du CPU _ utiliser\n"
> -" par le r_gulateur\n"
> +" -u FREQ, --max FREQ nouvelle fréquence maximale du CPU à utiliser\n"
> +" par le régulateur\n"
>
> #: utils/cpufreq-set.c:29
> #, c-format
> msgid " -g GOV, --governor GOV new cpufreq governor\n"
> -msgstr " -g GOV, --governor GOV active le r_gulateur GOV\n"
> +msgstr " -g GOV, --governor GOV active le régulateur GOV\n"
>
> #: utils/cpufreq-set.c:30
> #, c-format
> @@ -570,9 +570,9 @@ msgid ""
> " -f FREQ, --freq FREQ specific frequency to be set. Requires userspace\n"
> " governor to be available and loaded\n"
> msgstr ""
> -" -f FREQ, --freq FREQ fixe la fr_quence du processeur _ FREQ. Il faut\n"
> -" que le r_gulateur _ userspace _ soit disponible \n"
> -" et activ_.\n"
> +" -f FREQ, --freq FREQ fixe la fréquence du processeur à FREQ. Il faut\n"
> +" que le régulateur « userspace » soit disponible \n"
> +" et activé.\n"
>
> #: utils/cpufreq-set.c:32
> #, c-format
> @@ -582,7 +582,7 @@ msgstr ""
> #: utils/cpufreq-set.c:33 utils/cpupower-set.c:28 utils/cpupower-info.c:27
> #, fuzzy, c-format
> msgid " -h, --help Prints out this screen\n"
> -msgstr " -h, --help affiche l'aide-m_moire\n"
> +msgstr " -h, --help affiche l'aide-mémoire\n"
>
> #: utils/cpufreq-set.c:35
> #, fuzzy, c-format
> @@ -602,11 +602,11 @@ msgid ""
> " (FREQuency in kHz =^ Hz * 0.001 =^ MHz * 1000 =^ GHz * 1000000).\n"
> msgstr ""
> "Remarque :\n"
> -"1. Le CPU num_ro 0 sera utilis_ par d_faut si -c (ou --cpu) est omis ;\n"
> -"2. l'argument -f FREQ (ou --freq FREQ) ne peut _tre utilis_ qu'avec --cpu ;\n"
> -"3. on pourra pr_ciser l'unit_ des fr_quences en postfixant sans aucune "
> +"1. Le CPU numéro 0 sera utilisé par défaut si -c (ou --cpu) est omis ;\n"
> +"2. l'argument -f FREQ (ou --freq FREQ) ne peut être utilisé qu'avec --cpu ;\n"
> +"3. on pourra préciser l'unité des fréquences en postfixant sans aucune "
> "espace\n"
> -" les valeurs par hz, kHz (par d_faut), MHz, GHz ou THz\n"
> +" les valeurs par hz, kHz (par défaut), MHz, GHz ou THz\n"
> " (kHz =^ Hz * 0.001 =^ MHz * 1000 =^ GHz * 1000000).\n"
>
> #: utils/cpufreq-set.c:57
> @@ -622,21 +622,21 @@ msgid ""
> "frequency\n"
> " or because the userspace governor isn't loaded?\n"
> msgstr ""
> -"En ajustant les nouveaux param_tres, une erreur est apparue. Les sources\n"
> +"En ajustant les nouveaux paramètres, une erreur est apparue. Les sources\n"
> "d'erreur typique sont :\n"
> -"- droit d'administration insuffisant (_tes-vous root ?) ;\n"
> -"- le r_gulateur choisi n'est pas disponible, ou bien n'est pas disponible "
> +"- droit d'administration insuffisant (êtes-vous root ?) ;\n"
> +"- le régulateur choisi n'est pas disponible, ou bien n'est pas disponible "
> "en\n"
> " tant que module noyau ;\n"
> "- la tactique n'est pas disponible ;\n"
> -"- vous voulez utiliser l'option -f/--freq, mais le r_gulateur _ userspace _\n"
> -" n'est pas disponible, par exemple parce que le mat_riel ne le supporte\n"
> -" pas, ou bien n'est tout simplement pas charg_.\n"
> +"- vous voulez utiliser l'option -f/--freq, mais le régulateur « userspace »\n"
> +" n'est pas disponible, par exemple parce que le matériel ne le supporte\n"
> +" pas, ou bien n'est tout simplement pas chargé.\n"
>
> #: utils/cpufreq-set.c:170
> #, c-format
> msgid "wrong, unknown or unhandled CPU?\n"
> -msgstr "CPU inconnu ou non support_ ?\n"
> +msgstr "CPU inconnu ou non supporté ?\n"
>
> #: utils/cpufreq-set.c:302
> #, c-format
> @@ -653,7 +653,7 @@ msgid ""
> "At least one parameter out of -f/--freq, -d/--min, -u/--max, and\n"
> "-g/--governor must be passed\n"
> msgstr ""
> -"L'un de ces param_tres est obligatoire : -f/--freq, -d/--min, -u/--max et\n"
> +"L'un de ces paramètres est obligatoire : -f/--freq, -d/--min, -u/--max et\n"
> "-g/--governor\n"
>
> #: utils/cpufreq-set.c:347
> @@ -810,7 +810,7 @@ msgstr ""
> #: utils/cpuidle-info.c:48
> #, fuzzy, c-format
> msgid "Available idle states:"
> -msgstr " plage de fr_quence : "
> +msgstr " plage de fréquence : "
>
> #: utils/cpuidle-info.c:71
> #, c-format
> @@ -911,7 +911,7 @@ msgstr "Usage : cpufreq-info [options]\n"
> #: utils/cpuidle-info.c:149
> #, fuzzy, c-format
> msgid " -s, --silent Only show general C-state information\n"
> -msgstr " -e, --debug Afficher les informations de d_boguage\n"
> +msgstr " -e, --debug Afficher les informations de déboguage\n"
>
> #: utils/cpuidle-info.c:150
> #, fuzzy, c-format
> @@ -921,7 +921,7 @@ msgid ""
> " interface in older kernels\n"
> msgstr ""
> " -o, --proc Affiche les informations en utilisant l'interface\n"
> -" fournie par /proc/cpufreq, pr_sente dans les "
> +" fournie par /proc/cpufreq, présente dans les "
> "versions\n"
> " 2.4 et les anciennes versions 2.6 du noyau\n"
>
> @@ -929,19 +929,19 @@ msgstr ""
> #, fuzzy, c-format
> msgid "You can't specify more than one output-specific argument\n"
> msgstr ""
> -"On ne peut indiquer plus d'un param_tre --cpu, tout comme l'on ne peut\n"
> -"sp_cifier plus d'un argument de formatage\n"
> +"On ne peut indiquer plus d'un paramètre --cpu, tout comme l'on ne peut\n"
> +"spécifier plus d'un argument de formatage\n"
>
> #~ msgid ""
> #~ " -c CPU, --cpu CPU CPU number which information shall be determined "
> #~ "about\n"
> #~ msgstr ""
> -#~ " -c CPU, --cpu CPU Num_ro du CPU pour lequel l'information sera "
> -#~ "affich_e\n"
> +#~ " -c CPU, --cpu CPU Numéro du CPU pour lequel l'information sera "
> +#~ "affichée\n"
>
> #~ msgid ""
> #~ " -c CPU, --cpu CPU number of CPU where cpufreq settings shall be "
> #~ "modified\n"
> #~ msgstr ""
> -#~ " -c CPU, --cpu CPU num_ro du CPU _ prendre en compte pour les\n"
> +#~ " -c CPU, --cpu CPU numéro du CPU à prendre en compte pour les\n"
> #~ " changements\n"
^ permalink raw reply
* Re: [PATCH RFC/RFT net-next 00/17] net: Convert neighbor tables to per-namespace
From: Cong Wang @ 2018-07-24 22:09 UTC (permalink / raw)
To: David Ahern
Cc: David Miller, Linux Kernel Network Developers, nikita.leshchenko,
Roopa Prabhu, Stephen Hemminger, Ido Schimmel, Jiri Pirko,
Saeed Mahameed, Alexander Aring, linux-wpan, NetFilter, LKML,
Eric W. Biederman
In-Reply-To: <5021d874-8e99-6eba-f24b-4257c62d4457@gmail.com>
On Tue, Jul 24, 2018 at 8:14 AM David Ahern <dsahern@gmail.com> wrote:
>
> On 7/19/18 11:12 AM, Cong Wang wrote:
> > On Thu, Jul 19, 2018 at 9:16 AM David Ahern <dsahern@gmail.com> wrote:
> >>
> >> Chatting with Nikolay about this and he brought up a good corollary - ip
> >> fragmentation. It really is a similar problem in that memory is consumed
> >> as a result of packets received from an external entity. The ipfrag
> >> sysctls are per namespace with a limit that non-init_net namespaces can
> >> not set high_thresh > the current value of init_net. Potential memory
> >> consumed by fragments scales with the number of namespaces which is the
> >> primary concern with making neighbor tables per namespace.
> >
> > Nothing new, already discussed:
> > https://marc.info/?l=linux-netdev&m=140391416215988&w=2
> >
> > :)
> >
>
> Neighbor tables, bridge fdbs, vxlan fdbs and ip fragments all consume
> local memory resources due to received packets. bridge and vxlan fdb's
> are fairly straightforward analogs to neighbor entries; they are per
> device with no limits on the number of entries. Fragments have memory
> limits per namespace. So neighbor tables are the only ones with this
> strict limitation and concern on memory consumption.
>
> I get the impression there is no longer a strong resistance against
> moving the tables to per namespace, but deciding what is the right
> approach to handle backwards compatibility. Correct? Changing the
> accounting is inevitably going to be noticeable to some use case(s), but
> with sysctl settings it is a simple runtime update once the user knows
> to make the change.
This question definitely should go to Eric Biederman who was against
my proposal.
Let's add Eric into CC.
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: force_napi_tx module param.
From: Willem de Bruijn @ 2018-07-24 20:52 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: caleb.raitto, Jason Wang, David Miller, Network Development,
Caleb Raitto
In-Reply-To: <20180724212238-mutt-send-email-mst@kernel.org>
On Tue, Jul 24, 2018 at 2:39 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Tue, Jul 24, 2018 at 10:01:39AM -0400, Willem de Bruijn wrote:
> > On Tue, Jul 24, 2018 at 6:44 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Mon, Jul 23, 2018 at 04:11:19PM -0700, Caleb Raitto wrote:
> > > > From: Caleb Raitto <caraitto@google.com>
> > > >
> > > > The driver disables tx napi if it's not certain that completions will
> > > > be processed affine with tx service.
> > > >
> > > > Its heuristic doesn't account for some scenarios where it is, such as
> > > > when the queue pair count matches the core but not hyperthread count.
> > > >
> > > > Allow userspace to override the heuristic. This is an alternative
> > > > solution to that in the linked patch. That added more logic in the
> > > > kernel for these cases, but the agreement was that this was better left
> > > > to user control.
> > > >
> > > > Do not expand the existing napi_tx variable to a ternary value,
> > > > because doing so can break user applications that expect
> > > > boolean ('Y'/'N') instead of integer output. Add a new param instead.
> > > >
> > > > Link: https://patchwork.ozlabs.org/patch/725249/
> > > > Acked-by: Willem de Bruijn <willemb@google.com>
> > > > Acked-by: Jon Olson <jonolson@google.com>
> > > > Signed-off-by: Caleb Raitto <caraitto@google.com>
> > >
> > > Is there a reason the same rule should apply to all devices?
> > > If not shouldn't this be an ethtool option?
> >
> > It not very likely that a guest will have multiple virtio_net devices,
> > some of which have affinity_hint_set and some do not?
>
> Just to answer this question, I do hear a lot about guests with multiple
> virtio net interfaces. These might be just the noisy few, but they do
> exist.
>
> > I'd really rather not add the extra option at all, but remove
> > the affinity_hint_set requirement for now. Without more data,
> > I understand the concern about cacheline bouncing if napi-tx
> > would becomes the default at some point and we don't have
> > data on this by then. But while it isn't default and a user has to
> > opt in to napi-tx to try it that seems enough guardrail to me.
> >
> > The original reason was lack of data on whether napi-tx may suffer
> > from cache invalidations when tx and rx softirq are on different cpus
> > and we enable tx descriptor cleaning from the rx handler (i.e., on ACK).
> > >From those initial numbers it seemed to be a win even with those
> > invalidations.
> >
> > https://patchwork.ozlabs.org/patch/746232/
> >
> > In lieu of removing the affinity_hint_set, this boolean is the least amount
> > of both new interface and implementation to allow experimentation. We
> > can easily leave it as a noop eventually when we are confident that
> > napi-tx can be enabled even without affinity. By comparison, an ethtool
> > param would be quite a bit of new logic.
>
> So it boils down to this: if we believe napi tx is
> always a good idea, then this flag is there just in case,
> and the patch is fine. If it's good for some workloads
> but not others, and will be for a while, we are better off
> with an ethtool flag.
>
> What's the case here?
Based on benchmark results so far, it looks like the first. It's markedly
better for some and in the noise for most.
The crux is the "for a while". We undoubtedly will find some cases that
we need to fix before flipping the default.
The choice is between using napi_tx vs adding a separate ethtool function
to do essentially the same. This patch is the simpler option, and easier to
backport to guest kernels.
> OTOH if you want to add more trick to the affinity hint, such
> as the mentioned above # of queues matching core count,
> that is also fine IMHO.
>From the above linked patch, I understand that there are yet
other special cases in production, such as a hard cap on #tx queues to
32 regardless of number of vcpus. I don't think we want to add special
cases for all this kind of business logic in the kernel.
^ permalink raw reply
* Re: [PATCH mlx5-next] RDMA/mlx5: Don't use cached IRQ affinity mask
From: Steve Wise @ 2018-07-24 20:52 UTC (permalink / raw)
To: Max Gurtovoy, 'Sagi Grimberg', 'Leon Romanovsky'
Cc: 'Doug Ledford', 'Jason Gunthorpe',
'RDMA mailing list', 'Saeed Mahameed',
'linux-netdev'
In-Reply-To: <e32726b5-fbe5-178c-719e-8a71517977b0@opengridcomputing.com>
On 7/24/2018 10:24 AM, Steve Wise wrote:
>
> On 7/19/2018 8:25 PM, Max Gurtovoy wrote:
>>>>> [ 2032.194376] nvme nvme0: failed to connect queue: 9 ret=-18
>>>> queue 9 is not mapped (overlap).
>>>> please try the bellow:
>>>>
>>> This seems to work. Here are three mapping cases: each vector on its
>>> own cpu, each vector on 1 cpu within the local numa node, and each
>>> vector having all cpus in its numa node. The 2nd mapping looks kinda
>>> funny, but I think it achieved what you wanted? And all the cases
>>> resulted in successful connections.
>>>
>> Thanks for testing this.
>> I slightly improved the setting of the left CPUs and actually used
>> Sagi's initial proposal.
>>
>> Sagi,
>> please review the attached patch and let me know if I should add your
>> signature on it.
>> I'll run some perf test early next week on it (meanwhile I run
>> login/logout with different num_queues successfully and irq settings).
>>
>> Steve,
>> It will be great if you can apply the attached in your system and send
>> your findings.
> Sorry, I got side tracked. I'll try and test this today and report back.
>
> Steve.
### each vector gets a unique cpu, starting with node-local:
[ 754.976577] iw_cxgb4: comp_vector 0, irq 203 mask 0x100
[ 754.982378] iw_cxgb4: comp_vector 1, irq 204 mask 0x200
[ 754.988167] iw_cxgb4: comp_vector 2, irq 205 mask 0x400
[ 754.993935] iw_cxgb4: comp_vector 3, irq 206 mask 0x800
[ 754.999686] iw_cxgb4: comp_vector 4, irq 207 mask 0x1000
[ 755.005509] iw_cxgb4: comp_vector 5, irq 208 mask 0x2000
[ 755.011318] iw_cxgb4: comp_vector 6, irq 209 mask 0x4000
[ 755.017124] iw_cxgb4: comp_vector 7, irq 210 mask 0x8000
[ 755.022915] iw_cxgb4: comp_vector 8, irq 211 mask 0x1
[ 755.028437] iw_cxgb4: comp_vector 9, irq 212 mask 0x2
[ 755.033948] iw_cxgb4: comp_vector 10, irq 213 mask 0x4
[ 755.039543] iw_cxgb4: comp_vector 11, irq 214 mask 0x8
[ 755.045135] iw_cxgb4: comp_vector 12, irq 215 mask 0x10
[ 755.050801] iw_cxgb4: comp_vector 13, irq 216 mask 0x20
[ 755.056464] iw_cxgb4: comp_vector 14, irq 217 mask 0x40
[ 755.062117] iw_cxgb4: comp_vector 15, irq 218 mask 0x80
[ 755.067767] blk_mq_rdma_map_queues: set->mq_map[0] queue 8 vector 8
[ 755.067767] blk_mq_rdma_map_queues: set->mq_map[1] queue 9 vector 9
[ 755.067768] blk_mq_rdma_map_queues: set->mq_map[2] queue 10 vector 10
[ 755.067769] blk_mq_rdma_map_queues: set->mq_map[3] queue 11 vector 11
[ 755.067769] blk_mq_rdma_map_queues: set->mq_map[4] queue 12 vector 12
[ 755.067770] blk_mq_rdma_map_queues: set->mq_map[5] queue 13 vector 13
[ 755.067771] blk_mq_rdma_map_queues: set->mq_map[6] queue 14 vector 14
[ 755.067772] blk_mq_rdma_map_queues: set->mq_map[7] queue 15 vector 15
[ 755.067772] blk_mq_rdma_map_queues: set->mq_map[8] queue 0 vector 0
[ 755.067773] blk_mq_rdma_map_queues: set->mq_map[9] queue 1 vector 1
[ 755.067774] blk_mq_rdma_map_queues: set->mq_map[10] queue 2 vector 2
[ 755.067774] blk_mq_rdma_map_queues: set->mq_map[11] queue 3 vector 3
[ 755.067775] blk_mq_rdma_map_queues: set->mq_map[12] queue 4 vector 4
[ 755.067775] blk_mq_rdma_map_queues: set->mq_map[13] queue 5 vector 5
[ 755.067776] blk_mq_rdma_map_queues: set->mq_map[14] queue 6 vector 6
[ 755.067777] blk_mq_rdma_map_queues: set->mq_map[15] queue 7 vector 7
### each vector gets one cpu within the local node:
[ 777.590913] iw_cxgb4: comp_vector 0, irq 203 mask 0x400
[ 777.596588] iw_cxgb4: comp_vector 1, irq 204 mask 0x800
[ 777.602249] iw_cxgb4: comp_vector 2, irq 205 mask 0x1000
[ 777.607984] iw_cxgb4: comp_vector 3, irq 206 mask 0x2000
[ 777.613708] iw_cxgb4: comp_vector 4, irq 207 mask 0x4000
[ 777.619431] iw_cxgb4: comp_vector 5, irq 208 mask 0x8000
[ 777.625142] iw_cxgb4: comp_vector 6, irq 209 mask 0x100
[ 777.630762] iw_cxgb4: comp_vector 7, irq 210 mask 0x200
[ 777.636373] iw_cxgb4: comp_vector 8, irq 211 mask 0x400
[ 777.641982] iw_cxgb4: comp_vector 9, irq 212 mask 0x800
[ 777.647583] iw_cxgb4: comp_vector 10, irq 213 mask 0x1000
[ 777.653353] iw_cxgb4: comp_vector 11, irq 214 mask 0x2000
[ 777.659119] iw_cxgb4: comp_vector 12, irq 215 mask 0x4000
[ 777.664877] iw_cxgb4: comp_vector 13, irq 216 mask 0x8000
[ 777.670628] iw_cxgb4: comp_vector 14, irq 217 mask 0x100
[ 777.676289] iw_cxgb4: comp_vector 15, irq 218 mask 0x200
[ 777.681946] blk_mq_rdma_map_queues: set->mq_map[0] queue 8 vector 8
[ 777.681947] blk_mq_rdma_map_queues: set->mq_map[1] queue 9 vector 9
[ 777.681947] blk_mq_rdma_map_queues: set->mq_map[2] queue 10 vector 10
[ 777.681948] blk_mq_rdma_map_queues: set->mq_map[3] queue 11 vector 11
[ 777.681948] blk_mq_rdma_map_queues: set->mq_map[4] queue 12 vector 12
[ 777.681949] blk_mq_rdma_map_queues: set->mq_map[5] queue 13 vector 13
[ 777.681950] blk_mq_rdma_map_queues: set->mq_map[6] queue 14 vector 14
[ 777.681950] blk_mq_rdma_map_queues: set->mq_map[7] queue 15 vector 15
[ 777.681951] blk_mq_rdma_map_queues: set->mq_map[8] queue 6 vector 6
[ 777.681952] blk_mq_rdma_map_queues: set->mq_map[9] queue 7 vector 7
[ 777.681952] blk_mq_rdma_map_queues: set->mq_map[10] queue 0 vector 0
[ 777.681953] blk_mq_rdma_map_queues: set->mq_map[11] queue 1 vector 1
[ 777.681953] blk_mq_rdma_map_queues: set->mq_map[12] queue 2 vector 2
[ 777.681954] blk_mq_rdma_map_queues: set->mq_map[13] queue 3 vector 3
[ 777.681955] blk_mq_rdma_map_queues: set->mq_map[14] queue 4 vector 4
[ 777.681955] blk_mq_rdma_map_queues: set->mq_map[15] queue 5 vector 5
### each vector gets all cpus within the local node:
[ 838.251643] iw_cxgb4: comp_vector 0, irq 203 mask 0xff00
[ 838.257346] iw_cxgb4: comp_vector 1, irq 204 mask 0xff00
[ 838.263038] iw_cxgb4: comp_vector 2, irq 205 mask 0xff00
[ 838.268710] iw_cxgb4: comp_vector 3, irq 206 mask 0xff00
[ 838.274351] iw_cxgb4: comp_vector 4, irq 207 mask 0xff00
[ 838.279985] iw_cxgb4: comp_vector 5, irq 208 mask 0xff00
[ 838.285610] iw_cxgb4: comp_vector 6, irq 209 mask 0xff00
[ 838.291234] iw_cxgb4: comp_vector 7, irq 210 mask 0xff00
[ 838.296865] iw_cxgb4: comp_vector 8, irq 211 mask 0xff00
[ 838.302484] iw_cxgb4: comp_vector 9, irq 212 mask 0xff00
[ 838.308109] iw_cxgb4: comp_vector 10, irq 213 mask 0xff00
[ 838.313827] iw_cxgb4: comp_vector 11, irq 214 mask 0xff00
[ 838.319539] iw_cxgb4: comp_vector 12, irq 215 mask 0xff00
[ 838.325250] iw_cxgb4: comp_vector 13, irq 216 mask 0xff00
[ 838.330963] iw_cxgb4: comp_vector 14, irq 217 mask 0xff00
[ 838.336674] iw_cxgb4: comp_vector 15, irq 218 mask 0xff00
[ 838.342385] blk_mq_rdma_map_queues: set->mq_map[0] queue 8 vector 8
[ 838.342385] blk_mq_rdma_map_queues: set->mq_map[1] queue 9 vector 9
[ 838.342386] blk_mq_rdma_map_queues: set->mq_map[2] queue 10 vector 10
[ 838.342387] blk_mq_rdma_map_queues: set->mq_map[3] queue 11 vector 11
[ 838.342387] blk_mq_rdma_map_queues: set->mq_map[4] queue 12 vector 12
[ 838.342388] blk_mq_rdma_map_queues: set->mq_map[5] queue 13 vector 13
[ 838.342389] blk_mq_rdma_map_queues: set->mq_map[6] queue 14 vector 14
[ 838.342390] blk_mq_rdma_map_queues: set->mq_map[7] queue 15 vector 15
[ 838.342391] blk_mq_rdma_map_queues: set->mq_map[8] queue 0 vector 0
[ 838.342391] blk_mq_rdma_map_queues: set->mq_map[9] queue 1 vector 1
[ 838.342392] blk_mq_rdma_map_queues: set->mq_map[10] queue 2 vector 2
[ 838.342392] blk_mq_rdma_map_queues: set->mq_map[11] queue 3 vector 3
[ 838.342393] blk_mq_rdma_map_queues: set->mq_map[12] queue 4 vector 4
[ 838.342394] blk_mq_rdma_map_queues: set->mq_map[13] queue 5 vector 5
[ 838.342394] blk_mq_rdma_map_queues: set->mq_map[14] queue 6 vector 6
[ 838.342395] blk_mq_rdma_map_queues: set->mq_map[15] queue 7 vector 7
^ 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