lkml.org 
[lkml]   [1998]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.1.125 doesn't dump core on SIGSEGV
On Tue, Oct 20, 1998 at 11:11:53PM +0100, David Woodhouse wrote:

> As you say, there's still a race. It's better to leave a gaping
> hole which obviously needs fixing than a subtle one, so Linus
> wouldn't accept it.
>
> How about:
>
> lock_vfs()
> stat()
> open()
> unlock_vfs()
>
> As I said, it's only useful in the core dump case, but that's the
> original context of this discussion. We can worry about safe temp
> file creation later.

Hmm... I'm not sure how the lock_vfs semantics would work and no
interfere with the stat and open calls.

Assuming that isn't a problem, this isn't a bad solution but it would
suck rocks for time critical stuff (rt-linux?) which might be writing
data out to disk, then some other process goes and dumps core on an
old ESDI same-day-service disk with abysmal seeks times... (making
the stat take a _long_ time, the open would be a (d)cache hit).

I'm thinking this is much harder than I envisaged, and we should
declare core dumps and root `a bad thing' until we can get O_NOFOLLOW
semantics in the vfs.

Perhaps a sysclt /proc/sys/kernel/allow_root_coredump ?



-cw

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [from the cache]
©2003-2011 Jasper Spaans