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
