netdev - Re: [PATCH][XFRM] Optimize policy dumping

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 04 Dec 2006 15:26:12 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	hadi@...erus.ca
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH][XFRM] Optimize policy dumping

jamal wrote:
> On Mon, 2006-04-12 at 15:06 +0100, Patrick McHardy wrote:
> 
> 
>>Both ways are fine I guess. But the counting has almost no
>>overhead with the patch I sent, so I'm not sure if its worth
>>adding a callback (which still needs to get the last policy/SA
>>as argument, so that part won't get any nicer).
>>
>
> The only arguement for the callback is it will lead to eventually
> having some semi-reliable dump for pfkey. But i think that is a separate
> issue to be tackled later.

Agreed, that also looks a bit tricker than the optimization.

> I am actually scratching my head a little as to what happens when the
> pfkey socket recv is full.

dump_sp() doesn't check the return value of pfkey_broadcast, so I
guess it will just try to stuff more and more data in the recv queue,
leading to either all messages after the last one fitting getting
dropped or random drops if dumping and reading happen in parallel.

setkey will loop forever if it doesn't receive the zero sequence
number.
-
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