From: Timo_Teräs <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 09:38:15 +0200
> David Miller wrote:
> > From: Timo_Teräs <[EMAIL PROTECTED]>
> > Date: Thu, 17 Jan 2008 08:27:14 +0200
> >
> >> I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
> >> So I'd say pfkey might be a bi
On Thursday 17 January 2008, David Miller wrote:
> From: "Brandeburg, Jesse" <[EMAIL PROTECTED]>
>
> > We spent Wednesday trying to reproduce (without the patch) these issues
> > without much luck, and have applied the patch cleanly and will continue
> > testing it. Given the simplicity of the cha
David Miller wrote:
> From: Timo_Teräs <[EMAIL PROTECTED]>
> Date: Thu, 17 Jan 2008 08:27:14 +0200
>
>> I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
>> So I'd say pfkey might be a bit more portable. Though netlink is definitely
>> more robust and extensive.
>
> The RFC
From: "Brandeburg, Jesse" <[EMAIL PROTECTED]>
Date: Wed, 16 Jan 2008 23:09:47 -0800
> We spent Wednesday trying to reproduce (without the patch) these issues
> without much luck, and have applied the patch cleanly and will continue
> testing it. Given the simplicity of the changes, and the commun
From: Timo_Teräs <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 08:27:14 +0200
> I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
> So I'd say pfkey might be a bit more portable. Though netlink is definitely
> more robust and extensive.
The RFCs say absolutely nothing about po
David Miller wrote:
> From: "Brandeburg, Jesse" <[EMAIL PROTECTED]>
> Date: Tue, 15 Jan 2008 13:53:43 -0800
>
>> The tx code has an "early exit" that tries to limit the amount of tx
>> packets handled in a single poll loop and requires napi or interrupt
>> rescheduling based on the return value fr
There is no Documentation/networking/e1000e.txt.
Signed-off-by: Jason Uhlenkott <[EMAIL PROTECTED]>
Cc: Auke Kok <[EMAIL PROTECTED]>
---
Index: linux/drivers/net/Kconfig
===
--- linux.orig/drivers/net/Kconfig 2008-01-16 17:48:03
Is there any reason why these bugs should be treated gently? The
caller might not want to check NR_IRQS and IRQ_NOREQUEST cases, but
a NULL handler or NULL dev_id w/ shared are coding bugs.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
kernel/irq/manage.c |7 +++
1 file changed, 3
I assume that these ancient network drivers were trying to find out if
an irq is available. eepro.c expecting +EBUSY was doubly wrong.
I'm not sure that can_request_irq() is the right thing, but these drivers
are definitely wrong.
request_irq should BUG() on bad input, and these would have been
Herbert Xu wrote:
> jamal <[EMAIL PROTECTED]> wrote:
>> There are two issues that are inter-mingled in there. The most important
>> is pf_key not being robust on dump. The other being the accurracy of
>
> IMHO doing significant work on af_key is a waste of time. It has no
> advantages at all over
jamal wrote:
> On Wed, 2008-16-01 at 16:28 +0200, Timo Teräs wrote:
>> > No. I'm not creating second copies of the SADB/SPD entries. The entries
>> > are just added to one more list.
>
> Ah, sorry - yes, that sounds reasonable.
> So what happens if i delete an entry; does it get removed from the l
Maybe I'm wrong, but since this read_lock() is given and taken anyway,
it seems this looks a bit better to me (why hold this rtnl longer
than needed?):
read_unlock(&bond->lock);
rtnl_unlock();
read_lock(&bond->lock);
Seems better.
On the other han
But, since during this change from sysfs cancel_delayed_work_sync()
could be probably used, and it's rather efficient with killing
rearming works, it seems this check could be unnecessary yet.
What going to be cancelled in bonding_store_miimon() when setting miimon to 0
is arp monitor, not mii mo
Ben Greear <[EMAIL PROTECTED]> writes:
> Dan Nicolaescu wrote:
> > Ben Greear <[EMAIL PROTECTED]> writes:
> >
> > > Dan Nicolaescu wrote:
> > > > Hi,
> > > >
> > > > I have posted this patch in the past with absolutely no reply.
> > > > I would appreciate some sort of fee
On Wed, Jan 16, 2008 at 08:39:40PM -0500, jamal wrote:
>
> I wouldnt disagree except some apps like racoon which depend on pfkey
> are unfortunately beyond repair. Timo has a pretty good handle on the
Racoon doesn't use pfkey dumping as far as I know.
Cheers,
--
Visit Openswan at http://www.open
On Thu, 2008-17-01 at 09:58 +1100, Herbert Xu wrote:
> IMHO doing significant work on af_key is a waste of time. It has no
> advantages at all over xfrm_user since neither is portable. So we
> should discourage people from using af_key wherever possible.
I wouldnt disagree except some apps like
On Wed, 2008-16-01 at 16:28 +0200, Timo Teräs wrote:
[..]
> Creating a separate af_key patch would not be a big problem. I was
> just hoping avoiding it as the xfrm_state / xfrm_policy changes
> modify the API and requires changing af_key also.
The way dumping is done by xfrm_user is consistent ac
David Stevens said the following on 2008-1-17 0:23:
> Wang,
> I think your patch is correct; did you test the same case for
> IPv6?
>
I've tested IPv4, but IPv6 not yet.
If Davem accept this one, I will see the IPv6, or you take care of it.
--
WCN
--
To unsubscribe from this list: send
[EMAIL PROTECTED] wrote on 01/16/2008 03:17:29 PM:
> Fair enough. How about moving this code back into icmp.c and just
> add a new count call in raw.c? The push pending function is used on
> the UDP fast path so the leaner it is the better.
I started out with it there, but it certainly w
David Stevens <[EMAIL PROTECTED]> wrote:
>
>The patch was to support the ICMPMsgStats table. Since none of
> certain
> types of output ICMP messages are generated by the kernel, but are
> required
> by the RFC, counting raw sockets is intentional (and the only way those
> ICMP
> types ca
jamal <[EMAIL PROTECTED]> wrote:
>
> There are two issues that are inter-mingled in there. The most important
> is pf_key not being robust on dump. The other being the accurracy of
IMHO doing significant work on af_key is a waste of time. It has no
advantages at all over xfrm_user since neither i
On Wed, Jan 16, 2008 at 09:04:58PM +0100, Willy Tarreau wrote:
...
> you can work with latest release provided that you always have a fallback
> to an earlier one. That way, you don't bet too much on something you don't
> completely control. If it works, it tells you you'll be able to completely
>
net/sctp/sm_statefuns.c: In function 'sctp_sf_do_5_1C_ack':
net/sctp/sm_statefuns.c:484: warning: 'error' may be used uninitialized in this
function
It is not obvious that this is a false positive.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [E
Dave,
One more fix for rfkill in 2.6.24...note that this branch is based
on 2.6.24-rc8.
Thanks,
John
---
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-davem/
---
The following changes since commit cbd9c883696da72b2b1f03
Jeff,
A few more fixes for 2.6.24...note that this branch is based
on 2.6.24-rc8.
Thanks,
John
---
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/
---
The following changes since commit cbd9c883696da72b2b1f03f909
On Wed, Jan 16, 2008 at 07:58:36AM +0100, Jarek Poplawski wrote:
> On Wed, Jan 16, 2008 at 11:17:08AM +1100, Herbert Xu wrote:
> ...
> > Well people are always going to operate on this model for commercial
> > reasons. FWIW I used to work for a company that stuck to a specific
> > version of the L
Ritesh Kumar wrote:
On 1/16/08, Bill Fink <[EMAIL PROTECTED]> wrote:
On Tue, 15 Jan 2008, Ritesh Kumar wrote:
Hi,
I am using linux 2.6.20 and am trying to limit the receiver window
size for a TCP connection. However, it seems that auto tuning is not
turning itself off even after I use the
On 1/16/08, Bill Fink <[EMAIL PROTECTED]> wrote:
> On Tue, 15 Jan 2008, Ritesh Kumar wrote:
>
> > Hi,
> > I am using linux 2.6.20 and am trying to limit the receiver window
> > size for a TCP connection. However, it seems that auto tuning is not
> > turning itself off even after I use the sysca
On Wed, 16 Jan 2008 18:04:53 +0800
<[EMAIL PROTECTED]> wrote:
>
> In SMP, if a bridge fdb is being created when another CPU at the same time
> delete the bridge, this newly created fdb may incur a leakage:
>
> CPU0:
>
> static void del_nbp(struct net_bridge_port *p)
> {
> /*
>* CP
On Wed, 16 Jan 2008 05:59:21 +0100
Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Patrick McHardy wrote:
> > Very nice catch, that explains quite a few bug reports about
> > refcnt leaks. Your patch looks correct and performs the copying
> > in the logically correct place, it would be nicer to keep
Dan Nicolaescu wrote:
Ben Greear <[EMAIL PROTECTED]> writes:
> Dan Nicolaescu wrote:
> > Hi,
> >
> > I have posted this patch in the past with absolutely no reply.
> > I would appreciate some sort of feedback of the form interested/not
> > interested. Should I just drop it?
> >
Ben Greear <[EMAIL PROTECTED]> writes:
> Dan Nicolaescu wrote:
> > Hi,
> >
> > I have posted this patch in the past with absolutely no reply.
> > I would appreciate some sort of feedback of the form interested/not
> > interested. Should I just drop it?
> >
> >
> I like it, bu
Dan Nicolaescu wrote:
Hi,
I have posted this patch in the past with absolutely no reply.
I would appreciate some sort of feedback of the form
interested/not interested. Should I just drop it?
I like it, but why not offer this for all devices since they all have
these stats.
Could add ne
I noticed "ip route list" was slower than "cat /proc/net/route" on a machine
with a full Internet
routing table (214392 entries : Special thanks to Robert ;) )
This is similar to problem reported in commit
d8c9283089287341c85a0a69de32c2287a990e71
Fix is to avoid scanning the begining of fz_hash
David Miller writes:
> > On Wednesday 16 January 2008, David Miller wrote:
> > > Ok, here is the patch I'll propose to fix this. The goal is to make
> > > it as simple as possible without regressing the thing we were trying
> > > to fix.
> >
> > Looks good to me. Tested with -rc8.
>
> T
Herbert Xu <[EMAIL PROTECTED]> wrote on 01/16/2008 03:49:01 AM:
> Actually having the icmp_out_count call in ip_push_pending_frames seems
> inconsistent. Having it there means that we count raw socket ICMP
packets
> too. But we don't do that for any other protocol, e.g., raw UDP packets
> don't
Hi,
I have posted this patch in the past with absolutely no reply.
I would appreciate some sort of feedback of the form
interested/not interested. Should I just drop it?
"ethtool -S" only supports devices that have custom code written to
print the stats.
A lot of drivers use "struct net_devi
The garbage collection function receive the dst_ops structure as
parameter. This is useful for the next incoming patchset because
it will need the dst_ops (there will be several instances) and
the network namespace pointer (contained in the dst_ops).
The protocols which do not take care of the na
The network namespace pointer can be stored into the dst_ops structure.
This is usefull when there are multiple instances of the dst_ops for a
protocol. When there are no several instances, this field will be never
used in the protocol. So there is no impact for the protocols which do
implement the
The two following patches do trivial changes to facilitate the
implementation of the network namespace in some protocols.
The first one pass the dst_ops as parameter to the gc functions.
The second patch just adds a netns pointer field into the dst_ops
structure.
--
--
To unsubscribe from this l
On Wed, 16 Jan 2008 20:53:59 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
> > With the removal the the "rgmii-interface" device_type property from the
> > dts files, the newemac driver needs an update to only rely on compatible
jamal wrote:
> On Sun, 2008-13-01 at 14:26 +0200, Timo Teräs wrote:
>> I tried to address all these problems, and added the xfrm_policy
>> and xfrm_state structure to a new linked list that is used solely
>> for dumping. This way the dumps can be done in O(n) and have an
>> iterator point to them.
Timo,
Thanks for the effort you are putting on this.
I would just speak to the concepts instead of the code - hopefully that
would simulate a discussion (and shorten my email)
On Sun, 2008-13-01 at 14:26 +0200, Timo Teräs wrote:
> Hi all,
>
> The problem with IPsec SP/SA dumping is that they do
Hello,
A question about compiling as module using the 2.6.25 git tree:
I had git cloned the 2.6.25 DaveM tree.
I ran "make menuconfig".
In many cases I see in the help:
"To compile this code as a module, choose M here: the
module will be called ..."
For example, in "Packet Generator" or in 802.1d
On Wed, Jan 16, 2008 at 12:19:51PM +0900, Makito SHIOKAWA wrote:
> This patch is supposing a case that bond_mii_monitor() is invoked in
> bond_open(), and after that, 0 is set to miimon via sysfs (see same place
> on other monitors).
> Though message in bonding_store_miimon() says miimon value 1-
On Mon, 2008-14-01 at 20:20 -0200, Dzianis Kahanovich wrote:
> jamal wrote:
[..]
> > Did that make sense?
>
> After current "#endif" - may be.
I am afraid that would be counter to expected behavior.
Default is meant to apply when no value has been defined. Mark of 0 for
example doesnt mean "def
On 15-01-2008 07:36, Makito SHIOKAWA wrote:
> Fix some RTNL lock taking:
>
> * RTNL (mutex; may sleep) must not be taken under read_lock (spinlock; must be
> atomic). However, RTNL is taken under read_lock in bond_loadbalance_arp_mon()
> and bond_activebackup_arp_mon(). So change code to take RTNL
From: <[EMAIL PROTECTED]>
Date: Wed, 16 Jan 2008 18:04:53 +0800
> In SMP, if a bridge fdb is being created when another CPU at the same time
> delete the bridge, this newly created fdb may incur a leakage:
netdev@vger.kernel.org (CC:'d) is the proper place to report
things like this.
'linux-net'
From: Badalian Vyacheslav <[EMAIL PROTECTED]>
Date: Wed, 16 Jan 2008 12:02:28 +0300
> Also have regression after apply patch.
BTW, if you are using the e1000e driver then this initial
patch will not work.
My more recent patch posting for this problem, will.
I include it again below for you:
[N
From: Badalian Vyacheslav <[EMAIL PROTECTED]>
Date: Wed, 16 Jan 2008 12:02:28 +0300
> applied to 2.6.24-rc7-git2
> Have messages
> Also have regression after apply patch.
> System may do above 800mbs traffic before patch. After its "exit polling
> mode?" (4 CPU, 1 cpu get 100% si (process ksoftir
The problem with introducing IFF_GSO_HDR is that it needs to set dev->features
(to enable GSO, checksumming, etc), which is supposed to be done before
register_netdevice(), ie. as part of TUNSETIFF.
Unfortunately, TUNSETIFF has always just ignored flags it doesn't understand,
so there's no good wa
OK, revised with help from Herbert. Also, I have attached a test program and
a script to run it (it short-circuits two tun devices, so you can run it with
the patch applied and see big packets flowing).
This implements partial checksum and GSO support for tun/tap.
We use the virtio_net_hdr: it i
Wang Chen <[EMAIL PROTECTED]> wrote:
> In tree net-2.6.25, commit "96793b482540f3a26e2188eaf75cb56b7829d3e3"
> made a mistake.
>
> In that patch, David L added a icmp_out_count() in ip_push_pending_frames(),
> remove icmp_out_count() from icmp_reply(). But he forgot to remove
> icmp_out_count() f
Hello All,
I am sure that the TDM bus driver model/framework will make us put a lot
more programming effort without
any assurance of the code being accepted by the Linux community,
especially as there are many
Telephony/VoIP stack implementations in Linux such as the Sangoma
WANPIPE Kernel suite
http://bugzilla.kernel.org/show_bug.cgi?id=9493
The fib allows making identical routes with 'ip route replace'.
This patch makes the fib return -EEXIST if replacement would cause duplication.
Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]>
---
net/ipv4/fib_trie.c |3 +++
1 files changed, 3 i
http://bugzilla.kernel.org/show_bug.cgi?id=9493
The fib allows making identical routes with 'ip route replace'.
This patch makes the fib return -EEXIST if replacement would cause duplication.
Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]>
---
net/ipv4/fib_hash.c |3 +++
1 files changed, 3 i
From: Frans Pop <[EMAIL PROTECTED]>
Date: Wed, 16 Jan 2008 09:56:08 +0100
> On Wednesday 16 January 2008, David Miller wrote:
> > Ok, here is the patch I'll propose to fix this. The goal is to make
> > it as simple as possible without regressing the thing we were trying
> > to fix.
>
> Looks goo
In tree net-2.6.25, commit "96793b482540f3a26e2188eaf75cb56b7829d3e3"
made a mistake.
In that patch, David L added a icmp_out_count() in ip_push_pending_frames(),
remove icmp_out_count() from icmp_reply(). But he forgot to remove
icmp_out_count() from icmp_send() too.
Since icmp_send and icmp_rep
On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
> With the removal the the "rgmii-interface" device_type property from the
> dts files, the newemac driver needs an update to only rely on compatible
> property.
>
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
I need to test if it works
On Tue, 15 Jan 2008, Ritesh Kumar wrote:
> Hi,
> I am using linux 2.6.20 and am trying to limit the receiver window
> size for a TCP connection. However, it seems that auto tuning is not
> turning itself off even after I use the syscall
>
> rwin=65536
> setsockopt(sock, SOL_SOCKET, SO_RCVBUF,
On Wed, Jan 16, 2008 at 10:37:10AM +0100, Stefan Roese wrote:
> With the removal the the "rgmii-interface" device_type property from the
> dts files, the newemac driver needs an update to only rely on compatible
> property.
In fact, this patch should go in before the one changing the dts
files.
-
With the removal the the "rgmii-interface" device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
property.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/rgmii.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-
On Wed, Jan 16, 2008 at 11:35:35AM +0300, Badalian Vyacheslav wrote:
...
> I simple recreate all rules. I change idea from do many add,change,delete
> because have many kernel panics on many kernels 2.6.x
> First i have panics on "delete filter" operation... was fix it... great..
> then have pani
applied to 2.6.24-rc7-git2
Have messages
Also have regression after apply patch.
System may do above 800mbs traffic before patch. After its "exit polling
mode?" (4 CPU, 1 cpu get 100% si (process ksoftirqd/0), 3 CPU is IDLE)
After patch system was go to "exit polling mode" at above 600mbs.
Than
On Wednesday 16 January 2008, David Miller wrote:
> Ok, here is the patch I'll propose to fix this. The goal is to make
> it as simple as possible without regressing the thing we were trying
> to fix.
Looks good to me. Tested with -rc8.
Cheers,
FJP
--
To unsubscribe from this list: send the line
Jarek Poplawski пишет:
On Wed, Jan 16, 2008 at 09:05:47AM +0100, Patrick McHardy wrote:
...
Yes, thats one possibility (without the dummy device though please).
But I wonder what this would actually be useful for. I don't think
replacing the root qdisc by a different type is a common scenario
On Wed, Jan 16, 2008 at 09:05:47AM +0100, Patrick McHardy wrote:
...
> Yes, thats one possibility (without the dummy device though please).
> But I wonder what this would actually be useful for. I don't think
> replacing the root qdisc by a different type is a common scenario,
> for the same type y
Yes, thats one possibility (without the dummy device though please).
But I wonder what this would actually be useful for. I don't think
replacing the root qdisc by a different type is a common scenario,
for the same type you can simply use "tc qdisc change", "tc class
change" and "tc class rep
Jarek Poplawski wrote:
On Wed, Jan 16, 2008 at 06:02:00AM +0100, Patrick McHardy wrote:
...
This would need support from the qdiscs to do it properly. Looks
non-trivial for HTB/HFSC/CBQ, but the others shouldn't be that hard.
Yes. At first I've thought this would need quite a lot of work, but
69 matches
Mail list logo
