linux-kernel - Re: [PATCH] nextfd(2)

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

Message-ID: <20120430095835.GF51635@netch.kiev.ua>
Date:	Mon, 30 Apr 2012 12:58:35 +0300
From:	Valentin Nechayev <netch@...ch.kiev.ua>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"H. Peter Anvin" <hpa@...or.com>
Cc:	Alexey Dobriyan <adobriyan@...il.com>, akpm@...ux-foundation.org,
	viro@...iv.linux.org.uk, torvalds@...ux-foundation.org,
	drepper@...il.com, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] nextfd(2)

 Sun, Apr 01, 2012 at 15:13:31, hpa wrote about "Re: [PATCH] nextfd(2)": 

> - There is a huge backwards compatibility problem with this for a
> substantial transition period; using /proc/self/fd has worked for a very
> long time already.
> 
> - Your nextfd() system call will require more system calls that the
> typical case for reading /proc/self/fd, because each getdents() system
> call handles multiple readdir() invocations.

First, your forecast is very doubtfully correct in typical case when a
process checks extra descriptors to close; seeing tools like sendmail
shows that typically the all this long cycle does no work. So, it will
reduce to one nextfd() which returns final error, instead of
open()+getdents()+close().

Second, the principal advantage of nextfd() approach that it doesn't
consumer additional resources for its work, compared with open() which
allocates yet another descriptor. So, it could fail unpredictably.

Typical Unix-like system has at least four kinds of critical resources;
"critical" means here that they could be requested even in case of
lack of such resource, to provide a kind of graceful shutdown. They
are virtual memory, file descriptors, threads and disk space, all
possibly limited per-system, per-user or per-process. The current lack
of a measure to provide work when a resource is exhausted gives only
one possible reaction - to die immediately; this is now typical
reaction to memory allocation failure. I'm already sick of seeing
a language runtime which crash with messages like "cannot allocate
500M" when doing GC; this isn't single example but common approach of
such a devil-may-care attitude to application stability.

It isn't hard to expand the current approach in two ways: 1) allowing
to allocate reserve pool which will be then used by compating or
shutdown actions; 2) making actions which are typical on such
compacting using minimum of resources, even with some loss of
uniformity, API orthogonality and simplicity. Yep, this way is long
and can spend decades - more long than /proc existence - but it is
good to achieve.

Seems all this was in mind of Alexey Dobriyan when he proposed
nextfd(); maybe not with the same level of details, but in general.

 Mon, Apr 02, 2012 at 01:08:19, alan wrote about "Re: [PATCH] nextfd(2)": 

> If I've rlimited you to no file handles then you already lost whichever
> approach you use. Just abort.

Well, this is the good illustration to my words. In real work I don't
want to use the world when abort() is not simply the only case for
complicated state, but the suggestion. My software isn't
samurai-inspired kamikaze.

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