* [PATCH net-next 02/11] net: Introduce new api for walking upper and lower devices
From: David Ahern @ 2016-10-18 2:15 UTC (permalink / raw)
To: jiri, netdev, davem
Cc: dledford, sean.hefty, hal.rosenstock, linux-rdma, j.vosburgh,
vfalico, andy, jeffrey.t.kirsher, intel-wired-lan, David Ahern
In-Reply-To: <1476756953-30923-1-git-send-email-dsa@cumulusnetworks.com>
This patch introduces netdev_walk_all_upper_dev_rcu,
netdev_walk_all_lower_dev and netdev_walk_all_lower_dev_rcu. These
functions recursively walk the adj_list of devices to determine all upper
and lower devices.
The functions take a callback function that is invoked for each device
in the list. If the callback returns non-0, the walk is terminated and
the functions return that code back to callers.
v3
- simplified netdev_has_upper_dev_all_rcu and __netdev_has_upper_dev and
removed typecast as suggested by Stephen
v2
- fixed definition of netdev_next_lower_dev_rcu to mirror the upper_dev
version.
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
include/linux/netdevice.h | 17 +++++
net/core/dev.c | 155 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 172 insertions(+)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index bf341b65ca5e..a5902d995907 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3778,6 +3778,14 @@ struct net_device *netdev_all_upper_get_next_dev_rcu(struct net_device *dev,
updev; \
updev = netdev_all_upper_get_next_dev_rcu(dev, &(iter)))
+int netdev_walk_all_upper_dev_rcu(struct net_device *dev,
+ int (*fn)(struct net_device *upper_dev,
+ void *data),
+ void *data);
+
+bool netdev_has_upper_dev_all_rcu(struct net_device *dev,
+ struct net_device *upper_dev);
+
void *netdev_lower_get_next_private(struct net_device *dev,
struct list_head **iter);
void *netdev_lower_get_next_private_rcu(struct net_device *dev,
@@ -3821,6 +3829,15 @@ struct net_device *netdev_all_lower_get_next_rcu(struct net_device *dev,
ldev; \
ldev = netdev_all_lower_get_next_rcu(dev, &(iter)))
+int netdev_walk_all_lower_dev(struct net_device *dev,
+ int (*fn)(struct net_device *lower_dev,
+ void *data),
+ void *data);
+int netdev_walk_all_lower_dev_rcu(struct net_device *dev,
+ int (*fn)(struct net_device *lower_dev,
+ void *data),
+ void *data);
+
void *netdev_adjacent_get_private(struct list_head *adj_list);
void *netdev_lower_get_first_private_rcu(struct net_device *dev);
struct net_device *netdev_master_upper_dev_get(struct net_device *dev);
diff --git a/net/core/dev.c b/net/core/dev.c
index f67fd16615bb..fc48337cfab8 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5156,6 +5156,31 @@ bool netdev_has_upper_dev(struct net_device *dev,
EXPORT_SYMBOL(netdev_has_upper_dev);
/**
+ * netdev_has_upper_dev_all - Check if device is linked to an upper device
+ * @dev: device
+ * @upper_dev: upper device to check
+ *
+ * Find out if a device is linked to specified upper device and return true
+ * in case it is. Note that this checks the entire upper device chain.
+ * The caller must hold rcu lock.
+ */
+
+static int __netdev_has_upper_dev(struct net_device *upper_dev, void *data)
+{
+ struct net_device *dev = data;
+
+ return upper_dev == dev;
+}
+
+bool netdev_has_upper_dev_all_rcu(struct net_device *dev,
+ struct net_device *upper_dev)
+{
+ return !!netdev_walk_all_upper_dev_rcu(dev, __netdev_has_upper_dev,
+ upper_dev);
+}
+EXPORT_SYMBOL(netdev_has_upper_dev_all_rcu);
+
+/**
* netdev_has_any_upper_dev - Check if device is linked to some device
* @dev: device
*
@@ -5255,6 +5280,51 @@ struct net_device *netdev_all_upper_get_next_dev_rcu(struct net_device *dev,
}
EXPORT_SYMBOL(netdev_all_upper_get_next_dev_rcu);
+static struct net_device *netdev_next_upper_dev_rcu(struct net_device *dev,
+ struct list_head **iter)
+{
+ struct netdev_adjacent *upper;
+
+ WARN_ON_ONCE(!rcu_read_lock_held() && !lockdep_rtnl_is_held());
+
+ upper = list_entry_rcu((*iter)->next, struct netdev_adjacent, list);
+
+ if (&upper->list == &dev->adj_list.upper)
+ return NULL;
+
+ *iter = &upper->list;
+
+ return upper->dev;
+}
+
+int netdev_walk_all_upper_dev_rcu(struct net_device *dev,
+ int (*fn)(struct net_device *dev,
+ void *data),
+ void *data)
+{
+ struct net_device *udev;
+ struct list_head *iter;
+ int ret;
+
+ for (iter = &dev->adj_list.upper,
+ udev = netdev_next_upper_dev_rcu(dev, &iter);
+ udev;
+ udev = netdev_next_upper_dev_rcu(dev, &iter)) {
+ /* first is the upper device itself */
+ ret = fn(udev, data);
+ if (ret)
+ return ret;
+
+ /* then look at all of its upper devices */
+ ret = netdev_walk_all_upper_dev_rcu(udev, fn, data);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(netdev_walk_all_upper_dev_rcu);
+
/**
* netdev_lower_get_next_private - Get the next ->private from the
* lower neighbour list
@@ -5361,6 +5431,49 @@ struct net_device *netdev_all_lower_get_next(struct net_device *dev, struct list
}
EXPORT_SYMBOL(netdev_all_lower_get_next);
+static struct net_device *netdev_next_lower_dev(struct net_device *dev,
+ struct list_head **iter)
+{
+ struct netdev_adjacent *lower;
+
+ lower = list_entry(*iter, struct netdev_adjacent, list);
+
+ if (&lower->list == &dev->adj_list.lower)
+ return NULL;
+
+ *iter = lower->list.next;
+
+ return lower->dev;
+}
+
+int netdev_walk_all_lower_dev(struct net_device *dev,
+ int (*fn)(struct net_device *dev,
+ void *data),
+ void *data)
+{
+ struct net_device *ldev;
+ struct list_head *iter;
+ int ret;
+
+ for (iter = &dev->adj_list.lower,
+ ldev = netdev_next_lower_dev(dev, &iter);
+ ldev;
+ ldev = netdev_next_lower_dev(dev, &iter)) {
+ /* first is the lower device itself */
+ ret = fn(ldev, data);
+ if (ret)
+ return ret;
+
+ /* then look at all of its lower devices */
+ ret = netdev_walk_all_lower_dev(ldev, fn, data);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(netdev_walk_all_lower_dev);
+
/**
* netdev_all_lower_get_next_rcu - Get the next device from all
* lower neighbour list, RCU variant
@@ -5382,6 +5495,48 @@ struct net_device *netdev_all_lower_get_next_rcu(struct net_device *dev,
}
EXPORT_SYMBOL(netdev_all_lower_get_next_rcu);
+static struct net_device *netdev_next_lower_dev_rcu(struct net_device *dev,
+ struct list_head **iter)
+{
+ struct netdev_adjacent *lower;
+
+ lower = list_entry_rcu((*iter)->next, struct netdev_adjacent, list);
+ if (&lower->list == &dev->adj_list.lower)
+ return NULL;
+
+ *iter = &lower->list;
+
+ return lower->dev;
+}
+
+int netdev_walk_all_lower_dev_rcu(struct net_device *dev,
+ int (*fn)(struct net_device *dev,
+ void *data),
+ void *data)
+{
+ struct net_device *ldev;
+ struct list_head *iter;
+ int ret;
+
+ for (iter = &dev->adj_list.lower,
+ ldev = netdev_next_lower_dev_rcu(dev, &iter);
+ ldev;
+ ldev = netdev_next_lower_dev_rcu(dev, &iter)) {
+ /* first is the lower device itself */
+ ret = fn(ldev, data);
+ if (ret)
+ return ret;
+
+ /* then look at all of its lower devices */
+ ret = netdev_walk_all_lower_dev_rcu(ldev, fn, data);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(netdev_walk_all_lower_dev_rcu);
+
/**
* netdev_lower_get_first_private_rcu - Get the first ->private from the
* lower neighbour list, RCU
--
2.1.4
^ permalink raw reply related
* [PATCH net-next 03/11] net: bonding: Flip to the new dev walk API
From: David Ahern @ 2016-10-18 2:15 UTC (permalink / raw)
To: jiri-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
j.vosburgh-Re5JQEeQqe8AvxtiuMwx3w, vfalico-Re5JQEeQqe8AvxtiuMwx3w,
andy-QlMahl40kYEqcZcGjlUOXw,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
intel-wired-lan-qjLDD68F18P21nG7glBr7A, David Ahern
In-Reply-To: <1476756953-30923-1-git-send-email-dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
Convert alb_send_learning_packets and bond_has_this_ip to use the new
netdev_walk_all_upper_dev_rcu API. In both cases this is just a code
conversion; no functional change is intended.
v2
- removed typecast of data and simplified bond_upper_dev_walk
Signed-off-by: David Ahern <dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
---
drivers/net/bonding/bond_alb.c | 82 ++++++++++++++++++++++++++---------------
drivers/net/bonding/bond_main.c | 17 +++++----
2 files changed, 61 insertions(+), 38 deletions(-)
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index 551f0f8dead3..c80b023092dd 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -950,13 +950,61 @@ static void alb_send_lp_vid(struct slave *slave, u8 mac_addr[],
dev_queue_xmit(skb);
}
+struct alb_walk_data {
+ struct bonding *bond;
+ struct slave *slave;
+ u8 *mac_addr;
+ bool strict_match;
+};
+
+static int alb_upper_dev_walk(struct net_device *upper, void *_data)
+{
+ struct alb_walk_data *data = _data;
+ bool strict_match = data->strict_match;
+ struct bonding *bond = data->bond;
+ struct slave *slave = data->slave;
+ u8 *mac_addr = data->mac_addr;
+ struct bond_vlan_tag *tags;
+
+ if (is_vlan_dev(upper) && vlan_get_encap_level(upper) == 0) {
+ if (strict_match &&
+ ether_addr_equal_64bits(mac_addr,
+ upper->dev_addr)) {
+ alb_send_lp_vid(slave, mac_addr,
+ vlan_dev_vlan_proto(upper),
+ vlan_dev_vlan_id(upper));
+ } else if (!strict_match) {
+ alb_send_lp_vid(slave, upper->dev_addr,
+ vlan_dev_vlan_proto(upper),
+ vlan_dev_vlan_id(upper));
+ }
+ }
+
+ /* If this is a macvlan device, then only send updates
+ * when strict_match is turned off.
+ */
+ if (netif_is_macvlan(upper) && !strict_match) {
+ tags = bond_verify_device_path(bond->dev, upper, 0);
+ if (IS_ERR_OR_NULL(tags))
+ BUG();
+ alb_send_lp_vid(slave, upper->dev_addr,
+ tags[0].vlan_proto, tags[0].vlan_id);
+ kfree(tags);
+ }
+
+ return 0;
+}
+
static void alb_send_learning_packets(struct slave *slave, u8 mac_addr[],
bool strict_match)
{
struct bonding *bond = bond_get_bond_by_slave(slave);
- struct net_device *upper;
- struct list_head *iter;
- struct bond_vlan_tag *tags;
+ struct alb_walk_data data = {
+ .strict_match = strict_match,
+ .mac_addr = mac_addr,
+ .slave = slave,
+ .bond = bond,
+ };
/* send untagged */
alb_send_lp_vid(slave, mac_addr, 0, 0);
@@ -965,33 +1013,7 @@ static void alb_send_learning_packets(struct slave *slave, u8 mac_addr[],
* for that device.
*/
rcu_read_lock();
- netdev_for_each_all_upper_dev_rcu(bond->dev, upper, iter) {
- if (is_vlan_dev(upper) && vlan_get_encap_level(upper) == 0) {
- if (strict_match &&
- ether_addr_equal_64bits(mac_addr,
- upper->dev_addr)) {
- alb_send_lp_vid(slave, mac_addr,
- vlan_dev_vlan_proto(upper),
- vlan_dev_vlan_id(upper));
- } else if (!strict_match) {
- alb_send_lp_vid(slave, upper->dev_addr,
- vlan_dev_vlan_proto(upper),
- vlan_dev_vlan_id(upper));
- }
- }
-
- /* If this is a macvlan device, then only send updates
- * when strict_match is turned off.
- */
- if (netif_is_macvlan(upper) && !strict_match) {
- tags = bond_verify_device_path(bond->dev, upper, 0);
- if (IS_ERR_OR_NULL(tags))
- BUG();
- alb_send_lp_vid(slave, upper->dev_addr,
- tags[0].vlan_proto, tags[0].vlan_id);
- kfree(tags);
- }
- }
+ netdev_walk_all_upper_dev_rcu(bond->dev, alb_upper_dev_walk, &data);
rcu_read_unlock();
}
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 5fa36ebc0640..c9944d86d045 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2270,22 +2270,23 @@ static void bond_mii_monitor(struct work_struct *work)
}
}
+static int bond_upper_dev_walk(struct net_device *upper, void *data)
+{
+ __be32 ip = *((__be32 *)data);
+
+ return ip == bond_confirm_addr(upper, 0, ip);
+}
+
static bool bond_has_this_ip(struct bonding *bond, __be32 ip)
{
- struct net_device *upper;
- struct list_head *iter;
bool ret = false;
if (ip == bond_confirm_addr(bond->dev, 0, ip))
return true;
rcu_read_lock();
- netdev_for_each_all_upper_dev_rcu(bond->dev, upper, iter) {
- if (ip == bond_confirm_addr(upper, 0, ip)) {
- ret = true;
- break;
- }
- }
+ if (netdev_walk_all_upper_dev_rcu(bond->dev, bond_upper_dev_walk, &ip))
+ ret = true;
rcu_read_unlock();
return ret;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net-next 04/11] IB/core: Flip to the new dev walk API
From: David Ahern @ 2016-10-18 2:15 UTC (permalink / raw)
To: jiri-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
j.vosburgh-Re5JQEeQqe8AvxtiuMwx3w, vfalico-Re5JQEeQqe8AvxtiuMwx3w,
andy-QlMahl40kYEqcZcGjlUOXw,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
intel-wired-lan-qjLDD68F18P21nG7glBr7A, David Ahern
In-Reply-To: <1476756953-30923-1-git-send-email-dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
Convert rdma_is_upper_dev_rcu, handle_netdev_upper and
ipoib_get_net_dev_match_addr to the new upper device walk API.
This is just a code conversion; no functional change is intended.
v2
- removed typecast of data
Signed-off-by: David Ahern <dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
---
drivers/infiniband/core/core_priv.h | 9 +------
drivers/infiniband/core/roce_gid_mgmt.c | 42 ++++++++++++++++++---------------
2 files changed, 24 insertions(+), 27 deletions(-)
diff --git a/drivers/infiniband/core/core_priv.h b/drivers/infiniband/core/core_priv.h
index 19d499dcab76..0c0bea091de8 100644
--- a/drivers/infiniband/core/core_priv.h
+++ b/drivers/infiniband/core/core_priv.h
@@ -127,14 +127,7 @@ void ib_cache_release_one(struct ib_device *device);
static inline bool rdma_is_upper_dev_rcu(struct net_device *dev,
struct net_device *upper)
{
- struct net_device *_upper = NULL;
- struct list_head *iter;
-
- netdev_for_each_all_upper_dev_rcu(dev, _upper, iter)
- if (_upper == upper)
- break;
-
- return _upper == upper;
+ return netdev_has_upper_dev_all_rcu(dev, upper);
}
int addr_init(void);
diff --git a/drivers/infiniband/core/roce_gid_mgmt.c b/drivers/infiniband/core/roce_gid_mgmt.c
index 06556c34606d..3a64a0881882 100644
--- a/drivers/infiniband/core/roce_gid_mgmt.c
+++ b/drivers/infiniband/core/roce_gid_mgmt.c
@@ -437,6 +437,28 @@ static void callback_for_addr_gid_device_scan(struct ib_device *device,
&parsed->gid_attr);
}
+struct upper_list {
+ struct list_head list;
+ struct net_device *upper;
+};
+
+static int netdev_upper_walk(struct net_device *upper, void *data)
+{
+ struct upper_list *entry = kmalloc(sizeof(*entry), GFP_ATOMIC);
+ struct list_head *upper_list = data;
+
+ if (!entry) {
+ pr_info("roce_gid_mgmt: couldn't allocate entry to delete ndev\n");
+ return 0;
+ }
+
+ list_add_tail(&entry->list, upper_list);
+ dev_hold(upper);
+ entry->upper = upper;
+
+ return 0;
+}
+
static void handle_netdev_upper(struct ib_device *ib_dev, u8 port,
void *cookie,
void (*handle_netdev)(struct ib_device *ib_dev,
@@ -444,30 +466,12 @@ static void handle_netdev_upper(struct ib_device *ib_dev, u8 port,
struct net_device *ndev))
{
struct net_device *ndev = (struct net_device *)cookie;
- struct upper_list {
- struct list_head list;
- struct net_device *upper;
- };
- struct net_device *upper;
- struct list_head *iter;
struct upper_list *upper_iter;
struct upper_list *upper_temp;
LIST_HEAD(upper_list);
rcu_read_lock();
- netdev_for_each_all_upper_dev_rcu(ndev, upper, iter) {
- struct upper_list *entry = kmalloc(sizeof(*entry),
- GFP_ATOMIC);
-
- if (!entry) {
- pr_info("roce_gid_mgmt: couldn't allocate entry to delete ndev\n");
- continue;
- }
-
- list_add_tail(&entry->list, &upper_list);
- dev_hold(upper);
- entry->upper = upper;
- }
+ netdev_walk_all_upper_dev_rcu(ndev, netdev_upper_walk, &upper_list);
rcu_read_unlock();
handle_netdev(ib_dev, port, ndev);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net-next 05/11] IB/ipoib: Flip to new dev walk API
From: David Ahern @ 2016-10-18 2:15 UTC (permalink / raw)
To: jiri, netdev, davem
Cc: dledford, sean.hefty, hal.rosenstock, linux-rdma, j.vosburgh,
vfalico, andy, jeffrey.t.kirsher, intel-wired-lan, David Ahern
In-Reply-To: <1476756953-30923-1-git-send-email-dsa@cumulusnetworks.com>
Convert ipoib_get_net_dev_match_addr to the new upper device walk API.
This is just a code conversion; no functional change is intended.
v2
- removed typecast of data
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 37 +++++++++++++++++++++----------
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 5636fc3da6b8..cc059218c962 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -292,6 +292,25 @@ static struct net_device *ipoib_get_master_net_dev(struct net_device *dev)
return dev;
}
+struct ipoib_walk_data {
+ const struct sockaddr *addr;
+ struct net_device *result;
+};
+
+static int ipoib_upper_walk(struct net_device *upper, void *_data)
+{
+ struct ipoib_walk_data *data = _data;
+ int ret = 0;
+
+ if (ipoib_is_dev_match_addr_rcu(data->addr, upper)) {
+ dev_hold(upper);
+ data->result = upper;
+ ret = 1;
+ }
+
+ return ret;
+}
+
/**
* Find a net_device matching the given address, which is an upper device of
* the given net_device.
@@ -304,27 +323,21 @@ static struct net_device *ipoib_get_master_net_dev(struct net_device *dev)
static struct net_device *ipoib_get_net_dev_match_addr(
const struct sockaddr *addr, struct net_device *dev)
{
- struct net_device *upper,
- *result = NULL;
- struct list_head *iter;
+ struct ipoib_walk_data data = {
+ .addr = addr,
+ };
rcu_read_lock();
if (ipoib_is_dev_match_addr_rcu(addr, dev)) {
dev_hold(dev);
- result = dev;
+ data.result = dev;
goto out;
}
- netdev_for_each_all_upper_dev_rcu(dev, upper, iter) {
- if (ipoib_is_dev_match_addr_rcu(addr, upper)) {
- dev_hold(upper);
- result = upper;
- break;
- }
- }
+ netdev_walk_all_upper_dev_rcu(dev, ipoib_upper_walk, &data);
out:
rcu_read_unlock();
- return result;
+ return data.result;
}
/* returns the number of IPoIB netdevs on top a given ipoib device matching a
--
2.1.4
^ permalink raw reply related
* [PATCH net-next 06/11] ixgbe: Flip to the new dev walk API
From: David Ahern @ 2016-10-18 2:15 UTC (permalink / raw)
To: jiri-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
j.vosburgh-Re5JQEeQqe8AvxtiuMwx3w, vfalico-Re5JQEeQqe8AvxtiuMwx3w,
andy-QlMahl40kYEqcZcGjlUOXw,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
intel-wired-lan-qjLDD68F18P21nG7glBr7A, David Ahern
In-Reply-To: <1476756953-30923-1-git-send-email-dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
Convert ixgbe users to new dev walk API. This is just a code conversion;
no functional change is intended.
Signed-off-by: David Ahern <dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 132 ++++++++++++++++----------
1 file changed, 82 insertions(+), 50 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 784b0b98ab2f..f380fda11eb6 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -5012,24 +5012,23 @@ static int ixgbe_fwd_ring_up(struct net_device *vdev,
return err;
}
-static void ixgbe_configure_dfwd(struct ixgbe_adapter *adapter)
+static int ixgbe_upper_dev_walk(struct net_device *upper, void *data)
{
- struct net_device *upper;
- struct list_head *iter;
- int err;
-
- netdev_for_each_all_upper_dev_rcu(adapter->netdev, upper, iter) {
- if (netif_is_macvlan(upper)) {
- struct macvlan_dev *dfwd = netdev_priv(upper);
- struct ixgbe_fwd_adapter *vadapter = dfwd->fwd_priv;
+ if (netif_is_macvlan(upper)) {
+ struct macvlan_dev *dfwd = netdev_priv(upper);
+ struct ixgbe_fwd_adapter *vadapter = dfwd->fwd_priv;
- if (dfwd->fwd_priv) {
- err = ixgbe_fwd_ring_up(upper, vadapter);
- if (err)
- continue;
- }
- }
+ if (dfwd->fwd_priv)
+ ixgbe_fwd_ring_up(upper, vadapter);
}
+
+ return 0;
+}
+
+static void ixgbe_configure_dfwd(struct ixgbe_adapter *adapter)
+{
+ netdev_walk_all_upper_dev_rcu(adapter->netdev,
+ ixgbe_upper_dev_walk, NULL);
}
static void ixgbe_configure(struct ixgbe_adapter *adapter)
@@ -5448,12 +5447,25 @@ static void ixgbe_fdir_filter_exit(struct ixgbe_adapter *adapter)
spin_unlock(&adapter->fdir_perfect_lock);
}
+static int ixgbe_disable_macvlan(struct net_device *upper, void *data)
+{
+ if (netif_is_macvlan(upper)) {
+ struct macvlan_dev *vlan = netdev_priv(upper);
+
+ if (vlan->fwd_priv) {
+ netif_tx_stop_all_queues(upper);
+ netif_carrier_off(upper);
+ netif_tx_disable(upper);
+ }
+ }
+
+ return 0;
+}
+
void ixgbe_down(struct ixgbe_adapter *adapter)
{
struct net_device *netdev = adapter->netdev;
struct ixgbe_hw *hw = &adapter->hw;
- struct net_device *upper;
- struct list_head *iter;
int i;
/* signal that we are down to the interrupt handler */
@@ -5477,17 +5489,8 @@ void ixgbe_down(struct ixgbe_adapter *adapter)
netif_tx_disable(netdev);
/* disable any upper devices */
- netdev_for_each_all_upper_dev_rcu(adapter->netdev, upper, iter) {
- if (netif_is_macvlan(upper)) {
- struct macvlan_dev *vlan = netdev_priv(upper);
-
- if (vlan->fwd_priv) {
- netif_tx_stop_all_queues(upper);
- netif_carrier_off(upper);
- netif_tx_disable(upper);
- }
- }
- }
+ netdev_walk_all_upper_dev_rcu(adapter->netdev,
+ ixgbe_disable_macvlan, NULL);
ixgbe_irq_disable(adapter);
@@ -6728,6 +6731,18 @@ static void ixgbe_update_default_up(struct ixgbe_adapter *adapter)
#endif
}
+static int ixgbe_enable_macvlan(struct net_device *upper, void *data)
+{
+ if (netif_is_macvlan(upper)) {
+ struct macvlan_dev *vlan = netdev_priv(upper);
+
+ if (vlan->fwd_priv)
+ netif_tx_wake_all_queues(upper);
+ }
+
+ return 0;
+}
+
/**
* ixgbe_watchdog_link_is_up - update netif_carrier status and
* print link up message
@@ -6737,8 +6752,6 @@ static void ixgbe_watchdog_link_is_up(struct ixgbe_adapter *adapter)
{
struct net_device *netdev = adapter->netdev;
struct ixgbe_hw *hw = &adapter->hw;
- struct net_device *upper;
- struct list_head *iter;
u32 link_speed = adapter->link_speed;
const char *speed_str;
bool flow_rx, flow_tx;
@@ -6809,14 +6822,8 @@ static void ixgbe_watchdog_link_is_up(struct ixgbe_adapter *adapter)
/* enable any upper devices */
rtnl_lock();
- netdev_for_each_all_upper_dev_rcu(adapter->netdev, upper, iter) {
- if (netif_is_macvlan(upper)) {
- struct macvlan_dev *vlan = netdev_priv(upper);
-
- if (vlan->fwd_priv)
- netif_tx_wake_all_queues(upper);
- }
- }
+ netdev_walk_all_upper_dev_rcu(adapter->netdev,
+ ixgbe_enable_macvlan, NULL);
rtnl_unlock();
/* update the default user priority for VFs */
@@ -8350,12 +8357,38 @@ static int ixgbe_configure_clsu32_del_hnode(struct ixgbe_adapter *adapter,
}
#ifdef CONFIG_NET_CLS_ACT
+struct upper_walk_data {
+ struct ixgbe_adapter *adapter;
+ u64 action;
+ int ifindex;
+ u8 queue;
+};
+
+static int get_macvlan_queue(struct net_device *upper, void *_data)
+{
+ if (netif_is_macvlan(upper)) {
+ struct macvlan_dev *dfwd = netdev_priv(upper);
+ struct ixgbe_fwd_adapter *vadapter = dfwd->fwd_priv;
+ struct upper_walk_data *data = _data;
+ struct ixgbe_adapter *adapter = data->adapter;
+ int ifindex = data->ifindex;
+
+ if (vadapter && vadapter->netdev->ifindex == ifindex) {
+ data->queue = adapter->rx_ring[vadapter->rx_base_queue]->reg_idx;
+ data->action = data->queue;
+ return 1;
+ }
+ }
+
+ return 0;
+}
+
static int handle_redirect_action(struct ixgbe_adapter *adapter, int ifindex,
u8 *queue, u64 *action)
{
unsigned int num_vfs = adapter->num_vfs, vf;
+ struct upper_walk_data data;
struct net_device *upper;
- struct list_head *iter;
/* redirect to a SRIOV VF */
for (vf = 0; vf < num_vfs; ++vf) {
@@ -8373,17 +8406,16 @@ static int handle_redirect_action(struct ixgbe_adapter *adapter, int ifindex,
}
/* redirect to a offloaded macvlan netdev */
- netdev_for_each_all_upper_dev_rcu(adapter->netdev, upper, iter) {
- if (netif_is_macvlan(upper)) {
- struct macvlan_dev *dfwd = netdev_priv(upper);
- struct ixgbe_fwd_adapter *vadapter = dfwd->fwd_priv;
-
- if (vadapter && vadapter->netdev->ifindex == ifindex) {
- *queue = adapter->rx_ring[vadapter->rx_base_queue]->reg_idx;
- *action = *queue;
- return 0;
- }
- }
+ data.adapter = adapter;
+ data.ifindex = ifindex;
+ data.action = 0;
+ data.queue = 0;
+ if (netdev_walk_all_upper_dev_rcu(adapter->netdev,
+ get_macvlan_queue, &data)) {
+ *action = data.action;
+ *queue = data.queue;
+
+ return 0;
}
return -EINVAL;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net-next 07/11] mlxsw: Flip to the new dev walk API
From: David Ahern @ 2016-10-18 2:15 UTC (permalink / raw)
To: jiri, netdev, davem
Cc: dledford, sean.hefty, hal.rosenstock, linux-rdma, j.vosburgh,
vfalico, andy, jeffrey.t.kirsher, intel-wired-lan, David Ahern
In-Reply-To: <1476756953-30923-1-git-send-email-dsa@cumulusnetworks.com>
Convert mlxsw users to new dev walk API. This is just a code conversion;
no functional change is intended.
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 37 ++++++++++++++++----------
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 43a5eddc2c11..99805fd3d110 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -3092,19 +3092,30 @@ static bool mlxsw_sp_port_dev_check(const struct net_device *dev)
return dev->netdev_ops == &mlxsw_sp_port_netdev_ops;
}
+static int mlxsw_lower_dev_walk(struct net_device *lower_dev, void *data)
+{
+ struct mlxsw_sp_port **port = data;
+ int ret = 0;
+
+ if (mlxsw_sp_port_dev_check(lower_dev)) {
+ *port = netdev_priv(lower_dev);
+ ret = 1;
+ }
+
+ return ret;
+}
+
static struct mlxsw_sp_port *mlxsw_sp_port_dev_lower_find(struct net_device *dev)
{
- struct net_device *lower_dev;
- struct list_head *iter;
+ struct mlxsw_sp_port *port;
if (mlxsw_sp_port_dev_check(dev))
return netdev_priv(dev);
- netdev_for_each_all_lower_dev(dev, lower_dev, iter) {
- if (mlxsw_sp_port_dev_check(lower_dev))
- return netdev_priv(lower_dev);
- }
- return NULL;
+ port = NULL;
+ netdev_walk_all_lower_dev(dev, mlxsw_lower_dev_walk, &port);
+
+ return port;
}
static struct mlxsw_sp *mlxsw_sp_lower_get(struct net_device *dev)
@@ -3117,17 +3128,15 @@ static struct mlxsw_sp *mlxsw_sp_lower_get(struct net_device *dev)
static struct mlxsw_sp_port *mlxsw_sp_port_dev_lower_find_rcu(struct net_device *dev)
{
- struct net_device *lower_dev;
- struct list_head *iter;
+ struct mlxsw_sp_port *port;
if (mlxsw_sp_port_dev_check(dev))
return netdev_priv(dev);
- netdev_for_each_all_lower_dev_rcu(dev, lower_dev, iter) {
- if (mlxsw_sp_port_dev_check(lower_dev))
- return netdev_priv(lower_dev);
- }
- return NULL;
+ port = NULL;
+ netdev_walk_all_lower_dev_rcu(dev, mlxsw_lower_dev_walk, &port);
+
+ return port;
}
struct mlxsw_sp_port *mlxsw_sp_port_lower_dev_hold(struct net_device *dev)
--
2.1.4
^ permalink raw reply related
* [PATCH net-next 08/11] rocker: Flip to the new dev walk API
From: David Ahern @ 2016-10-18 2:15 UTC (permalink / raw)
To: jiri-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
j.vosburgh-Re5JQEeQqe8AvxtiuMwx3w, vfalico-Re5JQEeQqe8AvxtiuMwx3w,
andy-QlMahl40kYEqcZcGjlUOXw,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
intel-wired-lan-qjLDD68F18P21nG7glBr7A, David Ahern
In-Reply-To: <1476756953-30923-1-git-send-email-dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
Convert rocker to the new dev walk API. This is just a code conversion;
no functional change is intended.
v2
- removed typecast of data
Signed-off-by: David Ahern <dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
---
drivers/net/ethernet/rocker/rocker_main.c | 31 ++++++++++++++++++++++++-------
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/rocker/rocker_main.c b/drivers/net/ethernet/rocker/rocker_main.c
index 5424fb341613..5deb25f26e5f 100644
--- a/drivers/net/ethernet/rocker/rocker_main.c
+++ b/drivers/net/ethernet/rocker/rocker_main.c
@@ -2839,20 +2839,37 @@ static bool rocker_port_dev_check_under(const struct net_device *dev,
return true;
}
+struct rocker_walk_data {
+ struct rocker *rocker;
+ struct rocker_port *port;
+};
+
+static int rocker_lower_dev_walk(struct net_device *lower_dev, void *_data)
+{
+ struct rocker_walk_data *data = _data;
+ int ret = 0;
+
+ if (rocker_port_dev_check_under(lower_dev, data->rocker)) {
+ data->port = netdev_priv(lower_dev);
+ ret = 1;
+ }
+
+ return ret;
+}
+
struct rocker_port *rocker_port_dev_lower_find(struct net_device *dev,
struct rocker *rocker)
{
- struct net_device *lower_dev;
- struct list_head *iter;
+ struct rocker_walk_data data;
if (rocker_port_dev_check_under(dev, rocker))
return netdev_priv(dev);
- netdev_for_each_all_lower_dev(dev, lower_dev, iter) {
- if (rocker_port_dev_check_under(lower_dev, rocker))
- return netdev_priv(lower_dev);
- }
- return NULL;
+ data.rocker = rocker;
+ data.port = NULL;
+ netdev_walk_all_lower_dev(dev, rocker_lower_dev_walk, &data);
+
+ return data.port;
}
static int rocker_netdevice_event(struct notifier_block *unused,
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net-next 09/11] net: Remove all_adj_list and its references
From: David Ahern @ 2016-10-18 2:15 UTC (permalink / raw)
To: jiri-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
j.vosburgh-Re5JQEeQqe8AvxtiuMwx3w, vfalico-Re5JQEeQqe8AvxtiuMwx3w,
andy-QlMahl40kYEqcZcGjlUOXw,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
intel-wired-lan-qjLDD68F18P21nG7glBr7A, David Ahern
In-Reply-To: <1476756953-30923-1-git-send-email-dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
Only direct adjacencies are maintained. All upper or lower devices can
be learned via the new walk API which recursively walks the adj_list for
upper devices or lower devices.
Signed-off-by: David Ahern <dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
---
include/linux/netdevice.h | 25 ------
net/core/dev.c | 223 ++++------------------------------------------
2 files changed, 18 insertions(+), 230 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index a5902d995907..458c87631e7f 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1456,7 +1456,6 @@ enum netdev_priv_flags {
* @ptype_specific: Device-specific, protocol-specific packet handlers
*
* @adj_list: Directly linked devices, like slaves for bonding
- * @all_adj_list: All linked devices, *including* neighbours
* @features: Currently active device features
* @hw_features: User-changeable features
*
@@ -1675,11 +1674,6 @@ struct net_device {
struct list_head lower;
} adj_list;
- struct {
- struct list_head upper;
- struct list_head lower;
- } all_adj_list;
-
netdev_features_t features;
netdev_features_t hw_features;
netdev_features_t wanted_features;
@@ -3771,13 +3765,6 @@ struct net_device *netdev_all_upper_get_next_dev_rcu(struct net_device *dev,
updev; \
updev = netdev_upper_get_next_dev_rcu(dev, &(iter)))
-/* iterate through upper list, must be called under RCU read lock */
-#define netdev_for_each_all_upper_dev_rcu(dev, updev, iter) \
- for (iter = &(dev)->all_adj_list.upper, \
- updev = netdev_all_upper_get_next_dev_rcu(dev, &(iter)); \
- updev; \
- updev = netdev_all_upper_get_next_dev_rcu(dev, &(iter)))
-
int netdev_walk_all_upper_dev_rcu(struct net_device *dev,
int (*fn)(struct net_device *upper_dev,
void *data),
@@ -3817,18 +3804,6 @@ struct net_device *netdev_all_lower_get_next(struct net_device *dev,
struct net_device *netdev_all_lower_get_next_rcu(struct net_device *dev,
struct list_head **iter);
-#define netdev_for_each_all_lower_dev(dev, ldev, iter) \
- for (iter = (dev)->all_adj_list.lower.next, \
- ldev = netdev_all_lower_get_next(dev, &(iter)); \
- ldev; \
- ldev = netdev_all_lower_get_next(dev, &(iter)))
-
-#define netdev_for_each_all_lower_dev_rcu(dev, ldev, iter) \
- for (iter = (dev)->all_adj_list.lower.next, \
- ldev = netdev_all_lower_get_next_rcu(dev, &(iter)); \
- ldev; \
- ldev = netdev_all_lower_get_next_rcu(dev, &(iter)))
-
int netdev_walk_all_lower_dev(struct net_device *dev,
int (*fn)(struct net_device *lower_dev,
void *data),
diff --git a/net/core/dev.c b/net/core/dev.c
index fc48337cfab8..a9fe14908b44 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5137,6 +5137,13 @@ static struct netdev_adjacent *__netdev_find_adj(struct net_device *adj_dev,
return NULL;
}
+static int __netdev_has_upper_dev(struct net_device *upper_dev, void *data)
+{
+ struct net_device *dev = data;
+
+ return upper_dev == dev;
+}
+
/**
* netdev_has_upper_dev - Check if device is linked to an upper device
* @dev: device
@@ -5151,7 +5158,8 @@ bool netdev_has_upper_dev(struct net_device *dev,
{
ASSERT_RTNL();
- return __netdev_find_adj(upper_dev, &dev->all_adj_list.upper);
+ return netdev_walk_all_upper_dev_rcu(dev, __netdev_has_upper_dev,
+ upper_dev);
}
EXPORT_SYMBOL(netdev_has_upper_dev);
@@ -5165,13 +5173,6 @@ EXPORT_SYMBOL(netdev_has_upper_dev);
* The caller must hold rcu lock.
*/
-static int __netdev_has_upper_dev(struct net_device *upper_dev, void *data)
-{
- struct net_device *dev = data;
-
- return upper_dev == dev;
-}
-
bool netdev_has_upper_dev_all_rcu(struct net_device *dev,
struct net_device *upper_dev)
{
@@ -5191,7 +5192,7 @@ static bool netdev_has_any_upper_dev(struct net_device *dev)
{
ASSERT_RTNL();
- return !list_empty(&dev->all_adj_list.upper);
+ return !list_empty(&dev->adj_list.upper);
}
/**
@@ -5254,32 +5255,6 @@ struct net_device *netdev_upper_get_next_dev_rcu(struct net_device *dev,
}
EXPORT_SYMBOL(netdev_upper_get_next_dev_rcu);
-/**
- * netdev_all_upper_get_next_dev_rcu - Get the next dev from upper list
- * @dev: device
- * @iter: list_head ** of the current position
- *
- * Gets the next device from the dev's upper list, starting from iter
- * position. The caller must hold RCU read lock.
- */
-struct net_device *netdev_all_upper_get_next_dev_rcu(struct net_device *dev,
- struct list_head **iter)
-{
- struct netdev_adjacent *upper;
-
- WARN_ON_ONCE(!rcu_read_lock_held() && !lockdep_rtnl_is_held());
-
- upper = list_entry_rcu((*iter)->next, struct netdev_adjacent, list);
-
- if (&upper->list == &dev->all_adj_list.upper)
- return NULL;
-
- *iter = &upper->list;
-
- return upper->dev;
-}
-EXPORT_SYMBOL(netdev_all_upper_get_next_dev_rcu);
-
static struct net_device *netdev_next_upper_dev_rcu(struct net_device *dev,
struct list_head **iter)
{
@@ -5406,31 +5381,6 @@ void *netdev_lower_get_next(struct net_device *dev, struct list_head **iter)
}
EXPORT_SYMBOL(netdev_lower_get_next);
-/**
- * netdev_all_lower_get_next - Get the next device from all lower neighbour list
- * @dev: device
- * @iter: list_head ** of the current position
- *
- * Gets the next netdev_adjacent from the dev's all lower neighbour
- * list, starting from iter position. The caller must hold RTNL lock or
- * its own locking that guarantees that the neighbour all lower
- * list will remain unchanged.
- */
-struct net_device *netdev_all_lower_get_next(struct net_device *dev, struct list_head **iter)
-{
- struct netdev_adjacent *lower;
-
- lower = list_entry(*iter, struct netdev_adjacent, list);
-
- if (&lower->list == &dev->all_adj_list.lower)
- return NULL;
-
- *iter = lower->list.next;
-
- return lower->dev;
-}
-EXPORT_SYMBOL(netdev_all_lower_get_next);
-
static struct net_device *netdev_next_lower_dev(struct net_device *dev,
struct list_head **iter)
{
@@ -5474,27 +5424,6 @@ int netdev_walk_all_lower_dev(struct net_device *dev,
}
EXPORT_SYMBOL_GPL(netdev_walk_all_lower_dev);
-/**
- * netdev_all_lower_get_next_rcu - Get the next device from all
- * lower neighbour list, RCU variant
- * @dev: device
- * @iter: list_head ** of the current position
- *
- * Gets the next netdev_adjacent from the dev's all lower neighbour
- * list, starting from iter position. The caller must hold RCU read lock.
- */
-struct net_device *netdev_all_lower_get_next_rcu(struct net_device *dev,
- struct list_head **iter)
-{
- struct netdev_adjacent *lower;
-
- lower = list_first_or_null_rcu(&dev->all_adj_list.lower,
- struct netdev_adjacent, list);
-
- return lower ? lower->dev : NULL;
-}
-EXPORT_SYMBOL(netdev_all_lower_get_next_rcu);
-
static struct net_device *netdev_next_lower_dev_rcu(struct net_device *dev,
struct list_head **iter)
{
@@ -5722,15 +5651,6 @@ static int __netdev_adjacent_dev_link_lists(struct net_device *dev,
return 0;
}
-static int __netdev_adjacent_dev_link(struct net_device *dev,
- struct net_device *upper_dev)
-{
- return __netdev_adjacent_dev_link_lists(dev, upper_dev,
- &dev->all_adj_list.upper,
- &upper_dev->all_adj_list.lower,
- NULL, false);
-}
-
static void __netdev_adjacent_dev_unlink_lists(struct net_device *dev,
struct net_device *upper_dev,
u16 ref_nr,
@@ -5741,40 +5661,19 @@ static void __netdev_adjacent_dev_unlink_lists(struct net_device *dev,
__netdev_adjacent_dev_remove(upper_dev, dev, ref_nr, down_list);
}
-static void __netdev_adjacent_dev_unlink(struct net_device *dev,
- struct net_device *upper_dev,
- u16 ref_nr)
-{
- __netdev_adjacent_dev_unlink_lists(dev, upper_dev, ref_nr,
- &dev->all_adj_list.upper,
- &upper_dev->all_adj_list.lower);
-}
-
static int __netdev_adjacent_dev_link_neighbour(struct net_device *dev,
struct net_device *upper_dev,
void *private, bool master)
{
- int ret = __netdev_adjacent_dev_link(dev, upper_dev);
-
- if (ret)
- return ret;
-
- ret = __netdev_adjacent_dev_link_lists(dev, upper_dev,
- &dev->adj_list.upper,
- &upper_dev->adj_list.lower,
- private, master);
- if (ret) {
- __netdev_adjacent_dev_unlink(dev, upper_dev, 1);
- return ret;
- }
-
- return 0;
+ return __netdev_adjacent_dev_link_lists(dev, upper_dev,
+ &dev->adj_list.upper,
+ &upper_dev->adj_list.lower,
+ private, master);
}
static void __netdev_adjacent_dev_unlink_neighbour(struct net_device *dev,
struct net_device *upper_dev)
{
- __netdev_adjacent_dev_unlink(dev, upper_dev, 1);
__netdev_adjacent_dev_unlink_lists(dev, upper_dev, 1,
&dev->adj_list.upper,
&upper_dev->adj_list.lower);
@@ -5785,7 +5684,6 @@ static int __netdev_upper_dev_link(struct net_device *dev,
void *upper_priv, void *upper_info)
{
struct netdev_notifier_changeupper_info changeupper_info;
- struct netdev_adjacent *i, *j, *to_i, *to_j;
int ret = 0;
ASSERT_RTNL();
@@ -5794,10 +5692,10 @@ static int __netdev_upper_dev_link(struct net_device *dev,
return -EBUSY;
/* To prevent loops, check if dev is not upper device to upper_dev. */
- if (__netdev_find_adj(dev, &upper_dev->all_adj_list.upper))
+ if (netdev_has_upper_dev(upper_dev, dev))
return -EBUSY;
- if (__netdev_find_adj(upper_dev, &dev->adj_list.upper))
+ if (netdev_has_upper_dev(dev, upper_dev))
return -EEXIST;
if (master && netdev_master_upper_dev_get(dev))
@@ -5819,80 +5717,15 @@ static int __netdev_upper_dev_link(struct net_device *dev,
if (ret)
return ret;
- /* Now that we linked these devs, make all the upper_dev's
- * all_adj_list.upper visible to every dev's all_adj_list.lower an
- * versa, and don't forget the devices itself. All of these
- * links are non-neighbours.
- */
- list_for_each_entry(i, &dev->all_adj_list.lower, list) {
- list_for_each_entry(j, &upper_dev->all_adj_list.upper, list) {
- pr_debug("Interlinking %s with %s, non-neighbour\n",
- i->dev->name, j->dev->name);
- ret = __netdev_adjacent_dev_link(i->dev, j->dev);
- if (ret)
- goto rollback_mesh;
- }
- }
-
- /* add dev to every upper_dev's upper device */
- list_for_each_entry(i, &upper_dev->all_adj_list.upper, list) {
- pr_debug("linking %s's upper device %s with %s\n",
- upper_dev->name, i->dev->name, dev->name);
- ret = __netdev_adjacent_dev_link(dev, i->dev);
- if (ret)
- goto rollback_upper_mesh;
- }
-
- /* add upper_dev to every dev's lower device */
- list_for_each_entry(i, &dev->all_adj_list.lower, list) {
- pr_debug("linking %s's lower device %s with %s\n", dev->name,
- i->dev->name, upper_dev->name);
- ret = __netdev_adjacent_dev_link(i->dev, upper_dev);
- if (ret)
- goto rollback_lower_mesh;
- }
-
ret = call_netdevice_notifiers_info(NETDEV_CHANGEUPPER, dev,
&changeupper_info.info);
ret = notifier_to_errno(ret);
if (ret)
- goto rollback_lower_mesh;
+ goto rollback;
return 0;
-rollback_lower_mesh:
- to_i = i;
- list_for_each_entry(i, &dev->all_adj_list.lower, list) {
- if (i == to_i)
- break;
- __netdev_adjacent_dev_unlink(i->dev, upper_dev, i->ref_nr);
- }
-
- i = NULL;
-
-rollback_upper_mesh:
- to_i = i;
- list_for_each_entry(i, &upper_dev->all_adj_list.upper, list) {
- if (i == to_i)
- break;
- __netdev_adjacent_dev_unlink(dev, i->dev, i->ref_nr);
- }
-
- i = j = NULL;
-
-rollback_mesh:
- to_i = i;
- to_j = j;
- list_for_each_entry(i, &dev->all_adj_list.lower, list) {
- list_for_each_entry(j, &upper_dev->all_adj_list.upper, list) {
- if (i == to_i && j == to_j)
- break;
- __netdev_adjacent_dev_unlink(i->dev, j->dev, i->ref_nr);
- }
- if (i == to_i)
- break;
- }
-
+rollback:
__netdev_adjacent_dev_unlink_neighbour(dev, upper_dev);
return ret;
@@ -5949,7 +5782,6 @@ void netdev_upper_dev_unlink(struct net_device *dev,
struct net_device *upper_dev)
{
struct netdev_notifier_changeupper_info changeupper_info;
- struct netdev_adjacent *i, *j;
ASSERT_RTNL();
changeupper_info.upper_dev = upper_dev;
@@ -5961,23 +5793,6 @@ void netdev_upper_dev_unlink(struct net_device *dev,
__netdev_adjacent_dev_unlink_neighbour(dev, upper_dev);
- /* Here is the tricky part. We must remove all dev's lower
- * devices from all upper_dev's upper devices and vice
- * versa, to maintain the graph relationship.
- */
- list_for_each_entry(i, &dev->all_adj_list.lower, list)
- list_for_each_entry(j, &upper_dev->all_adj_list.upper, list)
- __netdev_adjacent_dev_unlink(i->dev, j->dev, i->ref_nr);
-
- /* remove also the devices itself from lower/upper device
- * list
- */
- list_for_each_entry(i, &dev->all_adj_list.lower, list)
- __netdev_adjacent_dev_unlink(i->dev, upper_dev, i->ref_nr);
-
- list_for_each_entry(i, &upper_dev->all_adj_list.upper, list)
- __netdev_adjacent_dev_unlink(dev, i->dev, i->ref_nr);
-
call_netdevice_notifiers_info(NETDEV_CHANGEUPPER, dev,
&changeupper_info.info);
}
@@ -7679,8 +7494,6 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
INIT_LIST_HEAD(&dev->link_watch_list);
INIT_LIST_HEAD(&dev->adj_list.upper);
INIT_LIST_HEAD(&dev->adj_list.lower);
- INIT_LIST_HEAD(&dev->all_adj_list.upper);
- INIT_LIST_HEAD(&dev->all_adj_list.lower);
INIT_LIST_HEAD(&dev->ptype_all);
INIT_LIST_HEAD(&dev->ptype_specific);
#ifdef CONFIG_NET_SCHED
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net-next 10/11] net: Add warning if any lower device is still in adjacency list
From: David Ahern @ 2016-10-18 2:15 UTC (permalink / raw)
To: jiri-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
j.vosburgh-Re5JQEeQqe8AvxtiuMwx3w, vfalico-Re5JQEeQqe8AvxtiuMwx3w,
andy-QlMahl40kYEqcZcGjlUOXw,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
intel-wired-lan-qjLDD68F18P21nG7glBr7A, David Ahern
In-Reply-To: <1476756953-30923-1-git-send-email-dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
Lower list should be empty just like upper.
Signed-off-by: David Ahern <dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
---
net/core/dev.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index a9fe14908b44..c6bbf310d407 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5219,6 +5219,20 @@ struct net_device *netdev_master_upper_dev_get(struct net_device *dev)
}
EXPORT_SYMBOL(netdev_master_upper_dev_get);
+/**
+ * netdev_has_any_lower_dev - Check if device is linked to some device
+ * @dev: device
+ *
+ * Find out if a device is linked to a lower device and return true in case
+ * it is. The caller must hold the RTNL lock.
+ */
+static bool netdev_has_any_lower_dev(struct net_device *dev)
+{
+ ASSERT_RTNL();
+
+ return !list_empty(&dev->adj_list.lower);
+}
+
void *netdev_adjacent_get_private(struct list_head *adj_list)
{
struct netdev_adjacent *adj;
@@ -6616,6 +6630,7 @@ static void rollback_registered_many(struct list_head *head)
/* Notifier chain MUST detach us all upper devices. */
WARN_ON(netdev_has_any_upper_dev(dev));
+ WARN_ON(netdev_has_any_lower_dev(dev));
/* Remove entries from kobject tree */
netdev_unregister_kobject(dev);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net-next 11/11] net: dev: Improve debug statements for adjacency tracking
From: David Ahern @ 2016-10-18 2:15 UTC (permalink / raw)
To: jiri-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
j.vosburgh-Re5JQEeQqe8AvxtiuMwx3w, vfalico-Re5JQEeQqe8AvxtiuMwx3w,
andy-QlMahl40kYEqcZcGjlUOXw,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
intel-wired-lan-qjLDD68F18P21nG7glBr7A, David Ahern
In-Reply-To: <1476756953-30923-1-git-send-email-dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
Adjacency code only has debugs for the insert case. Add debugs for
the remove path and make both consistently worded to make it easier
to follow the insert and removal with reference counts.
In addition, change the BUG to a WARN_ON. A missing adjacency at
removal time is not cause for a panic.
Signed-off-by: David Ahern <dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
---
net/core/dev.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index c6bbf310d407..f55fb4536016 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5561,6 +5561,9 @@ static int __netdev_adjacent_dev_insert(struct net_device *dev,
if (adj) {
adj->ref_nr += 1;
+ pr_debug("Insert adjacency: dev %s adj_dev %s adj->ref_nr %d\n",
+ dev->name, adj_dev->name, adj->ref_nr);
+
return 0;
}
@@ -5574,8 +5577,8 @@ static int __netdev_adjacent_dev_insert(struct net_device *dev,
adj->private = private;
dev_hold(adj_dev);
- pr_debug("dev_hold for %s, because of link added from %s to %s\n",
- adj_dev->name, dev->name, adj_dev->name);
+ pr_debug("Insert adjacency: dev %s adj_dev %s adj->ref_nr %d; dev_hold on %s\n",
+ dev->name, adj_dev->name, adj->ref_nr, adj_dev->name);
if (netdev_adjacent_is_neigh_list(dev, adj_dev, dev_list)) {
ret = netdev_adjacent_sysfs_add(dev, adj_dev, dev_list);
@@ -5614,17 +5617,22 @@ static void __netdev_adjacent_dev_remove(struct net_device *dev,
{
struct netdev_adjacent *adj;
+ pr_debug("Remove adjacency: dev %s adj_dev %s ref_nr %d\n",
+ dev->name, adj_dev->name, ref_nr);
+
adj = __netdev_find_adj(adj_dev, dev_list);
if (!adj) {
- pr_err("tried to remove device %s from %s\n",
+ pr_err("Adjacency does not exist for device %s from %s\n",
dev->name, adj_dev->name);
- BUG();
+ WARN_ON(1);
+ return;
}
if (adj->ref_nr > ref_nr) {
- pr_debug("%s to %s ref_nr-%d = %d\n", dev->name, adj_dev->name,
- ref_nr, adj->ref_nr-ref_nr);
+ pr_debug("adjacency: %s to %s ref_nr - %d = %d\n",
+ dev->name, adj_dev->name, ref_nr,
+ adj->ref_nr - ref_nr);
adj->ref_nr -= ref_nr;
return;
}
@@ -5636,7 +5644,7 @@ static void __netdev_adjacent_dev_remove(struct net_device *dev,
netdev_adjacent_sysfs_del(dev, adj_dev->name, dev_list);
list_del_rcu(&adj->list);
- pr_debug("dev_put for %s, because link removed from %s to %s\n",
+ pr_debug("adjacency: dev_put for %s, because link removed from %s to %s\n",
adj_dev->name, dev->name, adj_dev->name);
dev_put(adj_dev);
kfree_rcu(adj, rcu);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: iscsi_trx going into D state
From: Zhu Lingshan @ 2016-10-18 3:06 UTC (permalink / raw)
To: Robert LeBlanc
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAANLjFoh+C8QE=qcPKqUUG3SnH2EMmS7DWZ5D4AD7yWMxoK0Zw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Robert,
I think the reason why you can not logout the targets is that iscsi_np
in D status. I think the patches fixed something, but it seems to be
more than one code path can trigger these similar issues. as you can
see, there are several call stacks, I am still working on it. Actually
in my environment I see there is another call stack not listed in your
mail....
Thanks,
BR
Zhu Lingshan
On 10/18/2016 03:11 AM, Robert LeBlanc wrote:
> Sorry hit send too soon.
>
> In addition, on the client we see:
> # ps -aux | grep D | grep kworker
> root 5583 0.0 0.0 0 0 ? D 11:55 0:03 [kworker/11:0]
> root 7721 0.1 0.0 0 0 ? D 12:00 0:04 [kworker/4:25]
> root 10877 0.0 0.0 0 0 ? D 09:27 0:00 [kworker/22:1]
> root 11246 0.0 0.0 0 0 ? D 10:28 0:00 [kworker/30:2]
> root 14034 0.0 0.0 0 0 ? D 12:20 0:02 [kworker/19:15]
> root 14048 0.0 0.0 0 0 ? D 12:20 0:00 [kworker/16:0]
> root 15871 0.0 0.0 0 0 ? D 12:25 0:00 [kworker/13:0]
> root 17442 0.0 0.0 0 0 ? D 12:28 0:00 [kworker/9:1]
> root 17816 0.0 0.0 0 0 ? D 12:30 0:00 [kworker/11:1]
> root 18744 0.0 0.0 0 0 ? D 12:32 0:00 [kworker/10:2]
> root 19060 0.0 0.0 0 0 ? D 12:32 0:00 [kworker/29:0]
> root 21748 0.0 0.0 0 0 ? D 12:40 0:00 [kworker/21:0]
> root 21967 0.0 0.0 0 0 ? D 12:40 0:00 [kworker/22:0]
> root 21978 0.0 0.0 0 0 ? D 12:40 0:00 [kworker/22:2]
> root 22024 0.0 0.0 0 0 ? D 12:40 0:00 [kworker/22:4]
> root 22035 0.0 0.0 0 0 ? D 12:40 0:00 [kworker/22:5]
> root 22060 0.0 0.0 0 0 ? D 12:40 0:00 [kworker/16:1]
> root 22282 0.0 0.0 0 0 ? D 12:41 0:00 [kworker/26:0]
> root 22362 0.0 0.0 0 0 ? D 12:42 0:00 [kworker/18:9]
> root 22426 0.0 0.0 0 0 ? D 12:42 0:00 [kworker/16:3]
> root 23298 0.0 0.0 0 0 ? D 12:43 0:00 [kworker/12:1]
> root 23302 0.0 0.0 0 0 ? D 12:43 0:00 [kworker/12:5]
> root 24264 0.0 0.0 0 0 ? D 12:46 0:00 [kworker/30:1]
> root 24271 0.0 0.0 0 0 ? D 12:46 0:00 [kworker/14:8]
> root 24441 0.0 0.0 0 0 ? D 12:47 0:00 [kworker/9:7]
> root 24443 0.0 0.0 0 0 ? D 12:47 0:00 [kworker/9:9]
> root 25005 0.0 0.0 0 0 ? D 12:48 0:00 [kworker/30:3]
> root 25158 0.0 0.0 0 0 ? D 12:49 0:00 [kworker/9:12]
> root 26382 0.0 0.0 0 0 ? D 12:52 0:00 [kworker/13:2]
> root 26453 0.0 0.0 0 0 ? D 12:52 0:00 [kworker/21:2]
> root 26724 0.0 0.0 0 0 ? D 12:53 0:00 [kworker/19:1]
> root 28400 0.0 0.0 0 0 ? D 05:20 0:00 [kworker/25:1]
> root 29552 0.0 0.0 0 0 ? D 11:40 0:00 [kworker/17:1]
> root 29811 0.0 0.0 0 0 ? D 11:40 0:00 [kworker/7:10]
> root 31903 0.0 0.0 0 0 ? D 11:43 0:00 [kworker/26:1]
>
> And all of the processes have this stack:
> [<ffffffffa0727ed5>] iser_release_work+0x25/0x60 [ib_iser]
> [<ffffffff8109633f>] process_one_work+0x14f/0x400
> [<ffffffff81096bb4>] worker_thread+0x114/0x470
> [<ffffffff8109c6f8>] kthread+0xd8/0xf0
> [<ffffffff8172004f>] ret_from_fork+0x3f/0x70
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> We are not able to log out of the sessions in all cases. And have to
> restart the box.
>
> iscsiadm -m session will show messages like:
> iscsiadm: could not read session targetname: 5
> iscsiadm: could not find session info for session100
> iscsiadm: could not read session targetname: 5
> iscsiadm: could not find session info for session101
> iscsiadm: could not read session targetname: 5
> iscsiadm: could not find session info for session103
> ...
>
> I can't find any way to force iscsiadm to clean up these sessions
> possibly due to tasks in D state.
> ----------------
> Robert LeBlanc
> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
>
>
> On Mon, Oct 17, 2016 at 10:32 AM, Robert LeBlanc <robert-4JaGZRWAfWbajFs6igw21g@public.gmane.org> wrote:
>> Some more info as we hit this this morning. We have volumes mirrored
>> between two targets and we had one target on the kernel with the three
>> patches mentioned in this thread [0][1][2] and the other was on a
>> kernel without the patches. We decided that after a week and a half we
>> wanted to get both targets on the same kernel so we rebooted the
>> non-patched target. Within an hour we saw iSCSI in D state with the
>> same stack trace so it seems that we are not hitting any of the
>> WARN_ON lines. We are getting both iscsi_trx and iscsi_np both in D
>> state, this time we have two iscsi_trx processes in D state. I don't
>> know if stale sessions on the clients could be contributing to this
>> issue (the target trying to close non-existent sessions??). This is on
>> 4.4.23. Any more debug info we can throw at this problem to help?
>>
>> Thank you,
>> Robert LeBlanc
>>
>> # ps aux | grep D | grep iscsi
>> root 16525 0.0 0.0 0 0 ? D 08:50 0:00 [iscsi_np]
>> root 16614 0.0 0.0 0 0 ? D 08:50 0:00 [iscsi_trx]
>> root 16674 0.0 0.0 0 0 ? D 08:50 0:00 [iscsi_trx]
>>
>> # for i in 16525 16614 16674; do echo $i; cat /proc/$i/stack; done
>> 16525
>> [<ffffffff814f0d5f>] iscsit_stop_session+0x19f/0x1d0
>> [<ffffffff814e2516>] iscsi_check_for_session_reinstatement+0x1e6/0x270
>> [<ffffffff814e4ed0>] iscsi_target_check_for_existing_instances+0x30/0x40
>> [<ffffffff814e5020>] iscsi_target_do_login+0x140/0x640
>> [<ffffffff814e63bc>] iscsi_target_start_negotiation+0x1c/0xb0
>> [<ffffffff814e410b>] iscsi_target_login_thread+0xa9b/0xfc0
>> [<ffffffff8109c748>] kthread+0xd8/0xf0
>> [<ffffffff8172018f>] ret_from_fork+0x3f/0x70
>> [<ffffffffffffffff>] 0xffffffffffffffff
>> 16614
>> [<ffffffff814cca79>] target_wait_for_sess_cmds+0x49/0x1a0
>> [<ffffffffa064692b>] isert_wait_conn+0x1ab/0x2f0 [ib_isert]
>> [<ffffffff814f0ef2>] iscsit_close_connection+0x162/0x870
>> [<ffffffff814df9bf>] iscsit_take_action_for_connection_exit+0x7f/0x100
>> [<ffffffff814f00a0>] iscsi_target_rx_thread+0x5a0/0xe80
>> [<ffffffff8109c748>] kthread+0xd8/0xf0
>> [<ffffffff8172018f>] ret_from_fork+0x3f/0x70
>> [<ffffffffffffffff>] 0xffffffffffffffff
>> 16674
>> [<ffffffff814cca79>] target_wait_for_sess_cmds+0x49/0x1a0
>> [<ffffffffa064692b>] isert_wait_conn+0x1ab/0x2f0 [ib_isert]
>> [<ffffffff814f0ef2>] iscsit_close_connection+0x162/0x870
>> [<ffffffff814df9bf>] iscsit_take_action_for_connection_exit+0x7f/0x100
>> [<ffffffff814f00a0>] iscsi_target_rx_thread+0x5a0/0xe80
>> [<ffffffff8109c748>] kthread+0xd8/0xf0
>> [<ffffffff8172018f>] ret_from_fork+0x3f/0x70
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
>>
>> [0] https://www.spinics.net/lists/target-devel/msg13463.html
>> [1] http://marc.info/?l=linux-scsi&m=147282568910535&w=2
>> [2] http://www.spinics.net/lists/linux-scsi/msg100221.html
>> ----------------
>> Robert LeBlanc
>> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
>>
>>
>> On Fri, Oct 7, 2016 at 8:59 PM, Zhu Lingshan <lszhu-IBi9RG/b67k@public.gmane.org> wrote:
>>> Hi Robert,
>>>
>>> I also see this issue, but this is not the only code path can trigger this
>>> problem, I think you may also see iscsi_np in D status. I fixed one code
>>> path whitch still not merged to mainline. I will forward you my patch later.
>>> Note: my patch only fixed one code path, you may see other call statck with
>>> D status.
>>>
>>> Thanks,
>>> BR
>>> Zhu Lingshan
>>>
>>>
>>> 在 2016/10/1 1:14, Robert LeBlanc 写道:
>>>> We are having a reoccurring problem where iscsi_trx is going into D
>>>> state. It seems like it is waiting for a session tear down to happen
>>>> or something, but keeps waiting. We have to reboot these targets on
>>>> occasion. This is running the 4.4.12 kernel and we have seen it on
>>>> several previous 4.4.x and 4.2.x kernels. There is no message in dmesg
>>>> or /var/log/messages. This seems to happen with increased frequency
>>>> when we have a disruption in our Infiniband fabric, but can happen
>>>> without any changes to the fabric (other than hosts rebooting).
>>>>
>>>> # ps aux | grep iscsi | grep D
>>>> root 4185 0.0 0.0 0 0 ? D Sep29 0:00
>>>> [iscsi_trx]
>>>> root 18505 0.0 0.0 0 0 ? D Sep29 0:00
>>>> [iscsi_np]
>>>>
>>>> # cat /proc/4185/stack
>>>> [<ffffffff814cc999>] target_wait_for_sess_cmds+0x49/0x1a0
>>>> [<ffffffffa087292b>] isert_wait_conn+0x1ab/0x2f0 [ib_isert]
>>>> [<ffffffff814f0de2>] iscsit_close_connection+0x162/0x840
>>>> [<ffffffff814df8df>] iscsit_take_action_for_connection_exit+0x7f/0x100
>>>> [<ffffffff814effc0>] iscsi_target_rx_thread+0x5a0/0xe80
>>>> [<ffffffff8109c6f8>] kthread+0xd8/0xf0
>>>> [<ffffffff8172004f>] ret_from_fork+0x3f/0x70
>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>
>>>> # cat /proc/18505/stack
>>>> [<ffffffff814f0c71>] iscsit_stop_session+0x1b1/0x1c0
>>>> [<ffffffff814e2436>] iscsi_check_for_session_reinstatement+0x1e6/0x270
>>>> [<ffffffff814e4df0>] iscsi_target_check_for_existing_instances+0x30/0x40
>>>> [<ffffffff814e4f40>] iscsi_target_do_login+0x140/0x640
>>>> [<ffffffff814e62dc>] iscsi_target_start_negotiation+0x1c/0xb0
>>>> [<ffffffff814e402b>] iscsi_target_login_thread+0xa9b/0xfc0
>>>> [<ffffffff8109c6f8>] kthread+0xd8/0xf0
>>>> [<ffffffff8172004f>] ret_from_fork+0x3f/0x70
>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>
>>>> What can we do to help get this resolved?
>>>>
>>>> Thanks,
>>>>
>>>> ----------------
>>>> Robert LeBlanc
>>>> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: iscsi_trx going into D state
From: Robert LeBlanc @ 2016-10-18 4:42 UTC (permalink / raw)
To: Zhu Lingshan
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4fc72e32-26fb-96bd-8a0d-814eef712b43-IBi9RG/b67k@public.gmane.org>
Sorry I forget that Android has an aversion to plain text emails.
If we can provide any information to help, let us know. We are willing
to patch in more debug statements or whatever you think might help.
Today has been a difficult day. Thanks for looking into it, I tried
looking at it, but it is way over my head.
----------------
Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
On Mon, Oct 17, 2016 at 9:06 PM, Zhu Lingshan <lszhu-IBi9RG/b67k@public.gmane.org> wrote:
> Hi Robert,
>
> I think the reason why you can not logout the targets is that iscsi_np in D
> status. I think the patches fixed something, but it seems to be more than
> one code path can trigger these similar issues. as you can see, there are
> several call stacks, I am still working on it. Actually in my environment I
> see there is another call stack not listed in your mail....
>
> Thanks,
> BR
> Zhu Lingshan
>
>
> On 10/18/2016 03:11 AM, Robert LeBlanc wrote:
>>
>> Sorry hit send too soon.
>>
>> In addition, on the client we see:
>> # ps -aux | grep D | grep kworker
>> root 5583 0.0 0.0 0 0 ? D 11:55 0:03
>> [kworker/11:0]
>> root 7721 0.1 0.0 0 0 ? D 12:00 0:04
>> [kworker/4:25]
>> root 10877 0.0 0.0 0 0 ? D 09:27 0:00
>> [kworker/22:1]
>> root 11246 0.0 0.0 0 0 ? D 10:28 0:00
>> [kworker/30:2]
>> root 14034 0.0 0.0 0 0 ? D 12:20 0:02
>> [kworker/19:15]
>> root 14048 0.0 0.0 0 0 ? D 12:20 0:00
>> [kworker/16:0]
>> root 15871 0.0 0.0 0 0 ? D 12:25 0:00
>> [kworker/13:0]
>> root 17442 0.0 0.0 0 0 ? D 12:28 0:00
>> [kworker/9:1]
>> root 17816 0.0 0.0 0 0 ? D 12:30 0:00
>> [kworker/11:1]
>> root 18744 0.0 0.0 0 0 ? D 12:32 0:00
>> [kworker/10:2]
>> root 19060 0.0 0.0 0 0 ? D 12:32 0:00
>> [kworker/29:0]
>> root 21748 0.0 0.0 0 0 ? D 12:40 0:00
>> [kworker/21:0]
>> root 21967 0.0 0.0 0 0 ? D 12:40 0:00
>> [kworker/22:0]
>> root 21978 0.0 0.0 0 0 ? D 12:40 0:00
>> [kworker/22:2]
>> root 22024 0.0 0.0 0 0 ? D 12:40 0:00
>> [kworker/22:4]
>> root 22035 0.0 0.0 0 0 ? D 12:40 0:00
>> [kworker/22:5]
>> root 22060 0.0 0.0 0 0 ? D 12:40 0:00
>> [kworker/16:1]
>> root 22282 0.0 0.0 0 0 ? D 12:41 0:00
>> [kworker/26:0]
>> root 22362 0.0 0.0 0 0 ? D 12:42 0:00
>> [kworker/18:9]
>> root 22426 0.0 0.0 0 0 ? D 12:42 0:00
>> [kworker/16:3]
>> root 23298 0.0 0.0 0 0 ? D 12:43 0:00
>> [kworker/12:1]
>> root 23302 0.0 0.0 0 0 ? D 12:43 0:00
>> [kworker/12:5]
>> root 24264 0.0 0.0 0 0 ? D 12:46 0:00
>> [kworker/30:1]
>> root 24271 0.0 0.0 0 0 ? D 12:46 0:00
>> [kworker/14:8]
>> root 24441 0.0 0.0 0 0 ? D 12:47 0:00
>> [kworker/9:7]
>> root 24443 0.0 0.0 0 0 ? D 12:47 0:00
>> [kworker/9:9]
>> root 25005 0.0 0.0 0 0 ? D 12:48 0:00
>> [kworker/30:3]
>> root 25158 0.0 0.0 0 0 ? D 12:49 0:00
>> [kworker/9:12]
>> root 26382 0.0 0.0 0 0 ? D 12:52 0:00
>> [kworker/13:2]
>> root 26453 0.0 0.0 0 0 ? D 12:52 0:00
>> [kworker/21:2]
>> root 26724 0.0 0.0 0 0 ? D 12:53 0:00
>> [kworker/19:1]
>> root 28400 0.0 0.0 0 0 ? D 05:20 0:00
>> [kworker/25:1]
>> root 29552 0.0 0.0 0 0 ? D 11:40 0:00
>> [kworker/17:1]
>> root 29811 0.0 0.0 0 0 ? D 11:40 0:00
>> [kworker/7:10]
>> root 31903 0.0 0.0 0 0 ? D 11:43 0:00
>> [kworker/26:1]
>>
>> And all of the processes have this stack:
>> [<ffffffffa0727ed5>] iser_release_work+0x25/0x60 [ib_iser]
>> [<ffffffff8109633f>] process_one_work+0x14f/0x400
>> [<ffffffff81096bb4>] worker_thread+0x114/0x470
>> [<ffffffff8109c6f8>] kthread+0xd8/0xf0
>> [<ffffffff8172004f>] ret_from_fork+0x3f/0x70
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
>> We are not able to log out of the sessions in all cases. And have to
>> restart the box.
>>
>> iscsiadm -m session will show messages like:
>> iscsiadm: could not read session targetname: 5
>> iscsiadm: could not find session info for session100
>> iscsiadm: could not read session targetname: 5
>> iscsiadm: could not find session info for session101
>> iscsiadm: could not read session targetname: 5
>> iscsiadm: could not find session info for session103
>> ...
>>
>> I can't find any way to force iscsiadm to clean up these sessions
>> possibly due to tasks in D state.
>> ----------------
>> Robert LeBlanc
>> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
>>
>>
>> On Mon, Oct 17, 2016 at 10:32 AM, Robert LeBlanc <robert-4JaGZRWAfWbajFs6igw21g@public.gmane.org>
>> wrote:
>>>
>>> Some more info as we hit this this morning. We have volumes mirrored
>>> between two targets and we had one target on the kernel with the three
>>> patches mentioned in this thread [0][1][2] and the other was on a
>>> kernel without the patches. We decided that after a week and a half we
>>> wanted to get both targets on the same kernel so we rebooted the
>>> non-patched target. Within an hour we saw iSCSI in D state with the
>>> same stack trace so it seems that we are not hitting any of the
>>> WARN_ON lines. We are getting both iscsi_trx and iscsi_np both in D
>>> state, this time we have two iscsi_trx processes in D state. I don't
>>> know if stale sessions on the clients could be contributing to this
>>> issue (the target trying to close non-existent sessions??). This is on
>>> 4.4.23. Any more debug info we can throw at this problem to help?
>>>
>>> Thank you,
>>> Robert LeBlanc
>>>
>>> # ps aux | grep D | grep iscsi
>>> root 16525 0.0 0.0 0 0 ? D 08:50 0:00
>>> [iscsi_np]
>>> root 16614 0.0 0.0 0 0 ? D 08:50 0:00
>>> [iscsi_trx]
>>> root 16674 0.0 0.0 0 0 ? D 08:50 0:00
>>> [iscsi_trx]
>>>
>>> # for i in 16525 16614 16674; do echo $i; cat /proc/$i/stack; done
>>> 16525
>>> [<ffffffff814f0d5f>] iscsit_stop_session+0x19f/0x1d0
>>> [<ffffffff814e2516>] iscsi_check_for_session_reinstatement+0x1e6/0x270
>>> [<ffffffff814e4ed0>] iscsi_target_check_for_existing_instances+0x30/0x40
>>> [<ffffffff814e5020>] iscsi_target_do_login+0x140/0x640
>>> [<ffffffff814e63bc>] iscsi_target_start_negotiation+0x1c/0xb0
>>> [<ffffffff814e410b>] iscsi_target_login_thread+0xa9b/0xfc0
>>> [<ffffffff8109c748>] kthread+0xd8/0xf0
>>> [<ffffffff8172018f>] ret_from_fork+0x3f/0x70
>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>> 16614
>>> [<ffffffff814cca79>] target_wait_for_sess_cmds+0x49/0x1a0
>>> [<ffffffffa064692b>] isert_wait_conn+0x1ab/0x2f0 [ib_isert]
>>> [<ffffffff814f0ef2>] iscsit_close_connection+0x162/0x870
>>> [<ffffffff814df9bf>] iscsit_take_action_for_connection_exit+0x7f/0x100
>>> [<ffffffff814f00a0>] iscsi_target_rx_thread+0x5a0/0xe80
>>> [<ffffffff8109c748>] kthread+0xd8/0xf0
>>> [<ffffffff8172018f>] ret_from_fork+0x3f/0x70
>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>> 16674
>>> [<ffffffff814cca79>] target_wait_for_sess_cmds+0x49/0x1a0
>>> [<ffffffffa064692b>] isert_wait_conn+0x1ab/0x2f0 [ib_isert]
>>> [<ffffffff814f0ef2>] iscsit_close_connection+0x162/0x870
>>> [<ffffffff814df9bf>] iscsit_take_action_for_connection_exit+0x7f/0x100
>>> [<ffffffff814f00a0>] iscsi_target_rx_thread+0x5a0/0xe80
>>> [<ffffffff8109c748>] kthread+0xd8/0xf0
>>> [<ffffffff8172018f>] ret_from_fork+0x3f/0x70
>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>
>>>
>>> [0] https://www.spinics.net/lists/target-devel/msg13463.html
>>> [1] http://marc.info/?l=linux-scsi&m=147282568910535&w=2
>>> [2] http://www.spinics.net/lists/linux-scsi/msg100221.html
>>> ----------------
>>> Robert LeBlanc
>>> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
>>>
>>>
>>> On Fri, Oct 7, 2016 at 8:59 PM, Zhu Lingshan <lszhu-IBi9RG/b67k@public.gmane.org> wrote:
>>>>
>>>> Hi Robert,
>>>>
>>>> I also see this issue, but this is not the only code path can trigger
>>>> this
>>>> problem, I think you may also see iscsi_np in D status. I fixed one code
>>>> path whitch still not merged to mainline. I will forward you my patch
>>>> later.
>>>> Note: my patch only fixed one code path, you may see other call statck
>>>> with
>>>> D status.
>>>>
>>>> Thanks,
>>>> BR
>>>> Zhu Lingshan
>>>>
>>>>
>>>> 在 2016/10/1 1:14, Robert LeBlanc 写道:
>>>>>
>>>>> We are having a reoccurring problem where iscsi_trx is going into D
>>>>> state. It seems like it is waiting for a session tear down to happen
>>>>> or something, but keeps waiting. We have to reboot these targets on
>>>>> occasion. This is running the 4.4.12 kernel and we have seen it on
>>>>> several previous 4.4.x and 4.2.x kernels. There is no message in dmesg
>>>>> or /var/log/messages. This seems to happen with increased frequency
>>>>> when we have a disruption in our Infiniband fabric, but can happen
>>>>> without any changes to the fabric (other than hosts rebooting).
>>>>>
>>>>> # ps aux | grep iscsi | grep D
>>>>> root 4185 0.0 0.0 0 0 ? D Sep29 0:00
>>>>> [iscsi_trx]
>>>>> root 18505 0.0 0.0 0 0 ? D Sep29 0:00
>>>>> [iscsi_np]
>>>>>
>>>>> # cat /proc/4185/stack
>>>>> [<ffffffff814cc999>] target_wait_for_sess_cmds+0x49/0x1a0
>>>>> [<ffffffffa087292b>] isert_wait_conn+0x1ab/0x2f0 [ib_isert]
>>>>> [<ffffffff814f0de2>] iscsit_close_connection+0x162/0x840
>>>>> [<ffffffff814df8df>] iscsit_take_action_for_connection_exit+0x7f/0x100
>>>>> [<ffffffff814effc0>] iscsi_target_rx_thread+0x5a0/0xe80
>>>>> [<ffffffff8109c6f8>] kthread+0xd8/0xf0
>>>>> [<ffffffff8172004f>] ret_from_fork+0x3f/0x70
>>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>>
>>>>> # cat /proc/18505/stack
>>>>> [<ffffffff814f0c71>] iscsit_stop_session+0x1b1/0x1c0
>>>>> [<ffffffff814e2436>] iscsi_check_for_session_reinstatement+0x1e6/0x270
>>>>> [<ffffffff814e4df0>]
>>>>> iscsi_target_check_for_existing_instances+0x30/0x40
>>>>> [<ffffffff814e4f40>] iscsi_target_do_login+0x140/0x640
>>>>> [<ffffffff814e62dc>] iscsi_target_start_negotiation+0x1c/0xb0
>>>>> [<ffffffff814e402b>] iscsi_target_login_thread+0xa9b/0xfc0
>>>>> [<ffffffff8109c6f8>] kthread+0xd8/0xf0
>>>>> [<ffffffff8172004f>] ret_from_fork+0x3f/0x70
>>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>>
>>>>> What can we do to help get this resolved?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> ----------------
>>>>> Robert LeBlanc
>>>>> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-scsi"
>>>>> in
>>>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: 【For help】 some tips for upstream the userspace driver code of hns_roce
From: Leon Romanovsky @ 2016-10-18 5:03 UTC (permalink / raw)
To: oulijun; +Cc: Doug Ledford, Linuxarm, linux-rdma
In-Reply-To: <5804B615.2010002-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]
On Mon, Oct 17, 2016 at 07:29:25PM +0800, oulijun wrote:
> 在 2016/10/13 17:36, Leon Romanovsky 写道:
> > On Thu, Oct 13, 2016 at 04:09:46PM +0800, oulijun wrote:
> >> Hi, Doug Ledford
> >> Now, I am preparing for upstreaming the userspace driver code of hns_roce. But, we have
> >> some difficulty how to upstream it. for example,
> >> i) which branch of ofed should we upstream ?
> >> ii) if want to upstream the userspace driver of hns_roce successfully, how we should do?
> >>
> >> Can you give me some guides?
> >
> > Hi Lijun,
> >
> > Our main library for all user-space stack is located at github [1].
> > Please see similar question from Ram [2] and Jason's response [3] to it.
> >
> > [1] github.com/linux-rdma/rdma-core
> > [2[ http://marc.info/?l=linux-rdma&m=147574131706820&w=2
> > [3] http://marc.info/?l=linux-rdma&m=147577168016989&w=2
> >
> > Thanks.
> >
> >>
> >> thanks
> >> Lijun Ou
> >>
> Hi, leon
> if i will upstream the patch for user-space code, how to guarantee the code format satisfied the rdma-core.git?
> As is known to all, the kernel driver code will be checked by checkpatch.pl, the rdma-core.git also use the
> checkpatch.pl script?
There is no strict enforcement for specific coding style in this
package and we don't have checkpatch-like utility for rdma-core.
I would be happy to see kernel coding style in this repository, but
won't prevent acceptance for code which is written in other adequate style
(constant across new code and clear to read).
It can be changed in the future, once we decide to unify coding style in
rdma-core, but we are not there yet.
>
> thanks
>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> >> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: building rdma-core from travis
From: Leon Romanovsky @ 2016-10-18 5:08 UTC (permalink / raw)
To: Hefty, Sean
Cc: linux-rdma (linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373AB096A91-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
On Tue, Oct 18, 2016 at 12:06:19AM +0000, Hefty, Sean wrote:
> > CMake Error at CMakeLists.txt:23 (cmake_minimum_required):
> >
> > CMake 2.8.11 or higher is required. You are running version 2.8.7
> >
> >
> > I can see that travis runs successfully against rdma-core. Was there a
> > magic setting used to work-around the travis version?
>
> It looks like rdma-core requires the 'trusty' build on travis...
Yes, you are right.
"# We need at least cmake 2.12, this means we need to use trusty."
http://marc.info/?l=linux-rdma&m=147587977913428&w=2
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 6/8] IB/hns: Replace counting semaphore event_sem with wait condition
From: Binoy Jayan @ 2016-10-18 5:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Doug Ledford, Sean Hefty, Hal Rosenstock,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Linux kernel mailing list
In-Reply-To: <5900385.6T4BAIyXjD@wuerfel>
On 18 October 2016 at 01:59, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Monday, October 17, 2016 10:01:00 PM CEST Binoy Jayan wrote:
>> --- a/drivers/infiniband/hw/hns/hns_roce_cmd.c
>> +++ b/drivers/infiniband/hw/hns/hns_roce_cmd.c
>> @@ -248,10 +248,14 @@ static int hns_roce_cmd_mbox_wait(struct hns_roce_dev *hr_dev, u64 in_param,
>> {
>> int ret = 0;
>>
>> - down(&hr_dev->cmd.event_sem);
>> + wait_event(hr_dev->cmd.event_sem.wq,
>> + atomic_add_unless(&hr_dev->cmd.event_sem.count, -1, 0));
>> +
>> ret = __hns_roce_cmd_mbox_wait(hr_dev, in_param, out_param,
>> in_modifier, op_modifier, op, timeout);
>> - up(&hr_dev->cmd.event_sem);
>> +
>> + if (atomic_inc_return(&hr_dev->cmd.event_sem.count) == 1)
>> + wake_up(&hr_dev->cmd.event_sem.wq);
>>
>> return ret;
>> }
>
> This is the only interesting use of the event_sem that cares about
> the counting and it protects the __hns_roce_cmd_mbox_wait() from being
> entered too often. The count here is the number of size of the
> hr_dev->cmd.context[] array.
>
> However, that function already use a spinlock to protect that array
> and pick the correct context. I think changing the inner function
> to handle the case of 'no context available' by using a waitqueue
> without counting anything would be a reasonable transformation
> away from the semaphore.
>
> Arnd
Hi Arnd,
Thank you for replying for the questions. I''ll look for alternatives
for patches
6,7 and 8 and resend the series.
-Binoy
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 03/28] [v2] infiniband: shut up a maybe-uninitialized warning
From: Haggai Eran @ 2016-10-18 6:47 UTC (permalink / raw)
To: Arnd Bergmann, Doug Ledford
Cc: Linus Torvalds, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Sean Hefty,
Hal Rosenstock, Matan Barak, Leon Romanovsky, Sagi Grimberg,
Bart Van Assche, Alex Vesker, Guy Shapiro,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161017220557.1688282-3-arnd-r2nGTMty4D4@public.gmane.org>
On 10/18/2016 1:05 AM, Arnd Bergmann wrote:
> @@ -1309,7 +1311,7 @@ static bool validate_net_dev(struct net_device *net_dev,
> static struct net_device *cma_get_net_dev(struct ib_cm_event *ib_event,
> const struct cma_req_info *req)
> {
> - struct sockaddr_storage listen_addr_storage, src_addr_storage;
> + struct sockaddr_storage listen_addr_storage = {}, src_addr_storage = {};
Doesn't this still translate to an extra initialization that Doug was
worried about?
Haggai
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: iscsi_trx going into D state
From: Nicholas A. Bellinger @ 2016-10-18 7:05 UTC (permalink / raw)
To: Robert LeBlanc; +Cc: Zhu Lingshan, linux-rdma, linux-scsi
In-Reply-To: <CAANLjFpx1MRNiu2388pY+U0O5z9gw+OJBtpOof47Lb_DxaJSBQ@mail.gmail.com>
Hello Robert, Zhu & Co,
Thanks for your detailed bug report. Comments inline below.
On Mon, 2016-10-17 at 22:42 -0600, Robert LeBlanc wrote:
> Sorry I forget that Android has an aversion to plain text emails.
>
> If we can provide any information to help, let us know. We are willing
> to patch in more debug statements or whatever you think might help.
> Today has been a difficult day. Thanks for looking into it, I tried
> looking at it, but it is way over my head.
>
> ----------------
> Robert LeBlanc
> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
>
>
> On Mon, Oct 17, 2016 at 9:06 PM, Zhu Lingshan <lszhu@suse.com> wrote:
> > Hi Robert,
> >
> > I think the reason why you can not logout the targets is that iscsi_np in D
> > status. I think the patches fixed something, but it seems to be more than
> > one code path can trigger these similar issues. as you can see, there are
> > several call stacks, I am still working on it. Actually in my environment I
> > see there is another call stack not listed in your mail....
> >
> > Thanks,
> > BR
> > Zhu Lingshan
> >
> >
> > On 10/18/2016 03:11 AM, Robert LeBlanc wrote:
> >>
> >> Sorry hit send too soon.
> >>
> >> In addition, on the client we see:
> >> # ps -aux | grep D | grep kworker
> >> root 5583 0.0 0.0 0 0 ? D 11:55 0:03
> >> [kworker/11:0]
> >> root 7721 0.1 0.0 0 0 ? D 12:00 0:04
> >> [kworker/4:25]
> >> root 10877 0.0 0.0 0 0 ? D 09:27 0:00
> >> [kworker/22:1]
> >> root 11246 0.0 0.0 0 0 ? D 10:28 0:00
> >> [kworker/30:2]
> >> root 14034 0.0 0.0 0 0 ? D 12:20 0:02
> >> [kworker/19:15]
> >> root 14048 0.0 0.0 0 0 ? D 12:20 0:00
> >> [kworker/16:0]
> >> root 15871 0.0 0.0 0 0 ? D 12:25 0:00
> >> [kworker/13:0]
> >> root 17442 0.0 0.0 0 0 ? D 12:28 0:00
> >> [kworker/9:1]
> >> root 17816 0.0 0.0 0 0 ? D 12:30 0:00
> >> [kworker/11:1]
> >> root 18744 0.0 0.0 0 0 ? D 12:32 0:00
> >> [kworker/10:2]
> >> root 19060 0.0 0.0 0 0 ? D 12:32 0:00
> >> [kworker/29:0]
> >> root 21748 0.0 0.0 0 0 ? D 12:40 0:00
> >> [kworker/21:0]
> >> root 21967 0.0 0.0 0 0 ? D 12:40 0:00
> >> [kworker/22:0]
> >> root 21978 0.0 0.0 0 0 ? D 12:40 0:00
> >> [kworker/22:2]
> >> root 22024 0.0 0.0 0 0 ? D 12:40 0:00
> >> [kworker/22:4]
> >> root 22035 0.0 0.0 0 0 ? D 12:40 0:00
> >> [kworker/22:5]
> >> root 22060 0.0 0.0 0 0 ? D 12:40 0:00
> >> [kworker/16:1]
> >> root 22282 0.0 0.0 0 0 ? D 12:41 0:00
> >> [kworker/26:0]
> >> root 22362 0.0 0.0 0 0 ? D 12:42 0:00
> >> [kworker/18:9]
> >> root 22426 0.0 0.0 0 0 ? D 12:42 0:00
> >> [kworker/16:3]
> >> root 23298 0.0 0.0 0 0 ? D 12:43 0:00
> >> [kworker/12:1]
> >> root 23302 0.0 0.0 0 0 ? D 12:43 0:00
> >> [kworker/12:5]
> >> root 24264 0.0 0.0 0 0 ? D 12:46 0:00
> >> [kworker/30:1]
> >> root 24271 0.0 0.0 0 0 ? D 12:46 0:00
> >> [kworker/14:8]
> >> root 24441 0.0 0.0 0 0 ? D 12:47 0:00
> >> [kworker/9:7]
> >> root 24443 0.0 0.0 0 0 ? D 12:47 0:00
> >> [kworker/9:9]
> >> root 25005 0.0 0.0 0 0 ? D 12:48 0:00
> >> [kworker/30:3]
> >> root 25158 0.0 0.0 0 0 ? D 12:49 0:00
> >> [kworker/9:12]
> >> root 26382 0.0 0.0 0 0 ? D 12:52 0:00
> >> [kworker/13:2]
> >> root 26453 0.0 0.0 0 0 ? D 12:52 0:00
> >> [kworker/21:2]
> >> root 26724 0.0 0.0 0 0 ? D 12:53 0:00
> >> [kworker/19:1]
> >> root 28400 0.0 0.0 0 0 ? D 05:20 0:00
> >> [kworker/25:1]
> >> root 29552 0.0 0.0 0 0 ? D 11:40 0:00
> >> [kworker/17:1]
> >> root 29811 0.0 0.0 0 0 ? D 11:40 0:00
> >> [kworker/7:10]
> >> root 31903 0.0 0.0 0 0 ? D 11:43 0:00
> >> [kworker/26:1]
> >>
> >> And all of the processes have this stack:
> >> [<ffffffffa0727ed5>] iser_release_work+0x25/0x60 [ib_iser]
> >> [<ffffffff8109633f>] process_one_work+0x14f/0x400
> >> [<ffffffff81096bb4>] worker_thread+0x114/0x470
> >> [<ffffffff8109c6f8>] kthread+0xd8/0xf0
> >> [<ffffffff8172004f>] ret_from_fork+0x3f/0x70
> >> [<ffffffffffffffff>] 0xffffffffffffffff
> >>
> >> We are not able to log out of the sessions in all cases. And have to
> >> restart the box.
> >>
> >> iscsiadm -m session will show messages like:
> >> iscsiadm: could not read session targetname: 5
> >> iscsiadm: could not find session info for session100
> >> iscsiadm: could not read session targetname: 5
> >> iscsiadm: could not find session info for session101
> >> iscsiadm: could not read session targetname: 5
> >> iscsiadm: could not find session info for session103
> >> ...
> >>
> >> I can't find any way to force iscsiadm to clean up these sessions
> >> possibly due to tasks in D state.
> >> ----------------
> >> Robert LeBlanc
> >> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
> >>
> >>
> >> On Mon, Oct 17, 2016 at 10:32 AM, Robert LeBlanc <robert@leblancnet.us>
> >> wrote:
> >>>
> >>> Some more info as we hit this this morning. We have volumes mirrored
> >>> between two targets and we had one target on the kernel with the three
> >>> patches mentioned in this thread [0][1][2] and the other was on a
> >>> kernel without the patches. We decided that after a week and a half we
> >>> wanted to get both targets on the same kernel so we rebooted the
> >>> non-patched target. Within an hour we saw iSCSI in D state with the
> >>> same stack trace so it seems that we are not hitting any of the
> >>> WARN_ON lines. We are getting both iscsi_trx and iscsi_np both in D
> >>> state, this time we have two iscsi_trx processes in D state. I don't
> >>> know if stale sessions on the clients could be contributing to this
> >>> issue (the target trying to close non-existent sessions??). This is on
> >>> 4.4.23. Any more debug info we can throw at this problem to help?
> >>>
> >>> Thank you,
> >>> Robert LeBlanc
> >>>
> >>> # ps aux | grep D | grep iscsi
> >>> root 16525 0.0 0.0 0 0 ? D 08:50 0:00
> >>> [iscsi_np]
> >>> root 16614 0.0 0.0 0 0 ? D 08:50 0:00
> >>> [iscsi_trx]
> >>> root 16674 0.0 0.0 0 0 ? D 08:50 0:00
> >>> [iscsi_trx]
> >>>
> >>> # for i in 16525 16614 16674; do echo $i; cat /proc/$i/stack; done
> >>> 16525
> >>> [<ffffffff814f0d5f>] iscsit_stop_session+0x19f/0x1d0
> >>> [<ffffffff814e2516>] iscsi_check_for_session_reinstatement+0x1e6/0x270
> >>> [<ffffffff814e4ed0>] iscsi_target_check_for_existing_instances+0x30/0x40
> >>> [<ffffffff814e5020>] iscsi_target_do_login+0x140/0x640
> >>> [<ffffffff814e63bc>] iscsi_target_start_negotiation+0x1c/0xb0
> >>> [<ffffffff814e410b>] iscsi_target_login_thread+0xa9b/0xfc0
> >>> [<ffffffff8109c748>] kthread+0xd8/0xf0
> >>> [<ffffffff8172018f>] ret_from_fork+0x3f/0x70
> >>> [<ffffffffffffffff>] 0xffffffffffffffff
> >>> 16614
> >>> [<ffffffff814cca79>] target_wait_for_sess_cmds+0x49/0x1a0
> >>> [<ffffffffa064692b>] isert_wait_conn+0x1ab/0x2f0 [ib_isert]
> >>> [<ffffffff814f0ef2>] iscsit_close_connection+0x162/0x870
> >>> [<ffffffff814df9bf>] iscsit_take_action_for_connection_exit+0x7f/0x100
> >>> [<ffffffff814f00a0>] iscsi_target_rx_thread+0x5a0/0xe80
> >>> [<ffffffff8109c748>] kthread+0xd8/0xf0
> >>> [<ffffffff8172018f>] ret_from_fork+0x3f/0x70
> >>> [<ffffffffffffffff>] 0xffffffffffffffff
> >>> 16674
> >>> [<ffffffff814cca79>] target_wait_for_sess_cmds+0x49/0x1a0
> >>> [<ffffffffa064692b>] isert_wait_conn+0x1ab/0x2f0 [ib_isert]
> >>> [<ffffffff814f0ef2>] iscsit_close_connection+0x162/0x870
> >>> [<ffffffff814df9bf>] iscsit_take_action_for_connection_exit+0x7f/0x100
> >>> [<ffffffff814f00a0>] iscsi_target_rx_thread+0x5a0/0xe80
> >>> [<ffffffff8109c748>] kthread+0xd8/0xf0
> >>> [<ffffffff8172018f>] ret_from_fork+0x3f/0x70
> >>> [<ffffffffffffffff>] 0xffffffffffffffff
> >>>
> >>>
> >>> [0] https://www.spinics.net/lists/target-devel/msg13463.html
> >>> [1] http://marc.info/?l=linux-scsi&m=147282568910535&w=2
> >>> [2] http://www.spinics.net/lists/linux-scsi/msg100221.html
The call chain above is iscsi session reinstatement driven by
open-iscsi/iser resulting in target-core to sleep indefinitely, waiting
for outstanding target-core backend driver se_cmd I/O to complete in
order to make forward progress.
Note, there is a v4.1+ se_cmd->cmd_kref reference leak bug for
TMR ABORT_TASK during simultaneous target back-end I/O completion
timeouts here:
http://www.spinics.net/lists/target-devel/msg13530.html
If you are actively observing TMR ABORT_TASK preceding the hung task
timeout warnings above with v4.4.y + v4.2.y iser-target exports, then
it's likely the same bug. Please apply the patch on your v4.x setup to
verify.
If no TMR ABORT_TASK timeouts + session reinstatements are occurring on
your iser-target setup, then it is a separate bug.
^ permalink raw reply
* Re: iscsi_trx going into D state
From: Nicholas A. Bellinger @ 2016-10-18 7:52 UTC (permalink / raw)
To: Robert LeBlanc; +Cc: Zhu Lingshan, linux-rdma, linux-scsi
In-Reply-To: <1476774332.8490.43.camel@haakon3.risingtidesystems.com>
On Tue, 2016-10-18 at 00:05 -0700, Nicholas A. Bellinger wrote:
> Hello Robert, Zhu & Co,
>
> Thanks for your detailed bug report. Comments inline below.
>
> On Mon, 2016-10-17 at 22:42 -0600, Robert LeBlanc wrote:
> > Sorry I forget that Android has an aversion to plain text emails.
> >
> > If we can provide any information to help, let us know. We are willing
> > to patch in more debug statements or whatever you think might help.
> > Today has been a difficult day. Thanks for looking into it, I tried
> > looking at it, but it is way over my head.
> >
> > ----------------
> > Robert LeBlanc
> > PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
> >
> >
> > On Mon, Oct 17, 2016 at 9:06 PM, Zhu Lingshan <lszhu@suse.com> wrote:
> > > Hi Robert,
> > >
> > > I think the reason why you can not logout the targets is that iscsi_np in D
> > > status. I think the patches fixed something, but it seems to be more than
> > > one code path can trigger these similar issues. as you can see, there are
> > > several call stacks, I am still working on it. Actually in my environment I
> > > see there is another call stack not listed in your mail....
> > >
> > > Thanks,
> > > BR
> > > Zhu Lingshan
> > >
> > >
> > > On 10/18/2016 03:11 AM, Robert LeBlanc wrote:
> > >>
> > >> Sorry hit send too soon.
> > >>
> > >> In addition, on the client we see:
> > >> # ps -aux | grep D | grep kworker
> > >> root 5583 0.0 0.0 0 0 ? D 11:55 0:03
> > >> [kworker/11:0]
> > >> root 7721 0.1 0.0 0 0 ? D 12:00 0:04
> > >> [kworker/4:25]
> > >> root 10877 0.0 0.0 0 0 ? D 09:27 0:00
> > >> [kworker/22:1]
> > >> root 11246 0.0 0.0 0 0 ? D 10:28 0:00
> > >> [kworker/30:2]
> > >> root 14034 0.0 0.0 0 0 ? D 12:20 0:02
> > >> [kworker/19:15]
> > >> root 14048 0.0 0.0 0 0 ? D 12:20 0:00
> > >> [kworker/16:0]
> > >> root 15871 0.0 0.0 0 0 ? D 12:25 0:00
> > >> [kworker/13:0]
> > >> root 17442 0.0 0.0 0 0 ? D 12:28 0:00
> > >> [kworker/9:1]
> > >> root 17816 0.0 0.0 0 0 ? D 12:30 0:00
> > >> [kworker/11:1]
> > >> root 18744 0.0 0.0 0 0 ? D 12:32 0:00
> > >> [kworker/10:2]
> > >> root 19060 0.0 0.0 0 0 ? D 12:32 0:00
> > >> [kworker/29:0]
> > >> root 21748 0.0 0.0 0 0 ? D 12:40 0:00
> > >> [kworker/21:0]
> > >> root 21967 0.0 0.0 0 0 ? D 12:40 0:00
> > >> [kworker/22:0]
> > >> root 21978 0.0 0.0 0 0 ? D 12:40 0:00
> > >> [kworker/22:2]
> > >> root 22024 0.0 0.0 0 0 ? D 12:40 0:00
> > >> [kworker/22:4]
> > >> root 22035 0.0 0.0 0 0 ? D 12:40 0:00
> > >> [kworker/22:5]
> > >> root 22060 0.0 0.0 0 0 ? D 12:40 0:00
> > >> [kworker/16:1]
> > >> root 22282 0.0 0.0 0 0 ? D 12:41 0:00
> > >> [kworker/26:0]
> > >> root 22362 0.0 0.0 0 0 ? D 12:42 0:00
> > >> [kworker/18:9]
> > >> root 22426 0.0 0.0 0 0 ? D 12:42 0:00
> > >> [kworker/16:3]
> > >> root 23298 0.0 0.0 0 0 ? D 12:43 0:00
> > >> [kworker/12:1]
> > >> root 23302 0.0 0.0 0 0 ? D 12:43 0:00
> > >> [kworker/12:5]
> > >> root 24264 0.0 0.0 0 0 ? D 12:46 0:00
> > >> [kworker/30:1]
> > >> root 24271 0.0 0.0 0 0 ? D 12:46 0:00
> > >> [kworker/14:8]
> > >> root 24441 0.0 0.0 0 0 ? D 12:47 0:00
> > >> [kworker/9:7]
> > >> root 24443 0.0 0.0 0 0 ? D 12:47 0:00
> > >> [kworker/9:9]
> > >> root 25005 0.0 0.0 0 0 ? D 12:48 0:00
> > >> [kworker/30:3]
> > >> root 25158 0.0 0.0 0 0 ? D 12:49 0:00
> > >> [kworker/9:12]
> > >> root 26382 0.0 0.0 0 0 ? D 12:52 0:00
> > >> [kworker/13:2]
> > >> root 26453 0.0 0.0 0 0 ? D 12:52 0:00
> > >> [kworker/21:2]
> > >> root 26724 0.0 0.0 0 0 ? D 12:53 0:00
> > >> [kworker/19:1]
> > >> root 28400 0.0 0.0 0 0 ? D 05:20 0:00
> > >> [kworker/25:1]
> > >> root 29552 0.0 0.0 0 0 ? D 11:40 0:00
> > >> [kworker/17:1]
> > >> root 29811 0.0 0.0 0 0 ? D 11:40 0:00
> > >> [kworker/7:10]
> > >> root 31903 0.0 0.0 0 0 ? D 11:43 0:00
> > >> [kworker/26:1]
> > >>
> > >> And all of the processes have this stack:
> > >> [<ffffffffa0727ed5>] iser_release_work+0x25/0x60 [ib_iser]
> > >> [<ffffffff8109633f>] process_one_work+0x14f/0x400
> > >> [<ffffffff81096bb4>] worker_thread+0x114/0x470
> > >> [<ffffffff8109c6f8>] kthread+0xd8/0xf0
> > >> [<ffffffff8172004f>] ret_from_fork+0x3f/0x70
> > >> [<ffffffffffffffff>] 0xffffffffffffffff
> > >>
> > >> We are not able to log out of the sessions in all cases. And have to
> > >> restart the box.
> > >>
> > >> iscsiadm -m session will show messages like:
> > >> iscsiadm: could not read session targetname: 5
> > >> iscsiadm: could not find session info for session100
> > >> iscsiadm: could not read session targetname: 5
> > >> iscsiadm: could not find session info for session101
> > >> iscsiadm: could not read session targetname: 5
> > >> iscsiadm: could not find session info for session103
> > >> ...
> > >>
> > >> I can't find any way to force iscsiadm to clean up these sessions
> > >> possibly due to tasks in D state.
> > >> ----------------
> > >> Robert LeBlanc
> > >> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
> > >>
> > >>
> > >> On Mon, Oct 17, 2016 at 10:32 AM, Robert LeBlanc <robert@leblancnet.us>
> > >> wrote:
> > >>>
> > >>> Some more info as we hit this this morning. We have volumes mirrored
> > >>> between two targets and we had one target on the kernel with the three
> > >>> patches mentioned in this thread [0][1][2] and the other was on a
> > >>> kernel without the patches. We decided that after a week and a half we
> > >>> wanted to get both targets on the same kernel so we rebooted the
> > >>> non-patched target. Within an hour we saw iSCSI in D state with the
> > >>> same stack trace so it seems that we are not hitting any of the
> > >>> WARN_ON lines. We are getting both iscsi_trx and iscsi_np both in D
> > >>> state, this time we have two iscsi_trx processes in D state. I don't
> > >>> know if stale sessions on the clients could be contributing to this
> > >>> issue (the target trying to close non-existent sessions??). This is on
> > >>> 4.4.23. Any more debug info we can throw at this problem to help?
> > >>>
> > >>> Thank you,
> > >>> Robert LeBlanc
> > >>>
> > >>> # ps aux | grep D | grep iscsi
> > >>> root 16525 0.0 0.0 0 0 ? D 08:50 0:00
> > >>> [iscsi_np]
> > >>> root 16614 0.0 0.0 0 0 ? D 08:50 0:00
> > >>> [iscsi_trx]
> > >>> root 16674 0.0 0.0 0 0 ? D 08:50 0:00
> > >>> [iscsi_trx]
> > >>>
> > >>> # for i in 16525 16614 16674; do echo $i; cat /proc/$i/stack; done
> > >>> 16525
> > >>> [<ffffffff814f0d5f>] iscsit_stop_session+0x19f/0x1d0
> > >>> [<ffffffff814e2516>] iscsi_check_for_session_reinstatement+0x1e6/0x270
> > >>> [<ffffffff814e4ed0>] iscsi_target_check_for_existing_instances+0x30/0x40
> > >>> [<ffffffff814e5020>] iscsi_target_do_login+0x140/0x640
> > >>> [<ffffffff814e63bc>] iscsi_target_start_negotiation+0x1c/0xb0
> > >>> [<ffffffff814e410b>] iscsi_target_login_thread+0xa9b/0xfc0
> > >>> [<ffffffff8109c748>] kthread+0xd8/0xf0
> > >>> [<ffffffff8172018f>] ret_from_fork+0x3f/0x70
> > >>> [<ffffffffffffffff>] 0xffffffffffffffff
> > >>> 16614
> > >>> [<ffffffff814cca79>] target_wait_for_sess_cmds+0x49/0x1a0
> > >>> [<ffffffffa064692b>] isert_wait_conn+0x1ab/0x2f0 [ib_isert]
> > >>> [<ffffffff814f0ef2>] iscsit_close_connection+0x162/0x870
> > >>> [<ffffffff814df9bf>] iscsit_take_action_for_connection_exit+0x7f/0x100
> > >>> [<ffffffff814f00a0>] iscsi_target_rx_thread+0x5a0/0xe80
> > >>> [<ffffffff8109c748>] kthread+0xd8/0xf0
> > >>> [<ffffffff8172018f>] ret_from_fork+0x3f/0x70
> > >>> [<ffffffffffffffff>] 0xffffffffffffffff
> > >>> 16674
> > >>> [<ffffffff814cca79>] target_wait_for_sess_cmds+0x49/0x1a0
> > >>> [<ffffffffa064692b>] isert_wait_conn+0x1ab/0x2f0 [ib_isert]
> > >>> [<ffffffff814f0ef2>] iscsit_close_connection+0x162/0x870
> > >>> [<ffffffff814df9bf>] iscsit_take_action_for_connection_exit+0x7f/0x100
> > >>> [<ffffffff814f00a0>] iscsi_target_rx_thread+0x5a0/0xe80
> > >>> [<ffffffff8109c748>] kthread+0xd8/0xf0
> > >>> [<ffffffff8172018f>] ret_from_fork+0x3f/0x70
> > >>> [<ffffffffffffffff>] 0xffffffffffffffff
> > >>>
> > >>>
> > >>> [0] https://www.spinics.net/lists/target-devel/msg13463.html
> > >>> [1] http://marc.info/?l=linux-scsi&m=147282568910535&w=2
> > >>> [2] http://www.spinics.net/lists/linux-scsi/msg100221.html
>
> The call chain above is iscsi session reinstatement driven by
> open-iscsi/iser resulting in target-core to sleep indefinitely, waiting
> for outstanding target-core backend driver se_cmd I/O to complete in
> order to make forward progress.
>
> Note, there is a v4.1+ se_cmd->cmd_kref reference leak bug for
> TMR ABORT_TASK during simultaneous target back-end I/O completion
> timeouts here:
>
> http://www.spinics.net/lists/target-devel/msg13530.html
>
> If you are actively observing TMR ABORT_TASK preceding the hung task
> timeout warnings above with v4.4.y + v4.2.y iser-target exports, then
> it's likely the same bug. Please apply the patch on your v4.x setup to
> verify.
>
> If no TMR ABORT_TASK timeouts + session reinstatements are occurring on
> your iser-target setup, then it is a separate bug.
>
To clarify a bit more..
Using a v4.1.26+ kernel with traditional iscsi-target exports and patch
in place, I can confirm iscsi-target is able to successfully invoke
configfs network portal group delete via syscall:
rmdir /sys/kernel/config/target/iscsi/$IQN/$TPGT/np/$IPv4:$PORT
after TMR ABORT_TASKs due to backend I/O timeout + iscsi session
reinstatement scenario have occurred.
^ permalink raw reply
* Re: RQ overflow seen running isert traffic
From: Sagi Grimberg @ 2016-10-18 8:04 UTC (permalink / raw)
To: Steve Wise, 'Potnuri Bharat Teja'
Cc: target-devel-u79uwXL29TY76Z2rM5mHXA, nab-IzHhD5pYlfBP7FQvKIMDCQ,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <021001d228a4$6cd6a6c0$4683f440$@opengridcomputing.com>
Hey Steve and Baharat,
> Hey Sagi, I'm looking at isert_create_qp() and it appears to not be correctly
> sizing the SQ:
> ...
> #define ISERT_QP_MAX_REQ_DTOS (ISCSI_DEF_XMIT_CMDS_MAX + \
> ISERT_MAX_TX_MISC_PDUS + \
> ISERT_MAX_RX_MISC_PDUS)
> ...
> attr.cap.max_send_wr = ISERT_QP_MAX_REQ_DTOS + 1;
> attr.cap.max_recv_wr = ISERT_QP_MAX_RECV_DTOS + 1;
> ...
>
> I think above snipit assumes a DTO consumes exactly one WR/WQE in the SQ. But
> the DTO can be broken into multiple WRs to handle REG_MRs, multiple WRITE or
> READ WRs due to limits on local sge depths target sge depths, etc. Yes? Or am
> I all wet? Or perhaps isert doesn't require the SQ to be the max possible
> because it flow controls the DTO submissions?
I think you are correct.
On my test devices, I didn't see that multiple WRs has had any effect
becuase:
1. My test devices usually give next power of 2 (256)
2. workloads that involved multiple rdma operations never stressed the
system enough to get the queues full.
Now, in iWARP for non-immediate writes we'll need more than a single
wr per IO (I think the SQ size is expanded with the new rdma RW API
which implicitly increases with attr.cap.max_rdma_ctxs).
But I do agree that we need to take into account that each IO needs
at least 2 WRs (one for rdma and one for send).
So a temp bandage would be:
--
diff --git a/drivers/infiniband/ulp/isert/ib_isert.h
b/drivers/infiniband/ulp/isert/ib_isert.h
index fc791efe3a10..81afb95aeea9 100644
--- a/drivers/infiniband/ulp/isert/ib_isert.h
+++ b/drivers/infiniband/ulp/isert/ib_isert.h
@@ -54,8 +54,14 @@
#define ISERT_MIN_POSTED_RX (ISCSI_DEF_XMIT_CMDS_MAX >> 2)
-#define ISERT_QP_MAX_REQ_DTOS (ISCSI_DEF_XMIT_CMDS_MAX + \
- ISERT_MAX_TX_MISC_PDUS + \
+/*
+ * Max QP send work requests consist of:
+ * - RDMA + SEND for each iscsi IO
+ * - iscsi misc TX pdus
+ * - iscsi misc RX response pdus
+ */
+#define ISERT_QP_MAX_REQ_DTOS ((ISCSI_DEF_XMIT_CMDS_MAX * 2 ) + \
+ ISERT_MAX_TX_MISC_PDUS + \
ISERT_MAX_RX_MISC_PDUS)
#define ISER_RX_PAD_SIZE (ISCSI_DEF_MAX_RECV_SEG_LEN + 4096 - \
--
But we do need to track the SQ overflow and queue a retransmit work when
we don't have enough available SQ slots..
Thoughts?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 03/28] [v2] infiniband: shut up a maybe-uninitialized warning
From: Arnd Bergmann @ 2016-10-18 10:18 UTC (permalink / raw)
To: Haggai Eran
Cc: Doug Ledford, Linus Torvalds, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Sean Hefty, Hal Rosenstock, Matan Barak, Leon Romanovsky,
Sagi Grimberg, Bart Van Assche, Alex Vesker, Guy Shapiro,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <33302790-0a4c-e2b3-868d-3e7dadbd3c07-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
On Tuesday, October 18, 2016 9:47:31 AM CEST Haggai Eran wrote:
> On 10/18/2016 1:05 AM, Arnd Bergmann wrote:
> > @@ -1309,7 +1311,7 @@ static bool validate_net_dev(struct net_device *net_dev,
> > static struct net_device *cma_get_net_dev(struct ib_cm_event *ib_event,
> > const struct cma_req_info *req)
> > {
> > - struct sockaddr_storage listen_addr_storage, src_addr_storage;
> > + struct sockaddr_storage listen_addr_storage = {}, src_addr_storage = {};
>
> Doesn't this still translate to an extra initialization that Doug was
> worried about?
Thanks for spotting this. I must have screwed up while rebasing the patch
at some point, this one change should not be there, the other changes by
themselves sufficiently address the warning.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 03/28] [v2] infiniband: shut up a maybe-uninitialized warning
From: Haggai Eran @ 2016-10-18 10:32 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Doug Ledford, Linus Torvalds, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Sean Hefty, Hal Rosenstock, Matan Barak, Leon Romanovsky,
Sagi Grimberg, Bart Van Assche, Alex Vesker, Guy Shapiro,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <9469876.gij7f9Mh1b@wuerfel>
On 10/18/2016 1:18 PM, Arnd Bergmann wrote:
> On Tuesday, October 18, 2016 9:47:31 AM CEST Haggai Eran wrote:
>> On 10/18/2016 1:05 AM, Arnd Bergmann wrote:
>>> @@ -1309,7 +1311,7 @@ static bool validate_net_dev(struct net_device *net_dev,
>>> static struct net_device *cma_get_net_dev(struct ib_cm_event *ib_event,
>>> const struct cma_req_info *req)
>>> {
>>> - struct sockaddr_storage listen_addr_storage, src_addr_storage;
>>> + struct sockaddr_storage listen_addr_storage = {}, src_addr_storage = {};
>>
>> Doesn't this still translate to an extra initialization that Doug was
>> worried about?
>
> Thanks for spotting this. I must have screwed up while rebasing the patch
> at some point, this one change should not be there, the other changes by
> themselves sufficiently address the warning.
Okay, other than this the patch looks good to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 【For help】 configure crossbar build tool in CMakelist.txt
From: oulijun @ 2016-10-18 10:55 UTC (permalink / raw)
To: linux-rdma; +Cc: Linuxarm
Hi, all
I am working for debugging userspace code of hns in rdma-core.git.
I have met a cmake question now. please give a help for me.
if I use crossbar build tool aarch64-linux-gnu-gcc for building the directory(provider/hns), what i should do it ?
My modification currently according to the others as fllows:
in the file : provider/hns/CMakelist.txt
set(CMAKE_C_COMPILER /opt/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/bin/aarch64-linux-gnu-gcc)
but the modification is fail
-- The C compiler identification is GNU 4.8.4
-- Check for working C compiler using: Ninja
-- Check for working C compiler using: Ninja -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- cmake_share:
-- GNU:
-- BUILD_BIN_DIR:/home/ubuntu/rdma-core/build/bin
-- CMAKE_INSTALL: /usr/local/var/run
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- rdma_build: Debug;Release;RelWithDebInfo;MinSizeRel
-- BUILD_INCLUDE_DIR:/home/ubuntu/rdma-core/build/include
-- Performing Test SUPPORTS_GNU99
-- Performing Test SUPPORTS_GNU99 - Success
-- Performing Test HAVE_C_WARNINGS
-- Performing Test HAVE_C_WARNINGS - Success
-- Performing Test HAVE_C_WMISSING_PROTOTYPES
-- Performing Test HAVE_C_WMISSING_PROTOTYPES - Success
-- Performing Test HAVE_C_WMISSING_DECLARATIONS
-- Performing Test HAVE_C_WMISSING_DECLARATIONS - Success
-- Performing Test HAVE_C_WWRITE_STRINGS
-- Performing Test HAVE_C_WWRITE_STRINGS - Success
-- Performing Test HAVE_C_WFORMAT_2
-- Performing Test HAVE_C_WFORMAT_2 - Success
-- Performing Test HAVE_C_WORKING_SHADOW
-- Performing Test HAVE_C_WORKING_SHADOW - Success
-- Performing Test HAVE_C_WORKING_MISSING_FIELD_INITIALIZERS
-- Performing Test HAVE_C_WORKING_MISSING_FIELD_INITIALIZERS - Failed
-- Performing Test HAVE_C_WNO_MISSING_FIELD_INITIALIZERS
-- Performing Test HAVE_C_WNO_MISSING_FIELD_INITIALIZERS - Success
-- Performing Test HAVE_NO_STRICT_ALIASING
-- Performing Test HAVE_NO_STRICT_ALIASING - Success
-- Performing Test HAS_CLOEXEC
-- Performing Test HAS_CLOEXEC - Success
-- Performing Test HAVE_FUNC_ATTRIBUTE_ALWAYS_INLINE
-- Performing Test HAVE_FUNC_ATTRIBUTE_ALWAYS_INLINE - Success
-- Performing Test SUPPORTS_AS_NEEDED
-- Performing Test SUPPORTS_AS_NEEDED - Success
-- Performing Test SUPPORTS_NO_UNDEFINED
-- Performing Test SUPPORTS_NO_UNDEFINED - Success
-- Performing Test _LDSYMVER_SUCCESS
-- Performing Test _LDSYMVER_SUCCESS - Success
-- Found LDSymVer: GNU
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- checking for modules 'libnl-3.0;libnl-route-3.0'
-- found libnl-3.0, version 3.2.21
-- found libnl-route-3.0, version 3.2.21
-- Performing Test HAVE_WORKING_IF_H
-- Performing Test HAVE_WORKING_IF_H - Failed
-- Check size of long
-- Check size of long - done
-- Looking for rdma/rdma_user_rxe.h
-- Looking for rdma/rdma_user_rxe.h - not found
-- Looking for valgrind/memcheck.h
-- Looking for valgrind/memcheck.h - found
-- Looking for valgrind/drd.h
-- Looking for valgrind/drd.h - found
-- Performing Test LIBC_HAS_LIBRT
-- Performing Test LIBC_HAS_LIBRT - Success
-- Performing Test HAVE_C_WSTRICT_PROTOTYPES
-- Performing Test HAVE_C_WSTRICT_PROTOTYPES - Success
-- Performing Test HAVE_C_WOLD_STYLE_DEFINITION
-- Performing Test HAVE_C_WOLD_STYLE_DEFINITION - Success
-- Performing Test HAVE_C_WREDUNDANT_DECLS
-- Performing Test HAVE_C_WREDUNDANT_DECLS - Failed
-- c_complier: /opt/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/bin/aarch64-linux-gnu-gcc
-- Missing Optional Items:
-- netlink/route/link.h and net/if.h NOT co-includable (old headers)
-- rdma/rdma_user_rxe.h NOT found (old system kernel headers)
-- -Wmissing-field-initializers does NOT work
-- -Wredundant-decls does NOT work
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ubuntu/rdma-core/build
[115/164] Building C object providers/hns/CMakeFiles/hns-rdmav2.dir/hns_roce_u_hw_v1.c.o
FAILED: /usr/bin/cc -Dhns_rdmav2_EXPORTS -std=gnu99 -Wall -Wextra -Wno-sign-compare -Wno-unused-parameter -Wmissing-prototypes -Wmissing-declarations -Wwrite-strings -Wformat=2 -Wshadow -Wno-missing-field-initializers -Wstrict-prototypes -Wold-style-definition -O2 -g -fPIC -Iinclude -I/usr/include/libnl3 -MMD -MT providers/hns/CMakeFiles/hns-rdmav2.dir/hns_roce_u_hw_v1.c.o -MF "providers/hns/CMakeFiles/hns-rdmav2.dir/hns_roce_u_hw_v1.c.o.d" -o providers/hns/CMakeFiles/hns-rdmav2.dir/hns_roce_u_hw_v1.c.o -c ../providers/hns/hns_roce_u_hw_v1.c
../providers/hns/hns_roce_u_hw_v1.c: Assembler messages:
../providers/hns/hns_roce_u_hw_v1.c:830: Error: number of operands mismatch for `ds'
../providers/hns/hns_roce_u_hw_v1.c:264: Error: number of operands mismatch for `ds'
../providers/hns/hns_roce_u_hw_v1.c:413: Error: number of operands mismatch for `ds'
../providers/hns/hns_roce_u_hw_v1.c:586: Error: number of operands mismatch for `ds'
../providers/hns/hns_roce_u_hw_v1.c:630: Error: number of operands mismatch for `ds'
[115/164] Building C object ibacm/CMakeFiles/ibacm.dir/src/acm.c.o
ninja: build stopped: subcommand failed.
.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: SQ overflow seen running isert traffic
From: Potnuri Bharat Teja @ 2016-10-18 11:28 UTC (permalink / raw)
To: Sagi Grimberg; +Cc: Steve Wise, target-devel, nab, linux-rdma
In-Reply-To: <c4ee3313-9e67-f30a-3679-4c9afab79ac9@grimberg.me>
On Tuesday, October 10/18/16, 2016 at 11:04:00 +0300, Sagi Grimberg wrote:
> Hey Steve and Baharat,
>
> >Hey Sagi, I'm looking at isert_create_qp() and it appears to not be correctly
> >sizing the SQ:
> >...
> >#define ISERT_QP_MAX_REQ_DTOS (ISCSI_DEF_XMIT_CMDS_MAX + \
> > ISERT_MAX_TX_MISC_PDUS + \
> > ISERT_MAX_RX_MISC_PDUS)
> >...
> > attr.cap.max_send_wr = ISERT_QP_MAX_REQ_DTOS + 1;
> > attr.cap.max_recv_wr = ISERT_QP_MAX_RECV_DTOS + 1;
> >...
> >
> >I think above snipit assumes a DTO consumes exactly one WR/WQE in the SQ. But
> >the DTO can be broken into multiple WRs to handle REG_MRs, multiple WRITE or
> >READ WRs due to limits on local sge depths target sge depths, etc. Yes? Or am
> >I all wet? Or perhaps isert doesn't require the SQ to be the max possible
> >because it flow controls the DTO submissions?
>
> I think you are correct.
>
> On my test devices, I didn't see that multiple WRs has had any effect
> becuase:
> 1. My test devices usually give next power of 2 (256)
> 2. workloads that involved multiple rdma operations never stressed the
> system enough to get the queues full.
>
> Now, in iWARP for non-immediate writes we'll need more than a single
> wr per IO (I think the SQ size is expanded with the new rdma RW API
> which implicitly increases with attr.cap.max_rdma_ctxs).
Yes, rdma RW api factors the attr.cap.max_rdma_ctxs based on attr Flags.
>
> But I do agree that we need to take into account that each IO needs
> at least 2 WRs (one for rdma and one for send).
>
> So a temp bandage would be:
> --
> diff --git a/drivers/infiniband/ulp/isert/ib_isert.h
> b/drivers/infiniband/ulp/isert/ib_isert.h
> index fc791efe3a10..81afb95aeea9 100644
> --- a/drivers/infiniband/ulp/isert/ib_isert.h
> +++ b/drivers/infiniband/ulp/isert/ib_isert.h
> @@ -54,8 +54,14 @@
>
> #define ISERT_MIN_POSTED_RX (ISCSI_DEF_XMIT_CMDS_MAX >> 2)
>
> -#define ISERT_QP_MAX_REQ_DTOS (ISCSI_DEF_XMIT_CMDS_MAX + \
> - ISERT_MAX_TX_MISC_PDUS + \
> +/*
> + * Max QP send work requests consist of:
> + * - RDMA + SEND for each iscsi IO
> + * - iscsi misc TX pdus
> + * - iscsi misc RX response pdus
> + */
> +#define ISERT_QP_MAX_REQ_DTOS ((ISCSI_DEF_XMIT_CMDS_MAX * 2 ) + \
> + ISERT_MAX_TX_MISC_PDUS + \
> ISERT_MAX_RX_MISC_PDUS)
>
> #define ISER_RX_PAD_SIZE (ISCSI_DEF_MAX_RECV_SEG_LEN + 4096 - \
> --
>
I tried out this change and it works fine with iwarp. I dont see SQ
overflow. Apparently we have increased the sq too big to overflow. I am going
to let it run with higher workloads for longer time, to see if it holds good.
> But we do need to track the SQ overflow and queue a retransmit work when
> we don't have enough available SQ slots..
Agreed, iscsi-target (LIO in our case)expects failure to be returned by
overlying modules Or it could be for tcp as it handling is different to
that of iser.
It queues the WR and schedules it for repost incase
of post failures with ENOMEM/EAGAIN. Shall send the necessary change if
it is needed.
Thanks,
Bharat.
>
> Thoughts?
^ permalink raw reply
* Re: [PATCH 01/10] mm: remove write/force parameters from __get_user_pages_locked()
From: Jan Kara @ 2016-10-18 12:43 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: linux-mips, linux-fbdev, Jan Kara, kvm, linux-sh, Dave Hansen,
dri-devel, linux-mm, netdev, sparclinux, linux-ia64, linux-s390,
linux-samsung-soc, linux-scsi, linux-rdma, x86, Hugh Dickins,
linux-media, Rik van Riel, intel-gfx, adi-buildroot-devel,
ceph-devel, linux-arm-kernel, linux-cris-kernel, Linus Torvalds,
linuxppc-dev, linux-kernel, linux-security-module, linux-alpha
In-Reply-To: <20161013002020.3062-2-lstoakes@gmail.com>
On Thu 13-10-16 01:20:11, Lorenzo Stoakes wrote:
> This patch removes the write and force parameters from __get_user_pages_locked()
> to make the use of FOLL_FORCE explicit in callers as use of this flag can result
> in surprising behaviour (and hence bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Looks good. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 02/10] mm: remove write/force parameters from __get_user_pages_unlocked()
From: Jan Kara @ 2016-10-18 12:46 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: linux-mips, linux-fbdev, Jan Kara, kvm, linux-sh, Dave Hansen,
dri-devel, linux-mm, netdev, sparclinux, linux-ia64, linux-s390,
linux-samsung-soc, linux-scsi, linux-rdma, x86, Hugh Dickins,
linux-media, Rik van Riel, intel-gfx, adi-buildroot-devel,
ceph-devel, linux-arm-kernel, linux-cris-kernel, Linus Torvalds,
linuxppc-dev, linux-kernel, linux-security-module, linux-alpha
In-Reply-To: <20161013002020.3062-3-lstoakes@gmail.com>
On Thu 13-10-16 01:20:12, Lorenzo Stoakes wrote:
> This patch removes the write and force parameters from
> __get_user_pages_unlocked() to make the use of FOLL_FORCE explicit in callers as
> use of this flag can result in surprising behaviour (and hence bugs) within the
> mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
The patch looks good. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ 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