Hello, On Wed 27-03-19 14:08:51, Marko Rauhamaa wrote: > Just an observation of an fanotify complication... > > We have just managed to analyze an interesting vicious circle > (simplified): > > * disable IPv6 in the kernel > > * start a file monitor > > * during its initialization, the file monitor > > 1. marks file systems with OPEN_PERM > > 2. calls socket(PF_INET6) > > * the kernel executes this piece of code (socket.c): > > #ifdef CONFIG_MODULES > /* Attempt to load a protocol module if the find failed. > * > * 12/09/1996 Marcin: But! this makes REALLY only sense, if the user > * requested real, full-featured networking support upon configuration. > * Otherwise module support will break! > */ > if (rcu_access_pointer(net_families[family]) == NULL) > request_module("net-pf-%d", family); > #endif > > * request_module spawns "modprobe" in the user space > > * opening "modprobe" is blocked by OPEN_PERM; however, the file monitor > is still blocked in the socket(2) system call and can't release the > "modprobe" process > > I'm not sure if there is a bug somewhere here but a surprising > interaction nonetheless. Yeah. Everything works as it should but I agree it is rather surprising. It is difficult to design process processing fanotify permission events that does not deadlock... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR