Hello,
recently, one of our customers has reported a deadlock with fanotify. The
analysis has shown that a process has put (likely by mistake) FAN_OPEN_PERM
mark on /proc and / filesystem. That resulted in a deadlock like follows:
process 1: process 2: process 3:
open("/proc/process 2/maps")
- blocks waiting for response to
FAN_OPEN_PERM event
exec(2)
__do_execve_file()
- grabs current->signal->cred_guard_mutex
do_open_execat()
- blocks waiting for response to
FAN_OPEN_PERM event
reads fanotify event
generated by process 1
create_fd()
dentry_open()
proc_maps_open()
blocks on
cred_guard_mutex of process 2.
Now this is not the only case where you can setup fanotify permissions
events so that your listener deadlocks but I'd argue that this case is
especially nasty and it is unrealistic to expect from userspace that it
would be able to implement fanotify listener in such a way that is
deadlock-free for proc filesystem since the lock dependencies there are
very different. So how about we just forbid placing marks with fanotify
permission events on proc? Any other virtual filesystem we should exclude?
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
