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:	Wed, 22 Nov 2006 15:46:42 -0800
From:	Ulrich Drepper <drepper@...hat.com>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
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.

Evgeniy Polyakov wrote:
> + int kevent_wait(int ctl_fd, unsigned int num, __u64 timeout);
> +
> +ctl_fd - file descriptor referring to the kevent queue 
> +num - number of processed kevents 
> +timeout - this timeout specifies number of nanoseconds to wait until there is 
> +		free space in kevent queue 
> +
> +Return value:
> + number of events copied into ring buffer or negative error value.

This is not quite sufficient.  What we also need is a parameter which 
specifies which ring buffer the code assumes is currently active.  This 
is just like the EWOULDBLOCK error in the futex.  I.e., the kernel 
doesn't move the thread on the wait list if the index has changed. 
Otherwise asynchronous ring buffer filling is impossible.  Assume this

     thread                             kernel

     get current ring buffer idx

     front and tail pointer the same

                                        add new entry to ring buffer

                                        bump front pointer

     call kevent_wait()


With the interface above this leads to a deadlock.  The kernel delivered 
the event and is done with it.

If the kevent_wait() syscall gets an additional parameter which 
specifies the expected front pointer the kernel wouldn't put the thread 
to sleep since, in this case, the front pointer changed since last checked.

The kernel cannot and should not check the ring buffer is empty. 
Userlevel should maintain the tail pointer all by itself.  And even if 
the tail pointer is available to the kernel, the program might want to 
handle the queued events differently.

The above also comes to bear without asynchronous queuing if a thread 
waits for more than one event and it is possible to handle both events 
concurrently in two threads.

Passing in the expected front pointer value is flexible and efficient.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ