All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bernd Schmidt <bernds_cb1@t-online.de>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, torvalds@osdl.org,
	luke.yang@analog.com, gerg@snapgear.com
Subject: Re: Please revert git commit 1ad3dcc0
Date: Tue, 16 May 2006 16:29:03 +0200	[thread overview]
Message-ID: <4469E1AF.7040908@t-online.de> (raw)
In-Reply-To: <20060516065848.13028f9f.akpm@osdl.org>

Andrew Morton wrote:
> Bernd Schmidt <bernds_cb1@t-online.de> wrote:
>> please revert 1ad3dcc0.  That was a patch to the binfmt_flat loader, 
>> which was motivated by an LTP testcase which checks that execve returns 
>> EMFILE when the file descriptor table is full.
>>
>> The patch is buggy: the code now keeps file descriptors open for the 
>> executable and its libraries, which has confused at least one 
>> application.  It's also unnecessary, since there is no code that uses 
>> the file descriptor, so the new EMFILE error return is totally artificial.

> I don't get it.  The substance of the patch is
> 
> +	/* check file descriptor */
> +	exec_fileno = get_unused_fd();
> +	if (exec_fileno < 0) {
> +		ret = -EMFILE;
> +		goto err;
> +	}
> +	get_file(bprm->file);
> +	fd_install(exec_fileno, bprm->file);
> 
> and that get_file() will be undone by exit().  Without this change we'll
> forget to do file limit checking.

It's not the get_file that's the problem, it's the get_unused_fd and 
fd_install.  These files are now open while the process lives and 
consume file descriptors.  This does not happen with the ELF loader, 
which does

         if (interpreter_type != INTERPRETER_AOUT)
                 sys_close(elf_exec_fileno);

before transferring control to the application.  So, fewer file 
descriptors are available for the app, and they start at a higher number.

Before the change, we didn't allocate or install a file descriptor, 
hence there wasn't any reason to return EMFILE.  The spec at
   http://www.opengroup.org/onlinepubs/009695399/functions/exec.html
doesn't list EMFILE as a possible error.

If you're unconvinced, then at the very least we need to add a sys_close 
call in the success path.


Bernd

  reply	other threads:[~2006-05-16 14:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-16 11:23 Please revert git commit 1ad3dcc0 Bernd Schmidt
2006-05-16 13:58 ` Andrew Morton
2006-05-16 14:29   ` Bernd Schmidt [this message]
2006-05-16 14:50     ` Andrew Morton
2006-05-16 14:57       ` Bernd Schmidt
2006-05-16 14:54     ` Linus Torvalds
2006-05-16 15:10       ` Bernd Schmidt

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=4469E1AF.7040908@t-online.de \
    --to=bernds_cb1@t-online.de \
    --cc=akpm@osdl.org \
    --cc=gerg@snapgear.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luke.yang@analog.com \
    --cc=torvalds@osdl.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.