> From: Vitaly Kuznetsov [mailto:vkuznets@xxxxxxxxxx] > Sent: Friday, March 25, 2016 0:11 > To: Dexuan Cui <decui@xxxxxxxxxxxxx> > Cc: driverdev-devel@xxxxxxxxxxxxxxxxxxxxxx; Chris Valean (Cloudbase Solutions > SRL) <v-chvale@xxxxxxxxxxxxx>; KY Srinivasan <kys@xxxxxxxxxxxxx> > Subject: Re: KVP daemon/module race on module unloading > > Dexuan Cui <decui@xxxxxxxxxxxxx> writes: > > > Hi Vitaly, > > We got the below warning once -- it's pretty hard to repro it. > > > > I think the cause may be: before the daemon is terminated, we can > successfully > > "rmmod hv_utils" -- as a result all the code/data segments of the module > > shouldn't be accessed any more, but in the kernel we still has a dangling > > pointer set up by hvt_op_poll() -> poll_wait(file, &hvt->outmsg_q, wait); > > > > Finally, when the daemon is terminated, the call trace could happen. > > > > I think the module should never be unloaded when there is a fd opened > > on /dev/vmbus/hv_kvp? > > Yes, I was pretty sure .owner = THIS_MODULE does that. Hi Vitaly, Sorry -- I didn't realize I used a netlink version of the kvp daemon... Actually our test team got the call trace in a RHEL 7.2 VM that was updated with LIS 4.1. > There was a fix from Alex a month ago: > > commit e66853b09017a788dc384dadce9323396dae3293 > Author: Alex Ng <alexng@xxxxxxxxxxxxx> > Date: Fri Feb 26 15:13:20 2016 -0800 > > Drivers: hv: utils: Remove util transport handler from list if > registration fails > > Do you have it in your kernel? (though I think it only applies if > transport registration fails...) > > I'll take a closer look anyway, thanks for the report! > > Vitaly Thanks for the reminder! Yeah, LIS 4.1 lacks this fix and another more important fix: commit 9420098adc50a88d4a441e0f92d54bfa7af44448 Author: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> Date: Mon Dec 14 19:01:56 2015 -0800 Drivers: hv: utils: fix crash when device is removed from host side So please ignore this thread. We'll make sure all the upstream hv_utils patches are ported to LIS-next and hopefully the rare call trace will go away. Thanks, -- Dexuan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
