Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #91997

Re: fork/exec & close file descriptors

From Marko Rauhamaa <marko@pacujo.net>
Newsgroups comp.lang.python
Subject Re: fork/exec & close file descriptors
Date 2015-06-04 00:09 +0300
Organization A noiseless patient Spider
Message-ID <87vbf433es.fsf@elektro.pacujo.net> (permalink)
References (11 earlier) <mailman.104.1433336055.13271.python-list@python.org> <87wpzl3pnn.fsf@elektro.pacujo.net> <87oakw532a.fsf@elektro.pacujo.net> <87iob44zu9.fsf@elektro.pacujo.net> <mailman.125.1433362139.13271.python-list@python.org>

Show all headers | View raw


random832@fastmail.us:

> On Wed, Jun 3, 2015, at 10:43, Marko Rauhamaa wrote:
>> However, the child process needs to be prepared for os.close() to
>> block indefinitely because of an NFS problem or because SO_LINGER has
>> been specified by the parent, for example. Setting the close-on-exec
>> flag doesn't help there.
>
> Out of curiosity, does exec block in this situation?

I didn't try it, but it is apparent in the source code:

========================================================================
void do_close_on_exec(struct files_struct *files)
{
	unsigned i;
	struct fdtable *fdt;

	/* exec unshares first */
	spin_lock(&files->file_lock);
	for (i = 0; ; i++) {
		unsigned long set;
		unsigned fd = i * BITS_PER_LONG;
		fdt = files_fdtable(files);
		if (fd >= fdt->max_fds)
			break;
		set = fdt->close_on_exec[i];
		if (!set)
			continue;
		fdt->close_on_exec[i] = 0;
		for ( ; set ; fd++, set >>= 1) {
			struct file *file;
			if (!(set & 1))
				continue;
			file = fdt->fd[fd];
			if (!file)
				continue;
			rcu_assign_pointer(fdt->fd[fd], NULL);
			__put_unused_fd(files, fd);
			spin_unlock(&files->file_lock);
			filp_close(file, files);
			cond_resched();
			spin_lock(&files->file_lock);
		}

	}
	spin_unlock(&files->file_lock);
}

int filp_close(struct file *filp, fl_owner_t id)
{
	int retval = 0;

	if (!file_count(filp)) {
		printk(KERN_ERR "VFS: Close: file count is 0\n");
		return 0;
	}

	if (filp->f_op->flush)
		retval = filp->f_op->flush(filp, id);

	if (likely(!(filp->f_mode & FMODE_PATH))) {
		dnotify_flush(filp, id);
		locks_remove_posix(filp, id);
	}
	fput(filp);
	return retval;
}
========================================================================

Now, the kernel NFS code specifies a flush() method, which can block and
even fail.

Sockets don't have a flush() method. So closing a socket cannot fail.
However, fput(), which decrements the reference count, may block if
lingering has been specified for the socket.

So I wasn't all that wrong earlier after all: whoever closes a socket
last will linger. Thus, the parent (who wanted to linger) might zip
through closing a socket while the unwitting child process will suffer
the lingering delay before it gets to exec.

However, there's this comment in inet_release():

		/* [...]
		 * If the close is due to the process exiting, we never
		 * linger..
		 */


Marko

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: fork/exec & close file descriptors Skip Montanaro <skip.montanaro@gmail.com> - 2015-06-02 08:58 -0500
  Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-02 18:28 +0300
    Re: fork/exec & close file descriptors Skip Montanaro <skip.montanaro@gmail.com> - 2015-06-02 10:42 -0500
      Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-02 19:24 +0300
        Re: fork/exec & close file descriptors Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-02 16:37 +0000
    Re: fork/exec & close file descriptors MrJean1 <MrJean1@gmail.com> - 2015-06-12 13:43 -0700
  Re: fork/exec & close file descriptors Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2015-06-02 17:59 +0200
    Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-02 23:05 +0300
      Re: fork/exec & close file descriptors Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2015-06-02 23:06 +0200
        Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 01:24 +0300
          Re: fork/exec & close file descriptors Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2015-06-03 09:21 +0200
            Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 10:41 +0300
              Re: fork/exec & close file descriptors alister <alister.nospam.ware@ntlworld.com> - 2015-06-03 09:38 +0000
                Re: fork/exec & close file descriptors Steven D'Aprano <steve@pearwood.info> - 2015-06-03 22:07 +1000
                Re: fork/exec & close file descriptors alister <alister.nospam.ware@ntlworld.com> - 2015-06-03 12:18 +0000
                Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 15:27 +0300
                Re: fork/exec & close file descriptors alister <alister.nospam.ware@ntlworld.com> - 2015-06-03 13:05 +0000
                Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 17:49 +0300
                Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 15:25 +0300
                Re: fork/exec & close file descriptors random832@fastmail.us - 2015-06-03 08:54 -0400
                Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 16:08 +0300
                Re: fork/exec & close file descriptors random832@fastmail.us - 2015-06-03 09:21 -0400
                Re: fork/exec & close file descriptors Chris Angelico <rosuav@gmail.com> - 2015-06-03 23:32 +1000
                Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 16:33 +0300
                Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 17:43 +0300
                Re: fork/exec & close file descriptors random832@fastmail.us - 2015-06-03 16:08 -0400
                Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-04 00:09 +0300
                Re: fork/exec & close file descriptors random832@fastmail.us - 2015-06-03 16:07 -0400
                Re: fork/exec & close file descriptors Chris Angelico <rosuav@gmail.com> - 2015-06-04 07:54 +1000
        Re: fork/exec & close file descriptors Chris Angelico <rosuav@gmail.com> - 2015-06-03 09:54 +1000
          Re: fork/exec & close file descriptors Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2015-06-03 09:11 +0200
            Re: fork/exec & close file descriptors random832@fastmail.us - 2015-06-03 08:21 -0400
              Re: fork/exec & close file descriptors Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2015-06-03 15:16 +0200
        Re: fork/exec & close file descriptors Skip Montanaro <skip.montanaro@gmail.com> - 2015-06-02 20:21 -0500

csiph-web