linux-kernel - Re: [PATCH 3/3] exec: Allow do_coredump to wait for user space pipe readers to complete (v4)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090701055151.GB26877@redhat.com>
Date:	Wed, 1 Jul 2009 07:52:57 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Neil Horman <nhorman@...driver.com>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	earl_chew@...lent.com, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH 3/3] exec: Allow do_coredump to wait for user space
	pipe readers to complete (v4)

On 06/30, Neil Horman wrote:
>
>  void do_coredump(long signr, int exit_code, struct pt_regs *regs)
>  {
>  	struct core_state core_state;
>  	char corename[CORENAME_MAX_SIZE + 1];
>  	struct mm_struct *mm = current->mm;
>  	struct linux_binfmt * binfmt;
> -	struct inode * inode;
> -	struct file * file;
> +	struct inode * inode = NULL;
> +	struct file * file = NULL;

why this change?

> @@ -1824,6 +1860,17 @@ void do_coredump(long signr, int exit_code, struct pt_regs *regs)
>  			       corename);
>   			goto fail_dropcount;
>   		}
> +
> +		/*
> +		 * This lets us wait on a pipe after we close the writing
> +		 * end.  The extra reader count prevents the pipe_inode_info
> +		 * from getting freed.

but it can't be freed until we close file?

> This extra count is reclaimed in
> +		 * wait_for_dump_helpers
> +		 */
> +		pipe = file->f_path.dentry->d_inode->i_pipe;
> +		pipe_lock(pipe);
> +		pipe->readers++;
> +		pipe_unlock(pipe);

why should we inc ->readers in advance?

> +	wait_for_dump_helpers(file);

why do we call it unconditionally and then check ISFIFO? We only need to wait
when ispipe = T, and in that case we know that this file is pipe.

IOW, could you explain why the (much simpler) patch I sent doesn't work ?


Hmm. And in fact that pipe->readers++ above doesn't look right. What if
the core_patter task exits? Since we incremented ->readers we can't notice
the fact there are no readers, and f_op->write() will hang forever.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/