linux-kernel - Re: PID entries in /proc sorted by number, not start time in 2.6.19

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: <m1irdlg8cg.fsf@ebiederm.dsl.xmission.com>
Date:	Wed, 28 Feb 2007 16:39:43 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Chuck Ebbert <cebbert@...hat.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Albert Cahalan <acahalan@...il.com>
Subject: Re: PID entries in /proc sorted by number, not start time in 2.6.19

Chuck Ebbert <cebbert@...hat.com> writes:

> Starting with kernel 2.6.19, the process directories in
> /proc are sorted by number. They were sorted by process
> start time in 2.6.18 and earlier. This makes the output
> of procps come out in that order too, pissing off users
> who are used to the old way.
>
> To reproduce:
> 	1. Wrap your PID numbers.
> 	2. Do ls -fl /proc
> 	3. Look at output of ps command.
>
> Compare 2.6.18 to 2.6.19.
>
> See also:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230227

Apologies, but this was a bug fix for a more serious issue.  The code
to report the directory entries by start time was fundamentally broken.
In particular the sequence:
opendir
readdir
readdir
readdir
....
closedir

can miss processes that exist for the entire duration of that
sequence.  Which is non-posix, non-intuitive, and has no reasonable
work around.

The sorting by pid happened as a side effect of finding a stable token
we can come back to so we can at least guarantee normal readdir
semantics.  That objects that exist for the entire readdir are
guaranteed to be displayed.  That objects that come into existence or
are deleted during the readdir may be missed.  That isn't perfect but
it is a useable semantic. 

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