On Sun, Feb 06, 2005 at 09:30:18PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>
> How about this; Ignore entries addrconf_dst_alloc'ed entries in rt6_ifdown()?
Great, that definitely fixes the local address problem.
I'm not sure about anycast routes though. Who's going to delete them
when
In article <[EMAIL PROTECTED]> (at Sun, 6 Feb 2005 22:41:45 +1100), Herbert Xu
<[EMAIL PROTECTED]> says:
> On Sat, Feb 05, 2005 at 09:45:59PM +1100, herbert wrote:
> >
> > Although I still think this is a bug, I'm now starting to suspect
> > that there is another bug around as well.
> >
> >
On Sat, Feb 05, 2005 at 09:45:59PM +1100, herbert wrote:
>
> Although I still think this is a bug, I'm now starting to suspect
> that there is another bug around as well.
>
> There is probably an ifp leak which in turn leads to a split dst
> leak that allows the first bug to make its mark.
In article <[EMAIL PROTECTED]> (at Sun, 06 Feb 2005 11:55:19 +0100), Andre Tomt
<[EMAIL PROTECTED]> says:
> I'm contemplating just using it as a quick-fix until 2.6.11 to get this
> problem under control.
Would you find if my patch works? Thanks.
--yoshfuji
-
To unsubscribe from this list:
Herbert Xu wrote:
On Fri, Feb 04, 2005 at 09:38:13PM -0800, David S. Miller wrote:
It is just the first such thing I found, scanning rt6i_idev uses
will easily find several others.
You're right of course. I thought they were all harmless but I was
obviously wrong about this one.
So here is a
Herbert Xu wrote:
On Fri, Feb 04, 2005 at 09:38:13PM -0800, David S. Miller wrote:
It is just the first such thing I found, scanning rt6i_idev uses
will easily find several others.
You're right of course. I thought they were all harmless but I was
obviously wrong about this one.
So here is a
In article [EMAIL PROTECTED] (at Sun, 06 Feb 2005 11:55:19 +0100), Andre Tomt
[EMAIL PROTECTED] says:
I'm contemplating just using it as a quick-fix until 2.6.11 to get this
problem under control.
Would you find if my patch works? Thanks.
--yoshfuji
-
To unsubscribe from this list: send the
On Sat, Feb 05, 2005 at 09:45:59PM +1100, herbert wrote:
Although I still think this is a bug, I'm now starting to suspect
that there is another bug around as well.
There is probably an ifp leak which in turn leads to a split dst
leak that allows the first bug to make its mark.
Found it.
In article [EMAIL PROTECTED] (at Sun, 6 Feb 2005 22:41:45 +1100), Herbert Xu
[EMAIL PROTECTED] says:
On Sat, Feb 05, 2005 at 09:45:59PM +1100, herbert wrote:
Although I still think this is a bug, I'm now starting to suspect
that there is another bug around as well.
There is probably
On Sun, Feb 06, 2005 at 09:30:18PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
How about this; Ignore entries addrconf_dst_alloc'ed entries in rt6_ifdown()?
Great, that definitely fixes the local address problem.
I'm not sure about anycast routes though. Who's going to delete them
when the
On Sun, Feb 06, 2005 at 02:50:07PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>
> Which means in addrconf_notiry(), if the dev == _dev,
> call addrconf_ifdown for every device like this:
This should fix the reported issue. However, I'm not sure if it's
a good idea to stop all IP traffic when
On Sun, Feb 06, 2005 at 02:31:07PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>
> Here, lo is going down.
> rt->rt6i_dev = lo and rt->rt6i_idev = ethX.
> I think we already see dst->dev == dev (==lo) now.
> So, I doubt that fix the problem.
>
> The source of problem is entry (*) which still
On Sat, Feb 05, 2005 at 08:10:44PM -0800, David S. Miller wrote:
>
> > Alternatively we can
> > remove the dst->dev == dev check in dst_dev_event and dst_ifdown
> > and move that test down to the individual ifdown functions.
>
> I think there is a hole in this idea maybe.
>
> If the idea is
On Sat, Feb 05, 2005 at 09:04:11PM -0800, David S. Miller wrote:
>
> Oh I see. That would work, and it seems the simplest, and
> lowest risk fix for this problem.
>
> Herbert, what do you think?
Yes I agree.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
In article <[EMAIL PROTECTED]> (at Sun, 06 Feb 2005 14:31:07 +0900 (JST)),
YOSHIFUJI Hideaki / [EMAIL PROTECTED](B <[EMAIL PROTECTED]> says:
> The source of problem is entry (*) which still on routing entry,
> not on gc list. And, the owner of entry is not routing table but
>
In article <[EMAIL PROTECTED]> (at Sat, 5 Feb 2005 21:04:11 -0800), "David S.
Miller" <[EMAIL PROTECTED]> says:
> On Sun, 06 Feb 2005 13:37:23 +0900 (JST)
> YOSHIFUJI Hideaki / [EMAIL PROTECTED](B <[EMAIL PROTECTED]> wrote:
>
> > How about making dst->ops->dev_check() like this:
> >
> > static
On Sun, 06 Feb 2005 13:37:23 +0900 (JST)
YOSHIFUJI Hideaki / [EMAIL PROTECTED](B <[EMAIL PROTECTED]> wrote:
> How about making dst->ops->dev_check() like this:
>
> static int inline dst_dev_check(struct dst_entry *dst, struct net_device *dev)
> {
> if (dst->ops->dev_check)
>
In article <[EMAIL PROTECTED]> (at Sat, 5 Feb 2005 20:02:42 -0800), "David S.
Miller" <[EMAIL PROTECTED]> says:
> > Yes, IPv6 needs "split device" semantics
> > (for per-device statistics such as Ip6InDelivers etc),
> > and I like later solution.
>
> Ok. I never read whether ipv6, like ipv4,
In article <[EMAIL PROTECTED]> (at Sat, 5 Feb 2005 20:10:44 -0800), "David S.
Miller" <[EMAIL PROTECTED]> says:
> > Alternatively we can
> > remove the dst->dev == dev check in dst_dev_event and dst_ifdown
> > and move that test down to the individual ifdown functions.
>
> I think there is a
On Sat, 5 Feb 2005 17:46:43 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> This doesn't work because net/core/dst.c can only search based
> on dst->dev. For the split device case, dst->dev is set to
> loopback_dev while rt6i_idev is set to the real device.
Indeed. I didn't catch that.
> If we
On Sat, 05 Feb 2005 19:50:39 +0900 (JST)
YOSHIFUJI Hideaki / [EMAIL PROTECTED](B <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]> (at Sat, 5 Feb 2005 17:46:43 +1100), Herbert
> Xu <[EMAIL PROTECTED]> says:
>
> > If we wanted to preserve the split device semantics, then we
> > can
On Sat, Feb 05, 2005 at 08:39:00PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>
> I think "Make loopback idev stick around" patches
> (for IPv4 and IPv6) could be start of that.
Unfortunately that patch can't fix this particular problem. This
problem will show up whenever there is a dst on
On Sat, Feb 05, 2005 at 07:50:39PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>
> Yes, IPv6 needs "split device" semantics
> (for per-device statistics such as Ip6InDelivers etc),
> and I like later solution.
OK. Is there any reason why IPv4 should be different from IPv6 in
this respect
Matthias-Christian Ott wrote:
Mirko Parthey wrote:
On Mon, Jan 31, 2005 at 05:22:02PM +0100, wrote:
My Debian machine hangs during shutdown, with messages like this:
unregister_netdevice: waiting for br0 to become free. Usage count = 1
I narrowed it down to the command
# brctl delbr br0
which
In article <[EMAIL PROTECTED]> (at Sat, 05 Feb 2005 12:48:15 +0100), Andre Tomt
<[EMAIL PROTECTED]> says:
> > Please tell me, why your lo is down...
:
> "ifdown -a" gets run on shutdown and reboot here, and ifdown -a in
> Debian brings down loopback before any other interfaces.
Okay, thanks.
In article <[EMAIL PROTECTED]> (at Sat, 05 Feb 2005 12:14:04 +0100), Andre Tomt
<[EMAIL PROTECTED]> says:
> This patch fixes my problems with hangs when dot1q VLAN interfaces gets
> removed when loopback is down, as reported in the thread "2.6.10
> ipv6/8021q lockup on vconfig on interface
Herbert Xu wrote:
On Fri, Feb 04, 2005 at 09:38:13PM -0800, David S. Miller wrote:
It is just the first such thing I found, scanning rt6i_idev uses
will easily find several others.
You're right of course. I thought they were all harmless but I was
obviously wrong about this one.
So here is a
On Sat, Feb 05, 2005 at 05:46:43PM +1100, herbert wrote:
>
> This doesn't work because net/core/dst.c can only search based
> on dst->dev. For the split device case, dst->dev is set to
> loopback_dev while rt6i_idev is set to the real device.
Although I still think this is a bug, I'm now
In article <[EMAIL PROTECTED]> (at Sat, 5 Feb 2005 17:46:43 +1100), Herbert Xu
<[EMAIL PROTECTED]> says:
> If we wanted to preserve the split device semantics, then we
> can create a local GC list in IPv6 so that it can search based
> on rt6i_idev as well as the other keys. Alternatively we can
Matthias-Christian Ott wrote:
Mirko Parthey wrote:
On Mon, Jan 31, 2005 at 05:22:02PM +0100, wrote:
My Debian machine hangs during shutdown, with messages like this:
unregister_netdevice: waiting for br0 to become free. Usage count = 1
I narrowed it down to the command
# brctl delbr br0
which
On Sat, Feb 05, 2005 at 07:50:39PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
Yes, IPv6 needs split device semantics
(for per-device statistics such as Ip6InDelivers etc),
and I like later solution.
OK. Is there any reason why IPv4 should be different from IPv6 in
this respect though?
On Sat, Feb 05, 2005 at 08:39:00PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
I think Make loopback idev stick around patches
(for IPv4 and IPv6) could be start of that.
Unfortunately that patch can't fix this particular problem. This
problem will show up whenever there is a dst on the GC
On Sat, 05 Feb 2005 19:50:39 +0900 (JST)
YOSHIFUJI Hideaki / [EMAIL PROTECTED](B [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED] (at Sat, 5 Feb 2005 17:46:43 +1100), Herbert
Xu [EMAIL PROTECTED] says:
If we wanted to preserve the split device semantics, then we
can create a local
On Sat, 5 Feb 2005 17:46:43 +1100
Herbert Xu [EMAIL PROTECTED] wrote:
This doesn't work because net/core/dst.c can only search based
on dst-dev. For the split device case, dst-dev is set to
loopback_dev while rt6i_idev is set to the real device.
Indeed. I didn't catch that.
If we wanted
In article [EMAIL PROTECTED] (at Sat, 5 Feb 2005 20:10:44 -0800), David S.
Miller [EMAIL PROTECTED] says:
Alternatively we can
remove the dst-dev == dev check in dst_dev_event and dst_ifdown
and move that test down to the individual ifdown functions.
I think there is a hole in this
In article [EMAIL PROTECTED] (at Sat, 5 Feb 2005 20:02:42 -0800), David S.
Miller [EMAIL PROTECTED] says:
Yes, IPv6 needs split device semantics
(for per-device statistics such as Ip6InDelivers etc),
and I like later solution.
Ok. I never read whether ipv6, like ipv4, is specified to
On Sun, 06 Feb 2005 13:37:23 +0900 (JST)
YOSHIFUJI Hideaki / [EMAIL PROTECTED](B [EMAIL PROTECTED] wrote:
How about making dst-ops-dev_check() like this:
static int inline dst_dev_check(struct dst_entry *dst, struct net_device *dev)
{
if (dst-ops-dev_check)
return
In article [EMAIL PROTECTED] (at Sat, 5 Feb 2005 21:04:11 -0800), David S.
Miller [EMAIL PROTECTED] says:
On Sun, 06 Feb 2005 13:37:23 +0900 (JST)
YOSHIFUJI Hideaki / [EMAIL PROTECTED](B [EMAIL PROTECTED] wrote:
How about making dst-ops-dev_check() like this:
static int inline
In article [EMAIL PROTECTED] (at Sun, 06 Feb 2005 14:31:07 +0900 (JST)),
YOSHIFUJI Hideaki / [EMAIL PROTECTED](B [EMAIL PROTECTED] says:
The source of problem is entry (*) which still on routing entry,
not on gc list. And, the owner of entry is not routing table but
On Sat, Feb 05, 2005 at 08:10:44PM -0800, David S. Miller wrote:
Alternatively we can
remove the dst-dev == dev check in dst_dev_event and dst_ifdown
and move that test down to the individual ifdown functions.
I think there is a hole in this idea maybe.
If the idea is to scan
On Sat, Feb 05, 2005 at 09:04:11PM -0800, David S. Miller wrote:
Oh I see. That would work, and it seems the simplest, and
lowest risk fix for this problem.
Herbert, what do you think?
Yes I agree.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL
On Sun, Feb 06, 2005 at 02:31:07PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
Here, lo is going down.
rt-rt6i_dev = lo and rt-rt6i_idev = ethX.
I think we already see dst-dev == dev (==lo) now.
So, I doubt that fix the problem.
The source of problem is entry (*) which still on routing
On Sun, Feb 06, 2005 at 02:50:07PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
Which means in addrconf_notiry(), if the dev == loopback_dev,
call addrconf_ifdown for every device like this:
This should fix the reported issue. However, I'm not sure if it's
a good idea to stop all IP traffic
In article [EMAIL PROTECTED] (at Sat, 5 Feb 2005 17:46:43 +1100), Herbert Xu
[EMAIL PROTECTED] says:
If we wanted to preserve the split device semantics, then we
can create a local GC list in IPv6 so that it can search based
on rt6i_idev as well as the other keys. Alternatively we can
On Sat, Feb 05, 2005 at 05:46:43PM +1100, herbert wrote:
This doesn't work because net/core/dst.c can only search based
on dst-dev. For the split device case, dst-dev is set to
loopback_dev while rt6i_idev is set to the real device.
Although I still think this is a bug, I'm now starting to
Herbert Xu wrote:
On Fri, Feb 04, 2005 at 09:38:13PM -0800, David S. Miller wrote:
It is just the first such thing I found, scanning rt6i_idev uses
will easily find several others.
You're right of course. I thought they were all harmless but I was
obviously wrong about this one.
So here is a
In article [EMAIL PROTECTED] (at Sat, 05 Feb 2005 12:14:04 +0100), Andre Tomt
[EMAIL PROTECTED] says:
This patch fixes my problems with hangs when dot1q VLAN interfaces gets
removed when loopback is down, as reported in the thread 2.6.10
ipv6/8021q lockup on vconfig on interface removal.
In article [EMAIL PROTECTED] (at Sat, 05 Feb 2005 12:48:15 +0100), Andre Tomt
[EMAIL PROTECTED] says:
Please tell me, why your lo is down...
:
ifdown -a gets run on shutdown and reboot here, and ifdown -a in
Debian brings down loopback before any other interfaces.
Okay, thanks. (I now
On Fri, Feb 04, 2005 at 10:13:44PM -0800, David S. Miller wrote:
>
> But Herbert, let's take a step back real quick because I want
> to point something out. IPv6 does try to handle the dangling
> mismatched idev's, in route.c:ip6_dst_ifdown(), this is called
> via net/core/dst.c:dst_ifdown(),
On Sat, 5 Feb 2005 17:11:10 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> You're right of course. I thought they were all harmless but I was
> obviously wrong about this one.
>
> So here is a patch that essentially reverts the split devices
> semantics introduced by these two changesets:
>
>
On Fri, Feb 04, 2005 at 09:38:13PM -0800, David S. Miller wrote:
>
> It is just the first such thing I found, scanning rt6i_idev uses
> will easily find several others.
You're right of course. I thought they were all harmless but I was
obviously wrong about this one.
So here is a patch that
On Sat, 5 Feb 2005 16:24:07 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> This is the key to the problem.
...
> All of these bugs stem from the idev reference held in rtable/rt6_info.
...
> Anyway, this particular problem is due to IPv6 adding local addresses
> with split devices. That is,
On Mon, Jan 31, 2005 at 04:22:02PM +, Mirko Parthey wrote:
>
> How to reproduce the problem (I tried this on a Pentium 4 machine):
>
> boot: linux init=/bin/bash
> [...booting...]
> # mount proc -t proc /proc
> # ifconfig lo 127.0.0.1
> # brctl addbr br0
> # modprobe e100 # also
On Mon, Jan 31, 2005 at 04:22:02PM +, Mirko Parthey wrote:
How to reproduce the problem (I tried this on a Pentium 4 machine):
boot: linux init=/bin/bash
[...booting...]
# mount proc -t proc /proc
# ifconfig lo 127.0.0.1
# brctl addbr br0
# modprobe e100 # also
On Sat, 5 Feb 2005 16:24:07 +1100
Herbert Xu [EMAIL PROTECTED] wrote:
This is the key to the problem.
...
All of these bugs stem from the idev reference held in rtable/rt6_info.
...
Anyway, this particular problem is due to IPv6 adding local addresses
with split devices. That is, routes to
On Fri, Feb 04, 2005 at 09:38:13PM -0800, David S. Miller wrote:
It is just the first such thing I found, scanning rt6i_idev uses
will easily find several others.
You're right of course. I thought they were all harmless but I was
obviously wrong about this one.
So here is a patch that
On Sat, 5 Feb 2005 17:11:10 +1100
Herbert Xu [EMAIL PROTECTED] wrote:
You're right of course. I thought they were all harmless but I was
obviously wrong about this one.
So here is a patch that essentially reverts the split devices
semantics introduced by these two changesets:
[IPV6]
On Fri, Feb 04, 2005 at 10:13:44PM -0800, David S. Miller wrote:
But Herbert, let's take a step back real quick because I want
to point something out. IPv6 does try to handle the dangling
mismatched idev's, in route.c:ip6_dst_ifdown(), this is called
via net/core/dst.c:dst_ifdown(), and
Mirko Parthey wrote:
On Mon, Jan 31, 2005 at 05:22:02PM +0100, wrote:
My Debian machine hangs during shutdown, with messages like this:
unregister_netdevice: waiting for br0 to become free. Usage count = 1
I narrowed it down to the command
# brctl delbr br0
which does not return in the
Mirko Parthey wrote:
On Mon, Jan 31, 2005 at 05:22:02PM +0100, wrote:
My Debian machine hangs during shutdown, with messages like this:
unregister_netdevice: waiting for br0 to become free. Usage count = 1
I narrowed it down to the command
# brctl delbr br0
which does not return in the
On Mon, Jan 31, 2005 at 05:22:02PM +0100, wrote:
> My Debian machine hangs during shutdown, with messages like this:
> unregister_netdevice: waiting for br0 to become free. Usage count = 1
>
> I narrowed it down to the command
> # brctl delbr br0
> which does not return in the circumstances
On Mon, Jan 31, 2005 at 05:22:02PM +0100, wrote:
My Debian machine hangs during shutdown, with messages like this:
unregister_netdevice: waiting for br0 to become free. Usage count = 1
I narrowed it down to the command
# brctl delbr br0
which does not return in the circumstances shown
Mirko Parthey wrote:
My Debian machine hangs during shutdown, with messages like this:
unregister_netdevice: waiting for br0 to become free. Usage count = 1
I narrowed it down to the command
# brctl delbr br0
which does not return in the circumstances shown below.
The problem is reproducible with
My Debian machine hangs during shutdown, with messages like this:
unregister_netdevice: waiting for br0 to become free. Usage count = 1
I narrowed it down to the command
# brctl delbr br0
which does not return in the circumstances shown below.
The problem is reproducible with both 2.6.11-rc2
64 matches
Mail list logo
