linux-kernel - Re: [take24 0/6] kevent: Generic event handling mechanism.

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: <20061120091951.GA13050@2ka.mipt.ru>
Date:	Mon, 20 Nov 2006 12:19:51 +0300
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Andrew Morton <akpm@...l.org>
Cc:	Ulrich Drepper <drepper@...hat.com>,
	David Miller <davem@...emloft.net>,
	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>,
	linux-kernel@...r.kernel.org, Jeff Garzik <jeff@...zik.org>,
	Alexander Viro <aviro@...hat.com>
Subject: Re: [take24 0/6] kevent: Generic event handling mechanism.

On Mon, Nov 20, 2006 at 01:15:16AM -0800, Andrew Morton (akpm@...l.org) wrote:
> On Mon, 20 Nov 2006 11:51:59 +0300
> Evgeniy Polyakov <johnpol@....mipt.ru> wrote:
> 
> > On Mon, Nov 20, 2006 at 12:43:01AM -0800, Andrew Morton (akpm@...l.org) wrote:
> > > > > >If thread calls kevent_wait() it means it has processed previous entries, 
> > > > > >one can call kevent_wait() with $num parameter as zero, which
> > > > > >means that thread does not want any new events, so nothing will be
> > > > > >copied.
> > > > > 
> > > > > This doesn't solve the problem.  You could only request new events when 
> > > > > all previously reported events are processed.  Plus: how do you report 
> > > > > events if the you don't allow get_event pass them on?
> > > > 
> > > > Userspace should itself maintain order and possibility to get event in
> > > > this implementation, kernel just returns events which were requested.
> > > 
> > > That would mean that in a multithreaded application (or multi-processes
> > > sharing the same MAP_SHARED ringbuffer), all threads/processes will be
> > > slowed down to wait for the slowest one.
> > 
> > Not at all - all other threads can call kevent_get_events() with theirs
> > own place in the ring buffer, so while one of them is processing an
> > entry, others can fill next entries.
> 
> eh?  That's not a ringbuffer, and it sounds awfully complex.
> 
> I don't know if this (new?) proposal resolves the
> events-gets-lost-due-to-thread-cancellation problem?  Would need to see
> considerably more detail.

It does - event is copied into shared buffer, but place (or index in the
ring buffer) is selected by userspace (wrapper, glibc, anything).
It is simple and (from my point of view) elegant, but it will not be used - 
I surrender and implement kenelspace ring buffer management right now, I 
just said that it is possible to implement any kind of ring buffer in 
userspace with old kevent_get_events() syscall only.

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