Re: [patch-2.3.29] bugfix for pipe(2) system call.
Petr Vandrovec Ing. VTEI (VANDROVE@vc.cvut.cz)
Wed, 24 Nov 1999 18:45:38 MET-1
On 24 Nov 99 at 14:00 Tigran Aivazian wrote:
> having thought about it for a bit I think - perhaps it is better to run
> out of resources than to introduce (on some archs) a not so trivial to
> debug race condition... so perhaps it is wiser to not apply the patch
> below?
> What do people think?
We should apply it. If only one thread of application is broken,
others can continue ahead with enough resources. I do not see problems
with calling sys_close(). Thread doing pipe() allocated two descriptors,
but did not pass them to userspace yet, so if another thread closes them,
program is broken and it is program's problem. Only thing which can happen
is that sys_close() return -EBADFD. And what? That's not problem.
> > diff -urN -X dontdiff linux/arch/m68k/kernel/sys_m68k.c 2329-pipe/arch/m68k/kernel/sys_m68k.c
> > --- linux/arch/m68k/kernel/sys_m68k.c Tue Jan 19 18:58:34 1999
> > +++ 2329-pipe/arch/m68k/kernel/sys_m68k.c Wed Nov 24 14:26:19 1999
> > @@ -37,8 +37,11 @@
> > lock_kernel();
> > error = do_pipe(fd);
> > if (!error) {
> > - if (copy_to_user(fildes, fd, 2*sizeof(int)))
> > + if (copy_to_user(fildes, fd, 2*sizeof(int))) {
> > error = -EFAULT;
> > + sys_close(fd[0]);
> > + sys_close(fd[1]);
> > + }
> > }
> > unlock_kernel();
> > return error;
Erm, should not you sync m68k sys_pipe() path with other archs while you
are on it? 'unlock_kernel()' precede copy_to_user() on all other archs.
Or is there something different on m68k?
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
-
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/