Thread (33 messages) flat view 33 messages, 4 authors, 2008-01-18

Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key

From: Timo Teräs <hidden>
Date: 2008-01-17 10:59:05

David Miller wrote:
From: Timo_Teräs <redacted>
Date: Thu, 17 Jan 2008 12:01:17 +0200
quoted
David Miller wrote:
quoted
This is an inherent aspect of AF_KEY (and what it was
derived from, BSD routing sockets).
Yes, this is the way BSD does it.
 
quoted
It has to provide dumps atomically, and if there is no
space there is no way to provide those entries which
would require more rcvbuf space.
RFC does not say it has to be atomic.
Every application out there in the universe expects BSD socket
semantics, and therefore atomic dumps.  You cannot "fix" things
without breaking applications.
IMHO, it's a lot better then losing >50% of entries and the end
of sequence message on big dumps. SPD and SADB are not that
volatile; in most of the cases the dump would be as good as an
atomic one.

Even if it did change during ongoing dump you still get an usable
dump. All the entries reflect real data and there is no dependency
between different entries.

I'm not sure if there's other major applications that we should
be concerned about, but at least ipsec-tools racoon does not
expect to get atomic dumps (which btw, comes originally from BSD).

Cheers,
  Timo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help