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: <Pine.LNX.4.64.0706040743060.30836@alien.or.mcafeemobile.com>
Date:	Mon, 4 Jun 2007 07:53:55 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Eric Dumazet <dada1@...mosbay.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	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

On Mon, 4 Jun 2007, Eric Dumazet wrote:

> On Mon, 4 Jun 2007 06:35:16 -0700 (PDT)
> Davide Libenzi <davidel@...ilserver.org> wrote:
> 
> > On Mon, 4 Jun 2007, Eric Dumazet wrote:
> > 
> > > You add conditional branches on very hot spots.
> > 
> > Keep BS for the ones you argue usually, and that are not able to reply.
> > You *still* two bitmaps, because allocation spaces are far apart. So the 
> > "if" will still be there.
> 
> I actually read your patches and spent time to see the pros and cons.
> 
> If you dont need reviewers, please dont post your patches on lkml.

I *do like* reviews, and if you go back in all the reviews my code had 
during the last few months for example, you'll notice that I *almost always*
ACK the reviewers suggestions. I'm a believer that in computer science, 
there are many ways to do the same thing, and many of those are very close 
as far as pros&cons. So, if some reviewer suggests me something, I'm 
inclined to ACK it, even if the solution I wrote (or that I had in mind) 
was different.
In this case though, your solution and mine are *really* different. You 
are trying to fit a structure to a problem that is not meant to. And it is 
so clearly evident, that it blows my mind how this could even be argued.
As I said to Andrew, we can use fdmap for both allocations (fdmap already 
supports all the allocation modes the current fdtable does - modulo adding 
a bitmap), and cut a lot of code out.
This is the way I'm currently heading, so all the code from fs/file.c (256 
lines) can go. locate_fd will go. set_close_on_exec and get_close_on_exec 
will use the existing function in fdmap.c, etc...

> If I am not mistaken, you added a test in fget()/fget_light(), which is 
> a known hot point for said huge processes.

There is one "if", that you cannot avoid, since allocation areas are far 
apart (and one of them is even random). Unless you plan to have a single 
contiguous bitmap with *a lot* of wasted space in the middle.

- Davide

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