* Re: [PATCH v2 3/4] sctp: fix association hangs due to errors when reneging events from the ordering queue
From: Neil Horman @ 2013-02-28 14:34 UTC (permalink / raw)
To: Lee A. Roberts; +Cc: netdev
In-Reply-To: <1361991273-30578-4-git-send-email-lee.roberts@hp.com>
On Wed, Feb 27, 2013 at 11:54:32AM -0700, Lee A. Roberts wrote:
> From: "Lee A. Roberts" <lee.roberts@hp.com>
>
> Resolve SCTP association hangs observed during SCTP stress
> testing. Observable symptoms include communications hangs
> with data being held in the association reassembly and/or lobby
> (ordering) queues. Close examination of reassembly queue shows
> missing packets.
>
> In sctp_ulpq_renege_list(), events being reneged from the
> ordering queue may correspond to multiple TSNs. Identify
> all affected packets; sum freed space and renege from the
> tsnmap.
>
> Signed-off-by: Lee A. Roberts <lee.roberts@hp.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
>
^ permalink raw reply
* Re: [PATCH v2 4/4] sctp: fix association hangs due to partial delivery errors
From: Neil Horman @ 2013-02-28 14:34 UTC (permalink / raw)
To: Lee A. Roberts; +Cc: netdev
In-Reply-To: <1361991273-30578-5-git-send-email-lee.roberts@hp.com>
On Wed, Feb 27, 2013 at 11:54:33AM -0700, Lee A. Roberts wrote:
> From: "Lee A. Roberts" <lee.roberts@hp.com>
>
> Resolve SCTP association hangs observed during SCTP stress
> testing. Observable symptoms include communications hangs
> with data being held in the association reassembly and/or lobby
> (ordering) queues. Close examination of reassembly queue shows
> missing packets.
>
> In sctp_ulpq_tail_data(), use return values 0,1 to indicate whether
> a complete event (with MSG_EOR set) was delivered. A return value
> of -ENOMEM continues to indicate an out-of-memory condition was
> encountered.
>
> In sctp_ulpq_retrieve_partial() and sctp_ulpq_retrieve_first(),
> correct message reassembly logic for SCTP partial delivery.
> Change logic to ensure that as much data as possible is sent
> with the initial partial delivery and that following partial
> deliveries contain all available data.
>
> In sctp_ulpq_partial_delivery(), attempt partial delivery only
> if the data on the head of the reassembly queue is at or before
> the cumulative TSN ACK point.
>
> In sctp_ulpq_renege(), use the modified return values from
> sctp_ulpq_tail_data() to choose whether to attempt partial
> delivery or to attempt to drain the reassembly queue as a
> means to reduce memory pressure. Remove call to
> sctp_tsnmap_mark(), as this is handled correctly in call to
> sctp_ulpq_tail_data().
>
> Signed-off-by: Lee A. Roberts <lee.roberts@hp.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
>
^ permalink raw reply
* [PATCH v3 0/4] sctp: fix association hangs due to reassembly/ordering logic
From: Lee A. Roberts @ 2013-02-28 14:37 UTC (permalink / raw)
To: netdev; +Cc: linux-sctp, lee.roberts
In-Reply-To: <1361991273-30578-1-git-send-email-lee.roberts@hp.com>
From: "Lee A. Roberts" <lee.roberts@hp.com>
This series of patches resolves several SCTP association hangs observed during
SCTP stress testing. Observable symptoms include communications hangs with
data being held in the association reassembly and/or lobby (ordering) queues.
Close examination of reassembly/ordering queues may show either duplicated
or missing packets.
In version #2, corrected build failure in initial version of patch series
due to wrong calling sequence for sctp_ulpq_partial_delivery() being inserted
in sctp_ulpq_renege().
In version #3, adjusted patch documentation to be less repetitive.
Lee A. Roberts (4):
sctp: fix association hangs due to off-by-one errors in
sctp_tsnmap_grow()
sctp: fix association hangs due to reneging packets below the
cumulative TSN ACK point
sctp: fix association hangs due to errors when reneging events from
the ordering queue
sctp: fix association hangs due to partial delivery errors
net/sctp/tsnmap.c | 13 ++++----
net/sctp/ulpqueue.c | 87 +++++++++++++++++++++++++++++++++++++++++----------
2 files changed, 78 insertions(+), 22 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v3 1/4] sctp: fix association hangs due to off-by-one errors in sctp_tsnmap_grow()
From: Lee A. Roberts @ 2013-02-28 14:37 UTC (permalink / raw)
To: netdev; +Cc: linux-sctp, lee.roberts
In-Reply-To: <1361991273-30578-1-git-send-email-lee.roberts@hp.com>
From: "Lee A. Roberts" <lee.roberts@hp.com>
In sctp_tsnmap_mark(), correct off-by-one error when calculating
size value for sctp_tsnmap_grow().
In sctp_tsnmap_grow(), correct off-by-one error when copying
and resizing the tsnmap. If max_tsn_seen is in the LSB of the
word, this bit can be lost, causing the corresponding packet
to be transmitted again and to be entered as a duplicate into
the SCTP reassembly/ordering queues. Change parameter name
from "gap" (zero-based index) to "size" (one-based) to enhance
code readability.
Signed-off-by: Lee A. Roberts <lee.roberts@hp.com>
---
net/sctp/tsnmap.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/net/sctp/tsnmap.c b/net/sctp/tsnmap.c
index 5f25e0c..396c451 100644
--- a/net/sctp/tsnmap.c
+++ b/net/sctp/tsnmap.c
@@ -51,7 +51,7 @@
static void sctp_tsnmap_update(struct sctp_tsnmap *map);
static void sctp_tsnmap_find_gap_ack(unsigned long *map, __u16 off,
__u16 len, __u16 *start, __u16 *end);
-static int sctp_tsnmap_grow(struct sctp_tsnmap *map, u16 gap);
+static int sctp_tsnmap_grow(struct sctp_tsnmap *map, u16 size);
/* Initialize a block of memory as a tsnmap. */
struct sctp_tsnmap *sctp_tsnmap_init(struct sctp_tsnmap *map, __u16 len,
@@ -124,7 +124,7 @@ int sctp_tsnmap_mark(struct sctp_tsnmap *map, __u32 tsn,
gap = tsn - map->base_tsn;
- if (gap >= map->len && !sctp_tsnmap_grow(map, gap))
+ if (gap >= map->len && !sctp_tsnmap_grow(map, gap + 1))
return -ENOMEM;
if (!sctp_tsnmap_has_gap(map) && gap == 0) {
@@ -360,23 +360,24 @@ __u16 sctp_tsnmap_num_gabs(struct sctp_tsnmap *map,
return ngaps;
}
-static int sctp_tsnmap_grow(struct sctp_tsnmap *map, u16 gap)
+static int sctp_tsnmap_grow(struct sctp_tsnmap *map, u16 size)
{
unsigned long *new;
unsigned long inc;
u16 len;
- if (gap >= SCTP_TSN_MAP_SIZE)
+ if (size > SCTP_TSN_MAP_SIZE)
return 0;
- inc = ALIGN((gap - map->len),BITS_PER_LONG) + SCTP_TSN_MAP_INCREMENT;
+ inc = ALIGN((size - map->len), BITS_PER_LONG) + SCTP_TSN_MAP_INCREMENT;
len = min_t(u16, map->len + inc, SCTP_TSN_MAP_SIZE);
new = kzalloc(len>>3, GFP_ATOMIC);
if (!new)
return 0;
- bitmap_copy(new, map->tsn_map, map->max_tsn_seen - map->base_tsn);
+ bitmap_copy(new, map->tsn_map,
+ map->max_tsn_seen - map->cumulative_tsn_ack_point);
kfree(map->tsn_map);
map->tsn_map = new;
map->len = len;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 2/4] sctp: fix association hangs due to reneging packets below the cumulative TSN ACK point
From: Lee A. Roberts @ 2013-02-28 14:37 UTC (permalink / raw)
To: netdev; +Cc: linux-sctp, lee.roberts
In-Reply-To: <1361991273-30578-1-git-send-email-lee.roberts@hp.com>
From: "Lee A. Roberts" <lee.roberts@hp.com>
In sctp_ulpq_renege_list(), do not renege packets below the
cumulative TSN ACK point.
Signed-off-by: Lee A. Roberts <lee.roberts@hp.com>
---
net/sctp/ulpqueue.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
index ada1746..63afddc 100644
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -969,11 +969,16 @@ static __u16 sctp_ulpq_renege_list(struct sctp_ulpq *ulpq,
tsnmap = &ulpq->asoc->peer.tsn_map;
- while ((skb = __skb_dequeue_tail(list)) != NULL) {
- freed += skb_headlen(skb);
+ while ((skb = skb_peek_tail(list)) != NULL) {
event = sctp_skb2event(skb);
tsn = event->tsn;
+ /* Don't renege below the Cumulative TSN ACK Point. */
+ if (TSN_lte(tsn, sctp_tsnmap_get_ctsn(tsnmap)))
+ break;
+
+ __skb_unlink(skb, list);
+ freed += skb_headlen(skb);
sctp_ulpevent_free(event);
sctp_tsnmap_renege(tsnmap, tsn);
if (freed >= needed)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 4/4] sctp: fix association hangs due to partial delivery errors
From: Lee A. Roberts @ 2013-02-28 14:37 UTC (permalink / raw)
To: netdev; +Cc: linux-sctp, lee.roberts
In-Reply-To: <1361991273-30578-1-git-send-email-lee.roberts@hp.com>
From: "Lee A. Roberts" <lee.roberts@hp.com>
In sctp_ulpq_tail_data(), use return values 0,1 to indicate whether
a complete event (with MSG_EOR set) was delivered. A return value
of -ENOMEM continues to indicate an out-of-memory condition was
encountered.
In sctp_ulpq_retrieve_partial() and sctp_ulpq_retrieve_first(),
correct message reassembly logic for SCTP partial delivery.
Change logic to ensure that as much data as possible is sent
with the initial partial delivery and that following partial
deliveries contain all available data.
In sctp_ulpq_partial_delivery(), attempt partial delivery only
if the data on the head of the reassembly queue is at or before
the cumulative TSN ACK point.
In sctp_ulpq_renege(), use the modified return values from
sctp_ulpq_tail_data() to choose whether to attempt partial
delivery or to attempt to drain the reassembly queue as a
means to reduce memory pressure. Remove call to
sctp_tsnmap_mark(), as this is handled correctly in call to
sctp_ulpq_tail_data().
Signed-off-by: Lee A. Roberts <lee.roberts@hp.com>
---
net/sctp/ulpqueue.c | 54 ++++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 43 insertions(+), 11 deletions(-)
diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
index f221fbb..482e3ea 100644
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -106,6 +106,7 @@ int sctp_ulpq_tail_data(struct sctp_ulpq *ulpq, struct sctp_chunk *chunk,
{
struct sk_buff_head temp;
struct sctp_ulpevent *event;
+ int event_eor = 0;
/* Create an event from the incoming chunk. */
event = sctp_ulpevent_make_rcvmsg(chunk->asoc, chunk, gfp);
@@ -127,10 +128,12 @@ int sctp_ulpq_tail_data(struct sctp_ulpq *ulpq, struct sctp_chunk *chunk,
/* Send event to the ULP. 'event' is the sctp_ulpevent for
* very first SKB on the 'temp' list.
*/
- if (event)
+ if (event) {
+ event_eor = (event->msg_flags & MSG_EOR) ? 1 : 0;
sctp_ulpq_tail_event(ulpq, event);
+ }
- return 0;
+ return event_eor;
}
/* Add a new event for propagation to the ULP. */
@@ -540,14 +543,19 @@ static struct sctp_ulpevent *sctp_ulpq_retrieve_partial(struct sctp_ulpq *ulpq)
ctsn = cevent->tsn;
switch (cevent->msg_flags & SCTP_DATA_FRAG_MASK) {
+ case SCTP_DATA_FIRST_FRAG:
+ if (!first_frag)
+ return NULL;
+ goto done;
case SCTP_DATA_MIDDLE_FRAG:
if (!first_frag) {
first_frag = pos;
next_tsn = ctsn + 1;
last_frag = pos;
- } else if (next_tsn == ctsn)
+ } else if (next_tsn == ctsn) {
next_tsn++;
- else
+ last_frag = pos;
+ } else
goto done;
break;
case SCTP_DATA_LAST_FRAG:
@@ -651,6 +659,14 @@ static struct sctp_ulpevent *sctp_ulpq_retrieve_first(struct sctp_ulpq *ulpq)
} else
goto done;
break;
+
+ case SCTP_DATA_LAST_FRAG:
+ if (!first_frag)
+ return NULL;
+ else
+ goto done;
+ break;
+
default:
return NULL;
}
@@ -1025,16 +1041,28 @@ void sctp_ulpq_partial_delivery(struct sctp_ulpq *ulpq,
struct sctp_ulpevent *event;
struct sctp_association *asoc;
struct sctp_sock *sp;
+ __u32 ctsn;
+ struct sk_buff *skb;
asoc = ulpq->asoc;
sp = sctp_sk(asoc->base.sk);
/* If the association is already in Partial Delivery mode
- * we have noting to do.
+ * we have nothing to do.
*/
if (ulpq->pd_mode)
return;
+ /* Data must be at or below the Cumulative TSN ACK Point to
+ * start partial delivery.
+ */
+ skb = skb_peek(&asoc->ulpq.reasm);
+ if (skb != NULL) {
+ ctsn = sctp_skb2event(skb)->tsn;
+ if (!TSN_lte(ctsn, sctp_tsnmap_get_ctsn(&asoc->peer.tsn_map)))
+ return;
+ }
+
/* If the user enabled fragment interleave socket option,
* multiple associations can enter partial delivery.
* Otherwise, we can only enter partial delivery if the
@@ -1077,12 +1105,16 @@ void sctp_ulpq_renege(struct sctp_ulpq *ulpq, struct sctp_chunk *chunk,
}
/* If able to free enough room, accept this chunk. */
if (chunk && (freed >= needed)) {
- __u32 tsn;
- tsn = ntohl(chunk->subh.data_hdr->tsn);
- sctp_tsnmap_mark(&asoc->peer.tsn_map, tsn, chunk->transport);
- sctp_ulpq_tail_data(ulpq, chunk, gfp);
-
- sctp_ulpq_partial_delivery(ulpq, gfp);
+ int retval;
+ retval = sctp_ulpq_tail_data(ulpq, chunk, gfp);
+ /*
+ * Enter partial delivery if chunk has not been
+ * delivered; otherwise, drain the reassembly queue.
+ */
+ if (retval <= 0)
+ sctp_ulpq_partial_delivery(ulpq, gfp);
+ else if (retval == 1)
+ sctp_ulpq_reasm_drain(ulpq);
}
sk_mem_reclaim(asoc->base.sk);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 3/4] sctp: fix association hangs due to errors when reneging events from the ordering queue
From: Lee A. Roberts @ 2013-02-28 14:37 UTC (permalink / raw)
To: netdev; +Cc: linux-sctp, lee.roberts
In-Reply-To: <1361991273-30578-1-git-send-email-lee.roberts@hp.com>
From: "Lee A. Roberts" <lee.roberts@hp.com>
In sctp_ulpq_renege_list(), events being reneged from the
ordering queue may correspond to multiple TSNs. Identify
all affected packets; sum freed space and renege from the
tsnmap.
Signed-off-by: Lee A. Roberts <lee.roberts@hp.com>
---
net/sctp/ulpqueue.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
index 63afddc..f221fbb 100644
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -962,8 +962,8 @@ static __u16 sctp_ulpq_renege_list(struct sctp_ulpq *ulpq,
struct sk_buff_head *list, __u16 needed)
{
__u16 freed = 0;
- __u32 tsn;
- struct sk_buff *skb;
+ __u32 tsn, last_tsn;
+ struct sk_buff *skb, *flist, *last;
struct sctp_ulpevent *event;
struct sctp_tsnmap *tsnmap;
@@ -977,10 +977,28 @@ static __u16 sctp_ulpq_renege_list(struct sctp_ulpq *ulpq,
if (TSN_lte(tsn, sctp_tsnmap_get_ctsn(tsnmap)))
break;
- __skb_unlink(skb, list);
+ /* Events in ordering queue may have multiple fragments
+ * corresponding to additional TSNs. Sum the total
+ * freed space; find the last TSN.
+ */
freed += skb_headlen(skb);
+ flist = skb_shinfo(skb)->frag_list;
+ for (last = flist; flist; flist = flist->next) {
+ last = flist;
+ freed += skb_headlen(last);
+ }
+ if (last)
+ last_tsn = sctp_skb2event(last)->tsn;
+ else
+ last_tsn = tsn;
+
+ /* Unlink the event, then renege all applicable TSNs. */
+ __skb_unlink(skb, list);
sctp_ulpevent_free(event);
- sctp_tsnmap_renege(tsnmap, tsn);
+ while (TSN_lte(tsn, last_tsn)) {
+ sctp_tsnmap_renege(tsnmap, tsn);
+ tsn++;
+ }
if (freed >= needed)
return freed;
}
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC PATCH 2/3] ixgbe: Use default fdb handlers when not in VF mode.
From: Vlad Yasevich @ 2013-02-28 14:46 UTC (permalink / raw)
To: John Fastabend; +Cc: netdev, davem, Rose, Gregory V
In-Reply-To: <512EDC77.5090802@intel.com>
On 02/27/2013 11:26 PM, John Fastabend wrote:
> On 2/27/2013 9:46 AM, Vlad Yasevich wrote:
>> Allow the use of ndo_dflt_fdb_<add|del|dump> when the
>> adapter does not have VF configured. This allows for
>> IFF_UNICAST_FLT support and allows VF handling to potentially
>> do something different.
>>
>> CC: John Fastabend <john.r.fastabend@intel.com>
>> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
>> ---
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 26
>> ++++++++++--------------
>> 1 files changed, 11 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>> b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>> index 68478d6..0ae2525 100644
>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>> @@ -7007,7 +7007,7 @@ static int ixgbe_ndo_fdb_add(struct ndmsg *ndm,
>> struct nlattr *tb[],
>
> With the first patch we can just remove this routine altogether and
> let the dflt handler do its work.
>
> CC'd Greg in case I miss something.
OK. I took the safe approach and kept the functions. The only
difference right now is that right now with VF configured, fdb_add
refuses to add more then IXGBE_MAX_PF_MACVLANS and thus never would
enter into promisc mode. I am not sure if that how its supposed to
be have or not. That's one of the reasons I kept this around.
-vlad
>
>> int err;
>>
>> if (!(adapter->flags & IXGBE_FLAG_SRIOV_ENABLED))
>> - return -EOPNOTSUPP;
>> + return ndo_dflt_fdb_add(ndm, tb, dev, addr, flags);
>>
>> /* Hardware does not support aging addresses so if a
>> * ndm_state is given only allow permanent addresses
>> @@ -7045,20 +7045,21 @@ static int ixgbe_ndo_fdb_del(struct ndmsg
>> *ndm, struct nlattr *tb[],
>
> same here just remove it and use the dflt handler.
>
>> struct ixgbe_adapter *adapter = netdev_priv(dev);
>> int err = -EOPNOTSUPP;
>>
>> + if (!(adapter->flags & IXGBE_FLAG_SRIOV_ENABLED))
>> + return ndo_dflt_fdb_del(ndm, tb, dev, addr);
>> +
>> if (ndm->ndm_state & NUD_PERMANENT) {
>> pr_info("%s: FDB only supports static addresses\n",
>> ixgbe_driver_name);
>> return -EINVAL;
>> }
>>
>> - if (adapter->flags & IXGBE_FLAG_SRIOV_ENABLED) {
>> - if (is_unicast_ether_addr(addr))
>> - err = dev_uc_del(dev, addr);
>> - else if (is_multicast_ether_addr(addr))
>> - err = dev_mc_del(dev, addr);
>> - else
>> - err = -EINVAL;
>> - }
>> + if (is_unicast_ether_addr(addr))
>> + err = dev_uc_del(dev, addr);
>> + else if (is_multicast_ether_addr(addr))
>> + err = dev_mc_del(dev, addr);
>> + else
>> + err = -EINVAL;
>>
>> return err;
>> }
>> @@ -7068,12 +7069,7 @@ static int ixgbe_ndo_fdb_dump(struct sk_buff *skb,
>> struct net_device *dev,
>> int idx)
>> {
>
> This is the same as not defining the op at all right? Just
> remove it.
>
>> - struct ixgbe_adapter *adapter = netdev_priv(dev);
>> -
>> - if (adapter->flags & IXGBE_FLAG_SRIOV_ENABLED)
>> - idx = ndo_dflt_fdb_dump(skb, cb, dev, idx);
>> -
>> - return idx;
>> + return ndo_dflt_fdb_dump(skb, cb, dev, idx);
>> }
>>
>> static int ixgbe_ndo_bridge_setlink(struct net_device *dev,
>>
>
> Then we get a patch with all '-' which is sort of nice.
>
^ permalink raw reply
* Re: [PATCH ethtool] Restore 20000baseKR2 cap display
From: Ben Hutchings @ 2013-02-28 15:01 UTC (permalink / raw)
To: Yaniv Rosner; +Cc: netdev
In-Reply-To: <1362046206-6907-1-git-send-email-yanivr@broadcom.com>
On Thu, 2013-02-28 at 12:10 +0200, Yaniv Rosner wrote:
> Restore the 20000baseKR2 which was removed by mistake back in June 2012.
Applied, thanks.
Ben.
> Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
> ---
> ethtool.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/ethtool.c b/ethtool.c
> index 55bc082..acac32a 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -513,6 +513,7 @@ dump_link_caps(const char *prefix, const char *an_prefix, u32 mask,
> { 0, ADVERTISED_10000baseT_Full, "10000baseT/Full" },
> { 0, ADVERTISED_10000baseKX4_Full, "10000baseKX4/Full" },
> { 0, ADVERTISED_20000baseMLD2_Full, "20000baseMLD2/Full" },
> + { 0, ADVERTISED_20000baseKR2_Full, "20000baseKR2/Full" },
> { 0, ADVERTISED_40000baseKR4_Full, "40000baseKR4/Full" },
> { 0, ADVERTISED_40000baseCR4_Full, "40000baseCR4/Full" },
> { 0, ADVERTISED_40000baseSR4_Full, "40000baseSR4/Full" },
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* ethtool 3.8 released
From: Ben Hutchings @ 2013-02-28 15:04 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 753 bytes --]
ethtool version 3.8 has been released.
Home page: https://ftp.kernel.org/pub/software/network/ethtool/
Download link:
https://ftp.kernel.org/pub/software/network/ethtool/ethtool-3.8.tar.xz
Release notes:
* Feature: Allow setting destination MAC address in L3/L4 flow spec
rules (-N/-U option)
* Fix: Show full 64 bits of user-data (-n/-u option)
* Fix: Add version check for et131x regs (-d option)
* Doc: Improve description of -f, -t, -s, -N/-U, -W options in man page
* Fix: Restore 20000baseKR2 cap display (no options)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/4] sctp: fix association hangs due to reassembly/ordering logic
From: Vlad Yasevich @ 2013-02-28 15:07 UTC (permalink / raw)
To: Lee A. Roberts; +Cc: netdev, linux-sctp
In-Reply-To: <1362062250-26749-1-git-send-email-lee.roberts@hp.com>
On 02/28/2013 09:37 AM, Lee A. Roberts wrote:
> From: "Lee A. Roberts" <lee.roberts@hp.com>
>
> This series of patches resolves several SCTP association hangs observed during
> SCTP stress testing. Observable symptoms include communications hangs with
> data being held in the association reassembly and/or lobby (ordering) queues.
> Close examination of reassembly/ordering queues may show either duplicated
> or missing packets.
>
> In version #2, corrected build failure in initial version of patch series
> due to wrong calling sequence for sctp_ulpq_partial_delivery() being inserted
> in sctp_ulpq_renege().
>
> In version #3, adjusted patch documentation to be less repetitive.
My Acks from version 1 still apply.
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
>
> Lee A. Roberts (4):
> sctp: fix association hangs due to off-by-one errors in
> sctp_tsnmap_grow()
> sctp: fix association hangs due to reneging packets below the
> cumulative TSN ACK point
> sctp: fix association hangs due to errors when reneging events from
> the ordering queue
> sctp: fix association hangs due to partial delivery errors
>
> net/sctp/tsnmap.c | 13 ++++----
> net/sctp/ulpqueue.c | 87 +++++++++++++++++++++++++++++++++++++++++----------
> 2 files changed, 78 insertions(+), 22 deletions(-)
>
^ permalink raw reply
* Re: query: localhost - 794ed393b clips hefty load tbench, does it matter?
From: Eric Dumazet @ 2013-02-28 16:13 UTC (permalink / raw)
To: Mike Galbraith; +Cc: netdev, Eric Dumazet
In-Reply-To: <1362055757.4460.236.camel@marge.simpson.net>
On Thu, 2013-02-28 at 13:49 +0100, Mike Galbraith wrote:
> Greetings network wizards,
>
> I was testing a 64 core box after 3.0-stable update, and noticed
> $subject.
>
> vogelweide:~/:[0]# numactl --hardware
> available: 1 nodes (0)
> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
> node 0 size: 8181 MB
> node 0 free: 7353 MB
> node distances:
> node 0
> 0: 10
>
> Sob, poor thing. Anyway, that's the box in case it matters.
>
> Without 94ed393b.
>
> vogelweide:~/:[0]# for i in 1 2 4 8 16 32 64 128 256 512; do tbench.sh $i 10 2>&1|grep Throughput; done
> Throughput 288.784 MB/sec 1 procs
> Throughput 559.937 MB/sec 2 procs
> Throughput 1068.75 MB/sec 4 procs
> Throughput 2159.04 MB/sec 8 procs
> Throughput 4193.75 MB/sec 16 procs
> Throughput 7662.24 MB/sec 32 procs
> Throughput 9034.49 MB/sec 64 procs
> Throughput 9045.9 MB/sec 128 procs
> Throughput 9077.55 MB/sec 256 procs
> Throughput 8907.48 MB/sec 512 procs
>
> With.
>
> vogelweide:~/:[0]# for i in 1 2 4 8 16 32 64 128 256 512; do tbench.sh $i 10 2>&1|grep Throughput; done
> Throughput 288.833 MB/sec 1 procs
> Throughput 520.87 MB/sec 2 procs
> Throughput 937.758 MB/sec 4 procs
> Throughput 1563.3 MB/sec 8 procs
> Throughput 1775.14 MB/sec 16 procs
> Throughput 1406.55 MB/sec 32 procs
> Throughput 1448.77 MB/sec 64 procs
> Throughput 1468.92 MB/sec 128 procs
> Throughput 1525.35 MB/sec 256 procs
> Throughput 1713.54 MB/sec 512 procs
>
> I'm wondering if this could cause problems on a big box doing something
> like say mysql queries of a local database, blasting retrieved data out
> over industrial strength copper/glass or such. My desktop box surely
> won't notice, but it seems heavy lifters might. I saw the reason for
> it, but I was left wondering why we used to care about it, but no more,
> so here I am to see if I can get my curiosity spot scratched.
>
> I'll sorta miss good ole tbench in scheduler litmus test role. On the
> bright side, localhost based scalability reports are history. Oh wait.
Sure, this patch re-introduces the dst->__refcnt false sharing for
loopback.
Hopefully, with current kernels it's not an issue, because each cpu gets
a different dst.
(It would be an issue if the connect() calls are all done on a single
cpu, than traffic handled on other cpus)
So please try tbench on linux-3.8 or current git tree ;)
^ permalink raw reply
* Re: [PATCH net] tcp: Don't collapse if resulting skb could overflow skb->csum_start
From: Eric Dumazet @ 2013-02-28 16:18 UTC (permalink / raw)
To: Thomas Graf; +Cc: davem, netdev, foraker1
In-Reply-To: <20130228102603.GA7558@casper.infradead.org>
On Thu, 2013-02-28 at 10:26 +0000, Thomas Graf wrote:
> If a TCP retransmission gets partially ACKed and collapsed multiple
> times it is possible for the headroom to grow beyond 64K which will
> overflow the 16bit skb->csum_start which is based on the start of
> the headroom. It has been observed rarely in the wild with IPoIB due
> to the 64K MTU.
>
> With this patch, the overflow has not been observed for over a week
> while previously it would occur within ~ 1 day.
>
> A big thank you to Jim Foraker <foraker1@llnl.gov> and the team at
> LLNL for helping out with the investigation and testing.
>
> Reported-by: Jim Foraker <foraker1@llnl.gov>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> ---
> net/ipv4/tcp_output.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index e2b4461..1902fee 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -2305,6 +2305,12 @@ static void tcp_retrans_try_collapse(struct sock *sk, struct sk_buff *to,
> if (after(TCP_SKB_CB(skb)->end_seq, tcp_wnd_end(tp)))
> break;
>
> + /* Never collapse if the resulting headroom + data exceeds
> + * 64K as that is the maximum csum_start can cover.
> + */
> + if (skb_headroom(to) + to->len + skb->len > 0xFFFF)
> + break;
> +
> tcp_collapse_retrans(sk, to);
> }
> }
but.... what is the value of skb_availroom(to) ?
The earlier test at line 2302 should already guard this case ?
/* Punt if not enough space exists in the first SKB for
* the data in the second
*/
if (skb->len > skb_availroom(to))
break;
^ permalink raw reply
* [PATCH iproute 0/3] Bridge VLAN support
From: Vlad Yasevich @ 2013-02-28 16:21 UTC (permalink / raw)
To: netdev; +Cc: shemminger
This series adds VLAN configuration to the bridge command. With this
series, one can specify vlans in FDB entries as well as to configure
VLAN configuration on the bridge ports.
Vlad Yasevich (3):
bridge: Add vlan support to fdb entries
bridge: Add vlan configuration support
bridge: Update bridge man pages to include vlan command
bridge/Makefile | 2 +-
bridge/br_common.h | 1 +
bridge/bridge.c | 3 +-
bridge/fdb.c | 16 +++-
bridge/vlan.c | 220 +++++++++++++++++++++++++++++++++++++++++++++
include/libnetlink.h | 2 +
include/linux/if_bridge.h | 10 ++
include/linux/neighbour.h | 1 +
include/linux/rtnetlink.h | 1 +
lib/libnetlink.c | 28 ++++++-
man/man8/bridge.8 | 73 +++++++++++++++-
11 files changed, 352 insertions(+), 5 deletions(-)
create mode 100644 bridge/vlan.c
--
1.7.7.6
^ permalink raw reply
* [PATCH iproute 1/3] bridge: Add vlan support to fdb entries
From: Vlad Yasevich @ 2013-02-28 16:21 UTC (permalink / raw)
To: netdev; +Cc: shemminger
In-Reply-To: <1362068514-10342-1-git-send-email-vyasevic@redhat.com>
Provide the ability to set and show vlans on FDB entries.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
---
bridge/fdb.c | 16 +++++++++++++++-
include/linux/neighbour.h | 1 +
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/bridge/fdb.c b/bridge/fdb.c
index 4ca4861..447045e 100644
--- a/bridge/fdb.c
+++ b/bridge/fdb.c
@@ -29,7 +29,7 @@ int filter_index;
static void usage(void)
{
- fprintf(stderr, "Usage: bridge fdb { add | del } ADDR dev DEV {self|master} [ temp ] [ dst IPADDR]\n");
+ fprintf(stderr, "Usage: bridge fdb { add | del } ADDR dev DEV {self|master} [ temp ] [ dst IPADDR] [ vlan VID ]\n");
fprintf(stderr, " bridge fdb {show} [ dev DEV ]\n");
exit(-1);
}
@@ -107,6 +107,11 @@ int print_fdb(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
abuf, sizeof(abuf)));
}
+ if (tb[NDA_VLAN]) {
+ __u16 vid = rta_getattr_u16(tb[NDA_VLAN]);
+ fprintf(fp, "vlan %hu ", vid);
+ }
+
if (show_stats && tb[NDA_CACHEINFO]) {
struct nda_cacheinfo *ci = RTA_DATA(tb[NDA_CACHEINFO]);
int hz = get_user_hz();
@@ -171,6 +176,7 @@ static int fdb_modify(int cmd, int flags, int argc, char **argv)
char abuf[ETH_ALEN];
int dst_ok = 0;
inet_prefix dst;
+ short vid = -1;
memset(&req, 0, sizeof(req));
@@ -199,6 +205,11 @@ static int fdb_modify(int cmd, int flags, int argc, char **argv)
req.ndm.ndm_state |= NUD_PERMANENT;
} else if (matches(*argv, "temp") == 0) {
req.ndm.ndm_state |= NUD_REACHABLE;
+ } else if (matches(*argv, "vlan") == 0) {
+ if (vid >= 0)
+ duparg2("vlan", *argv);
+ NEXT_ARG();
+ vid = atoi(*argv);
} else {
if (strcmp(*argv, "to") == 0) {
NEXT_ARG();
@@ -236,6 +247,9 @@ static int fdb_modify(int cmd, int flags, int argc, char **argv)
if (dst_ok)
addattr_l(&req.n, sizeof(req), NDA_DST, &dst.data, dst.bytelen);
+ if (vid >= 0)
+ addattr16(&req.n, sizeof(req), NDA_VLAN, vid);
+
req.ndm.ndm_ifindex = ll_name_to_index(d);
if (req.ndm.ndm_ifindex == 0) {
fprintf(stderr, "Cannot find device \"%s\"\n", d);
diff --git a/include/linux/neighbour.h b/include/linux/neighbour.h
index 275e5d6..adb068c 100644
--- a/include/linux/neighbour.h
+++ b/include/linux/neighbour.h
@@ -20,6 +20,7 @@ enum {
NDA_LLADDR,
NDA_CACHEINFO,
NDA_PROBES,
+ NDA_VLAN,
__NDA_MAX
};
--
1.7.7.6
^ permalink raw reply related
* [PATCH iproute 2/3] bridge: Add vlan configuration support
From: Vlad Yasevich @ 2013-02-28 16:21 UTC (permalink / raw)
To: netdev; +Cc: shemminger
In-Reply-To: <1362068514-10342-1-git-send-email-vyasevic@redhat.com>
Recent kernel patches added support for VLAN filtering on the bridge.
This functionality allows one to turn a basic bridge into a VLAN bridge,
where VLANs dicatate packet forwarding and header transformation.
To configure the VLANs on the bridge and its ports a new command is
added to the 'bridge' utility.
# bridge vlan add dev eth0 vid 10 pvid untagged brdev
# bridge vlan add
# bridge vlan delete dev eth0 vid 10
# bridge vlan show
This command supports the following flags:
master - peform the operation on the software bridge device. This is
the default behavior.
self - perform the operation on the hardware associated with the port.
This flag is required when the device is the bridge device and
the configuration is desired on the bridge device itself (not
one of the ports).
pvid - Set the PVID (port vlan id) for a given port. Any untagged
frames arriving on the port will be assigned to this vlan.
untagged - Sets the egress policy of for a given vlan. Default port
egress policy is tagged. Set this flag if you wish traffic
associated with this VLAN to exit the port untagged.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
---
bridge/Makefile | 2 +-
bridge/br_common.h | 1 +
bridge/bridge.c | 3 +-
bridge/vlan.c | 220 +++++++++++++++++++++++++++++++++++++++++++++
include/libnetlink.h | 2 +
include/linux/if_bridge.h | 10 ++
include/linux/rtnetlink.h | 1 +
lib/libnetlink.c | 28 ++++++-
8 files changed, 264 insertions(+), 3 deletions(-)
create mode 100644 bridge/vlan.c
diff --git a/bridge/Makefile b/bridge/Makefile
index 67aceb4..1fb8320 100644
--- a/bridge/Makefile
+++ b/bridge/Makefile
@@ -1,4 +1,4 @@
-BROBJ = bridge.o fdb.o monitor.o link.o mdb.o
+BROBJ = bridge.o fdb.o monitor.o link.o mdb.o vlan.o
include ../Config
diff --git a/bridge/br_common.h b/bridge/br_common.h
index 10f6ce9..8764563 100644
--- a/bridge/br_common.h
+++ b/bridge/br_common.h
@@ -9,6 +9,7 @@ extern int print_mdb(const struct sockaddr_nl *who,
extern int do_fdb(int argc, char **argv);
extern int do_mdb(int argc, char **argv);
extern int do_monitor(int argc, char **argv);
+extern int do_vlan(int argc, char **argv);
extern int preferred_family;
extern int show_stats;
diff --git a/bridge/bridge.c b/bridge/bridge.c
index 1d59a1e..06b7a54 100644
--- a/bridge/bridge.c
+++ b/bridge/bridge.c
@@ -27,7 +27,7 @@ static void usage(void)
{
fprintf(stderr,
"Usage: bridge [ OPTIONS ] OBJECT { COMMAND | help }\n"
-"where OBJECT := { fdb | mdb | monitor }\n"
+"where OBJECT := { fdb | mdb | vlan | monitor }\n"
" OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails]\n" );
exit(-1);
}
@@ -44,6 +44,7 @@ static const struct cmd {
} cmds[] = {
{ "fdb", do_fdb },
{ "mdb", do_mdb },
+ { "vlan", do_vlan },
{ "monitor", do_monitor },
{ "help", do_help },
{ 0 }
diff --git a/bridge/vlan.c b/bridge/vlan.c
new file mode 100644
index 0000000..83c4088
--- /dev/null
+++ b/bridge/vlan.c
@@ -0,0 +1,220 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <fcntl.h>
+#include <sys/socket.h>
+#include <net/if.h>
+#include <netinet/in.h>
+#include <linux/if_bridge.h>
+#include <linux/if_ether.h>
+#include <string.h>
+
+#include "libnetlink.h"
+#include "br_common.h"
+#include "utils.h"
+
+int filter_index;
+
+static void usage(void)
+{
+ fprintf(stderr, "Usage: bridge vlan { add | del } vid VLAN_ID dev DEV [ pvid] [ untagged ]\n");
+ fprintf(stderr, " [ self ] [ master ]\n");
+ fprintf(stderr, " bridge vlan { show } [ dev DEV ]\n");
+ exit(-1);
+}
+
+static int vlan_modify(int cmd, int argc, char **argv)
+{
+ struct {
+ struct nlmsghdr n;
+ struct ifinfomsg ifm;
+ char buf[1024];
+ } req;
+ char *d = NULL;
+ short vid = -1;
+ struct rtattr *afspec;
+ struct bridge_vlan_info vinfo;
+ unsigned short flags = 0;
+
+ memset(&vinfo, 0, sizeof(vinfo));
+ memset(&req, 0, sizeof(req));
+
+ req.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
+ req.n.nlmsg_flags = NLM_F_REQUEST;
+ req.n.nlmsg_type = cmd;
+ req.ifm.ifi_family = PF_BRIDGE;
+
+ while (argc > 0) {
+ if (strcmp(*argv, "dev") == 0) {
+ NEXT_ARG();
+ d = *argv;
+ } else if (strcmp(*argv, "vid") == 0) {
+ NEXT_ARG();
+ vid = atoi(*argv);
+ } else if (strcmp(*argv, "self") == 0) {
+ flags |= BRIDGE_FLAGS_SELF;
+ } else if (strcmp(*argv, "master") == 0) {
+ flags |= BRIDGE_FLAGS_MASTER;
+ } else if (strcmp(*argv, "pvid") == 0) {
+ vinfo.flags |= BRIDGE_VLAN_INFO_PVID;
+ } else if (strcmp(*argv, "untagged") == 0) {
+ vinfo.flags |= BRIDGE_VLAN_INFO_UNTAGGED;
+ } else {
+ if (matches(*argv, "help") == 0) {
+ NEXT_ARG();
+ }
+ }
+ argc--; argv++;
+ }
+
+ if (d == NULL || vid == -1) {
+ fprintf(stderr, "Device and VLAN ID are required arguments.\n");
+ exit(-1);
+ }
+
+ req.ifm.ifi_index = ll_name_to_index(d);
+ if (req.ifm.ifi_index == 0) {
+ fprintf(stderr, "Cannot find bridge device \"%s\"\n", d);
+ return -1;
+ }
+
+ if (vid >= 4096) {
+ fprintf(stderr, "Invalid VLAN ID \"%hu\"\n", vid);
+ return -1;
+ }
+
+ vinfo.vid = vid;
+
+ afspec = addattr_nest(&req.n, sizeof(req), IFLA_AF_SPEC);
+
+ if (flags)
+ addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
+
+ addattr_l(&req.n, sizeof(req), IFLA_BRIDGE_VLAN_INFO, &vinfo,
+ sizeof(vinfo));
+
+ addattr_nest_end(&req.n, afspec);
+
+ if (rtnl_talk(&rth, &req.n, 0, 0, NULL) < 0)
+ exit(2);
+
+ return 0;
+}
+
+static int print_vlan(const struct sockaddr_nl *who,
+ struct nlmsghdr *n,
+ void *arg)
+{
+ FILE *fp = arg;
+ struct ifinfomsg *ifm = NLMSG_DATA(n);
+ int len = n->nlmsg_len;
+ struct rtattr * tb[IFLA_MAX+1];
+
+ if (n->nlmsg_type != RTM_NEWLINK) {
+ fprintf(stderr, "Not RTM_NEWLINK: %08x %08x %08x\n",
+ n->nlmsg_len, n->nlmsg_type, n->nlmsg_flags);
+ return 0;
+ }
+
+ len -= NLMSG_LENGTH(sizeof(*ifm));
+ if (len < 0) {
+ fprintf(stderr, "BUG: wrong nlmsg len %d\n", len);
+ return -1;
+ }
+
+ if (ifm->ifi_family != AF_BRIDGE)
+ return 0;
+
+ if (filter_index && filter_index != ifm->ifi_index)
+ return 0;
+
+ parse_rtattr(tb, IFLA_MAX, IFLA_RTA(ifm), len);
+
+ /* if AF_SPEC isn't there, vlan table is not preset for this port */
+ if (!tb[IFLA_AF_SPEC]) {
+ fprintf(fp, "%s\tNone\n", ll_index_to_name(ifm->ifi_index));
+ return 0;
+ } else {
+ struct rtattr *i, *list = tb[IFLA_AF_SPEC];
+ int rem = RTA_PAYLOAD(list);
+
+ fprintf(fp, "%s", ll_index_to_name(ifm->ifi_index));
+ for (i = RTA_DATA(list); RTA_OK(i, rem); i = RTA_NEXT(i, rem)) {
+ struct bridge_vlan_info *vinfo;
+
+ if (i->rta_type != IFLA_BRIDGE_VLAN_INFO)
+ continue;
+
+ vinfo = RTA_DATA(i);
+ fprintf(fp, "\t %hu", vinfo->vid);
+ if (vinfo->flags & BRIDGE_VLAN_INFO_PVID)
+ fprintf(fp, " PVID");
+ if (vinfo->flags & BRIDGE_VLAN_INFO_UNTAGGED)
+ fprintf(fp, " Egress Untagged");
+ fprintf(fp, "\n");
+ }
+ }
+ fprintf(fp, "\n");
+ fflush(fp);
+ return 0;
+}
+
+static int vlan_show(int argc, char **argv)
+{
+ char *filter_dev = NULL;
+
+ while (argc > 0) {
+ if (strcmp(*argv, "dev") == 0) {
+ NEXT_ARG();
+ if (filter_dev)
+ duparg("dev", *argv);
+ filter_dev = *argv;
+ }
+ argc--; argv++;
+ }
+
+ if (filter_dev) {
+ if ((filter_index = if_nametoindex(filter_dev)) == 0) {
+ fprintf(stderr, "Cannot find device \"%s\"\n",
+ filter_dev);
+ return -1;
+ }
+ }
+
+ if (rtnl_wilddump_req_filter(&rth, PF_BRIDGE, RTM_GETLINK,
+ RTEXT_FILTER_BRVLAN) < 0) {
+ perror("Cannont send dump request");
+ exit(1);
+ }
+
+ printf("port\tvlan ids\n");
+ if (rtnl_dump_filter(&rth, print_vlan, stdout) < 0) {
+ fprintf(stderr, "Dump ternminated\n");
+ exit(1);
+ }
+
+ return 0;
+}
+
+
+int do_vlan(int argc, char **argv)
+{
+ ll_init_map(&rth);
+
+ if (argc > 0) {
+ if (matches(*argv, "add") == 0)
+ return vlan_modify(RTM_SETLINK, argc-1, argv+1);
+ if (matches(*argv, "delete") == 0)
+ return vlan_modify(RTM_DELLINK, argc-1, argv+1);
+ if (matches(*argv, "show") == 0 ||
+ matches(*argv, "lst") == 0 ||
+ matches(*argv, "list") == 0)
+ return vlan_show(argc-1, argv+1);
+ if (matches(*argv, "help") == 0)
+ usage();
+ } else
+ return vlan_show(0, NULL);
+
+ fprintf(stderr, "Command \"%s\" is unknown, try \"bridge fdb help\".\n", *argv);
+ exit(-1);
+}
diff --git a/include/libnetlink.h b/include/libnetlink.h
index 41e6ed1..8d15ee5 100644
--- a/include/libnetlink.h
+++ b/include/libnetlink.h
@@ -26,6 +26,8 @@ extern int rtnl_open(struct rtnl_handle *rth, unsigned subscriptions);
extern int rtnl_open_byproto(struct rtnl_handle *rth, unsigned subscriptions, int protocol);
extern void rtnl_close(struct rtnl_handle *rth);
extern int rtnl_wilddump_request(struct rtnl_handle *rth, int fam, int type);
+extern int rtnl_wilddump_req_filter(struct rtnl_handle *rth, int fam, int type,
+ __u32 filt_mask);
extern int rtnl_dump_request(struct rtnl_handle *rth, int type, void *req, int len);
typedef int (*rtnl_filter_t)(const struct sockaddr_nl *,
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index aac8b8c..7a44a27 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -113,10 +113,20 @@ struct __fdb_entry {
enum {
IFLA_BRIDGE_FLAGS,
IFLA_BRIDGE_MODE,
+ IFLA_BRIDGE_VLAN_INFO,
__IFLA_BRIDGE_MAX,
};
#define IFLA_BRIDGE_MAX (__IFLA_BRIDGE_MAX - 1)
+#define BRIDGE_VLAN_INFO_MASTER (1<<0)
+#define BRIDGE_VLAN_INFO_PVID (1<<1)
+#define BRIDGE_VLAN_INFO_UNTAGGED (1<<2)
+
+struct bridge_vlan_info {
+ __u16 flags;
+ __u16 vid;
+};
+
/* Bridge multicast database attributes
* [MDBA_MDB] = {
* [MDBA_MDB_ENTRY] = {
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index 87452b4..93370bd 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -628,6 +628,7 @@ struct tcamsg {
/* New extended info filters for IFLA_EXT_MASK */
#define RTEXT_FILTER_VF (1 << 0)
+#define RTEXT_FILTER_BRVLAN (1 << 1)
/* End of information exported to user level */
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 8e8c8b9..77b7128 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -109,7 +109,33 @@ int rtnl_wilddump_request(struct rtnl_handle *rth, int family, int type)
req.ext_req.rta_type = IFLA_EXT_MASK;
req.ext_req.rta_len = RTA_LENGTH(sizeof(__u32));
- req.ext_filter_mask = RTEXT_FILTER_VF;
+ req.ext_filter_mask = RTEXT_FILTER_VF | RTEXT_FILTER_BRVLAN;
+
+ return send(rth->fd, (void*)&req, sizeof(req), 0);
+}
+
+int rtnl_wilddump_req_filter(struct rtnl_handle *rth, int family, int type,
+ __u32 filt_mask)
+{
+ struct {
+ struct nlmsghdr nlh;
+ struct rtgenmsg g;
+ __u16 align_rta; /* attribute has to be 32bit aligned */
+ struct rtattr ext_req;
+ __u32 ext_filter_mask;
+ } req;
+
+ memset(&req, 0, sizeof(req));
+ req.nlh.nlmsg_len = sizeof(req);
+ req.nlh.nlmsg_type = type;
+ req.nlh.nlmsg_flags = NLM_F_DUMP|NLM_F_REQUEST;
+ req.nlh.nlmsg_pid = 0;
+ req.nlh.nlmsg_seq = rth->dump = ++rth->seq;
+ req.g.rtgen_family = family;
+
+ req.ext_req.rta_type = IFLA_EXT_MASK;
+ req.ext_req.rta_len = RTA_LENGTH(sizeof(__u32));
+ req.ext_filter_mask = filt_mask;
return send(rth->fd, (void*)&req, sizeof(req), 0);
}
--
1.7.7.6
^ permalink raw reply related
* [PATCH iproute 3/3] bridge: Update bridge man pages to include vlan command
From: Vlad Yasevich @ 2013-02-28 16:21 UTC (permalink / raw)
To: netdev; +Cc: shemminger
In-Reply-To: <1362068514-10342-1-git-send-email-vyasevic@redhat.com>
Add the vlan command documentation to bridge man page.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
---
man/man8/bridge.8 | 73 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 72 insertions(+), 1 deletions(-)
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index fd91618..d34e3cf 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -13,7 +13,7 @@ bridge \- show / manipulate bridge addresses and devices
.ti -8
.IR OBJECT " := { "
-.BR fdb " | " monitor " }"
+.BR fdb " | " vlan " | " monitor " }"
.sp
.ti -8
@@ -35,6 +35,20 @@ bridge \- show / manipulate bridge addresses and devices
.IR DEV " ]"
.ti -8
+.BR "bridge vlan" " { " add " | " del " } "
+.B dev
+.IR DEV
+.B vid
+.IR VID " [ "
+.BR pvid " ] [ " untagged " ] [ "
+.BR self " ] [ " master " ] "
+
+.ti -8
+.BR "bridge vlan" " [ " show " ] [ "
+.B dev
+.IR DEV " ]"
+
+.ti -8
.BR "bridge monitor" " [ " all " | " neigh " | " link " ]"
.SH OPTIONS
@@ -61,6 +75,10 @@ As a rule, the information is statistics or some time values.
.B fdb
- Forwarding Database entry.
+.TP
+.B vlan
+- VLAN filter list.
+
.SS
.I COMMAND
@@ -143,6 +161,59 @@ With the
option, the command becomes verbose. It prints out the last updated
and last used time for each entry.
+.SH bridge vlan - VLAN filter list
+
+.B vlan
+objects contain known VLAN IDs for a link.
+
+.P
+The corresponding commands display vlan filter entries, add new entries,
+and delete old ones.
+
+.SS bridge vlan add - add a new vlan filter entry
+
+This command creates a new vlan filter entry.
+
+.TP
+.BI dev " NAME"
+the interface with which this vlan is associated.
+
+.TP
+.BI vid " VID"
+the VLAN ID that identifies the vlan.
+
+.TP
+.BI pvid
+the vlan specified is to be considered a PVID at ingress.
+Any untagged frames will be assigned to this VLAN.
+
+.TP
+.BI untagged
+the vlan specified is to be treated as untagged on egress.
+
+.TP
+.BI self
+the vlan is configured on the specified physical device. Required if the
+device is the bridge device.
+
+.TP
+.BI master
+the vlan is configured on the sofware bridge (default).
+
+.SS bridge vlan delete - delete a forwarding database entry
+This command removes an existing fdb entry.
+
+.PP
+The arguments are the same as with
+.BR "bridge vlan add".
+The
+.BR "pvid " and " untagged"
+flags are ignored.
+
+.SS bridge vlan show - list vlan configuration.
+
+This command displays the current VLAN filter table.
+
.SH bridge monitor - state monitoring
The
--
1.7.7.6
^ permalink raw reply related
* Fw: [Bug 54021] No internet with kernel 3.7 or 3.8 with LAN
From: Stephen Hemminger @ 2013-02-28 16:42 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Wed, 27 Feb 2013 11:39:28 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 54021] No internet with kernel 3.7 or 3.8 with LAN
https://bugzilla.kernel.org/show_bug.cgi?id=54021
Otamay <Matt.Pikaflash@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |Matt.Pikaflash@gmail.com
--- Comment #11 from Otamay <Matt.Pikaflash@gmail.com> 2013-02-27 19:38:48 ---
I have the same problem, with a similar ethernet controller, an Atheros AR8152
v2.0 (same module, atl1c)
rchavez-iron rchavez # lspci -d 1969:2062
02:00.0 Ethernet controller: Atheros Communications Inc. AR8152 v2.0 Fast
Ethernet (rev c1)
Kernel problems:
3.6.11 does works
3.7.0 does not work
3.7.2 does not work
3.7.3 does not work
3.8.0 does not work
I've reverted all linux/drivers/net/ethernet/atheros/atl1c/* files from 3.7.0
kernel to 3.6.11 and didn't work. I think this could be related to the
networking regressions from 3.7 .
Related problem:
http://forums.gentoo.org/viewtopic-t-949168-highlight-.html
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH net] tcp: Don't collapse if resulting skb could overflow skb->csum_start
From: Thomas Graf @ 2013-02-28 16:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, foraker1
In-Reply-To: <1362068326.15793.33.camel@edumazet-glaptop>
On 02/28/13 at 08:18am, Eric Dumazet wrote:
> but.... what is the value of skb_availroom(to) ?
>
> The earlier test at line 2302 should already guard this case ?
>
> /* Punt if not enough space exists in the first SKB for
> * the data in the second
> */
> if (skb->len > skb_availroom(to))
> break;
Only if it is guaranteed that we never see an MSS > 64K.
Assuming that is true forever, then a21d45726 (tcp: avoid order-1
allocations on wifi and tx path) does in fact resolve this
issue at the cost of not being able to use the extra room
kmalloc() might have given us in __alloc_skb() for collapsing.
Was that an intentional side effect of a21d45726?
^ permalink raw reply
* [PATCH] bgmac: omit the fcs
From: Hauke Mehrtens @ 2013-02-28 17:16 UTC (permalink / raw)
To: davem; +Cc: zajec5, netdev, Hauke Mehrtens
Do not include the frame check sequence when adding the skb to
netif_receive_skb(). This causes problems when this interface was
bridged to a wifi ap and a big package should be forwarded from this
Ethernet driver through a bride to the wifi client.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/net/ethernet/broadcom/bgmac.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index bf985c0..bce30e7 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -301,12 +301,16 @@ static int bgmac_dma_rx_read(struct bgmac *bgmac, struct bgmac_dma_ring *ring,
bgmac_err(bgmac, "Found poisoned packet at slot %d, DMA issue!\n",
ring->start);
} else {
+ /* Omit CRC. */
+ len -= ETH_FCS_LEN;
+
new_skb = netdev_alloc_skb_ip_align(bgmac->net_dev, len);
if (new_skb) {
skb_put(new_skb, len);
skb_copy_from_linear_data_offset(skb, BGMAC_RX_FRAME_OFFSET,
new_skb->data,
len);
+ skb_checksum_none_assert(skb);
new_skb->protocol =
eth_type_trans(new_skb, bgmac->net_dev);
netif_receive_skb(new_skb);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH net] tcp: Don't collapse if resulting skb could overflow skb->csum_start
From: Eric Dumazet @ 2013-02-28 17:35 UTC (permalink / raw)
To: Thomas Graf; +Cc: davem, netdev, foraker1
In-Reply-To: <20130228164502.GD7558@casper.infradead.org>
On Thu, 2013-02-28 at 16:45 +0000, Thomas Graf wrote:
> On 02/28/13 at 08:18am, Eric Dumazet wrote:
> > but.... what is the value of skb_availroom(to) ?
> >
> > The earlier test at line 2302 should already guard this case ?
> >
> > /* Punt if not enough space exists in the first SKB for
> > * the data in the second
> > */
> > if (skb->len > skb_availroom(to))
> > break;
>
> Only if it is guaranteed that we never see an MSS > 64K.
>
> Assuming that is true forever, then a21d45726 (tcp: avoid order-1
> allocations on wifi and tx path) does in fact resolve this
> issue at the cost of not being able to use the extra room
> kmalloc() might have given us in __alloc_skb() for collapsing.
>
> Was that an intentional side effect of a21d45726?
This had a followup with 22b4a4f22da4
(tcp: fix retransmit of partially acked frames)
I also wonder if there is not another similar potential problem in
__tcp_retransmit_skb) after call to
tcp_trim_head(sk, skb, tp->snd_una - TCP_SKB_CB(skb)->seq)
csum_start can overflow again because of MAX_TCP_HEADER headroom
reserve.
So maybe we should limit TCP MTU to (64K - MAX_TCP_HEADER)
^ permalink raw reply
* Re: [PATCH net] tcp: Don't collapse if resulting skb could overflow skb->csum_start
From: Eric Dumazet @ 2013-02-28 17:40 UTC (permalink / raw)
To: Thomas Graf; +Cc: davem, netdev, foraker1
In-Reply-To: <1362072952.15793.41.camel@edumazet-glaptop>
On Thu, 2013-02-28 at 09:35 -0800, Eric Dumazet wrote:
> On Thu, 2013-02-28 at 16:45 +0000, Thomas Graf wrote:
> > On 02/28/13 at 08:18am, Eric Dumazet wrote:
> > > but.... what is the value of skb_availroom(to) ?
> > >
> > > The earlier test at line 2302 should already guard this case ?
> > >
> > > /* Punt if not enough space exists in the first SKB for
> > > * the data in the second
> > > */
> > > if (skb->len > skb_availroom(to))
> > > break;
> >
> > Only if it is guaranteed that we never see an MSS > 64K.
> >
> > Assuming that is true forever, then a21d45726 (tcp: avoid order-1
> > allocations on wifi and tx path) does in fact resolve this
> > issue at the cost of not being able to use the extra room
> > kmalloc() might have given us in __alloc_skb() for collapsing.
> >
> > Was that an intentional side effect of a21d45726?
>
> This had a followup with 22b4a4f22da4
> (tcp: fix retransmit of partially acked frames)
>
> I also wonder if there is not another similar potential problem in
> __tcp_retransmit_skb) after call to
>
> tcp_trim_head(sk, skb, tp->snd_una - TCP_SKB_CB(skb)->seq)
>
> csum_start can overflow again because of MAX_TCP_HEADER headroom
> reserve.
>
> So maybe we should limit TCP MTU to (64K - MAX_TCP_HEADER)
>
Or adapt the test at line 2390 in net/ipv4/tcp_output.c
to force in the case there could be an overflow a :
struct sk_buff *nskb = __pskb_copy()
So that we have a new skb with minimal headroom.
^ permalink raw reply
* Re: [PATCH] bgmac: omit the fcs
From: Rafał Miłecki @ 2013-02-28 17:57 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: davem, netdev
In-Reply-To: <1362071814-12822-1-git-send-email-hauke@hauke-m.de>
2013/2/28 Hauke Mehrtens <hauke@hauke-m.de>:
> Do not include the frame check sequence when adding the skb to
> netif_receive_skb(). This causes problems when this interface was
> bridged to a wifi ap and a big package should be forwarded from this
> Ethernet driver through a bride to the wifi client.
Is this a real fix?
Don't get me wrong, but it sounds a little like a workaround for some
issue in another network layer ;)
--
Rafał
^ permalink raw reply
* Re: [PATCH v6 04/46] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Oleg Nesterov @ 2013-02-28 18:00 UTC (permalink / raw)
To: Michel Lespinasse
Cc: Srivatsa S. Bhat, Lai Jiangshan, linux-doc, peterz, fweisbec,
linux-kernel, namhyung, mingo, linux-arch, linux, xiaoguangrong,
wangyun, paulmck, nikunj, linux-pm, rusty, rostedt, rjw,
vincent.guittot, tglx, linux-arm-kernel, netdev, sbw, tj, akpm,
linuxppc-dev
In-Reply-To: <CANN689EhqoQAKALR7WhT3YrQh3=VDA2Dq3QX1yLuYU_gZAo_Tg@mail.gmail.com>
On 02/28, Michel Lespinasse wrote:
>
> On Thu, Feb 28, 2013 at 3:25 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> > On 02/27, Michel Lespinasse wrote:
> >>
> >> +void lg_rwlock_local_read_lock(struct lgrwlock *lgrw)
> >> +{
> >> + preempt_disable();
> >> +
> >> + if (__this_cpu_read(*lgrw->local_refcnt) ||
> >> + arch_spin_trylock(this_cpu_ptr(lgrw->lglock->lock))) {
> >> + __this_cpu_inc(*lgrw->local_refcnt);
> >
> > Please look at __this_cpu_generic_to_op(). You need this_cpu_inc()
> > to avoid the race with irs. The same for _read_unlock.
>
> Hmmm, I was thinking that this was safe because while interrupts might
> modify local_refcnt to acquire a nested read lock, they are expected
> to release that lock as well which would set local_refcnt back to its
> original value ???
Yes, yes, this is correct.
I meant that (in general, x86 is fine) __this_cpu_inc() itself is not
irq-safe. It simply does "pcp += 1".
this_cpu_inc() is fine, _this_cpu_generic_to_op() does cli/sti around.
I know this only because I did the same mistake recently, and Srivatsa
explained the problem to me ;)
Oleg.
^ permalink raw reply
* Re: [PATCH] bgmac: omit the fcs
From: Hauke Mehrtens @ 2013-02-28 18:13 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: davem, netdev
In-Reply-To: <CACna6rw6MR3agrDvz0+X7ne6uSNQN0tpZupeM5c-6xy5-pvv2Q@mail.gmail.com>
On 02/28/2013 06:57 PM, Rafał Miłecki wrote:
> 2013/2/28 Hauke Mehrtens <hauke@hauke-m.de>:
>> Do not include the frame check sequence when adding the skb to
>> netif_receive_skb(). This causes problems when this interface was
>> bridged to a wifi ap and a big package should be forwarded from this
>> Ethernet driver through a bride to the wifi client.
>
> Is this a real fix?
>
> Don't get me wrong, but it sounds a little like a workaround for some
> issue in another network layer ;)
>
Many drivers are doing similar things, b44 is one of them. Hopefully
someone more familiar with the network stack could say if this is the
right way to do this.
On a wireless client I saw that all packages directly from my router did
not had a FCS, but all the packages send from an other LAN client which
went through this driver had a FCS and where 4 bytes bigger and this FCS
was wrong.
Hauke
^ 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