> -----Original Message----- > From: Richard Weinberger [mailto:richard@xxxxxx] > Sent: Monday, August 25, 2014 8:07 AM > To: KY Srinivasan; Sitsofe Wheeler > Cc: Haiyang Zhang; Greg Kroah-Hartman; devel@xxxxxxxxxxxxxxxxxxxxxx; > linux-kernel@xxxxxxxxxxxxxxx; Jason Wang; Daniel Borkmann; David S. Miller; > netdev@xxxxxxxxxxxxxxx > Subject: Re: [hyperv] BUG at drivers/hv/channel.c:462 while changing MTU > > Am 25.08.2014 16:53, schrieb KY Srinivasan: > > > > > >> -----Original Message----- > >> From: Richard Weinberger [mailto:richard.weinberger@xxxxxxxxx] > >> Sent: Monday, August 25, 2014 3:48 AM > >> To: Sitsofe Wheeler > >> Cc: Haiyang Zhang; KY Srinivasan; Greg Kroah-Hartman; > >> devel@xxxxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Jason > >> Wang; Daniel Borkmann; David S. Miller; netdev@xxxxxxxxxxxxxxx > >> Subject: Re: [hyperv] BUG at drivers/hv/channel.c:462 while changing > >> MTU > >> > >> via > >> > >> > >> On Wed, Aug 20, 2014 at 5:41 AM, Sitsofe Wheeler <sitsofe@xxxxxxxxx> > >> wrote: > >>> Aug 20 04:04:41 ubuntuhv kernel: [ 9.230399] random: nonblocking pool > is > >> initialized > >>> Aug 20 04:04:41 ubuntuhv kernel: [ 10.338487] EXT4-fs (sda1): re- > >> mounted. Opts: errors=remount-ro > >>> Aug 20 04:04:41 ubuntuhv kernel: [ 11.099094] hv_storvsc vmbus_0_1: > >> cmd 0x85 scsi status 0x2 srb status 0x6 > >>> Aug 20 04:04:41 ubuntuhv kernel: [ 11.099901] hv_storvsc vmbus_0_1: > >> cmd 0x85 scsi status 0x2 srb status 0x6 > >>> Aug 20 04:04:43 ubuntuhv kernel: [ 12.999830] psmouse serio1: > trackpoint: > >> IBM TrackPoint firmware: 0x01, buttons: 0/0 > >>> Aug 20 03:55:47 ubuntuhv kernel: [ 13.003659] input: TPPS/2 IBM > >> TrackPoint as /devices/platform/i8042/serio1/input/input4 > >>> Aug 20 03:57:28 ubuntuhv kernel: [ 113.711832] hv_netvsc vmbus_0_14: > >>> net device safe to remove Aug 20 03:57:28 ubuntuhv kernel: [ > >>> 113.713882] hv_netvsc: hv_netvsc channel opened successfully Aug 20 > >>> 03:57:29 ubuntuhv kernel: [ 114.961312] hv_netvsc vmbus_0_14: Send > >>> section size: 6144, Section count:2560 Aug 20 03:57:29 ubuntuhv > >>> kernel: [ 114.962711] hv_netvsc vmbus_0_14: Device MAC > >>> 00:15:5d:6f:02:af link state up Aug 20 03:57:34 ubuntuhv kernel: [ > >>> 120.027718] hv_netvsc vmbus_0_14: net device safe to remove Aug 20 > >>> 03:57:34 ubuntuhv kernel: [ 120.030047] hv_netvsc: hv_netvsc > >>> channel opened successfully Aug 20 03:57:34 ubuntuhv kernel: [ > >>> 120.035422] > >> hv_netvsc vmbus_0_14 eth0: unable to establish receive buffer's gpadl > >> Aug > >> 20 03:57:34 ubuntuhv kernel: [ 120.039778] hv_netvsc vmbus_0_14 eth0: > >> unable to connect to NetVSP - 4 Aug 20 03:57:34 ubuntuhv kernel: [ > >> 120.039818] ------------[ cut here ]------------ Aug 20 03:57:34 ubuntuhv > kernel: > >> [ 120.039832] kernel BUG at drivers/hv/channel.c:504! > >> > >> This is one is also a rude BUG_ON: > >> ret = vmbus_post_msg(msg, sizeof(struct > >> vmbus_channel_close_channel)); > >> > >> BUG_ON(ret != 0); > >> > >> vmbus_post_msg() hv_post_message() can easily return !0. > >> i.e. if this kmalloc() fails: > >> addr = (unsigned long)kmalloc(sizeof(struct aligned_input), > >> GFP_ATOMIC); > >> if (!addr) > >> return -ENOMEM; > > > > I will submit a patch to handle this case. I suspect though that the > > original ASSERT at channel.c (line 504) is not related to kmalloc failing in > vmbus_post_msg(). I will also look at that issue as well. > > I'm sure you can replace most BUG_ON() by a WARN_ON(). > Also print more details why the assertion does not hold. The cases where I have intended to use BUG_ON are only cases where there was reasonable way to roll back from the failure (barring bugs such as what we are discussing hre). I will audit all BUG_ON calls and also print details to help debug. Thank you, K. Y > > Thanks, > //richard _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
