* Re: [PATCH 1/2] cleanup pernet operation without CONFIG_NET_NS
From: David Miller @ 2007-11-13 11:24 UTC (permalink / raw)
To: den; +Cc: devel, containers, netdev, clg, benjamin.thery
In-Reply-To: <20071107120007.GA10169@iris.sw.ru>
From: "Denis V. Lunev" <den@openvz.org>
Date: Wed, 7 Nov 2007 15:00:07 +0300
> If CONFIG_NET_NS is not set, the only namespace is possible.
>
> This patch removes list of pernet_operations and cleanups code a bit.
> This list is not needed if there are no namespaces. We should just call
> ->init method.
>
> Additionally, the ->exit will be called on module unloading only. This
> case is safe - the code is not discarded. For the in/kernel code, ->exit
> should never be called.
>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] move unneeded data to initdata section
From: David Miller @ 2007-11-13 11:24 UTC (permalink / raw)
To: den; +Cc: devel, containers, netdev, clg, benjamin.thery
In-Reply-To: <20071107120100.GA10185@iris.sw.ru>
From: "Denis V. Lunev" <den@openvz.org>
Date: Wed, 7 Nov 2007 15:01:00 +0300
> This patch reverts Eric's commit 2b008b0a8e96b726c603c5e1a5a7a509b5f61e35
>
> It diets .text & .data section of the kernel if CONFIG_NET_NS is not set.
> This is safe after list operations cleanup.
>
> Signed-of-by: Denis V. Lunev <den@openvz.org>
Applied, thanks Denis.
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Jens Axboe @ 2007-11-13 11:24 UTC (permalink / raw)
To: Andrew Morton
Cc: Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide,
linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <20071113031553.3c7b5c16.akpm@linux-foundation.org>
On Tue, Nov 13 2007, Andrew Morton wrote:
> > I/O STORAGE===========================================================
> >
> > kernel bug from pktcdvd
> > http://bugzilla.kernel.org/show_bug.cgi?id=9294
> > Kernel: 2.6.23
>
> I think we might have fixed this.
It's fixed and merged, I just forgot to close the bugzilla. Did so now.
--
Jens Axboe
^ permalink raw reply
* [NET] netfilter : xt_time should not assume CONFIG_KTIME_SCALAR
From: Eric Dumazet @ 2007-11-13 11:30 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Patrick McHardy
[-- Attachment #1: Type: text/plain, Size: 143 bytes --]
It is not correct to assume one can get nsec from a ktime directly by
using .tv64 field.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
[-- Attachment #2: xt_time.patch --]
[-- Type: text/plain, Size: 435 bytes --]
diff --git a/net/netfilter/xt_time.c b/net/netfilter/xt_time.c
index ff44f86..f9c55dc 100644
--- a/net/netfilter/xt_time.c
+++ b/net/netfilter/xt_time.c
@@ -170,7 +170,7 @@ static bool xt_time_match(const struct sk_buff *skb,
if (skb->tstamp.tv64 == 0)
__net_timestamp((struct sk_buff *)skb);
- stamp = skb->tstamp.tv64;
+ stamp = ktime_to_ns(skb->tstamp);
do_div(stamp, NSEC_PER_SEC);
if (info->flags & XT_TIME_LOCAL_TZ)
^ permalink raw reply related
* Re: [BUG] New Kernel Bugs
From: Evgeniy Polyakov @ 2007-11-13 11:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: Natalie Protasevich, linux-kernel, netdev
In-Reply-To: <20071113031553.3c7b5c16.akpm@linux-foundation.org>
On Tue, Nov 13, 2007 at 03:15:53AM -0800, Andrew Morton (akpm@linux-foundation.org) wrote:
> > NETWORKING===========================================================
> >
> > RTNLGRP_ND_USEROPT does not report ifindex (IPv6)
> > http://bugzilla.kernel.org/show_bug.cgi?id=9349
> > Kernel: 2.6.24+
>
> No response from developers
Fixed (extended) in the DaveM's tree (or will be soon - patch was
submitted by Pierre Ynard).
Sorry, others are either driver related (and thus require
hardware to be tested on and maintainers to be kicked in)
or too obscure (like 2.6.11 bug and weird network problem
which is undetectible on other systems).
Yes, we suck, but we try to recover :)
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH 13/24] [IPSEC]: Move x->outer_mode->output out of locked section
From: David Miller @ 2007-11-13 11:33 UTC (permalink / raw)
To: herbert; +Cc: netdev, netdev
In-Reply-To: <20071108003903.GA11963@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 8 Nov 2007 08:39:03 +0800
> On Wed, Nov 07, 2007 at 05:17:42PM +0100, Ingo Oeser wrote:
> > Hi Herbert,
> >
> > Herbert Xu schrieb:
> > > diff --git a/net/ipv6/xfrm6_mode_ro.c b/net/ipv6/xfrm6_mode_ro.c
> > > index a7bc8c6..4a01cb3 100644
> > > --- a/net/ipv6/xfrm6_mode_ro.c
> > > +++ b/net/ipv6/xfrm6_mode_ro.c
> > > @@ -53,7 +54,9 @@ static int xfrm6_ro_output(struct xfrm_state *x, struct sk_buff *skb)
> > > __skb_pull(skb, hdr_len);
> > > memmove(ipv6_hdr(skb), iph, hdr_len);
> > >
> > > + spin_lock_bh(&x->lock);
> > > x->lastused = get_seconds();
> > > + spin_unlock_bh(&x->lock);
> > >
> > > return 0;
> > > }
> >
> > Can you move the retrieval of the seconds outside the spinlock?
>
> You certainly could. Whether it's worth it I won't speculate :)
Make 'lastused' an 'unsigned long' (that's all that get_seconds()
gives to us anyways), fix up the nla_total_size(x->lastused) thing in
net/xfrm/xfrm_user.c, and then you can remove this lock acquisition
completely because the store into x->lastused will now be atomic and
therefore locks aren't protecting anything.
^ permalink raw reply
* Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
From: David Miller @ 2007-11-13 11:36 UTC (permalink / raw)
To: herbert
Cc: auke-jan.h.kok, e1000-devel, netdev, djohnson+linux-kernel,
linux-kernel, joonwpark81, w, cfriesen, kaber
In-Reply-To: <E1Irtdz-0000DX-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 13 Nov 2007 19:09:23 +0800
> I agree. People doing a tcpdump don't have to turn on promiscuous
> mode, that's what the -p option is for. In other words, having
> promiscuous mode disable VLAN filtering does not take away the
> user's options at all.
>
> In fact, the very definition of promiscuous is to turn off hardware
> filtering, albeit the filtering of MAC addresses rather than VLAN
> tags. So it would seem logical to have it turn off VLAN filtering
> too.
Ok.
The performance implications can be pretty severe however.
I wish we could address this somehow.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: David Miller @ 2007-11-13 11:39 UTC (permalink / raw)
To: akpm
Cc: protasnb, linux-kernel, netdev, alsa-devel, linux-ide,
linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <20071113031553.3c7b5c16.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Tue, 13 Nov 2007 03:15:53 -0800
> > NETWORKING===========================================================
> >
> > RTNLGRP_ND_USEROPT does not report ifindex (IPv6)
> > http://bugzilla.kernel.org/show_bug.cgi?id=9349
> > Kernel: 2.6.24+
>
> No response from developers
That's funny, then how come there was a proper patch fix posted
and it's now in my tree ready to go to Linus?
I think you like just saying "No response from developers" over and
over again to make some of point about how developers are ignoring
lots of bugs. That's fine, but at least be accurate about it :-)
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Jarek Poplawski @ 2007-11-13 11:47 UTC (permalink / raw)
To: Andrew Morton
Cc: Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide,
linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <20071113031553.3c7b5c16.akpm@linux-foundation.org>
On 13-11-2007 12:15, Andrew Morton wrote:
...
> Zero responses from developers
...
> No response from developers
...
> Andreas did some work, seemed to lose interest.
...
> Rafael poked Thomas a week ago, to no effect. Thomas has been travelling.
Looks like very reproducible!
Maybe you should add this to ...bugzilla?
Regards,
Jarek P.
^ permalink raw reply
* [PATCH]iwlwifi not correctly dealing with hotunplug
From: Oliver Neukum @ 2007-11-13 11:49 UTC (permalink / raw)
To: David Miller, netdev
It makes no sense to enable interrupts if a device has been unplugged.
In addition if in doubt IRQ_HANDLED should be returned.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Regards
Oliver
----
--- linux-2.6.24-rc1/drivers/net/wireless/iwlwifi/iwl3945-base.c.alt 2007-11-13 12:23:07.000000000 +0100
+++ linux-2.6.24-rc1/drivers/net/wireless/iwlwifi/iwl3945-base.c 2007-11-13 12:26:00.000000000 +0100
@@ -4850,7 +4850,7 @@ static irqreturn_t iwl_isr(int irq, void
if ((inta == 0xFFFFFFFF) || ((inta & 0xFFFFFFF0) == 0xa5a5a5a0)) {
/* Hardware disappeared */
IWL_WARNING("HARDWARE GONE?? INTA == 0x%080x\n", inta);
- goto none;
+ goto unplugged;
}
IWL_DEBUG_ISR("ISR inta 0x%08x, enabled 0x%08x, fh 0x%08x\n",
@@ -4858,6 +4858,7 @@ static irqreturn_t iwl_isr(int irq, void
/* iwl_irq_tasklet() will service interrupts and re-enable them */
tasklet_schedule(&priv->irq_tasklet);
+unplugged:
spin_unlock(&priv->lock);
return IRQ_HANDLED;
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Andrew Morton @ 2007-11-13 11:49 UTC (permalink / raw)
To: David Miller
Cc: protasnb, linux-kernel, netdev, alsa-devel, linux-ide,
linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <20071113.033946.114918709.davem@davemloft.net>
On Tue, 13 Nov 2007 03:39:46 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Tue, 13 Nov 2007 03:15:53 -0800
>
> > > NETWORKING===========================================================
> > >
> > > RTNLGRP_ND_USEROPT does not report ifindex (IPv6)
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9349
> > > Kernel: 2.6.24+
> >
> > No response from developers
>
> That's funny, then how come there was a proper patch fix posted
> and it's now in my tree ready to go to Linus?
>
> I think you like just saying "No response from developers" over and
> over again to make some of point about how developers are ignoring
> lots of bugs. That's fine, but at least be accurate about it :-)
Do you believe that our response to bug reports is adequate?
^ permalink raw reply
* Re: [NET] netfilter : xt_time should not assume CONFIG_KTIME_SCALAR
From: David Miller @ 2007-11-13 11:50 UTC (permalink / raw)
To: dada1; +Cc: netdev, kaber
In-Reply-To: <47398ADD.2030509@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Tue, 13 Nov 2007 12:30:37 +0100
> It is not correct to assume one can get nsec from a ktime directly by
> using .tv64 field.
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Patrick, this is very clearly a correct bug fix, so I'm
going to apply this directly.
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 13/24] [IPSEC]: Move x->outer_mode->output out of locked section
From: Herbert Xu @ 2007-11-13 11:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, netdev
In-Reply-To: <20071113.033348.13935138.davem@davemloft.net>
On Tue, Nov 13, 2007 at 03:33:48AM -0800, David Miller wrote:
>
> Make 'lastused' an 'unsigned long' (that's all that get_seconds()
> gives to us anyways), fix up the nla_total_size(x->lastused) thing in
> net/xfrm/xfrm_user.c, and then you can remove this lock acquisition
> completely because the store into x->lastused will now be atomic and
> therefore locks aren't protecting anything.
Brilliant, make that patch 25/25 :)
[IPSEC]: Make x->lastused an unsigned long
Currently x->lastused is u64 which means that it cannot be read/written
atomically on all architectures. David Miller observed that the value
stored in it is only an unsigned long which is always atomic.
So based on his suggestion this patch changes the internal representation
from u64 to unsigned long while the user-interface still refers to it as
u64.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
include/net/xfrm.h | 2 +-
net/ipv6/xfrm6_mode_ro.c | 2 --
net/xfrm/xfrm_user.c | 4 ++--
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 944fdad..e184c11 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -183,7 +183,7 @@ struct xfrm_state
struct timer_list timer;
/* Last used time */
- u64 lastused;
+ unsigned long lastused;
/* Reference to data common to all the instances of this
* transformer. */
diff --git a/net/ipv6/xfrm6_mode_ro.c b/net/ipv6/xfrm6_mode_ro.c
index 4a01cb3..63d5d49 100644
--- a/net/ipv6/xfrm6_mode_ro.c
+++ b/net/ipv6/xfrm6_mode_ro.c
@@ -54,9 +54,7 @@ static int xfrm6_ro_output(struct xfrm_state *x, struct sk_buff *skb)
__skb_pull(skb, hdr_len);
memmove(ipv6_hdr(skb), iph, hdr_len);
- spin_lock_bh(&x->lock);
x->lastused = get_seconds();
- spin_unlock_bh(&x->lock);
return 0;
}
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index d41588d..02cf26f 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1993,8 +1993,8 @@ static inline size_t xfrm_sa_len(struct xfrm_state *x)
if (x->coaddr)
l += nla_total_size(sizeof(*x->coaddr));
- /* Must count this as this may become non-zero behind our back. */
- l += nla_total_size(sizeof(x->lastused));
+ /* Must count x->lastused as it may become non-zero behind our back. */
+ l += nla_total_size(sizeof(u64));
return l;
}
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: [BUG] New Kernel Bugs
From: David Miller @ 2007-11-13 11:58 UTC (permalink / raw)
To: akpm
Cc: protasnb, linux-kernel, netdev, alsa-devel, linux-ide,
linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <20071113034916.2556edd7.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Tue, 13 Nov 2007 03:49:16 -0800
> Do you believe that our response to bug reports is adequate?
Do you feel that making us feel and look like shit helps?
I guess I'm just masterbating here all night long with the 46
bug fixes I've reviewed fully and queued up into my tree. Along
with all the 10 or so -stable submissions I did tonight as well.
When someone like me is bug fixing full time, I take massive offense
to the impression you're trying to give especially when it's directed
at the networking.
So turn it down a notch Andrew.
I bet if you did things like list explicitly by name every single
person who adds a bug fix (however trivial) to an -mm release instead
of a new feature, you'll better achieve your goal than what you're
doing here.
^ permalink raw reply
* Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
From: Herbert Xu @ 2007-11-13 12:03 UTC (permalink / raw)
To: David Miller
Cc: kaber, joonwpark81, w, cfriesen, auke-jan.h.kok, netdev,
djohnson+linux-kernel, linux-kernel, e1000-devel
In-Reply-To: <20071113.033611.73195922.davem@davemloft.net>
On Tue, Nov 13, 2007 at 03:36:11AM -0800, David Miller wrote:
>
> The performance implications can be pretty severe however.
> I wish we could address this somehow.
Or perhaps we should just teach everyone to always run tcpdump
with -p, like me :)
Of course this would still have a negative impact on those who
have to be in promiscuous mode all the time (heh) due to multiple
unicast MAC addresses and such. However, we should able to
communicate that fact to the driver and the driver can then elect
to not disable VLAN acceleration unless we really want to be in
promiscuous mode.
In other words we can make it so that nobody is in promiscuous
mode and therefore have to disable VLAN acceleration *unless*
they really want to be in that state. In which case it would
imply that they wish to see everything and therefore we should
disable VLAN acceleration.
So that means I'd like to see our current core/driver interface
enhanced so that whether the user has requested us to be in
promiscuous mode can be differentiated from whether the network
stack wants us to be.
Once we have that then I would think that such a patch would be
less controversial.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
From: David Miller @ 2007-11-13 12:06 UTC (permalink / raw)
To: herbert
Cc: kaber, joonwpark81, w, cfriesen, auke-jan.h.kok, netdev,
djohnson+linux-kernel, linux-kernel, e1000-devel
In-Reply-To: <20071113120328.GB1086@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 13 Nov 2007 20:03:28 +0800
> On Tue, Nov 13, 2007 at 03:36:11AM -0800, David Miller wrote:
> >
> > The performance implications can be pretty severe however.
> > I wish we could address this somehow.
>
> Or perhaps we should just teach everyone to always run tcpdump
> with -p, like me :)
:-)
> Of course this would still have a negative impact on those who
> have to be in promiscuous mode all the time (heh) due to multiple
> unicast MAC addresses and such. However, we should able to
> communicate that fact to the driver and the driver can then elect
> to not disable VLAN acceleration unless we really want to be in
> promiscuous mode.
We already do with the code Patrick added a while ago so
that drivers can support multiple MAC addresses in hardware.
Now just to get the virtualization technologies and all the
drivers using it properly.
> In other words we can make it so that nobody is in promiscuous
> mode and therefore have to disable VLAN acceleration *unless*
> they really want to be in that state. In which case it would
> imply that they wish to see everything and therefore we should
> disable VLAN acceleration.
This is too complicated, we have multiple unicast MAC support
in the driver API already, let's simply use it.
^ permalink raw reply
* Re: [NET] netfilter : xt_time should not assume CONFIG_KTIME_SCALAR
From: Patrick McHardy @ 2007-11-13 12:07 UTC (permalink / raw)
To: David Miller; +Cc: dada1, netdev
In-Reply-To: <20071113.035019.268404275.davem@davemloft.net>
David Miller wrote:
> From: Eric Dumazet <dada1@cosmosbay.com>
> Date: Tue, 13 Nov 2007 12:30:37 +0100
>
>> It is not correct to assume one can get nsec from a ktime directly by
>> using .tv64 field.
>>
>> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
>
> Patrick, this is very clearly a correct bug fix, so I'm
> going to apply this directly.
Thanks, thats obviously correct. Still, I would prefer if
people would CC netfilter-devel and myself, it has become
a bad habit lately especially to skip netfilter-devel.
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Andrew Morton @ 2007-11-13 12:12 UTC (permalink / raw)
To: David Miller
Cc: protasnb, linux-kernel, netdev, alsa-devel, linux-ide,
linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <20071113.035824.40509981.davem@davemloft.net>
On Tue, 13 Nov 2007 03:58:24 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Tue, 13 Nov 2007 03:49:16 -0800
>
> > Do you believe that our response to bug reports is adequate?
>
> Do you feel that making us feel and look like shit helps?
>
That doesn't answer my question.
See, first we need to work out whether we have a problem. If we do this,
then we can then have a think about what to do about it.
I tried to convince the 2006 KS attendees that we have a problem and I
resoundingly failed. People seemed to think that we're doing OK.
But it appears that data such as this contradicts that belief.
This is not a minor matter. If the kernel _is_ slowly deteriorating then
this won't become readily apparent until it has been happening for a number
of years. By that stage there will be so much work to do to get us back to
an acceptable level that it will take a huge effort. And it will take a
long time after that for the kerel to get its reputation back.
So it is important that we catch deterioration *early* if it is happening.
^ permalink raw reply
* Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
From: Herbert Xu @ 2007-11-13 12:16 UTC (permalink / raw)
To: David Miller
Cc: kaber, joonwpark81, w, cfriesen, auke-jan.h.kok, netdev,
djohnson+linux-kernel, linux-kernel, e1000-devel
In-Reply-To: <20071113.040624.43544149.davem@davemloft.net>
On Tue, Nov 13, 2007 at 04:06:24AM -0800, David Miller wrote:
>
> > In other words we can make it so that nobody is in promiscuous
> > mode and therefore have to disable VLAN acceleration *unless*
> > they really want to be in that state. In which case it would
> > imply that they wish to see everything and therefore we should
> > disable VLAN acceleration.
>
> This is too complicated, we have multiple unicast MAC support
> in the driver API already, let's simply use it.
Yes I agree. People not using Patrick's new API deserves to
get poor performance so they can switch over sooner :)
What I was trying to say above is that e1000 currently uses
the old set_multicast_list interface (rather than dev_set_rx_mode)
so it's not immediately obvious why we're in promiscuous mode.
We could look at dev->promiscuity - !!uc_count but that feels a
bit fragile.
Perhaps those who want to push this patch should be encouraged
to convert e1000 to the new interface :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
From: Patrick McHardy @ 2007-11-13 12:18 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, joonwpark81, w, cfriesen, auke-jan.h.kok, netdev,
djohnson+linux-kernel, linux-kernel, e1000-devel
In-Reply-To: <20071113121647.GA1330@gondor.apana.org.au>
Herbert Xu wrote:
> On Tue, Nov 13, 2007 at 04:06:24AM -0800, David Miller wrote:
>>> In other words we can make it so that nobody is in promiscuous
>>> mode and therefore have to disable VLAN acceleration *unless*
>>> they really want to be in that state. In which case it would
>>> imply that they wish to see everything and therefore we should
>>> disable VLAN acceleration.
>> This is too complicated, we have multiple unicast MAC support
>> in the driver API already, let's simply use it.
>
> Yes I agree. People not using Patrick's new API deserves to
> get poor performance so they can switch over sooner :)
>
> What I was trying to say above is that e1000 currently uses
> the old set_multicast_list interface (rather than dev_set_rx_mode)
> so it's not immediately obvious why we're in promiscuous mode.
> We could look at dev->promiscuity - !!uc_count but that feels a
> bit fragile.
>
> Perhaps those who want to push this patch should be encouraged
> to convert e1000 to the new interface :)
I already posted a patch for this, not sure what happened to it.
Auke, any news on merging the secondary unicast address support?
^ permalink raw reply
* possible bug in tcp_probe
From: Gavin McCullagh @ 2007-11-13 11:26 UTC (permalink / raw)
To: netdev
Hi,
I'm using linux v2.6.22.6 and tcp_probe with a couple of small
modifications[1].
Even with moderately large numbers of flows (16 on the one machine) and
increasingly as I monitor more flows than that, I get strange overflow
problems such as this one:
74.259589763 192.168.2.1 36988 192.168.3.5 5001 0x679c23dc 0x679bc3b4 18 13 9114624 78 76 10000 0 64
74.260590660 192.168.2.1 44261 192.168.3.5 5006 0x573bb3ed 0x573b700d 13 9 5254144 155 127 10000 0 64
74.261607478 192.168.2.1 44261 192.168.3.5 5006 0x588.066586741 192.168.2.1 33739 192.168.3.5 5009 0xe26d1767 0xe26cf577 2 3 13090816 443 15818 10000 0 64
88.066690797 192.168.2.1 33739 192.168.3.5 5009 0xe26d1767 0xe26cfb1f 3 3 13092864 2365 15818 10000 0 64
88.067625714 192.168.2.1 59385 192.168.3.5 5012 0x411c1090 0x411bd258 12 9 14578688 2807 15812 10000 0 64
As you can see the third line has been truncated as well as the next
roughly 14 seconds of data after which data continues writing as usual.
I don't think my small changes are causing this but perhaps I'm wrong.
Does anyone know what might be causing the above?
Many thanks for any ideas,
Gavin
[1] I have slightly modified tcp_probe to print out information for a range
of ports (instead of one port or all) and to print info from the congestion
avoidance inet_csk_ca struct. This adds a couple of extra fields to the
end. If either of these are of interest as patches I'll happily submit
them.
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: David Miller @ 2007-11-13 12:32 UTC (permalink / raw)
To: akpm
Cc: protasnb, linux-kernel, netdev, alsa-devel, linux-ide,
linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <20071113041259.79c9a8c5.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Tue, 13 Nov 2007 04:12:59 -0800
> On Tue, 13 Nov 2007 03:58:24 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> > From: Andrew Morton <akpm@linux-foundation.org>
> > Date: Tue, 13 Nov 2007 03:49:16 -0800
> >
> > > Do you believe that our response to bug reports is adequate?
> >
> > Do you feel that making us feel and look like shit helps?
>
> That doesn't answer my question.
>
> See, first we need to work out whether we have a problem. If we do this,
> then we can then have a think about what to do about it.
>
> I tried to convince the 2006 KS attendees that we have a problem and I
> resoundingly failed. People seemed to think that we're doing OK.
>
> But it appears that data such as this contradicts that belief.
>
> This is not a minor matter. If the kernel _is_ slowly deteriorating then
> this won't become readily apparent until it has been happening for a number
> of years. By that stage there will be so much work to do to get us back to
> an acceptable level that it will take a huge effort. And it will take a
> long time after that for the kerel to get its reputation back.
>
> So it is important that we catch deterioration *early* if it is happening.
You tell me what I should spend my time working on, and I promise to
do it OK? :-)
For example, if I have a choice between a TCP crash just about anyone
can hit and some obscure issue only reported with some device nearly
nobody has, which one should I analyze and work on?
That's the problem. All of us prioritize and it means the chaff
collects at the bottom. You cannot fix that except by getting more
bug fixers so that the chaff pile has a chance to get smaller.
Luckily if the report being ignored isn't chaff, it will show up again
(and again and again) and this triggers a reprioritization because not
only is the bug no longer chaff, it also now got a lot of information
tagged to it so it's a double worthwhile investment to work on the
problem.
I think a lot of bugs that "aren't getting looked at" are simply
sitting in some early stage of this process.
^ permalink raw reply
* Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
From: David Miller @ 2007-11-13 12:32 UTC (permalink / raw)
To: herbert
Cc: auke-jan.h.kok, e1000-devel, netdev, djohnson+linux-kernel,
linux-kernel, joonwpark81, w, cfriesen, kaber
In-Reply-To: <20071113121647.GA1330@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 13 Nov 2007 20:16:47 +0800
> Perhaps those who want to push this patch should be encouraged
> to convert e1000 to the new interface :)
That is my feeling as well :-)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply
* Re: Problem with frame time stamping
From: Antoine Zen-Ruffinen @ 2007-11-13 12:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-net, netfilter-devel, patrik.arlos
In-Reply-To: <473982A7.6040409@cosmosbay.com>
THIS is what I did at the beginning. But is seem me to be some thing
wrong. So I put a static value in skb->tstamp instead of
ktime_get_real() for debug purpose. And I was still becoming the
amount of second, microsecond since 1970. We are back to my initial
mail ! The value of skb->tsamp doesn't seems to be returned by
ioctl().
2007/11/13, Eric Dumazet <dada1@cosmosbay.com>:
> Antoine Zen-Ruffinen a écrit :
> > This is exactly my problem : The driver of the network card I am using
> > (see rt2x00.serialmonkey.com) do the minimum in the hardware interrupt
> > (not filling skb->tstamp). Then netif_rx() is called later using a
> > tasklet (also not filling skb->tstamp). As it seem to me (maybe I am
> > wrong, if so please tell), the elapse time between the actual frame
> > arrival and the time where netif_rx() do net_timestamp(skb) is not
> > predicable !?
> >
> > Else, I would like to thank you to spend time helping me.
> >
> >
> >
> A tasklet could process the skb much later than corresponding IRQ,
> depending on various things
> (other tasks/softirqs on system with higher priorities). So yes, it is
> not predictable at all.
>
> Usually it doesnt matter, but if your business depends on precise tstamps,
> then just do skb->tstamp = ktime_get_real(); in IRQ handler (but it will
> slow it a bit,
> depending on how fast is ktime_get_real() on the target machine)
> netif_rx() wont overwrite it.
>
> skb = dev_alloc_skb(desc.size + NET_IP_ALIGN);
> if (!skb)
> return;
> skb->tstamp = ktime_get_real(); /* do it before other copies */
> skb_reserve(skb, NET_IP_ALIGN);
> skb_put(skb, desc.size);
> memcpy(skb->data, entry->data_addr, desc.size);
>
> ...
>
>
>
>
>
>
^ permalink raw reply
* Re: [patch 1/1][NETNS][IPV6] protect addrconf from loopback registration
From: Eric W. Biederman @ 2007-11-13 12:59 UTC (permalink / raw)
To: David Miller
Cc: den, dlezcano, netdev, xemul, containers, yoshfuji,
benjamin.thery
In-Reply-To: <20071112.142455.73541417.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
Well this is a weird way to get to this part of the conversation.
> From: "Denis V. Lunev" <den@sw.ru>
> Date: Mon, 12 Nov 2007 19:49:03 +0300
>
>> Unregister for a loopback in !init_net is a _valid_ operation and should
>> be clean, i.e. without kludges in the path. This is the only way to
>> check the ref-counting.
>
> For ipv6 the stack really wants to pin down the loopback
> device because we need a valid inet6_dev object to reference
> at all times in order to simplify the per-device SNMP
> statistic bumping.
>
> When a non-loopback device goes down, we point any existing
> references to that device's idev to the loopback one instead.
>
> I really consider taking down the loopback device to be
> an invalid operation at least how things are implemented
> currently.
In a secondary network namespace the current implementation
registers the loopback device before all other network devices
in a network namespace and it unregisters the loopback device
after all other network devices.
So we don't endanger the current scheme of pointing any existing
reference to the loopback device. In fact the current ipv6 addrconf_cleanup
largely does the same thing.
Unregistering the loopback device is definitely a case where we need
to tread very carefully.
Bug we absolutely need to do all of our cleanup for a network
namespace went it goes away and that includes removing the per network
namespace copy of the loopback device.
Eric
^ 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