netdev - Re: [PATCH net RFC] xen-netback: Fix grant ref resolution in RX path

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, 14 May 2014 04:35:18 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Zoltan Kiss <zoltan.kiss@...rix.com>
Cc:	xen-devel@...ts.xenproject.org, ian.campbell@...rix.com,
	wei.liu2@...rix.com, linux@...elenboom.it, paul.durrant@...rix.com,
	netdev@...r.kernel.org, david.vrabel@...rix.com,
	davem@...emloft.net
Subject: Re: [PATCH net RFC] xen-netback: Fix grant ref resolution in RX path

On Wed, 2014-05-14 at 12:12 +0100, Zoltan Kiss wrote:
> On 13/05/14 17:13, Eric Dumazet wrote:
> >
> > The 'cleanup' of stale ubufs should be right after __pskb_pull_tail().
> We can't fix every place in the kernel where frags might be changed, 
> especially with a netback specific stuff, so unfortunately that won't work
> >
> > This is the function that can 'consume frags' after all.
> >
> > Its not clear that you catch all cases, like skbs being purged in case
> > of device dismantle.
> We need this list for two reason:
> a) give back the pages to the sending guest (kfree/skb_copy_ubufs)

So If networking stack takes a reference on one particular frag, or
releases a ref on a frag, how is it done exactly ?

Are you 'giving back' page to the guest later because ubuf chain is now
obsolete ???


> b) find out the grant refs when the skb is sent to another vif
> b) is handled by this patch. For a) netback doesn't mind if granted 
> frags were removed and/or local ones were injected. It only needs to 
> give back the pages, it doesn't matter how the skb ended up.

> The only other problematic point if frags are passed around between 
> skbs, I'll write a separate mail about it.

Well, it seems this is exactly the point.
You give 'very special skb' to the stack, expecting stack will never do
any frag games, like in skb_try_coalesce()



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