netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* An ioctl to delete an ipv6 tunnel leads to a kernel panic
@ 2008-02-11 20:49 Natalie Protasevich
  2008-02-13  5:49 ` David Miller
  0 siblings, 1 reply; 3+ messages in thread
From: Natalie Protasevich @ 2008-02-11 20:49 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: Andrew Morton

Hello,

This bug was reported to bugzilla.kernel.org:

http://bugzilla.kernel.org/show_bug.cgi?id=8895

Hardware Environment:  user mode linux and vmware
Software Environment:   an evolution of mip6d (ip mobility daemon)
Problem Description:     The mip6d HA was modified to make a
redondancy evolution, when an HA is interrupted, the other takes over,
this leads to some
creation/deletion of routes and tunnels.
Note: The HA ip address known by the mobile (MR) stays the same, the
slave HA takes it with an override neighbor advertisement message. So
the tunnel between
the mobile router and the HA(s) keep the same end adresses.
The problem occurs when a Ctrl C is done on the master HA, the slave
takes over but sometimes, the master gets a kernel panic.


Possible reason for this failure was identified and tested by the
submitter and several other reporters that ran into the same problem.
Can the patch be reviewed and pushed upstream if accepted (if the
problem hasn't been addressed already)?

Thanks,
--Natalie

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: An ioctl to delete an ipv6 tunnel leads to a kernel panic
  2008-02-11 20:49 An ioctl to delete an ipv6 tunnel leads to a kernel panic Natalie Protasevich
@ 2008-02-13  5:49 ` David Miller
  2008-02-13  6:00   ` Natalie Protasevich
  0 siblings, 1 reply; 3+ messages in thread
From: David Miller @ 2008-02-13  5:49 UTC (permalink / raw)
  To: protasnb; +Cc: netdev, akpm

From: "Natalie Protasevich" <protasnb@gmail.com>
Date: Mon, 11 Feb 2008 12:49:12 -0800

> Possible reason for this failure was identified and tested by the
> submitter and several other reporters that ran into the same problem.
> Can the patch be reviewed and pushed upstream if accepted (if the
> problem hasn't been addressed already)?

There are a lot of bogus patches in there, using funny
long variable names, and mainly they were meant for testing
and verification of the problem.

I see no real serious patch submissions in that bug and furthermore
the patch, if ready, should be submitted formally here to netdev not
rot in bugzilla.

Finally, what appears to be the proposal cannot be correct.  If the
fib6_add_rt2node() finds that the new route is a duplicate, we should
disconnect it from the fn->leaf and do a dst_release().  The bug
appears to be rather that we leave the route attached to the fn, not
that we drop the refrence to it.

Thank you.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: An ioctl to delete an ipv6 tunnel leads to a kernel panic
  2008-02-13  5:49 ` David Miller
@ 2008-02-13  6:00   ` Natalie Protasevich
  0 siblings, 0 replies; 3+ messages in thread
From: Natalie Protasevich @ 2008-02-13  6:00 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, akpm

On Feb 12, 2008 9:49 PM, David Miller <davem@davemloft.net> wrote:
> From: "Natalie Protasevich" <protasnb@gmail.com>
> Date: Mon, 11 Feb 2008 12:49:12 -0800
>
> > Possible reason for this failure was identified and tested by the
> > submitter and several other reporters that ran into the same problem.
> > Can the patch be reviewed and pushed upstream if accepted (if the
> > problem hasn't been addressed already)?
>
> There are a lot of bogus patches in there, using funny
> long variable names, and mainly they were meant for testing
> and verification of the problem.
>
> I see no real serious patch submissions in that bug and furthermore
> the patch, if ready, should be submitted formally here to netdev not
> rot in bugzilla.
>
> Finally, what appears to be the proposal cannot be correct.  If the
> fib6_add_rt2node() finds that the new route is a duplicate, we should
> disconnect it from the fn->leaf and do a dst_release().  The bug
> appears to be rather that we leave the route attached to the fn, not
> that we drop the refrence to it.
>
> Thank you.

Thanks David for looking in this. I will give this thought to the
diligent reporters, unless someone on the net team can produce a patch
for them to test.
Sometimes reporters come up with patches and I always try to make sure
the patches end up on appropriate mailing list, and I will continue
doing so :)

Regards,
--Natalie
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-02-13  6:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-11 20:49 An ioctl to delete an ipv6 tunnel leads to a kernel panic Natalie Protasevich
2008-02-13  5:49 ` David Miller
2008-02-13  6:00   ` Natalie Protasevich

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).