Re: fanotify: surprising chain reaction -> deadlock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux