netdev - Re: [PATCH 1/2] xfrm: Force a dst refcount before entering the xfrm type handlers

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]

Date:	Wed, 16 Mar 2011 08:43:06 +0100
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	David Miller <davem@...emloft.net>
Cc:	eric.dumazet@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] xfrm: Force a dst refcount before entering the
 xfrm type handlers

On Wed, Mar 16, 2011 at 12:17:32AM -0700, David Miller wrote:
> 
> Steffen we really need to find another way to fix these problems.
> 
> We already make way too many expensive atomic operations in these code
> paths modified by your 3 patches, we should strive to not add new
> ones.
> 

I know that it is exspensive, but we have to take a refcount if
the crypto layer returns asyncronous. Unfortunately it is too
late to take the refcount when the crypto layer notifies us about
that as the skb might be already gone.

The second patch just moves the refcount from xfrm_output_one
to skb_dst_pop. As xfrm_output_one is the only user of
skb_dst_pop, we take the refcont just a bit realier.

The third one makes the socket policy case consistent to the
case where we get the destination entry from the flow cache
where we take a reference. We can either return the dst entry
with or without a refcont in both cases. But we can't return
sometimes with and somtimes without a refcount.

I'd be happy to see all these refcounts gone too of course,
but that's way beyond a simple bug fix.

Steffen
--
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