Re: regression due to "flush SAD/SPD generate false events"

[jamal <hadi@cyberus.ca>]

On Thu, 2010-02-18 at 15:53 -0500, jamal wrote:

> Agree - that is a better alternative.
> I was hoping returning an error code of 0 will do that.
> But that triggers the EAGAIN you saw. It doesnt trigger
> an EAGAIN for the netlink side (and it is a nop there).
> Let me look at it. Clearly the EAGAIN is causing the 
> latency.

Ok, looking closely at the strace i think ive figured out
what pfkey is doing. It basically sets non-blocking receive
and expects to see the flush event whether real or bogus
(EAGAIN is because it tries to recvmsg and fails the first
time because we dont send the event when table is empty).

The two options are: 1) Restore old behavior just for pfkey
where bogus event is sent always or 2) return -ESRCH as I
have done in the last patch.
I think #2 is more accurate. But if that is going to break
existing scripts then #1 is the way to go.

Thoughts?

cheers,
jamal