Commit "nl: Return -NLE_AGAIN if non-blocking socket would block" breaks nl_cache_mngr_data_ready?

[Thomas Graf]

On 06/14/13 at 03:52pm, Andrew Collins wrote:
> I'm upgrading an application to libnl 3.2.22, and I ran into an issue
> with my usual poll()/nl_cache_mngr_data_ready() method for watching
> for link updates.
> 
> Every time I get a link update and poll wakes up, I call
> nl_cache_mngr_data_ready() which consumes data on a non-blocking
> socket (created through the cache mgr) until nl_recv returns something
> <= 0.
> 
> Prior to 3.2.22, -EAGAIN would be handled within nl_recv and send back
> 0, stopping nl_cache_mngr_data_ready() which would then return
> success.
> 
> Since "nl: Return -NLE_AGAIN if non-blocking socket would block"
> however, nl_recv returns an actual error and nl_cache_mngr_data_ready
> interprets this as a failure.  Users of
> nl_cache_mngr_poll will likely see the same issue.
> 
> What's the right thing to do here?  Should nl_cache_mngr_data_ready be
> handling -NLE_AGAIN or is my application expected to?

Right, the best option forward is to have nl_cache_mngr_data_ready()
handle NLE_AGAIN properly. Feel free to send a patch or I'll take
care of it as soon as I'm done travelling.