From: Miklos S. <mi...@sz...> - 2008-03-14 20:06:23
|
> > Miklos Szeredi <mi...@sz...> writes: > >>> Now the big question is how to get that pid? Does the fuse kernel > >>> module already know the pid somewhere? > >> > >> No, generally there's no way to know which pid belongs to a userspace > >> filesystem. One hint would be those which have an open file referring > >> to /dev/fuse, you can get a list of these with > > > > The 'open("/dev/fuse")' call should call some (currently unset) hook > > in > > > > fs/fuse/dev.c: const struct file_operations fuse_dev_operations > > > > or not? At that point fuse could store the process group of > > 'current'. And in fuse_dev_release the process group could be removed again. > > Or would that result in the wrong thing? > > Actually I added the thing at a different place. I added a reference > to "struct pid" to the fuse connection and initialize it from > "current" in fill_super right before the connection gets added to the > active list. > > Unfortunately this gives me the wrong pid. For example when I mount > fuse-unionfs the mounting pid is 879. But the actual userspace task is > then 880, the next pid. So somewhere after mount fuse forks and dies > while the child remains running. > > I'm assuming this is the detaching. Right. But why involve the kernel at all? As I've already mentioned, 'fuser /dev/fuse' will give you a list of processes, and with a bit of digging in ps output or in /proc you could even get the members of the process groups. This would probably work most of the time, although there's no guarantee, that all filesystems use just a single process group. So I don't think there's any really generic solution to this problem, except if filesystems themselves register any process that they don't want killed at shoutdown. But this can have dangers as well, since a broken filesystem could hang the shutdown. Miklos |