* [PATCH 2/2] IPv6: fix DESYNC_FACTOR
From: Jiri Bohac @ 2016-10-13 16:52 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
Cc: netdev
The IPv6 temporary address generation uses a variable called DESYNC_FACTOR
to prevent hosts updating the addresses at the same time. Quoting RFC 4941:
... The value DESYNC_FACTOR is a random value (different for each
client) that ensures that clients don't synchronize with each other and
generate new addresses at exactly the same time ...
DESYNC_FACTOR is defined as:
DESYNC_FACTOR -- A random value within the range 0 - MAX_DESYNC_FACTOR.
It is computed once at system start (rather than each time it is used)
and must never be greater than (TEMP_VALID_LIFETIME - REGEN_ADVANCE).
First, I believe the RFC has a typo in it and meant to say: "and must
never be greater than (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE)"
The reason is that at various places in the RFC, DESYNC_FACTOR is used in
a calculation like (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR) or
(TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR). It needs to be
smaller than (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE) for the result of
these calculations to be larger than zero. It's never used in a
calculation together with TEMP_VALID_LIFETIME.
I already submitted an errata to the rfc-editor:
https://www.rfc-editor.org/errata_search.php?rfc=4941
The Linux implementation of DESYNC_FACTOR is very wrong:
max_desync_factor is used in places DESYNC_FACTOR should be used.
max_desync_factor is initialized to the RFC-recommended value for
MAX_DESYNC_FACTOR (600) but the whole point is to get a _random_ value.
And nothing ensures that the value used is not greater than
(TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE), which leads to underflows. The
effect can easily be observed when setting the temp_prefered_lft sysctl
e.g. to 60. The preferred lifetime of the temporary addresses will be
bogus.
TEMP_PREFERRED_LIFETIME and REGEN_ADVANCE are not constants and can be
influenced by these three sysctls: regen_max_retry, dad_transmits and
temp_prefered_lft. Thus, the upper bound for desync_factor needs to be
re-calculated each time a new address is generated and if desync_factor is
larger than the new upper bound, a new random value needs to be
re-generated.
And since we already have max_desync_factor configurable per interface, we
also need to calculate and store desync_factor per interface.
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
---
include/net/if_inet6.h | 1 +
net/ipv6/addrconf.c | 39 +++++++++++++++++++++++++++++++--------
2 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/include/net/if_inet6.h b/include/net/if_inet6.h
index ae70735..b0576cb 100644
--- a/include/net/if_inet6.h
+++ b/include/net/if_inet6.h
@@ -190,6 +190,7 @@ struct inet6_dev {
__u32 if_flags;
int dead;
+ u32 desync_factor;
u8 rndid[8];
struct list_head tempaddr_list;
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 63fc857..eca15f3 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -422,6 +422,7 @@ static struct inet6_dev *ipv6_add_dev(struct net_device *dev)
#endif
INIT_LIST_HEAD(&ndev->tempaddr_list);
+ ndev->desync_factor = U32_MAX;
if ((dev->flags&IFF_LOOPBACK) ||
dev->type == ARPHRD_TUNNEL ||
dev->type == ARPHRD_TUNNEL6 ||
@@ -1183,6 +1184,7 @@ static int ipv6_create_tempaddr(struct inet6_ifaddr *ifp, struct inet6_ifaddr *i
int ret = 0;
u32 addr_flags;
unsigned long now = jiffies;
+ long max_desync_factor;
write_lock_bh(&idev->lock);
if (ift) {
@@ -1218,20 +1220,41 @@ static int ipv6_create_tempaddr(struct inet6_ifaddr *ifp, struct inet6_ifaddr *i
ipv6_try_regen_rndid(idev, tmpaddr);
memcpy(&addr.s6_addr[8], idev->rndid, 8);
age = (now - ifp->tstamp) / HZ;
+
+ regen_advance = idev->cnf.regen_max_retry *
+ idev->cnf.dad_transmits *
+ NEIGH_VAR(idev->nd_parms, RETRANS_TIME) / HZ;
+
+ /* recalculate max_desync_factor each time and update
+ * idev->desync_factor if it's larger
+ */
+ max_desync_factor = min_t(__u32,
+ idev->cnf.max_desync_factor,
+ idev->cnf.temp_prefered_lft - regen_advance);
+
+ if (unlikely(idev->desync_factor > max_desync_factor)) {
+ if (max_desync_factor > 0) {
+ get_random_bytes(&idev->desync_factor,
+ sizeof(idev->desync_factor));
+ idev->desync_factor %= max_desync_factor;
+ } else {
+ idev->desync_factor = 0;
+ }
+ }
+
tmp_valid_lft = min_t(__u32,
ifp->valid_lft,
idev->cnf.temp_valid_lft + age);
- tmp_prefered_lft = min_t(__u32,
- ifp->prefered_lft,
- idev->cnf.temp_prefered_lft + age -
- idev->cnf.max_desync_factor);
+ tmp_prefered_lft = idev->cnf.temp_prefered_lft + age -
+ idev->desync_factor;
+ /* guard against underflow in case of concurrent updates to cnf */
+ if (unlikely(tmp_prefered_lft < 0))
+ tmp_prefered_lft = 0;
+ tmp_prefered_lft = min_t(__u32, ifp->prefered_lft, tmp_prefered_lft);
tmp_plen = ifp->prefix_len;
tmp_tstamp = ifp->tstamp;
spin_unlock_bh(&ifp->lock);
- regen_advance = idev->cnf.regen_max_retry *
- idev->cnf.dad_transmits *
- NEIGH_VAR(idev->nd_parms, RETRANS_TIME) / HZ;
write_unlock_bh(&idev->lock);
/* A temporary address is created only if this calculated Preferred
@@ -2316,7 +2339,7 @@ static void manage_tempaddrs(struct inet6_dev *idev,
max_valid = 0;
max_prefered = idev->cnf.temp_prefered_lft -
- idev->cnf.max_desync_factor - age;
+ idev->desync_factor - age;
if (max_prefered < 0)
max_prefered = 0;
--
2.10.0
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ permalink raw reply related
* Re: [PATCH v4 3/3] net: phy: leds: add support for led triggers on phy link state change
From: Andrew Lunn @ 2016-10-13 16:40 UTC (permalink / raw)
To: Zach Brown
Cc: devel, florian.c.schilhabel, f.fainelli, netdev, linux-kernel,
j.anaszewski, rpurdie, gregkh, Larry.Finger, David Miller,
linux-leds, mlindner
In-Reply-To: <20161013154246.GA17387@zach-desktop>
> Do you have suggestions on how to better handle the choice of the array size
> and the speeds?
phydev->supported lists the speeds this phy supports.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: phy: Trigger state machine on state change and not polling.
From: David Miller @ 2016-10-13 16:30 UTC (permalink / raw)
To: andrew; +Cc: netdev, f.fainelli, kyle.roeschley
In-Reply-To: <20161013162901.GA1286@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Thu, 13 Oct 2016 18:29:01 +0200
> Just for my clarification:
>
> We are in the middle of the merge window. What does net-next and net
> mean at the moment?
Once I merge net-next to Linus, bug fixes should go to 'net'.
And for the past day or so I've been slowly merging new features and
cleanups into 'net-next'. I realize that this latter aspect is a
departure from the past, but no matter how hard I try people still
submit net-next things during the merge window so I've basically given
up pushing back on that.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: Trigger state machine on state change and not polling.
From: Andrew Lunn @ 2016-10-13 16:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, f.fainelli, kyle.roeschley
In-Reply-To: <20161013.120438.1184858529653754916.davem@davemloft.net>
> On Thu, Oct 13, 2016 at 12:04:38PM -0400, David Miller wrote:
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Wed, 12 Oct 2016 22:14:53 +0200
>
> > The phy_start() is used to indicate the PHY is now ready to do its
> > work. The state is changed, normally to PHY_UP which means that both
> > the MAC and the PHY are ready.
> >
> > If the phy driver is using polling, when the next poll happens, the
> > state machine notices the PHY is now in PHY_UP, and kicks off
> > auto-negotiation, if needed.
> >
> > If however, the PHY is using interrupts, there is no polling. The phy
> > is stuck in PHY_UP until the next interrupt comes along. And there is
> > no reason for the PHY to interrupt.
> >
> > Have phy_start() schedule the state machine to run, which both speeds
> > up the polling use case, and makes the interrupt use case actually
> > work.
> >
> > This problems exists whenever there is a state change which will not
> > cause an interrupt. Trigger the state machine in these cases,
> > e.g. phy_error().
> >
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > Cc: Kyle Roeschley <kyle.roeschley@ni.com>
> > ---
> >
> > This should be applied to stable, but i've no idea what fixes: tag to
> > use. It could be phylib has been broken since interrupts were added?
>
> Since you think it should go to -stable, it is not appropriate to target
> this patch to 'net-next', only 'net' makes sense.
Hi David
Just for my clarification:
We are in the middle of the merge window. What does net-next and net
mean at the moment?
Outside of the merge window, net is patches being collected to go into
the next -rc. net-next is used to collect patches for the next merge
window.
During the merge window, i've seen you collect patches into net-next
and send additional pull requests to Linus. Which is why i based it on
net-next. I did not check, but i assumed net was still on v4.8.0,
waiting for -rc1 to come out. But this assumption seems untrue. During
the merge window does net equate to what Linus has already pulled from
net-next?
Thanks
Andrew
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2016-10-13 16:27 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix various build warnings in tlan/qed/xen-netback drivers, from Arnd Bergmann.
2) Propagate proper error code in strparser's strp_recv(), from Geert
Uytterhoeven.
3) Fix accidental broadcast of RTM_GETTFILTER responses, from Eric Dumazret.
4) Need to use list_for_each_entry_safe() in qed driver, from Wei
Yongjun.
5) Openvswitch 802.1AD bug fixes from Jiri Benc.
6) Cure BUILD_BUG_ON() in mlx5 driver, from Tom Herbert.
7) Fix UDP ipv6 checksumming in netvsc driver, from Stephen Hemminger.
8) stmmac driver fixes from Giuseppe CAVALLARO.
9) Fix access to mangled IP6CB in tcp, from Eric Dumazet.
10) Fix info leaks in tipc and rtnetlink, from Dan Carpenter.
Please pull, thanks a lot!
The following changes since commit 6b25e21fa6f26d0f0d45f161d169029411c84286:
Merge tag 'drm-for-v4.9' of git://people.freedesktop.org/~airlied/linux (2016-10-11 18:12:22 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 4eb6753c3324873752f56543e149956e39dd32b6:
net: bridge: add the multicast_flood flag attribute to brport_attrs (2016-10-13 12:16:36 -0400)
----------------------------------------------------------------
Andrew Lunn (1):
net: phy: Trigger state machine on state change and not polling.
Arnd Bergmann (3):
tlan: avoid unused label with PCI=n
qed: fix old-style function definition
xen-netback: fix type mismatch warning
Bjørn Mork (1):
qmi_wwan: add support for Quectel EC21 and EC25
Dan Carpenter (3):
tipc: info leak in __tipc_nl_add_udp_addr()
net: rtnl: info leak in rtnl_fill_vfinfo()
liquidio: CN23XX: fix a loop timeout
David Ahern (1):
net: ipv4: Do not drop to make_route if oif is l3mdev
David S. Miller (2):
Merge branch 'ovs-8021AD-fixes'
netvsc: Remove mistaken udp.h inclusion.
David Vrabel (1):
xen-netback: fix guest Rx stall detection (after guest Rx refactor)
Eric Dumazet (2):
net_sched: do not broadcast RTM_GETTFILTER result
ipv6: tcp: restore IP6CB for pktoptions skbs
Geert Uytterhoeven (1):
strparser: Propagate correct error code in strp_recv()
Giuseppe CAVALLARO (2):
stmmac: fix ptp init for gmac4
stmmac: fix error check when init ptp
Jiri Benc (3):
openvswitch: vlan: remove wrong likely statement
openvswitch: fix vlan subtraction from packet length
openvswitch: add NETIF_F_HW_VLAN_STAG_TX to internal dev
Nikolay Aleksandrov (1):
net: bridge: add the multicast_flood flag attribute to brport_attrs
Paul Durrant (1):
xen-netback: (re-)create a debugfs node for hash information
Tobias Klauser (1):
net: axienet: Remove unused parameter from __axienet_device_reset
Tom Herbert (1):
net/mlx5: Add MLX5_ARRAY_SET64 to fix BUILD_BUG_ON
Vlad Tsyrklevich (1):
drivers/ptp: Fix kernel memory disclosure
WANG Cong (1):
net_sched: reorder pernet ops and act ops registrations
Wei Yongjun (1):
qed: Fix to use list_for_each_entry_safe() when delete items
stephen hemminger (1):
netvsc: fix checksum on UDP IPV6
drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c | 4 ++--
drivers/net/ethernet/qlogic/qed/qed_ll2.c | 4 ++--
drivers/net/ethernet/qlogic/qed/qed_roce.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 21 ++++++++++++++-------
drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c | 10 ++++++----
drivers/net/ethernet/ti/tlan.c | 2 +-
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 11 +++++------
drivers/net/hyperv/netvsc_drv.c | 71 +++++++++++++++++++++--------------------------------------------------
drivers/net/phy/phy.c | 22 ++++++++++++++++++++--
drivers/net/usb/qmi_wwan.c | 30 ++++++++++++++++++++++++++++--
drivers/net/xen-netback/common.h | 4 ++++
drivers/net/xen-netback/hash.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/net/xen-netback/rx.c | 8 +++++---
drivers/net/xen-netback/xenbus.c | 37 +++++++++++++++++++++++++++++++++++--
drivers/ptp/ptp_chardev.c | 1 +
include/linux/mlx5/device.h | 13 +++++++++++--
include/net/l3mdev.h | 24 ++++++++++++++++++++++++
net/bridge/br_sysfs_if.c | 1 +
net/core/rtnetlink.c | 2 ++
net/ipv4/route.c | 3 ++-
net/ipv6/tcp_ipv6.c | 20 +++++++++++---------
net/openvswitch/flow.c | 2 +-
net/openvswitch/vport-internal_dev.c | 2 +-
net/openvswitch/vport.c | 3 ++-
net/sched/act_api.c | 19 +++++++++++--------
net/sched/cls_api.c | 18 +++++++++++-------
net/strparser/strparser.c | 2 +-
net/tipc/udp_media.c | 2 ++
29 files changed, 294 insertions(+), 114 deletions(-)
^ permalink raw reply
* [PATCH v3] IB/ipoib: move back IB LL address into the hard header
From: Paolo Abeni @ 2016-10-13 16:26 UTC (permalink / raw)
To: linux-rdma
Cc: Doug Ledford, Sean Hefty, Hal Rosenstock, Jason Gunthorpe, netdev,
David Miller
After the commit 9207f9d45b0a ("net: preserve IP control block
during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
That destroy the IPoIB address information cached there,
causing a severe performance regression, as better described here:
http://marc.info/?l=linux-kernel&m=146787279825501&w=2
This change moves the data cached by the IPoIB driver from the
skb control lock into the IPoIB hard header, as done before
the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
and use skb->cb to stash LL addresses").
In order to avoid GRO issue, on packet reception, the IPoIB driver
stash into the skb a dummy pseudo header, so that the received
packets have actually a hard header matching the declared length.
To avoid changing the connected mode maximum mtu, the allocated
head buffer size is increased by the pseudo header length.
After this commit, IPoIB performances are back to pre-regression
value.
v2 -> v3: rebased
v1 -> v2: avoid changing the max mtu, increasing the head buf size
Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
drivers/infiniband/ulp/ipoib/ipoib.h | 20 +++++++---
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 15 +++----
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 12 +++---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 54 ++++++++++++++++----------
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 6 ++-
5 files changed, 64 insertions(+), 43 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h b/drivers/infiniband/ulp/ipoib/ipoib.h
index 7b8d2d9..da12717 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -63,6 +63,8 @@ enum ipoib_flush_level {
enum {
IPOIB_ENCAP_LEN = 4,
+ IPOIB_PSEUDO_LEN = 20,
+ IPOIB_HARD_LEN = IPOIB_ENCAP_LEN + IPOIB_PSEUDO_LEN,
IPOIB_UD_HEAD_SIZE = IB_GRH_BYTES + IPOIB_ENCAP_LEN,
IPOIB_UD_RX_SG = 2, /* max buffer needed for 4K mtu */
@@ -134,15 +136,21 @@ struct ipoib_header {
u16 reserved;
};
-struct ipoib_cb {
- struct qdisc_skb_cb qdisc_cb;
- u8 hwaddr[INFINIBAND_ALEN];
+struct ipoib_pseudo_header {
+ u8 hwaddr[INFINIBAND_ALEN];
};
-static inline struct ipoib_cb *ipoib_skb_cb(const struct sk_buff *skb)
+static inline void skb_add_pseudo_hdr(struct sk_buff *skb)
{
- BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct ipoib_cb));
- return (struct ipoib_cb *)skb->cb;
+ char *data = skb_push(skb, IPOIB_PSEUDO_LEN);
+
+ /*
+ * only the ipoib header is present now, make room for a dummy
+ * pseudo header and set skb field accordingly
+ */
+ memset(data, 0, IPOIB_PSEUDO_LEN);
+ skb_reset_mac_header(skb);
+ skb_pull(skb, IPOIB_HARD_LEN);
}
/* Used for all multicast joins (broadcast, IPv4 mcast and IPv6 mcast) */
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 4ad297d..339a1ee 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -63,6 +63,8 @@
#define IPOIB_CM_RX_DELAY (3 * 256 * HZ)
#define IPOIB_CM_RX_UPDATE_MASK (0x3)
+#define IPOIB_CM_RX_RESERVE (ALIGN(IPOIB_HARD_LEN, 16) - IPOIB_ENCAP_LEN)
+
static struct ib_qp_attr ipoib_cm_err_attr = {
.qp_state = IB_QPS_ERR
};
@@ -146,15 +148,15 @@ static struct sk_buff *ipoib_cm_alloc_rx_skb(struct net_device *dev,
struct sk_buff *skb;
int i;
- skb = dev_alloc_skb(IPOIB_CM_HEAD_SIZE + 12);
+ skb = dev_alloc_skb(ALIGN(IPOIB_CM_HEAD_SIZE + IPOIB_PSEUDO_LEN, 16));
if (unlikely(!skb))
return NULL;
/*
- * IPoIB adds a 4 byte header. So we need 12 more bytes to align the
+ * IPoIB adds a IPOIB_ENCAP_LEN byte header, this will align the
* IP header to a multiple of 16.
*/
- skb_reserve(skb, 12);
+ skb_reserve(skb, IPOIB_CM_RX_RESERVE);
mapping[0] = ib_dma_map_single(priv->ca, skb->data, IPOIB_CM_HEAD_SIZE,
DMA_FROM_DEVICE);
@@ -624,9 +626,9 @@ void ipoib_cm_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
if (wc->byte_len < IPOIB_CM_COPYBREAK) {
int dlen = wc->byte_len;
- small_skb = dev_alloc_skb(dlen + 12);
+ small_skb = dev_alloc_skb(dlen + IPOIB_CM_RX_RESERVE);
if (small_skb) {
- skb_reserve(small_skb, 12);
+ skb_reserve(small_skb, IPOIB_CM_RX_RESERVE);
ib_dma_sync_single_for_cpu(priv->ca, rx_ring[wr_id].mapping[0],
dlen, DMA_FROM_DEVICE);
skb_copy_from_linear_data(skb, small_skb->data, dlen);
@@ -663,8 +665,7 @@ void ipoib_cm_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
copied:
skb->protocol = ((struct ipoib_header *) skb->data)->proto;
- skb_reset_mac_header(skb);
- skb_pull(skb, IPOIB_ENCAP_LEN);
+ skb_add_pseudo_hdr(skb);
++dev->stats.rx_packets;
dev->stats.rx_bytes += skb->len;
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ib.c b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
index be11d5d..830fecb 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
@@ -128,16 +128,15 @@ static struct sk_buff *ipoib_alloc_rx_skb(struct net_device *dev, int id)
buf_size = IPOIB_UD_BUF_SIZE(priv->max_ib_mtu);
- skb = dev_alloc_skb(buf_size + IPOIB_ENCAP_LEN);
+ skb = dev_alloc_skb(buf_size + IPOIB_HARD_LEN);
if (unlikely(!skb))
return NULL;
/*
- * IB will leave a 40 byte gap for a GRH and IPoIB adds a 4 byte
- * header. So we need 4 more bytes to get to 48 and align the
- * IP header to a multiple of 16.
+ * the IP header will be at IPOIP_HARD_LEN + IB_GRH_BYTES, that is
+ * 64 bytes aligned
*/
- skb_reserve(skb, 4);
+ skb_reserve(skb, sizeof(struct ipoib_pseudo_header));
mapping = priv->rx_ring[id].mapping;
mapping[0] = ib_dma_map_single(priv->ca, skb->data, buf_size,
@@ -253,8 +252,7 @@ static void ipoib_ib_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
skb_pull(skb, IB_GRH_BYTES);
skb->protocol = ((struct ipoib_header *) skb->data)->proto;
- skb_reset_mac_header(skb);
- skb_pull(skb, IPOIB_ENCAP_LEN);
+ skb_add_pseudo_hdr(skb);
++dev->stats.rx_packets;
dev->stats.rx_bytes += skb->len;
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 5636fc3..b58d9dc 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -925,9 +925,12 @@ static void neigh_add_path(struct sk_buff *skb, u8 *daddr,
ipoib_neigh_free(neigh);
goto err_drop;
}
- if (skb_queue_len(&neigh->queue) < IPOIB_MAX_PATH_REC_QUEUE)
+ if (skb_queue_len(&neigh->queue) <
+ IPOIB_MAX_PATH_REC_QUEUE) {
+ /* put pseudoheader back on for next time */
+ skb_push(skb, IPOIB_PSEUDO_LEN);
__skb_queue_tail(&neigh->queue, skb);
- else {
+ } else {
ipoib_warn(priv, "queue length limit %d. Packet drop.\n",
skb_queue_len(&neigh->queue));
goto err_drop;
@@ -964,7 +967,7 @@ static void neigh_add_path(struct sk_buff *skb, u8 *daddr,
}
static void unicast_arp_send(struct sk_buff *skb, struct net_device *dev,
- struct ipoib_cb *cb)
+ struct ipoib_pseudo_header *phdr)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ipoib_path *path;
@@ -972,16 +975,18 @@ static void unicast_arp_send(struct sk_buff *skb, struct net_device *dev,
spin_lock_irqsave(&priv->lock, flags);
- path = __path_find(dev, cb->hwaddr + 4);
+ path = __path_find(dev, phdr->hwaddr + 4);
if (!path || !path->valid) {
int new_path = 0;
if (!path) {
- path = path_rec_create(dev, cb->hwaddr + 4);
+ path = path_rec_create(dev, phdr->hwaddr + 4);
new_path = 1;
}
if (path) {
if (skb_queue_len(&path->queue) < IPOIB_MAX_PATH_REC_QUEUE) {
+ /* put pseudoheader back on for next time */
+ skb_push(skb, IPOIB_PSEUDO_LEN);
__skb_queue_tail(&path->queue, skb);
} else {
++dev->stats.tx_dropped;
@@ -1009,10 +1014,12 @@ static void unicast_arp_send(struct sk_buff *skb, struct net_device *dev,
be16_to_cpu(path->pathrec.dlid));
spin_unlock_irqrestore(&priv->lock, flags);
- ipoib_send(dev, skb, path->ah, IPOIB_QPN(cb->hwaddr));
+ ipoib_send(dev, skb, path->ah, IPOIB_QPN(phdr->hwaddr));
return;
} else if ((path->query || !path_rec_start(dev, path)) &&
skb_queue_len(&path->queue) < IPOIB_MAX_PATH_REC_QUEUE) {
+ /* put pseudoheader back on for next time */
+ skb_push(skb, IPOIB_PSEUDO_LEN);
__skb_queue_tail(&path->queue, skb);
} else {
++dev->stats.tx_dropped;
@@ -1026,13 +1033,15 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ipoib_neigh *neigh;
- struct ipoib_cb *cb = ipoib_skb_cb(skb);
+ struct ipoib_pseudo_header *phdr;
struct ipoib_header *header;
unsigned long flags;
+ phdr = (struct ipoib_pseudo_header *) skb->data;
+ skb_pull(skb, sizeof(*phdr));
header = (struct ipoib_header *) skb->data;
- if (unlikely(cb->hwaddr[4] == 0xff)) {
+ if (unlikely(phdr->hwaddr[4] == 0xff)) {
/* multicast, arrange "if" according to probability */
if ((header->proto != htons(ETH_P_IP)) &&
(header->proto != htons(ETH_P_IPV6)) &&
@@ -1045,13 +1054,13 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
return NETDEV_TX_OK;
}
/* Add in the P_Key for multicast*/
- cb->hwaddr[8] = (priv->pkey >> 8) & 0xff;
- cb->hwaddr[9] = priv->pkey & 0xff;
+ phdr->hwaddr[8] = (priv->pkey >> 8) & 0xff;
+ phdr->hwaddr[9] = priv->pkey & 0xff;
- neigh = ipoib_neigh_get(dev, cb->hwaddr);
+ neigh = ipoib_neigh_get(dev, phdr->hwaddr);
if (likely(neigh))
goto send_using_neigh;
- ipoib_mcast_send(dev, cb->hwaddr, skb);
+ ipoib_mcast_send(dev, phdr->hwaddr, skb);
return NETDEV_TX_OK;
}
@@ -1060,16 +1069,16 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
case htons(ETH_P_IP):
case htons(ETH_P_IPV6):
case htons(ETH_P_TIPC):
- neigh = ipoib_neigh_get(dev, cb->hwaddr);
+ neigh = ipoib_neigh_get(dev, phdr->hwaddr);
if (unlikely(!neigh)) {
- neigh_add_path(skb, cb->hwaddr, dev);
+ neigh_add_path(skb, phdr->hwaddr, dev);
return NETDEV_TX_OK;
}
break;
case htons(ETH_P_ARP):
case htons(ETH_P_RARP):
/* for unicast ARP and RARP should always perform path find */
- unicast_arp_send(skb, dev, cb);
+ unicast_arp_send(skb, dev, phdr);
return NETDEV_TX_OK;
default:
/* ethertype not supported by IPoIB */
@@ -1086,11 +1095,13 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
goto unref;
}
} else if (neigh->ah) {
- ipoib_send(dev, skb, neigh->ah, IPOIB_QPN(cb->hwaddr));
+ ipoib_send(dev, skb, neigh->ah, IPOIB_QPN(phdr->hwaddr));
goto unref;
}
if (skb_queue_len(&neigh->queue) < IPOIB_MAX_PATH_REC_QUEUE) {
+ /* put pseudoheader back on for next time */
+ skb_push(skb, sizeof(*phdr));
spin_lock_irqsave(&priv->lock, flags);
__skb_queue_tail(&neigh->queue, skb);
spin_unlock_irqrestore(&priv->lock, flags);
@@ -1122,8 +1133,8 @@ static int ipoib_hard_header(struct sk_buff *skb,
unsigned short type,
const void *daddr, const void *saddr, unsigned len)
{
+ struct ipoib_pseudo_header *phdr;
struct ipoib_header *header;
- struct ipoib_cb *cb = ipoib_skb_cb(skb);
header = (struct ipoib_header *) skb_push(skb, sizeof *header);
@@ -1132,12 +1143,13 @@ static int ipoib_hard_header(struct sk_buff *skb,
/*
* we don't rely on dst_entry structure, always stuff the
- * destination address into skb->cb so we can figure out where
+ * destination address into skb hard header so we can figure out where
* to send the packet later.
*/
- memcpy(cb->hwaddr, daddr, INFINIBAND_ALEN);
+ phdr = (struct ipoib_pseudo_header *) skb_push(skb, sizeof(*phdr));
+ memcpy(phdr->hwaddr, daddr, INFINIBAND_ALEN);
- return sizeof *header;
+ return IPOIB_HARD_LEN;
}
static void ipoib_set_mcast_list(struct net_device *dev)
@@ -1759,7 +1771,7 @@ void ipoib_setup(struct net_device *dev)
dev->flags |= IFF_BROADCAST | IFF_MULTICAST;
- dev->hard_header_len = IPOIB_ENCAP_LEN;
+ dev->hard_header_len = IPOIB_HARD_LEN;
dev->addr_len = INFINIBAND_ALEN;
dev->type = ARPHRD_INFINIBAND;
dev->tx_queue_len = ipoib_sendq_size * 2;
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index d3394b6..1909dd2 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -796,9 +796,11 @@ void ipoib_mcast_send(struct net_device *dev, u8 *daddr, struct sk_buff *skb)
__ipoib_mcast_add(dev, mcast);
list_add_tail(&mcast->list, &priv->multicast_list);
}
- if (skb_queue_len(&mcast->pkt_queue) < IPOIB_MAX_MCAST_QUEUE)
+ if (skb_queue_len(&mcast->pkt_queue) < IPOIB_MAX_MCAST_QUEUE) {
+ /* put pseudoheader back on for next time */
+ skb_push(skb, sizeof(struct ipoib_pseudo_header));
skb_queue_tail(&mcast->pkt_queue, skb);
- else {
+ } else {
++dev->stats.tx_dropped;
dev_kfree_skb_any(skb);
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] net: axienet: Remove unused parameter from __axienet_device_reset
From: David Miller @ 2016-10-13 16:15 UTC (permalink / raw)
To: tklauser; +Cc: anirudh, John.Linn, michal.simek, soren.brinkmann, netdev
In-Reply-To: <20161013112833.7581-1-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Thu, 13 Oct 2016 13:28:33 +0200
> The dev parameter passed to __axienet_device_reset() is not used inside
> the function, so remove it.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* [PATCH net 1/4] afs: unmapping the wrong buffer
From: David Howells @ 2016-10-13 16:12 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, dan.carpenter, linux-kernel
In-Reply-To: <147637512988.17348.9857198849984467857.stgit@warthog.procyon.org.uk>
From: Dan Carpenter <dan.carpenter@oracle.com>
We switched from kmap_atomic() to kmap() so the kunmap() calls need to
be updated to match.
Fixes: d001648ec7cf ('rxrpc: Don't expose skbs to in-kernel users [ver #2]')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David Howells <dhowells@redhat.com>
---
fs/afs/fsclient.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/afs/fsclient.c b/fs/afs/fsclient.c
index 96f4d764d1a6..31c616ab9b40 100644
--- a/fs/afs/fsclient.c
+++ b/fs/afs/fsclient.c
@@ -364,7 +364,7 @@ static int afs_deliver_fs_fetch_data(struct afs_call *call)
buffer = kmap(page);
ret = afs_extract_data(call, buffer,
call->count, true);
- kunmap(buffer);
+ kunmap(page);
if (ret < 0)
return ret;
}
@@ -397,7 +397,7 @@ static int afs_deliver_fs_fetch_data(struct afs_call *call)
page = call->reply3;
buffer = kmap(page);
memset(buffer + call->count, 0, PAGE_SIZE - call->count);
- kunmap(buffer);
+ kunmap(page);
}
_leave(" = 0 [done]");
^ permalink raw reply related
* [PATCH net 2/4] rxrpc: Fix checker warning by not passing always-zero value to ERR_PTR()
From: David Howells @ 2016-10-13 16:12 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, dan.carpenter, linux-kernel
In-Reply-To: <147637512988.17348.9857198849984467857.stgit@warthog.procyon.org.uk>
Fix the following checker warning:
net/rxrpc/call_object.c:279 rxrpc_new_client_call()
warn: passing zero to 'ERR_PTR'
where a value that's always zero is passed to ERR_PTR() so that it can be
passed to a tracepoint in an auxiliary pointer field.
Just pass NULL instead to the tracepoint.
Fixes: a84a46d73050 ("rxrpc: Add some additional call tracing")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David Howells <dhowells@redhat.com>
---
net/rxrpc/call_object.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
index 4353a29f3b57..1ed18d8c9c9f 100644
--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -276,7 +276,7 @@ struct rxrpc_call *rxrpc_new_client_call(struct rxrpc_sock *rx,
goto error;
trace_rxrpc_call(call, rxrpc_call_connected, atomic_read(&call->usage),
- here, ERR_PTR(ret));
+ here, NULL);
spin_lock_bh(&call->conn->params.peer->lock);
hlist_add_head(&call->error_link,
^ permalink raw reply related
* Re: Kernel 4.6.7-rt13: Intel Ethernet driver igb causes huge latencies in cyclictest
From: Julia Cartwright @ 2016-10-13 16:18 UTC (permalink / raw)
To: Koehrer Mathias (ETAS/ESW5)
Cc: Williams, Mitch A, Kirsher, Jeffrey T,
linux-rt-users@vger.kernel.org, Sebastian Andrzej Siewior,
netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org, Greg
In-Reply-To: <b77ea8ab312149d2b20a717d3ab0a8dc@FE-MBX1012.de.bosch.com>
Hey Mathias-
On Thu, Oct 13, 2016 at 10:57:18AM +0000, Koehrer Mathias (ETAS/ESW5) wrote:
[..]
Interesting indeed!
> > Here are some places where I added traces:
> > In file igb_ptp.c:
> > void igb_ptp_rx_hang(struct igb_adapter *adapter) {
> > struct e1000_hw *hw = &adapter->hw;
> > unsigned long rx_event;
> > u32 tsyncrxctl;
> > trace_igb(700);
> > tsyncrxctl = rd32(E1000_TSYNCRXCTL);
> > trace_igb(701);
> >
> > /* Other hardware uses per-packet timestamps */
> > if (hw->mac.type != e1000_82576)
> > return;
> > ...
> >
> > In file igb_main.c:
> > static void igb_check_lvmmc(struct igb_adapter *adapter) {
> > struct e1000_hw *hw = &adapter->hw;
> > u32 lvmmc;
> >
> > trace_igb(600);
> > lvmmc = rd32(E1000_LVMMC);
> > trace_igb(601);
> > if (lvmmc) {
> > ...
> >
[..]
> > The time between my trace points 700 and 701 is about 30us, the time between my
> > trace points 600 and 601 is even 37us!!
> >
> > The code in between is
> > tsyncrxctl = rd32(E1000_TSYNCRXCTL); resp.
> > lvmmc = rd32(E1000_LVMMC);
> >
> > In both cases this is a single read from a register.
> >
> > I have no idea why this single read could take that much time!
Are these the only registers you see this amount of delay when reading?
It's also possible that it's not these registers themselves that cause
problems, but any writes prior to these reads. That is, given to PCI's
posted write behavior, it could be that these reads are delayed only
because it's flushing previously writes to the device.
> > Is it possible that the igb hardware is in a state that delays the read access and this is
> > why the whole I/O system might be delayed?
One additional hypothesis is that some register accesses trigger
accesses to off-chip resources synchronously; for example, a write to
enable timestamping needs to access an external phy on a slower bus,
etc. I don't know enough about this device to say whether or not that
happens or not.
> To have a proper comparison, I did the same with kernel 3.18.27-rt27.
> Also here, I instrumented the igb driver to get traces for the rd32 calls.
> However, here everything is generally much faster!
> In the idle system the maximum I got for a read was about 6us, most times it was 1-2us.
> On the 4.8 kernel this is always much slower (see above).
> My question is now: Is there any kernel config option that has been introduced in the meantime
> that may lead to this effect and which is not set in my 4.8 config?
Have you tested on a vanilla (non-RT) kernel? I doubt there is anything
RT specific about what you are seeing, but it might be nice to get
confirmation. Also, bisection would probably be easier if you confirm
on a vanilla kernel.
I find it unlikely that it's a kernel config option that changed which
regressed you, but instead was a code change to a driver. Which driver
is now the question, and the surface area is still big (processor
mapping attributes for this region, PCI root complex configuration, PCI
brige configuration, igb driver itself, etc.).
Big enough that I'd recommend a bisection. It looks like a bisection
between 3.18 and 4.8 would take you about 18 tries to narrow down,
assuming all goes well.
Julia
^ permalink raw reply
* Re: [PATCH net] net: bridge: add the multicast_flood flag attribute to brport_attrs
From: David Miller @ 2016-10-13 16:17 UTC (permalink / raw)
To: nikolay; +Cc: netdev, stephen, roopa
In-Reply-To: <1476364852-25777-1-git-send-email-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Thu, 13 Oct 2016 15:20:52 +0200
> When I added the multicast flood control flag, I also added an attribute
> for it for sysfs similar to other flags, but I forgot to add it to
> brport_attrs.
>
> Fixes: b6cb5ac8331b ("net: bridge: add per-port multicast flood flag")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Applied, thanks.
^ permalink raw reply
* [PATCH net-next 0/4] rxrpc: Fixes
From: David Howells @ 2016-10-13 16:12 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, dan.carpenter, linux-kernel
This set of patches contains a bunch of fixes:
(1) Fix use of kunmap() after change from kunmap_atomic() within AFS.
(2) Don't use of ERR_PTR() with an always zero value.
(3) Check the right error when using ip6_route_output().
(4) Be consistent about whether call->operation_ID is BE or CPU-E within
AFS.
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rewrite
Tagged thusly:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
rxrpc-rewrite-20161013
David
---
Dan Carpenter (1):
afs: unmapping the wrong buffer
David Howells (3):
rxrpc: Fix checker warning by not passing always-zero value to ERR_PTR()
rxrpc: Fix checking of error from ip6_route_output()
afs: call->operation_ID sometimes used as __be32 sometimes as u32
fs/afs/cmservice.c | 6 ++----
fs/afs/fsclient.c | 4 ++--
fs/afs/internal.h | 2 +-
fs/afs/rxrpc.c | 3 ++-
net/rxrpc/call_object.c | 2 +-
net/rxrpc/peer_object.c | 4 ++--
6 files changed, 10 insertions(+), 11 deletions(-)
^ permalink raw reply
* Re: [patch] liquidio: CN23XX: fix a loop timeout
From: David Miller @ 2016-10-13 16:13 UTC (permalink / raw)
To: dan.carpenter
Cc: derek.chickles, raghu.vatsavayi, satananda.burla, felix.manlunas,
netdev, kernel-janitors
In-Reply-To: <20161013085657.GL16198@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 13 Oct 2016 11:56:57 +0300
> This is supposed to loop 1000 times and then give up. The problem is
> it's a post-op and after the loop we test if "loop" is zero when really
> it would be -1. Fix this by making it a pre-op.
>
> Fixes: 1b7c55c4538b ("liquidio: CN23XX queue manipulation")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
^ permalink raw reply
* [PATCH net 4/4] afs: call->operation_ID sometimes used as __be32 sometimes as u32
From: David Howells @ 2016-10-13 16:12 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, dan.carpenter, linux-kernel
In-Reply-To: <147637512988.17348.9857198849984467857.stgit@warthog.procyon.org.uk>
call->operation_ID is sometimes being used as __be32 sometimes is being
used as u32. Be consistent and settle on using as u32.
Signed-off-by: David Howells <dhowells@redhat.com.
---
fs/afs/cmservice.c | 6 ++----
fs/afs/internal.h | 2 +-
fs/afs/rxrpc.c | 3 ++-
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/fs/afs/cmservice.c b/fs/afs/cmservice.c
index 2037e7a77a37..d764236072b1 100644
--- a/fs/afs/cmservice.c
+++ b/fs/afs/cmservice.c
@@ -91,11 +91,9 @@ static const struct afs_call_type afs_SRXCBTellMeAboutYourself = {
*/
bool afs_cm_incoming_call(struct afs_call *call)
{
- u32 operation_id = ntohl(call->operation_ID);
+ _enter("{CB.OP %u}", call->operation_ID);
- _enter("{CB.OP %u}", operation_id);
-
- switch (operation_id) {
+ switch (call->operation_ID) {
case CBCallBack:
call->type = &afs_SRXCBCallBack;
return true;
diff --git a/fs/afs/internal.h b/fs/afs/internal.h
index 5497c8496055..535a38d2c1d0 100644
--- a/fs/afs/internal.h
+++ b/fs/afs/internal.h
@@ -112,7 +112,7 @@ struct afs_call {
bool need_attention; /* T if RxRPC poked us */
u16 service_id; /* RxRPC service ID to call */
__be16 port; /* target UDP port */
- __be32 operation_ID; /* operation ID for an incoming call */
+ u32 operation_ID; /* operation ID for an incoming call */
u32 count; /* count for use in unmarshalling */
__be32 tmp; /* place to extract temporary data */
afs_dataversion_t store_version; /* updated version expected from store */
diff --git a/fs/afs/rxrpc.c b/fs/afs/rxrpc.c
index 477928b25940..25f05a8d21b1 100644
--- a/fs/afs/rxrpc.c
+++ b/fs/afs/rxrpc.c
@@ -676,10 +676,11 @@ static int afs_deliver_cm_op_id(struct afs_call *call)
ASSERTCMP(call->offset, <, 4);
/* the operation ID forms the first four bytes of the request data */
- ret = afs_extract_data(call, &call->operation_ID, 4, true);
+ ret = afs_extract_data(call, &call->tmp, 4, true);
if (ret < 0)
return ret;
+ call->operation_ID = ntohl(call->tmp);
call->state = AFS_CALL_AWAIT_REQUEST;
call->offset = 0;
^ permalink raw reply related
* [PATCH net 3/4] rxrpc: Fix checking of error from ip6_route_output()
From: David Howells @ 2016-10-13 16:12 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, dan.carpenter, linux-kernel
In-Reply-To: <147637512988.17348.9857198849984467857.stgit@warthog.procyon.org.uk>
ip6_route_output() doesn't return a negative error when it fails, rather
the ->error field of the returned dst_entry struct needs to be checked.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 75b54cb57ca3 ("rxrpc: Add IPv6 support")
Signed-off-by: David Howells <dhowells@redhat.com>
---
net/rxrpc/peer_object.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/rxrpc/peer_object.c b/net/rxrpc/peer_object.c
index 941b724d523b..862eea6b266c 100644
--- a/net/rxrpc/peer_object.c
+++ b/net/rxrpc/peer_object.c
@@ -193,8 +193,8 @@ static void rxrpc_assess_MTU_size(struct rxrpc_peer *peer)
fl6->fl6_dport = htons(7001);
fl6->fl6_sport = htons(7000);
dst = ip6_route_output(&init_net, NULL, fl6);
- if (IS_ERR(dst)) {
- _leave(" [route err %ld]", PTR_ERR(dst));
+ if (dst->error) {
+ _leave(" [route err %d]", dst->error);
return;
}
break;
^ permalink raw reply related
* Re: [patch -next] net: rtnl: info leak in rtnl_fill_vfinfo()
From: David Miller @ 2016-10-13 16:12 UTC (permalink / raw)
To: dan.carpenter
Cc: moshe, roopa, nicolas.dichtel, nikolay, edumazet, hannes, nogahf,
bblanco, netdev, kernel-janitors
In-Reply-To: <20161013084528.GA16198@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 13 Oct 2016 11:45:28 +0300
> The "vf_vlan_info" struct ends with a 2 byte struct hole so we have to
> memset it to ensure that no stack information is revealed to user space.
>
> Fixes: 79aab093a0b5 ('net: Update API for VF vlan protocol 802.1ad support')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: [PATCH v6] net: ip, diag -- Add diag interface for raw sockets
From: Cyrill Gorcunov @ 2016-10-13 15:58 UTC (permalink / raw)
To: David Ahern
Cc: David Miller, netdev, eric.dumazet, jhs, linux-kernel, kuznet,
jmorris, yoshfuji, kaber, avagin, stephen
In-Reply-To: <e59c339f-ca3d-92e9-88e0-8c3e9e02e01a@cumulusnetworks.com>
On Thu, Oct 13, 2016 at 09:43:57AM -0600, David Ahern wrote:
> On 10/13/16 1:16 AM, Cyrill Gorcunov wrote:
> > On Wed, Oct 12, 2016 at 07:55:04PM -0400, David Miller wrote:
> >> From: Cyrill Gorcunov <gorcunov@gmail.com>
> >> Date: Wed, 12 Oct 2016 09:53:29 +0300
> >>
> >>> I can't rename the field, neither a can use union.
> >>
> >> Remind me again what is wrong with using an anonymous union?
> >
> > Anon union would be a preferred but Eric pointed me that even
> > though it might cause problems (https://patchwork.kernel.org/patch/9353365/)
> >
> > | Note that some programs could fail to compile with the added union
> > | anyway.
> > |
> > | Some gcc versions are unable to compile a static init with an union
> > |
> > | struct inet_diag_req_v2 foo = { .pad = 0, sdiag_family = AF_INET, };
> > |
> > | When I cooked my recent fq commit I simply removed a pad and replaced
> > | it :
> > |
> > | git show fefa569a9d4bc4 -- include
> >
>
> That commit suggests it is acceptable to just rename the
> pad field, which is the simplest approach.
No. In further message Eric points that
| This is a bit different of course, since struct tc_fq_qd_stats is only
| one way : Kernel produces the content and gives it to user space.
and we are simply lucky that we didn't break anything in userspace yet.
IOW, it's not a problem for me simply to
- rename it or,
- use anonymous union
but both options have own problems :/
Also I just thought what if we introduce
struct inet_diag_req_raw_v2 {
__u8 sdiag_family;
__u8 sdiag_protocol;
__u8 idiag_ext;
__u8 sdiag_raw_protocol;
__u32 idiag_states;
struct inet_diag_sockid id;
};
where @sdiag_raw_protocol explicitly stated and
will collide with existing struct inet_diag_req_v2?
This is a hack too of course but at least this
won't break api definitely.
^ permalink raw reply
* Re: [patch] tipc: info leak in __tipc_nl_add_udp_addr()
From: David Miller @ 2016-10-13 16:10 UTC (permalink / raw)
To: dan.carpenter
Cc: jon.maloy, netdev, kernel-janitors, linux-kernel, tipc-discussion,
richard.alpe
In-Reply-To: <20161013080606.GA3389@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 13 Oct 2016 11:06:06 +0300
> We should clear out the padding and unused struct members so that we
> don't expose stack information to userspace.
>
> Fixes: fdb3accc2c15 ('tipc: add the ability to get UDP options via netlink')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
^ permalink raw reply
* Re: [PATCH] net: ipv4: Do not drop to make_route if oif is l3mdev
From: David Miller @ 2016-10-13 16:05 UTC (permalink / raw)
To: dsa; +Cc: netdev
In-Reply-To: <1476303611-28154-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Wed, 12 Oct 2016 13:20:11 -0700
> Commit e0d56fdd7342 was a bit aggressive removing l3mdev calls in
> the IPv4 stack. If the fib_lookup fails we do not want to drop to
> make_route if the oif is an l3mdev device.
>
> Also reverts 19664c6a0009 ("net: l3mdev: Remove netif_index_is_l3_master")
> which removed netif_index_is_l3_master.
>
> Fixes: e0d56fdd7342 ("net: l3mdev: remove redundant calls")
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Applied, thanks David.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: Trigger state machine on state change and not polling.
From: David Miller @ 2016-10-13 16:04 UTC (permalink / raw)
To: andrew; +Cc: netdev, f.fainelli, kyle.roeschley
In-Reply-To: <1476303294-14944-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Wed, 12 Oct 2016 22:14:53 +0200
> The phy_start() is used to indicate the PHY is now ready to do its
> work. The state is changed, normally to PHY_UP which means that both
> the MAC and the PHY are ready.
>
> If the phy driver is using polling, when the next poll happens, the
> state machine notices the PHY is now in PHY_UP, and kicks off
> auto-negotiation, if needed.
>
> If however, the PHY is using interrupts, there is no polling. The phy
> is stuck in PHY_UP until the next interrupt comes along. And there is
> no reason for the PHY to interrupt.
>
> Have phy_start() schedule the state machine to run, which both speeds
> up the polling use case, and makes the interrupt use case actually
> work.
>
> This problems exists whenever there is a state change which will not
> cause an interrupt. Trigger the state machine in these cases,
> e.g. phy_error().
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> Cc: Kyle Roeschley <kyle.roeschley@ni.com>
> ---
>
> This should be applied to stable, but i've no idea what fixes: tag to
> use. It could be phylib has been broken since interrupts were added?
Since you think it should go to -stable, it is not appropriate to target
this patch to 'net-next', only 'net' makes sense.
Therefore I applied this to 'net' and will queue it up for -stable.
Personally I think phylib was broken in this area since interrupts
were added.
^ permalink raw reply
* Re: [PATCH] net: axienet: Remove unused parameter from __axienet_device_reset
From: Michal Simek @ 2016-10-13 12:23 UTC (permalink / raw)
To: Tobias Klauser, Anirudha Sarangi, John Linn
Cc: Michal Simek, Sören Brinkmann, netdev
In-Reply-To: <20161013112833.7581-1-tklauser@distanz.ch>
On 13.10.2016 13:28, Tobias Klauser wrote:
> The dev parameter passed to __axienet_device_reset() is not used inside
> the function, so remove it.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> ---
> drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index 35f9f9742a48..c688d68c39aa 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -431,8 +431,7 @@ static void axienet_setoptions(struct net_device *ndev, u32 options)
> lp->options |= options;
> }
>
> -static void __axienet_device_reset(struct axienet_local *lp,
> - struct device *dev, off_t offset)
> +static void __axienet_device_reset(struct axienet_local *lp, off_t offset)
> {
> u32 timeout;
> /* Reset Axi DMA. This would reset Axi Ethernet core as well. The reset
> @@ -468,8 +467,8 @@ static void axienet_device_reset(struct net_device *ndev)
> u32 axienet_status;
> struct axienet_local *lp = netdev_priv(ndev);
>
> - __axienet_device_reset(lp, &ndev->dev, XAXIDMA_TX_CR_OFFSET);
> - __axienet_device_reset(lp, &ndev->dev, XAXIDMA_RX_CR_OFFSET);
> + __axienet_device_reset(lp, XAXIDMA_TX_CR_OFFSET);
> + __axienet_device_reset(lp, XAXIDMA_RX_CR_OFFSET);
>
> lp->max_frm_size = XAE_MAX_VLAN_FRAME_SIZE;
> lp->options |= XAE_OPTION_VLAN;
> @@ -1338,8 +1337,8 @@ static void axienet_dma_err_handler(unsigned long data)
> axienet_iow(lp, XAE_MDIO_MC_OFFSET, (mdio_mcreg &
> ~XAE_MDIO_MC_MDIOEN_MASK));
>
> - __axienet_device_reset(lp, &ndev->dev, XAXIDMA_TX_CR_OFFSET);
> - __axienet_device_reset(lp, &ndev->dev, XAXIDMA_RX_CR_OFFSET);
> + __axienet_device_reset(lp, XAXIDMA_TX_CR_OFFSET);
> + __axienet_device_reset(lp, XAXIDMA_RX_CR_OFFSET);
>
> axienet_iow(lp, XAE_MDIO_MC_OFFSET, mdio_mcreg);
> axienet_mdio_wait_until_ready(lp);
>
Can you please send this directly to mainline?
And put my:
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v4 3/3] net: phy: leds: add support for led triggers on phy link state change
From: David Miller @ 2016-10-13 15:59 UTC (permalink / raw)
To: zach.brown
Cc: devel, florian.c.schilhabel, f.fainelli, andrew, netdev,
linux-kernel, rpurdie, gregkh, Larry.Finger, j.anaszewski,
linux-leds, mlindner
In-Reply-To: <20161013154246.GA17387@zach-desktop>
From: Zach Brown <zach.brown@ni.com>
Date: Thu, 13 Oct 2016 10:42:46 -0500
> Do you have suggestions on how to better handle the choice of the array size
> and the speeds?
All of the speed values are simply the rate in bits per second.
There is therefore no reason you can't just print the raw value and
scale it to whatever is appropriate ("MB/s", "GB/s", etc.)
^ permalink raw reply
* Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header
From: David Miller @ 2016-10-13 15:57 UTC (permalink / raw)
To: dledford; +Cc: pabeni, linux-rdma, sean.hefty, hal.rosenstock, netdev
In-Reply-To: <2eadc083-e2e0-5c6d-fe84-c5851be3e2ec@redhat.com>
From: Doug Ledford <dledford@redhat.com>
Date: Thu, 13 Oct 2016 11:20:59 -0400
> We *had* a safe way to do that. It got broken. What about increasing
> the size of skb->cb? Or adding a skb->dgid that is a
> u8[INFINIBAND_ALEN]? Or a more generic skb->dest_ll_addr that is sized
> to hold the dest address for any link layer?
I understand the situation, and I also believe that making sk_buff any
huger than it already is happens to be a non-starter.
>> Pushing metadata before the head of the SKB data pointer is illegal,
>> as the layers in between might want to push protocol headers,
>
> That's a total non-issue for us. There are no headers that protocols
> can add before ours.
Ok, if that's the case, and based upon Paolo's response to me it appears
to be, I guess this is OK for now.
Paolo please resubmit your patch, thanks.
^ permalink raw reply
* [PATCH iproute2] bridge: add support for the multicast flood flag
From: Nikolay Aleksandrov @ 2016-10-13 15:54 UTC (permalink / raw)
To: netdev; +Cc: stephen, roopa, Nikolay Aleksandrov
Recently a new per-port flag was added which controls the flooding of
unknown multicast, this patch adds support for controlling it via iproute2.
It also updates the man pages with information about the new flag.
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
note that there's one line that's > 80 chars in link.c but it is following
the style of the previous flags
bridge/link.c | 12 ++++++++++++
ip/iplink_bridge_slave.c | 9 +++++++++
man/man8/bridge.8 | 7 ++++++-
man/man8/ip-link.8.in | 7 ++++++-
4 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/bridge/link.c b/bridge/link.c
index 13f606c7d456..93472ad3699e 100644
--- a/bridge/link.c
+++ b/bridge/link.c
@@ -195,6 +195,9 @@ int print_linkinfo(const struct sockaddr_nl *who,
if (prtb[IFLA_BRPORT_UNICAST_FLOOD])
print_onoff(fp, "flood",
rta_getattr_u8(prtb[IFLA_BRPORT_UNICAST_FLOOD]));
+ if (prtb[IFLA_BRPORT_MCAST_FLOOD])
+ print_onoff(fp, "mcast_flood",
+ rta_getattr_u8(prtb[IFLA_BRPORT_MCAST_FLOOD]));
}
} else
print_portstate(fp, rta_getattr_u8(tb[IFLA_PROTINFO]));
@@ -227,6 +230,7 @@ static void usage(void)
fprintf(stderr, " [ learning {on | off} ]\n");
fprintf(stderr, " [ learning_sync {on | off} ]\n");
fprintf(stderr, " [ flood {on | off} ]\n");
+ fprintf(stderr, " [ mcast_flood {on | off} ]\n");
fprintf(stderr, " [ hwmode {vepa | veb} ]\n");
fprintf(stderr, " [ self ] [ master ]\n");
fprintf(stderr, " bridge link show [dev DEV]\n");
@@ -265,6 +269,7 @@ static int brlink_modify(int argc, char **argv)
__s8 learning = -1;
__s8 learning_sync = -1;
__s8 flood = -1;
+ __s8 mcast_flood = -1;
__s8 hairpin = -1;
__s8 bpdu_guard = -1;
__s8 fast_leave = -1;
@@ -308,6 +313,10 @@ static int brlink_modify(int argc, char **argv)
NEXT_ARG();
if (!on_off("flood", &flood, *argv))
return -1;
+ } else if (strcmp(*argv, "mcast_flood") == 0) {
+ NEXT_ARG();
+ if (!on_off("mcast_flood", &mcast_flood, *argv))
+ return -1;
} else if (strcmp(*argv, "cost") == 0) {
NEXT_ARG();
cost = atoi(*argv);
@@ -380,6 +389,9 @@ static int brlink_modify(int argc, char **argv)
addattr8(&req.n, sizeof(req), IFLA_BRPORT_PROTECT, root_block);
if (flood >= 0)
addattr8(&req.n, sizeof(req), IFLA_BRPORT_UNICAST_FLOOD, flood);
+ if (mcast_flood >= 0)
+ addattr8(&req.n, sizeof(req), IFLA_BRPORT_MCAST_FLOOD,
+ mcast_flood);
if (learning >= 0)
addattr8(&req.n, sizeof(req), IFLA_BRPORT_LEARNING, learning);
if (learning_sync >= 0)
diff --git a/ip/iplink_bridge_slave.c b/ip/iplink_bridge_slave.c
index 6c5c59a9524f..fbb3f06e8ff7 100644
--- a/ip/iplink_bridge_slave.c
+++ b/ip/iplink_bridge_slave.c
@@ -33,6 +33,7 @@ static void print_explain(FILE *f)
" [ proxy_arp_wifi {on | off} ]\n"
" [ mcast_router MULTICAST_ROUTER ]\n"
" [ mcast_fast_leave {on | off} ]\n"
+ " [ mcast_flood {on | off} ]\n"
);
}
@@ -187,6 +188,10 @@ static void bridge_slave_print_opt(struct link_util *lu, FILE *f,
if (tb[IFLA_BRPORT_FAST_LEAVE])
print_onoff(f, "mcast_fast_leave",
rta_getattr_u8(tb[IFLA_BRPORT_FAST_LEAVE]));
+
+ if (tb[IFLA_BRPORT_MCAST_FLOOD])
+ print_onoff(f, "mcast_flood",
+ rta_getattr_u8(tb[IFLA_BRPORT_MCAST_FLOOD]));
}
static void bridge_slave_parse_on_off(char *arg_name, char *arg_val,
@@ -251,6 +256,10 @@ static int bridge_slave_parse_opt(struct link_util *lu, int argc, char **argv,
NEXT_ARG();
bridge_slave_parse_on_off("flood", *argv, n,
IFLA_BRPORT_UNICAST_FLOOD);
+ } else if (matches(*argv, "mcast_flood") == 0) {
+ NEXT_ARG();
+ bridge_slave_parse_on_off("mcast_flood", *argv, n,
+ IFLA_BRPORT_MCAST_FLOOD);
} else if (matches(*argv, "proxy_arp") == 0) {
NEXT_ARG();
bridge_slave_parse_on_off("proxy_arp", *argv, n,
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index 7bfb068b74fe..6617e188a384 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -43,7 +43,8 @@ bridge \- show / manipulate bridge addresses and devices
.BR learning_sync " { " on " | " off " } ] [ "
.BR flood " { " on " | " off " } ] [ "
.BR hwmode " { " vepa " | " veb " } ] [ "
-.BR self " ] [ " master " ] "
+.BR mcast_flood " { " on " | " off " } ] [ "
+.BR self " ] [ " master " ]"
.ti -8
.BR "bridge link" " [ " show " ] [ "
@@ -310,6 +311,10 @@ switch.
- bridging happens in hardware.
.TP
+.BR "mcast_flood on " or " mcast_flood off "
+Controls whether a given port will be flooded with multicast traffic for which there is no MDB entry. By default this flag is on.
+
+.TP
.BI self
link setting is configured on specified physical device
diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index 6cb97ea9c66e..7c0d602b50d3 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8/ip-link.8.in
@@ -1431,7 +1431,9 @@ the following additional arguments are supported:
] [
.BI mcast_router " MULTICAST_ROUTER"
] [
-.BR mcast_fast_leave " { " on " | " off "} ]"
+.BR mcast_fast_leave " { " on " | " off "}"
+] [
+.BR mcast_flood " { " on " | " off " } ]"
.in +8
.sp
@@ -1500,6 +1502,9 @@ queries.
.B fastleave
option above.
+.BR mcast_flood " { " on " | " off " }"
+- controls whether a given port will be flooded with multicast traffic for which there is no MDB entry.
+
.in -8
.TP
--
2.1.4
^ permalink raw reply related
* RE: [PATCH] qed: fix old-style function definition
From: Mintz, Yuval @ 2016-10-13 14:15 UTC (permalink / raw)
To: David Miller, arnd@arndb.de
Cc: Yuval.Mintz@qlogic.com, Ariel.Elior@qlogic.com,
everest-linux-l2@qlogic.com, Amrani, Ram, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20161013.095532.1238800778112994579.davem@davemloft.net>
> > The definition of qed_get_rdma_ops() is not a prototype unless we add
> > 'void' here, as indicated by this W=1 warning:
> >
> > drivers/net/ethernet/qlogic/qed/qed_roce.c: In function ‘qed_get_rdma_ops’:
> > drivers/net/ethernet/qlogic/qed/qed_roce.c:2950:28: error: old-style
> > function definition [-Werror=old-style-definition]
> >
> > Fixes: abd49676c707 ("qed: Add RoCE ll2 & GSI support")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Again, Qlogic folks, please properly review patches posted against your driver.
>
> Thanks.
Sorry, managed to miss this one.
Acked-by: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
^ 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