* [PATCH] bridge: mcast snooping, fix length check of snooped MLDv1/2
From: Linus Lüssing @ 2011-03-27 6:27 UTC (permalink / raw)
To: bridge
Cc: Stephen Hemminger, David Miller, YOSHIFUJI Hideaki, Herbert Xu,
netdev, Linus Lüssing
In-Reply-To: <1301207244-10428-1-git-send-email-linus.luessing@web.de>
"len = ntohs(ip6h->payload_len)" does not include the length of the ipv6
header itself, which the rest of this function assumes, though.
This leads to a length check less restrictive as it should be in the
following line for one thing. For another, it very likely leads to an
integer underrun when substracting the offset and therefore to a very
high new value of 'len' due to its unsignedness. This will ultimately
lead to the pskb_trim_rcsum() practically never being called, even in
the cases where it should.
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
---
net/bridge/br_multicast.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 47fae4f..3793264 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1475,7 +1475,7 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
ip6h->payload_len == 0)
return 0;
- len = ntohs(ip6h->payload_len);
+ len = ntohs(ip6h->payload_len) + sizeof(*ip6h);
if (skb->len < len)
return -EINVAL;
--
1.5.6.5
^ permalink raw reply related
* bridge: mcast snooping, fixes for IPv6 MLDv1/2 parsing
From: Linus Lüssing @ 2011-03-27 6:27 UTC (permalink / raw)
To: bridge
Cc: Stephen Hemminger, David Miller, YOSHIFUJI Hideaki, Herbert Xu,
netdev
In-Reply-To: <20110327034404.GC31916@Sellars>
Hi everyone,
The following two patches are fixing two issues, related to the parsing of
IPv6 MLD messages.
The first one fixes an observed issue which lead to ignored MLD messages.
In the tests this patch fixes the issue in my scenario. However I'm not
so familiar with the checksumming functions in the kernel, so would be
great if someone could double-check whether the new checksum calculations
make sense like this.
The second patch fixes a potential issue. Bogus values of the 'len' variable
had been observed during tests and this patch successfully fixed this
here. However this patch is untested for the potential issues named
in the patch's description that could have occured without it.
Both patches together have been applied and tested and no more
issues with the parsing and adding of new IPv6 multicast listeners to
the bridge snooping database could be observed (for now ;) ).
Cheers, Linus
^ permalink raw reply
* [PATCH] bridge: mcast snooping, fix IPv6 MLD checksum calculation
From: Linus Lüssing @ 2011-03-27 6:27 UTC (permalink / raw)
To: bridge
Cc: Stephen Hemminger, David Miller, YOSHIFUJI Hideaki, Herbert Xu,
netdev, Linus Lüssing
In-Reply-To: <1301207244-10428-1-git-send-email-linus.luessing@web.de>
In contrast to IGMP, the MLDv1/2 message checksum needs to include an
IPv6 "pseudo-header" in the calculations (see RFC2710, section 3.3;
RFC3810, section 5.1.2).
The multicast snooping feature of the bridge code however did not take
this "pseudo-header" into consideration for the checksum validation when
parsing a snooped IPv6 MLDv1/2 message of another host, leading to
possibly ignored, though valid MLDv1/2 messages. This commit shall fix
this issue.
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
---
net/bridge/br_multicast.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index f61eb2e..47fae4f 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1525,7 +1525,10 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
break;
/*FALLTHROUGH*/
case CHECKSUM_NONE:
- skb2->csum = 0;
+ skb2->csum = ~csum_unfold(csum_ipv6_magic(&ip6h->saddr,
+ &ip6h->daddr,
+ skb2->len,
+ nexthdr, 0));
if (skb_checksum_complete(skb2))
goto out;
}
--
1.5.6.5
^ permalink raw reply related
* Checksumming bug in bridge multicast snooping for IPv6?
From: Linus Lüssing @ 2011-03-27 3:44 UTC (permalink / raw)
To: bridge
Cc: Stephen Hemminger, David Miller, YOSHIFUJI Hideaki, Herbert Xu,
netdev
[-- Attachment #1: Type: text/plain, Size: 2959 bytes --]
Hi everyone,
Somehow I'm having trouble with the IPv6 bridge snooping again:
MLDv2 Reports are dropped by the multicast snooping feature, looks
like it has something to do with checksums. Wireshark does not
display any weirdness, it at least reports the MLD reports
checksum as correct.
The setup is the following: The VM is running a current Linux
version of torvalds branch with no other additions then the
printk-debug patch attached (2.6.38+ #4 SMP PREEMPT Sat Mar 26
22:59:11 GMT 2011 i686 GNU/Linux):
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;h=16c29dafcc86024048f1dbb8349d31cb22c7c55a;hb=16c29dafcc86024048f1dbb8349d31cb22c7c55a
The host machine which is joining a multicast group is doing an
explicit join on the KVM instances provided tap interface:
IPv6: vlc -vvv "udp://@[ff12::124%vmtap1]"
(IPv4: vlc -vvv "udp://@224.0.1.123")
The host machine is running a kernel from Debian unstable:
2.6.37-2-amd64 #1 SMP Sun Feb 27 12:32:01 UTC 2011 x86_64
GNU/Linux
See the attached debug patch and the according output for some
more details where it fails (the bridge is basically ignoring the
MLDv2 report due to the goto in this line:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=net/bridge/br_multicast.c;h=f61eb2eff3fdd387b83d9fab642bb610dde1ad69;hb=HEAD#l1530)
I'm also attaching both a wireshark capture of the ignored IPv6
MLDv2 report and the working IGMPv3 report, which correspond
directly to the attached printk debug output.
I'm a little bit startled because I definitely had that part
working a couple of weeks ago and I'm still trying to figure out
what I might have changed in the setup. I definitely have updated
the VMs kernel, but the same issue is present for the 2.6.38 and
also 2.6.37 release versions with my fixes backported
(the latter one was the one I had been using back then).
I probably have updated the multicast listener host's kernel, too,
I might have been running 2.6.32 or something more earlier... I've
also tried having the listener host in another VM with the same
2.6.38+ kernel as the bridge-snooping host, but also that did not
make a difference.
Anyways, skb_checksum_complete() is calculating the checksum from
skb's data to tail pointer, right?
RFC3810 for MLDv2, section 5.1.2 says:
"The standard ICMPv6 checksum; it covers the entire MLDv2 message,
plus a "pseudo-header" of IPv6 header fields [RFC2463]."
Could it be that this "pseudo-header" is not included in the
checksumming? Is there a function in the kernel which could
already provide that?
I guess that could also explain why it's working fine for IPv4,
there it's just the IGMP message being checksummed according to
RFC 3376, section 4.1.2.
Cheers, Linus
PS: There also seems to be another offset bug in the same
function, see comment in debug patch file, though seemingly
unrelated to the issue described above. Correcting that
len-variable does to help for the above issue.
[-- Attachment #2: br-mcast-snoop-printk-debug.log --]
[-- Type: text/plain, Size: 1839 bytes --]
IPv6:
[ 2460.557303] +++ br_multicast_ipv6_rcv()
[ 2460.558114] +++ br_multicast_ipv6_rcv() here 0.5
[ 2460.558114] +++ br_multicast_ipv6_rcv() len: 36, offset: 48, skb_network_offset(skb2): 0
[ 2460.558114] +++ br_multicast_ipv6_rcv() new len: -12
[ 2460.558114] +++ br_multicast_ipv6_rcv() skb2->len: 28 len: -12 skb->len: 76
[ 2460.558114] +++ br_multicast_ipv6_rcv() here 1.5
[ 2460.558114] +++ br_multicast_ipv6_rcv() here 1.7, skb2->csum is 0
[ 2460.558114] +++ br_multicast_ipv6_rcv() here 1.8, skb_checksum_complete(skb2): 81e9 (skb): 2e60
[ 2464.981808] +++ br_multicast_ipv6_rcv()
[ 2464.982388] +++ br_multicast_ipv6_rcv() here 0.5
[ 2465.062634] +++ br_multicast_ipv6_rcv() len: 36, offset: 48, skb_network_offset(skb2): 0
[ 2465.066698] +++ br_multicast_ipv6_rcv() new len: -12
[ 2465.069183] +++ br_multicast_ipv6_rcv() skb2->len: 28 len: -12 skb->len: 76
[ 2465.072013] +++ br_multicast_ipv6_rcv() here 1.5
[ 2465.074217] +++ br_multicast_ipv6_rcv() here 1.7, skb2->csum is 0
[ 2465.076785] +++ br_multicast_ipv6_rcv() here 1.8, skb_checksum_complete(skb2): 81e9 (skb): 2e60
IPv4:
[ 2325.265830] +++ br_multicast_ipv4_rcv() skb2->len: 40 len: 40 skb->len: 40
[ 2325.266567] +++ br_multicast_ipv4_rcv() 2) skb2->len: 16 len: 16 skb->len: 16
[ 2325.266567] +++ br_multicast_ipv4_rcv() here 1.7, skb2->csum is 0
[ 2325.266567] +++ br_multicast_ipv4_rcv() here 1.8, skb_checksum_complete: 0
[ 2325.266567] +++ br_ip4_multicast_add_group() eth1 224.0.1.123
[ 2327.326179] +++ br_multicast_ipv4_rcv() skb2->len: 40 len: 40 skb->len: 40
[ 2327.326674] +++ br_multicast_ipv4_rcv() 2) skb2->len: 16 len: 16 skb->len: 16
[ 2327.326674] +++ br_multicast_ipv4_rcv() here 1.7, skb2->csum is 0
[ 2327.326674] +++ br_multicast_ipv4_rcv() here 1.8, skb_checksum_complete: 0
[ 2327.326674] +++ br_ip4_multicast_add_group() eth1 224.0.1.123
[-- Attachment #3: bridge-snoop-debug.patch --]
[-- Type: text/x-diff, Size: 4954 bytes --]
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index f61eb2e..3d4c5d2 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -764,8 +764,11 @@ static int br_ip4_multicast_add_group(struct net_bridge *br,
{
struct br_ip br_group;
- if (ipv4_is_local_multicast(group))
+printk("+++ br_ip4_multicast_add_group() %s %pI4\n", port->dev->name, &group);
+ if (ipv4_is_local_multicast(group)) {
+printk("+++ br_ip4_multicast_add_group() %s %pI4, is link local\n", port->dev->name, &group);
return 0;
+ }
br_group.u.ip4 = group;
br_group.proto = htons(ETH_P_IP);
@@ -780,8 +783,11 @@ static int br_ip6_multicast_add_group(struct net_bridge *br,
{
struct br_ip br_group;
- if (!ipv6_is_transient_multicast(group))
+printk("+++ br_ip6_multicast_add_group() %s %pI6\n", port->dev->name, group);
+ if (!ipv6_is_transient_multicast(group)) {
+printk("+++ br_ip6_multicast_add_group() %s %pI6, is not transient\n", port->dev->name, group);
return 0;
+ }
ipv6_addr_copy(&br_group.u.ip6, group);
br_group.proto = htons(ETH_P_IPV6);
@@ -1001,6 +1007,7 @@ static int br_ip6_multicast_mld2_report(struct net_bridge *br,
int num;
int err = 0;
+printk("+++ br_ip6_multicast_mld2_report()\n");
if (!pskb_may_pull(skb, sizeof(*icmp6h)))
return -EINVAL;
@@ -1386,11 +1393,14 @@ static int br_multicast_ipv4_rcv(struct net_bridge *br,
if (skb->len < len || len < ip_hdrlen(skb))
return -EINVAL;
+printk("+++ br_multicast_ipv4_rcv() skb2->len: %i len: %i skb->len: %i\n", skb2->len, len, skb->len);
if (skb->len > len) {
+printk("+++ br_multicast_ipv4_rcv() doing clone\n");
skb2 = skb_clone(skb, GFP_ATOMIC);
if (!skb2)
return -ENOMEM;
+printk("+++ br_multicast_ipv4_rcv() and pskb_trim_rcsum\n");
err = pskb_trim_rcsum(skb2, len);
if (err)
goto err_out;
@@ -1405,14 +1415,20 @@ static int br_multicast_ipv4_rcv(struct net_bridge *br,
if (!pskb_may_pull(skb2, sizeof(*ih)))
goto out;
+printk("+++ br_multicast_ipv4_rcv() 2) skb2->len: %i len: %i skb->len: %i\n", skb2->len, len, skb->len);
switch (skb2->ip_summed) {
case CHECKSUM_COMPLETE:
+printk("+++ br_multicast_ipv4_rcv() here 1.6\n");
if (!csum_fold(skb2->csum))
break;
/* fall through */
case CHECKSUM_NONE:
+printk("+++ br_multicast_ipv4_rcv() here 1.7, skb2->csum is %x\n", skb2->csum);
+ __sum16 foobar;
skb2->csum = 0;
- if (skb_checksum_complete(skb2))
+ foobar = skb_checksum_complete(skb2);
+printk("+++ br_multicast_ipv4_rcv() here 1.8, skb_checksum_complete: %x\n", foobar);
+ if (foobar)
goto out;
}
@@ -1459,6 +1475,7 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
int offset;
int err;
+printk("+++ br_multicast_ipv6_rcv()\n");
if (!pskb_may_pull(skb, sizeof(*ip6h)))
return -EINVAL;
@@ -1476,6 +1493,7 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
return 0;
len = ntohs(ip6h->payload_len);
+// len = ntohs(ip6h->payload_len) + sizeof(*ip6h); <- should probably be this?
if (skb->len < len)
return -EINVAL;
@@ -1485,6 +1503,7 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
if (offset < 0 || nexthdr != IPPROTO_ICMPV6)
return 0;
+printk("+++ br_multicast_ipv6_rcv() here 0.5\n");
/* Okay, we found ICMPv6 header */
skb2 = skb_clone(skb, GFP_ATOMIC);
if (!skb2)
@@ -1494,7 +1513,9 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
if (!pskb_may_pull(skb2, offset + sizeof(struct icmp6hdr)))
goto out;
+printk("+++ br_multicast_ipv6_rcv() len: %i, offset: %i, skb_network_offset(skb2): %i\n", len, offset, skb_network_offset(skb2));
len -= offset - skb_network_offset(skb2);
+printk("+++ br_multicast_ipv6_rcv() new len: %i\n", len);
__skb_pull(skb2, offset);
skb_reset_transport_header(skb2);
@@ -1513,27 +1534,37 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
}
/* Okay, we found MLD message. Check further. */
+printk("+++ br_multicast_ipv6_rcv() skb2->len: %i len: %i skb->len: %i\n", skb2->len, len, skb->len);
if (skb2->len > len) {
+printk("+++ br_multicast_ipv6_rcv() doing pskb_trim_rcsum\n");
err = pskb_trim_rcsum(skb2, len);
if (err)
goto out;
}
+printk("+++ br_multicast_ipv6_rcv() here 1.5\n");
switch (skb2->ip_summed) {
case CHECKSUM_COMPLETE:
+printk("+++ br_multicast_ipv6_rcv() here 1.6\n");
if (!csum_fold(skb2->csum))
break;
/*FALLTHROUGH*/
case CHECKSUM_NONE:
+printk("+++ br_multicast_ipv6_rcv() here 1.7, skb2->csum is %x\n", skb2->csum);
+ __sum16 foobar;
skb2->csum = 0;
- if (skb_checksum_complete(skb2))
+ foobar = skb_checksum_complete(skb2);
+ if (foobar) {
+printk("+++ br_multicast_ipv6_rcv() here 1.8, skb_checksum_complete(skb2): %x (skb): %x\n", foobar, skb_checksum_complete(skb));
goto out;
+ }
}
err = 0;
BR_INPUT_SKB_CB(skb)->igmp = 1;
+printk("+++ br_multicast_ipv6_rcv() here 2\n");
switch (icmp6h->icmp6_type) {
case ICMPV6_MGM_REPORT:
{
[-- Attachment #4: ipv4-group-join.cap --]
[-- Type: application/cap, Size: 164 bytes --]
[-- Attachment #5: ipv6-group-join.cap --]
[-- Type: application/cap, Size: 236 bytes --]
^ permalink raw reply related
* Re: [PATCH 2/3] tg3: Don't use IRQF_SAMPLE_RANDOM
From: Dan Carpenter @ 2011-03-27 3:08 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Matt Carlson, Michael Chan, netdev, kernel-janitors
In-Reply-To: <1301193753-10045-2-git-send-email-martinez.javier@gmail.com>
On Sun, Mar 27, 2011 at 04:42:32AM +0200, Javier Martinez Canillas wrote:
> This flag is scheduled for removal so we shouldn't used it.
>
> Signed-off-by: Javier Martinez Canillas <martinez.javier@gmail.com>
> ---
> drivers/net/tg3.c | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index c67eb19..58c6049 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -8844,12 +8844,11 @@ static int tg3_request_irq(struct tg3 *tp, int irq_num)
> fn = tg3_msi;
> if (tp->tg3_flags2 & TG3_FLG2_1SHOT_MSI)
> fn = tg3_msi_1shot;
> - flags = IRQF_SAMPLE_RANDOM;
You need initialize flags to zero here. Apparently gcc doesn't catch
this. I'm using gcc 4.4.3-4ubuntu5.
regards,
dan carpenter
v
> } else {
> fn = tg3_interrupt;
> if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)
> fn = tg3_interrupt_tagged;
> - flags = IRQF_SHARED | IRQF_SAMPLE_RANDOM;
> + flags = IRQF_SHARED;
> }
>
> return request_irq(tnapi->irq_vec, fn, flags, name, tnapi);
^ permalink raw reply
* [PATCH 3/3] tg3: Fix inline keyword usage
From: Javier Martinez Canillas @ 2011-03-27 2:42 UTC (permalink / raw)
To: Matt Carlson
Cc: Michael Chan, netdev, kernel-janitors, Javier Martinez Canillas
In-Reply-To: <1301193753-10045-1-git-send-email-martinez.javier@gmail.com>
The correct usage is "static inline void" not "static void inline".
Signed-off-by: Javier Martinez Canillas <martinez.javier@gmail.com>
---
drivers/net/tg3.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 58c6049..d7e564d 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -13061,7 +13061,7 @@ done:
static struct pci_dev * __devinit tg3_find_peer(struct tg3 *);
-static void inline vlan_features_add(struct net_device *dev, unsigned long flags)
+static inline void vlan_features_add(struct net_device *dev, unsigned long flags)
{
dev->vlan_features |= flags;
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/3] tg3: Don't use IRQF_SAMPLE_RANDOM
From: Javier Martinez Canillas @ 2011-03-27 2:42 UTC (permalink / raw)
To: Matt Carlson
Cc: Michael Chan, netdev, kernel-janitors, Javier Martinez Canillas
In-Reply-To: <1301193753-10045-1-git-send-email-martinez.javier@gmail.com>
This flag is scheduled for removal so we shouldn't used it.
Signed-off-by: Javier Martinez Canillas <martinez.javier@gmail.com>
---
drivers/net/tg3.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index c67eb19..58c6049 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -8844,12 +8844,11 @@ static int tg3_request_irq(struct tg3 *tp, int irq_num)
fn = tg3_msi;
if (tp->tg3_flags2 & TG3_FLG2_1SHOT_MSI)
fn = tg3_msi_1shot;
- flags = IRQF_SAMPLE_RANDOM;
} else {
fn = tg3_interrupt;
if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)
fn = tg3_interrupt_tagged;
- flags = IRQF_SHARED | IRQF_SAMPLE_RANDOM;
+ flags = IRQF_SHARED;
}
return request_irq(tnapi->irq_vec, fn, flags, name, tnapi);
@@ -8880,7 +8879,7 @@ static int tg3_test_interrupt(struct tg3 *tp)
}
err = request_irq(tnapi->irq_vec, tg3_test_isr,
- IRQF_SHARED | IRQF_SAMPLE_RANDOM, dev->name, tnapi);
+ IRQF_SHARED, dev->name, tnapi);
if (err)
return err;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/3] tg3: use <linux/io.h> and <linux/uaccess.h> instead <asm/io.h> and <asm/uaccess.h>
From: Javier Martinez Canillas @ 2011-03-27 2:42 UTC (permalink / raw)
To: Matt Carlson
Cc: Michael Chan, netdev, kernel-janitors, Javier Martinez Canillas
It is proper style to include linux/foo.h instead asm/foo.h if both exist
Signed-off-by: Javier Martinez Canillas <martinez.javier@gmail.com>
---
drivers/net/tg3.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 6be4185..4410d73 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -48,9 +48,9 @@
#include <net/ip.h>
#include <asm/system.h>
-#include <asm/io.h>
+#include <linux/io.h>
#include <asm/byteorder.h>
-#include <asm/uaccess.h>
+#include <linux/uaccess.h>
#ifdef CONFIG_SPARC
#include <asm/idprom.h>
--
1.7.2.3
^ permalink raw reply related
* Re: [RFC PATCH] rtl8187: Fix led support for rfkill
From: Hin-Tak Leung @ 2011-03-27 0:55 UTC (permalink / raw)
To: wu zhangjin
Cc: Herton Ronaldo Krzesinski, Larry Finger,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Roman Mamedov
In-Reply-To: <AANLkTind3Va9J_tvZBDAPfbuyQtgxoAE+ZzG6VpU1b1q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
wu zhangjin wrote:
> On Sun, Mar 27, 2011 at 5:33 AM, Hin-Tak Leung
> <htl10-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> wrote:
>> Wu Zhangjin wrote:
>>> led can not be turned off normally when rfkill is blocked, the cause is
>>> the led_turn_off() function exit as not expected:
>> Hmm. While this sounds more sensible, is it needed? And what does the
>> windows driver do?
>>
>> I think there are two kind of LEDs - one that comes on and off with the
>> rfkill switch; Larry or Herton makes the 2nd one, if there is one, blink
>> while there is traffic (and stay steady on otherwise).
>
> I have used this driver on the YeeLoong netbook(only support Linux),
> there is only one LED for rtl8187, when there is traffic, it blinks
> perfectly, but If press the hotkey to turn off the rf, the network
> interface is down, but the LED is still light, then, the users may
> mistakenly think the hotkey or rfkill support doesn't work or simply
> think the interface is still on. So, that's why we may need to fix it.
My laptop (a Toshiba one) has the other kind of LED - the LED only comes on and
off in relation to the rfkill switch, and does not blink with traffic. I think
Herton or Larry has some devices with both types.
Hmm, I seem to have the impression that there is code somewhere for switching a
singular LED's behavior of the driver between one or the other, by echo'ing into
sysfs or some other trickery? Or would that be a desired approach if that's not
done at the moment?
>
> Regards,
> Wu Zhangjin
>
>>> drivers/net/wireless/rtl818x/rtl8187/leds.c:
>>>
>>> static void led_turn_off(struct work_struct *work)
>>> {
>>> [...]
>>> /* Don't change the LED, when the device is down. */
>>> if (!priv->vif || priv->vif->type == NL80211_IFTYPE_UNSPECIFIED)
>>> return ;
>>> [...]
>>>
>>> When rfkill is blocked, the function calling order looks like this:
>>>
>>> net/mac80211/iface.c:
>>>
>>> ieee80211_do_stop
>>> -> drv_remove_interface = rtl8187_remove_interface
>>> -> ieee80211_stop_device
>>> -> led_set_brightness
>>> -> led_turn_off
>>> -> drv_stop = rtl8187_stop
>>>
>>> rtl8187_remove_interface() set priv->vif to NULL, so, led_turn_off()
>>> will return and will not be able to turn off the led. delay the setting
>>> of priv->vif to rtl8187_stop() can solve it.
>>>
>>> Signed-off-by: Wu Zhangjin <wuzhangjin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> ---
>>> drivers/net/wireless/rtl818x/rtl8187/dev.c | 8 ++++----
>>> 1 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/rtl818x/rtl8187/dev.c
>>> b/drivers/net/wireless/rtl818x/rtl8187/dev.c
>>> index 2bb5297..1fea0cd 100644
>>> --- a/drivers/net/wireless/rtl818x/rtl8187/dev.c
>>> +++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c
>>> @@ -1007,6 +1007,9 @@ static void rtl8187_stop(struct ieee80211_hw *dev)
>>> u32 reg;
>>> mutex_lock(&priv->conf_mutex);
>>> +
>>> + priv->vif = NULL;
>>> +
>>> rtl818x_iowrite16(priv, &priv->map->INT_MASK, 0);
>>> reg = rtl818x_ioread8(priv, &priv->map->CMD);
>>> @@ -1067,10 +1070,7 @@ exit:
>>> static void rtl8187_remove_interface(struct ieee80211_hw *dev,
>>> struct ieee80211_vif *vif)
>>> {
>>> - struct rtl8187_priv *priv = dev->priv;
>>> - mutex_lock(&priv->conf_mutex);
>>> - priv->vif = NULL;
>>> - mutex_unlock(&priv->conf_mutex);
>>> + /* Nothing to do */
>>> }
>>> static int rtl8187_config(struct ieee80211_hw *dev, u32 changed)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ipv4: do not ignore route errors
From: Simon Horman @ 2011-03-27 0:35 UTC (permalink / raw)
To: David Miller; +Cc: ja, netdev
In-Reply-To: <20110325.203338.193726112.davem@davemloft.net>
On Fri, Mar 25, 2011 at 08:33:38PM -0700, David Miller wrote:
> From: Julian Anastasov <ja@ssi.bg>
> Date: Sat, 26 Mar 2011 01:45:25 +0200
>
> > The "ipv4: Inline fib_semantic_match into check_leaf"
> > change forgets to return the route errors. check_leaf should
> > return the same results as fib_table_lookup.
> >
> > Signed-off-by: Julian Anastasov <ja@ssi.bg>
>
> Your mailer corrupted this patch, so I applied it by hand.
I have noticed that Julian's patches usually arrive
with two leading spaces where there should be one but
are otherwise intact. And that its not a new thing,
I can remember seeing this 6 months ago, and I don't think
it was a new thing then either.
Just an observation.
^ permalink raw reply
* Re: [RFC PATCH] rtl8187: Fix led support for rfkill
From: wu zhangjin @ 2011-03-26 22:25 UTC (permalink / raw)
To: Hin-Tak Leung
Cc: Herton Ronaldo Krzesinski, Larry Finger, linux-wireless, netdev,
Roman Mamedov
In-Reply-To: <4D8E5BA3.1090909@users.sourceforge.net>
On Sun, Mar 27, 2011 at 5:33 AM, Hin-Tak Leung
<htl10@users.sourceforge.net> wrote:
> Wu Zhangjin wrote:
>>
>> led can not be turned off normally when rfkill is blocked, the cause is
>> the led_turn_off() function exit as not expected:
>
> Hmm. While this sounds more sensible, is it needed? And what does the
> windows driver do?
>
> I think there are two kind of LEDs - one that comes on and off with the
> rfkill switch; Larry or Herton makes the 2nd one, if there is one, blink
> while there is traffic (and stay steady on otherwise).
I have used this driver on the YeeLoong netbook(only support Linux),
there is only one LED for rtl8187, when there is traffic, it blinks
perfectly, but If press the hotkey to turn off the rf, the network
interface is down, but the LED is still light, then, the users may
mistakenly think the hotkey or rfkill support doesn't work or simply
think the interface is still on. So, that's why we may need to fix it.
Regards,
Wu Zhangjin
>
>>
>> drivers/net/wireless/rtl818x/rtl8187/leds.c:
>>
>> static void led_turn_off(struct work_struct *work)
>> {
>> [...]
>> /* Don't change the LED, when the device is down. */
>> if (!priv->vif || priv->vif->type == NL80211_IFTYPE_UNSPECIFIED)
>> return ;
>> [...]
>>
>> When rfkill is blocked, the function calling order looks like this:
>>
>> net/mac80211/iface.c:
>>
>> ieee80211_do_stop
>> -> drv_remove_interface = rtl8187_remove_interface
>> -> ieee80211_stop_device
>> -> led_set_brightness
>> -> led_turn_off
>> -> drv_stop = rtl8187_stop
>>
>> rtl8187_remove_interface() set priv->vif to NULL, so, led_turn_off()
>> will return and will not be able to turn off the led. delay the setting
>> of priv->vif to rtl8187_stop() can solve it.
>>
>> Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com>
>> ---
>> drivers/net/wireless/rtl818x/rtl8187/dev.c | 8 ++++----
>> 1 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/wireless/rtl818x/rtl8187/dev.c
>> b/drivers/net/wireless/rtl818x/rtl8187/dev.c
>> index 2bb5297..1fea0cd 100644
>> --- a/drivers/net/wireless/rtl818x/rtl8187/dev.c
>> +++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c
>> @@ -1007,6 +1007,9 @@ static void rtl8187_stop(struct ieee80211_hw *dev)
>> u32 reg;
>> mutex_lock(&priv->conf_mutex);
>> +
>> + priv->vif = NULL;
>> +
>> rtl818x_iowrite16(priv, &priv->map->INT_MASK, 0);
>> reg = rtl818x_ioread8(priv, &priv->map->CMD);
>> @@ -1067,10 +1070,7 @@ exit:
>> static void rtl8187_remove_interface(struct ieee80211_hw *dev,
>> struct ieee80211_vif *vif)
>> {
>> - struct rtl8187_priv *priv = dev->priv;
>> - mutex_lock(&priv->conf_mutex);
>> - priv->vif = NULL;
>> - mutex_unlock(&priv->conf_mutex);
>> + /* Nothing to do */
>> }
>> static int rtl8187_config(struct ieee80211_hw *dev, u32 changed)
>
^ permalink raw reply
* Re: [RFC PATCH] rtl8187: Fix led support for rfkill
From: Hin-Tak Leung @ 2011-03-26 21:33 UTC (permalink / raw)
To: Wu Zhangjin
Cc: Herton Ronaldo Krzesinski, Larry Finger,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1301174394-12642-1-git-send-email-wuzhangjin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Wu Zhangjin wrote:
> led can not be turned off normally when rfkill is blocked, the cause is
> the led_turn_off() function exit as not expected:
Hmm. While this sounds more sensible, is it needed? And what does the windows
driver do?
I think there are two kind of LEDs - one that comes on and off with the rfkill
switch; Larry or Herton makes the 2nd one, if there is one, blink while there is
traffic (and stay steady on otherwise).
>
> drivers/net/wireless/rtl818x/rtl8187/leds.c:
>
> static void led_turn_off(struct work_struct *work)
> {
> [...]
> /* Don't change the LED, when the device is down. */
> if (!priv->vif || priv->vif->type == NL80211_IFTYPE_UNSPECIFIED)
> return ;
> [...]
>
> When rfkill is blocked, the function calling order looks like this:
>
> net/mac80211/iface.c:
>
> ieee80211_do_stop
> -> drv_remove_interface = rtl8187_remove_interface
> -> ieee80211_stop_device
> -> led_set_brightness
> -> led_turn_off
> -> drv_stop = rtl8187_stop
>
> rtl8187_remove_interface() set priv->vif to NULL, so, led_turn_off()
> will return and will not be able to turn off the led. delay the setting
> of priv->vif to rtl8187_stop() can solve it.
>
> Signed-off-by: Wu Zhangjin <wuzhangjin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/net/wireless/rtl818x/rtl8187/dev.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/rtl818x/rtl8187/dev.c b/drivers/net/wireless/rtl818x/rtl8187/dev.c
> index 2bb5297..1fea0cd 100644
> --- a/drivers/net/wireless/rtl818x/rtl8187/dev.c
> +++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c
> @@ -1007,6 +1007,9 @@ static void rtl8187_stop(struct ieee80211_hw *dev)
> u32 reg;
>
> mutex_lock(&priv->conf_mutex);
> +
> + priv->vif = NULL;
> +
> rtl818x_iowrite16(priv, &priv->map->INT_MASK, 0);
>
> reg = rtl818x_ioread8(priv, &priv->map->CMD);
> @@ -1067,10 +1070,7 @@ exit:
> static void rtl8187_remove_interface(struct ieee80211_hw *dev,
> struct ieee80211_vif *vif)
> {
> - struct rtl8187_priv *priv = dev->priv;
> - mutex_lock(&priv->conf_mutex);
> - priv->vif = NULL;
> - mutex_unlock(&priv->conf_mutex);
> + /* Nothing to do */
> }
>
> static int rtl8187_config(struct ieee80211_hw *dev, u32 changed)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* [RFC PATCH] rtl8187: Fix led support for rfkill
From: Wu Zhangjin @ 2011-03-26 21:19 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski, Hin-Tak Leung, Larry Finger
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Wu Zhangjin
led can not be turned off normally when rfkill is blocked, the cause is
the led_turn_off() function exit as not expected:
drivers/net/wireless/rtl818x/rtl8187/leds.c:
static void led_turn_off(struct work_struct *work)
{
[...]
/* Don't change the LED, when the device is down. */
if (!priv->vif || priv->vif->type == NL80211_IFTYPE_UNSPECIFIED)
return ;
[...]
When rfkill is blocked, the function calling order looks like this:
net/mac80211/iface.c:
ieee80211_do_stop
-> drv_remove_interface = rtl8187_remove_interface
-> ieee80211_stop_device
-> led_set_brightness
-> led_turn_off
-> drv_stop = rtl8187_stop
rtl8187_remove_interface() set priv->vif to NULL, so, led_turn_off()
will return and will not be able to turn off the led. delay the setting
of priv->vif to rtl8187_stop() can solve it.
Signed-off-by: Wu Zhangjin <wuzhangjin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/wireless/rtl818x/rtl8187/dev.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8187/dev.c b/drivers/net/wireless/rtl818x/rtl8187/dev.c
index 2bb5297..1fea0cd 100644
--- a/drivers/net/wireless/rtl818x/rtl8187/dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c
@@ -1007,6 +1007,9 @@ static void rtl8187_stop(struct ieee80211_hw *dev)
u32 reg;
mutex_lock(&priv->conf_mutex);
+
+ priv->vif = NULL;
+
rtl818x_iowrite16(priv, &priv->map->INT_MASK, 0);
reg = rtl818x_ioread8(priv, &priv->map->CMD);
@@ -1067,10 +1070,7 @@ exit:
static void rtl8187_remove_interface(struct ieee80211_hw *dev,
struct ieee80211_vif *vif)
{
- struct rtl8187_priv *priv = dev->priv;
- mutex_lock(&priv->conf_mutex);
- priv->vif = NULL;
- mutex_unlock(&priv->conf_mutex);
+ /* Nothing to do */
}
static int rtl8187_config(struct ieee80211_hw *dev, u32 changed)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] ceph: fix possible NULL pointer dereference
From: Sage Weil @ 2011-03-26 20:48 UTC (permalink / raw)
To: Mariusz Kozlowski; +Cc: David S. Miller, ceph-devel, netdev, linux-kernel
In-Reply-To: <1301164174-8597-1-git-send-email-mk@lab.zgora.pl>
Applied, thanks!
sage
On Sat, 26 Mar 2011, Mariusz Kozlowski wrote:
> This patch fixes 'event_work' dereference before it is checked for NULL.
>
> Signed-off-by: Mariusz Kozlowski <mk@lab.zgora.pl>
> ---
> net/ceph/osd_client.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c
> index 02212ed..b6776cb 100644
> --- a/net/ceph/osd_client.c
> +++ b/net/ceph/osd_client.c
> @@ -1602,11 +1602,11 @@ void handle_watch_notify(struct ceph_osd_client *osdc, struct ceph_msg *msg)
> cookie, ver, event);
> if (event) {
> event_work = kmalloc(sizeof(*event_work), GFP_NOIO);
> - INIT_WORK(&event_work->work, do_event_work);
> if (!event_work) {
> dout("ERROR: could not allocate event_work\n");
> goto done_err;
> }
> + INIT_WORK(&event_work->work, do_event_work);
> event_work->event = event;
> event_work->ver = ver;
> event_work->notify_id = notify_id;
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" 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: [Bonding-devel] bonding inside a bridge does not work when using arp monitoring
From: Nicolas de Pesloüan @ 2011-03-26 20:32 UTC (permalink / raw)
To: Michał Mirosław, Leonardo Borda
Cc: Jiri Pirko, Nicolas de Pesloüan, Bridge, bonding-devel,
netdev@vger.kernel.org
In-Reply-To: <AANLkTimkVqHaU=Ye96xK4Zs7XyzcL3Xgh5ouz5m2KXur@mail.gmail.com>
Le 26/03/2011 16:42, Michał Mirosław a écrit :
> 2011/3/26 Jiri Pirko<jpirko@redhat.com>:
>> Sat, Mar 26, 2011 at 01:20:22PM CET, nicolas.2p.debian@gmail.com wrote:
>>> Le 23/03/2011 22:13, Leonardo Borda a écrit :
>>>> Thank you for answering my question.
>>>> Actually this is what I want to achieve:
>>>>
>>>> eth0----+ +----bond0.100----br0-100---{+virtual machines
>>>> | |
>>>> +----bond0----+----br0---(LAN)
>>>> | |
>>>> eth1----+ +----bond0.200----br0-200---{+virtual machines
>>>
>>> Hi Leonardo,
>>>
>>> I'm not sure recent kernels allow for a given interface to be a port
>>> for a bridge and the base interface for vlan interfaces at the same
>>> time. This might be particularly true for 2.6.38 or 2.6.38+, because
>>> of the new rx_handler usage.
>>
>> This topology is not legit and should/will be prohibited.
>>
>> Only consider that you have + br0.100 device on top of br0. Where should
>> the packet go?
>>
>> I suggest to consider topology change.
>
> It should be possible to have bridge for untagged (or 802.1p only)
> packets independent of 802.1q tagged packets. I wonder if tag 0
> devices should be expanded to have a flag that will enable handling
> untagged packets by it.
Isn't the BROUTING chain of the broute table of ebtables designed exactly for that?
I think DROPing in this chain should allow delivery to VLAN:
In br_input.c :
rhook = rcu_dereference(br_should_route_hook);
if (rhook) {
if ((*rhook)(skb)) {
*pskb = skb;
return RX_HANDLER_PASS;
}
RX_HANDLER_PASS causes the skb to be normally delivered in __netif_receive_skb.
Leonardo, would you please try to DROP vlan tagged packets in the BROUTING chain of the broute table
of ebtables?
Nicolas.
^ permalink raw reply
* Re: [PATCH] Bridge allows the userspace to configure the bridge parameters with values not defined in the IEEE 802.1D std
From: Sasikanth V @ 2011-03-26 18:31 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, bridge
In-Reply-To: <20110326085536.1ef03edb@nehalam>
[-- Attachment #1.1: Type: text/plain, Size: 793 bytes --]
On Sat, Mar 26, 2011 at 9:25 PM, Stephen Hemminger <
shemminger@linux-foundation.org> wrote:
> On Sat, 26 Mar 2011 20:19:57 +0530
> Sasikanth V <sasikanth.v19@gmail.com> wrote:
>
> >
> > Signed-off-by: Sasikanth V <sasikanth.v19@gmail.com>
> > ---
>
> I will clean this up. There are things like introducing
> global function names (set_forward_delay, etc) that need
> to be fixed.
>
Thanks for looking at the patch. I made 5 set functions
(set_forward_delay, set_max_age,
set_hello_time, set_priority and set_ageing_time) in br_sysfs_br.c global
to use in br_ioctl.c to
avoid code duplication (but it looks it is not a good idea).
Now i thought something like making those 5 functions static inline and
moving it to br_private.h.
If this is fine , I will resend the patch
[-- Attachment #1.2: Type: text/html, Size: 1292 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Bridge mailing list
Bridge@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/bridge
^ permalink raw reply
* [PATCH] ceph: fix possible NULL pointer dereference
From: Mariusz Kozlowski @ 2011-03-26 18:29 UTC (permalink / raw)
To: Sage Weil
Cc: David S. Miller, ceph-devel, netdev, linux-kernel,
Mariusz Kozlowski
This patch fixes 'event_work' dereference before it is checked for NULL.
Signed-off-by: Mariusz Kozlowski <mk@lab.zgora.pl>
---
net/ceph/osd_client.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c
index 02212ed..b6776cb 100644
--- a/net/ceph/osd_client.c
+++ b/net/ceph/osd_client.c
@@ -1602,11 +1602,11 @@ void handle_watch_notify(struct ceph_osd_client *osdc, struct ceph_msg *msg)
cookie, ver, event);
if (event) {
event_work = kmalloc(sizeof(*event_work), GFP_NOIO);
- INIT_WORK(&event_work->work, do_event_work);
if (!event_work) {
dout("ERROR: could not allocate event_work\n");
goto done_err;
}
+ INIT_WORK(&event_work->work, do_event_work);
event_work->event = event;
event_work->ver = ver;
event_work->notify_id = notify_id;
--
1.7.0.4
^ permalink raw reply related
* [PATCH] cfg80211:: fix possible NULL pointer dereference
From: Mariusz Kozlowski @ 2011-03-26 18:26 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, David S. Miller, linux-wireless, netdev,
linux-kernel, Mariusz Kozlowski
In cfg80211_inform_bss_frame() wiphy is first dereferenced on privsz
initialisation and then it is checked for NULL. This patch fixes that.
Signed-off-by: Mariusz Kozlowski <mk@lab.zgora.pl>
---
net/wireless/scan.c | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index ea427f4..300c11d 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -585,16 +585,23 @@ cfg80211_inform_bss_frame(struct wiphy *wiphy,
struct cfg80211_internal_bss *res;
size_t ielen = len - offsetof(struct ieee80211_mgmt,
u.probe_resp.variable);
- size_t privsz = wiphy->bss_priv_size;
+ size_t privsz;
+
+ if (WARN_ON(!mgmt))
+ return NULL;
+
+ if (WARN_ON(!wiphy))
+ return NULL;
if (WARN_ON(wiphy->signal_type == CFG80211_SIGNAL_TYPE_UNSPEC &&
(signal < 0 || signal > 100)))
return NULL;
- if (WARN_ON(!mgmt || !wiphy ||
- len < offsetof(struct ieee80211_mgmt, u.probe_resp.variable)))
+ if (WARN_ON(len < offsetof(struct ieee80211_mgmt, u.probe_resp.variable)))
return NULL;
+ privsz = wiphy->bss_priv_size;
+
res = kzalloc(sizeof(*res) + privsz + ielen, gfp);
if (!res)
return NULL;
--
1.7.0.4
^ permalink raw reply related
* [PATCH] mac80211: fix possible NULL pointer dereference
From: Mariusz Kozlowski @ 2011-03-26 17:58 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, David S. Miller, linux-wireless, netdev,
linux-kernel, Mariusz Kozlowski
This patch moves 'key' dereference after BUG_ON(!key) so that when key is NULL
we will see proper trace instead of oops.
Signed-off-by: Mariusz Kozlowski <mk@lab.zgora.pl>
---
net/mac80211/key.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index 8c02469..fd97925 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -400,11 +400,12 @@ int ieee80211_key_link(struct ieee80211_key *key,
{
struct ieee80211_key *old_key;
int idx, ret;
- bool pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
+ bool pairwise;
BUG_ON(!sdata);
BUG_ON(!key);
+ pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
idx = key->conf.keyidx;
key->local = sdata->local;
key->sdata = sdata;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Bridge allows the userspace to configure the bridge parameters with values not defined in the IEEE 802.1D std
From: Stephen Hemminger @ 2011-03-26 15:55 UTC (permalink / raw)
To: Sasikanth V; +Cc: bridge, netdev
In-Reply-To: <1301150997-4639-1-git-send-email-sasikanth.v19@gmail.com>
On Sat, 26 Mar 2011 20:19:57 +0530
Sasikanth V <sasikanth.v19@gmail.com> wrote:
>
> Signed-off-by: Sasikanth V <sasikanth.v19@gmail.com>
> ---
I will clean this up. There are things like introducing
global function names (set_forward_delay, etc) that need
to be fixed.
^ permalink raw reply
* Re: Kernel panic nf_nat_setup_info+0x5b3/0x6e0
From: Changli Gao @ 2011-03-26 15:44 UTC (permalink / raw)
To: Oleg A. Arkhangelsky
Cc: Patrick McHardy, netfilter-devel, netdev, Paul E McKenney
In-Reply-To: <AANLkTik87dd0=CqcMOcwKN-Hx7W6KD7A36DUhGAzLddr@mail.gmail.com>
On Thu, Mar 3, 2011 at 3:33 PM, Changli Gao <xiaosuo@gmail.com> wrote:
> Please try the patch attached and test if the problem is solved or not. Thanks.
>
Any feedback? Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [Bonding-devel] bonding inside a bridge does not work when using arp monitoring
From: Michał Mirosław @ 2011-03-26 15:42 UTC (permalink / raw)
To: Jiri Pirko
Cc: Nicolas de Pesloüan, Leonardo Borda,
Nicolas de Pesloüan, Bridge, bonding-devel,
netdev@vger.kernel.org
In-Reply-To: <20110326140115.GA2882@psychotron.redhat.com>
2011/3/26 Jiri Pirko <jpirko@redhat.com>:
> Sat, Mar 26, 2011 at 01:20:22PM CET, nicolas.2p.debian@gmail.com wrote:
>>Le 23/03/2011 22:13, Leonardo Borda a écrit :
>>>Thank you for answering my question.
>>>Actually this is what I want to achieve:
>>>
>>>eth0----+ +----bond0.100----br0-100---{+virtual machines
>>> | |
>>> +----bond0----+----br0---(LAN)
>>> | |
>>>eth1----+ +----bond0.200----br0-200---{+virtual machines
>>
>>Hi Leonardo,
>>
>>I'm not sure recent kernels allow for a given interface to be a port
>>for a bridge and the base interface for vlan interfaces at the same
>>time. This might be particularly true for 2.6.38 or 2.6.38+, because
>>of the new rx_handler usage.
>
> This topology is not legit and should/will be prohibited.
>
> Only consider that you have + br0.100 device on top of br0. Where should
> the packet go?
>
> I suggest to consider topology change.
It should be possible to have bridge for untagged (or 802.1p only)
packets independent of 802.1q tagged packets. I wonder if tag 0
devices should be expanded to have a flag that will enable handling
untagged packets by it.
Best Regards,
Michał Mirosław
^ permalink raw reply
* [PATCH] net: use CHECKSUM_NONE instead of magic number
From: Cesar Eduardo Barros @ 2011-03-26 15:10 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet,
Tristram Ha, linux-kernel, Cesar Eduardo Barros
Two places in the kernel were doing skb->ip_summed = 0.
Change both to skb->ip_summed = CHECKSUM_NONE, which is more readable.
Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
---
drivers/net/ksz884x.c | 2 +-
net/ipv6/ip6mr.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ksz884x.c b/drivers/net/ksz884x.c
index 540a8dc..7f7d570 100644
--- a/drivers/net/ksz884x.c
+++ b/drivers/net/ksz884x.c
@@ -4898,7 +4898,7 @@ static netdev_tx_t netdev_tx(struct sk_buff *skb, struct net_device *dev)
goto unlock;
}
skb_copy_and_csum_dev(org_skb, skb->data);
- org_skb->ip_summed = 0;
+ org_skb->ip_summed = CHECKSUM_NONE;
skb->len = org_skb->len;
copy_old_skb(org_skb, skb);
}
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 7ff0343..29e4859 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -663,7 +663,7 @@ static int pim6_rcv(struct sk_buff *skb)
skb_pull(skb, (u8 *)encap - skb->data);
skb_reset_network_header(skb);
skb->protocol = htons(ETH_P_IPV6);
- skb->ip_summed = 0;
+ skb->ip_summed = CHECKSUM_NONE;
skb->pkt_type = PACKET_HOST;
skb_tunnel_rx(skb, reg_dev);
--
1.7.4
^ permalink raw reply related
* [PATCH] Bridge allows the userspace to configure the bridge parameters with values not defined in the IEEE 802.1D std
From: Sasikanth V @ 2011-03-26 14:49 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: bridge, netdev, Sasikanth V
Signed-off-by: Sasikanth V <sasikanth.v19@gmail.com>
---
include/linux/if_bridge.h | 28 +++++++++++++++
net/bridge/br_ioctl.c | 35 +++++++-----------
net/bridge/br_private.h | 7 +++-
net/bridge/br_stp_if.c | 7 +++-
net/bridge/br_sysfs_br.c | 83 ++++++++++++++++++++++++++++++++++++---------
net/bridge/br_sysfs_if.c | 3 +-
6 files changed, 122 insertions(+), 41 deletions(-)
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index dd3f201..9c6cc49 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -49,6 +49,34 @@
#define BR_STATE_FORWARDING 3
#define BR_STATE_BLOCKING 4
+/*802.1D STP compatibility Range*/
+#define BR_DEFAULT_BRIDGE_PRIORITY 32768
+#define BR_MIN_BRIDGE_PRIORITY 0
+#define BR_MAX_BRIDGE_PRIORITY 65535
+
+#define BR_DEFAULT_PORT_PRIORITY 128
+#define BR_MIN_PORT_PRIORITY 0
+#define BR_MAX_PORT_PRIORITY 240
+
+#define BR_MIN_PATH_COST 1
+#define BR_MAX_PATH_COST 200000000
+
+#define BR_DEFAULT_HELLO_TIME 2
+#define BR_MIN_HELLO_TIME 1
+#define BR_MAX_HELLO_TIME 10
+
+#define BR_DEFAULT_MAX_AGE 20
+#define BR_MIN_MAX_AGE 6
+#define BR_MAX_MAX_AGE 40
+
+#define BR_DEFAULT_FORWARD_DELAY 15
+#define BR_MIN_FORWARD_DELAY 2
+#define BR_MAX_FORWARD_DELAY 30
+
+#define BR_DEFAULT_AGEING_TIME 300
+#define BR_MIN_AGEING_TIME 10
+#define BR_MAX_AGEING_TIME 1000000
+
struct __bridge_info {
__u64 designated_root;
__u64 bridge_id;
diff --git a/net/bridge/br_ioctl.c b/net/bridge/br_ioctl.c
index cb43312..72cf6b6 100644
--- a/net/bridge/br_ioctl.c
+++ b/net/bridge/br_ioctl.c
@@ -112,6 +112,7 @@ static int old_dev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
struct net_bridge *br = netdev_priv(dev);
unsigned long args[4];
+ int rval = 0;
if (copy_from_user(args, rq->ifr_data, sizeof(args)))
return -EFAULT;
@@ -182,27 +183,19 @@ static int old_dev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
return -EPERM;
spin_lock_bh(&br->lock);
- br->bridge_forward_delay = clock_t_to_jiffies(args[1]);
- if (br_is_root_bridge(br))
- br->forward_delay = br->bridge_forward_delay;
+ rval = set_forward_delay (br, args[1]);
spin_unlock_bh(&br->lock);
- return 0;
+ return rval;
case BRCTL_SET_BRIDGE_HELLO_TIME:
{
- unsigned long t = clock_t_to_jiffies(args[1]);
if (!capable(CAP_NET_ADMIN))
return -EPERM;
- if (t < HZ)
- return -EINVAL;
-
spin_lock_bh(&br->lock);
- br->bridge_hello_time = t;
- if (br_is_root_bridge(br))
- br->hello_time = br->bridge_hello_time;
+ rval = set_hello_time (br, args[1]);
spin_unlock_bh(&br->lock);
- return 0;
+ return rval;
}
case BRCTL_SET_BRIDGE_MAX_AGE:
@@ -210,18 +203,18 @@ static int old_dev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
return -EPERM;
spin_lock_bh(&br->lock);
- br->bridge_max_age = clock_t_to_jiffies(args[1]);
- if (br_is_root_bridge(br))
- br->max_age = br->bridge_max_age;
+ rval = set_max_age (br, args[1]);
spin_unlock_bh(&br->lock);
- return 0;
+ return rval;
case BRCTL_SET_AGEING_TIME:
if (!capable(CAP_NET_ADMIN))
return -EPERM;
- br->ageing_time = clock_t_to_jiffies(args[1]);
- return 0;
+ spin_lock_bh(&br->lock);
+ rval = set_ageing_time (br, args[1]);
+ spin_unlock_bh(&br->lock);
+ return rval;
case BRCTL_GET_PORT_INFO:
{
@@ -268,9 +261,9 @@ static int old_dev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
return -EPERM;
spin_lock_bh(&br->lock);
- br_stp_set_bridge_priority(br, args[1]);
+ rval = set_priority (br, args[1]);
spin_unlock_bh(&br->lock);
- return 0;
+ return rval;
case BRCTL_SET_PORT_PRIORITY:
{
@@ -303,7 +296,7 @@ static int old_dev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
if ((p = br_get_port(br, args[1])) == NULL)
ret = -EINVAL;
else
- br_stp_set_path_cost(p, args[2]);
+ ret = br_stp_set_path_cost(p, args[2]);
return ret;
}
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 19e2f46..87dd054 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -503,7 +503,7 @@ extern void br_stp_set_bridge_priority(struct net_bridge *br,
u16 newprio);
extern void br_stp_set_port_priority(struct net_bridge_port *p,
u8 newprio);
-extern void br_stp_set_path_cost(struct net_bridge_port *p,
+extern int br_stp_set_path_cost(struct net_bridge_port *p,
u32 path_cost);
extern ssize_t br_show_bridge_id(char *buf, const struct bridge_id *id);
@@ -536,6 +536,11 @@ extern int br_sysfs_renameif(struct net_bridge_port *p);
/* br_sysfs_br.c */
extern int br_sysfs_addbr(struct net_device *dev);
extern void br_sysfs_delbr(struct net_device *dev);
+extern int set_forward_delay(struct net_bridge *br, unsigned long val);
+extern int set_max_age(struct net_bridge *br, unsigned long val);
+extern int set_hello_time(struct net_bridge *br, unsigned long val);
+extern int set_priority(struct net_bridge *br, unsigned long val);
+extern int set_ageing_time(struct net_bridge *br, unsigned long val);
#else
diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index 79372d4..6b9923c 100644
--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
@@ -269,11 +269,16 @@ void br_stp_set_port_priority(struct net_bridge_port *p, u8 newprio)
}
/* called under bridge lock */
-void br_stp_set_path_cost(struct net_bridge_port *p, u32 path_cost)
+int br_stp_set_path_cost(struct net_bridge_port *p, u32 path_cost)
{
+ if (path_cost < BR_MIN_PATH_COST &&
+ path_cost > BR_MAX_PATH_COST)
+ return -ERANGE;
+
p->path_cost = path_cost;
br_configuration_update(p->br);
br_port_state_selection(p->br);
+ return 0;
}
ssize_t br_show_bridge_id(char *buf, const struct bridge_id *id)
diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
index 5c1e555..31a09c5 100644
--- a/net/bridge/br_sysfs_br.c
+++ b/net/bridge/br_sysfs_br.c
@@ -57,12 +57,25 @@ static ssize_t show_forward_delay(struct device *d,
return sprintf(buf, "%lu\n", jiffies_to_clock_t(br->forward_delay));
}
-static int set_forward_delay(struct net_bridge *br, unsigned long val)
+int set_forward_delay(struct net_bridge *br, unsigned long val)
{
- unsigned long delay = clock_t_to_jiffies(val);
- br->forward_delay = delay;
+ unsigned long fwd_dly = clock_t_to_jiffies(val) / HZ;
+ unsigned long max_age = br->max_age / HZ;
+
+ if ((fwd_dly < BR_MIN_FORWARD_DELAY) ||
+ (fwd_dly > BR_MAX_FORWARD_DELAY))
+ return -ERANGE;
+
+ /*2 × (Bridge_Forward_Delay – 1.0 seconds) >= Bridge_Max_Age*/
+ if ((2 * (fwd_dly - 1) < (max_age))) {
+ return -EINVAL;
+ }
+
+ fwd_dly *= HZ;
+
+ br->forward_delay = fwd_dly;
if (br_is_root_bridge(br))
- br->bridge_forward_delay = delay;
+ br->bridge_forward_delay = fwd_dly;
return 0;
}
@@ -82,16 +95,25 @@ static ssize_t show_hello_time(struct device *d, struct device_attribute *attr,
jiffies_to_clock_t(to_bridge(d)->hello_time));
}
-static int set_hello_time(struct net_bridge *br, unsigned long val)
+int set_hello_time(struct net_bridge *br, unsigned long val)
{
- unsigned long t = clock_t_to_jiffies(val);
+ unsigned long hello_time = clock_t_to_jiffies(val) / HZ;
+ unsigned long max_age = br->max_age / HZ;
+
+ if ((hello_time < BR_MIN_HELLO_TIME) ||
+ (hello_time > BR_MAX_HELLO_TIME))
+ return -ERANGE;
- if (t < HZ)
+ /*Bridge_Max_Age >= 2 × (Bridge_Hello_Time + 1.0 seconds)*/
+
+ if (max_age < ( 2 * (hello_time + 1)))
return -EINVAL;
- br->hello_time = t;
+ hello_time *= HZ;
+
+ br->hello_time = hello_time;
if (br_is_root_bridge(br))
- br->bridge_hello_time = t;
+ br->bridge_hello_time = hello_time;
return 0;
}
@@ -111,12 +133,31 @@ static ssize_t show_max_age(struct device *d, struct device_attribute *attr,
jiffies_to_clock_t(to_bridge(d)->max_age));
}
-static int set_max_age(struct net_bridge *br, unsigned long val)
+int set_max_age(struct net_bridge *br, unsigned long val)
{
- unsigned long t = clock_t_to_jiffies(val);
- br->max_age = t;
+ unsigned long max_age = clock_t_to_jiffies(val) / HZ;
+ unsigned long hello_time = br->hello_time / HZ;
+ unsigned long fwd_dly = br->forward_delay / HZ;
+
+ if ((max_age < BR_MIN_MAX_AGE) ||
+ (max_age > BR_MAX_MAX_AGE))
+ return -ERANGE;
+
+ /* To support interoperability with legacy Bridges,
+ a Bridge shall enforce the following relationships
+ 2 × (Bridge_Forward_Delay – 1.0 seconds) >= Bridge_Max_Age
+ Bridge_Max_Age >= 2 × (Bridge_Hello_Time + 1.0 seconds)
+ */
+
+ if ((max_age < ( 2 * (hello_time + 1))) ||
+ (2 * (fwd_dly - 1) < (max_age)))
+ return -EINVAL;
+
+ max_age *= HZ;
+
+ br->max_age = max_age;
if (br_is_root_bridge(br))
- br->bridge_max_age = t;
+ br->bridge_max_age = max_age;
return 0;
}
@@ -134,9 +175,15 @@ static ssize_t show_ageing_time(struct device *d,
return sprintf(buf, "%lu\n", jiffies_to_clock_t(br->ageing_time));
}
-static int set_ageing_time(struct net_bridge *br, unsigned long val)
+int set_ageing_time(struct net_bridge *br, unsigned long val)
{
- br->ageing_time = clock_t_to_jiffies(val);
+ val = clock_t_to_jiffies(val) / HZ;
+
+ if (val < BR_MIN_AGEING_TIME ||
+ val > BR_MAX_AGEING_TIME)
+ return -ERANGE;
+
+ br->ageing_time = val * HZ;
return 0;
}
@@ -190,8 +237,12 @@ static ssize_t show_priority(struct device *d, struct device_attribute *attr,
(br->bridge_id.prio[0] << 8) | br->bridge_id.prio[1]);
}
-static int set_priority(struct net_bridge *br, unsigned long val)
+int set_priority(struct net_bridge *br, unsigned long val)
{
+ if ((val < BR_MIN_BRIDGE_PRIORITY) ||
+ (val > BR_MAX_BRIDGE_PRIORITY))
+ return -ERANGE;
+
br_stp_set_bridge_priority(br, (u16) val);
return 0;
}
diff --git a/net/bridge/br_sysfs_if.c b/net/bridge/br_sysfs_if.c
index fd5799c..6bd4520 100644
--- a/net/bridge/br_sysfs_if.c
+++ b/net/bridge/br_sysfs_if.c
@@ -40,8 +40,7 @@ static ssize_t show_path_cost(struct net_bridge_port *p, char *buf)
}
static ssize_t store_path_cost(struct net_bridge_port *p, unsigned long v)
{
- br_stp_set_path_cost(p, v);
- return 0;
+ return br_stp_set_path_cost(p, v);
}
static BRPORT_ATTR(path_cost, S_IRUGO | S_IWUSR,
show_path_cost, store_path_cost);
--
1.7.3.4
^ permalink raw reply related
* Re: [Bonding-devel] bonding inside a bridge does not work when using arp monitoring
From: Jiri Pirko @ 2011-03-26 14:01 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Leonardo Borda, Nicolas de Pesloüan, Bridge, bonding-devel,
netdev@vger.kernel.org
In-Reply-To: <4D8DDA06.4040704@gmail.com>
Sat, Mar 26, 2011 at 01:20:22PM CET, nicolas.2p.debian@gmail.com wrote:
>Le 23/03/2011 22:13, Leonardo Borda a écrit :
>>Hi Nicolas,
>>
>>Thank you for answering my question.
>>Actually this is what I want to achieve:
>>
>>eth0----+ +----bond0.100----br0-100---{+virtual machines
>> | |
>> +----bond0----+----br0---(LAN)
>> | |
>>eth1----+ +----bond0.200----br0-200---{+virtual machines
>
>Hi Leonardo,
>
>I'm not sure recent kernels allow for a given interface to be a port
>for a bridge and the base interface for vlan interfaces at the same
>time. This might be particularly true for 2.6.38 or 2.6.38+, because
>of the new rx_handler usage.
This topology is not legit and should/will be prohibited.
Only consider that you have + br0.100 device on top of br0. Where should
the packet go?
I suggest to consider topology change.
>
>cc: netdev and Jiri Pirko, for advices. For the history of the thread, see:
>
>http://sourceforge.net/mailarchive/forum.php?thread_name=1300914794.32252.68.camel%40bordalnx&
>forum_name=bonding-devel
>
>>br0 --> br0 in my understanding is an untagged vlan therefore it
>>provides access to my LAN. So i am able to access that server from my
>>internal network.
>>br0-100 and br0-200 -> Vlans over a bridged interface will allow me to
>>have many virtual machines in the same vlan on each bridged interface.
>>
>>I am misunderstanding concepts, maybe?
>>If you need to do further tests I have a test environment ready for use.
>>
>>Leonardo
^ 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