public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Jaeger <aj@suse.de>
To: Wolfram Gloger <wg@malloc.de>
Cc: kaz@ashi.footprints.net, brianmc1@us.ibm.com,
	libc-alpha@sources.redhat.com, linux-kernel@vger.kernel.org
Subject: Re: SMP-ix86-threads-fork: Linux 2.4.x kernel problem identified [phantom read()]
Date: Tue, 11 Sep 2001 09:31:56 +0200	[thread overview]
Message-ID: <ho1yletc7n.fsf@gee.suse.de> (raw)
In-Reply-To: <Pine.LNX.4.33.0109100931190.20444-100000@ashi.FootPrints.net> <E15gZyh-00074n-00@mrvdom04.kundenserver.de>
In-Reply-To: <E15gZyh-00074n-00@mrvdom04.kundenserver.de> (Wolfram Gloger's message of "Tue, 11 Sep 2001 00:56:31 +0200")

Wolfram Gloger <wg@malloc.de> writes:

> Hi,
>
>> So it's perfectly possible to observe the behavior you are seeing
>> if __libc_read() returns -1. Because then sz_read will acquire the
>> value -1, and the guard expresssion sz_read < sizeof(request) will yield
>> zero, terminating the loop.
>
> Argh!  That indeed seems to be the case, _no_ apparent kernel problem
> is involved, sorry for the false alarm.  read() 'just' returns -1 with
> errno becoming EINTR.  One should never code up a loop like that in
> the last minute (I only found the effect yesterday)..
>
>> Could you recode the test patch to eliminate these suspicions and re-test?
>
> The analysis was nevertheless correct, LinuxThreads gets out of synch
> with disastrous effects.  I was puzzled how read() could return -1,
> however it may make sense with a __pthread_sig_cancel pending in the
> manager thread due to a child exiting (?).  But then, why wasn't this
> possibility discovered before?

Because we never compiled with -DDEBUG so that the ASSERT was
triggered?

There's another such place (line 135) with __libc_read in
__pthread_manager:

  /* Synchronize debugging of the thread manager */
  n = __libc_read(reqfd, (char *)&request, sizeof(request));
  ASSERT(n == sizeof(request) && request.req_kind == REQ_DEBUG);

We should account for a return value of -1 here also, shouldn't we?

> Below is a corrected patch for glibc-2.2.4.  I've run fork-malloc with
> this for a couple of hours.

Is it still running? ;-)  That would be excellent!

Thanks a lot Wolfram,
Andreas

> Thanks,
> Wolfram.
>
> 2001-09-11  Wolfram Gloger  <wg@malloc.de>
>
> 	* manager.c (__pthread_manager): When reading from pipe. account
> 	for possible error return from read().
>
> --- linuxthreads/manager.c.orig	Mon Jul 23 19:54:13 2001
> +++ linuxthreads/manager.c	Tue Sep 11 00:47:48 2001
> @@ -150,8 +150,19 @@
>      }
>      /* Read and execute request */
>      if (n == 1 && (ufd.revents & POLLIN)) {
> -      n = __libc_read(reqfd, (char *)&request, sizeof(request));
> -      ASSERT(n == sizeof(request));
> +      int sz_read = 0;
> +
> +      while (sz_read < sizeof(request)) {
> +	n = __libc_read(reqfd, (char *)&request + sz_read,
> +			sizeof(request) - sz_read);
> +	if (n < 0) {
> +#ifdef DEBUG
> +	  char d[64];
> +	  sprintf(d, "*** read err %d\n", errno);
> +#endif
> +	} else
> +	  sz_read += n;
> +      }
>        switch(request.req_kind) {
>        case REQ_CREATE:
>          request.req_thread->p_retcode =
>

-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

      reply	other threads:[~2001-09-11  7:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-10 15:18 SMP-ix86-threads-fork: Linux 2.4.x kernel problem identified [phantom read()] Wolfram Gloger
2001-09-10 16:42 ` Kaz Kylheku
2001-09-10 22:56   ` Wolfram Gloger
2001-09-11  7:31     ` Andreas Jaeger [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=ho1yletc7n.fsf@gee.suse.de \
    --to=aj@suse.de \
    --cc=brianmc1@us.ibm.com \
    --cc=kaz@ashi.footprints.net \
    --cc=libc-alpha@sources.redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wg@malloc.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox