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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1266529558.3879.121.camel@bigi>
Date:	Thu, 18 Feb 2010 16:45:58 -0500
From:	jamal <hadi@...erus.ca>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: regression due to "flush SAD/SPD generate false events"

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html