On Friday 20 August 2010 05:38:17 Eric Paris wrote: > As to when a listener dies: You have to define 'dies'. I meant a process that gets killed or simply exits while there are outstanding perm events. Nothing in the code would wake up the processes blocked on the perm event; they will simply be stuck forever. (They cannot even be killed with SIGKILL.) This is easy to reproduce with a listener that is killed while processing a perm event: just run the fanotify example [1] with the new -s option and hit ^C while it is sleeping. Bonus points would be awarded to make a process blocked on a listener killable with SIGKILL or other lethal signals. [1] http://git.kernel.org/?p=linux/kernel/git/agruen/fanotify-example.git The listener will also hang forever in that case; not sure why that is the case. I already told you about this before (http://lkml.org/lkml/2010/8/16/349); not sure why everything needs to repeated multiple times until it sinks in. > If the process just stops respond it is supposed to lock forever. I agree. > I was explicitly ask to remove timeouts (even though I've already been ask > off list to put them back) I disagree with putting timeouts back in. > In Linus' tree there is a race in which both processes (the > listener and the process doing an action waiting on the listener) can > deadlock and hang forever. A (much less racy but not right) patch to > fix this has already been posted. > > I have a better version which has worked well for me today which I will > likely post tomorrow morning after I look over it again. I'd love your > feedback. Do you have a pointer to that? Thanks, Andreas -- 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
