Re: 2.0.32 exit.c bug when CLONE_FILES? [2.1.65 also]

Ingo Molnar (mingo@pc7537.hil.siemens.at)
Tue, 25 Nov 1997 17:46:52 +0100 (MET)


On Tue, 25 Nov 1997, Bill Hawes wrote:

> > Dan Hollis has sent me some very interesting oopses. There still seems to
> > be a bug/race in sys_close() / close_fp() <==> sys_exit() / close_files()
> > / close_fp(), when there is CLONE_FILES between two processes. (bug
> > present in 2.1.65 also, i think)

> I just took a quick look at the 2.1.65 code, and I don't see how you
> would get more than one call to close_files() in the first place. The
> close_files() is called from exit_files only when the use count of the
> files structure goes to 0, and that should happen for exactly one clone
> task. [...]

ah, in 2.1.65 this seems to be fixed already.

the problem is not two close_files() but two close_fp()s for the same file
pointer, which seem to be well possible in 2.0, as file counts are
post-decremented. In 2.1 it seems to be fixed, as we explicitly pre-NULL
every file pointer.

Dan, does it still crash if you change 2.0.32 kernel/exit.c:close_files()

from:
while (set) {
if (set & 1)
- close_fp(files->fd[i]);
i++;
set >>= 1;
}

to:
while (set) {
if (set & 1) {
+ struct file * file = files->fd[i];
+ if (file) {
+ files->fd[i] = NULL;
+ close_fp(file);
+ }
}
i++;
set >>= 1;
}

-- mingo