linux-kernel - Re: [take25 1/6] kevent: Description.

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:	Fri, 24 Nov 2006 19:49:16 +0300
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Ulrich Drepper <drepper@...hat.com>
Cc:	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>,
	Chase Venters <chase.venters@...entec.com>,
	Johann Borck <johann.borck@...sedata.com>,
	linux-kernel@...r.kernel.org, Jeff Garzik <jeff@...zik.org>
Subject: Re: [take25 1/6] kevent: Description.

On Fri, Nov 24, 2006 at 08:30:14AM -0800, Ulrich Drepper (drepper@...hat.com) wrote:
> Evgeniy Polyakov wrote:
> >>Very much simplified but it should show that we need a writable copy of 
> >>the uidx.  And this value at any time must be consistent with the index 
> >>the kernel assumes.
> >
> >I seriously doubt it is simpler than having index provided by kernel.
> 
> What has simpler to do with it?  The userlevel code should not modify 
> the ring buffer structure at all.  If we'd do this then all operations, 
> at least on the uidx field, would have to be atomic operations.  This is 
> currently not the case for the kernel side since it's protected by a 
> lock for the event queue.  Using the uidx field from userlevel would 
> therefore just make things slower.

That index is provided by kernel for userspace so that userspace could
determine where indexes are - of course userspace can maintain it
itself, but it can also use provided by kernel. It is not written
explicitly, but only through kevent_commit().

> And for what?  Changing the uidx value would make the commit syscall 
> unnecessary.  This might be an argument but it sounds too dangerous. 
> IMO the value should be protected by the kernel.
> 
> And in any case, the uidx value cannot be updated until the event 
> actually has been processed.  But the threads still need to coordinate 
> distributing the events from the ring buffer amongst themselves.  This 
> will in any case require a second variable.
> 
> So, if you want to do away with the commit syscall, keep the uidx value. 
>  This also requires that the ring buffer head will always be writable 
> (something I'd like to avoid making part of the interface but I'm 
> flexible on this).  Otherwise, the ring_uidx element can go away, it's 
> not needed and will only make people think about wrong approaches to use it.

No, head will not be writeable - it is absolutely.

I do not care actually about that index, but as you have probably noticed, 
there was such an interface already, and I changed it. So, this will be the 
last change of the interface. You think it should not be exported -
fine, it will not be.

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