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
| ||
|
Date: Wed, 26 Mar 2014 17:46:06 +0000 From: Paul Durrant <Paul.Durrant@...rix.com> To: Sander Eikelenboom <linux@...elenboom.it> CC: Wei Liu <wei.liu2@...rix.com>, annie li <annie.li@...cle.com>, Zoltan Kiss <zoltan.kiss@...rix.com>, "xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>, Ian Campbell <Ian.Campbell@...rix.com>, linux-kernel <linux-kernel@...r.kernel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org> Subject: RE: [Xen-devel] Xen-unstable Linux 3.14-rc3 and 3.13 Network troubles "bisected" Re-send shortened version... > -----Original Message----- > From: Sander Eikelenboom [mailto:linux@...elenboom.it] > Sent: 26 March 2014 16:54 > To: Paul Durrant > Cc: Wei Liu; annie li; Zoltan Kiss; xen-devel@...ts.xen.org; Ian Campbell; linux- > kernel; netdev@...r.kernel.org > Subject: Re: [Xen-devel] Xen-unstable Linux 3.14-rc3 and 3.13 Network > troubles "bisected" > [snip] > >> > >> - When processing an SKB we end up in "xenvif_gop_frag_copy" while > prod > >> == cons ... but we still have bytes and size left .. > >> - start_new_rx_buffer() has returned true .. > >> - so we end up in get_next_rx_buffer > >> - this does a RING_GET_REQUEST and ups cons .. > >> - and we end up with a bad grant reference. > >> > >> Sometimes we are saved by the bell .. since additional slots have become > >> free (you see cons become > prod in "get_next_rx_buffer" but shortly > after > >> that prod is increased .. > >> just in time to not cause a overrun). > >> > > > Ah, but hang on... There's a BUG_ON meta_slots_used > > max_slots_needed, so if we are overflowing the worst-case calculation then > why is that BUG_ON not firing? > > You mean: > sco = (struct skb_cb_overlay *)skb->cb; > sco->meta_slots_used = xenvif_gop_skb(skb, &npo); > BUG_ON(sco->meta_slots_used > max_slots_needed); > > in "get_next_rx_buffer" ? > That code excerpt is from net_rx_action(),isn't it? > I don't know .. at least now it doesn't crash dom0 and therefore not my > complete machine and since tcp is recovering from a failed packet :-) > Well, if the code calculating max_slots_needed were underestimating then the BUG_ON() should fire. If it is not firing in your case then this suggests your problem lies elsewhere, or that meta_slots_used is not equal to the number of ring slots consumed. > But probably because "npo->copy_prod++" seems to be used for the frags .. > and it isn't added to npo->meta_prod ? > meta_slots_used is calculated as the value of meta_prod at return (from xenvif_gop_skb()) minus the value on entry , and if you look back up the code then you can see that meta_prod is incremented every time RING_GET_REQUEST() is evaluated. So, we must be consuming a slot without evaluating RING_GET_REQUEST() and I think that's exactly what's happening... Right at the bottom of xenvif_gop_frag_copy() req_cons is simply incremented in the case of a GSO. So the BUG_ON() is indeed off by one. Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists