linux-kernel - Re: [patch 1/2] ufd v1 - unsequential O(1) fdmap core

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: <20070604084227.GA29446@elte.hu>
Date:	Mon, 4 Jun 2007 10:42:27 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Davide Libenzi <davidel@...ilserver.org>,
	Eric Dumazet <dada1@...mosbay.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ulrich Drepper <drepper@...hat.com>
Subject: Re: [patch 1/2] ufd v1 - unsequential O(1) fdmap core

* Andrew Morton <akpm@...ux-foundation.org> wrote:

> If we just want some pseudo-private fd space for glibc to use then I'd 
> have thought that the existing code could be tweaked to do that: 
> top-down allocation, start at some high offset, etc.  But apparently 
> there's more to it than this.

top-down has the problem of rlimits: 'where is top' is a variable 
notion.

start-at-high-offset using the existing scheme has a 'bitmap size' 
problem: even at 2^28 the bitmap size would be 32+ MB. per process (!). 
The bitmap could be allocated on demand, but that slows down the current 
code, uglifies it, and it would still end up somewhere looking a bit 
like Davide's clean new code.

so, instead of trying to mesh this thing into the old fd data structures 
which are very much centered around and tailored to the 
continuous-allocation usage model, Davide cleanly separated it out into 
a separate data structure that fits this independently-allocated usage 
model well and leaves the original data structure alone. I'm strongly in 
favor of such clean data structure separations.

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