From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 08 Jan 2008 12:28:52 +0100
> We can avoid divides (as seen with CONFIG_CC_OPTIMIZE_FOR_SIZE=y on x86)
> changing vlan_group_get_device()/vlan_group_set_device() id parameter
> from signed to
> unsigned.
>
> Signed-off-by: Eric Dumazet <[EMAIL PR
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 09 Jan 2008 08:51:39 +0100
> Yes I have a patch for these divides, but will apply on 2.6.25 once this one
> hits it. (this saves 192 bytes of kernel text BTW)
I never doubted you for a second.
--
To unsubscribe from this list: send the line "un
From: David Stevens <[EMAIL PROTECTED]>
Date: Mon, 7 Jan 2008 17:18:56 -0800
> Acked-by: David L Stevens <[EMAIL PROTECTED]>
Patch applied, thanks everyone.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
David Miller a écrit :
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 09 Jan 2008 08:29:11 +0100
Thanks for catching this.
Applied to net-2.6
+static inline int xfrm_alg_len(struct xfrm_algo *alg)
+{
+ return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
+}
That gets emitted as a di
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 09 Jan 2008 17:17:06 +1100
> Eric Dumazet <[EMAIL PROTECTED]> wrote:
> >
> > It seems commit fda9ef5d679b07c9d9097aaf6ef7f069d794a8f9 introduced a RCU
> > protection for sk_filter(), without a rcu_dereference()
> >
> > Either we need a rcu_derefer
Herbert Xu a écrit :
Eric Dumazet <[EMAIL PROTECTED]> wrote:
Very good question, but honestly I really dont see why it was there at the
first place :
It was there because someone went through this file and robotically
replaced all conditional read barriers with rcu_dereference, even when
it ma
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 09 Jan 2008 08:29:11 +0100
Thanks for catching this.
Applied to net-2.6
> +static inline int xfrm_alg_len(struct xfrm_algo *alg)
> +{
> + return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
> +}
That gets emitted as a divide doesn't it :-)))
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Tue, 8 Jan 2008 14:29:14 -0500
> Here are a few more for 2.6.25. The are mostly clean-ups for the new
> PID rate control algorithm, and some A-MPDU bits related to supporting
> 802.11n.
Pulled and pushed back out to net-2.6.25, thanks John.
--
T
Herbert Xu a écrit :
Eric Dumazet <[EMAIL PROTECTED]> wrote:
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 58dfa82..731f0a8 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1188,10 +1188,15 @@ static inline int xfrm_aevent_is_on(void)
return ret;
}
+static inline
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Wed, 9 Jan 2008 08:03:18 +0100
> Also even freeing a lot of objects doesn't have to be
> that expensive. I suspect the most cost is in taking
> the slab locks, but that could be batched.
We're touching SKB struct members, doing atomics on them, etc. for
> It adds severe spikes in CPU utilization that are even moderate
> line rates begins to affect RTTs.
>
> Or do you think it's OK to process 500,000 SKBs while locked
> in a software interrupt.
You can always push it into a work queue. Even put it to
other cores if you want.
In fact this is al
From: Don Fry <[EMAIL PROTECTED]>
Date: Tue, 08 Jan 2008 22:14:29 -0800
> Tested pcnet32 on x86_64 box and see no problems with the change.
> The code is only exercised if doing loopback testing, or changing
> the ring size during a receive storm.
>
> Acked-by: Don Fry <[EMAIL PROTECTED]>
Thank
As mentioned in
http://marc.info/?l=linux-bridge&m=113105949718826&w=2
Released package doesn't contain ./configure script
For people who know what is make on, it is easy to run autoconf , but some
know only how to use ./configure :-)
Other than this, it is works fine with me, but i didn't tes
From: John Heffner <[EMAIL PROTECTED]>
Date: Tue, 08 Jan 2008 23:27:08 -0500
> I also wonder how much of a problem this is (for now, with window sizes
> of order 1 packets. My understanding is that the biggest problems
> arise from O(N^2) time for recovery because every ack was expensive.
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Wed, 09 Jan 2008 03:25:05 +0100
> David Miller <[EMAIL PROTECTED]> writes:
> >
> > The big problem is that recovery from even a single packet loss in a
> > window makes us run kfree_skb() for a all the packets in a full
> > window's worth of data when rec
On Tue, 8 Jan 2008, Jay Vosburgh wrote:
Krzysztof Oledzki <[EMAIL PROTECTED]> wrote:
On Mon, 7 Jan 2008, Jay Vosburgh wrote:
Following are three fixes to fix locking problems and
silence locking-related warnings in the current 2.6.24-rc.
patch 1: fix locking in sysfs prima
From: "Lachlan Andrew" <[EMAIL PROTECTED]>
Date: Tue, 8 Jan 2008 17:34:03 -0800
> John also suggested freeing the packets as a lower priority task, just
> doing it after they're acknowledged.
>
> When the ACK finally comes, you could do something like moving John's
> entire list of packets to a "
Tested pcnet32 on x86_64 box and see no problems with the change.
The code is only exercised if doing loopback testing, or changing
the ring size during a receive storm.
Acked-by: Don Fry <[EMAIL PROTECTED]>
---
[NET]: Fix drivers to handle napi_disable() disabling interrupts.
When we add the g
Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> It seems commit fda9ef5d679b07c9d9097aaf6ef7f069d794a8f9 introduced a RCU
> protection for sk_filter(), without a rcu_dereference()
>
> Either we need a rcu_dereference(), either a comment should explain why we
> dont need it. I vote for the former.
>
Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> diff --git a/include/net/xfrm.h b/include/net/xfrm.h
> index 58dfa82..731f0a8 100644
> --- a/include/net/xfrm.h
> +++ b/include/net/xfrm.h
> @@ -1188,10 +1188,15 @@ static inline int xfrm_aevent_is_on(void)
>return ret;
> }
>
> +static inline in
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
>
> Jay's patches will not fix this issue. I think something like this did
> it for me, but as I mentioned to Jay in the last thread, I'm not
> convinced it doesn't violate some of the locking expectations we have.
>
> diff --git a/drivers/net/bonding/b
Just some idle brainstorming on the subject...
It seems the only way to handle network pipes sigificantly larger (delay *
bandwidth product) than the processor cache is to make freeing retransmit
data o(n).
Now, there are some ways to reduce the constant factor. The one that
comes to mind first
Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> Very good question, but honestly I really dont see why it was there at the
> first place :
It was there because someone went through this file and robotically
replaced all conditional read barriers with rcu_dereference, even when
it made zero sense.
B
Andi Kleen wrote:
David Miller <[EMAIL PROTECTED]> writes:
The big problem is that recovery from even a single packet loss in a
window makes us run kfree_skb() for a all the packets in a full
window's worth of data when recovery completes.
Why exactly is it a problem to free them all at once?
[ 2nd try...more thoroughly checked... ]
Jeff,
Another round of patches intended for 2.6.25...the biggest factions are
rt2x00 and b43 updates, as well as some Viro-isms... :-)
Please let me know if there are any problems!
John
P.S. Copying Dave in case he is handling these requests...FWIW, it
On Tue, Jan 08, 2008 at 06:58:11PM +0300, Pavel Emelyanov wrote:
> The feature of ipvs ctls is that the net/ipv4/vs path
> is common for core ipvs ctls and for two schedulers,
> so I make it exported and re-use it in modules.
>
> Two other .c files required linux/sysctl.h to make the
> extern decl
David Miller <[EMAIL PROTECTED]> writes:
>
> The big problem is that recovery from even a single packet loss in a
> window makes us run kfree_skb() for a all the packets in a full
> window's worth of data when recovery completes.
Why exactly is it a problem to free them all at once? Are you worrie
Please don't pull yet -- I let a patch get in out of order.
I'll post a new pull request when I straighten this out...
John
On Tue, Jan 08, 2008 at 05:42:02PM -0500, John W. Linville wrote:
> On Tue, Jan 08, 2008 at 05:23:05PM -0500, John W. Linville wrote:
> > Jeff,
> >
> > Another round of pa
Greetings David,
On 08/01/2008, David Miller <[EMAIL PROTECTED]> wrote:
> From: John Heffner <[EMAIL PROTECTED]>
>
> > I haven't thought about this too hard, but can we approximate this by
> > moving scaked data into a sacked queue, then if something bad happens
> > merge this back into the retran
On Wed, 09 Jan 2008 09:54:45 +0900
FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > > --- a/lib/iommu-helper.c~a
> > > +++ a/lib/iommu-helper.c
> > > @@ -8,15 +8,20 @@
> > > static unsigned long find_next_zero_area(unsigned long *map,
> > >unsigned long size,
> >
On Tue, 8 Jan 2008 16:27:39 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 09 Jan 2008 08:57:53 +0900
> FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
>
> > Andrew, can you replace
> >
> > iommu-sg-add-iommu-helper-functions-for-the-free-area-management.patch
> >
> > with the updated patc
> Can you try the patch below ?
Testing now... (I presume you noticed the one-character typo in my
earlier patch. That should be "mc = mc->next", not "mv = mc->next".)
That doesn't seem to do it. Not entirely, at least. After downloading
and partially re-uploading an 800M file, slabtop reports
On Wed, 09 Jan 2008 08:57:53 +0900
FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> Andrew, can you replace
>
> iommu-sg-add-iommu-helper-functions-for-the-free-area-management.patch
>
> with the updated patch:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048997.html
>
> For your con
On Tue, 8 Jan 2008, Tom Spink wrote:
> Ach. I *am* missing something... and what I'm missing is my
> understanding of the sendmsg and recvmsg calls.
No problem. We all have those days. :)
Brent
--
Brent Casavant All music is folk music. I ain't
[EMAIL PROTECTED]
On Tue, 8 Jan 2008 16:59:48 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
>
> > The patches are available at:
> >
> > http://www.kernel.org/pub/linux/kernel/people/tomo/iommu/
> >
> > Or if you prefer the git tree:
> >
> > git://git.kernel.org/p
On 08/01/2008, Tom Spink <[EMAIL PROTECTED]> wrote:
> On 08/01/2008, Brent Casavant <[EMAIL PROTECTED]> wrote:
> > On Tue, 8 Jan 2008, Tom Spink wrote:
> >
> > > Where in the code is the message length being sent across the socket?
> >
> > In do_producer(), there are the following lines in the main
David Miller <[EMAIL PROTECTED]> :
[...]
> Same kind of bug as the RX side :-) I bet this fixes his
> problem...
I am not sure but the Rx side is probably just here to distract
from the real problem. Please don't ask... :o)
Anyway I'll poke an adapter in the test computer and give it a
try tomor
On 08/01/2008, Brent Casavant <[EMAIL PROTECTED]> wrote:
> On Tue, 8 Jan 2008, Tom Spink wrote:
>
> > Where in the code is the message length being sent across the socket?
>
> In do_producer(), there are the following lines in the main loop:
>
> /* Send random lengths of data */
> m
>> +do {
>> +/* IPG_PC_MGMTDATA is a power of 2; compiler knows to shift */
>> +u8 d = ((data >> --len) & 1) * IPG_PC_MGMTDATA;
>> +/* + rather than | lets compiler microoptimize better */
>> +ipg_drive_phy_ctl_low_high(ioaddr, d + otherbits);
>>
On Tue, 8 Jan 2008, Rick Jones wrote:
> Potential bugs notwithstanding, given that this is a STREAM socket, and as
> such shouldn't (I hope, or I'm eating toes for dinner again) have side effects
> like tossing the rest of a datagram, why are you using MSG_PEEK? Why not
> simply read the N bytes
On Tue, 8 Jan 2008, Tom Spink wrote:
> Where in the code is the message length being sent across the socket?
In do_producer(), there are the following lines in the main loop:
/* Send random lengths of data */
messages[i].length = (rand() % MAXLEN) + sizeof(size_t);
iov[i]
Dave,
Got it. These new napi interface changes were introduced by someone else
and we assumed it to be correct. We will make the fix and submit.
Thanks,
Ram
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 08, 2008 3:08 PM
> To: Ramkrishna Vepa
Can people do me a favor and do more constructive things like test
that my patches really do fix the "device down during packet flood"
bug instead of nit-picking all the individual driver fixups I made?
That's what is useful at this time, thanks.
--
To unsubscribe from this list: send the line "u
From: "Ramkrishna Vepa" <[EMAIL PROTECTED]>
Date: Tue, 8 Jan 2008 18:01:32 -0500
> Dave,
> Sorry, should have been clearer. When I meant "brought down" did not
> mean close, but when a adapter reset is initiated. The napi_disable() is
> called only on a close. When the driver does a reset, napi_di
Dave,
Sorry, should have been clearer. When I meant "brought down" did not
mean close, but when a adapter reset is initiated. The napi_disable() is
called only on a close. When the driver does a reset, napi_disable() is
not called.
Ram
> -Original Message-
> From: David Miller [mailto:[EM
From: Francois Romieu <[EMAIL PROTECTED]>
Date: Tue, 8 Jan 2008 22:36:40 +0100
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> :
> > I take that back. This patch does NOT fix the leak, at least if
> > ping: sendmsg: No buffer space available
> > is any indication...
>
> Can you try the patch below ?
Sa
From: "Kok, Auke" <[EMAIL PROTECTED]>
Date: Tue, 08 Jan 2008 11:04:59 -0800
> this is exactly the change I was eyeballing and indeed this seems to be the
> general use case in most drivers anyway.
>
> I'll try to see how this impacts the (especially 4-port) TX performance issue
> with
> e1000e,
On Tuesday, 8 of January 2008, Linus Torvalds wrote:
>
> On Tue, 8 Jan 2008, Arjan van de Ven wrote:
> >
> > ok done; I had to fizzle a bit because some things aren't *exactly* a
> > BUG() statement but I track them anyway (things like the "sleeping in
> > invalid context" check), so I had to s
On 08/01/2008, Rick Jones <[EMAIL PROTECTED]> wrote:
> Potential bugs notwithstanding, given that this is a STREAM socket, and
> as such shouldn't (I hope, or I'm eating toes for dinner again) have
> side effects like tossing the rest of a datagram, why are you using
> MSG_PEEK? Why not simply rea
On Tue, Jan 08, 2008 at 05:23:05PM -0500, John W. Linville wrote:
> Jeff,
>
> Another round of patches intended for 2.6.25...the biggest factions are
> rt2x00 and b43 updates, as well as some Viro-isms... :-)
>
> Please let me know if there are any problems!
>
> John
>
> P.S. Copying Dave in c
From: "Ramkrishna Vepa" <[EMAIL PROTECTED]>
Date: Tue, 8 Jan 2008 13:17:03 -0500
> Dave,
>
> This change is not required as the macro, is_s2io_card_up() checks for
> an internal state of the adapter and not netif's state. We want to make
> sure that the adapter registers are not accessed when the
From: John Heffner <[EMAIL PROTECTED]>
Date: Tue, 08 Jan 2008 11:51:53 -0500
> I haven't thought about this too hard, but can we approximate this by
> moving scaked data into a sacked queue, then if something bad happens
> merge this back into the retransmit queue?
That defeats the impetus for
Potential bugs notwithstanding, given that this is a STREAM socket, and
as such shouldn't (I hope, or I'm eating toes for dinner again) have
side effects like tossing the rest of a datagram, why are you using
MSG_PEEK? Why not simply read the N bytes of the message that will have
the message l
Hello,
I was coding an application which passes variable-length messages
over an AF_UNIX SOCK_STREAM socket. As such I would pass a message
length embedded as the first element in the message, use recv(...,MSG_PEEK)
to determine the message length, and perform the necessary allocation
on the rece
Hello !
as suggested by Ian McDonald, i`m forwarding this to dccp and netdev mailing
lists.
> hi !
>
> i know dccp_ccid2 and ccid3 modules are considered experimental, but i`m
> unsure if i probably triggered a bug inside or outside that modules here (i`m
> no kernel developer)
>
> apparently
On Sun, Dec 30, 2007 at 11:39:31AM -0500, Pavel Roskin wrote:
> Quoting Marcin Juszkiewicz <[EMAIL PROTECTED]>:
>
>> + PCMCIA_DEVICE_PROD_ID1233(
>> + "The Linksys Group, Inc.", "Wireless Network CF Card",
>> "ISL37300P",
>> + 0xa5f472c2, 0x9c05598d, 0xc9049a39),
[EMAIL PROTECTED] <[EMAIL PROTECTED]> :
> I take that back. This patch does NOT fix the leak, at least if
> ping: sendmsg: No buffer space available
> is any indication...
Can you try the patch below ?
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index dbd23bb..c304e5c 100644
--- a/drivers
[EMAIL PROTECTED] <[EMAIL PROTECTED]> :
[...]
> diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
> index 3860fcd..b3d3fc8 100644
> --- a/drivers/net/ipg.c
> +++ b/drivers/net/ipg.c
> @@ -202,12 +202,31 @@ static u16 read_phy_bit(void __iomem * ioaddr, u8
> phyctrlpolarity)
> }
>
> /*
> + * T
It seems commit fda9ef5d679b07c9d9097aaf6ef7f069d794a8f9 introduced a RCU
protection for sk_filter(), without a rcu_dereference()
Either we need a rcu_dereference(), either a comment should explain why we
dont need it. I vote for the former.
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
di
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
[...]
>Jay's patches will not fix this issue. I think something like this did
>it for me, but as I mentioned to Jay in the last thread, I'm not
>convinced it doesn't violate some of the locking expectations we have.
>
>diff --git a/drivers/net/bonding/bon
On Tue, 8 Jan 2008, Arjan van de Ven wrote:
>
> ok done; I had to fizzle a bit because some things aren't *exactly* a
> BUG() statement but I track them anyway (things like the "sleeping in
> invalid context" check), so I had to somewhat arbitrarily assign
> categories for those. I might fine
Krzysztof Oledzki <[EMAIL PROTECTED]> wrote:
>On Mon, 7 Jan 2008, Jay Vosburgh wrote:
>
>> Following are three fixes to fix locking problems and
>> silence locking-related warnings in the current 2.6.24-rc.
>>
>> patch 1: fix locking in sysfs primary/active selection
>>
>> Call core
On Tue, Jan 08, 2008 at 07:50:22PM +0100, Krzysztof Oledzki wrote:
>
>
> On Mon, 7 Jan 2008, Jay Vosburgh wrote:
>
> > Following are three fixes to fix locking problems and
> >silence locking-related warnings in the current 2.6.24-rc.
> >
> > patch 1: fix locking in sysfs primary/active
Linus Torvalds wrote:
On Tue, 8 Jan 2008, Arjan van de Ven wrote:
the database has the information so it's just a matter of slightly different
php code ;)
Before I do that... do you want the BUG's separate, part of the warnings or
part of the oopses?
(I rather make this change once ;)
I'd lik
David Miller wrote:
> [NET]: Make ->poll() breakout consistent in Intel ethernet drivers.
>
> This makes the ->poll() routines of the E100, E1000, E1000E, IXGB, and
> IXGBE drivers complete ->poll() consistently.
>
> Now they will all break out when the amount of RX work done is less
> than 'budg
On Mon, 7 Jan 2008, Jay Vosburgh wrote:
Following are three fixes to fix locking problems and
silence locking-related warnings in the current 2.6.24-rc.
patch 1: fix locking in sysfs primary/active selection
Call core network functions with expected locks to
eliminate
On Tuesday 08 January 2008, Johannes Berg wrote:
>
> > I see that the rndis_wext.c Kconfig won't kick in unless the
> > 802.11 stuff is available ... what additional dependencies
> > does that imply for a fatter rndis_host module?
>
> No extra modules are currently required for just plain wext [1
It is an embedded system, With a small file system and 2.6.23 kernel.
There are no link-monitoring tool running. I will
Try to reproduce with 2.6.24-rc7.
Chathu
-Original Message-
From: ext Kok, Auke [mailto:[EMAIL PROTECTED]
Sent: Monday, January 07, 2008 5:10 PM
To: Chathu Jayakrishn
alg_key_len is the length in bits of the key, not in bytes.
Best way to fix this is to move alg_len() function from net/xfrm/xfrm_user.c
to include/net/xfrm.h, and to use it in xfrm_algo_clone()
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
include/net/xfrm.h |7 ++-
net/xfrm/xfr
On Tue, 8 Jan 2008, Arjan van de Ven wrote:
>
> the database has the information so it's just a matter of slightly different
> php code ;)
> Before I do that... do you want the BUG's separate, part of the warnings or
> part of the oopses?
> (I rather make this change once ;)
I'd like them all s
Linus Torvalds wrote:
Cool.
One thing I wonder about - could you separate out the bug-ons and warnings
from the oopses? They really are different issues, and an oops with
register information etc is very different from a BUG() with line numbers,
which in turn is very different from a WARN_ON(
Dave,
This change is not required as the macro, is_s2io_card_up() checks for
an internal state of the adapter and not netif's state. We want to make
sure that the adapter registers are not accessed when the adapter is
being brought down.
> @@ -2704,9 +2704,6 @@ static int s2io_poll(struct napi_st
On Tue, 8 Jan 2008, Arjan van de Ven wrote:
>
> I've made life easier for those using the www.kerneloops.org website;
> at least for x86 oopses the website now does this for you and shows
> the decoded Code: line in the raw oops data:
>
> http://www.kerneloops.org/raw.php?rawid=2716
Cool.
One
Randy Dunlap wrote:
(You can do it other and smarter ways too, I'm not claiming that's a
particularly good way to do it, and the old "ksymoops" program used to do
a pretty good job of this, but I'm used to that particular idiotic way
myself, since it's how I've basically always done it)
One
> I see that the rndis_wext.c Kconfig won't kick in unless the
> 802.11 stuff is available ... what additional dependencies
> does that imply for a fatter rndis_host module?
No extra modules are currently required for just plain wext [1]. In the
future, we hope to migrate stuff to cfg80211 though
This is a preliminary release that includes all the changes for new
features in 2.6.24. It should be backward compatible with older kernels.
http://devresources.linux-foundation.org/dev/iproute2/download/iproute2-2.6.24-rc7.tar.bz2
Note: This release is for validation (don't put it in your d
Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> I usually just compile a small program like
Just use scripts/decodecode and cat the Code line into that.
> particularly good way to do it, and the old "ksymoops" program used to do
> a pretty good job of this, but I'm used to that particular idiotic
Minor update to bridge-utils. Mostly fixing bugs in usage of sysfs.
Release tarball:
http://downloads.sourceforge.net/bridge/bridge-utils-1.4.tar.gz
Alon Bar-Lev (1):
Allow bridge-utils to run when no TCP/IP is available
Denys Vlasenko (1):
fix use of sysfs (affects 32/64 bit compa
David Miller wrote:
Ilpo, just trying to keep an old conversation from dying off.
Did you happen to read a recent blog posting of mine?
http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2007/12/31#tcp_overhead
I've been thinking more and more and I think we might be able
to get away with
Denys Vlasenko wrote:
On Monday 31 December 2007 17:00, Patrick McHardy wrote:
Denys Vlasenko wrote:
ip[6]_tables.c seem to abuse inline.
This patch removes inlines except those which are used
by packet matching code and thus are performance-critical.
Some people also consider the ruleset
Pavel Emelyanov wrote:
The conntracks subsystem has a similar infrastructure
to maintain ctl_paths, but since we already have it
on the generic level, I think it's OK to switch to
using it.
So, basically, this patch just replaces the ctl_table-s
with ctl_path-s, nf_register_sysctl_table with
re
Pavel Emelyanov wrote:
This includes the most simple cases for netfilter.
The first part is tne queue modules for ipv4 and ipv6,
on which the net/ipv4/ and net/ipv6/ paths are reused
from the appropriate ipv4 and ipv6 code.
The conntrack module is also patched, but this hunk is
very small an
On Mon, 7 Jan 2008 19:26:12 -0800 (PST) Linus Torvalds wrote:
> On Mon, 7 Jan 2008, Kevin Winchester wrote:
>
> > J. Bruce Fields wrote:
> > >
> > > Is there any good basic documentation on this to point people at?
> >
> > I would second this question. I see people "decode" oops on lkml often
The conntracks subsystem has a similar infrastructure
to maintain ctl_paths, but since we already have it
on the generic level, I think it's OK to switch to
using it.
So, basically, this patch just replaces the ctl_table-s
with ctl_path-s, nf_register_sysctl_table with
register_sysctl_paths() and
This includes the most simple cases for netfilter.
The first part is tne queue modules for ipv4 and ipv6,
on which the net/ipv4/ and net/ipv6/ paths are reused
from the appropriate ipv4 and ipv6 code.
The conntrack module is also patched, but this hunk is
very small and simple.
Signed-off-by:
This one is almost the same as the hunks in the
first patch, but ax25 tables are created dynamically.
So this patch differs a bit to handle this case.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
net/ax25/sysctl_net_ax25.c | 27 +--
1 files changed, 5 insert
The decnet includes two places to patch. The first one is
the net/decnet table itself, and it is patched just like
other subsystems in the first patch in this series.
The second place is a bit more complex - it is the
net/decnet/conf/xxx entries,. similar to those in
ipv4/devinet.c and ipv6/ad
* FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> The patches are available at:
>
> http://www.kernel.org/pub/linux/kernel/people/tomo/iommu/
>
> Or if you prefer the git tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git
> iommu-sg-fixes
btw., these improvements to
The feature of ipvs ctls is that the net/ipv4/vs path
is common for core ipvs ctls and for two schedulers,
so I make it exported and re-use it in modules.
Two other .c files required linux/sysctl.h to make the
extern declaration of this path compile well.
Signed-off-by: Pavel Emelyanov <[EMAIL PR
This patch includes many places, that only required
replacing the ctl_table-s with appropriate ctl_paths
and call register_sysctl_paths().
Nothing special was done with them.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
net/appletalk/sysctl_net_atalk.c | 24 +---
This set almost completes the ctl paths usage in the
networking code. The first patches doing this were accepted
in the last year :), but they tuned only core, ipv4 and ipv6.
I thought, that splitting this into many subsystem would
produce too many patches, so I splitted it so, that most
subsys
Hi,
Remove two unused macros, INV_FLAG and SET_BITMASK
from net/bridge/netfilter/ebt_vlan.c.
Regards,
Rami Rosen
Signed-off-by: Rami Rosen <[EMAIL PROTECTED]>
diff --git a/net/bridge/netfilter/ebt_vlan.c b/net/bridge/netfilter/ebt_vlan.c
index a43c697..0ddf749 100644
--- a/net/bridge/netfilte
device_type property is bogus, thus use proper compatible.
Also change compatible property to "fsl,ucc-mdio".
Per http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048388.html
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc832x_mds.dts |3 +--
arch/powe
This is patch 2 in the set and uses the routines provided by the previous
patch to implement parsing of received Ack Vectors, replacing duplicate code.
Signed-off-by: Gerrit Renker <[EMAIL PROTECTED]>
---
net/dccp/ccids/ccid2.c | 132
net/dccp/cci
The problem with Ack Vectors is that
i) their length is variable and can in principle grow quite large,
ii) it is hard to predict exactly how large they will be.
Due to the second point it seems not a good idea to reduce the MPS;
i particular when on average there is enough room for the Ack V
This patch replaces an almost identical reduplication of code; large parts of
dccp_parse_options() are repeated as ccid2_ackvector() in ccid2.c.
Two problems are involved, apart from the duplication:
1. no separation of concerns: CCIDs should not need to be concerned with the
details of parsi
This is the "new stuff" for Ack Vectors, completing the Ack Vector work.
All other patches are as before, with the single exception of the update sent
yesterday (the recovery strategy for dealing with suddenly large losses).
Arnaldo, can you please indicate whether I should resubmit the older pat
I take that back. This patch does NOT fix the leak, at least if
ping: sendmsg: No buffer space available
is any indication...
I think I was reading slabinfo wrong.
kmalloc-2048 42111 42112 204842 : tunables000 :
slabdata 10528 10528 0
Sorry for the false hope
Prompted by davem, this attempt at fixing the memory leak
actually appears to work. At least, leaving ping -f -s1472 -l64
running doesn't drop packets and doesn't show up in /proc/slabinfo.
---
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index dbd23bb..a0dfba5 100644
--- a/drivers/net/ipg.c
This is a fairly basic code cleanup that annoyed me while working
on the first patch.
---
diff --git a/drivers/net/ipg.h b/drivers/net/ipg.h
index d5d092c..5d7cc84 100644
--- a/drivers/net/ipg.h
+++ b/drivers/net/ipg.h
@@ -789,11 +789,6 @@ struct ipg_rx {
__le64 frag_info;
};
-struct SJu
1 - 100 of 114 matches
Mail list logo
