On Fri, 2009-04-17 at 23:53 +0100, Al Viro wrote: > On Fri, Apr 17, 2009 at 11:43:50PM +0100, Al Viro wrote: > > On Fri, Apr 17, 2009 at 11:17:00PM +0100, David Woodhouse wrote: > > > It sounds like the better answer is to just make sure i_mutex is held > > > when nfsd_buffered_readdir() calls back into the provided filldir > > > function (we could do it in the various filldir functions themselves, > > > _if_ they call lookup_one_len(), but I think I prefer it this way -- > > > it's simpler). Patch below for comment. > > > > Umm... I can live with that, assuming that we don't have callbacks > > that take i_mutex themselves. AFAICS, everything we call there is > > either obviously not touching i_mutex or is already called while we > > hold i_mutex elsewhere, but I'd appreciate if somebody actually > > tested that sucker for different versions of protocol... > > BTW, why mess with taking i_mutex inside the inner loop and not > immediately around it? Just to avoid making spaghetti of the bail-out cases, really. I did consider it (it wouldn't be _that_ bad), but figured that it wasn't such a bad thing if we don't hog the lock. -- David Woodhouse Open Source Technology Centre David.Woodhouse@xxxxxxxxx Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
