linux-kernel - waitid() return value strangeness when infop is NULL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <cfd18e0f0901131438n232ba114n27ea2d7964d071de@mail.gmail.com>
Date:	Wed, 14 Jan 2009 11:38:18 +1300
From:	"Michael Kerrisk" <mtk.manpages@...glemail.com>
To:	"Roland McGrath" <roland@...hat.com>
Cc:	"kernel list" <linux-kernel@...r.kernel.org>,
	"Ulrich Drepper" <drepper@...hat.com>,
	"Vegard Nossum" <vegard.nossum@...il.com>,
	"linux-man@...r.kernel.org" <linux-man@...r.kernel.org>
Subject: waitid() return value strangeness when infop is NULL

[Resend with right LKML address.]

Hello Roland,

Vegard sent me a report of a possible bug in the waitid(2) man page,
but on closer examination, the issue seems to be in the waitid()
system call.

POSIX.1 says of waitid():

  RETURN VALUE
      If WNOHANG was specified and there are no children to wait for,
      0 shall be returned. If waitid() returns due to the  change  of
      state  of  one of its children, 0 shall be returned. Otherwise,
      -1 shall be returned and errno set to indicate the error.

The Linux waitid() follows this behavior, as long as infop is not
NULL, which is what POSIX requires:

      The  application shall ensure that the infop argument points to
      a siginfo_t structure.

However, Linux's waitid() does permit infop to be NULL.  But in this
case, a successful call returns the PID of the waited-for child.
Thinking about it, I suppose there is a rationale for doing this,
since otherwise the caller of waitid() has no way of obtaining the PID
of the waited-for child.  Anyway, this behavior should either be
documented, or "fixed" (i.e., change waitid() to return 0 on success
even if infop is NULL).  So, some questions:

a) Is it intentional to support the infop==NULL case for waitid() --
rather than simply giving an error return?

b) If so, what is the rationale for supporting this feature?

c) If the the answer a) is "yes", is it intentional for
waitid(idtype,id,NULL,options) to return the PID of the child, rather
than returning 0?

I'll post a test program in a follow-up message.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/