bug in nl_cache_mngr_data_ready / nl_cache_refill / nl_cache_resync [+patch proposition]

[Brett Ciphery]

[Re: bug in nl_cache_mngr_data_ready / nl_cache_refill / nl_cache_resync [+patch proposition]] On 21/04/2012 (Sat 06:51) Thomas Graf wrote:

> On Thu, Apr 19, 2012 at 01:09:10PM -0400, Thomas Graf wrote:
> > What we can do is extend recvmsgs() do offer both behaviours
> > and have the cache manager direct it to continue reading
> > as long as there is data.
> > 
> > I'll fix that. I'm planning to look into and improve the
> > cache manager anyway. It's not reliable enough at the moment.
> 
> See commit a518a31 (cache_mngr: Let nl_cache_mngr_data_ready()
> read multiple messages).
> 
> It should fix your case Brett while keeping the behaviour for
> blocking sockets the same.

Many thanks.

I was looking at comments of nl_recvmsgs() which
nl_cache_mngr_data_ready() calls:

 * Repeatedly calls nl_recv() or the respective replacement if provided
 * by the application (see nl_cb_overwrite_recv()) and parses the
 * received data as netlink messages. Stops reading if one of the
 * callbacks returns NL_STOP or nl_recv returns either 0 or a negative
 * error code.

and so thought the expected behaviour would be to loop until there was
nothing left.  Returning a count is clean though, I'll check how this
works with nl_cache_mngr_data_ready() and other cache refilling
functions.

Brett