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

On Tuesday 17 October 2006 05:42, Evgeniy Polyakov wrote:
> On Tue, Oct 17, 2006 at 12:59:47AM -0500, Chase Venters 
(chase.venters@...entec.com) wrote:
> > On Tuesday 17 October 2006 00:09, Johann Borck wrote:
> > > Regarding mukevent I'm thinking of a event-type specific struct, that
> > > is filled by the originating code, and placed into a per-event-type
> > > ring buffer (which  requires modification of kevent_wait).
> >
> > I'd personally worry about an implementation that used a per-event-type
> > ring buffer, because you're still left having to hack around starvation
> > issues in user-space. It is of course possible under the current model
> > for anyone who wants per-event-type ring buffers to have them - just make
> > separate kevent sets.
> >
> > I haven't thought this through all the way yet, but why not have variable
> > length event structures and have the kernel fill in a "next" pointer in
> > each one? This could even be used to keep backwards binary compatibility
> > while
>
> Why do we want variable size structures in mmap ring buffer?

Flexibility primarily. So when we all decide to add a new event type six 
months from now, or add more information to an existing one, we don't run the 
risk that the existing mukevent isn't big enough.

> > adding additional fields to the structures over time, though no space
> > would be wasted on modern programs. You still end up with a question of
> > what to do in case of overflow, but I'm thinking the thing to do in that
> > case might be to start pushing overflow events onto a linked list which
> > can be written back into the ring buffer when space becomes available.
> > The appropriate behavior would be to throw new events on the linked list
> > if the linked list had any events, so that things are delivered in order,
> > but write to the mapped buffer directly otherwise.
>
> I think in a similar way.
> Kevent actually do not require such list, since it has already queue of
> the ready events.

The current event types coalesce if there are multiple events, correct? It 
sounds like there may be other event types where coalescing multiple events 
is not the correct approach.

Thanks,
Chase
-
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/