linux-kernel - Re: [PATCH v2 0/7] CLONE_FD: Task exit notification via file descriptor

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150331220807.6927e780@lwn.net>
Date:	Tue, 31 Mar 2015 22:08:07 +0200
From:	Jonathan Corbet <corbet@....net>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Kees Cook <keescook@...omium.org>,
	Oleg Nesterov <oleg@...hat.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	"H. Peter Anvin" <hpa@...or.com>, Rik van Riel <riel@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	Thiago Macieira <thiago.macieira@...el.com>,
	linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH v2 0/7] CLONE_FD: Task exit notification via file
 descriptor

So I finally got around to having a look at this, and one thing caught my
eye:

>              read(2) (and similar)
>                      When  the  new  process  exits,  reading  from  the  file
>                      descriptor produces a single clonefd_info structure:
> 
>                      struct clonefd_info {
>                          uint32_t code;   /* Signal code */
>                          uint32_t status; /* Exit status or signal */
>                          uint64_t utime;  /* User CPU time */
>                          uint64_t stime;  /* System CPU time */
>                      };

This would appear to assume that a clonefd_info structure is the only
thing that will ever be read from this descriptor.  It seems to me that
there is the potential for, someday, wanting to be able to read and write
other things as well.  Should this structure be marked with type and
length fields so that other structures could be added in the future?

(I suppose we could just use ioctl() for any other functionality in the
future, though...:)

jon
--
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/