linux-kernel - Re: [take19 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:	Thu, 5 Oct 2006 17:07:48 +0200
From:	Hans Henrik Happe <hhh@...da.sdu.dk>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
Cc:	Eric Dumazet <dada1@...mosbay.com>,
	Ulrich Drepper <drepper@...il.com>,
	lkml <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Ulrich Drepper <drepper@...hat.com>,
	Andrew Morton <akpm@...l.org>, netdev <netdev@...r.kernel.org>,
	Zach Brown <zach.brown@...cle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Chase Venters <chase.venters@...entec.com>,
	Johann Borck <johann.borck@...sedata.com>
Subject: Re: [take19 1/4] kevent: Core files.

On Thursday 05 October 2006 16:15, Evgeniy Polyakov wrote:
> On Thu, Oct 05, 2006 at 04:01:19PM +0200, Hans Henrik Happe 
(hhh@...da.sdu.dk) wrote:
> > > And what happens when there are 3 empty at the beginning and \we need to
> > > put there 4 ready events?
> > 
> > Couldn't there be 3 areas in the mmap buffer:
> > 
> > - Unused: entries that the kernel can alloc from.
> > - Alloced: entries alloced by kernel but not yet used by user. Kernel can 
> > update these if new events requires that.
> > - Consumed: entries that the user are processing.
> > 
> > The user takes a set of alloced entries and make them consumed. Then it 
> > processes the events after which it makes them unused. 
> > 
> > If there are no unused entries and the kernel needs some, it has wait for 
free 
> > entries. The user has to notify when unused entries becomes available. It 
> > could set a flag in the mmap'ed area to avoid unnessesary wakeups.
> > 
> > The are some details with indexing and wakeup notification that I have 
left 
> > out, but I hope my idea is clear. I could give a more detailed description 
if 
> > requested. Also, I'm a user-level programmer so I might not get the whole 
> > picture.
> 
> This looks good on a picture, but how can you put it into page-based
> storage without major and complex shared structures, which should be
> properly locked between kernelspace and userspace?

I wasn't clear about the structure. I meant a ring-buffer with 3 areas. So 
it's basically the same model as Eric Dumazet described, only with 3 indexes; 
2 in the user-writeable page and 1 in kernel.

When the kernel has alloced an entry it should store it in a way that makes it 
invalid after user consumsion, which is simply an increment of an index. 
Sliding-window like schemes should solve this.

Hans Henrik Happe
-
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/