netdev - Re: [XFRM] Optimize SA 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <1165240502.3664.67.camel@localhost>
Date:	Mon, 04 Dec 2006 08:55:02 -0500
From:	jamal <hadi@...erus.ca>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [XFRM] Optimize SA dumping

On Mon, 2006-04-12 at 14:39 +0100, Patrick McHardy wrote:
...
...
> 4. iteration:
> 
> We have send_x = NULL and last_x != NULL, so send_x != last_x,
> leading to dump(NULL, ...)
> 

Ok, that is a very easy fix i.e just have 
         (send_x && send_x != last_x) 
as is done when the loop is exited. I thought i did that.

But i dont know if i even wanna fix that; consider the callback approach
i mentioned earlier.

> > In any case, if i go the done callback approach, I can get rid of all
> > this tracking thing ...
> 
> I need to read your other mail first before commenting on this :)

There is one key thing to observe: 
The count parameter is only used by pfkey; this is because the RFC
requires that we set the last entry to zero. So all that counting done
in the original codes first loop (which is huge overhead if you have a
large number of rules) is just so that we can achieve that ;->

By doing a callback, we move the burden of storing any state to pfkey
and free xfrm.

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