Re: [lvs-users] LVS kernel panic

To: Julian Anastasov <ja@xxxxxx>
Subject: Re: [lvs-users] LVS kernel panic
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx, lvs-devel@xxxxxxxxxxxxxxx
From: Alexander Vasiliev <a.vasylev@xxxxxxxxxxxxx>
Date: Fri, 19 Jun 2015 10:53:56 +0300
Thanks, for answer. I will use -D ==> -A for edit services.

> On Jun 18, 2015, at 9:52 PM, Julian Anastasov <ja@xxxxxx> wrote:
>       Hello,
> On Thu, 18 Jun 2015, Alexander Vasiliev wrote:
>> Hello.
>> I have installed ipvsadm (1.2.1) on Linux Ubuntu-14.04 (3.13.0-55-generic) 
>> server.
>> Next I create service: ipvsadm -A -t -s lblc.
>> When I tried edit created service I got kernel panic. Edit command: ipvsadm 
>> -A -t -s rr, for example.
>> The problem is repeatable, I try in VirtualBox.
>       You mean second command is -E, not -A, right?
> It looks like I completely messed the scheduler editing
> with commit ceec4c381681 ("ipvs: convert services to rcu").
> The problem is with the svc->sched_data. I forgot about it.
> The reverse order of ip_vs_bind_scheduler and
> ip_vs_unbind_scheduler causes problem in all cases
> for schedulers that maintain sched_data.
> And RCU readers are not guaranteed to get the
> scheduler+sched_data pointers safely for same scheduler.
>       The simple fix would be to make sure
> ip_vs_unbind_scheduler and ip_vs_bind_scheduler work
> in this order but with synchronize_rcu between them.
> Something like what was before this change.
> The individual schedulers will not be touched.
> As changing of scheduler is a rare operation it can
> be the initial bugfix. If we want to fix it without
> such delay we have to change all schedulers, may be
> by moving sched_data in some new struct scheduler_context
> where schedulers can store their sched_data. Then
> svc->sched_context (RCU ptr) can contain both the
> scheduler and the sched_data pointers.
> Regards
> --
> Julian Anastasov <ja@xxxxxx>

To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

<Prev in Thread] Current Thread [Next in Thread>