All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] creat05: count opened fds
Date: Tue, 17 May 2016 10:34:43 -0400 (EDT)	[thread overview]
Message-ID: <945685507.3524681.1463495683812.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20160517141906.GG12051@rei.lan>





----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it
> Sent: Tuesday, 17 May, 2016 4:19:06 PM
> Subject: Re: [PATCH] creat05: count opened fds
> 
> Hi!
> > This testcase estimates number of opened fds by opening
> > a new one and assuming there are no gaps. This doesn't always
> > hold true. There can be gaps if test harness that runs it
> > opens couple fds with O_CLOEXEC prior to starting creat05.
> > As result, testcase unexpectedly fails in setup.
> 
> As far as I understand it the O_CLOEXEC is not the problem here. It may
> be reproduced even without it when the test harness leaves an open fd
> after some open one, right?

Agreed, that is also one way to get "gap".

> 
> Something as:
> 
> fd0 = open("foo", ...);
> fd1 = open("bar", ...);
> close(fd0);
> fork();
> if (!pid)
> 	exec("creat05");
> 
> 
> And in that case the testcase can do even without listing the
> /proc/self/fd. Since POSIX specifies that we get the smallest unused fd
> for each creat() we can just call it in a loop until the resulting
> fd == max_fd - 1.

We could do that. It's quite unlikely that fd would be already in use.
I'll send v2 with this change.

Regards,
Jan

> We would have to allocate the array to store the fds
> so that we can close them in cleanup though.
> 
> --
> Cyril Hrubis
> chrubis@suse.cz
> 

      reply	other threads:[~2016-05-17 14:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-17 13:16 [LTP] [PATCH] creat05: count opened fds Jan Stancek
2016-05-17 14:19 ` Cyril Hrubis
2016-05-17 14:34   ` Jan Stancek [this message]

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=945685507.3524681.1463495683812.JavaMail.zimbra@redhat.com \
    --to=jstancek@redhat.com \
    --cc=ltp@lists.linux.it \
    /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.