Jan Kara <jack@xxxxxxx>: > Yes, so from the backtraces it is pretty clear what is going on: > > You have placed OPEN_PERM fanotify mark on a / mountpoint. Once you do > that, any open attempt anywhere in / must be approved by your process. > Then you want to place an fanotify mark on /sshome/test. As a part of > directory lookup of that path automounter triggers and wants to mount > /sshome. That tries to open something in / (likely the config file in > /etc) and blocks on approval from your process. Deadlock. > > So the kernel behaves as it was asked to, you just have to be *very* > careful when placing permission marks into the system as it is very > easy to deadlock it. Another similar type of deadlocks users of > fanotify permission events hit is that the process responding to > fanotify permission events does something (perhaps indirectly through > some library) that generates another fanotify event. That means it is not possible, in the general case, to use fanotify from a single thread/process. A worthwhile lesson. Thanks, Jan, for the clarification. Now we all know that fanotify_mark() *can* block. The fanotify_mark() man page could benefit from the addition of EINTR in the ERRORS section. Marko -- 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
