linux-kernel - Re: [RFC 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]

Message-ID: <20060725062625.GA29242@2ka.mipt.ru>
Date:	Tue, 25 Jul 2006 10:26:29 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	David Miller <davem@...emloft.net>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [RFC 1/4] kevent: core files.

On Mon, Jul 24, 2006 at 11:17:08PM -0700, David Miller (davem@...emloft.net) wrote:
> From: Evgeniy Polyakov <johnpol@....mipt.ru>
> Date: Sun, 9 Jul 2006 17:24:46 +0400
> 
> > This patch includes core kevent files:
> >  - userspace controlling
> >  - kernelspace interfaces
> >  - initialisation
> >  - notification state machines
> > 
> > It might also inlclude parts from other subsystem (like network related
> > syscalls so it is possible that it will not compile without other
> > patches applied).
> > 
> > Signed-off-by: Evgeniy Polyakov <johnpol@....mipt.ru>
> 
> I like this work a lot, as I've stated before.  The data structures
> look like they will scale well and it takes care of all the limitations
> that networking in particular seems to have in this area.
> 
> I have to say that the user API is not the nicest in the world.  Yet,
> at the same time, I cannot think of a better one :)

Hi David. I see you have a day of backlog mails processing :)

> Please, remove some grot such as this:
> 
> > +	if (kevent_cache)
> > +		k = kmem_cache_alloc(kevent_cache, mask);
> > +	else
> > +		k = kzalloc(sizeof(struct kevent), mask);
>  ...
> > +	if (kevent_cache)
> > +		kmem_cache_free(kevent_cache, k);
> > +	else
> > +		kfree(k);
> 
> Instead, make this:
> 
> > +	kevent_cache = kmem_cache_create("kevent_cache", 
> > +			sizeof(struct kevent), 0, 0, NULL, NULL);
> > +	if (!kevent_cache)
> > +		err = -ENOMEM;
> 
> panic().  This is consistent with how other core subsystems handle
> SLAB cache creation failures.

Ok.

> I also think that if we accept this work, it should be first class
> citizen with no config options and no ifdefs scattered all over.
> Either this is how we do network AIO or it is not.
> 
> I've looked only briefly at Ulrich Drepper's AIO proposal in his OLS
> slides, although the DMA bits do not initially strike me as such a hot
> idea.  I haven't wrapped my brain much around this new stuff, so I'm
> not going to touch on it much more just yet.

Yes, his idea of dma alloc is extremely good.
I manage it with quite big overhead in kevent unfortunately.
All other topics are fully covered with kevent (except nice userspace
API of course :) )

> The practical advantage kevent has over any new proposal is that 1)
> implementation exists :) and 2) several types of test applications and
> performance measurements have been made against it which usually
> flushes out the worst design issues.

I will clean code up and resubmit today.
Thank you.

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