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  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, 10 Mar 2010 01:50:37 +0100
From:	M vd S <>
Subject: Re: O_NONBLOCK is NOOP on block devices

> mmap(2) / madvise(2) / mincore(2) may be a way around things (although 
> non-atomic), but I haven't tested it yet. It might also solve the 
> problem that started this thread, at least for the reading part of it. 
> Writing a small read() like function that operates through mmap() 
> doesn't seem too complicated. As for writing, you could use msync() 
> with MS_ASYNC to initiate a write. I'm not sure how to find out if a 
> write has indeed taken place, but at least initiating a non-blocking 
> write is possible. munmap() might then still block.

For the record I would like to share my very positive experience with 
the approach described. Thanks to 64 bit addressing you can mmap() an 
entire block device, and madvise() and mincore() work like you would 
expect them to. I haven't tried writing.

I also briefly tried aio_* and the libaio interface. The former is not 
really asynchronous - all requests are put in one separate thread where 
they will be executed in order, i.e. blocking, so you don't get any 
advantage from NCQ or data that was cached by the disk or the kernel. 
The latter apparently ends in an io_submit() which will block until all 
queued reads are finished, but I might have missed something there.

Imagine the orderly world in which O_NONBLOCK would make syscalls 
actually non-blocking...


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists