Found the bug, i introduced it, so sorry,
On Fri, Apr 25, 2014 at 9:45 AM, Gurucharan Shetty <shet...@nicira.com>wrote:
> Alex wanted the backtrace:
> at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x00007ffff6d13bab in __GI_abort () at abort.c:91
> #2 0x00000000004f08b0 in ovs_abort_valist (err_no=22,
> format=0x55714f "%s failed", args=0x7fffffffdf58) at lib/util.c:306
> #3 0x00000000004f0883 in ovs_abort (err_no=22, format=0x55714f "%s
> failed")
> at lib/util.c:298
> #4 0x00000000004cae36 in xpthread_barrier_init (arg1=0x9dbfd0, arg2=0x0,
> arg3=0) at lib/ovs-thread.c:149
> #5 0x0000000000439929 in udpif_start_threads (udpif=0x9dbf70,
> n_handlers=0,
> n_revalidators=0) at ofproto/ofproto-dpif-upcall.c:361
> #6 0x0000000000439d95 in udpif_flush (udpif=0x9dbf70)
> at ofproto/ofproto-dpif-upcall.c:476
> #7 0x000000000042a2ce in flush (ofproto_=0x9eaee0)
> at ofproto/ofproto-dpif.c:1497
> #8 0x0000000000418fc0 in ofproto_flush__ (ofproto=0x9eaee0)
> at ofproto/ofproto.c:1279
> #9 0x0000000000419c11 in ofproto_run (p=0x9eaee0) at
> ofproto/ofproto.c:1553
> #10 0x000000000040aec0 in bridge_run__ () at vswitchd/bridge.c:2340
> #11 0x0000000000406c78 in bridge_reconfigure (ovs_cfg=0xa6ff30)
> at vswitchd/bridge.c:623
> #12 0x000000000040b14c in bridge_run () at vswitchd/bridge.c:2423
> #13 0x0000000000410365 in main (argc=9, argv=0x7fffffffe4a8)
> at vswitchd/ovs-vswitchd.c:116
>
> On Fri, Apr 25, 2014 at 9:39 AM, Gurucharan Shetty <shet...@nicira.com>
> wrote:
> > With this patch, ovs-vswitchd now crashes with the following error
> > during upgrades.
> >
> > ovs-vswitchd: pthread_barrier_init failed (Invalid argument)
> > ovs-vswitchd: fork child died before signaling startup (killed
> > (Aborted), core dumped)
> >
> > Note that this happens when ovs-vswitchd is started with:
> > other_config:flow-restore-wait=true (which is true for all package
> > installations)
> >
> > Can you guys please take a look.
> >
> > On Wed, Apr 23, 2014 at 11:24 PM, Ethan Jackson <et...@nicira.com>
> wrote:
> >> W00t, nice to see this in.
> >>
> >> Ethan
> >>
> >> On Wed, Apr 23, 2014 at 9:32 PM, Joe Stringer <joestrin...@nicira.com>
> wrote:
> >>> Thanks, I tidied up the comments, added threadsafety annotations for
> xcache
> >>> and pushed.
> >>>
> >>>
> >>> On 24 April 2014 06:38, Ben Pfaff <b...@nicira.com> wrote:
> >>>>
> >>>> On Tue, Apr 22, 2014 at 04:54:24PM +1200, Joe Stringer wrote:
> >>>> > From: Ethan Jackson <et...@nicira.com>
> >>>> >
> >>>> > Previously, we had a separate flow_dumper thread that fetched flows
> from
> >>>> > the datapath to distribute to revalidator threads. This patch takes
> the
> >>>> > logic for dumping and pushes it into the revalidator threads,
> resulting
> >>>> > in simpler code with similar performance to the current code.
> >>>> >
> >>>> > One thread, the "leader", is responsible for beginning and ending
> each
> >>>> > flow dump, maintaining the flow_limit, and checking whether the
> >>>> > revalidator threads need to exit. All revalidator threads dump,
> >>>> > revalidate, delete datapath flows and garbage collect ukeys.
> >>>> >
> >>>> > Co-authored-by: Joe Stringer <joestrin...@nicira.com>
> >>>> > Signed-off-by: Joe Stringer <joestrin...@nicira.com>
> >>>>
> >>>> Here in the definition of struct udpif, I would mention that there are
> >>>> n_revalidators member of 'ukeys'. Otherwise the casual reader might
> >>>> guess that there was only one:
> >>>> > + /* During the flow dump phase, revalidators insert into these
> with
> >>>> > a random
> >>>> > + * distribution. During the garbage collection phase, each
> >>>> > revalidator
> >>>> > + * takes care of garbage collecting one of these hmaps. */
> >>>> > + struct {
> >>>> > + struct ovs_mutex mutex; /* Guards the following. */
> >>>> > + struct hmap hmap OVS_GUARDED; /* Datapath flow keys. */
> >>>> > + } *ukeys;
> >>>>
> >>>> In the definition of struct udpif_key, the synchronization of most of
> >>>> the members is pretty clear, except for 'xcache'.
> >>>>
> >>>> Acked-by: Ben Pfaff <b...@nicira.com>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> dev mailing list
> >>> dev@openvswitch.org
> >>> http://openvswitch.org/mailman/listinfo/dev
> >>>
> >> _______________________________________________
> >> dev mailing list
> >> dev@openvswitch.org
> >> http://openvswitch.org/mailman/listinfo/dev
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
