On 07:36 Fri 31 May, Peter P Waskiewicz Jr wrote: > On 05/31/2013 06:04 AM, Hemmo Nieminen wrote: > >My question for you is, do you think that dropping the RTNL as, for > >example, in the attached patch is safe? The used mutex should protect > >the EEPROM from concurrent invocations that are coming via ethtool's > >interface, but is there some other places that should also acquire this > >mutex before proceeding? > I would say no, it's unsafe, since the RTNL in this case is > serializing ethtool access. What happens if you release RTNL, and > allow a device reset to be issued via ethtool while the EEPROM is > updating? Good point. I had somehow thought that the dev_hold()/dev_put() calls would have prevented that, but this doesn't seem to be the case. I suppose I should acquire the mutex in for that operation as well.
However, even if I acquired the mutex in all the operations that can be called via the ethtool's interface, this would still leave any access that is not coming via it unprotected. Do you that this is really an issue? Is there a way that the EEPROM operations could be disturbed by a function call that is not coming via ethtool? -- Hemmo ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
