xfrm_state_clone() is not used outside of net/xfrm/xfrm_state.c
There is no need to export it.
Spoted by sparse checker.
CHECK net/xfrm/xfrm_state.c
net/xfrm/xfrm_state.c:1103:19: warning: symbol 'xfrm_state_clone' was not
declared. Should it be static?
Signed-off-by: Eric Dumazet [EMAIL
David Miller [EMAIL PROTECTED] :
[...]
I invested 30 seconds of code reading to figure out the leak. A much
better investment of time than adding bogus comments to the Kconfig
help text don't you think? :-)
Thanks for the hint David.
I'll roll up a patch for it after the day work.
--
On Mon, Jan 07, 2008 at 09:55:50PM -0800, David Miller wrote:
Can you replace the printk()'s with comments at least?
Otherwise nobody is going to remember what we were trying
to accomplish here and it will guarentee that, in fact,
support for these old things will never get removed.
At
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 08 Jan 2008 09:00:20 +0100
xfrm_state_clone() is not used outside of net/xfrm/xfrm_state.c
There is no need to export it.
Spoted by sparse checker.
CHECK net/xfrm/xfrm_state.c
net/xfrm/xfrm_state.c:1103:19: warning: symbol
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 08 Jan 2008 08:53:10 +0100
It warns us because rt_cache_get_first() can returns with RCU_BH
*acquired* or not.
As Herbert mentioned that's a pretty often used paradigm called
conditional locking. :-)
--
To unsubscribe from this list: send the
On Mon, 7 Jan 2008, David Miller wrote:
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 8 Jan 2008 06:00:07 +0100
On Mon, Jan 07, 2008 at 07:37:00PM -0800, David Miller wrote:
The vast majority of them are one, two, and three liners.
% awk ' { line++ } ; /^{/ { total++; start = line
On Tue, 8 Jan 2008, Andi Kleen wrote:
David Miller [EMAIL PROTECTED] writes:
Similarly I question just about any inline usage at all in *.c files
Don't forget the .h files. Especially a lot of stuff in tcp.h should
be probably in some .c file and not be inline.
I'm not forgetting
On Wednesday 02 January 2008, Jussi Kivilinna wrote:
Hello,
Bjorge was not comfortable with double probing rndis_wext requires,
wireless RNDIS devices have same device id as the rest of RNDIS.
I should have known Microsoft wouldn't start by assuming systems
software module boundaries should
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 PROTECTED]
diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index
On Mon, 7 Jan 2008, David Miller wrote:
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 enforcing that SACKs are always
On 08-01-2008 08:53, Eric Dumazet wrote:
David Miller a écrit :
...
Furthermore, these:
rcu_read_unlock_bh()
rcu_read_lock_bh()
sequences are at best funny looking. For other lock types we would
look at this and ask Does this even accomplish anything reliably?
Well, original
Hi
I notice a lot of messages like
[8447790.549705] UDP: short packet: From XXX.XXX.224.29:21005 60046/1480 to
XXX.XXX.247.1:1024
[8448040.893317] UDP: short packet: From XXX.XXX.224.29:21218 17820/1480 to
XXX.XXX.247.1:49974
[8448216.603759] UDP: short packet: From XXX.XXX.224.29:21004
On Tuesday 08 January 2008 1:02:11 am David Miller wrote:
From: Paul Moore [EMAIL PROTECTED]
Date: Mon, 07 Jan 2008 12:47:48 -0500
This patch implements packet ingress/egress controls for SELinux which
allow SELinux security policy to control the flow of all IPv4 and IPv6
packets into and
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
---
akpm noticed that this code was awful.
ipg.c | 158
+- 1 file
changed, 43 insertions(+), 115 deletions(-)
should be sufficient justification all by itself.
---
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index
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
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
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
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
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
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
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
---
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 +--
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
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
* 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
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 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 +---
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
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
enough, but
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
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
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()
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
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
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
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
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
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 way
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,
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
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
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
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
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]. In
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
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
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
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 ++-
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 'budget'.
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 tune
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
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 selection
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 network
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
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]
[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)
}
/*
+ * Transmit the
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),
Acked-by:
[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
---
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, i
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 adapter
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 case he is
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 read the
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 somewhat
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 the
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
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
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
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 of
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, but this
+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);
+} while
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 */
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
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);
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 ?
Same kind of
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:[EMAIL
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_disable()
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
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 loop:
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:
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 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 convenience
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 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 patch:
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,
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 retransmit queue?
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 patches
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 worried
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
[ 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,
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?
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.
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
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
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 int
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.
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
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 to be
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
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 recovery
1 - 100 of 114 matches
Mail list logo
