From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 9 Feb 2009 16:03:54 +1100

David Miller [off-list ref] wrote:

quoted

But some apps might start breaking since this would now
charge the socket and we could hit the limits whereas
before we wouldn't.

Yes we should definitely test this carefully.

However, I think it is the right thing to do since we shouldn't
leave holes where the user can allocate kernel memory that is
uncapped.

In fact, a number of spots in IPv6 already use sock_kmalloc
for these objects anyway (e.g., ipv6_dup_options in exthdrs.c)
so there is no fundamental reason why this limit can't be imposed.

Actually it turns out we can't do that here.  This flow label object
is global, rather than specifically associated with a given socket.

See net/ipv6/ip6_flowlabel.c:fl_{create,intern}() and how those
are used.