Messages in this thread | | | From | "Petr Vandrovec Ing. VTEI" <> | Date | Wed, 24 Nov 1999 18:45:38 MET-1 | Subject | Re: [patch-2.3.29] bugfix for pipe(2) system call. |
| |
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/
| |