I've changed kernel to rc4 and completely changed hardware.
Now this is
I've got new trace, but this is another problem as i can see and connected
with pppoe
===
[ INFO: possible circular locking dependency detected ]
2.6.21-rc4 #1
This patch fixes two NULL dereferences spotted by the Coverity checker.
For a better understanding, the diff -uwp output (that ignores the
indentation changes) is:
--- linux-2.6.21-rc3-mm2/net/x25/x25_forward.c.old 2007-03-19
02:28:34.0 +0100
+++
IMHO the problem with classifying RxRPC as a reliable datagram
socket is that even an atomic unidirectional communication isn't a
single datagram, it's at least 3; there is shared connection state
Thats fine. Any *reliable* protocol sends more than one packet per
message you send. RDM is
Paul E. McKenney writes:
We have two users of trie_leaf_remove, fn_trie_flush and fn_trie_delete
both are holding RTNL. So there shouldn't be need for this preempt stuff.
This is assumed to a leftover from an older RCU-take.
True enough! One request -- would it be reasonable to
Hi David,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.22
- Arnaldo
---
I did it just in alloc_skb_from_cache, forgot __alloc_skb, fixed now.
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
net/core/skbuff.c |5 -
1 files changed,
Hi,
On kernel based on 2.6.20.3-rc1 (FC6), 'ip -6 r l' shows:
default via fe80::212:f0ff:fe5f:c4ec dev eth1 proto kernel metric 1024
expires 7191sec mtu 1500 advmss 1440 hoplimit 4294967295
(this is the same with iproute2-ss061214 and iproute2-ss070313.)
So, it seems that the data length
Pekka Savola wrote:
On kernel based on 2.6.20.3-rc1 (FC6), 'ip -6 r l' shows:
default via fe80::212:f0ff:fe5f:c4ec dev eth1 proto kernel metric
1024 expires 7191sec mtu 1500 advmss 1440 hoplimit 4294967295
(this is the same with iproute2-ss061214 and iproute2-ss070313.)
So, it seems
Patrick McHardy wrote:
Pekka Savola wrote:
On kernel based on 2.6.20.3-rc1 (FC6), 'ip -6 r l' shows:
default via fe80::212:f0ff:fe5f:c4ec dev eth1 proto kernel metric
1024 expires 7191sec mtu 1500 advmss 1440 hoplimit 4294967295
(this is the same with iproute2-ss061214 and
Martin Schiller wrote:
To be more exactly, it's the examination of
ct-tuplehash[dir].tuple.dst.u.all != ct-tuplehash[!dir].tuple.src.u.all
which is only be done if XFRM is configured. Since I don't need this anyway,
I deactivated XFRM now and my ping -I is working now.
Could you try this
[SCTP]: Reset some transport and association variables on restart
If the association has been restarted, we need to reset the
transport congestion variables as well as accumulated error
counts and CACC variables. If we do not, the association
will use the wrong values and may terminate
[SCTP]: Increment error counters on user requested HBs.
2960bis states (Section 8.3):
D) Request an on-demand HEARTBEAT on a specific destination transport
address of a given association.
The endpoint should increment the respective error counter of the
destination transport
Dave,
Please consider the following 3 SCTP bug fix patches for
inclusion in 2.6.21.
Thanks
Sridhar
[SCTP]: Clean up stale data during association restart
During association restart we may have stale data sitting
on the ULP queue waiting for ordering or reassembly. This
data may cause severe
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 10:50:30 -0300
Hi David,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.22
Pulled, thanks Arnaldo.
Can you please verify the white-space in your patches in the future?
I have a ton
From: Patrick McHardy [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 16:27:29 +0100
Mhh actually this looks intentional:
icmpv6_send and some other output functions do:
int hlimit;
...
if (hlimit 0)
hlimit = dst_metric(dst, RTAX_HOPLIMIT);
if (hlimit 0)
On 3/19/07, David Miller [EMAIL PROTECTED] wrote:
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 10:50:30 -0300
Hi David,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.22
Pulled, thanks Arnaldo.
Can you please verify the
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 17:48:02 -0300
OK, I wasn' t expecting any whitspaces, probably were whitespaces
already there that were kept,
I am pretty sure this is exactly what happened.
I'll try and check future patches.
Thanks!
-
To unsubscribe
Hi Baruch and all,
As you recommended, I used oprofile and it turned out that the
__udp4_lib_lookup function spent most of the time. There is a udp hash
table and the sockets are sought based on the 7 LSBs of the destination
port number. So what happened is now quite obvious: I had many
From: Zacco [EMAIL PROTECTED]
Date: Tue, 20 Mar 2007 00:10:19 +0100
As you recommended, I used oprofile and it turned out that the
__udp4_lib_lookup function spent most of the time. There is a udp hash
table and the sockets are sought based on the 7 LSBs of the destination
port number. So
From: Robert Olsson [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 11:46:41 +0100
Hello.
The patch below adds break condition for the resize operations. If
we don't achieve the desired fill factor a warning is printed. Trie
should still be operational but new thresholds should be considered.
From: Robert Olsson [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 12:21:38 +0100
The threshold for root node can be more aggressive set to get
better tree compression. The new setting mekes the root grow
from 16 to 19 bits and substansial improvemnt in Aver depth
this with the current table of
NETPOLL support for Sibyte MAC
Signed-off-by: Manish Lachwani [EMAIL PROTECTED]
Signed-off-by: Deepak Saxena [EMAIL PROTECTED]
---
Applies cleanly to 2.6.21-rc4
drivers/net/sb1250-mac.c | 23 +++
1 files changed, 23 insertions(+)
Index:
From: Sridhar Samudrala [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 11:38:02 -0700
[SCTP]: Clean up stale data during association restart
During association restart we may have stale data sitting
on the ULP queue waiting for ordering or reassembly. This
data may cause severe problems if not
From: Sridhar Samudrala [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 11:38:10 -0700
[SCTP]: Increment error counters on user requested HBs.
2960bis states (Section 8.3):
D) Request an on-demand HEARTBEAT on a specific destination transport
address of a given association.
The
From: Sridhar Samudrala [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 11:38:05 -0700
[SCTP]: Reset some transport and association variables on restart
If the association has been restarted, we need to reset the
transport congestion variables as well as accumulated error
counts and CACC
On Mon, 19 Mar 2007 15:43:11 -0700, Deepak Saxena [EMAIL PROTECTED] wrote:
NETPOLL support for Sibyte MAC
Signed-off-by: Manish Lachwani [EMAIL PROTECTED]
Signed-off-by: Deepak Saxena [EMAIL PROTECTED]
If you added NETPOLL support, do not forget to ensure hard_start_xmit
routine callable
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.22
Best Regards,
- Arnaldo
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
For the common (struct nlmsghdr *)skb-data sequence, so that we reduce the
number of direct accesses to skb-data and for consistency with all the other
cast skb member helpers.
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
drivers/connector/connector.c |2 +-
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
include/linux/skbuff.h |1 -
net/core/skbuff.c | 14 --
2 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 4803e4d..155f0e6 100644
---
Not used anywhere and defined inside __KERNEL__, Thomas acked this on irc.
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
include/linux/netlink.h | 12
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
include/net/netlink.h|2 +-
net/core/wireless.c |2 +-
net/decnet/dn_route.c|3 ++-
net/decnet/dn_table.c|3 ++-
net/ipv4/inet_diag.c |
So that we reduce the number of direct accesses to skb-data.
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
net/ipv6/netfilter/ip6_tables.c |2 +-
net/ipv6/netfilter/nf_conntrack_reasm.c |5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 22:38:53 -0300
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.22
Pulled, thanks a lot!
-
To unsubscribe from this list: send the line unsubscribe netdev in
the
From: Chris Madden [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 16:10:29 -0400
I did some digging, and it appears the filter add isn't mutexed right.
Inside net/core/dev.c, ing_filter, I see:
spin_lock(dev-ingress_lock);
if ((q = dev-qdisc_ingress) != NULL)
result
This patch adds a space between printing of the src and dst ipv6 addresses.
Otherwise, audit or other test tools may fail to process the audit
record properly because they cannot find the dst address.
Please let me know if this patch is ok. It is minor fix, but I have
tested it and printing
* Patrick McHardy [EMAIL PROTECTED] 2007-03-19 06:54
Thomas, I can't see a clean way to fix this right now that
doesn't either bloat struct nla_policy or removes FRA_SRC/FRA_DST
from the policy, could you please look into this? Thanks.
I guess the only way is to remove FRA_SRC/FRA_DST from the
Alan Cox [EMAIL PROTECTED] wrote:
IMHO the problem with classifying RxRPC as a reliable datagram
socket is that even an atomic unidirectional communication isn't a
single datagram, it's at least 3; there is shared connection state
Thats fine. Any *reliable* protocol sends more than
message transmission. You yourself defined RDM to be a datagram service.
RxRPC is not, in my opinion, a datagram service, and neither is it a stream
service.
Message is what I should have said.
Interestingly, searching for SOCK_RDM definitions with google shows there's
some disagreement as
Alan Cox [EMAIL PROTECTED] wrote:
message transmission. You yourself defined RDM to be a datagram service.
RxRPC is not, in my opinion, a datagram service, and neither is it a stream
service.
Message is what I should have said.
socket(2) also says datagram...
Which is just fine, does
Other RPC types use normal socket types.
They do? Examples please. I didn't think Linux, at least, has any other RPC
socket families, though I could be wrong as I haven't made a thorough study of
them.
SunRPC is implemented in user space and uses the existing TCP/IP layer
and socket
Alan Cox [EMAIL PROTECTED] wrote:
Other RPC types use normal socket types.
They do? Examples please. I didn't think Linux, at least, has any other
RPC socket families, though I could be wrong as I haven't made a thorough
study of them.
SunRPC is implemented in user space and uses
O No, it's not. SOCK_DGRAM is an unreliable, unidirectional datagram passing
service.
Thats funny UDP receives and sends packets.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Sat, Mar 17, 2007 at 10:08:10PM +0900, takada wrote:
I tested some patterns. just X86_OOSTORE was effective. WBINVD is needless.
--- arch/i386/Kconfig.cpu~2007-02-05 03:44:54.0 +0900
+++ arch/i386/Kconfig.cpu 2007-02-17 21:25:52.0 +0900
@@ -322,7 +322,7 @@ config
Rusty Russell [EMAIL PROTECTED] writes:
On Sun, 2007-03-18 at 13:08 +0100, Andi Kleen wrote:
The idea is _NOT_ that you go look for references to the paravirt_ops
members structure, that would be stupid and you wouldn't be able to
use the most efficient addressing mode on a given cpu,
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
True. You can use all of the call clobbered registers.
Quite often, the biggest single win of inlining is not so much the code
size (although if done right, that will be smaller too), but the fact that
inlining DOES NOT CLOBBER AS MANY
* Eric W. Biederman ([EMAIL PROTECTED]) wrote:
Is it truly critical to inline any of these instructions?
I don't have any current measurements. But we'd been aiming
at getting irq_{en,dis}able to a simple memory write to pda.
But simplicity, maintenance, etc. win over trimming a couple
cycles,
On Mon, 19 Mar 2007, Linus Torvalds wrote:
So *please* don't believe that you can make it as cheap to have some
automatic fixup of two sequences, one inlined and one as a call. It may
look so when you look at the single instruction generated, but you're
ignoring all the instructions
Eric W. Biederman wrote:
Rusty Russell [EMAIL PROTECTED] writes:
On Sun, 2007-03-18 at 13:08 +0100, Andi Kleen wrote:
The idea is _NOT_ that you go look for references to the paravirt_ops
members structure, that would be stupid and you wouldn't be able to
use the most efficient
From: David Howells [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 15:41:38 +
Alan Cox [EMAIL PROTECTED] wrote:
So use SOCK_DGRAM, its clearly near enough.
No, it's not. SOCK_DGRAM is an unreliable, unidirectional datagram passing
service.
David we're not looking for a precise match, so
Linus Torvalds wrote:
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
True. You can use all of the call clobbered registers.
Quite often, the biggest single win of inlining is not so much the code
size (although if done right, that will be smaller too), but the fact that
inlining
From: Jeremy Fitzhardinge [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 12:10:08 -0700
All this is doable; I'd probably end up hacking boot/compressed/relocs.c
to generate the appropriate reloc table. My main concern is hacking the
kernel build process itself; I'm unsure of what it would actually
David Miller wrote:
Another point worth making is that for function calls you
can fix things up lazily if you want.
[...]
In fact forget I mentioned this idea :)
OK :) I think we'll only ever want to bind to a hypervisor once, since
the underlying hypervisor can't change on the fly
-stable review patch. If anyone has any objections, please let us know.
--
From: Samuel Ortiz [EMAIL PROTECTED]
Without this initialization one gets
kernel BUG at kernel/rtmutex_common.h:80!
This patch should also be included in the -stable kernel.
Signed-off-by: G.
I got it the first time, it's just very low priority and very
deep in my backlog and I'm also about to be away for 3 days.
I have it so you don't need to keep resending it.
Thanks.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
Possibly not, but I'd like to be able to say with confidence that
running a PARAVIRT kernel on bare hardware has no performance loss
compared to running a !PARAVIRT kernel. There's the case of small
instruction sequences which have been replaced with calls (such as
sti/cli/push;popf/etc),
On Mon, 2007-03-19 at 11:38 -0700, Linus Torvalds wrote:
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
True. You can use all of the call clobbered registers.
Quite often, the biggest single win of inlining is not so much the code
size (although if done right, that will be smaller
From: Adrian Bunk [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 10:24:03 +0100
This patch fixes two NULL dereferences spotted by the Coverity checker.
For a better understanding, the diff -uwp output (that ignores the
indentation changes) is:
I'll apply this, thanks Adrian.
-
To unsubscribe
Jeremy Fitzhardinge wrote:
For example, say we wanted to put a general call for sti into entry.S,
where its expected it won't touch any registers. In that case, we'd
have a sequence like:
push %eax
push %ecx
push %edx
call paravirt_cli
pop %edx
pop %ecx
pop %eax
Zachary Amsden wrote:
Jeremy Fitzhardinge wrote:
If we then work out in each direction and see matched push/pops,
then we know what registers can be trashed in the call. This also
allows us to determine the callsite size, and therefore how much space
we need for inlining.
No, that is
Rusty Russell wrote:
On Mon, 2007-03-19 at 11:38 -0700, Linus Torvalds wrote:
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
True. You can use all of the call clobbered registers.
Quite often, the biggest single win of inlining is not so much the code
size (although if done
From: Adrian Bunk [EMAIL PROTECTED]
Date: Sun, 18 Mar 2007 19:49:38 +0100
Subject: ipv6 crash
References : http://lkml.org/lkml/2007/3/10/2
Submitter : Len Brown [EMAIL PROTECTED]
Status : unknown
This is caused by some problem in the router round-robin code in
From: Joy Latten [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 18:14:59 -0600
This patch adds a space between printing of the src and dst ipv6 addresses.
Otherwise, audit or other test tools may fail to process the audit
record properly because they cannot find the dst address.
Please let me
On Mon, 2007-19-03 at 19:22 -0700, David Miller wrote:
I think this should use dev-queue_lock.
It would slow down things if he is doing both ingress and egress
traffic as well as control changes.
It looks like the idea might have been to allow more parallelized
running of ingress
jamal wrote:
On Mon, 2007-19-03 at 19:22 -0700, David Miller wrote:
It looks like the idea might have been to allow more parallelized
running of ingress filters, but this is done wrong and leads to
the crashes you are seeing.
The main idea is to avoid one BigLock for both ingress and
Thomas Graf wrote:
* Patrick McHardy [EMAIL PROTECTED] 2007-03-19 06:54
Thomas, I can't see a clean way to fix this right now that
doesn't either bloat struct nla_policy or removes FRA_SRC/FRA_DST
from the policy, could you please look into this? Thanks.
I guess the only way is to remove
Patrick McHardy wrote:
[NET]: Fix fib_rules compatibility breakage
I forgot to remove FRA_SRC/FRA_DST from fib6_rule_policy.
Updated patch attached.
[NET]: Fix fib_rules compatibility breakage
The fib_rules netlink attribute policy introduced in 2.6.19 broke
userspace compatibilty. When
On Mon, 2007-03-19 at 18:00 -0800, Zachary Amsden wrote:
Rusty Russell wrote:
*This* was the reason that the current hand-coded calls only clobber %
eax. It was a compromise between native (no clobbers) and others (might
need a reg).
I still don't think this was a good trade.
...
Xen
Zachary Amsden wrote:
For VMI, the default clobber was cc, and you need a way to allow at
least that, because saving and restoring flags is too expensive on x86.
According to lore (Andi, I think), asm() always clobbers cc.
I still don't think this was a good trade. The primary motivation
On Monday 19 March 2007 00:46, Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
Yes. All inline assembly tells gcc what registers are clobbered
and it fills in the tables. Hand clobbering in inline assembly cannot
be expressed with the current toolchain, so we moved all those
out of line.
Andi Kleen wrote:
push %eax
push %ecx
push %edx
call paravirt_cli
pop %edx
pop %ecx
pop %eax
This cannot right now be expressed as inline assembly in the unwinder at all
because there is no way to inject the push/pops into the compiler generated
From: Andi Kleen [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 11:57:28 +0100
On Monday 19 March 2007 00:46, Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
For example, say we wanted to put a general call for sti into entry.S,
where its expected it won't touch any registers. In that case, we'd
It's inability to handle sequences like the above sounds to me like
a very good argument to _not_ merge the unwinder back into the tree.
The unwinder can handle it fine, it is just that gcc right now cannot
be taught to generate correct unwind tables for it. If paravirt ops
is widely used i
On Mon, 19 Mar 2007, Andi Kleen wrote:
Initially we had some bugs that accounted for near all failures, but they
were all fixed in the latest version.
No. The real bugs were that the people involved wouldn't even accept that
unwinding information was inevitably buggy and/or incomplete.
From: Linus Torvalds [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 20:18:14 -0700 (PDT)
Please don't subject us to another couple months of hair-pulling only
to have Linus yank the thing out again, there are certainly more
useful things to spend time on :-)
Good call. Dwarf2 unwinding
David Miller [EMAIL PROTECTED] writes:
From: Linus Torvalds [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 20:18:14 -0700 (PDT)
Please don't subject us to another couple months of hair-pulling only
to have Linus yank the thing out again, there are certainly more
useful things to spend time
Hello!
Well I don't think the loopback device is currently but as soon
as we get network namespace support we will have multiple loopback
devices and they will get unregistered when we remove the network
namespace.
There is no logical difference. At the moment when namespace is gone
there is
Hello!
Does this look sane (untested)?
It does not, unfortunately.
Instead of regular crash in infiniband you will get numerous
random NULL pointer dereferences both due to dst-neighbour
and due to dst-dev.
Alexey
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
Does this look sane (untested)?
It does not, unfortunately.
Instead of regular crash in infiniband you will get numerous
random NULL pointer dereferences both due to dst-neighbour
Hello!
I think the thing to do is to just leave the loopback references
in place, try to unregister the per-namespace loopback device,
and that will safely wait for all the references to go away.
Yes, it is exactly how it works in openvz. All the sockets are killed,
queues are cleared, nobody
Any simpler ideas?
Well, if inifiniband destructor really needs to take that lock... no.
Right now I do not see.
OK, this is actually not hard to fix - for infiniband, we can just look at
neighbour-dev-type or compare neighbour-dev and
neighbour-parms-dev - if they are different, device is
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Any simpler ideas?
Well, if inifiniband destructor really needs to take that lock... no.
Right now I do not see.
OK, this is actually not hard to fix - for infiniband, we can just look at
Hello!
If a device driver sets neigh_destructor in neigh_params, this could
get called after the device has been unregistered and the driver module
removed.
It is the same problem: if dst-neighbour holds neighbour, it should
not hold device. parms-dev is not supposed to be used after
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Hello!
If a device driver sets neigh_destructor in neigh_params, this could
get called after the device has been unregistered and the driver module
removed.
It is the same problem: if
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Hello!
If a device driver sets neigh_destructor in neigh_params, this could
get called after the device has been unregistered and the driver module
removed.
It is the same problem: if
Hello!
infiniband sets parm-neigh_destructor, and I search for a way to prevent
this destructor from being called after the module has been unloaded.
Ideas?
It must be called in any case to update/release internal ipoib structures.
The idea is to move call of parm-neigh_destructor from
David Miller [EMAIL PROTECTED] writes:
I think the thing to do is to just leave the loopback references
in place, try to unregister the per-namespace loopback device,
and that will safely wait for all the references to go away.
Right. The only thing I have found that needs to be changed so
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Hello!
infiniband sets parm-neigh_destructor, and I search for a way to prevent
this destructor from being called after the module has been unloaded.
Ideas?
It must be called in any case to
Hello!
This might work. Could you post a patch to better show what you mean to do?
Here it is.
-neigh_destructor() is killed (not used), replaced with -neigh_cleanup(),
which is called when neighbor entry goes to dead state. At this point
everything is still valid: neigh-dev, neigh-parms etc.
87 matches
Mail list logo
