linux-kernel - Re: [PATCH] rfc: threaded epoll

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:	Mon, 7 May 2007 23:56:40 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Ulrich Drepper <drepper@...il.com>
Cc:	Davide Libenzi <davidel@...ilserver.org>,
	Davi Arnaut <davi@...ent.com.br>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] rfc: threaded epoll_wait thundering herd

On May 07, 2007, at 22:49:04, Ulrich Drepper wrote:
> On 5/7/07, Davide Libenzi <davidel@...ilserver.org> wrote:
>> read(2) is a cancellation point too. So if the fine userspace code  
>> issues a random pthread_cancel() to a thread handling that, data  
>> is lost together with the session that thread was handling.
>
> This is absolutely not comparable.  When read/write is canceled no  
> data is lost.  Some other thread might have to pick up the slack  
> but that's it.

Uhh, how can you claim "no data is lost" in this scenario:

A bunch of threads shares a common fd and fpos, reading fixed-size  
records:

thread1: read(myfd, per_thread_buf, 512);
thread2: pthread_cancel(thread1);
thread3: read(myfd, per_thread_buf, 512);

This is *exactly* analogous to the epoll() scenario:  A bunch of  
threads are attempting to get data (either events or records) from a  
given object.  If thread1 gets cancelled after the completion of its  
read() syscall then the file position will have been advanced but the  
data in the per-thread buffer will be discarded.  The third thread  
won't (reliably) get the same data as thread1.  It might get it  
randomly on occasion if file position updates race, but you can't  
rely on that behavior.

Here's how you make both of those models safe against thread  
cancellation (assuming, of course, that process_one_buf has no  
cancellation points until after it saves the buffer state somewhere):

char per_thread_buf[512];
pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL);
pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
while (read(fd, per_thread_buf, 512) == 512) {
	pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
	process_one_buffer(per_thread_buf);
	pthread_testcancel();
	pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
}
pthread_exit(NULL);

Look how trivial that is!  Isn't it fun?  Of course, once you look at  
it this way you could do the same verbose crap that pthread_cancel/ 
pthread_setcancelstate/pthread_testcancel are doing with a simple int  
protected by a pthread_mutex.

Cheers,
Kyle Moffett

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