[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCHv1 2/2] xen-netback: unref frags when handling a from-guest skb with a frag list
On Wed, 2015-03-04 at 09:56 +0000, David Vrabel wrote: > On 04/03/15 09:48, Ian Campbell wrote: > > On Tue, 2015-03-03 at 16:26 +0000, David Vrabel wrote: > >> Every time a VIF is destroyed up-to 256 pages may be leaked if packets > >> with more than MAX_SKB_FRAGS frags where transmitted from the guest. > >> Even worse, if another user of ballooned pages allocated one of these > >> ballooned pages it would not handle the the unexpectedly non-zero page > >> count (e.g., gntdev would deadlock when unmapping a grant because the > >> page count would never reach 1). > >> > >> When handling a from-guest skb with a frag list, unref the frags > >> before releasing them so they are freed correctly when the VIF is > >> destroyed. > > > > Am I right that the majority of the first 2 hunks (and various bits of > > the 3rd) are just switching the outer loop to nr_frags instead of i, to > > free up i for use in the new code below? And also to switch j to the now > > available i in the inner loop. > > Yes. If you prefer I can split this into one patch that adds the > skb_frag_unref() calls and one that reorders/refactors. If you can be bothered that might make things easier to read, thanks. > >> Also swap over to the new (local) frags /after/ calling the skb > >> destructor. This isn't strictly necessary but it's less confusing. > > > > My only concern would be that this now means there is a period where the > > frags list is invalid. However I think the calling context is such that > > nobody else can have a reference to an skb which has the same shinfo as > > the one in our hand. Is that right? > > That is correct. This skb is allocated by netback and has not yet been > passed up to the network stack. Phew! ;-) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |