On Wed, Mar 04, 2009 at 09:51:28PM +0100, Oleg Nesterov wrote: > On 03/04, Andrew Morton wrote: > > > > From: Oleg Nesterov <oleg@xxxxxxxxxx> > > > > If the second fasync_helper() fails, pipe_rdwr_fasync() returns the error > > but leaves the file on ->fasync_readers. > > > > This was always wrong, but since 233e70f4228e78eb2f80dc6650f65d3ae3dbf17c > > "saner FASYNC handling on file close" we have the new problem. Because in > > this case setfl() doesn't set FASYNC bit, __fput() will not do > > ->fasync(0), and we leak fasync_struct with ->fa_file pointing to the > > freed file. > > > > Signed-off-by: Oleg Nesterov <oleg@xxxxxxxxxx> > > Cc: Al Viro <viro@xxxxxxxxxxxxxxxxxx> > > Cc: Andi Kleen <andi@xxxxxxxxxxxxxx> > > Cc: Jonathan Corbet <corbet@xxxxxxx> > > Cc: <stable@xxxxxxxxxx> [2.6.28.x] > > Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > > Just in case... > > This bug is minor. fasync_helper() can only fail if > kmem_cache_alloc(fasync_cache, GFP_KERNEL) fails, this should "never" happen. > > Perhaps -stable doesn't need this fix. Can't hurt, right? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
