On 03/05/2014 12:57 AM, Haiyang Zhang wrote: > >> -----Original Message----- >> From: Jason Wang [mailto:jasowang@xxxxxxxxxx] >> Sent: Monday, March 3, 2014 10:10 PM >> To: Haiyang Zhang; davem@xxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx >> Cc: KY Srinivasan; olaf@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; driverdev- >> devel@xxxxxxxxxxxxxxxxxxxxxx >> Subject: Re: [PATCH net-next] hyperv: Move state setting for link query >> >> On 03/04/2014 07:54 AM, Haiyang Zhang wrote: >>> It moves the state setting for query into rndis_filter_receive_response(). >>> All callbacks including query-complete and status-callback are >>> synchronized by channel->inbound_lock. This prevents pentential race >> between them. >> >> This still looks racy to me. The problem is workqueue is not synchronized with >> those here. >> >> Consider the following case in netvsc_link_change(): >> >> if (rdev->link_state) { >> ... receive interrupt ... >> rndis_filter_receice_response() which changes rdev->link_state >> ... >> netif_carrier_off() >> } >> >> And also it need to schedule a work otherwise the link status is out of sync. > The rndis_filter_query_device_link_status() makes the query and wait for the > complete message, including set state, before returning. > > The rndis_filter_query_device_link_status() is called from rndis_filter_device_add(), > which is called from either netvsc_change_mtu() or netvsc_probe(). > > The change_mtu() and netvsc_link_change() are synchronized by rtnl_lock(). > In netvsc_probe(), the status query & complete happens before register_netdev(), and > the netvsc_linkstatus_callback() schedules the work only after netdevice is registered. > So, there are no race in either case. > > The carrier_on/off work will be scheduled when netvsc_open() is called. Then, > the status will be updated based on the latest link_state. > > Thanks, > - Haiyang > I see. Then if the link status is changing during mtu changing in guest. Looks like we may miss a link status updating? _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
