From: David Howells <[EMAIL PROTECTED]>
Date: Mon, 18 Jun 2007 12:52:36 +0100
> Return the number of bytes buffered in rxrpc_send_data().
>
> Signed-off-by: David Howells <[EMAIL PROTECTED]>
Patch applied, thanks a lot David.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
From: PJ Waskiewicz <[EMAIL PROTECTED]>
Date: Mon, 18 Jun 2007 11:42:29 -0700
> +
> + /* The TX queue control structures */
> + struct net_device_subqueue *egress_subqueue;
> + int egress_subqueue_count;
Since every net device will have at least one su
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Tue, 19 Jun 2007 01:25:56 +0300
> Do you have some plans regarding tcp-2.6?
It is sort-of stuck in the mud until some real performance analysis of
the RB-Tree stuff can be done.
I'm currently knee-deep in working on support for some virtualization
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Tue, 19 Jun 2007 01:25:58 +0300
> From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= <[EMAIL PROTECTED]>
>
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
Adding this MIB item is perfectly fine, patch applied.
-
To unsubscribe from this list: send the line
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Tue, 19 Jun 2007 01:25:57 +0300
> From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= <[EMAIL PROTECTED]>
>
> SACK processing code has been sort of russian roulette as no
> validation of SACK blocks is previously attempted. It is not
> very clear what all kinds
On Mon, Jun 18, 2007 at 08:10:00AM -0700, Stephen Hemminger wrote:
> On Mon, 18 Jun 2007 13:08:49 +0200
> Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> > On 16-06-2007 23:35, Marcin .lusarz wrote:
> > > hi
> > > after upgrading kernel from 2.6.20 to 2.6.21.3 i'm experiencing really
> > > strange
From: James Morris <[EMAIL PROTECTED]>
Date: Mon, 18 Jun 2007 12:16:31 -0400 (EDT)
> -- Forwarded message --
> Date: Mon, 18 Jun 2007 12:05:49 -0400
> From: Jeff Dike <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Guido Guenther <[EMAIL PROTECTED]>, LKML <[EMAIL PROTECTED]>,
>
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 18 Jun 2007 18:09:11 +0200
> [XFRM]: Fix MTU calculation for non-ESP SAs
>
> My IPsec MTU optimization patch introduced a regression in MTU calculation
> for non-ESP SAs, the SA's header_len needs to be subtracted from the MTU if
> the transfor
On Mon, Jun 18, 2007 at 08:10:00AM -0700, Stephen Hemminger wrote:
> On Mon, 18 Jun 2007 13:08:49 +0200
> Jarek Poplawski <[EMAIL PROTECTED]> wrote:
...
> > It looks like skge driver enables different device than probbed.
> > Maybe you've something old/wrong about eth0/eth1 in /etc configs?
>
> Mo
Hi Dave,
I have copied him in these patches, so he doesn't have to read the netdev
to get them :)
- KK
David Miller <[EMAIL PROTECTED]> wrote on 06/19/2007 09:28:31 AM:
> From: Krishna Kumar2 <[EMAIL PROTECTED]>
> Date: Tue, 19 Jun 2007 09:05:28 +0530
>
> > Dave, does it make sense to add this
From: Krishna Kumar2 <[EMAIL PROTECTED]>
Date: Tue, 19 Jun 2007 09:05:28 +0530
> Dave, does it make sense to add this to 2.6.23 ? Herbert and Peter
> had earlier reviewed Patch 2/2 and said they were OK with it.
What does Jamal think of it :-)
-
To unsubscribe from this list: send the line "unsub
Thanks Peter for testing out. I forgot to mention that I had also ran a 64
process
netperf (tcp & udp) on 2--CPU SMP systems without any issues.
Dave, does it make sense to add this to 2.6.23 ? Herbert and Peter had
earlier reviewed
Patch 2/2 and said they were OK with it.
thanks,
- KK
[EMAIL
From: Zhang Rui <[EMAIL PROTECTED]>
Export ACPI events via Generic Netlink.
An "acpi_event" genetlink family message is sent
when an ACPI event is generated.
Note: The behavior of how ACPI event works nowadays is not changed.
Use genetlink to export ACPI event instead of
/proc/a
On Mon, 2007-06-18 at 11:01 -0400, jamal wrote:
> On Fri, 2007-15-06 at 09:01 +0800, Zhang Rui wrote:
>
> > > I dont have much time to look at your code given travel, but did you
> > > try to use your group id instead of the controller's?
> > > i.e:
> > > rtnl_open_byproto(&rth, nl_mgrp(mydiscover
On Mon, 2007-06-18 at 11:16 -0400, jamal wrote:
> > in your model how to
> > define the queue wakeup strategy in the driver to deal with the PHL full
> > situation? Consider about 1) both high prio and low prio packets could
> > come (you cannot predict it beforehand)
>
> I am assuming by "come"
Tim Durack <[EMAIL PROTECTED]> :
[snip]
Can you try 2.6.22-rc5 +
http://www.fr.zoreil.com/people/francois/misc/20070619-2.6.22-rc5-r8169-test.patch
It does not seem to work too bad here (tested with 2.6.22-rc5 + patch):
# grep bonding /etc/modprobe.conf
alias bond0 bonding
options bonding miimon
From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= <[EMAIL PROTECTED]>
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/snmp.h |1 +
net/ipv4/proc.c |1 +
net/ipv4/tcp_input.c |4 +++-
3 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/include/linux/snmp.h b/inc
From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= <[EMAIL PROTECTED]>
SACK processing code has been sort of russian roulette as no
validation of SACK blocks is previously attempted. It is not
very clear what all kinds of broken SACK blocks really mean
(e.g., one that has start and end sequence numbers revers
Hi,
SACK block validation to tcp-2.6 tree. Before preparing this, I rebased
tcp-2.6 to net-2.6 (not 2.6.23) because of DSACK patch in net-2.6 (some
conflicts will occur). I did some very basic testing with this. No
TCPSACKDiscards occured in it but it's kind of hard for me to fully
test the whole
Waskiewicz Jr, Peter P wrote:
Nested netlink attributes, like most qdisc use, instead of
struct tc_rr_qopt (or additionally). The way you've done it
makes it hard to add further attributes later.
I'm going to need to think about this more, since I'm not immediately
getting what you're ref
> > Hmm. This is the sch_prio from the first 2.6.23-dev tree. I'll
> > resync and make sure it's the correct one.
>
> Current 2.6.22-rc and net-2.6.23 have
>
> if (band >= q->bands)
I just pulled 2.6.23 down, and see that is true. I must have had that
left over. I'll fix that.
> >
Stephen Hemminger wrote:
> On Mon, 18 Jun 2007 22:43:50 +0200
> Patrick McHardy <[EMAIL PROTECTED]> wrote:
>
>>Unloading the driver (with your patch) crashed my box twice.
>
> Was that under load or just idle?
Pretty much idle, maybe a few NTP broadcasts flying around.
>>I've
>>attached a log o
Waskiewicz Jr, Peter P wrote:
>>>+band = TC_H_MIN(band) - 1;
>>>+if (band > q->bands) {
>>
>>You copied an off-by-one from an old sch_prio version here.
>
>
> Hmm. This is the sch_prio from the first 2.6.23-dev tree. I'll resync
> and make sure it's the correct one.
Current 2.6.22-rc a
On Mon, 18 Jun 2007 22:43:50 +0200
Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > On Mon, 18 Jun 2007 22:13:50 +0200
> > Patrick McHardy <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Stephen Hemminger wrote:
> >>
> >>>Does this fix it? It was possible for the PHY interrupt t
Stephen Hemminger wrote:
> On Mon, 18 Jun 2007 22:13:50 +0200
> Patrick McHardy <[EMAIL PROTECTED]> wrote:
>
>
>>Stephen Hemminger wrote:
>>
>>>Does this fix it? It was possible for the PHY interrupt to race
>>>while bringing link up.
>>
>>
>>No, both problems are still present.
>
>
> What har
> PJ Waskiewicz wrote:
> >
> > diff --git a/net/sched/sch_prio.c b/net/sched/sch_prio.c index
> > 6d7542c..44ecdc6 100644
> > --- a/net/sched/sch_prio.c
> > +++ b/net/sched/sch_prio.c
> > }
> > +#ifdef CONFIG_NET_SCH_PRIO_MQ
> > + /* setup queue to band mapping */
> > + if (q->bands < sch-
Waskiewicz Jr, Peter P wrote:
/* Functions used for multicast support */ diff --git
a/include/linux/skbuff.h b/include/linux/skbuff.h index
e7367c7..8bcd870 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -215,6 +215,7 @@ typedef unsigned char *sk_buff_data_t;
* @pk
> PJ Waskiewicz wrote:
> > Add the multiqueue hardware device support API to the core network
> > stack. Allow drivers to allocate multiple queues and
> manage them at
> > the netdev level if they choose to do so.
> >
>
> Should be 2/3 and qdisc changes should be 3/3. Well actually
> the q
On Mon, 18 Jun 2007 22:13:50 +0200
Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > Does this fix it? It was possible for the PHY interrupt to race
> > while bringing link up.
>
>
> No, both problems are still present.
What hardware. Could you load with messages max: m
Stephen Hemminger wrote:
> Does this fix it? It was possible for the PHY interrupt to race
> while bringing link up.
No, both problems are still present.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
Does this fix it? It was possible for the PHY interrupt to race
while bringing link up.
--- a/drivers/net/sky2.c2007-06-18 12:56:29.0 -0700
+++ b/drivers/net/sky2.c2007-06-18 13:02:11.0 -0700
@@ -652,7 +652,6 @@ static void sky2_wol_init(struct sky2_po
static v
Stephen Hemminger wrote:
> On Mon, 18 Jun 2007 21:49:49 +0200
> Patrick McHardy <[EMAIL PROTECTED]> wrote:
>
>
>>sky2 breaks reproducably in 2.6.22-rc5 when setting the interface
>>down and up again. Packets are not received on the other side,
>>after a short time tcpdump (on the sky2 side) shows
On Mon, 18 Jun 2007 21:49:49 +0200
Patrick McHardy <[EMAIL PROTECTED]> wrote:
> sky2 breaks reproducably in 2.6.22-rc5 when setting the interface
> down and up again. Packets are not received on the other side,
> after a short time tcpdump (on the sky2 side) shows
> use-after-free patterns:
>
Ha
sky2 breaks reproducably in 2.6.22-rc5 when setting the interface
down and up again. Packets are not received on the other side,
after a short time tcpdump (on the sky2 side) shows
use-after-free patterns:
IP6 (hlim 255, next-header: ICMPv6 (58), length: 16)
fe80::215:f2ff:fe24:91f8 > ff02::2: [ic
Steve Wise wrote:
I get this crash running the chelsio cxgb3 module on 2.6.22-rc5. This
is regression. I believe Divy from Chelsio has already posted a fix for
this. This needs to be in 2.6.22...
Jeff do you have this fix queued for 2.6.22?
I think Divy's patches are here:
http://lkml.o
PJ Waskiewicz wrote:
Add the multiqueue hardware device support API to the core network
stack. Allow drivers to allocate multiple queues and manage them
at the netdev level if they choose to do so.
Should be 2/3 and qdisc changes should be 3/3. Well actually the qdisc
sch_generic changes
b
PJ Waskiewicz wrote:
diff --git a/net/sched/sch_prio.c b/net/sched/sch_prio.c
index 6d7542c..44ecdc6 100644
--- a/net/sched/sch_prio.c
+++ b/net/sched/sch_prio.c
}
+#ifdef CONFIG_NET_SCH_PRIO_MQ
+ /* setup queue to band mapping */
+ if (q->bands < sch->dev->egress_subqueue_co
Add the multiqueue hardware device support API to the core network
stack. Allow drivers to allocate multiple queues and manage them
at the netdev level if they choose to do so.
Signed-off-by: Peter P Waskiewicz Jr <[EMAIL PROTECTED]>
---
include/linux/etherdevice.h |3 +-
include/linux/netd
Add a brief howto to Documentation/networking for multiqueue. It
explains how to use the multiqueue API in a driver to support
multiqueue paths from the stack, as well as the qdiscs to use for
feeding a multiqueue device.
Signed-off-by: Peter P Waskiewicz Jr <[EMAIL PROTECTED]>
---
Documentatio
Add the new sch_rr qdisc for multiqueue network device support.
Allow sch_prio to be compiled with or without multiqueue hardware
support.
Signed-off-by: Peter P Waskiewicz Jr <[EMAIL PROTECTED]>
---
include/linux/pkt_sched.h | 11 +
net/sched/Kconfig | 22 ++
net/sched/Makefile
Please consider these patches for 2.6.23 inclusion.
This patchset is an updated version of previous multiqueue network device
support patches. The general approach of introducing a new API for multiqueue
network devices to register with the stack has remained. The changes include
adding a round-
Add tc support for the sch_rr qdisc. This qdisc supports multiple queues
on hardware. The syntax for sch_rr is the same as sch_prio.
Signed-off-by: Peter P Waskiewicz Jr <[EMAIL PROTECTED]>
---
include/linux/pkt_sched.h | 11
tc/Makefile |1
tc/q_rr.c
This patch is to support the new sch_rr (round-robin) qdisc being proposed
in NET for multiqueue network device support in the Linux network stack.
It uses q_prio.c as the template, since the qdiscs are nearly identical,
outside of the ->dequeue() routine.
I'm soliciting feedback for a 2.6.23 mult
YOSHIFUJI Hideaki / 吉藤英明 wrote:
>IPSTATS_MIB_INHDRERRORS);
> @@ -465,6 +440,8 @@ looped_back:
> break;
> #ifdef CONFIG_IPV6_MIP6
> case IPV6_SRCRT_TYPE_2:
> + if (accept_source_route < 0)
> + goto unknown_r
Herbert Xu wrote:
> On Fri, Jun 15, 2007 at 03:14:57PM -0700, David Miller wrote:
>>> No, the questions should really be:
>>>
>>> 1. Is IPV6 supported over this media type.
>>> yes: got to 2
>>> no: stop
>>>
>>> 2. Is the device MTU >= IPV6_MIN_MTU
>>> yes: continue
>>> no: stop
> -Original Message-
> From: Krishna Kumar [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 17, 2007 9:51 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Waskiewicz
> Jr, Peter P; [EMAIL PROTECTED]; [EMAIL PROTECTED]; netdev@vger.kernel.org
> Subject: [PATCH 1/2 - rev
I get this crash running the chelsio cxgb3 module on 2.6.22-rc5. This
is regression. I believe Divy from Chelsio has already posted a fix for
this. This needs to be in 2.6.22...
Jeff do you have this fix queued for 2.6.22?
I think Divy's patches are here:
http://lkml.org/lkml/2007/5/30/2
On Sun, 17 Jun 2007 16:24:00 +0200
Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Here is a list of some known regressions in 2.6.22-rc5
> with patches available.
>
> Feel free to add new regressions/remove fixed etc.
> http://kernelnewbies.org/known_regressions
>
>
>
> Memory man
-- Forwarded message --
Date: Mon, 18 Jun 2007 12:05:49 -0400
From: Jeff Dike <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Guido Guenther <[EMAIL PROTECTED]>, LKML <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Subject: [PATCH] Allow group ownership of TUN/TAP devices
I recieved from
[XFRM]: Fix MTU calculation for non-ESP SAs
My IPsec MTU optimization patch introduced a regression in MTU calculation
for non-ESP SAs, the SA's header_len needs to be subtracted from the MTU if
the transform doesn't provide a ->get_mtu() function.
Reported-and-tested-by: Marco Berizzi <[EMAIL PR
On Fri, 2007-06-15 at 14:03 -0400, Zhu Han wrote:
> On 6/15/07, Kieran Mansley <[EMAIL PROTECTED]> wrote:
> >
> > The lock protects the use_count variable. The use_count variable
> > prevents the plugin module unloading while it is being used. I couldn't
> > just use the lock to prevent the modul
On Mon, 18 Jun 2007 10:56:06 -0400 Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
> Is there any way to print the addresses the notifier is calling
> to try and release net device references? I see:
>
> net/core/dev/c::netdev_wait_allrefs():
>
> while (atomic_read(&dev->refcnt) != 0) {
>
On Mon, 18 Jun 2007 10:56:06 -0400
Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
> Is there any way to print the addresses the notifier is calling
> to try and release net device references? I see:
>
> net/core/dev/c::netdev_wait_allrefs():
>
> while (atomic_read(&dev->refcnt) != 0) {
>
Hello Yi,
On Mon, 2007-18-06 at 09:18 +0800, Zhu Yi wrote:
> Would you respond the question I asked early,
I thought i did respond to all questions you asked but some may have
been lost in the noise.
> in your model how to
> define the queue wakeup strategy in the driver to deal with the PHL
On Fri, Jun 15, 2007 at 01:33:14AM +1000, David Gundersen wrote:
> In the mean-time I'll attach my patch for the r8168-8.001.00 realtek
> driver here in case anybody else wants to have a play with it and see if
> it helps them out.
Out of curiousity, does it work if you just do a single read (ie
On Mon, 18 Jun 2007 13:08:49 +0200
Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> On 16-06-2007 23:35, Marcin .lusarz wrote:
> > hi
> > after upgrading kernel from 2.6.20 to 2.6.21.3 i'm experiencing really
> > strange problem - my _both_ network cards dies after random uptime -
> > sometimes it's a
On Fri, 2007-15-06 at 09:01 +0800, Zhang Rui wrote:
> > I dont have much time to look at your code given travel, but did you
> > try to use your group id instead of the controller's?
> > i.e:
> > rtnl_open_byproto(&rth, nl_mgrp(mydiscoveredacpiid), NETLINK_GENERIC)
> >
> Yes. It doesn't work if I
Is there any way to print the addresses the notifier is calling
to try and release net device references? I see:
net/core/dev/c::netdev_wait_allrefs():
while (atomic_read(&dev->refcnt) != 0) {
if (time_after(jiffies, rebroadcast_time + 1 * HZ)) {
r
> > No, correctness always trumps performance. Lost packets on an AF_UNIX
> > socket are _unexceptable_, and this is definitely not a theoretical
> > problem.
>
> If its so unacceptable why has nobody noticed until now - its a bug
> clearly, it needs fixing clearly, but unless you can produce som
On Mon, 18 Jun 2007 12:43:40 +0200
Thomas Graf <[EMAIL PROTECTED]> wrote:
> * Miklos Szeredi <[EMAIL PROTECTED]> 2007-06-18 12:39
> > You are wrong. Look in unix_release_sock():
> >
> > if (atomic_read(&unix_tot_inflight))
> > unix_gc(); /* Garbage collect fds */
> >
Return the number of bytes buffered in rxrpc_send_data().
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
net/rxrpc/ar-output.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/rxrpc/ar-output.c b/net/rxrpc/ar-output.c
index 591c442..cc9102c 100644
--- a/net/
> > > I'm all for fixing this gc mess that we have now. But please don't
> > > expect me to be the one who's doing it.
> >
> > Don't worry, I only expect you to make the situation worse :-)
>
> In any event, I'll try to find some time to look more at your patch.
>
> But just like you don't want
On Jun 18 2007 12:47, Alan Cox wrote:
>
>> Do you want me to send the patch to Andrew instead? His attitude
>> towards bugfixes is rather better ;)
>
>And it'll get NAKked and binned. DaveM is (as happens sometimes ;)) right
>to insist on the code being clean and efficient.
Or see RFC 1925 numbe
> No, correctness always trumps performance. Lost packets on an AF_UNIX
> socket are _unexceptable_, and this is definitely not a theoretical
> problem.
If its so unacceptable why has nobody noticed until now - its a bug
clearly, it needs fixing clearly, but unless you can produce some kind of
ex
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch removes dead code spotted by the Coverity checker.
This is the wrong solution. 'copied' should be updated.
David
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch fixes a NULL dereference spotted by the Coverity checker.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: David Howells <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a messag
From: David Miller <[EMAIL PROTECTED]>
Date: Mon, 18 Jun 2007 04:02:53 -0700 (PDT)
> From: Miklos Szeredi <[EMAIL PROTECTED]>
> Date: Mon, 18 Jun 2007 12:55:24 +0200
>
> > I'm all for fixing this gc mess that we have now. But please don't
> > expect me to be the one who's doing it.
>
> Don't wo
> > I'm all for fixing this gc mess that we have now. But please don't
> > expect me to be the one who's doing it.
>
> Don't worry, I only expect you to make the situation worse :-)
That's real nice. Looks like finding and fixing bugs in not
appreciated in the networking subsystem :-/
Miklos
-
From: Miklos Szeredi <[EMAIL PROTECTED]>
Date: Mon, 18 Jun 2007 12:55:24 +0200
> I'm all for fixing this gc mess that we have now. But please don't
> expect me to be the one who's doing it.
Don't worry, I only expect you to make the situation worse :-)
-
To unsubscribe from this list: send the l
On 16-06-2007 23:35, Marcin .lusarz wrote:
> hi
> after upgrading kernel from 2.6.20 to 2.6.21.3 i'm experiencing really
> strange problem - my _both_ network cards dies after random uptime -
> sometimes it's a few minutes, sometimes hours, sometimes it does not
> happen for a couple of days...
> t
> > but it's not as if it's really going to affect performance
> > in real cases.
>
> Since these circumstances are creatable by any user, we have
> to consider the cases caused by malicious entities.
OK. But then the whole gc thing is already broken, since a user can
DoS socket creation/destruc
From: Miklos Szeredi <[EMAIL PROTECTED]>
Date: Mon, 18 Jun 2007 12:47:17 +0200
> but it's not as if it's really going to affect performance
> in real cases.
Since these circumstances are creatable by any user, we have
to consider the cases caused by malicious entities.
-
To unsubscribe from this
> * Thomas Graf <[EMAIL PROTECTED]> 2007-06-18 12:32
> > * Miklos Szeredi <[EMAIL PROTECTED]> 2007-06-18 11:44
> > > Garbage collection only ever happens, if the app is sending AF_UNIX
> > > sockets over AF_UNIX sockets. Which is a rather rare case. And which
> > > is basically why this bug went
* Miklos Szeredi <[EMAIL PROTECTED]> 2007-06-18 12:39
> You are wrong. Look in unix_release_sock():
>
> if (atomic_read(&unix_tot_inflight))
> unix_gc(); /* Garbage collect fds */
>
>
> unix_tot_inflight is the number of AF_UNIX sockets currently being
> transfe
* Thomas Graf <[EMAIL PROTECTED]> 2007-06-18 12:32
> * Miklos Szeredi <[EMAIL PROTECTED]> 2007-06-18 11:44
> > Garbage collection only ever happens, if the app is sending AF_UNIX
> > sockets over AF_UNIX sockets. Which is a rather rare case. And which
> > is basically why this bug went unnoticed
> * Miklos Szeredi <[EMAIL PROTECTED]> 2007-06-18 11:44
> > Garbage collection only ever happens, if the app is sending AF_UNIX
> > sockets over AF_UNIX sockets. Which is a rather rare case. And which
> > is basically why this bug went unnoticed for so long.
> >
> > So my second patch only affec
* Miklos Szeredi <[EMAIL PROTECTED]> 2007-06-18 11:44
> Garbage collection only ever happens, if the app is sending AF_UNIX
> sockets over AF_UNIX sockets. Which is a rather rare case. And which
> is basically why this bug went unnoticed for so long.
>
> So my second patch only affects the perfo
From: Miklos Szeredi <[EMAIL PROTECTED]>
Date: Mon, 18 Jun 2007 11:55:19 +0200
> It's doing trylocks and releasing all those locks within the same spin
> locked region, how the f**k can that deadlock?
The case I'm very concerned about is the interactions of your
new code with the unix_state_doubl
> > > Secondarily, this bug has been around for years and nobody noticed.
> > > The world will not explode if this bug takes a few more days or
> > > even a week to work out. Let's do it right instead of ramming
> > > arbitrary turds into the kernel.
> >
> > Fine, but just wishing a bug to get fi
From: Miklos Szeredi <[EMAIL PROTECTED]>
Date: Mon, 18 Jun 2007 11:44:07 +0200
> > Secondarily, this bug has been around for years and nobody noticed.
> > The world will not explode if this bug takes a few more days or
> > even a week to work out. Let's do it right instead of ramming
> > arbitrar
> > > > And is anyone working on a better patch?
> > >
> > > I have no idea.
> > >
> > > > Those patches aren't "bad" in the correctness sense. So IMO any one
> > > > of them is better, than having that bug in there.
> > >
> > > You're adding a very serious performance regression, which is
> >
From: Miklos Szeredi <[EMAIL PROTECTED]>
Date: Mon, 18 Jun 2007 11:29:52 +0200
> > > And is anyone working on a better patch?
> >
> > I have no idea.
> >
> > > Those patches aren't "bad" in the correctness sense. So IMO any one
> > > of them is better, than having that bug in there.
> >
> > Yo
> > And is anyone working on a better patch?
>
> I have no idea.
>
> > Those patches aren't "bad" in the correctness sense. So IMO any one
> > of them is better, than having that bug in there.
>
> You're adding a very serious performance regression, which is
> about as bad as the bug itself.
N
From: Miklos Szeredi <[EMAIL PROTECTED]>
Date: Mon, 18 Jun 2007 10:20:23 +0200
> And is anyone working on a better patch?
I have no idea.
> Those patches aren't "bad" in the correctness sense. So IMO any one
> of them is better, than having that bug in there.
You're adding a very serious perfo
On Mon, 2007-06-18 at 10:08 +0800, Zhu Yi wrote:
> OK. This is the key of the discussion.
I agree.
> Do we take wpa_supplicant the
> only implementation of userspace MLME or even decision making (ie. DLS
> config) daemon?
I think it's a combination of these facts. I don't think DLS decision
ma
> From: Miklos Szeredi <[EMAIL PROTECTED]>
> Date: Mon, 18 Jun 2007 09:49:32 +0200
>
> > Ping Dave,
> >
> > Since there doesn't seem to be any new ideas forthcoming, can we
> > please decide on either one of my two sumbitted patches?
>
> You just need to be patient, we can't just put a bad patch
From: Miklos Szeredi <[EMAIL PROTECTED]>
Date: Mon, 18 Jun 2007 09:49:32 +0200
> Ping Dave,
>
> Since there doesn't seem to be any new ideas forthcoming, can we
> please decide on either one of my two sumbitted patches?
You just need to be patient, we can't just put a bad patch
in because a bett
Ping Dave,
Since there doesn't seem to be any new ideas forthcoming, can we
please decide on either one of my two sumbitted patches?
Thanks,
Miklos
> [CC'd Al Viro and Alan Cox, restored patch]
>
> > > There are races involving the garbage collector, that can throw away
> > > perfectly good pac
88 matches
Mail list logo
