* fanotify: surprising chain reaction -> deadlock
@ 2019-03-27 12:08 Marko Rauhamaa
2019-03-29 14:40 ` Jan Kara
0 siblings, 1 reply; 2+ messages in thread
From: Marko Rauhamaa @ 2019-03-27 12:08 UTC (permalink / raw)
To: linux-fsdevel
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.
Marko
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: fanotify: surprising chain reaction -> deadlock
2019-03-27 12:08 fanotify: surprising chain reaction -> deadlock Marko Rauhamaa
@ 2019-03-29 14:40 ` Jan Kara
0 siblings, 0 replies; 2+ messages in thread
From: Jan Kara @ 2019-03-29 14:40 UTC (permalink / raw)
To: Marko Rauhamaa; +Cc: linux-fsdevel
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@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-03-29 14:40 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-27 12:08 fanotify: surprising chain reaction -> deadlock Marko Rauhamaa
2019-03-29 14:40 ` Jan Kara
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).