linux-kernel - Re: [take2 1/4] kevent: core files.

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:	Wed, 2 Aug 2006 10:43:51 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	David Miller <davem@...emloft.net>
Cc:	zach.brown@...cle.com, linux-kernel@...r.kernel.org,
	drepper@...hat.com, netdev@...r.kernel.org
Subject: Re: [take2 1/4] kevent: core files.

On Tue, Aug 01, 2006 at 05:01:38PM -0700, David Miller (davem@...emloft.net) wrote:
> From: Zach Brown <zach.brown@...cle.com>
> Date: Tue, 01 Aug 2006 16:56:59 -0700
> 
> > Even if we only have one syscall with a cmd multiplexer (which I'm not
> > thrilled with), we should at least make these arguments explicit in the
> > system call.  It's weird to hide them in a struct.  We could also think
> > about making them u32 or u64 so that we don't need compat wrappers, but
> > maybe that's overkill.
> 
> I think making the userspace data structure not require any compat
> handling is a must, thanks for pointing this out Zach.

It does not require compat macros, since unsigned int has the same size
on all normal machines where Linux runs, although it can be different.
Anyway, I will replace it with explicit syscall parameters.

> > It'd be great if these struct members could get a prefix (ala: inode ->
> > i_, socket -> sk_) so that it's less painful getting tags helpers to
> > look up instances for us.  Asking for 'lock' is hilarious.
> 
> Agreed.

Heh, it was so much less typing...

> > Hmm.  I think the current preference is not to have a lock per bucket.
> 
> Yes, it loses badly, that's why we undid this in the routing cache
> and just have a fixed sized array of locks which is hashed into.
> 
> For kevents, I think a single spinlock initially is fine and
> if we hit performance problems on SMP we can fix it.  We should
> not implement complexity we have no proof of needing yet :)

Ok, let's see how it will behave.

> > > +#define KEVENT_MAX_REQUESTS		PAGE_SIZE/sizeof(struct kevent)
> > 
> > This is unused?
> 
> It is probably groundwork for the mmap() ring buffer... :)

A lot of work, isn't it? :)

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