* Re: shutdown(3) and bluetooth.
From: John W. Linville @ 2013-11-13 14:02 UTC (permalink / raw)
To: David Miller; +Cc: davej, netdev, linux-bluetooth, linux-wireless
In-Reply-To: <20131112.161350.946584501122269943.davem@davemloft.net>
On Tue, Nov 12, 2013 at 04:13:50PM -0500, David Miller wrote:
> From: Dave Jones <davej@redhat.com>
> Date: Tue, 12 Nov 2013 16:11:25 -0500
>
> > Is shutdown() allowed to block indefinitely ? The man page doesn't say either way,
> > and I've noticed that my fuzz tester occasionally hangs for days spinning in bt_sock_wait_state()
> >
> > Is there something I should be doing to guarantee that this operation
> > will either time out, or return instantly ?
> >
> > In this specific case, I doubt anything is on the "sender" end of the socket, so
> > it's going to be waiting forever for a state change that won't arrive.
>
> Adding bluetooth and wireless lists. Dave, please consult MAINTAINERS when
> asking questions like this, thanks!
I don't have an authoritative answer. I do, however, seem to recall
that trying to shutdown a SunOS box with a hung NFS mount would seem
to hang forever. I don't think that is a great metric for how we
should behave, of course...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH iproute2 v2] ss: avoid passing negative numbers to malloc
From: Eric Dumazet @ 2013-11-13 14:16 UTC (permalink / raw)
To: Andreas Henriksson; +Cc: stephen, netdev
In-Reply-To: <20131113084642.GA23572@amd64.fatal.se>
On Wed, 2013-11-13 at 09:46 +0100, Andreas Henriksson wrote:
> Example:
>
> $ ss state established \( sport = :4060 or sport = :4061 or sport = :4062 or sport = :4063 or sport = :4064 or sport = :4065 or sport = :4066 or sport = :4067 \) > /dev/null
> Aborted
>
> In the example above ssfilter_bytecompile(...) will return (int)136.
> char l1 = 136; means -120 which will result in a negative number
> being passed to malloc at misc/ss.c:913.
>
> Simply declare l1 and l2 as integers to avoid the char overflow.
>
> This is one of the issues originally reported in http://bugs.debian.org/511720
>
> Fix the same problem in other code paths as well (thanks to Eric Dumazet).
>
> Reported-by: Andreas Schuldei <andreas@debian.org>
> Signed-off-by: Andreas Henriksson <andreas@fatal.se>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: [PATCH net-next 4/4] virtio-net: auto-tune mergeable rx buffer size for improved performance
From: Eric Dumazet @ 2013-11-13 14:19 UTC (permalink / raw)
To: Ronen Hod
Cc: Michael Dalton, Michael S. Tsirkin, netdev, Daniel Borkmann,
virtualization, Eric Dumazet, David S. Miller
In-Reply-To: <52833C9B.7070908@redhat.com>
On Wed, 2013-11-13 at 10:47 +0200, Ronen Hod wrote:
> I looked at how ewma works, and although it is computationally efficient,
> and it does what it is supposed to do, initially (at the first samples) it is strongly
> biased towards the value that was added at the first ewma_add.
> I suggest that you print the values of ewma_add() and ewma_read(). If you are
> happy with the results, then ignore my comments. If you are not, then I can
> provide a version that does better for the first samples.
> Unfortunately, it will be slightly less efficient.
Value is clamped by (GOOD_PACKET_LEN, PAGE_SIZE - hdr_len)
So initial value is conservative and not really used.
Thanks
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Stefan Priebe - Profihost AG @ 2013-11-13 14:20 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: Linux Netdev List
In-Reply-To: <20131113141244.GM19702@redhat.com>
Hi Falico,
Am 13.11.2013 15:12, schrieb Veaceslav Falico:
> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
> wrote:
>> Hello,
>>
>> while my vlans, bridging and bonding stuff was working until 3.9 i never
>> thought about how it is right. So maybe i was always wrong.
>>
>> I've this:
>>
>> eth2
>> \
>> -- bond1 -- vmbr1
>> /
>> eth3
>>
>> This works fine and as expected now i want to have a vlan using the
>> bonding and using a bridge.
>>
>> I the past i had this:
>> eth2
>> \
>> -- bond1 -- vmbr1
>> / \
>> eth3 \ vmbr1.3000
>> \ ---- tap114i1
>>
>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>> is bad!
>
> As a guess - do you use arp monitoring for bonding? Try using miimon -
> there were some issues with it in 3.10, which were fixed by some huge
> patchsets that will never hit 3.10 stable.
> Also, the bonding configuration would be welcome.
Debian Bonding konfiguration looks like this:
auto bond1
iface bond1 inet manual
slaves eth2 eth3
bond-mode 802.3ad
bond_miimon 100
bond_updelay 200
bond_downdelay 0
This should be miimon using lacp and not arp isn't it?
Anything more needed?
One thing i forgot the one with vmbr1.3000 does not work at all eben not
with promisc mode. The one below works fine if i set eth2 and eth3 into
promisc mode.
Stefan
>> I also tried this one without success:
>> eth2
>> \
>> -- bond1 -- vmbr1
>> / \
>> eth3 ----- bond1.3000 --- vmbr1v3000
>> \ ---- tap114i1
>>
>>
>>
>> Greets,
>> Stefan
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH iproute2] htb: support 64bit rates
From: Eric Dumazet @ 2013-11-13 14:21 UTC (permalink / raw)
To: Yang Yingliang; +Cc: Stephen Hemminger, netdev
In-Reply-To: <52834248.3040103@huawei.com>
On Wed, 2013-11-13 at 17:11 +0800, Yang Yingliang wrote:
> > - if (!buffer) buffer = opt.rate.rate / get_hz() + mtu;
> > - if (!cbuffer) cbuffer = opt.ceil.rate / get_hz() + mtu;
> > + if (!buffer)
> > + buffer = rate64 / get_hz() + mtu;
> > + if (!cbuffer)
> > + cbuffer = ceil64 / get_hz() + mtu;
>
> Hi,
> It may overflow here if rate64 and mtu are big enough.
Not really.
get_hz() on current kernels is really huge : 1000000000
^ permalink raw reply
* Re: [PATCH 1/1] net: sctp: bug fixing when sctp path recovers
From: Vlad Yasevich @ 2013-11-13 14:22 UTC (permalink / raw)
To: Chang, nhorman, davem; +Cc: linux-sctp, netdev, linux-kernel, dreibh
In-Reply-To: <5282E9EC.3090307@gmail.com>
On 11/12/2013 09:54 PM, Chang wrote:
>
> On 11/13/2013 03:37 AM, Vlad Yasevich wrote:
>> On 11/12/2013 08:34 PM, Chang Xiangzhong wrote:
>>> Look for the __two__ most recently used path/transport and set to
>>> active_path
>>> and retran_path respectively
>>>
>>> Signed-off-by: changxiangzhong@gmail.com
>>> ---
>>> net/sctp/associola.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
>>> index ab67efc..070011a 100644
>>> --- a/net/sctp/associola.c
>>> +++ b/net/sctp/associola.c
>>> @@ -913,11 +913,15 @@ void sctp_assoc_control_transport(struct
>>> sctp_association *asoc,
>>> if (!first || t->last_time_heard > first->last_time_heard) {
>>> second = first;
>>> first = t;
>>> + continue;
>>> }
>>> if (!second || t->last_time_heard > second->last_time_heard)
>>> second = t;
>>
>> You might as well remove this bit and then you don't need a continue.
> I don't think we could remove this bit. My understanding of these
> algorithms are to find the 1st recently used path and the 2nd, assigning
> to active_path and retran_path respectively. If we remove the
> looking-for-second block, how are we suppose to find the 2nd?
> I think we can remove the continue and use else-if in the
> 2nd-assignment-block.
Yes, you are right. An if...else block is what we need here.
-vlad
>>
>>> }
>>>
>>> + if (!second)
>>> + second = first;
>>> +
>>
>> This needs to move down 1 more block. Set the second transport after we
>> check to see if the primary is back up and we need to go back to using
>> it.
>>
>> -vlad
>>
> I agree with this change
>>> /* RFC 2960 6.4 Multi-Homed SCTP Endpoints
>>> *
>>> * By default, an endpoint should always transmit to the
>>>
>>
>
^ permalink raw reply
* Re: gso: Handle new frag_list of frags GRO packets
From: Herbert Xu @ 2013-11-13 14:26 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ben Hutchings, David Miller, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <1384310704.28458.79.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Nov 12, 2013 at 06:45:04PM -0800, Eric Dumazet wrote:
> On Wed, 2013-11-13 at 10:25 +0800, Herbert Xu wrote:
>
> > So a better test for the time being would be to test with TSO
> > disabled in both cases.
> >
>
> GRO on, TSO off, little difference between two cases :
>
> (Note some small things run in background, so these numbers are not
> ultra precise)
OK looks pretty sane.
> > In the mean time I'm cooking up a patch to generate TSO packets.
>
> That would be very nice !
It's failing on my machine but I'm not certain whether it's a bug
in my patch or a bug in my NIC's TSO code. So I'd appreciate it
if you can give this a spin on your mlx4.
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 557e1a5..1302515 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2786,6 +2786,8 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
__be16 proto;
bool csum;
int sg = !!(features & NETIF_F_SG);
+ int gso_type = 0;
+ int gso_size = 0;
int nfrags = skb_shinfo(skb)->nr_frags;
int err = -ENOMEM;
int i = 0;
@@ -2795,6 +2797,11 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
if (unlikely(!proto))
return ERR_PTR(-EINVAL);
+ if (net_gso_ok(gso_type, features)) {
+ gso_type = skb_shinfo(skb)->gso_type & ~SKB_GSO_DODGY;
+ gso_size = mss;
+ }
+
csum = !!can_checksum_protocol(features, proto);
__skb_push(skb, doffset);
headroom = skb_headroom(skb);
@@ -2807,7 +2814,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
int size;
len = skb->len - offset;
- if (len > mss)
+ if (!gso_size && len > mss)
len = mss;
hsize = skb_headlen(skb) - offset;
@@ -2819,6 +2826,26 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
if (!hsize && i >= nfrags && skb_headlen(fskb) &&
(skb_headlen(fskb) == len || sg)) {
BUG_ON(skb_headlen(fskb) > len);
+ SKB_FRAG_ASSERT(fskb);
+
+ nskb = skb_clone(fskb, GFP_ATOMIC);
+ if (unlikely(!nskb))
+ goto err;
+
+ if (gso_size) {
+ len = nskb->len;
+ pos += len;
+
+ skb_shinfo(nskb)->gso_segs = len / mss;
+
+ /*
+ * Original GRO packet boundaries must
+ * have been preserved.
+ */
+ BUG_ON(fskb->next && len % mss);
+
+ goto skip_trim;
+ }
i = 0;
nfrags = skb_shinfo(fskb)->nr_frags;
@@ -2837,17 +2864,14 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
skb_frag++;
}
- nskb = skb_clone(fskb, GFP_ATOMIC);
- fskb = fskb->next;
-
- if (unlikely(!nskb))
- goto err;
-
if (unlikely(pskb_trim(nskb, len))) {
kfree_skb(nskb);
goto err;
}
+skip_trim:
+ fskb = fskb->next;
+
hsize = skb_end_offset(nskb);
if (skb_cow_head(nskb, doffset + headroom)) {
kfree_skb(nskb);
@@ -2880,6 +2904,9 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
skb_headers_offset_update(nskb, skb_headroom(nskb) - headroom);
+ skb_shinfo(nskb)->gso_size = gso_size;
+ skb_shinfo(nskb)->gso_type = gso_type;
+
skb_copy_from_linear_data_offset(skb, -tnl_hlen,
nskb->data - tnl_hlen,
doffset + tnl_hlen);
@@ -2902,6 +2929,41 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
skb_shinfo(nskb)->tx_flags = skb_shinfo(skb)->tx_flags & SKBTX_SHARED_FRAG;
+ /*
+ * virtio-net misery:
+ *
+ * Do a trial run for hardware GSO to get the proper length.
+ */
+ if (pos < offset + len && gso_size) {
+ int j;
+
+ len = hsize - (offset - pos);
+
+ for (j = i; j < nfrags; j++)
+ len += skb_frag_size(skb_frag + j);
+
+ if (fskb && !skb_headlen(fskb)) {
+ j = min_t(int,
+ skb_shinfo(fskb)->nr_frags,
+ MAX_SKB_FRAGS - nfrags + i);
+
+ while (--j >= 0)
+ len += skb_frag_size(
+ skb_shinfo(fskb)->frags + j);
+ }
+
+ if (len < mss && offset + len < skb->len)
+ goto too_many_frags;
+
+ skb_shinfo(nskb)->gso_segs = len / mss;
+ if (len % mss) {
+ if (offset + len >= skb->len)
+ skb_shinfo(nskb)->gso_segs++;
+ else
+ len -= len % mss;
+ }
+ }
+
while (pos < offset + len) {
if (i >= nfrags) {
BUG_ON(skb_headlen(fskb));
@@ -2917,6 +2979,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
if (unlikely(skb_shinfo(nskb)->nr_frags >=
MAX_SKB_FRAGS)) {
+too_many_frags:
net_warn_ratelimited(
"skb_segment: too many frags: %u %u\n",
pos, mss);
Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* [PATCH v2] tcp: tsq: restore minimal amount of queueing
From: Eric Dumazet @ 2013-11-13 14:32 UTC (permalink / raw)
To: Arnaud Ebalard
Cc: David Miller, Sujith Manoharan, Cong Wang, netdev, Felix Fietkau
In-Reply-To: <1384267141.28458.24.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
After commit c9eeec26e32e ("tcp: TSQ can use a dynamic limit"), several
users reported throughput regressions, notably on mvneta and wifi
adapters.
802.11 AMPDU requires a fair amount of queueing to be effective.
This patch partially reverts the change done in tcp_write_xmit()
so that the minimal amount is sysctl_tcp_limit_output_bytes.
It also remove the use of this sysctl while building skb stored
in write queue, as TSO autosizing does the right thing anyway.
Users with well behaving NICS and correct qdisc (like sch_fq),
can then lower the default sysctl_tcp_limit_output_bytes value from
128KB to 8KB.
This new usage of sysctl_tcp_limit_output_bytes permits each driver
authors to check how their driver performs when/if the value is set
to a minimum of 4KB.
Normally, line rate for a single TCP flow should be possible,
but some drivers rely on timers to perform TX completion and
too long TX completion delays prevent reaching full throughput.
Fixes: c9eeec26e32e ("tcp: TSQ can use a dynamic limit")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Sujith Manoharan <sujith@msujith.org>
Reported-by: Arnaud Ebalard <arno@natisbad.org>
Tested-by: Sujith Manoharan <sujith@msujith.org>
Cc: Felix Fietkau <nbd@openwrt.org>
---
v2: use a max_t() instead of max() to suppress a compiler warning
Documentation/networking/ip-sysctl.txt | 3 ---
net/ipv4/tcp.c | 6 ------
net/ipv4/tcp_output.c | 6 +++++-
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 8b8a057..3c12d9a 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -577,9 +577,6 @@ tcp_limit_output_bytes - INTEGER
typical pfifo_fast qdiscs.
tcp_limit_output_bytes limits the number of bytes on qdisc
or device to reduce artificial RTT/cwnd and reduce bufferbloat.
- Note: For GSO/TSO enabled flows, we try to have at least two
- packets in flight. Reducing tcp_limit_output_bytes might also
- reduce the size of individual GSO packet (64KB being the max)
Default: 131072
tcp_challenge_ack_limit - INTEGER
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 8e8529d..3dc0c6c 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -808,12 +808,6 @@ static unsigned int tcp_xmit_size_goal(struct sock *sk, u32 mss_now,
xmit_size_goal = min_t(u32, gso_size,
sk->sk_gso_max_size - 1 - hlen);
- /* TSQ : try to have at least two segments in flight
- * (one in NIC TX ring, another in Qdisc)
- */
- xmit_size_goal = min_t(u32, xmit_size_goal,
- sysctl_tcp_limit_output_bytes >> 1);
-
xmit_size_goal = tcp_bound_to_half_wnd(tp, xmit_size_goal);
/* We try hard to avoid divides here */
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 6728546..c5231d9 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1875,8 +1875,12 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
* - better RTT estimation and ACK scheduling
* - faster recovery
* - high rates
+ * Alas, some drivers / subsystems require a fair amount
+ * of queued bytes to ensure line rate.
+ * One example is wifi aggregation (802.11 AMPDU)
*/
- limit = max(skb->truesize, sk->sk_pacing_rate >> 10);
+ limit = max_t(unsigned int, sysctl_tcp_limit_output_bytes,
+ sk->sk_pacing_rate >> 10);
if (atomic_read(&sk->sk_wmem_alloc) > limit) {
set_bit(TSQ_THROTTLED, &tp->tsq_flags);
^ permalink raw reply related
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Veaceslav Falico @ 2013-11-13 14:34 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: Linux Netdev List
In-Reply-To: <52838AC8.8070005@profihost.ag>
On Wed, Nov 13, 2013 at 03:20:56PM +0100, Stefan Priebe - Profihost AG wrote:
>Hi Falico,
>Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>> wrote:
>>> Hello,
>>>
>>> while my vlans, bridging and bonding stuff was working until 3.9 i never
>>> thought about how it is right. So maybe i was always wrong.
>>>
>>> I've this:
>>>
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> /
>>> eth3
>>>
>>> This works fine and as expected now i want to have a vlan using the
>>> bonding and using a bridge.
>>>
>>> I the past i had this:
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 \ vmbr1.3000
>>> \ ---- tap114i1
>>>
>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>> is bad!
>>
>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>> there were some issues with it in 3.10, which were fixed by some huge
>> patchsets that will never hit 3.10 stable.
>> Also, the bonding configuration would be welcome.
>
>Debian Bonding konfiguration looks like this:
>auto bond1
>iface bond1 inet manual
> slaves eth2 eth3
> bond-mode 802.3ad
> bond_miimon 100
> bond_updelay 200
> bond_downdelay 0
>
>This should be miimon using lacp and not arp isn't it?
>Anything more needed?
Yeah, it's miimon, so nothing here...
I'll try to set up a reproducer in the nearest future, a bit burdened now.
Are you using 3.10.X stable? Which version exactly? And at what version did
it work - 3.9.?
Thank you!
>
>One thing i forgot the one with vmbr1.3000 does not work at all eben not
>with promisc mode. The one below works fine if i set eth2 and eth3 into
>promisc mode.
>
>Stefan
>
>>> I also tried this one without success:
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>> \ ---- tap114i1
>>>
>>>
>>>
>>> Greets,
>>> Stefan
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Stefan Priebe - Profihost AG @ 2013-11-13 14:43 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: Linux Netdev List
In-Reply-To: <20131113143410.GN19702@redhat.com>
Am 13.11.2013 15:34, schrieb Veaceslav Falico:
> On Wed, Nov 13, 2013 at 03:20:56PM +0100, Stefan Priebe - Profihost AG
> wrote:
>> Hi Falico,
>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>>> wrote:
>>>> Hello,
>>>>
>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>> never
>>>> thought about how it is right. So maybe i was always wrong.
>>>>
>>>> I've this:
>>>>
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> /
>>>> eth3
>>>>
>>>> This works fine and as expected now i want to have a vlan using the
>>>> bonding and using a bridge.
>>>>
>>>> I the past i had this:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 \ vmbr1.3000
>>>> \ ---- tap114i1
>>>>
>>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>>> is bad!
>>>
>>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>>> there were some issues with it in 3.10, which were fixed by some huge
>>> patchsets that will never hit 3.10 stable.
>>> Also, the bonding configuration would be welcome.
>>
>> Debian Bonding konfiguration looks like this:
>> auto bond1
>> iface bond1 inet manual
>> slaves eth2 eth3
>> bond-mode 802.3ad
>> bond_miimon 100
>> bond_updelay 200
>> bond_downdelay 0
>>
>> This should be miimon using lacp and not arp isn't it?
>> Anything more needed?
>
> Yeah, it's miimon, so nothing here...
>
> I'll try to set up a reproducer in the nearest future, a bit burdened now.
>
> Are you using 3.10.X stable? Which version exactly? And at what version did
> it work - 3.9.?
I'm using 3.10.19 + this patchset from v3.12 (commit
b8bde1c4f94908ce8e3c0434fb369a00e9217497
Merge: 4b6c787 dfb5fa3
Author: David S. Miller <davem@davemloft.net>
Date: Fri Oct 18 16:03:03 2013 -0400
Merge branch 'bridge_pvid'
)
The problem is simply that the network cards and also the bonds do not
seem to know about the bridge on top so they just drop the vlan tagged
packages.
> Thank you!
>
>>
>> One thing i forgot the one with vmbr1.3000 does not work at all eben not
>> with promisc mode. The one below works fine if i set eth2 and eth3 into
>> promisc mode.
>>
>> Stefan
>>
>>>> I also tried this one without success:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>> \ ---- tap114i1
>>>>
>>>>
>>>>
>>>> Greets,
>>>> Stefan
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net RESEND] bonding: add ip checks when store ip target
From: Ding Tianhong @ 2013-11-13 14:35 UTC (permalink / raw)
To: Veaceslav Falico
Cc: Ding Tianhong, Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Netdev
In-Reply-To: <20131113100000.GH19702@redhat.com>
于 2013/11/13 18:00, Veaceslav Falico 写道:
> On Wed, Nov 13, 2013 at 10:19:02AM +0800, Ding Tianhong wrote:
>> I met a Bug when I add ip target with the wrong ip address:
>>
>> echo +500.500.500.500 > /sys/class/net/bond0/bonding/arp_ip_target
>>
>> the wrong ip address will transfor to 245.245.245.244 and add
>> to the ip target success, it is uncorrect, so I add checks to avoid
>> adding wrong address.
>>
>> The in4_pton() will set wrong ip address to 0.0.0.0, it will return by
>> the next check and will not add to ip target.
>>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> ---
>> drivers/net/bonding/bond_sysfs.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/bonding/bond_sysfs.c
>> b/drivers/net/bonding/bond_sysfs.c
>> index ec9b646..e0c97fb 100644
>> --- a/drivers/net/bonding/bond_sysfs.c
>> +++ b/drivers/net/bonding/bond_sysfs.c
>> @@ -653,7 +653,7 @@ static ssize_t bonding_store_arp_targets(struct
>> device *d,
>> int ind, i, j, ret = -EINVAL;
>>
>> targets = bond->params.arp_targets;
>> - newtarget = in_aton(buf + 1);
>> + in4_pton(buf + 1, strlen(buf) - 1, (u8 *)&newtarget, -1, NULL);
>
> No need for strlen(buf)-1, if you specify -1 it will compute it by
> itself.
>
> Also, you might simplify the code a bit in the function. Otherwise -
> looks
> good, thank you.
>
> Untested patch:
>
> diff --git a/drivers/net/bonding/bond_sysfs.c
> b/drivers/net/bonding/bond_sysfs.c
> index c29b836..e3fff6e 100644
> --- a/drivers/net/bonding/bond_sysfs.c
> +++ b/drivers/net/bonding/bond_sysfs.c
> @@ -661,16 +661,16 @@ static ssize_t bonding_store_arp_targets(struct
> device *d,
> unsigned long *targets_rx;
> int ind, i, j, ret = -EINVAL;
>
> + if (!in4_pton(buf + 1, -1, (u8 *)&newtarget, -1, NULL)) {
> + pr_err("%s: invalid ARP target specified, use +<addr> or -<addr>\n",
> + bond->dev->name);
> + goto out;
> + }
> +
> targets = bond->params.arp_targets;
> - newtarget = in_aton(buf + 1);
> +
> /* look for adds */
> if (buf[0] == '+') {
> - if ((newtarget == 0) || (newtarget == htonl(INADDR_BROADCAST))) {
> - pr_err("%s: invalid ARP target %pI4 specified for addition\n",
> - bond->dev->name, &newtarget);
> - goto out;
> - }
> -
> if (bond_get_targets_ip(targets, newtarget) != -1) { /* dup */
> pr_err("%s: ARP target %pI4 is already present\n",
> bond->dev->name, &newtarget);
> @@ -693,12 +693,6 @@ static ssize_t bonding_store_arp_targets(struct
> device *d,
> targets[ind] = newtarget;
> write_unlock_bh(&bond->lock);
> } else if (buf[0] == '-') {
> - if ((newtarget == 0) || (newtarget == htonl(INADDR_BROADCAST))) {
> - pr_err("%s: invalid ARP target %pI4 specified for removal\n",
> - bond->dev->name, &newtarget);
> - goto out;
> - }
> -
> ind = bond_get_targets_ip(targets, newtarget);
> if (ind == -1) {
> pr_err("%s: unable to remove nonexistent ARP target %pI4.\n",
> --
Although there is no substantial changes, but more simple more
beautiful, I'll take it,
resend it later, thanks for your opinion.
Regards
Ding
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: VLAN filtering/VLAN aware bridge problems
From: Vlad Yasevich @ 2013-11-13 14:49 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG, vyasevic; +Cc: David Miller, Linux Netdev List
In-Reply-To: <52832A0B.9030605@profihost.ag>
On 11/13/2013 02:28 AM, Stefan Priebe - Profihost AG wrote:
> Am 13.11.2013 00:25, schrieb Vlad Yasevich:
>> On 11/12/2013 04:31 PM, Stefan Priebe wrote:
>>> sorry for the very late response.
>>>
>>> Am 10.09.2013 16:11, schrieb Vlad Yasevich:
>>>> On 08/30/2013 11:01 AM, Stefan Priebe - Profihost AG wrote:
>>>>> Yes
>>>>>
>>>>
>>>> Can you apply this patch and see if this fixes your problem.
>>>> http://patchwork.ozlabs.org/patch/273841/
>>>>
>>>> In my attempts to reproduce your problem I didn't configuring filtering
>>>> on the upper bridge, but that is what could have been causing
>>>> your problem. I'll attempt it and let you know.
>>>
>>> Even with the complete patchset which was merged upstream it doesn't
>>> work ;-(
>>>
>>> What's wrong there and / or how can i debug?
>>
>> Can you provide the filtering settings for both bridges you use?
>
> I don't filter at all right now it's compiled in but not enabled - but i
> have these problems since these patches were included.
>
> It only start to work if i set the eth0 and eth1 (slaves of the bond) to
> promisc mode. So the problem seems to be that the ethernet devices do
> not accept the VLAN tagged packages.
That doesn't make much sense. If the filtering is not enabled, then
this code isn't in use. It will not try to set any vlan filtering
so you should be running with essentially stock bridge.
Bridge sets promisc mode on all its ports, so your bond device should
be in promisc mode. Bonding code sets different set of slaves into
promisc mode depending on the mode you use. Which mode do you have
your bond configured in?
Does, dmesg tell you if devices have entered promisc mode?
-vlad
>
> Stefan
>
>> Thanks
>> -vlad
>>
>>>
>>> Stefan
>>>
>>>> -vlad
>>>>
>>>>
>>>>> Stefan
>>>>>
>>>>> This mail was sent with my iPhone.
>>>>>
>>>>> Am 30.08.2013 um 16:13 schrieb Vlad Yasevich <vyasevic@redhat.com>:
>>>>>
>>>>>> On 08/30/2013 03:24 AM, Stefan Priebe - Profihost AG wrote:
>>>>>>> Am 29.08.2013 22:45, schrieb Vlad Yasevich:
>>>>>>>> On 08/29/2013 08:50 AM, Stefan Priebe - Profihost AG wrote:
>>>>>>>
>>>>>>>>> The packets never reach the TAP device.
>>>>>>>>>
>>>>>>>>> Here is an output of ip a l (vlan 3021):
>>>>>>>>
>>>>>>>> Can you provide output of brctl show?
>>>>>>>
>>>>>>> Sure:
>>>>>>> # brctl show
>>>>>>> bridge name bridge id STP enabled interfaces
>>>>>>> vmbr0 8000.00259084dea8 no bond0
>>>>>>> tap320i0
>>>>>>> vmbr1 8000.00259084deaa no bond1
>>>>>>> vmbr1v3021 8000.00259084deaa no
>>>>>>> tap320i1
>>>>>>> vmbr1.3021
>>>>>>
>>>>>> so let me see if I can understand this configuration.
>>>>>>
>>>>>> vmbr1v3021 (bridge)
>>>>>> / \
>>>>>> tap320i1 vmbr1.3021 (vlan)
>>>>>> \
>>>>>> vmbr1 (bridge)
>>>>>> \
>>>>>> bond1
>>>>>> \
>>>>>> eth X
>>>>>>
>>>>>>
>>>>>> Is that right? Is this the setup that has the problem you are
>>>>>> describing?
>>>>>>
>>>>>> Thanks
>>>>>> -vlad
>>>>>>
>>>>>>>> On the off chance that you are actually trying to configure vlan
>>>>>>>> filtering, can you give this patch a try (net-2.6 tree):
>>>>>>>>
>>>>>>>> Author: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>>>>>> Date: Tue Aug 20 17:10:18 2013 +0900
>>>>>>>>
>>>>>>>> bridge: Use the correct bit length for bitmap functions in the
>>>>>>>> VLAN
>>>>>>>> code
>>>>>>>>
>>>>>>>> I don't think it made it to stable yet.
>>>>>>>
>>>>>>> I addd that patch and now the vlan stuff works at least on the host
>>>>>>> node. But my tap devices still don't work.
>>>>>>>
>>>>>>> I also tried to attach the tap device on top of a vlan attached to
>>>>>>> bond1
>>>>>>> but then gvrp does not work anymore. The kernel announces gvrp once
>>>>>>> and
>>>>>>> then does not answer the query packets from the switch.
>>>>>>>
>>>>>>> Stefan
>>>>>>
>>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Subject: ref: Bridge Financial Services Ltd
From: Bowker Maxwell - DGM @ 2013-11-13 11:24 UTC (permalink / raw)
To: netdev
Hello,
Apply for all types of loans, credits or capital from us at 3% interest rate.
Contact us today, and discover how we can help.
Bowker Maxwell - DGM.
Bridge Financial Services Ltd.
Company No. 04625391
Bridge Financial Services Ltd.
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Vlad Yasevich @ 2013-11-13 15:05 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG, Veaceslav Falico; +Cc: Linux Netdev List
In-Reply-To: <52838AC8.8070005@profihost.ag>
On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
> Hi Falico,
> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>> wrote:
>>> Hello,
>>>
>>> while my vlans, bridging and bonding stuff was working until 3.9 i never
>>> thought about how it is right. So maybe i was always wrong.
>>>
>>> I've this:
>>>
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> /
>>> eth3
>>>
>>> This works fine and as expected now i want to have a vlan using the
>>> bonding and using a bridge.
>>>
>>> I the past i had this:
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 \ vmbr1.3000
>>> \ ---- tap114i1
>>>
>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>> is bad!
>>
>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>> there were some issues with it in 3.10, which were fixed by some huge
>> patchsets that will never hit 3.10 stable.
>> Also, the bonding configuration would be welcome.
>
> Debian Bonding konfiguration looks like this:
> auto bond1
> iface bond1 inet manual
> slaves eth2 eth3
> bond-mode 802.3ad
> bond_miimon 100
> bond_updelay 200
> bond_downdelay 0
>
> This should be miimon using lacp and not arp isn't it?
> Anything more needed?
>
Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
bond should place all of its ports into promiscuous mode. Do you see
the the kernel messages that say that?
-vlad
> One thing i forgot the one with vmbr1.3000 does not work at all eben not
> with promisc mode. The one below works fine if i set eth2 and eth3 into
> promisc mode.
>
> Stefan
>
>>> I also tried this one without success:
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>> \ ---- tap114i1
>>>
>>>
>>>
>>> Greets,
>>> Stefan
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: gso: Handle new frag_list of frags GRO packets
From: Eric Dumazet @ 2013-11-13 15:06 UTC (permalink / raw)
To: Herbert Xu
Cc: Ben Hutchings, David Miller, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <20131113142615.GA1851@gondor.apana.org.au>
On Wed, 2013-11-13 at 22:26 +0800, Herbert Xu wrote:
> On Tue, Nov 12, 2013 at 06:45:04PM -0800, Eric Dumazet wrote:
> > On Wed, 2013-11-13 at 10:25 +0800, Herbert Xu wrote:
> >
> > > So a better test for the time being would be to test with TSO
> > > disabled in both cases.
> > >
> >
> > GRO on, TSO off, little difference between two cases :
> >
> > (Note some small things run in background, so these numbers are not
> > ultra precise)
>
> OK looks pretty sane.
>
> > > In the mean time I'm cooking up a patch to generate TSO packets.
> >
> > That would be very nice !
>
> It's failing on my machine but I'm not certain whether it's a bug
> in my patch or a bug in my NIC's TSO code. So I'd appreciate it
> if you can give this a spin on your mlx4.
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 557e1a5..1302515 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
Well, I wont try this patch, as it can not possibly work :(
The problem is not only skb_segment() but all its callers / users, as I
mentioned yesterday.
Specifically, you'll have to change inet_gso_segment(),
gre_gso_segment(), tcp_gso_segment(), ipv6_gso_segment(),
udp6_ufo_fragment() ...
Yes, we have to propagate correct IP id identifiers, and correct tcp
sequence numbers, tcp checksums.
^ permalink raw reply
* RE: [PATCH] rds: Error on offset mismatch if not loopback
From: Venkat Venkatsubra @ 2013-11-13 15:16 UTC (permalink / raw)
To: Josh Hunt, David Miller; +Cc: jjolly, LKML, netdev
In-Reply-To: <CAKA=qzYpd7Wo9XdU16TEhnbm5dPJjOZMhAY1jA7N+YFBWz5pzw@mail.gmail.com>
-----Original Message-----
From: Josh Hunt [mailto:joshhunt00@gmail.com]
Sent: Tuesday, November 12, 2013 10:25 PM
To: David Miller
Cc: jjolly@suse.com; LKML; Venkat Venkatsubra; netdev@vger.kernel.org
Subject: Re: [PATCH] rds: Error on offset mismatch if not loopback
On Tue, Nov 12, 2013 at 10:22 PM, Josh Hunt <joshhunt00@gmail.com> wrote:
> On Sat, Sep 22, 2012 at 2:25 PM, David Miller <davem@davemloft.net> wrote:
>>
>> From: John Jolly <jjolly@suse.com>
>> Date: Fri, 21 Sep 2012 15:32:40 -0600
>>
>> > Attempting an rds connection from the IP address of an IPoIB
>> > interface to itself causes a kernel panic due to a BUG_ON() being triggered.
>> > Making the test less strict allows rds-ping to work without
>> > crashing the machine.
>> >
>> > A local unprivileged user could use this flaw to crash the system.
>> >
>> > Signed-off-by: John Jolly <jjolly@suse.com>
>>
>> Besides the questions being asked of you by Venkat Venkatsubra, this
>> patch has another issue.
>>
>> It has been completely corrupted by your email client, it has turned
>> all TAB characters into spaces, making the patch useless.
>>
>> Please learn how to send a patch unmolested in the body of your
>> email. Test it by emailing the patch to yourself, and verifying that
>> you can in fact apply the patch you receive in that email.
>> Then, and only then, should you consider making a new submission of
>> this patch.
>>
>> Use Documentation/email-clients.txt for guidance.
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
>
> I think this issue was lost in the shuffle. It appears that redhat,
> ubuntu, and oracle are maintaining local patches to resolve this:
>
> https://oss.oracle.com/git/?p=redpatch.git;a=commit;h=c7b6a0a1d8d63685
> 2be130fa15fa8be10d4704e8
> https://bugzilla.redhat.com/show_bug.cgi?id=822754
> http://ubuntu.5.x6.nabble.com/CVE-2012-2372-RDS-local-ping-DOS-td49853
> 88.html
>
> Given that Oracle has applied it I'll make the assumption that
> Venkat's question was answered at some point.
>
> David - I can resubmit the patch with the proper signed-off-by and
> formatting if you are willing to apply it unless John wants to try
> again. I think it's time this got upstream.
>
> --
> Josh
Ugh.. hopefully resending with all the html crap removed...
--
Josh
Hi Josh,
No, I still didn't get an answer for how "off" could be non-zero in case of rds-ping to hit BUG_ON(off % RDS_FRAG_SIZE).
Because, rds-ping uses zero byte messages to ping.
If you have a test case that reproduces the kernel panic I can try it out and see how that can happen.
The Oracle's internal code I checked doesn't have that patch applied.
Venkat
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Stefan Priebe - Profihost AG @ 2013-11-13 15:17 UTC (permalink / raw)
To: Vlad Yasevich, Veaceslav Falico; +Cc: Linux Netdev List
In-Reply-To: <52839540.6020908@gmail.com>
Am 13.11.2013 16:05, schrieb Vlad Yasevich:
> On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
>> Hi Falico,
>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>>> wrote:
>>>> Hello,
>>>>
>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>> never
>>>> thought about how it is right. So maybe i was always wrong.
>>>>
>>>> I've this:
>>>>
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> /
>>>> eth3
>>>>
>>>> This works fine and as expected now i want to have a vlan using the
>>>> bonding and using a bridge.
>>>>
>>>> I the past i had this:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 \ vmbr1.3000
>>>> \ ---- tap114i1
>>>>
>>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>>> is bad!
>>>
>>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>>> there were some issues with it in 3.10, which were fixed by some huge
>>> patchsets that will never hit 3.10 stable.
>>> Also, the bonding configuration would be welcome.
>>
>> Debian Bonding konfiguration looks like this:
>> auto bond1
>> iface bond1 inet manual
>> slaves eth2 eth3
>> bond-mode 802.3ad
>> bond_miimon 100
>> bond_updelay 200
>> bond_downdelay 0
>>
>> This should be miimon using lacp and not arp isn't it?
>> Anything more needed?
>>
>
> Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
> bond should place all of its ports into promiscuous mode. Do you see
> the the kernel messages that say that?
No it does not - i only see:
# dmesg -c|egrep "promiscuous|forward"
[ 5.445161] device bond0 entered promiscuous mode
[ 7.670701] device bond1 entered promiscuous mode
[ 7.845472] vmbr0: port 1(bond0) entered forwarding state
[ 7.845474] vmbr0: port 1(bond0) entered forwarding state
[ 8.269769] vmbr1: port 1(bond1) entered forwarding state
[ 8.269771] vmbr1: port 1(bond1) entered forwarding state
Now adding variant 1:
# dmesg -c|egrep "promiscuous|forward"
[ 85.919382] device tap113i0 entered promiscuous mode
[ 85.965018] vmbr0: port 2(tap113i0) entered forwarding state
[ 85.965023] vmbr0: port 2(tap113i0) entered forwarding state
[ 86.263292] device tap113i1 entered promiscuous mode
[ 86.314151] device vmbr1.3000 entered promiscuous mode
[ 86.314153] device vmbr1 entered promiscuous mode
[ 86.314192] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
[ 86.314196] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
[ 86.318116] vmbr1v3000: port 2(tap113i1) entered forwarding state
[ 86.318120] vmbr1v3000: port 2(tap113i1) entered forwarding state
[ 101.382129] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
Now it looks like this:
# ip a l|grep PROMISC
13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
htb master vmbr0 state UNKNOWN qlen 500
14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
htb master vmbr1v3000 state UNKNOWN qlen 500
Greets,
Stefan
Main question is - is this one correct:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 \ vmbr1.3000
>>>> \ ---- tap114i1
<= does not work at all
or this one?:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>> \ ---- tap114i1
<= works if i manually put eth2 and eth3 into promiscous mode.
> -vlad
>
>> One thing i forgot the one with vmbr1.3000 does not work at all eben not
>> with promisc mode. The one below works fine if i set eth2 and eth3 into
>> promisc mode.
>>
>> Stefan
>>
>>>> I also tried this one without success:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>> \ ---- tap114i1
>>>>
>>>>
>>>>
>>>> Greets,
>>>> Stefan
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* [PATCH net v2] ipv4: fix wildcard search with inet_confirm_addr()
From: Nicolas Dichtel @ 2013-11-13 15:23 UTC (permalink / raw)
To: ja; +Cc: davem, netdev, Nicolas Dichtel
In-Reply-To: <alpine.LFD.2.03.1311082258430.1811@ssi.bg>
Help of this function says: "in_dev: only on this interface, 0=any interface",
but since commit 39a6d0630012 ("[NETNS]: Process inet_confirm_addr in the
correct namespace."), the code supposes that it will never be NULL. This
function is never called with in_dev == NULL, but it's exported and may be used
by an external module.
Because this patch restore the ability to call inet_confirm_addr() with in_dev
== NULL, I partially revert the above commit, as suggested by Julian.
CC: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
This bug was spotted by code review.
v2: fix change in bond_confirm_addr()
partially revert 39a6d0630012 ("[NETNS]: Process inet_confirm_addr in the
correct namespace.")
fix API desc of inet_confirm_addr()
drivers/net/bonding/bonding.h | 4 ++--
include/linux/inetdevice.h | 3 ++-
net/ipv4/arp.c | 4 +++-
net/ipv4/devinet.c | 9 ++++-----
4 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 03cf3fd14490..0ad3f4bd99c0 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -414,8 +414,8 @@ static inline __be32 bond_confirm_addr(struct net_device *dev, __be32 dst, __be3
in_dev = __in_dev_get_rcu(dev);
if (in_dev)
- addr = inet_confirm_addr(in_dev, dst, local, RT_SCOPE_HOST);
-
+ addr = inet_confirm_addr(dev_net(dev), in_dev, dst, local,
+ RT_SCOPE_HOST);
rcu_read_unlock();
return addr;
}
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index 79640e015a86..5870f7060917 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -164,7 +164,8 @@ extern int devinet_ioctl(struct net *net, unsigned int cmd, void __user *);
extern void devinet_init(void);
extern struct in_device *inetdev_by_index(struct net *, int);
extern __be32 inet_select_addr(const struct net_device *dev, __be32 dst, int scope);
-extern __be32 inet_confirm_addr(struct in_device *in_dev, __be32 dst, __be32 local, int scope);
+__be32 inet_confirm_addr(struct net *net, struct in_device *in_dev, __be32 dst,
+ __be32 local, int scope);
extern struct in_ifaddr *inet_ifa_byprefix(struct in_device *in_dev, __be32 prefix, __be32 mask);
static __inline__ int inet_ifa_match(__be32 addr, struct in_ifaddr *ifa)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 7808093cede6..46c7b4483bcf 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -379,6 +379,7 @@ static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb)
static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
{
+ struct net *net = dev_net(in_dev->dev);
int scope;
switch (IN_DEV_ARP_IGNORE(in_dev)) {
@@ -397,6 +398,7 @@ static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
case 3: /* Do not reply for scope host addresses */
sip = 0;
scope = RT_SCOPE_LINK;
+ in_dev = NULL;
break;
case 4: /* Reserved */
case 5:
@@ -408,7 +410,7 @@ static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
default:
return 0;
}
- return !inet_confirm_addr(in_dev, sip, tip, scope);
+ return !inet_confirm_addr(net, in_dev, sip, tip, scope);
}
static int arp_filter(__be32 sip, __be32 tip, struct net_device *dev)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index a1b5bcbd04ae..19426e4b232c 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1236,22 +1236,21 @@ static __be32 confirm_addr_indev(struct in_device *in_dev, __be32 dst,
/*
* Confirm that local IP address exists using wildcards:
- * - in_dev: only on this interface, 0=any interface
+ * - net: netns to check, cannot be NULL
+ * - in_dev: only on this interface, NULL=any interface
* - dst: only in the same subnet as dst, 0=any dst
* - local: address, 0=autoselect the local address
* - scope: maximum allowed scope value for the local address
*/
-__be32 inet_confirm_addr(struct in_device *in_dev,
+__be32 inet_confirm_addr(struct net *net, struct in_device *in_dev,
__be32 dst, __be32 local, int scope)
{
__be32 addr = 0;
struct net_device *dev;
- struct net *net;
- if (scope != RT_SCOPE_LINK)
+ if (in_dev != NULL)
return confirm_addr_indev(in_dev, dst, local, scope);
- net = dev_net(in_dev->dev);
rcu_read_lock();
for_each_netdev_rcu(net, dev) {
in_dev = __in_dev_get_rcu(dev);
--
1.8.4.1
^ permalink raw reply related
* [PATCH RFC] netlink: a flag requesting header w/o data in error ACK
From: Jiri Benc @ 2013-11-13 15:46 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Thomas Graf, Jamal Hadi Salim, Pablo Neira Ayuso
Currently, ACK in case of error contains a full copy of the originating
message, although many applications do not need it. This can cause lost ACKs
with large netlink messages, especially after commit c05cdb1b864f ("netlink:
allow large data transfers from user-space").
Introduce a new message flag, NLM_F_SHORT_NACK, which requests only message
header to be included in ACK regardless of the error code. This flag has no
effect if NLM_F_ACK is not set.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
I'm not entirely happy with taking a bit in netlink message header for this.
Alternative approach would be to make this a socket option (as suggested by
David) but that would mean a socket lookup in netlink_ack for each and every
ACK, which doesn't sound nice, either. If this is preferred, I'll rework the
patch.
---
include/uapi/linux/netlink.h | 3 ++-
net/netlink/af_netlink.c | 10 +++++++---
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/netlink.h b/include/uapi/linux/netlink.h
index 1a85940..d21dc2b 100644
--- a/include/uapi/linux/netlink.h
+++ b/include/uapi/linux/netlink.h
@@ -53,7 +53,8 @@ struct nlmsghdr {
#define NLM_F_MULTI 2 /* Multipart message, terminated by NLMSG_DONE */
#define NLM_F_ACK 4 /* Reply with ack, with zero or error code */
#define NLM_F_ECHO 8 /* Echo this request */
-#define NLM_F_DUMP_INTR 16 /* Dump was inconsistent due to sequence change */
+#define NLM_F_DUMP_INTR 0x10 /* Dump was inconsistent due to sequence change */
+#define NLM_F_SHORT_NACK 0x20 /* Quote only the header in ack on error */
/* Modifiers to GET request */
#define NLM_F_ROOT 0x100 /* specify tree root */
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 8df7f64..7ea2a1e 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -2716,13 +2716,17 @@ EXPORT_SYMBOL(__netlink_dump_start);
void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err)
{
+ int full_quote;
struct sk_buff *skb;
struct nlmsghdr *rep;
struct nlmsgerr *errmsg;
size_t payload = sizeof(*errmsg);
- /* error messages get the original request appened */
- if (err)
+ /* Error messages get the original request appened, unless
+ * NLM_F_SHORT_NACK is set.
+ */
+ full_quote = err && !(nlh->nlmsg_flags & NLM_F_SHORT_NACK);
+ if (full_quote)
payload += nlmsg_len(nlh);
skb = netlink_alloc_skb(in_skb->sk, nlmsg_total_size(payload),
@@ -2745,7 +2749,7 @@ void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err)
NLMSG_ERROR, payload, 0);
errmsg = nlmsg_data(rep);
errmsg->error = err;
- memcpy(&errmsg->msg, nlh, err ? nlh->nlmsg_len : sizeof(*nlh));
+ memcpy(&errmsg->msg, nlh, full_quote ? nlh->nlmsg_len : sizeof(*nlh));
netlink_unicast(in_skb->sk, skb, NETLINK_CB(in_skb).portid, MSG_DONTWAIT);
}
EXPORT_SYMBOL(netlink_ack);
--
1.7.6.5
^ permalink raw reply related
* Re: [PATCH] svcrpc: remove the unnecessary evaluation
From: J. Bruce Fields @ 2013-11-13 15:56 UTC (permalink / raw)
To: Weng Meiling
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Li Zefan
In-Reply-To: <527C9160.3070808-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
On Fri, Nov 08, 2013 at 03:23:12PM +0800, Weng Meiling wrote:
>
> From: Weng Meiling <wengmeiling.weng-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Huh. Looks like that was introduced with "[PATCH] knfsd: make sure
svc_process call the correct pg_authenticate for multi-service port" in
2005. OK! Applied.
--b.
>
> Signed-off-by: Weng Meiling <wengmeiling.weng-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> ---
> net/sunrpc/svc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
> index b974571..e7fbe36 100644
> --- a/net/sunrpc/svc.c
> +++ b/net/sunrpc/svc.c
> @@ -1104,8 +1104,6 @@ svc_process_common(struct svc_rqst *rqstp, struct kvec *argv, struct kvec *resv)
> rqstp->rq_vers = vers = svc_getnl(argv); /* version number */
> rqstp->rq_proc = proc = svc_getnl(argv); /* procedure number */
>
> - progp = serv->sv_program;
> -
> for (progp = serv->sv_program; progp; progp = progp->pg_next)
> if (prog == progp->pg_prog)
> break;
> --
> 1.8.3.1
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Fwd: Re: [PATCH v2 2/2] x86: add prefetching to do_csum]
From: Neil Horman @ 2013-11-13 16:01 UTC (permalink / raw)
To: David Laight
Cc: Ingo Molnar, Joe Perches, netdev, Dave Jones, linux-kernel,
sebastien.dugue, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
x86, Eric Dumazet, Peter Zijlstra
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7412@saturn3.aculab.com>
On Wed, Nov 13, 2013 at 01:32:50PM -0000, David Laight wrote:
> > > I'm not sure, whats the typical capacity for the branch predictors
> > > ability to remember code paths?
> ...
> >
> > For such simple single-target branches it goes near or over a thousand for
> > recent Intel and AMD microarchitectures. Thousands for really recent CPUs.
>
> IIRC the x86 can also correctly predict simple sequences - like a branch
> in a loop that is taken every other iteration, or only after a previous
> branch is taken.
>
> Much simpler cpus may use a much simpler strategy.
> I think one I've used (a fpga soft-core cpu) just uses the low
> bits of the instruction address to index a single bit table.
> This means that branches alias each other.
> In order to get the consistent cycle counts in order to minimise
> the worst case code path we had to disable the dynamic prediction.
>
> For the checksum code the loop branch isn't a problem.
> Tests on entry to the function might get mispredicted.
>
> So if you have conditional prefetch when the buffer is long
> then time a short buffer after a 100 long ones you'll almost
> certainly see the mispredition penalty.
>
> FWIW I remember speeding up a copy (I think) loop on a strongarm by
> adding an extra instruction to fetch a word from later in the buffer
> into a register I never otherwise used.
> (That was an unpaged system so I knew it couldn't fault.)
>
Fair enough, but the code we're looking at here is arch specific. If strongarms
benefit from different coding patterns, we can handle that in that arch. This
x86 implementation can still avoid worrying about branch predicition since its
hardware handles it well
Neil
> David
>
>
>
>
>
^ permalink raw reply
* [PATCH net] bonding: fix two race conditions in bond_store_updelay/downdelay
From: Nikolay Aleksandrov @ 2013-11-13 16:07 UTC (permalink / raw)
To: netdev
Cc: davem, Nikolay Aleksandrov, Jay Vosburgh, Andy Gospodarek,
Veaceslav Falico
This patch fixes two race conditions between bond_store_updelay/downdelay
and bond_store_miimon which could lead to division by zero as miimon can
be set to 0 while either updelay/downdelay are being set and thus miss the
zero check in the beginning, the zero div happens because updelay/downdelay
are stored as new_value / bond->params.miimon. Use rtnl to synchronize with
miimon setting.
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
drivers/net/bonding/bond_sysfs.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index bc8fd36..8f8a607 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -701,6 +701,8 @@ static ssize_t bonding_store_downdelay(struct device *d,
int new_value, ret = count;
struct bonding *bond = to_bond(d);
+ if (!rtnl_trylock())
+ return restart_syscall();
if (!(bond->params.miimon)) {
pr_err("%s: Unable to set down delay as MII monitoring is disabled\n",
bond->dev->name);
@@ -734,6 +736,7 @@ static ssize_t bonding_store_downdelay(struct device *d,
}
out:
+ rtnl_unlock();
return ret;
}
static DEVICE_ATTR(downdelay, S_IRUGO | S_IWUSR,
@@ -756,6 +759,8 @@ static ssize_t bonding_store_updelay(struct device *d,
int new_value, ret = count;
struct bonding *bond = to_bond(d);
+ if (!rtnl_trylock())
+ return restart_syscall();
if (!(bond->params.miimon)) {
pr_err("%s: Unable to set up delay as MII monitoring is disabled\n",
bond->dev->name);
@@ -789,6 +794,7 @@ static ssize_t bonding_store_updelay(struct device *d,
}
out:
+ rtnl_unlock();
return ret;
}
static DEVICE_ATTR(updelay, S_IRUGO | S_IWUSR,
--
1.8.1.4
^ permalink raw reply related
* RE: [PATCH] usb: xhci: Link TRB must not occur with a USB payload burst.
From: Alan Stern @ 2013-11-13 16:20 UTC (permalink / raw)
To: David Laight
Cc: Sarah Sharp, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B740B-CgBM+Bx2aUAnGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
On Wed, 13 Nov 2013, David Laight wrote:
> > > Since you don't really want to do all the work twice, the sensible
> > > way is to add each input fragment to the ring one a time.
> > > If you need to cross a link TRB and the last MBP boundary is within
> > > the previous data TRB then you can split the previous data TRB at the
> > > MBP boundary and continue.
> > > If the previous TRB is short then you'd need to go back through the
> > > earlier TRB until you found the one that contains a TRB boundary,
> > > split it, and write a link TRB in the following slot.
> >
> > Right. You could avoid doing a lot of work twice by using two passes.
> > In the first pass, keep track of the number of bytes allotted to each
> > TRB and the MBP boundaries, without doing anything else. That way,
> > you'll know where to put a Link TRB without any need for backtracking.
> > Then in the second pass, fill in the actual contents of the TRBs.
>
> No - you really don't want to process everything twice.
What I described does not process anything twice. It calculates the
byte counts on the first pass and everything else on the second pass.
> You could remember the TRB and offset of the last MBP boundary.
Then you really _do_ end up processing the TRB's which follow the last
MBP boundary twice. Once when setting up the TD as normal, and then
again after you realize they need to be moved to a different ring
segment.
> > Unless the first TRB of the message is the first TRB of the ring
> > segment. Then you're in trouble... Hopefully, real URBs will never be
> > that badly fragmented.
>
> I suspect that ones from the network stack might be badly fragmented.
> The code needs to at least detect and error them.
I'm not so sure about this. The network stack works okay with other
host controller drivers (like ehci-hcd), which have much stricter
requirements about fragmentation. They require that the length of each
SG element except the last one must be a multiple of the maxpacket
size. For high-speed bulk transfers, that means a multiple of 512.
> > > You can split a bulk TD on a 1k boundary and the target won't know the
> > > difference.
> >
> > The target won't know the difference, but the host will. Here's an
> > example: Suppose the driver submits two URBs, each for a data-in
> > transfer of 32 KB. You split each URB up into two 16-KB TDs; let's
> > call them A, B, C, and D (where A and B make up the first URB, and C
> > and D make up the second URB).
>
> I was thinking about OUT transfers, IN ones are unlikely to be badly
> fragmented.
Maybe not for the network stack, but OUT and IN end up equally
fragmented for the storage stack.
> > Suppose you have only two ring segments, and a driver submits an URB
> > which is so fragmented that it requires more TRBs than you have room
> > for in those two segments. When do you want the interrupts to arrive?
> > Answer: At each segment crossing.
>
> You bounce the original request and fix the driver to submit URB
> with fewer fragments.
In other words, you want to limit the number of SG elements the driver
will accept.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Veaceslav Falico @ 2013-11-13 16:21 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: Vlad Yasevich, Linux Netdev List
In-Reply-To: <5283980D.7020508@profihost.ag>
On Wed, Nov 13, 2013 at 04:17:33PM +0100, Stefan Priebe - Profihost AG wrote:
>Am 13.11.2013 16:05, schrieb Vlad Yasevich:
>> On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
>>> Hi Falico,
>>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>>>> wrote:
>>>>> Hello,
>>>>>
>>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>>> never
>>>>> thought about how it is right. So maybe i was always wrong.
>>>>>
>>>>> I've this:
>>>>>
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> /
>>>>> eth3
>>>>>
>>>>> This works fine and as expected now i want to have a vlan using the
>>>>> bonding and using a bridge.
>>>>>
>>>>> I the past i had this:
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> / \
>>>>> eth3 \ vmbr1.3000
>>>>> \ ---- tap114i1
>>>>>
>>>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>>>> is bad!
>>>>
>>>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>>>> there were some issues with it in 3.10, which were fixed by some huge
>>>> patchsets that will never hit 3.10 stable.
>>>> Also, the bonding configuration would be welcome.
>>>
>>> Debian Bonding konfiguration looks like this:
>>> auto bond1
>>> iface bond1 inet manual
>>> slaves eth2 eth3
>>> bond-mode 802.3ad
>>> bond_miimon 100
>>> bond_updelay 200
>>> bond_downdelay 0
>>>
>>> This should be miimon using lacp and not arp isn't it?
>>> Anything more needed?
>>>
>>
>> Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
>> bond should place all of its ports into promiscuous mode. Do you see
>> the the kernel messages that say that?
>
>No it does not - i only see:
># dmesg -c|egrep "promiscuous|forward"
>[ 5.445161] device bond0 entered promiscuous mode
>[ 7.670701] device bond1 entered promiscuous mode
>[ 7.845472] vmbr0: port 1(bond0) entered forwarding state
>[ 7.845474] vmbr0: port 1(bond0) entered forwarding state
>[ 8.269769] vmbr1: port 1(bond1) entered forwarding state
>[ 8.269771] vmbr1: port 1(bond1) entered forwarding state
>
>Now adding variant 1:
># dmesg -c|egrep "promiscuous|forward"
>[ 85.919382] device tap113i0 entered promiscuous mode
>[ 85.965018] vmbr0: port 2(tap113i0) entered forwarding state
>[ 85.965023] vmbr0: port 2(tap113i0) entered forwarding state
>[ 86.263292] device tap113i1 entered promiscuous mode
>[ 86.314151] device vmbr1.3000 entered promiscuous mode
>[ 86.314153] device vmbr1 entered promiscuous mode
>[ 86.314192] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>[ 86.314196] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>[ 86.318116] vmbr1v3000: port 2(tap113i1) entered forwarding state
>[ 86.318120] vmbr1v3000: port 2(tap113i1) entered forwarding state
>[ 101.382129] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>
>Now it looks like this:
># ip a l|grep PROMISC
>13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>htb master vmbr0 state UNKNOWN qlen 500
>14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>htb master vmbr1v3000 state UNKNOWN qlen 500
eth* should get into forwarding mode cause bond0 is a port of the bridge
and should propagate its state towards its slaves. Something is wrong here.
Maybe we're looking at the wrong direction - and the promisc for the
ethernet drivers got broken?
What ethernet cards/driver do you use for eth*?
>
>Greets,
>Stefan
>
>
>Main question is - is this one correct:
Both are correct. Here's my setup (sorry for stretching):
+---------------+ +------------+ +-------------+ +---------+ +------+
| bond1 | | | | bridge0 | | | | |
| 192.168.2.1 | master | bridge0.15 | neighbour | 192.168.3.1 | master | bond0 | master | eth2 |
| | --------> | | ------------ | 192.168.4.1 | --------> | | --------> | |
+---------------+ +------------+ +-------------+ +---------+ +------+
|
| master
v
+---------------+ +---------+
| dummy0 | | eth0 |
+---------------+ +---------+
(disregard that dummy0).
All 192.168.X.1 ips are pingable (via the correct vlans) on both net-next and stable 3.10.19.
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> / \
>>>>> eth3 \ vmbr1.3000
>>>>> \ ---- tap114i1
>
><= does not work at all
>
>or this one?:
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> / \
>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>> \ ---- tap114i1
>
><= works if i manually put eth2 and eth3 into promiscous mode.
>
>> -vlad
>>
>>> One thing i forgot the one with vmbr1.3000 does not work at all eben not
>>> with promisc mode. The one below works fine if i set eth2 and eth3 into
>>> promisc mode.
>>>
>>> Stefan
>>>
>>>>> I also tried this one without success:
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> / \
>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>> \ ---- tap114i1
>>>>>
>>>>>
>>>>>
>>>>> Greets,
>>>>> Stefan
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
^ permalink raw reply
* RE: [PATCH] usb: xhci: Link TRB must not occur with a USB payload burst.
From: Alan Stern @ 2013-11-13 16:27 UTC (permalink / raw)
To: David Laight
Cc: Sarah Sharp, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B740C-CgBM+Bx2aUAnGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
On Wed, 13 Nov 2013, David Laight wrote:
> > > that doesn't matter; we don't get an interrupt when a ring segment is
> > > crossed. Instead we set the interrupt-on-completion flag on the last
> > > TRB of the TD, not on any earlier fragment or link TRB.
> >
> > That's because you don't worry about handling URBs which require too
> > many TRBs (i.e., more than are available). You just add more ring
> > segments. Instead, you could re-use segments on the fly.
> >
> > For example, suppose you have only two ring segments and you get an URB
> > which requires enough TRBs to fill up four segments. You could fill in
> > the first two segments worth, and get an interrupt when the controller
> > traverses the Link TRB between them. At that point you store the third
> > set of TRBs in the first segment, which is now vacant. Similarly, when
> > the second Link TRB is traversed, you fill in the fourth set of TRBs.
>
> That isn't going to work.
Queuing URBs and processing them in pieces was _your_ suggestion. I
merely repeated it to Sarah and filled in some detail.
> It might work for very long TD, but for very fragmented ones the interrupt
> rate would be stupid.
Not if the individual SG elements are reasonably large -- say at least
512 bytes. They have to be that big if they are to work with ehci-hcd,
so why not also for xhci-hcd?
> In any case you'd definitely need enough ring
> segments for the TRB that describe a single 'max packet size' block.
That would be two TRBs (for maxpacket = 1024), meaning you'd need at
least one ring segment. That's not much of a restriction.
> > > Finally, it's interesting to note that the USB mass storage driver is
> > > using scatter gather lists just fine without the driver following the TD
> > > fragment rules. Or at least no one has reported any issues. I wonder
> > > why it works?
> >
> > I'd guess this is because the hardware is actually a lot more flexible
> > than the "No Link TRBs in the middle of a TD fragment" rule.
>
> With the hardware I have (Intel i7 Sandy bridge) Link TRB cannot
> be placed at arbitrary boundaries.
> I don't know whether the actual restriction is only to packet boundaries.
That's what I had in mind by "more flexible" above.
> I don't have a USB3 monitor and it would also require a more contrived
> test than I've been doing.
You wouldn't need a monitor to check it, but you would need some
careful tests.
> > The whole idea of TD fragments makes no sense to begin with. What
> > point is there in grouping packets into MaxBurst-sized collections?
>
> It probably saved a few logic gates somewhere, either that or it is
> a bug in some hardware implementation that got documented in the spec
> instead of being fixed :-)
I can believe the guess about it reflecting a bug. Particularly since
it is so badly written.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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