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: <20060731.150028.26276495.davem@davemloft.net>
Date:	Mon, 31 Jul 2006 15:00:28 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	johnpol@....mipt.ru
Cc:	drepper@...hat.com, zach.brown@...cle.com,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [RFC 1/4] kevent: core files.

From: Evgeniy Polyakov <johnpol@....mipt.ru>
Date: Mon, 31 Jul 2006 23:41:43 +0400

> Since kevents are never generated by kernel, but only marked as ready,
> length of the main queue performs as flow control, so we can create a
> mapped buffer which will have space equal to the main queue length
> multiplied by size of the copied to userspace structure plus 16 bits for
> the start index of the kernel writing side, i.e. it will store offset
> where the oldest event was placed.
>
> Since queue length is a limited factor and thus no new events can be added
> when queue is full, that means that buffer is full too and userspace
> must read events. When syscall is called to add new kevent and provided 
> there offset differs from what kernel stored, that means that all events 
> from kernel to provided index have been read and new events can be added.
> Thus we can even allow read-only mapping. Kernel's index is incremented
> modulo queue length. If kevent was removed after it was marked as
> ready, it's copy stays in the mapped buffer, but special flag can be
> assigned to show that kevent is no longer valid.

This sounds reasonable.

However we must be mindful that the thread of control trying to
add a new event might not be in a position to drain the queue
of pending events when the queue is full.  Usually he will be
trying to add an event in response to handling another event.

So we'd have cases like this, assume we start with a full event
queue:

	thread A		thread B

	dequeue event
	aha, new connection
	accept()
				register new kevent
				queue is now full again
	add kevent on new
	connection

At this point thread A doesn't have very many options when the kevent
add fails.  You cannot force this thread to read more events, since he
may not be in a state where he is easily able to do so.
-
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/