linux-kernel - Re: [patch 1/8] fdmap v2

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]

Date:	Thu, 07 Jun 2007 08:54:15 +0200
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Davide Libenzi <davidel@...ilserver.org>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ulrich Drepper <drepper@...hat.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [patch 1/8] fdmap v2 - fdmap core

Davide Libenzi a écrit :
 > Core code for the fdmap implementation. Random allocation, exact allocation,
 > de-allocation and lookup are all O(1) operations. It also support the "legacy"
 > sequential (compact) file descriptor allocation, that is O(N) like the old
 > fdtable implementation.
 > Like the old "struct fdtable", fdmap is RCU friendly too.
 >

Hi Davide

I just took a 10 minutes look before running away this morning, I'll try to 
test this to get performance numbers in about 12 hours.



> + */
> +int fdmap_newfd_seq(struct fd_map *fmap, unsigned int start,
> +		    unsigned int limit, unsigned long flags)
> +{
> +	int fd;
> +
> +	if (unlikely(start))
> +		start = start - fmap->base;
> +	if (likely(start < fmap->fdnext))
> +		start = fmap->fdnext;
> +	fd = find_next_zero_bit(fmap->map, fmap->size, start);
> +	if (unlikely(fd >= limit))
> +		return -EMFILE;
> +	if (unlikely(fd >= fmap->size))
> +		return -ENOSPC;

> +	fmap->fdnext = fd + 1;

Here you broke POSIX I'm afraid.

You might need some test like

     if (start <= fmap->fdnext)
         fmap->fdnext = fd + 1;

Also I'm not sure the first unlikely() and likely() are worth it.

They probably match the user code you wrote yourself :)

Best thing is probably let the compiler generate a 50/50 code and let CPU uses 
its predictors.


> +
> +	return fdmap_alloc_tail(fmap, fd, flags);
> +}

/*
  * untested prog
  * should not fail if/when (ulimit -n 1024)
  */
#include <fcntl.h>
int main()
{
int highfd = fcntl(0, F_DUPFD, 1023);
int fd = open("/dev/null", O_RDONLY);
if (fd == -1) {
     perror("open /dev/null");
     return 1;
     }
return 0;
}
-
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/