* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Eric Dumazet @ 2010-06-02 16:33 UTC (permalink / raw)
To: Christoph Lameter; +Cc: David Miller, netdev, shemminger
In-Reply-To: <alpine.DEB.2.00.1006021126500.30182@router.home>
Le mercredi 02 juin 2010 à 11:27 -0500, Christoph Lameter a écrit :
> On Wed, 2 Jun 2010, David Miller wrote:
>
> > From: Christoph Lameter <cl@linux-foundation.org>
> > Date: Wed, 2 Jun 2010 11:12:14 -0500 (CDT)
> >
> > > Its important to know why drops occur (any drops for that matter, drops
> > > mean retransmit which means latency).
> >
> > We know, that's why there is a networking tracepoint that allows you
> > to see where all drops occur. :-)
>
> Where can I find out more about the network tracepoint?
>
take a look at
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/html/SystemTap_Beginners_Guide/useful-systemtap-scripts.html#dropwatch
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Christoph Lameter @ 2010-06-02 16:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Stephen Hemminger, David Miller
In-Reply-To: <1275496088.2725.202.camel@edumazet-laptop>
On Wed, 2 Jun 2010, Eric Dumazet wrote:
> Your patch has nothing to do with dropped packets because of rp_filter.
>
> You inserted a counter increment in a path that is not taken at all by
> packet delivery.
>
> Maybe I missed something really obvious with your patch ?
rp_filter rejects a route and packets are dropped then.
> Have you considered CONFIG_NET_DROP_MONITOR ?
> This one catches all possible cases, a developper doesnt have to patch
> his kernel to add SNMP counters everywhere...
Just looking at it. Great. A hook into skb_free. That will do.
^ permalink raw reply
* Re: [PATCH] net/core: Save the port number a netdevice uses
From: Ben Hutchings @ 2010-06-02 16:42 UTC (permalink / raw)
To: David Miller
Cc: Eli Cohen, netdev, linux-rdma, Roland Dreier, Yevgeny Petrilin
In-Reply-To: <20100526.021635.179940939.davem@davemloft.net>
On Wed, 2010-05-26 at 02:16 -0700, David Miller wrote:
> From: Eli Cohen <eli@dev.mellanox.co.il>
> Date: Wed, 26 May 2010 12:08:52 +0300
>
> > So if I understand you correctly, you think that I should not bother
> > to set a default value of 1. Each driver that cares about the value
> > of this field, will set it however they want.
>
> I actually mean that the value "0" should mean the first port,
> the value "1" should mean the second port, etc.
There's a compatibility problem here though: when user-space looks at
this number it can't tell whether "0" really means the first port or
that the driver isn't setting dev_id. In order to tell that it would
have to check the driver or kernel version too, and this is really nasty
(what if the driver was backported?). So I think that 1-based numbering
for drivers that previously didn't set dev_id.
Why does this matter? I'm maintaining the firmware update program for
Solarflare NICs under Linux. Some of the firmware it updates is
per-port and some of it is per-board. It needs to be able to tell which
net and PCI devices are associated with the same board. At the moment
it works on the basis of PCI addresses, but this is unreliable in the
presence of virtualisation. It would be better to use board serial
number and the port identifier that I just changed the driver to use,
but since there are existing driver versions always leave dev_id = 0, I
it needs to be able to tell whether dev_id is meaningful.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: sysfs class/net/ problem
From: Eric W. Biederman @ 2010-06-02 16:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: Greg KH, netdev
In-Reply-To: <1275495677.3915.16.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2010-06-02 at 09:17 -0700, Eric W. Biederman wrote:
>
>> >> Ah, so the network devices aren't getting removed?
>> >
>> > Well the netdevs are gone, just the links aren't going away. the
>> > mac80211_hwsim directory is gone too.
>> >
>> >> Do you have network namespaces enabled in your kernel or disabled?
>> >
>> > enabled
>> >
>> >> And this is 2.6.35-rc1, right?
>> >
>> > yes.
>> >
>> > Come to think of it, maybe somehow it ends up removing
>> > mac80211_hwsim/hwsim0 before wlan0, and thus the link stays around? I
>> > guess I could make it print messages about that somehow?
>>
>> The wireless drivers are a little different, and come to think of it
>> network namespace support has been added to the wireless drivers since
>> last I looked closely.
>
> Yeah, I now need to go add tagged sysfs support to it too.
>
>> Do you know what creates/deletes these links?
>> Is it the normal register_netdevice -> device_add path?
>
> Yes, they aren't done specially.
>> I definitely changed the symlink code a little making things network namespace
>> aware so it is reasonable to assume that something in my changes affected the
>> wireless drivers.
>
>> I took a quick look and with my patches against 2.6.33 I'm not seeing this.
>
> Hmm. I'm also not seeing it with veth, it would seem that ought to be
> similar?
Since it is the register_netdev path it should be exactly the same.
The big change I made is I in some instances I replaced
sysfs_remove_link with sysfs_delete_link so I could have enough
information to infer which network namespace the link was in. Since
wlan0 is a netdevice all of that information should already be there.
>> I take a closer look at 2.6.35-rc1 and see if I can figure out what is
>> going on. It would definitely be wrong if hwsim0 is removed before
>> wlan0.
>
> I don't know if that's happening .. just guessing that it might cause
> such a problem, and maybe some things are deferred somehow? Since netdev
> destruction can be deferred, but the wifi sysfs destruction isn't. But
> then that link there should cause the refcount to not go down until the
> link goes away>?
unregister_netdevice will defer the final destruction but it does not
defer netdev_unregister_kobject -> device_del.
What happens if in exit_mac80211_hwsim you call unregister_netdev before
mac80211_hwsim_free?
At a quick glance it simply looks like you have the ordering reversed in your
module cleanup, and this is not network namespace related at all.
Eric
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Christoph Lameter @ 2010-06-02 16:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, shemminger
In-Reply-To: <1275496439.2725.203.camel@edumazet-laptop>
On Wed, 2 Jun 2010, Eric Dumazet wrote:
> take a look at
>
> http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/html/SystemTap_Beginners_Guide/useful-systemtap-scripts.html#dropwatch
System tap? Oh no. Also skbs may be freed for legitimate reasons. The
point is that the loss detection needs to be usable for a regular mortal.
With the counters in /proc/net/snmp you have something that is easy to
handle.
The approach with systemtap will need lots of work to both get the tracing
environment setup (local competence in systemtap) and participation by a
developer to figure out what the output means. Then there is also the
additional code overhead that you do not want by default in the kernel. So
we would need a different kernel for diagnostics.
^ permalink raw reply
* Re: sysfs class/net/ problem
From: Johannes Berg @ 2010-06-02 17:00 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Greg KH, netdev
In-Reply-To: <m14ohlxu51.fsf@fess.ebiederm.org>
On Wed, 2010-06-02 at 09:43 -0700, Eric W. Biederman wrote:
> > Hmm. I'm also not seeing it with veth, it would seem that ought to be
> > similar?
>
> Since it is the register_netdev path it should be exactly the same.
>
> The big change I made is I in some instances I replaced
> sysfs_remove_link with sysfs_delete_link so I could have enough
> information to infer which network namespace the link was in. Since
> wlan0 is a netdevice all of that information should already be there.
I have no idea :)
> > I don't know if that's happening .. just guessing that it might cause
> > such a problem, and maybe some things are deferred somehow? Since netdev
> > destruction can be deferred, but the wifi sysfs destruction isn't. But
> > then that link there should cause the refcount to not go down until the
> > link goes away>?
>
> unregister_netdevice will defer the final destruction but it does not
> defer netdev_unregister_kobject -> device_del.
>
> What happens if in exit_mac80211_hwsim you call unregister_netdev before
> mac80211_hwsim_free?
>
> At a quick glance it simply looks like you have the ordering reversed in your
> module cleanup, and this is not network namespace related at all.
Nah, the unregister_netdev there removes the "hwsim0" device, while the
mac80211_hwsim_free() will remove all the others, so the ordering of
those two doesn't matter.
johannes
^ permalink raw reply
* Re: [PATCH] net/core: Save the port number a netdevice uses
From: David Miller @ 2010-06-02 17:12 UTC (permalink / raw)
To: bhutchings-s/n/eUQHGBpZroRs9YW3xA
Cc: eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
rdreier-FYB4Gu1CFyUAvxtiuMwx3w, yevgenyp-VPRAkNaXOzVS1MOuV/RT9w
In-Reply-To: <1275496949.2115.18.camel-xQnnTUlwzDrdvaEqJLTMTA9jg9n5Vt1AMm0uRHvK7Nw@public.gmane.org>
From: Ben Hutchings <bhutchings-s/n/eUQHGBpZroRs9YW3xA@public.gmane.org>
Date: Wed, 02 Jun 2010 17:42:29 +0100
> On Wed, 2010-05-26 at 02:16 -0700, David Miller wrote:
>> From: Eli Cohen <eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
>> Date: Wed, 26 May 2010 12:08:52 +0300
>>
>> > So if I understand you correctly, you think that I should not bother
>> > to set a default value of 1. Each driver that cares about the value
>> > of this field, will set it however they want.
>>
>> I actually mean that the value "0" should mean the first port,
>> the value "1" should mean the second port, etc.
>
> There's a compatibility problem here though: when user-space looks at
> this number it can't tell whether "0" really means the first port or
> that the driver isn't setting dev_id.
That's perfect, it means we don't have to add explicit settings to
drivers which driver only one port. Ie. the vast majority of
cases.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: David Miller @ 2010-06-02 17:12 UTC (permalink / raw)
To: cl; +Cc: eric.dumazet, netdev, shemminger
In-Reply-To: <alpine.DEB.2.00.1006021140320.30182@router.home>
From: Christoph Lameter <cl@linux-foundation.org>
Date: Wed, 2 Jun 2010 11:49:18 -0500 (CDT)
> On Wed, 2 Jun 2010, Eric Dumazet wrote:
>
>> take a look at
>>
>> http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/html/SystemTap_Beginners_Guide/useful-systemtap-scripts.html#dropwatch
>
> System tap?
You don't need to use system tap, just the normal tracing stuff using
sysfs files suffices.
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Eric Dumazet @ 2010-06-02 17:19 UTC (permalink / raw)
To: David Miller; +Cc: cl, netdev, shemminger, Neil Horman
In-Reply-To: <20100602.101258.134121018.davem@davemloft.net>
Le mercredi 02 juin 2010 à 10:12 -0700, David Miller a écrit :
> From: Christoph Lameter <cl@linux-foundation.org>
> Date: Wed, 2 Jun 2010 11:49:18 -0500 (CDT)
>
> > On Wed, 2 Jun 2010, Eric Dumazet wrote:
> >
> >> take a look at
> >>
> >> http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/html/SystemTap_Beginners_Guide/useful-systemtap-scripts.html#dropwatch
> >
> > System tap?
>
> You don't need to use system tap, just the normal tracing stuff using
> sysfs files suffices.
>
It would be good if Neil could gave us a man page or something ;)
^ permalink raw reply
* Re: sysfs class/net/ problem
From: Eric W. Biederman @ 2010-06-02 17:23 UTC (permalink / raw)
To: Johannes Berg; +Cc: Greg KH, netdev
In-Reply-To: <1275498007.3915.20.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2010-06-02 at 09:43 -0700, Eric W. Biederman wrote:
>
>> > Hmm. I'm also not seeing it with veth, it would seem that ought to be
>> > similar?
>>
>> Since it is the register_netdev path it should be exactly the same.
>>
>> The big change I made is I in some instances I replaced
>> sysfs_remove_link with sysfs_delete_link so I could have enough
>> information to infer which network namespace the link was in. Since
>> wlan0 is a netdevice all of that information should already be there.
>
> I have no idea :)
>
>> > I don't know if that's happening .. just guessing that it might cause
>> > such a problem, and maybe some things are deferred somehow? Since netdev
>> > destruction can be deferred, but the wifi sysfs destruction isn't. But
>> > then that link there should cause the refcount to not go down until the
>> > link goes away>?
>>
>> unregister_netdevice will defer the final destruction but it does not
>> defer netdev_unregister_kobject -> device_del.
>>
>> What happens if in exit_mac80211_hwsim you call unregister_netdev before
>> mac80211_hwsim_free?
>>
>> At a quick glance it simply looks like you have the ordering reversed in your
>> module cleanup, and this is not network namespace related at all.
>
> Nah, the unregister_netdev there removes the "hwsim0" device, while the
> mac80211_hwsim_free() will remove all the others, so the ordering of
> those two doesn't matter.
So far that hypothesis that the target of the symlink is being removed before
the actual actual link looks like it could cause this.
Are there any other left overs in sysfs, besides just /sys/class/net/wlan0?
Eric
^ permalink raw reply
* Re: [PATCH] net: mac8390 - Sort out memory/MMIO accesses and casts (was: Re: drivers/net/mac8390.c: Remove useless memcpy casting)
From: Geert Uytterhoeven @ 2010-06-02 17:24 UTC (permalink / raw)
To: Finn Thain
Cc: Joe Perches, David S. Miller, netdev, Linux Kernel Mailing List,
Linux/m68k
In-Reply-To: <AANLkTilLXOSb2P_m4uUubmJar2VMFXizzpa_mQ1j8GPz@mail.gmail.com>
On Sat, May 29, 2010 at 10:03, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Fri, May 28, 2010 at 19:21, Finn Thain <fthain@telegraphics.com.au> wrote:
>> On Sun, 23 May 2010, Geert Uytterhoeven wrote:
>>> >> But here's a better solution. I do not have the hardware to test it,
>>> >> though. Finn, does it {look OK,work}?
>>> >
>>> > It looks fine. I can't test it right now, but I will do so when I get
>>> > the opportunity.
>>>
>>> Any news from the test front?
>>
>> This is commit ba0f916ca7ac79356e2ed32a85c3aa8255b104e7, right?
>
> Yep.
>
>> If so, it tests OK here.
>
> Thanks for testing!
David, will you take this one too?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] net: mac8390 - Sort out memory/MMIO accesses and casts
From: David Miller @ 2010-06-02 17:26 UTC (permalink / raw)
To: geert; +Cc: fthain, joe, netdev, linux-kernel, linux-m68k
In-Reply-To: <AANLkTilqknhgBCXd-5Yxj9U8gDzDfMmmZdwDOvf-8kbH@mail.gmail.com>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Wed, 2 Jun 2010 19:24:08 +0200
> On Sat, May 29, 2010 at 10:03, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Fri, May 28, 2010 at 19:21, Finn Thain <fthain@telegraphics.com.au> wrote:
>>> On Sun, 23 May 2010, Geert Uytterhoeven wrote:
>>>> >> But here's a better solution. I do not have the hardware to test it,
>>>> >> though. Finn, does it {look OK,work}?
>>>> >
>>>> > It looks fine. I can't test it right now, but I will do so when I get
>>>> > the opportunity.
>>>>
>>>> Any news from the test front?
>>>
>>> This is commit ba0f916ca7ac79356e2ed32a85c3aa8255b104e7, right?
>>
>> Yep.
>>
>>> If so, it tests OK here.
>>
>> Thanks for testing!
>
> David, will you take this one too?
Please post a fresh copy, there is no way that sucker still applies cleanly
as there have been some changes in this area recently.
Thanks.
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: David Miller @ 2010-06-02 17:31 UTC (permalink / raw)
To: cl; +Cc: eric.dumazet, netdev, shemminger
In-Reply-To: <20100602.101258.134121018.davem@davemloft.net>
Just in case people are really so clueless as to be unable to figure
this out:
echo 1 >/sys/kernel/debug/tracing/events/skb/kfree_skb/enable
...do some stuff...
cat /sys/kernel/debug/tracing/trace
You can even trace it using 'perf' by passing "skb:kfree_skb"
as the event specifier.
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Neil Horman @ 2010-06-02 17:41 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, cl, netdev, shemminger
In-Reply-To: <1275499150.2519.0.camel@edumazet-laptop>
On Wed, Jun 02, 2010 at 07:19:10PM +0200, Eric Dumazet wrote:
> Le mercredi 02 juin 2010 à 10:12 -0700, David Miller a écrit :
> > From: Christoph Lameter <cl@linux-foundation.org>
> > Date: Wed, 2 Jun 2010 11:49:18 -0500 (CDT)
> >
> > > On Wed, 2 Jun 2010, Eric Dumazet wrote:
> > >
> > >> take a look at
> > >>
> > >> http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/html/SystemTap_Beginners_Guide/useful-systemtap-scripts.html#dropwatch
> > >
> > > System tap?
> >
> > You don't need to use system tap, just the normal tracing stuff using
> > sysfs files suffices.
> >
>
> It would be good if Neil could gave us a man page or something ;)
>
That stap script was really meant to be a stopgap measure. As mentioned, you
can use the debugfs interface to turn tracepoints on and use them anyway you
wish. Or, if you want to use the kfree_skb and napi_poll tracepoints in a more
formalized way, you can use the dropwatch user space utility:
https://fedorahosted.org/dropwatch/
Which includes a man page on usage :)
I also recently updated it so that this utility can query /proc/kallsyms to
translate program counter values into symbollic names and offsets for you. :)
Regards
Neil
^ permalink raw reply
* [PATCH] net: mac8390 - Sort out memory/MMIO accesses and casts
From: Geert Uytterhoeven @ 2010-06-02 17:36 UTC (permalink / raw)
To: davem; +Cc: netdev, Geert Uytterhoeven
commit 5c7fffd0e3b57cb63f50bbd710868f012d67654f ("drivers/net/mac8390.c: Remove
useless memcpy casting") removed too many casts, introducing the following
warnings:
| drivers/net/mac8390.c:248: warning: passing argument 1 of '__builtin_memcpy' makes pointer from integer without a cast
| drivers/net/mac8390.c:253: warning: passing argument 1 of 'word_memcpy_tocard' makes pointer from integer without a cast
| drivers/net/mac8390.c:255: warning: passing argument 2 of 'word_memcpy_fromcard' makes pointer from integer without a cast
Instead of just readding the casts,
- move all casts inside word_memcpy_{to,from}card(),
- replace an incorrect memcpy() by memcpy_toio(),
- add memcmp_withio() as a wrapper around memcmp(),
- replace an incorrect memcpy_toio() by memcpy_fromio().
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Finn Thain <fthain@telegraphics.com.au>
---
drivers/net/mac8390.c | 44 ++++++++++++++++++++++----------------------
1 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/net/mac8390.c b/drivers/net/mac8390.c
index 1136c9a..c7476a4 100644
--- a/drivers/net/mac8390.c
+++ b/drivers/net/mac8390.c
@@ -157,6 +157,8 @@ static void dayna_block_output(struct net_device *dev, int count,
#define memcpy_fromio(a, b, c) memcpy((a), (void *)(b), (c))
#define memcpy_toio(a, b, c) memcpy((void *)(a), (b), (c))
+#define memcmp_withio(a, b, c) memcmp((a), (void *)(b), (c))
+
/* Slow Sane (16-bit chunk memory read/write) Cabletron uses this */
static void slow_sane_get_8390_hdr(struct net_device *dev,
struct e8390_pkt_hdr *hdr, int ring_page);
@@ -164,8 +166,8 @@ static void slow_sane_block_input(struct net_device *dev, int count,
struct sk_buff *skb, int ring_offset);
static void slow_sane_block_output(struct net_device *dev, int count,
const unsigned char *buf, int start_page);
-static void word_memcpy_tocard(void *tp, const void *fp, int count);
-static void word_memcpy_fromcard(void *tp, const void *fp, int count);
+static void word_memcpy_tocard(unsigned long tp, const void *fp, int count);
+static void word_memcpy_fromcard(void *tp, unsigned long fp, int count);
static enum mac8390_type __init mac8390_ident(struct nubus_dev *dev)
{
@@ -245,9 +247,9 @@ static enum mac8390_access __init mac8390_testio(volatile unsigned long membase)
unsigned long outdata = 0xA5A0B5B0;
unsigned long indata = 0x00000000;
/* Try writing 32 bits */
- memcpy(membase, &outdata, 4);
+ memcpy_toio(membase, &outdata, 4);
/* Now compare them */
- if (memcmp((char *)&outdata, (char *)membase, 4) == 0)
+ if (memcmp_withio(&outdata, membase, 4) == 0)
return ACCESS_32;
/* Write 16 bit output */
word_memcpy_tocard(membase, &outdata, 4);
@@ -731,7 +733,7 @@ static void sane_get_8390_hdr(struct net_device *dev,
struct e8390_pkt_hdr *hdr, int ring_page)
{
unsigned long hdr_start = (ring_page - WD_START_PG)<<8;
- memcpy_fromio((void *)hdr, (char *)dev->mem_start + hdr_start, 4);
+ memcpy_fromio(hdr, dev->mem_start + hdr_start, 4);
/* Fix endianness */
hdr->count = swab16(hdr->count);
}
@@ -745,14 +747,13 @@ static void sane_block_input(struct net_device *dev, int count,
if (xfer_start + count > ei_status.rmem_end) {
/* We must wrap the input move. */
int semi_count = ei_status.rmem_end - xfer_start;
- memcpy_fromio(skb->data, (char *)dev->mem_start + xfer_base,
+ memcpy_fromio(skb->data, dev->mem_start + xfer_base,
semi_count);
count -= semi_count;
- memcpy_toio(skb->data + semi_count,
- (char *)ei_status.rmem_start, count);
- } else {
- memcpy_fromio(skb->data, (char *)dev->mem_start + xfer_base,
+ memcpy_fromio(skb->data + semi_count, ei_status.rmem_start,
count);
+ } else {
+ memcpy_fromio(skb->data, dev->mem_start + xfer_base, count);
}
}
@@ -761,7 +762,7 @@ static void sane_block_output(struct net_device *dev, int count,
{
long shmem = (start_page - WD_START_PG)<<8;
- memcpy_toio((char *)dev->mem_start + shmem, buf, count);
+ memcpy_toio(dev->mem_start + shmem, buf, count);
}
/* dayna block input/output */
@@ -812,7 +813,7 @@ static void slow_sane_get_8390_hdr(struct net_device *dev,
int ring_page)
{
unsigned long hdr_start = (ring_page - WD_START_PG)<<8;
- word_memcpy_fromcard(hdr, (char *)dev->mem_start + hdr_start, 4);
+ word_memcpy_fromcard(hdr, dev->mem_start + hdr_start, 4);
/* Register endianism - fix here rather than 8390.c */
hdr->count = (hdr->count&0xFF)<<8|(hdr->count>>8);
}
@@ -826,15 +827,14 @@ static void slow_sane_block_input(struct net_device *dev, int count,
if (xfer_start + count > ei_status.rmem_end) {
/* We must wrap the input move. */
int semi_count = ei_status.rmem_end - xfer_start;
- word_memcpy_fromcard(skb->data,
- (char *)dev->mem_start + xfer_base,
+ word_memcpy_fromcard(skb->data, dev->mem_start + xfer_base,
semi_count);
count -= semi_count;
word_memcpy_fromcard(skb->data + semi_count,
- (char *)ei_status.rmem_start, count);
+ ei_status.rmem_start, count);
} else {
- word_memcpy_fromcard(skb->data,
- (char *)dev->mem_start + xfer_base, count);
+ word_memcpy_fromcard(skb->data, dev->mem_start + xfer_base,
+ count);
}
}
@@ -843,12 +843,12 @@ static void slow_sane_block_output(struct net_device *dev, int count,
{
long shmem = (start_page - WD_START_PG)<<8;
- word_memcpy_tocard((char *)dev->mem_start + shmem, buf, count);
+ word_memcpy_tocard(dev->mem_start + shmem, buf, count);
}
-static void word_memcpy_tocard(void *tp, const void *fp, int count)
+static void word_memcpy_tocard(unsigned long tp, const void *fp, int count)
{
- volatile unsigned short *to = tp;
+ volatile unsigned short *to = (void *)tp;
const unsigned short *from = fp;
count++;
@@ -858,10 +858,10 @@ static void word_memcpy_tocard(void *tp, const void *fp, int count)
*to++ = *from++;
}
-static void word_memcpy_fromcard(void *tp, const void *fp, int count)
+static void word_memcpy_fromcard(void *tp, unsigned long fp, int count)
{
unsigned short *to = tp;
- const volatile unsigned short *from = fp;
+ const volatile unsigned short *from = (const void *)fp;
count++;
count /= 2;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Eric Dumazet @ 2010-06-02 17:46 UTC (permalink / raw)
To: David Miller; +Cc: cl, netdev, shemminger
In-Reply-To: <20100602.103102.121237521.davem@davemloft.net>
Le mercredi 02 juin 2010 à 10:31 -0700, David Miller a écrit :
> Just in case people are really so clueless as to be unable to figure
> this out:
>
> echo 1 >/sys/kernel/debug/tracing/events/skb/kfree_skb/enable
> ...do some stuff...
> cat /sys/kernel/debug/tracing/trace
>
> You can even trace it using 'perf' by passing "skb:kfree_skb"
> as the event specifier.
Thanks !
Here is the patch I cooked to account for RP_FILTER errors in multicast
path.
I will complete it to also do the unicast part before official
submission.
Christoph, the official counter would be IPSTATS_MIB_INNOROUTES
ipSystemStatsInNoRoutes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of input IP datagrams discarded because no route
could be found to transmit them to their destination.
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 4f0ed45..f207289 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -284,7 +284,7 @@ int fib_validate_source(__be32 src, __be32 dst, u8 tos, int oif,
if (no_addr)
goto last_resort;
if (rpf == 1)
- goto e_inval;
+ goto e_rpf;
fl.oif = dev->ifindex;
ret = 0;
@@ -299,7 +299,7 @@ int fib_validate_source(__be32 src, __be32 dst, u8 tos, int oif,
last_resort:
if (rpf)
- goto e_inval;
+ goto e_rpf;
*spec_dst = inet_select_addr(dev, 0, RT_SCOPE_UNIVERSE);
*itag = 0;
return 0;
@@ -308,6 +308,8 @@ e_inval_res:
fib_res_put(&res);
e_inval:
return -EINVAL;
+e_rpf:
+ return -ENETUNREACH;
}
static inline __be32 sk_extract_addr(struct sockaddr *addr)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 8495bce..8e9e2f9 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1851,6 +1851,7 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,
__be32 spec_dst;
struct in_device *in_dev = in_dev_get(dev);
u32 itag = 0;
+ int err;
/* Primary sanity checks. */
@@ -1865,10 +1866,12 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,
if (!ipv4_is_local_multicast(daddr))
goto e_inval;
spec_dst = inet_select_addr(dev, 0, RT_SCOPE_LINK);
- } else if (fib_validate_source(saddr, 0, tos, 0,
- dev, &spec_dst, &itag, 0) < 0)
- goto e_inval;
-
+ } else {
+ err = fib_validate_source(saddr, 0, tos, 0, dev, &spec_dst,
+ &itag, 0);
+ if (err < 0)
+ goto e_err;
+ }
rth = dst_alloc(&ipv4_dst_ops);
if (!rth)
goto e_nobufs;
@@ -1922,6 +1925,9 @@ e_nobufs:
e_inval:
in_dev_put(in_dev);
return -EINVAL;
+e_err:
+ in_dev_put(in_dev);
+ return err;
}
^ permalink raw reply related
* Re: sysfs class/net/ problem
From: Johannes Berg @ 2010-06-02 17:52 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Greg KH, netdev
In-Reply-To: <m1ocftwdp7.fsf@fess.ebiederm.org>
On Wed, 2010-06-02 at 10:23 -0700, Eric W. Biederman wrote:
> So far that hypothesis that the target of the symlink is being removed before
> the actual actual link looks like it could cause this.
Yeah though I'm not sure how that would happen? Wouldn't the symlink
cause the target kobject to still be referenced, and thus stay around
until the symlink goes away?
> Are there any other left overs in sysfs, besides just /sys/class/net/wlan0?
No, not based on find /sys and diffing before/after anyway.
johannes
^ permalink raw reply
* Re: [Patch]8139too: remove unnecessary cast of ioread32()'s return value
From: Jeff Garzik @ 2010-06-02 17:52 UTC (permalink / raw)
To: David Miller; +Cc: romieu, netdev
In-Reply-To: <20100530.183557.104047217.davem@davemloft.net>
On 05/30/2010 09:35 PM, David Miller wrote:
> From: David Miller<davem@davemloft.net>
> Date: Sun, 30 May 2010 18:29:48 -0700 (PDT)
>
>> From: Jeff Garzik<jeff@garzik.org>
>> Date: Sun, 30 May 2010 19:24:18 -0400
>>
>>> That was the genesis of the question. Some arches still use unsigned
>>> long.
>>
>> They are 32-bit.
>
> In fact the only two offenders are h8300 and m32r, which are
> both 32-bit.
The main interesting one is an ARM sub-arch that supports PCI.
> This is really in the realm of "who cares."
Fair enough. That answers my question.
Jeff
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Christoph Lameter @ 2010-06-02 18:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, shemminger
In-Reply-To: <1275500802.2519.7.camel@edumazet-laptop>
On Wed, 2 Jun 2010, Eric Dumazet wrote:
> Here is the patch I cooked to account for RP_FILTER errors in multicast
> path.
>
> I will complete it to also do the unicast part before official
> submission.
>
> Christoph, the official counter would be IPSTATS_MIB_INNOROUTES
Great. Thanks.
> ipSystemStatsInNoRoutes OBJECT-TYPE
> SYNTAX Counter32
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The number of input IP datagrams discarded because no route
> could be found to transmit them to their destination.
add "or because the rp_filter rejected the packet"? In the case of MC
traffic you dont really need a route.
In my particular case it is a weird corner case for the rp_filter.
Two NICs are on the same subnet. Different multicast groups are joined
on each (Using two NICs to balance the MC load since the drivers have
some multicast limitations and having different interrupt lines for each
NIC is also beneficial).
The rp_filter rejects all multicast traffic to the subscriptions on the
second NIC. I guess this is because the source address of the MC traffic
(on the same subnet) is also reachable via the first NIC.
So you could add also "because of breakage in the rp_filter (rp_filter
ignores the multicast subscription tables when determining the correct
reverse path of the packet)"
^ permalink raw reply
* [PATCH] chelsio: Remove remnants of CONFIG_CHELSIO_T1_COUGAR
From: Roland Dreier @ 2010-06-02 18:04 UTC (permalink / raw)
To: netdev, David S. Miller, Stephen Hemminger
CONFIG_CHELSIO_T1_COUGAR cannot be set (it appears nowhere in any
Kconfig files), and the code it protects could never build (cspi.h was
never added to the kernel tree). Therefore it's pretty safe to remove
all vestiges of this dead code.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
---
drivers/net/chelsio/common.h | 1 -
drivers/net/chelsio/subr.c | 49 +----------------------------------------
2 files changed, 2 insertions(+), 48 deletions(-)
diff --git a/drivers/net/chelsio/common.h b/drivers/net/chelsio/common.h
index 036b2df..092f31a 100644
--- a/drivers/net/chelsio/common.h
+++ b/drivers/net/chelsio/common.h
@@ -286,7 +286,6 @@ struct board_info {
unsigned int clock_mc3;
unsigned int clock_mc4;
unsigned int espi_nports;
- unsigned int clock_cspi;
unsigned int clock_elmer0;
unsigned char mdio_mdien;
unsigned char mdio_mdiinv;
diff --git a/drivers/net/chelsio/subr.c b/drivers/net/chelsio/subr.c
index 53bde15..599d178 100644
--- a/drivers/net/chelsio/subr.c
+++ b/drivers/net/chelsio/subr.c
@@ -185,9 +185,6 @@ static int t1_pci_intr_handler(adapter_t *adapter)
return 0;
}
-#ifdef CONFIG_CHELSIO_T1_COUGAR
-#include "cspi.h"
-#endif
#ifdef CONFIG_CHELSIO_T1_1G
#include "fpga_defs.h"
@@ -280,7 +277,7 @@ static void mi1_mdio_init(adapter_t *adapter, const struct board_info *bi)
t1_tpi_write(adapter, A_ELMER0_PORT0_MI1_CFG, val);
}
-#if defined(CONFIG_CHELSIO_T1_1G) || defined(CONFIG_CHELSIO_T1_COUGAR)
+#if defined(CONFIG_CHELSIO_T1_1G)
/*
* Elmer MI1 MDIO read/write operations.
*/
@@ -317,7 +314,7 @@ static int mi1_mdio_write(struct net_device *dev, int phy_addr, int mmd_addr,
return 0;
}
-#if defined(CONFIG_CHELSIO_T1_1G) || defined(CONFIG_CHELSIO_T1_COUGAR)
+#if defined(CONFIG_CHELSIO_T1_1G)
static const struct mdio_ops mi1_mdio_ops = {
.init = mi1_mdio_init,
.read = mi1_mdio_read,
@@ -752,31 +749,6 @@ int t1_elmer0_ext_intr_handler(adapter_t *adapter)
mod_detect ? "removed" : "inserted");
}
break;
-#ifdef CONFIG_CHELSIO_T1_COUGAR
- case CHBT_BOARD_COUGAR:
- if (adapter->params.nports == 1) {
- if (cause & ELMER0_GP_BIT1) { /* Vitesse MAC */
- struct cmac *mac = adapter->port[0].mac;
- mac->ops->interrupt_handler(mac);
- }
- if (cause & ELMER0_GP_BIT5) { /* XPAK MOD_DETECT */
- }
- } else {
- int i, port_bit;
-
- for_each_port(adapter, i) {
- port_bit = i ? i + 1 : 0;
- if (!(cause & (1 << port_bit)))
- continue;
-
- phy = adapter->port[i].phy;
- phy_cause = phy->ops->interrupt_handler(phy);
- if (phy_cause & cphy_cause_link_change)
- t1_link_changed(adapter, i);
- }
- }
- break;
-#endif
}
t1_tpi_write(adapter, A_ELMER0_INT_CAUSE, cause);
return 0;
@@ -955,7 +927,6 @@ static int board_init(adapter_t *adapter, const struct board_info *bi)
case CHBT_BOARD_N110:
case CHBT_BOARD_N210:
case CHBT_BOARD_CHT210:
- case CHBT_BOARD_COUGAR:
t1_tpi_par(adapter, 0xf);
t1_tpi_write(adapter, A_ELMER0_GPO, 0x800);
break;
@@ -1004,10 +975,6 @@ int t1_init_hw_modules(adapter_t *adapter)
adapter->regs + A_MC5_CONFIG);
}
-#ifdef CONFIG_CHELSIO_T1_COUGAR
- if (adapter->cspi && t1_cspi_init(adapter->cspi))
- goto out_err;
-#endif
if (adapter->espi && t1_espi_init(adapter->espi, bi->chip_mac,
bi->espi_nports))
goto out_err;
@@ -1061,10 +1028,6 @@ void t1_free_sw_modules(adapter_t *adapter)
t1_tp_destroy(adapter->tp);
if (adapter->espi)
t1_espi_destroy(adapter->espi);
-#ifdef CONFIG_CHELSIO_T1_COUGAR
- if (adapter->cspi)
- t1_cspi_destroy(adapter->cspi);
-#endif
}
static void __devinit init_link_config(struct link_config *lc,
@@ -1084,14 +1047,6 @@ static void __devinit init_link_config(struct link_config *lc,
}
}
-#ifdef CONFIG_CHELSIO_T1_COUGAR
- if (bi->clock_cspi && !(adapter->cspi = t1_cspi_create(adapter))) {
- pr_err("%s: CSPI initialization failed\n",
- adapter->name);
- goto error;
- }
-#endif
-
/*
* Allocate and initialize the data structures that hold the SW state of
* the Terminator HW modules.
--
Roland Dreier <rolandd@cisco.com> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
^ permalink raw reply related
* (unknown),
From: SHUNG EDWIN @ 2010-06-02 14:31 UTC (permalink / raw)
Dear Friend,
I am Mr. Shung Hin Hui Edwin a manager on investor relations in Standard
Chartered Bank, Hong Kong. I have a business proposal for you. If interested
please contact me for details
I greet
Edwin Shung Hui Hin.
^ permalink raw reply
* Re: sysfs class/net/ problem
From: Eric W. Biederman @ 2010-06-02 18:05 UTC (permalink / raw)
To: Johannes Berg; +Cc: Greg KH, netdev
In-Reply-To: <1275501157.3915.22.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2010-06-02 at 10:23 -0700, Eric W. Biederman wrote:
>
>> So far that hypothesis that the target of the symlink is being removed before
>> the actual actual link looks like it could cause this.
>
> Yeah though I'm not sure how that would happen? Wouldn't the symlink
> cause the target kobject to still be referenced, and thus stay around
> until the symlink goes away?
The references don't affect visibility in sysfs. All of that is manual
at the sysfs layer, and there doesn't appear to be a good substitute. Generally
the device layer manages to handle all of the details automatically but it
appears something is missing.
>> Are there any other left overs in sysfs, besides just /sys/class/net/wlan0?
>
> No, not based on find /sys and diffing before/after anyway.
It is going to be a little bit before I manage to dig into this deeply.
If you want to dig into this look at sysfs_delete_link. instrument
it so that you can see if it is called for wlan{0,1,2} and see what
ns it is called for.
My current hypothesis is something is causing us to try and delete
the symlink from the wrong namespace, so we just skip that part of it.
Eric
^ permalink raw reply
* Re: [PATCH] net: mac8390 - Sort out memory/MMIO accesses and casts
From: Joe Perches @ 2010-06-02 18:21 UTC (permalink / raw)
To: Geert Uytterhoeven, Finn Thain; +Cc: davem, netdev
In-Reply-To: <1275500180-32640-1-git-send-email-geert@linux-m68k.org>
On Wed, 2010-06-02 at 19:36 +0200, Geert Uytterhoeven wrote:
> commit 5c7fffd0e3b57cb63f50bbd710868f012d67654f ("drivers/net/mac8390.c: Remove
> useless memcpy casting") removed too many casts, introducing the following
> warnings:
>
> | drivers/net/mac8390.c:248: warning: passing argument 1 of '__builtin_memcpy' makes pointer from integer without a cast
> | drivers/net/mac8390.c:253: warning: passing argument 1 of 'word_memcpy_tocard' makes pointer from integer without a cast
> | drivers/net/mac8390.c:255: warning: passing argument 2 of 'word_memcpy_fromcard' makes pointer from integer without a cast
>
> Instead of just readding the casts,
> - move all casts inside word_memcpy_{to,from}card(),
> - replace an incorrect memcpy() by memcpy_toio(),
> - add memcmp_withio() as a wrapper around memcmp(),
> - replace an incorrect memcpy_toio() by memcpy_fromio().
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Tested-by: Finn Thain <fthain@telegraphics.com.au>
Thanks Geert and Finn.
Apologies for not setting up a cross-compiler to fix this.
cheers, Joe
^ permalink raw reply
* Re: [PATCH v2] netfilter: Xtables: idletimer target implementation
From: Luciano Coelho @ 2010-06-02 18:37 UTC (permalink / raw)
To: ext Jan Engelhardt
Cc: netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
kaber@trash.net, Timo Teras
In-Reply-To: <alpine.LSU.2.01.1006021708370.27340@obet.zrqbmnf.qr>
On Wed, 2010-06-02 at 17:16 +0200, ext Jan Engelhardt wrote:
> On Wednesday 2010-06-02 15:41, Luciano Coelho wrote:
>
> >+static int __init idletimer_tg_init(void)
> >+{
> >+ int ret;
> >+
> >+ idletimer_tg_kobj = kobject_create_and_add("idletimer",
> >+ &THIS_MODULE->mkobj.kobj);
>
> Isn't this going to oops when you compile this module as =y?
Damn, that's true. :(
I'll investigate how to fix this.
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH net-next-2.6 1/2][v2] bonding: add all_slaves_active parameter
From: Andy Gospodarek @ 2010-06-02 18:39 UTC (permalink / raw)
To: netdev; +Cc: fubar, nhorman
v2: changed parameter name from 'keep_all' to 'all_slaves_active' and
skipped setting slaves to inactive rather than creating a new flag at
Jay's suggestion.
In an effort to suppress duplicate frames on certain bonding modes
(specifically the modes that do not require additional configuration on
the switch or switches connected to the host), code was added in the
generic receive patch in 2.6.16. The current behavior works quite well
for most users, but there are some times it would be nice to restore old
functionality and allow all frames to make their way up the stack.
This patch adds support for a new module option and sysfs file called
'all_slaves_active' that will restore pre-2.6.16 functionality if the
user desires. The default value is '0' and retains existing behavior,
but the user can set it to '1' and allow all frames up if desired.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
---
drivers/net/bonding/bond_main.c | 13 +++++++++
drivers/net/bonding/bond_sysfs.c | 52 ++++++++++++++++++++++++++++++++++++++
drivers/net/bonding/bonding.h | 4 ++-
3 files changed, 68 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index ef60244..f22f6bf 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -106,6 +106,7 @@ static int arp_interval = BOND_LINK_ARP_INTERV;
static char *arp_ip_target[BOND_MAX_ARP_TARGETS];
static char *arp_validate;
static char *fail_over_mac;
+static int all_slaves_active = 0;
static struct bond_params bonding_defaults;
module_param(max_bonds, int, 0);
@@ -155,6 +156,10 @@ module_param(arp_validate, charp, 0);
MODULE_PARM_DESC(arp_validate, "validate src/dst of ARP probes: none (default), active, backup or all");
module_param(fail_over_mac, charp, 0);
MODULE_PARM_DESC(fail_over_mac, "For active-backup, do not set all slaves to the same MAC. none (default), active or follow");
+module_param(all_slaves_active, int, 0);
+MODULE_PARM_DESC(all_slaves_active, "Keep all frames received on an interface"
+ "by setting active flag for all slaves. "
+ "0 for never (default), 1 for always.");
/*----------------------------- Global variables ----------------------------*/
@@ -4771,6 +4776,13 @@ static int bond_check_params(struct bond_params *params)
}
}
+ if ((all_slaves_active != 0) && (all_slaves_active != 1)) {
+ pr_warning("Warning: all_slaves_active module parameter (%d), "
+ "not of valid value (0/1), so it was set to "
+ "0\n", all_slaves_active);
+ all_slaves_active = 0;
+ }
+
/* reset values for TLB/ALB */
if ((bond_mode == BOND_MODE_TLB) ||
(bond_mode == BOND_MODE_ALB)) {
@@ -4941,6 +4953,7 @@ static int bond_check_params(struct bond_params *params)
params->primary[0] = 0;
params->primary_reselect = primary_reselect_value;
params->fail_over_mac = fail_over_mac_value;
+ params->all_slaves_active = all_slaves_active;
if (primary) {
strncpy(params->primary, primary, IFNAMSIZ);
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 496ac1e..066311a 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -1411,7 +1411,58 @@ static ssize_t bonding_show_ad_partner_mac(struct device *d,
}
static DEVICE_ATTR(ad_partner_mac, S_IRUGO, bonding_show_ad_partner_mac, NULL);
+/*
+ * Show and set the all_slaves_active flag.
+ */
+static ssize_t bonding_show_slaves_active(struct device *d,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct bonding *bond = to_bond(d);
+
+ return sprintf(buf, "%d\n", bond->params.all_slaves_active);
+}
+
+static ssize_t bonding_store_slaves_active(struct device *d,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int i, new_value, ret = count;
+ struct bonding *bond = to_bond(d);
+ struct slave *slave;
+
+ if (sscanf(buf, "%d", &new_value) != 1) {
+ pr_err("%s: no all_slaves_active value specified.\n",
+ bond->dev->name);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (new_value == bond->params.all_slaves_active)
+ goto out;
+
+ if ((new_value == 0) || (new_value == 1)) {
+ bond->params.all_slaves_active = new_value;
+ } else {
+ pr_info("%s: Ignoring invalid all_slaves_active value %d.\n",
+ bond->dev->name, new_value);
+ ret = -EINVAL;
+ goto out;
+ }
+ bond_for_each_slave(bond, slave, i) {
+ if (slave->state == BOND_STATE_BACKUP) {
+ if (new_value)
+ slave->dev->priv_flags &= ~IFF_SLAVE_INACTIVE;
+ else
+ slave->dev->priv_flags |= IFF_SLAVE_INACTIVE;
+ }
+ }
+out:
+ return count;
+}
+static DEVICE_ATTR(all_slaves_active, S_IRUGO | S_IWUSR,
+ bonding_show_slaves_active, bonding_store_slaves_active);
static struct attribute *per_bond_attrs[] = {
&dev_attr_slaves.attr,
@@ -1438,6 +1489,7 @@ static struct attribute *per_bond_attrs[] = {
&dev_attr_ad_actor_key.attr,
&dev_attr_ad_partner_key.attr,
&dev_attr_ad_partner_mac.attr,
+ &dev_attr_all_slaves_active.attr,
NULL,
};
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index da80964..cecdea2 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -131,6 +131,7 @@ struct bond_params {
char primary[IFNAMSIZ];
int primary_reselect;
__be32 arp_targets[BOND_MAX_ARP_TARGETS];
+ int all_slaves_active;
};
struct bond_parm_tbl {
@@ -290,7 +291,8 @@ static inline void bond_set_slave_inactive_flags(struct slave *slave)
struct bonding *bond = netdev_priv(slave->dev->master);
if (!bond_is_lb(bond))
slave->state = BOND_STATE_BACKUP;
- slave->dev->priv_flags |= IFF_SLAVE_INACTIVE;
+ if (!bond->params.all_slaves_active)
+ slave->dev->priv_flags |= IFF_SLAVE_INACTIVE;
if (slave_do_arp_validate(bond, slave))
slave->dev->priv_flags |= IFF_SLAVE_NEEDARP;
}
--
1.7.0.1
^ permalink raw reply related
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