On Wed, Jul 16, 2014 at 05:12:58PM +1200, Joe Stringer wrote:
> On 16 July 2014 05:55, Ben Pfaff <b...@nicira.com> wrote:
> >
> > The kernel shouldn't ever return EAGAIN if there's more data to dump.
> > When dumping is single-threaded (as in branch-1.11) or serialized (as
> > post-commit 0791315e4d), the kernel implements that correctly. When
> > dumping is multithreaded, the kernel has races that screw it up, and
> > each thread can get EAGAIN if it loses a race. (I tried to explain
> > this in the commit message for commit 0791315e4d.) I'm pretty sure
> > that this is OK because that's how OVS worked throughout the whole OVS
> > 1.x series.
> >
>
> Thanks for explaining. Is it worth commenting this assumption in the code?
OK, I added:
/* The kernel shouldn't return EAGAIN while there's data left. */
> > * Current master, if a different error code is returned, will store the
> > > error code and stop dumping. This code appears to fall through and
> > continue
> > > reading from the buffer. Maybe the '0' is meant to be 'error'?
> >
> > Oops. Yes.
> >
> > I think that the other return could just pass along EAGAIN instead of
> > converting it to EPROTO.
> >
>
> That sounds fine.
>
>
>
> > EOF has a negative value (which is guaranteed by ANSI C and by POSIX),
> > normally -1 (but that part isn't guaranteed).
> >
>
> Now I know :-)
Thanks.
I got the impression at this point that you're happy with this patch,
even though you didn't say so explicitly, so I pushed it to master, to
avoid another day's round trip time due to timezone differences.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
