From: Sergey Vlasov <vsu@altlinux.ru> To: devel-kernel <devel-kernel@altlinux.ru> Subject: [d-kernel] 2.4.20-alt9 - possibly more bugs Date: Mon, 11 Aug 2003 20:47:26 +0400 Message-ID: <20030811204726.64e0926a.vsu@altlinux.ru> (raw) [-- Attachment #1.1: Type: text/plain, Size: 168 bytes --] Hello! Похоже, в фиксе steal_locks к фиксу unshare_files нашли ещё баг :-( (Я ещё не рассматривал внимательно код 2.4.20-alt9 на эту тему) -- Sergey Vlasov [-- Attachment #1.2: Type: message/rfc822, Size: 3507 bytes --] From: Andreas Gruenbacher <agruen@suse.de> Cc: Marcelo Tosatti <marcelo@conectiva.com.br>, Alan Cox <alan@lxorguk.ukuu.org.uk>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] 2.4: Fix steal_locks race Date: Sat, 9 Aug 2003 05:17:15 +0200 (CEST) Message-ID: <Pine.LNX.4.53.0308090514430.18879@Chaos.suse.de> On Sat, 9 Aug 2003, Herbert Xu wrote: > On Sat, Aug 09, 2003 at 04:59:03AM +0200, Andreas Gruenbacher wrote: > > > > @@ -714,18 +715,16 @@ static int load_elf_binary(struct linux_ > > elf_entry = load_elf_interp(&interp_elf_ex, > > interpreter, > > &interp_load_addr); > > - > > - allow_write_access(interpreter); > > - fput(interpreter); > > - kfree(elf_interpreter); > > - > > if (BAD_ADDR(elf_entry)) { > > printk(KERN_ERR "Unable to load interpreter\n"); > > - kfree(elf_phdata); > > send_sig(SIGSEGV, current, 0); > > retval = -ENOEXEC; /* Nobody gets to see this, but.. */ > > - goto out; > > + goto out_free_dentry; > > } > > + > > + allow_write_access(interpreter); > > + fput(interpreter); > > + kfree(elf_interpreter); > > } > > This looks bad since you're past the point of no return. This is an equivalence transformation except for the explicit sys_close(elf_exec_fileno) in the unwind code, which would eventually happen, anyway. [-- Attachment #1.3: Type: message/rfc822, Size: 3681 bytes --] From: Herbert Xu <herbert@gondor.apana.org.au> Cc: Marcelo Tosatti <marcelo@conectiva.com.br>, Alan Cox <alan@lxorguk.ukuu.org.uk>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] 2.4: Fix steal_locks race Date: Sat, 9 Aug 2003 13:04:09 +1000 Message-ID: <20030809030409.GA11867@gondor.apana.org.au> On Sat, Aug 09, 2003 at 04:59:03AM +0200, Andreas Gruenbacher wrote: > > @@ -714,18 +715,16 @@ static int load_elf_binary(struct linux_ > elf_entry = load_elf_interp(&interp_elf_ex, > interpreter, > &interp_load_addr); > - > - allow_write_access(interpreter); > - fput(interpreter); > - kfree(elf_interpreter); > - > if (BAD_ADDR(elf_entry)) { > printk(KERN_ERR "Unable to load interpreter\n"); > - kfree(elf_phdata); > send_sig(SIGSEGV, current, 0); > retval = -ENOEXEC; /* Nobody gets to see this, but.. */ > - goto out; > + goto out_free_dentry; > } > + > + allow_write_access(interpreter); > + fput(interpreter); > + kfree(elf_interpreter); > } This looks bad since you're past the point of no return. -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt [-- Attachment #1.4: Type: message/rfc822, Size: 9899 bytes --] [-- Attachment #1.4.1.1: Type: TEXT/PLAIN, Size: 514 bytes --] Here is an accumulate patch of Herbert's and my changes. I could see no reason for ftmp in flush_old_exec and load_elf_binary, so I removed that. Please correct me if that is wrong. Cheers, Andreas. On Fri, 8 Aug 2003, Herbert Xu wrote: > Hi: > > The steal_locks() call in binfmt_elf.c is buggy. It steals locks from > a files entry whose reference was dropped much earlier. This allows it > to steal other process's locks. > > The following patch calls steal_locks() earlier so that this does not > happen. [-- Attachment #1.4.1.2: Type: TEXT/PLAIN, Size: 4686 bytes --] Index: linux-2.4.22-rc2.orig/fs/exec.c =================================================================== --- linux-2.4.22-rc2.orig.orig/fs/exec.c 2003-08-09 04:44:07.000000000 +0200 +++ linux-2.4.22-rc2.orig/fs/exec.c 2003-08-09 04:47:53.000000000 +0200 @@ -582,8 +582,6 @@ int flush_old_exec(struct linux_binprm * retval = unshare_files(); if(retval) goto flush_failed; - steal_locks(files, current->files); - put_files_struct(files); /* * Release all of the old mmap stuff @@ -592,6 +590,8 @@ int flush_old_exec(struct linux_binprm * if (retval) goto mmap_failed; /* This is the point of no return */ + steal_locks(files); + put_files_struct(files); release_old_signals(oldsig); current->sas_ss_sp = current->sas_ss_size = 0; @@ -629,6 +629,8 @@ int flush_old_exec(struct linux_binprm * return 0; mmap_failed: + put_files_struct(current->files); + current->files = files; flush_failed: spin_lock_irq(¤t->sigmask_lock); if (current->sig != oldsig) { Index: linux-2.4.22-rc2.orig/include/linux/fs.h =================================================================== --- linux-2.4.22-rc2.orig.orig/include/linux/fs.h 2003-08-09 04:44:07.000000000 +0200 +++ linux-2.4.22-rc2.orig/include/linux/fs.h 2003-08-09 04:46:05.000000000 +0200 @@ -674,7 +674,7 @@ extern int __get_lease(struct inode *ino extern time_t lease_get_mtime(struct inode *); extern int lock_may_read(struct inode *, loff_t start, unsigned long count); extern int lock_may_write(struct inode *, loff_t start, unsigned long count); -extern void steal_locks(fl_owner_t from, fl_owner_t to); +extern void steal_locks(fl_owner_t from); struct fasync_struct { int magic; Index: linux-2.4.22-rc2.orig/fs/binfmt_elf.c =================================================================== --- linux-2.4.22-rc2.orig.orig/fs/binfmt_elf.c 2003-08-09 04:44:07.000000000 +0200 +++ linux-2.4.22-rc2.orig/fs/binfmt_elf.c 2003-08-09 04:48:27.000000000 +0200 @@ -444,7 +444,7 @@ static int load_elf_binary(struct linux_ struct elfhdr interp_elf_ex; struct exec interp_ex; char passed_fileno[6]; - struct files_struct *files, *ftmp; + struct files_struct *files; /* Get the exec-header */ elf_ex = *((struct elfhdr *) bprm->buf); @@ -480,7 +480,6 @@ static int load_elf_binary(struct linux_ files = current->files; /* Refcounted so ok */ if(unshare_files() < 0) goto out_free_ph; - steal_locks(files, current->files); /* exec will make our files private anyway, but for the a.out loader stuff we need to do it earlier */ @@ -603,7 +602,9 @@ static int load_elf_binary(struct linux_ goto out_free_dentry; /* Discard our unneeded old files struct */ + steal_locks(files); put_files_struct(files); + files = NULL; /* OK, This is the point of no return */ current->mm->start_data = 0; @@ -714,18 +715,16 @@ static int load_elf_binary(struct linux_ elf_entry = load_elf_interp(&interp_elf_ex, interpreter, &interp_load_addr); - - allow_write_access(interpreter); - fput(interpreter); - kfree(elf_interpreter); - if (BAD_ADDR(elf_entry)) { printk(KERN_ERR "Unable to load interpreter\n"); - kfree(elf_phdata); send_sig(SIGSEGV, current, 0); retval = -ENOEXEC; /* Nobody gets to see this, but.. */ - goto out; + goto out_free_dentry; } + + allow_write_access(interpreter); + fput(interpreter); + kfree(elf_interpreter); } kfree(elf_phdata); @@ -811,10 +810,10 @@ out_free_interp: out_free_file: sys_close(elf_exec_fileno); out_free_fh: - ftmp = current->files; - current->files = files; - steal_locks(ftmp, current->files); - put_files_struct(ftmp); + if (files) { + put_files_struct(current->files); + current->files = files; + } out_free_ph: kfree(elf_phdata); goto out; Index: linux-2.4.22-rc2.orig/fs/locks.c =================================================================== --- linux-2.4.22-rc2.orig.orig/fs/locks.c 2003-08-09 04:44:07.000000000 +0200 +++ linux-2.4.22-rc2.orig/fs/locks.c 2003-08-09 04:46:05.000000000 +0200 @@ -1937,11 +1937,11 @@ done: return length; } -void steal_locks(fl_owner_t from, fl_owner_t to) +void steal_locks(fl_owner_t from) { struct list_head *tmp; - if (from == to) + if (from == current->files) return; lock_kernel(); @@ -1949,7 +1949,7 @@ void steal_locks(fl_owner_t from, fl_own struct file_lock *fl = list_entry(tmp, struct file_lock, fl_link); if (fl->fl_owner == from) - fl->fl_owner = to; + fl->fl_owner = current->files; } unlock_kernel(); } [-- Attachment #1.5: Type: message/rfc822, Size: 4454 bytes --] From: Andreas Gruenbacher <agruen@suse.de> Cc: Marcelo Tosatti <marcelo@conectiva.com.br>, Alan Cox <alan@lxorguk.ukuu.org.uk>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] 2.4: Fix steal_locks race Date: 09 Aug 2003 05:30:16 +0200 Message-ID: <1060399816.1798.38.camel@bree.suse.de> On Sat, 2003-08-09 at 05:19, Herbert Xu wrote: > On Sat, Aug 09, 2003 at 05:13:52AM +0200, Andreas Gruenbacher wrote: > > On Sat, 9 Aug 2003, Herbert Xu wrote: > > > > > On Sat, Aug 09, 2003 at 04:04:53AM +0200, Andreas Gruenbacher wrote: > > > > > > > > > My patch is buggy too. If a file is closed by another clone between > > > > > the two steal_locks calls the lock will again be lost. Fortunately > > > > > this much harder to trigger than the previous bug. > > > > > > > > I think this is not a strict bug---this scenario is not covered by POSIX > > > > in the first place. Unless lock stealing is done atomically with > > > > unshare_files there is a window of oportunity between unshare_files() and > > > > steal_locks(), so locks can still get lost. > > > > > > It's not a standard compliance issue. In this case the lock will never > > > be released and it will eventually lead to a crash when someone reads > > > /proc/locks. > > > > I don't see how this would happen. Could you please elaborate? > > Suppose that A and B share current->files and fd has a POSIX lock on it. > > A B > unshare_files > steal_locks > close(fd) > exec fails > steal_locks > put_files_struct > > The close in B fails to release the lock as it has been stolen by the > new files structure. The second steal_locks sets the fl_owner back to > the original files structure which no longer has fd in it and hence can > never release that lock. The put_files_struct doesn't release the lock > either since it is now owned by the original file structure. In the patch I've sent there is no stealing back of locks, so that case does not exist. Cheers, -- Andreas Gruenbacher <agruen@suse.de> SuSE Labs, SuSE Linux AG <http://www.suse.de/> [-- Attachment #1.6: Type: message/rfc822, Size: 4492 bytes --] From: Herbert Xu <herbert@gondor.apana.org.au> Cc: Marcelo Tosatti <marcelo@conectiva.com.br>, Alan Cox <alan@lxorguk.ukuu.org.uk>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] 2.4: Fix steal_locks race Date: Sat, 9 Aug 2003 13:19:45 +1000 Message-ID: <20030809031945.GA12102@gondor.apana.org.au> On Sat, Aug 09, 2003 at 05:13:52AM +0200, Andreas Gruenbacher wrote: > On Sat, 9 Aug 2003, Herbert Xu wrote: > > > On Sat, Aug 09, 2003 at 04:04:53AM +0200, Andreas Gruenbacher wrote: > > > > > > > My patch is buggy too. If a file is closed by another clone between > > > > the two steal_locks calls the lock will again be lost. Fortunately > > > > this much harder to trigger than the previous bug. > > > > > > I think this is not a strict bug---this scenario is not covered by POSIX > > > in the first place. Unless lock stealing is done atomically with > > > unshare_files there is a window of oportunity between unshare_files() and > > > steal_locks(), so locks can still get lost. > > > > It's not a standard compliance issue. In this case the lock will never > > be released and it will eventually lead to a crash when someone reads > > /proc/locks. > > I don't see how this would happen. Could you please elaborate? Suppose that A and B share current->files and fd has a POSIX lock on it. A B unshare_files steal_locks close(fd) exec fails steal_locks put_files_struct The close in B fails to release the lock as it has been stolen by the new files structure. The second steal_locks sets the fl_owner back to the original files structure which no longer has fd in it and hence can never release that lock. The put_files_struct doesn't release the lock either since it is now owned by the original file structure. -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt [-- Attachment #1.7: Type: message/rfc822, Size: 3372 bytes --] From: Andreas Gruenbacher <agruen@suse.de> Cc: Marcelo Tosatti <marcelo@conectiva.com.br>, Alan Cox <alan@lxorguk.ukuu.org.uk>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] 2.4: Fix steal_locks race Date: Sat, 9 Aug 2003 05:13:52 +0200 (CEST) Message-ID: <Pine.LNX.4.53.0308090509020.18879@Chaos.suse.de> On Sat, 9 Aug 2003, Herbert Xu wrote: > On Sat, Aug 09, 2003 at 04:04:53AM +0200, Andreas Gruenbacher wrote: > > > > > My patch is buggy too. If a file is closed by another clone between > > > the two steal_locks calls the lock will again be lost. Fortunately > > > this much harder to trigger than the previous bug. > > > > I think this is not a strict bug---this scenario is not covered by POSIX > > in the first place. Unless lock stealing is done atomically with > > unshare_files there is a window of oportunity between unshare_files() and > > steal_locks(), so locks can still get lost. > > It's not a standard compliance issue. In this case the lock will never > be released and it will eventually lead to a crash when someone reads > /proc/locks. I don't see how this would happen. Could you please elaborate? [-- Attachment #1.8: Type: message/rfc822, Size: 3679 bytes --] From: Herbert Xu <herbert@gondor.apana.org.au> Cc: Marcelo Tosatti <marcelo@conectiva.com.br>, Alan Cox <alan@lxorguk.ukuu.org.uk>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] 2.4: Fix steal_locks race Date: Sat, 9 Aug 2003 12:52:32 +1000 Message-ID: <20030809025232.GA11777@gondor.apana.org.au> On Sat, Aug 09, 2003 at 04:04:53AM +0200, Andreas Gruenbacher wrote: > > > My patch is buggy too. If a file is closed by another clone between > > the two steal_locks calls the lock will again be lost. Fortunately > > this much harder to trigger than the previous bug. > > I think this is not a strict bug---this scenario is not covered by POSIX > in the first place. Unless lock stealing is done atomically with > unshare_files there is a window of oportunity between unshare_files() and > steal_locks(), so locks can still get lost. It's not a standard compliance issue. In this case the lock will never be released and it will eventually lead to a crash when someone reads /proc/locks. -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt [-- Attachment #1.9: Type: message/rfc822, Size: 3305 bytes --] From: Andreas Gruenbacher <agruen@suse.de> Cc: Marcelo Tosatti <marcelo@conectiva.com.br>, Alan Cox <alan@lxorguk.ukuu.org.uk>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] 2.4: Fix steal_locks race Date: Sat, 9 Aug 2003 04:04:53 +0200 (CEST) Message-ID: <Pine.LNX.4.53.0308090357290.18879@Chaos.suse.de> On Sat, 9 Aug 2003, Herbert Xu wrote: > On Fri, Aug 08, 2003 at 08:53:21PM +1000, herbert wrote: > > > > The steal_locks() call in binfmt_elf.c is buggy. It steals locks from > > a files entry whose reference was dropped much earlier. This allows it > > to steal other process's locks. > > > > The following patch calls steal_locks() earlier so that this does not > > happen. > > My patch is buggy too. If a file is closed by another clone between > the two steal_locks calls the lock will again be lost. Fortunately > this much harder to trigger than the previous bug. I think this is not a strict bug---this scenario is not covered by POSIX in the first place. Unless lock stealing is done atomically with unshare_files there is a window of oportunity between unshare_files() and steal_locks(), so locks can still get lost. Cheers, Andreas. [-- Attachment #1.10: Type: message/rfc822, Size: 3295 bytes --] From: Andreas Gruenbacher <agruen@suse.de> Cc: Marcelo Tosatti <marcelo@conectiva.com.br>, Alan Cox <alan@lxorguk.ukuu.org.uk>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] 2.4: Fix steal_locks race Date: Sat, 9 Aug 2003 03:46:55 +0200 (CEST) Message-ID: <Pine.LNX.4.53.0308090343490.18879@Chaos.suse.de> Hello, thanks a lot for analyzing this. Please see the patch I just posted unter the subject: [PATCH] 2.4.22-rc2 steal_locks and load_elf_binary cleanups That patch fixes the bug in a slightly cleaner way. On Sat, 9 Aug 2003, Herbert Xu wrote: > On Fri, Aug 08, 2003 at 08:53:21PM +1000, herbert wrote: > > > > The steal_locks() call in binfmt_elf.c is buggy. It steals locks from > > a files entry whose reference was dropped much earlier. This allows it > > to steal other process's locks. This makes sense. > > The following patch calls steal_locks() earlier so that this does not > > happen. > > My patch is buggy too. If a file is closed by another clone between > the two steal_locks calls the lock will again be lost. Fortunately > this much harder to trigger than the previous bug. > > The following patch fixes that. > [-- Attachment #1.11: Type: message/rfc822, Size: 3005 bytes --] From: Andreas Gruenbacher <agruen@suse.de> Cc: Marcelo Tosatti <marcelo@conectiva.com.br>, Alan Cox <alan@lxorguk.ukuu.org.uk>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] 2.4: Restore current->files in flush_old_exec Date: Sat, 9 Aug 2003 03:48:06 +0200 (CEST) Message-ID: <Pine.LNX.4.53.0308090347240.18879@Chaos.suse.de> On Sat, 9 Aug 2003, Herbert Xu wrote: > Hi: > > The unshare_files patch to flush_old_exec() did not restore the original > state when exec_mmap fails. This patch fixes that. Indeed. This is still needed. > At this point, I believe the unshare_files stuff should be fine from > a correctness point of view. However, there is still a performance > problem as every ELF exec call ends up dupliating the files structure > as well as walking through all file locks. Cheers, Andreas. [-- Attachment #1.12: Type: message/rfc822, Size: 9946 bytes --] [-- Attachment #1.12.1.1: Type: TEXT/PLAIN, Size: 143 bytes --] Here is an update ... > On Sat, 9 Aug 2003, Herbert Xu wrote: > > Yes but when you call unshare_files twice one of them will have to > > copy. [-- Attachment #1.12.1.2: Type: TEXT/PLAIN, Size: 4826 bytes --] Index: linux-2.4.22-rc2.orig/fs/exec.c =================================================================== --- linux-2.4.22-rc2.orig.orig/fs/exec.c 2003-08-09 04:44:07.000000000 +0200 +++ linux-2.4.22-rc2.orig/fs/exec.c 2003-08-09 05:04:35.000000000 +0200 @@ -582,8 +582,6 @@ int flush_old_exec(struct linux_binprm * retval = unshare_files(); if(retval) goto flush_failed; - steal_locks(files, current->files); - put_files_struct(files); /* * Release all of the old mmap stuff @@ -592,6 +590,8 @@ int flush_old_exec(struct linux_binprm * if (retval) goto mmap_failed; /* This is the point of no return */ + steal_locks(files); + put_files_struct(files); release_old_signals(oldsig); current->sas_ss_sp = current->sas_ss_size = 0; @@ -629,6 +629,8 @@ int flush_old_exec(struct linux_binprm * return 0; mmap_failed: + put_files_struct(current->files); + current->files = files; flush_failed: spin_lock_irq(¤t->sigmask_lock); if (current->sig != oldsig) { Index: linux-2.4.22-rc2.orig/include/linux/fs.h =================================================================== --- linux-2.4.22-rc2.orig.orig/include/linux/fs.h 2003-08-09 04:44:07.000000000 +0200 +++ linux-2.4.22-rc2.orig/include/linux/fs.h 2003-08-09 05:04:35.000000000 +0200 @@ -674,7 +674,7 @@ extern int __get_lease(struct inode *ino extern time_t lease_get_mtime(struct inode *); extern int lock_may_read(struct inode *, loff_t start, unsigned long count); extern int lock_may_write(struct inode *, loff_t start, unsigned long count); -extern void steal_locks(fl_owner_t from, fl_owner_t to); +extern void steal_locks(fl_owner_t from); struct fasync_struct { int magic; Index: linux-2.4.22-rc2.orig/fs/binfmt_elf.c =================================================================== --- linux-2.4.22-rc2.orig.orig/fs/binfmt_elf.c 2003-08-09 04:44:07.000000000 +0200 +++ linux-2.4.22-rc2.orig/fs/binfmt_elf.c 2003-08-09 05:06:05.000000000 +0200 @@ -444,7 +444,7 @@ static int load_elf_binary(struct linux_ struct elfhdr interp_elf_ex; struct exec interp_ex; char passed_fileno[6]; - struct files_struct *files, *ftmp; + struct files_struct *files; /* Get the exec-header */ elf_ex = *((struct elfhdr *) bprm->buf); @@ -480,7 +480,10 @@ static int load_elf_binary(struct linux_ files = current->files; /* Refcounted so ok */ if(unshare_files() < 0) goto out_free_ph; - steal_locks(files, current->files); + if (files == current->files) { + put_files_struct(files); + files = NULL; + } /* exec will make our files private anyway, but for the a.out loader stuff we need to do it earlier */ @@ -603,7 +606,11 @@ static int load_elf_binary(struct linux_ goto out_free_dentry; /* Discard our unneeded old files struct */ - put_files_struct(files); + if (files) { + steal_locks(files); + put_files_struct(files); + files = NULL; + } /* OK, This is the point of no return */ current->mm->start_data = 0; @@ -714,18 +721,16 @@ static int load_elf_binary(struct linux_ elf_entry = load_elf_interp(&interp_elf_ex, interpreter, &interp_load_addr); - - allow_write_access(interpreter); - fput(interpreter); - kfree(elf_interpreter); - if (BAD_ADDR(elf_entry)) { printk(KERN_ERR "Unable to load interpreter\n"); - kfree(elf_phdata); send_sig(SIGSEGV, current, 0); retval = -ENOEXEC; /* Nobody gets to see this, but.. */ - goto out; + goto out_free_dentry; } + + allow_write_access(interpreter); + fput(interpreter); + kfree(elf_interpreter); } kfree(elf_phdata); @@ -811,10 +816,10 @@ out_free_interp: out_free_file: sys_close(elf_exec_fileno); out_free_fh: - ftmp = current->files; - current->files = files; - steal_locks(ftmp, current->files); - put_files_struct(ftmp); + if (files) { + put_files_struct(current->files); + current->files = files; + } out_free_ph: kfree(elf_phdata); goto out; Index: linux-2.4.22-rc2.orig/fs/locks.c =================================================================== --- linux-2.4.22-rc2.orig.orig/fs/locks.c 2003-08-09 04:44:07.000000000 +0200 +++ linux-2.4.22-rc2.orig/fs/locks.c 2003-08-09 05:04:35.000000000 +0200 @@ -1937,11 +1937,11 @@ done: return length; } -void steal_locks(fl_owner_t from, fl_owner_t to) +void steal_locks(fl_owner_t from) { struct list_head *tmp; - if (from == to) + if (from == current->files) return; lock_kernel(); @@ -1949,7 +1949,7 @@ void steal_locks(fl_owner_t from, fl_own struct file_lock *fl = list_entry(tmp, struct file_lock, fl_link); if (fl->fl_owner == from) - fl->fl_owner = to; + fl->fl_owner = current->files; } unlock_kernel(); } [-- Attachment #1.13: Type: message/rfc822, Size: 3479 bytes --] From: Andreas Gruenbacher <agruen@suse.de> Cc: Marcelo Tosatti <marcelo@conectiva.com.br>, Alan Cox <alan@lxorguk.ukuu.org.uk>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] 2.4: Restore current->files in flush_old_exec Date: Sat, 9 Aug 2003 05:01:50 +0200 (CEST) Message-ID: <Pine.LNX.4.53.0308090501090.18879@Chaos.suse.de> On Sat, 9 Aug 2003, Herbert Xu wrote: > On Sat, Aug 09, 2003 at 04:20:38AM +0200, Andreas Gruenbacher wrote: > > On Sat, 9 Aug 2003, Herbert Xu wrote: > > > > > On Sat, Aug 09, 2003 at 11:11:16AM +1000, herbert wrote: > > > > > > > > At this point, I believe the unshare_files stuff should be fine from > > > > a correctness point of view. However, there is still a performance > > > > problem as every ELF exec call ends up dupliating the files structure > > > > as well as walking through all file locks. > > > > > > Here is the patch that ensures files is only duplicated when necessary. > > > > This patch is correct but unnecessary: steal_locks already tests for this > > condition. > > Yes but when you call unshare_files twice one of them will have to > copy. I see---that happens through flush_old_exec. [-- Attachment #1.14: Type: message/rfc822, Size: 3796 bytes --] From: Herbert Xu <herbert@gondor.apana.org.au> Cc: Marcelo Tosatti <marcelo@conectiva.com.br>, Alan Cox <alan@lxorguk.ukuu.org.uk>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] 2.4: Restore current->files in flush_old_exec Date: Sat, 9 Aug 2003 12:53:11 +1000 Message-ID: <20030809025311.GB11777@gondor.apana.org.au> On Sat, Aug 09, 2003 at 04:20:38AM +0200, Andreas Gruenbacher wrote: > On Sat, 9 Aug 2003, Herbert Xu wrote: > > > On Sat, Aug 09, 2003 at 11:11:16AM +1000, herbert wrote: > > > > > > At this point, I believe the unshare_files stuff should be fine from > > > a correctness point of view. However, there is still a performance > > > problem as every ELF exec call ends up dupliating the files structure > > > as well as walking through all file locks. > > > > Here is the patch that ensures files is only duplicated when necessary. > > This patch is correct but unnecessary: steal_locks already tests for this > condition. Yes but when you call unshare_files twice one of them will have to copy. -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt [-- Attachment #1.15: Type: message/rfc822, Size: 3116 bytes --] From: Andreas Gruenbacher <agruen@suse.de> Cc: Marcelo Tosatti <marcelo@conectiva.com.br>, Alan Cox <alan@lxorguk.ukuu.org.uk>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] 2.4: Restore current->files in flush_old_exec Date: Sat, 9 Aug 2003 04:20:38 +0200 (CEST) Message-ID: <Pine.LNX.4.53.0308090418270.18879@Chaos.suse.de> On Sat, 9 Aug 2003, Herbert Xu wrote: > On Sat, Aug 09, 2003 at 11:11:16AM +1000, herbert wrote: > > > > At this point, I believe the unshare_files stuff should be fine from > > a correctness point of view. However, there is still a performance > > problem as every ELF exec call ends up dupliating the files structure > > as well as walking through all file locks. > > Here is the patch that ensures files is only duplicated when necessary. This patch is correct but unnecessary: steal_locks already tests for this condition. Cheers, Andreas. [-- Attachment #1.16: Type: message/rfc822, Size: 4673 bytes --] [-- Attachment #1.16.1.1: Type: text/plain, Size: 615 bytes --] On Sat, Aug 09, 2003 at 11:11:16AM +1000, herbert wrote: > > At this point, I believe the unshare_files stuff should be fine from > a correctness point of view. However, there is still a performance > problem as every ELF exec call ends up dupliating the files structure > as well as walking through all file locks. Here is the patch that ensures files is only duplicated when necessary. -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt [-- Attachment #1.16.1.2: p --] [-- Type: text/plain, Size: 1090 bytes --] --- kernel-source-2.4/fs/binfmt_elf.c.orig 2003-08-09 11:28:18.000000000 +1000 +++ kernel-source-2.4/fs/binfmt_elf.c 2003-08-09 11:32:13.000000000 +1000 @@ -480,6 +480,10 @@ files = current->files; /* Refcounted so ok */ if(unshare_files() < 0) goto out_free_ph; + if (files == current->files) { + put_files_struct(files); + files = NULL; + } /* exec will make our files private anyway, but for the a.out loader stuff we need to do it earlier */ @@ -602,8 +606,10 @@ goto out_free_dentry; /* Discard our unneeded old files struct */ - steal_locks(files, current->files); - put_files_struct(files); + if (files) { + steal_locks(files, current->files); + put_files_struct(files); + } /* OK, This is the point of no return */ current->mm->start_data = 0; @@ -811,9 +817,11 @@ out_free_file: sys_close(elf_exec_fileno); out_free_fh: - ftmp = current->files; - current->files = files; - put_files_struct(ftmp); + if (files) { + ftmp = current->files; + current->files = files; + put_files_struct(ftmp); + } out_free_ph: kfree(elf_phdata); goto out; [-- Attachment #1.17: Type: message/rfc822, Size: 4738 bytes --] [-- Attachment #1.17.1.1: Type: text/plain, Size: 614 bytes --] Hi: The unshare_files patch to flush_old_exec() did not restore the original state when exec_mmap fails. This patch fixes that. At this point, I believe the unshare_files stuff should be fine from a correctness point of view. However, there is still a performance problem as every ELF exec call ends up dupliating the files structure as well as walking through all file locks. Cheers, -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt [-- Attachment #1.17.1.2: q --] [-- Type: text/plain, Size: 1206 bytes --] Index: kernel-source-2.4/fs/exec.c =================================================================== RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.4/fs/exec.c,v retrieving revision 1.5 diff -u -r1.5 exec.c --- kernel-source-2.4/fs/exec.c 26 Jul 2003 02:54:45 -0000 1.5 +++ kernel-source-2.4/fs/exec.c 9 Aug 2003 01:00:28 -0000 @@ -557,7 +557,7 @@ char * name; int i, ch, retval; struct signal_struct * oldsig; - struct files_struct * files; + struct files_struct *files, *ftmp; /* * Make sure we have a private signal table @@ -576,8 +576,6 @@ retval = unshare_files(); if(retval) goto flush_failed; - steal_locks(files, current->files); - put_files_struct(files); /* * Release all of the old mmap stuff @@ -586,6 +584,8 @@ if (retval) goto mmap_failed; /* This is the point of no return */ + steal_locks(files, current->files); + put_files_struct(files); release_old_signals(oldsig); current->sas_ss_sp = current->sas_ss_size = 0; @@ -623,6 +623,9 @@ return 0; mmap_failed: + ftmp = current->files; + current->files = files; + put_files_struct(ftmp); flush_failed: spin_lock_irq(¤t->sigmask_lock); if (current->sig != oldsig) { [-- Attachment #1.18: Type: message/rfc822, Size: 4433 bytes --] [-- Attachment #1.18.1.1: Type: text/plain, Size: 772 bytes --] On Fri, Aug 08, 2003 at 08:53:21PM +1000, herbert wrote: > > The steal_locks() call in binfmt_elf.c is buggy. It steals locks from > a files entry whose reference was dropped much earlier. This allows it > to steal other process's locks. > > The following patch calls steal_locks() earlier so that this does not > happen. My patch is buggy too. If a file is closed by another clone between the two steal_locks calls the lock will again be lost. Fortunately this much harder to trigger than the previous bug. The following patch fixes that. -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt [-- Attachment #1.18.1.2: p --] [-- Type: text/plain, Size: 806 bytes --] --- kernel-source-2.4/fs/binfmt_elf.c.orig 2003-08-09 10:43:56.000000000 +1000 +++ kernel-source-2.4/fs/binfmt_elf.c 2003-08-09 10:57:29.000000000 +1000 @@ -480,7 +480,6 @@ files = current->files; /* Refcounted so ok */ if(unshare_files() < 0) goto out_free_ph; - steal_locks(files, current->files); /* exec will make our files private anyway, but for the a.out loader stuff we need to do it earlier */ @@ -603,6 +602,7 @@ goto out_free_dentry; /* Discard our unneeded old files struct */ + steal_locks(files, current->files); put_files_struct(files); /* OK, This is the point of no return */ @@ -813,7 +813,6 @@ out_free_fh: ftmp = current->files; current->files = files; - steal_locks(ftmp, current->files); put_files_struct(ftmp); out_free_ph: kfree(elf_phdata); [-- Attachment #1.19: Type: message/rfc822, Size: 3976 bytes --] [-- Attachment #1.19.1.1: Type: text/plain, Size: 492 bytes --] Hi: The steal_locks() call in binfmt_elf.c is buggy. It steals locks from a files entry whose reference was dropped much earlier. This allows it to steal other process's locks. The following patch calls steal_locks() earlier so that this does not happen. Cheers, -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt [-- Attachment #1.19.1.2: p --] [-- Type: text/plain, Size: 770 bytes --] --- kernel-source-2.4/fs/binfmt_elf.c.orig 2003-08-08 20:46:56.000000000 +1000 +++ kernel-source-2.4/fs/binfmt_elf.c 2003-08-08 20:47:05.000000000 +1000 @@ -480,6 +480,7 @@ files = current->files; /* Refcounted so ok */ if(unshare_files() < 0) goto out_free_ph; + steal_locks(files, current->files); /* exec will make our files private anyway, but for the a.out loader stuff we need to do it earlier */ @@ -797,7 +798,6 @@ if (current->ptrace & PT_PTRACED) send_sig(SIGTRAP, current, 0); retval = 0; - steal_locks(files, current->files); out: return retval; @@ -813,6 +813,7 @@ out_free_fh: ftmp = current->files; current->files = files; + steal_locks(ftmp, current->files); put_files_struct(ftmp); out_free_ph: kfree(elf_phdata); [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
reply other threads:[~2003-08-11 16:47 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030811204726.64e0926a.vsu@altlinux.ru \ --to=vsu@altlinux.ru \ --cc=devel-kernel@altlinux.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux kernel packages development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-kernel/0 devel-kernel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel-kernel devel-kernel/ http://lore.altlinux.org/devel-kernel \ devel-kernel@altlinux.org devel-kernel@altlinux.ru devel-kernel@altlinux.com public-inbox-index devel-kernel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git