All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Seebs <seebs@seebs.net>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] pseudo: update to latest master
Date: Mon, 19 Feb 2018 20:01:31 +0100	[thread overview]
Message-ID: <CA+chaQd2-perimm0_Eey85TTniWx9BE5KJMAO69PveyBB9vQEQ@mail.gmail.com> (raw)
In-Reply-To: <20180219115538.5081767b@seebsdell>

[-- Attachment #1: Type: text/plain, Size: 2433 bytes --]

I've bumped SRCREV to include your latest fix and re-enabled epoll and now
it doesn't get stuck for me, thanks!

I did quick check for UID/GID issue:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434

without epoll disabled and SRCREV "b6a015a Handle O_TMPFILE more better" it
was still reproducible, now I'm testing with epoll enabled and latest
SRCREV "f3f4459 Epoll: use the correct client"

Regards,


On Mon, Feb 19, 2018 at 6:55 PM, Seebs <seebs@seebs.net> wrote:

> On Mon, 19 Feb 2018 11:27:56 +0200
> Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:
>
> > > Huh. It's possible that the initial "don't try to close fd 0" was
> > > correct, and the real problem is that the attempt is getting made
> > > mistakenly. I'll study that more; the epoll code was a contribution
> > > and I may not have fully understood it.
> >
> > To be honest, it would have been better to apply my epoll patch as it
> > is, and then do additional modifications as separate commits. That
> > would make it simpler to isolate the issue. We've used my epoll patch
> > for many months without problems on the autobuilder and elsewhere.
>
> ... Wow, you know, now that you *mention* it, that is a really good
> idea. *sigh* Sorry about that.
>
> Hmm.
>
> > if (clients[events[i].data.u64].fd == listen_fd) {
>
> Just a sanity-check: Should this be equivalent to:
>     if (events[[i].data.u64 == 0)
> ?
>
> The reason I ask is that, looking at the code, we should never, ever,
> be getting into close_client(0). The "<=" check was right.
>
> The only call to close_client anywhere in the epoll case is:
>
> > } else {
> >       int n = 0;
> >       ioctl(clients[i].fd, FIONREAD, &n);
> >       if (n == 0) {
> >               close_client(i);
> >       } else {
> >               serve_client(i);
> >       }
>
> And that's the else for clients... oh hey
>
>
> > if (clients[events[i].data.u64].fd == listen_fd) {
> ...
> > ioctl(clients[i].fd, FIONREAD, &n);
>
> do you see the error? I do.
>
> This gets back to "and one of the problems with testing is that
> if I don't actually check the logs, I often don't see problems",
> because pseudo does enough internal disaster recovery that things can
> explode horribly without observable failures.
>
> Now extracting the data.u64 value and using that consistently as the
> index. Pushed fix to master.
>
> -s
>

[-- Attachment #2: Type: text/html, Size: 3412 bytes --]

  parent reply	other threads:[~2018-02-19 19:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-16  9:56 [PATCH] pseudo: update to latest master Alexander Kanavin
2018-02-16 16:55 ` Martin Jansa
2018-02-16 17:26   ` Alexander Kanavin
2018-02-16 17:51   ` Seebs
2018-02-16 19:11     ` Martin Jansa
2018-02-16 19:25       ` Seebs
2018-02-17 11:22         ` Alexander Kanavin
2018-02-17 11:56           ` Martin Jansa
2018-02-17 12:03             ` Martin Jansa
2018-02-17 13:28               ` Alexander Kanavin
2018-02-17 20:17                 ` Seebs
2018-02-18 11:43                   ` Martin Jansa
2018-02-18 20:23                     ` Martin Jansa
2018-02-19  9:38                       ` Alexander Kanavin
2018-02-19  9:27                   ` Alexander Kanavin
2018-02-19 17:55                     ` Seebs
2018-02-19 18:37                       ` Alexander Kanavin
2018-02-19 19:01                       ` Martin Jansa [this message]
2018-02-19 19:36                         ` Seebs
2018-03-01 13:53 Alexander Kanavin
2018-03-01 15:06 ` Seebs

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=CA+chaQd2-perimm0_Eey85TTniWx9BE5KJMAO69PveyBB9vQEQ@mail.gmail.com \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=seebs@seebs.net \
    /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.