All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Alexander Kanavin <alexander.kanavin@linux.intel.com>,
	Trevor Woerner <twoerner@gmail.com>,
	seebs@seebs.net
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: long (never ending?) do_install for adwaita-icon-theme
Date: Mon, 28 Aug 2017 17:22:32 +0100	[thread overview]
Message-ID: <1503937352.32591.292.camel@linuxfoundation.org> (raw)
In-Reply-To: <ce197f69-4a7a-3df6-c860-4433e97ab583@linux.intel.com>

On Mon, 2017-08-28 at 18:27 +0300, Alexander Kanavin wrote:
> On 08/28/2017 06:14 PM, Alexander Kanavin wrote:
> > 
> > On 08/28/2017 05:43 PM, Richard Purdie wrote:
> > 
> > > 
> > > The bitfield operation that says "can I read this fd?" probably
> > > overflows into the next data item in the structure (I haven't
> > > checked
> > > exactly how it fails). It may be "set", certainly the case I
> > > debugged
> > > had to have thought it was and the code thinks "fd 1025 is ready
> > > for
> > > reading" when in fact it may not be. The code then calls read()
> > > on it
> > > and if it wasn't ready for reading, it would block.
> > Right; what I am getting at is that we might have a bug here 
> > (specifically the absence of check against FD_SETSIZE), rather
> > than 
> > something that needs to be solved by switching to poll().
> > 
> > Does the code use that constant anywhere?
> 
>
> Actually, wait: "Executing FD_CLR() or FD_SET() with a value of fd
> that is negative or is equal to or larger than FD_SETSIZE will result
> in undefined behavior." (man select)
> 
> This means that select() cannot be used with fd >= FD_SETSIZE at all?

Correct. The code has no guards on this happening.

Cheers,

Richard


  reply	other threads:[~2017-08-28 16:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-22 17:32 long (never ending?) do_install for adwaita-icon-theme Trevor Woerner
2017-08-22 17:40 ` Richard Purdie
2017-08-22 18:01   ` Alexander Kanavin
2017-08-22 18:46     ` Trevor Woerner
     [not found]       ` <e165f760-1c1e-1a5f-2fba-f8c293a16278@intel.com>
2017-08-23 12:48         ` Alexander Kanavin
2017-08-27 16:01         ` Richard Purdie
2017-08-27 16:07           ` Richard Purdie
2017-08-28 10:38             ` Alexander Kanavin
2017-08-28 14:43               ` Richard Purdie
2017-08-28 15:14                 ` Alexander Kanavin
2017-08-28 15:27                   ` Alexander Kanavin
2017-08-28 16:22                     ` Richard Purdie [this message]
2017-08-28 17:53             ` Khem Raj

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=1503937352.32591.292.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=alexander.kanavin@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=seebs@seebs.net \
    --cc=twoerner@gmail.com \
    /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.