[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150526170043.6bd8eaf1@lxorguk.ukuu.org.uk>
Date: Tue, 26 May 2015 17:00:43 +0100
From: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To: 曾昭荣 <zrzeng@...il.com>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Close all file descriptors for a process before starting its
core dump?
> I have a kernel customization which closes all file descriptors for
> this process just
> before starting its core dump. This way any file locks held by this
> process can be
> released automatically inside kernel before core dump.
In some cases closing the file descriptors will have side effects on the
core dump (consider mmap() objects). There are also users who rely upon
pipe() returning EOF as a way of detecting a process has exited (closing
the other end of the pipe). The pipe case is already racy agains the exit
completing so ought not to matter.
> I am wondering whether this kernel customization can cause any side effects for
> the user land process memory state? I roughly went through mmap/socket/fifo/
> pipe/sysv-ipc code, it looks closing files from inside kernel doesn't
> change user
> land process's memory content. However I am not sure, so I would like to ask
> help and confirm from you.
If you drop the locks and close the file descriptors but don't drop the
mmap() references at that point then as far as I can see on a first
think you ought to be ok. The last reference to an mmap() object would
then remain however - so mmap() objects would be cleaned up and the final
release happen after the core dump finished.
The other quick hack for this of course is to make the app use sigaction
to catch the core dumping signals except SIGABRT and close the file
descriptors and call abort().
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists