[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Xen-users] kernel 3.9.2 - xen 4.2.2/4.3rc1 => BUG unable to handle kernel paging request netif_poll+0x49c/0xe8



On Fri, Jul 05, 2013 at 09:46:25PM +0200, Dion Kant wrote:
> On 07/05/2013 12:56 PM, Jan Beulich wrote:
> >>>> On 05.07.13 at 12:40, Dion Kant <g.w.kant@xxxxxxxxxx> wrote:
> >> On 07/04/2013 05:01 PM, Wei Liu wrote:
> >>> --- a/drivers/xen/netfront/netfront.c
> >>> +++ b/drivers/xen/netfront/netfront.c
> >>> @@ -1306,6 +1306,7 @@ static RING_IDX xennet_fill_frags(struct 
> >>> netfront_info *np,
> >>>         struct sk_buff *nskb;
> >>>
> >>>         while ((nskb = __skb_dequeue(list))) {
> >>> +               BUG_ON(nr_frags >= MAX_SKB_FRAGS);
> >>>                 struct netif_rx_response *rx =
> >>>                         RING_GET_RESPONSE(&np->rx, ++cons);
> >>>
> >>
> >> Integrated the patch. I obtained a crash dump and the log in it did not
> >> show this BUG_ON. Here is the relevant section from the log
> >>
> >> var/lib/xen/dump/domUA # crash /root/vmlinux-p1
> >> 2013-0705-1347.43-domUA.1.core
> >>
> >> [    7.670132] Adding 4192252k swap on /dev/xvda1.  Priority:-1 extents:1 
> >> across:4192252k SS
> >> [   10.204340] NET: Registered protocol family 17
> >> [  481.534979] netfront: Too many frags
> >> [  487.543946] netfront: Too many frags
> >> [  491.049458] netfront: Too many frags
> >> [  491.491153] ------------[ cut here ]------------
> >> [  491.491628] kernel BUG at drivers/xen/netfront/netfront.c:1295!
> > 
> > So if not the BUG_ON() from the patch above, what else does that
> > line have in your sources?
> 
> Nothing else, but thanks for pointing this out to me.
> 
> After obtaining results with your patch
> 
> 1285 static RING_IDX xennet_fill_frags(struct netfront_info *np,
> 1286                                   struct sk_buff *skb,
> 1287                                   struct sk_buff_head *list)
> 1288 {
> 1289         struct skb_shared_info *shinfo = skb_shinfo(skb);
> 1290         int nr_frags = shinfo->nr_frags;
> 1291         RING_IDX cons = np->rx.rsp_cons;
> 1292         struct sk_buff *nskb;
> 1293
> 1294         while ((nskb = __skb_dequeue(list))) {
> 1295                 struct netif_rx_response *rx =
> 1296                         RING_GET_RESPONSE(&np->rx, ++cons);
> 1297
> 1298
> 1299 if (nr_frags == MAX_SKB_FRAGS) {
> 1300         unsigned int pull_to = NETFRONT_SKB_CB(skb)->pull_to;
> 1301
> 1302         BUG_ON(pull_to <= skb_headlen(skb));
> 1303         __pskb_pull_tail(skb, pull_to - skb_headlen(skb));
> 1304                 nr_frags = shinfo->nr_frags;
> 1305 }
> 1306 BUG_ON(nr_frags >= MAX_SKB_FRAGS);
> 1307
> 1308  __skb_fill_page_desc(skb, nr_frags,
> 1309                       skb_frag_page(skb_shinfo(nskb)->frags),
> 1310                       rx->offset, rx->status);
> 
> Can I conclude that nr_frags == MAX_SKB_FRAGS, pull_to <=
> skb_headlen(skb) and the panic happens before the next BUG_ON is reached ?
> 

So the oops message below is from a kernel with Jan's patch applied,
right? The quoting level confuses me.

> > [  717.568040] netfront: Too many frags
> > [  723.768738] ------------[ cut here ]------------
> > [  723.769226] kernel BUG at drivers/xen/netfront/netfront.c:1302!

From you description and the line number I presume it is a kernel with
Jan's patch applied.

Looking at Jan's patch for upstream I discovered a problem that might
lead to this crash.


Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.