From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lino Sanfilippo Subject: Re: fanotify coredump issue Date: Tue, 4 Jan 2011 11:28:49 +0100 Message-ID: <20110104102849.GB26251@lsanfilippo.unix.rd.tt.avira.com> References: <4D219A39.70805@avira.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: eparis@redhat.com, linux-fsdevel@vger.kernel.org, malware-list@dmesg.printk.net To: vasily.novikov@kaspersky.com Return-path: Received: from mailout-de.gmx.net ([213.165.64.22]:35046 "HELO mail.gmx.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with SMTP id S1750917Ab1ADKbk (ORCPT ); Tue, 4 Jan 2011 05:31:40 -0500 Content-Disposition: inline In-Reply-To: <4D219A39.70805@avira.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > > -------- Original Message -------- > Subject: [malware-list] fanotify coredump issue > Date: Mon, 27 Dec 2010 19:52:08 +0300 > From: =D0=92=D0=B0=D1=81=D0=B8=D0=BB=D0=B8=D0=B9 =D0=9D=D0=BE=D0=B2=D0= =B8=D0=BA=D0=BE=D0=B2 > To: eparis@redhat.com > CC: linux-fsdevel@vger.kernel.org , > vasily.novikov@kaspersky.com, malware-list@dmesg.printk.net > > > > Hi Eric, > > I tested fanotify in 2.6.37-rc7 and faced the following issue: when a > fanotify server process (started with open_perm set) segfaults the > kernel tries to open core dump file and here it is forced to wait a > permission result because fanotify server receives notifications on > file operations initiated by itself. Since fanotify server has crashe= d > the permission will never be granted. So the whole system hangs. Hmm I could not reproduce this with the latest state (ef9bf3b7144bee6ce= ) of =20 branch 'origin/for-next' from git.infradead.org/users/eparis/notify.git= =20 What i did was: - register with fanotify - set mark for OPEN_PERM event - read an event - cause a segfault before response is returned to fanotify The process terminates and the core file is created as expected. Could you provide some code to trigger this? > I don't see the point in receiving notifications on file operations > initiated by fanotify server process so I created a patch that > disables that and solves the issue at least in case of one fanotify > server. > > Best regards, > Vasily > > /usr/src/linux > --- ./fs/notify/fanotify/fanotify.c.orig 2010-12-24 12:50:33.65302900= 1 -0500 > +++ ./fs/notify/fanotify/fanotify.c 2010-12-24 13:28:19.561029005 -05= 00 > @@ -92,6 +92,9 @@ static int fanotify_get_response_from_ac > =20 > pr_debug("%s: group=3D%p event=3D%p\n", __func__, group, event); > =20 > + if(group->fanotify_data.tgid =3D=3D task_tgid(current)) > + return 0; > + > wait_event(group->fanotify_data.access_waitq, event->response || > atomic_read(&group->fanotify_data.bypass_perm)); > =20 > @@ -217,6 +220,7 @@ static void fanotify_free_group_priv(str > user =3D group->fanotify_data.user; > atomic_dec(&user->fanotify_listeners); > free_uid(user); > + put_pid(group->fanotify_data.tgid); > } > =20 > const struct fsnotify_ops fanotify_fsnotify_ops =3D { > --- ./fs/notify/fanotify/fanotify_user.c.orig 2010-12-24 12:12:07.593= 029001 -0500 > +++ ./fs/notify/fanotify/fanotify_user.c 2010-12-27 09:26:15.25995600= 1 -0500 > @@ -337,6 +337,10 @@ static ssize_t fanotify_read(struct file > ret =3D PTR_ERR(kevent); > if (IS_ERR(kevent)) > break; > + if(kevent->tgid =3D=3D group->fanotify_data.tgid) { > + fsnotify_put_event(kevent); > + continue; > + } > ret =3D copy_event_to_user(group, kevent, buf); > fsnotify_put_event(kevent); > if (ret < 0) > @@ -718,6 +722,7 @@ SYSCALL_DEFINE2(fanotify_init, unsigned > INIT_LIST_HEAD(&group->fanotify_data.access_list); > atomic_set(&group->fanotify_data.bypass_perm, 0); > #endif > + group->fanotify_data.tgid =3D get_pid(task_tgid(current)); > switch (flags & FAN_ALL_CLASS_BITS) { > case FAN_CLASS_NOTIF: > group->priority =3D FS_PRIO_0; > --- ./include/linux/fsnotify_backend.h.orig 2010-12-24 12:08:59.96502= 9002 -0500 > +++ ./include/linux/fsnotify_backend.h 2010-12-27 13:05:34.738636001 = -0500 > @@ -171,6 +171,7 @@ struct fsnotify_group { > int f_flags; > unsigned int max_marks; > struct user_struct *user; > + struct pid *tgid; > } fanotify_data; > #endif /* CONFIG_FANOTIFY */ > }; I dont think that this will work.=20 A fanotify registration is not tracked by its pid, but by its group whi= ch may be valid within several processes (think of fork() after you regist= ered with fanotify).=20 Thus checking for the pid of the process that has registered with fanot= ify does=20 not really make that much sense - the process may terminate right after= registration while the group continues to exist in (an)other process(es).=20 Regards, Lino=20 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html