I'm pretty sure it stalled on me. I pushed his work to my tree months and months ago and never sent it along to Linus. I'll try to make sure to do that this window. -Eric On Tue, 2012-03-20 at 18:49 +0000, Luis Henriques wrote: > Hi Lino, > > Lino Sanfilippo <LinoSanfilippo@xxxxxx> writes: > > > On Mon, Aug 01, 2011 at 04:38:22PM -0400, Eric Paris wrote: > ... > >> > >> Looks at aweful lot like the problem from: > >> http://www.spinics.net/lists/linux-fsdevel/msg46101.html > >> > > > > I tried to reproduce this bug with your test program, but without success. > > However, if I understand correctly, this occurs since we dont hold any locks when > > we call iput() in mark_destroy(), right? > > With the patches you tested, iput() is also not called within any lock, since the > > groups mark_mutex is released temporarily before iput() is called. This is, since > > the original codes behaviour is similar. > > However since we now have a mutex as the biggest lock, we can do what you > > suggested (http://www.spinics.net/lists/linux-fsdevel/msg46107.html) and > > call iput() with the mutex held to avoid the race. > > The patch below implements this. It uses nested locking to avoid deadlock in case > > we do the final iput() on an inode which still holds marks and thus would take > > the mutex again when calling fsnotify_inode_delete() in destroy_inode(). > > I know it's been a while since you posted this series, but I was > wondering if there has been any progress. Is there anyone working on > this, or is it stalled? > > Cheers, > -- > Luis -- 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
