* Re[3]: kernel oops - do_ip_vs_get_ctl
@ 2012-04-21 10:11 Hans Schillstrom
2012-04-23 13:32 ` Simon Horman
0 siblings, 1 reply; 4+ messages in thread
From: Hans Schillstrom @ 2012-04-21 10:11 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Ryan O'Hara, lvs-devel
Hello
>Subject: Re[2]: kernel oops - do_ip_vs_get_ctl
>
>Hello,
>
>On Fri, 20 Apr 2012, Hans Schillstrom wrote:
>
>> >On Fri, 20 Apr 2012, Ryan O'Hara wrote:
>> >
>> >>
>> >> I frequently get a kernel oops in do_ip_vs_get_ctl when starting keepalived on
>> >> a 3.3.0 kernel. I'm attaching the trace from /var/log/messages. Has anyone
>> >> encountered this problem and if so is there a patch available? Much
>> >> appreciated.
>> >
[snip]
>> Do you prepare a patch or should I do it ?
>
> I'm stopping doing more patches until Simon takes
>the previous changes, so that we can use some fresh tree.
>You can try fixing this problem if you think you have
>recent changes.
>
OK I'll take care of this and double check with Simon that we have the same view of patches
Regards
Hans Schillstrom <hans@schillstrom.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: kernel oops - do_ip_vs_get_ctl
2012-04-21 10:11 Re[3]: kernel oops - do_ip_vs_get_ctl Hans Schillstrom
@ 2012-04-23 13:32 ` Simon Horman
2012-04-23 19:55 ` Julian Anastasov
0 siblings, 1 reply; 4+ messages in thread
From: Simon Horman @ 2012-04-23 13:32 UTC (permalink / raw)
To: Hans Schillstrom
Cc: Julian Anastasov, Ryan O'Hara, lvs-devel, Sasha Levin
On Sat, Apr 21, 2012 at 12:11:49PM +0200, Hans Schillstrom wrote:
> Hello
> >Subject: Re[2]: kernel oops - do_ip_vs_get_ctl
> >
> >Hello,
> >
> >On Fri, 20 Apr 2012, Hans Schillstrom wrote:
> >
> >> >On Fri, 20 Apr 2012, Ryan O'Hara wrote:
> >> >
> >> >>
> >> >> I frequently get a kernel oops in do_ip_vs_get_ctl when starting keepalived on
> >> >> a 3.3.0 kernel. I'm attaching the trace from /var/log/messages. Has anyone
> >> >> encountered this problem and if so is there a patch available? Much
> >> >> appreciated.
> >> >
> [snip]
>
> >> Do you prepare a patch or should I do it ?
> >
> > I'm stopping doing more patches until Simon takes
> >the previous changes, so that we can use some fresh tree.
> >You can try fixing this problem if you think you have
> >recent changes.
> >
> OK I'll take care of this and double check with Simon that we have the
> same view of patches
Hi,
sorry for not being a little more attentive to patches.
I have now picked up all the patches that seem to have consensus.
Those that seem critical I have pushed into ipvs with a CC: stable@
and sent a pull request to Pablo to consider them for 3.4.
There are two such patches and the head of the ipvs tree now looks like
this:
0cc4789 ipvs: fix crash in ip_vs_control_net_cleanup on unload
bd7dc1c netfilter: ipvs: Verify that IP_VS protocol has been registered
Those that seemed less critical where the GFP_ATOMIC changes, one
from Sasha and 6 from Julian. The head of the ipvs-next tree now looks like
this:
663f4b2 netfilter: ipvs: use GFP_KERNEL allocation where possible
b5cfd04 ipvs: SH scheduler does not need GFP_ATOMIC allocation
5b3b290 ipvs: LBLCR scheduler does not need GFP_ATOMIC allocation on init
c087c6f ipvs: WRR scheduler does not need GFP_ATOMIC allocation
8cfaf8d ipvs: DH scheduler does not need GFP_ATOMIC allocation
e7c6390 ipvs: LBLC scheduler does not need GFP_ATOMIC allocation on init
8f78609 ipvs: timeout tables do not need GFP_ATOMIC allocation
Please let me know if there are any other patches you would like
merged at this time.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: kernel oops - do_ip_vs_get_ctl
2012-04-23 13:32 ` Simon Horman
@ 2012-04-23 19:55 ` Julian Anastasov
2012-04-26 6:31 ` Simon Horman
0 siblings, 1 reply; 4+ messages in thread
From: Julian Anastasov @ 2012-04-23 19:55 UTC (permalink / raw)
To: Simon Horman; +Cc: Hans Schillstrom, Ryan O'Hara, lvs-devel, Sasha Levin
Hello,
On Mon, 23 Apr 2012, Simon Horman wrote:
> Hi,
>
> sorry for not being a little more attentive to patches.
>
> I have now picked up all the patches that seem to have consensus.
> Those that seem critical I have pushed into ipvs with a CC: stable@
> and sent a pull request to Pablo to consider them for 3.4.
>
> There are two such patches and the head of the ipvs tree now looks like
> this:
>
> 0cc4789 ipvs: fix crash in ip_vs_control_net_cleanup on unload
> bd7dc1c netfilter: ipvs: Verify that IP_VS protocol has been registered
>
> Those that seemed less critical where the GFP_ATOMIC changes, one
> from Sasha and 6 from Julian. The head of the ipvs-next tree now looks like
> this:
>
> 663f4b2 netfilter: ipvs: use GFP_KERNEL allocation where possible
> b5cfd04 ipvs: SH scheduler does not need GFP_ATOMIC allocation
> 5b3b290 ipvs: LBLCR scheduler does not need GFP_ATOMIC allocation on init
> c087c6f ipvs: WRR scheduler does not need GFP_ATOMIC allocation
> 8cfaf8d ipvs: DH scheduler does not need GFP_ATOMIC allocation
> e7c6390 ipvs: LBLC scheduler does not need GFP_ATOMIC allocation on init
> 8f78609 ipvs: timeout tables do not need GFP_ATOMIC allocation
>
> Please let me know if there are any other patches you would like
> merged at this time.
These two patches are also fixes but may be the 2nd
patch is too long for fix:
ipvs: reset ipvs pointer in netns
ipvs: fix app registration in netns
If it looks too long for fix we can push some
simple check for net->ipvs in __ip_vs_ftp_init, so that
we do not oops when IPVS core is compiled in kernel.
Even if smaller version is sent to stable kernels,
I prefer "ipvs: fix app registration in netns" to be
applied at least for net-next. May be I should split
this 2nd patch as two-line fix + additional change
for net-next?
Hans should provide similar two-line fixes for
LBLC and LBLCR. And one for latest crash report.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: kernel oops - do_ip_vs_get_ctl
2012-04-23 19:55 ` Julian Anastasov
@ 2012-04-26 6:31 ` Simon Horman
0 siblings, 0 replies; 4+ messages in thread
From: Simon Horman @ 2012-04-26 6:31 UTC (permalink / raw)
To: Julian Anastasov
Cc: Hans Schillstrom, Ryan O'Hara, lvs-devel, Sasha Levin
On Mon, Apr 23, 2012 at 10:55:30PM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Mon, 23 Apr 2012, Simon Horman wrote:
>
> > Hi,
> >
> > sorry for not being a little more attentive to patches.
> >
> > I have now picked up all the patches that seem to have consensus.
> > Those that seem critical I have pushed into ipvs with a CC: stable@
> > and sent a pull request to Pablo to consider them for 3.4.
> >
> > There are two such patches and the head of the ipvs tree now looks like
> > this:
> >
> > 0cc4789 ipvs: fix crash in ip_vs_control_net_cleanup on unload
> > bd7dc1c netfilter: ipvs: Verify that IP_VS protocol has been registered
> >
> > Those that seemed less critical where the GFP_ATOMIC changes, one
> > from Sasha and 6 from Julian. The head of the ipvs-next tree now looks like
> > this:
> >
> > 663f4b2 netfilter: ipvs: use GFP_KERNEL allocation where possible
> > b5cfd04 ipvs: SH scheduler does not need GFP_ATOMIC allocation
> > 5b3b290 ipvs: LBLCR scheduler does not need GFP_ATOMIC allocation on init
> > c087c6f ipvs: WRR scheduler does not need GFP_ATOMIC allocation
> > 8cfaf8d ipvs: DH scheduler does not need GFP_ATOMIC allocation
> > e7c6390 ipvs: LBLC scheduler does not need GFP_ATOMIC allocation on init
> > 8f78609 ipvs: timeout tables do not need GFP_ATOMIC allocation
> >
> > Please let me know if there are any other patches you would like
> > merged at this time.
>
> These two patches are also fixes but may be the 2nd
> patch is too long for fix:
>
> ipvs: reset ipvs pointer in netns
> ipvs: fix app registration in netns
Thanks, I have these now.
> If it looks too long for fix we can push some
> simple check for net->ipvs in __ip_vs_ftp_init, so that
> we do not oops when IPVS core is compiled in kernel.
> Even if smaller version is sent to stable kernels,
> I prefer "ipvs: fix app registration in netns" to be
> applied at least for net-next. May be I should split
> this 2nd patch as two-line fix + additional change
> for net-next?
>
> Hans should provide similar two-line fixes for
> LBLC and LBLCR. And one for latest crash report.
And I am awaiting consensus on the following fixes from Hans.
ipvs: null check of net->ipvs in lblc(r) shedulers
ipvs: take care of return value from protocol init_netns
ipvs: kernel oops - do_ip_vs_get_ctl
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-04-26 6:31 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-21 10:11 Re[3]: kernel oops - do_ip_vs_get_ctl Hans Schillstrom
2012-04-23 13:32 ` Simon Horman
2012-04-23 19:55 ` Julian Anastasov
2012-04-26 6:31 ` Simon Horman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.