Re: Corruption with O_DIRECT and unaligned user buffers

[Hugh Dickins <hughd@google.com>]

On Fri, 27 Jun 2014, Xiaoguang Wang wrote:
> Hi maintainers,

That's not me, but I'll answer with my opinion.

> 
> In August 2008, there was a discussion about 'Corruption with O_DIRECT and unaligned user buffers',
> please have a look at this url: http://thread.gmane.org/gmane.linux.file-systems/27358

Whereas (now the truth can be told!) "someone wishing to remain anonymous"
in that thread was indeed me.  Then as now, disinclined to spend time on it.

> 
> The attached test program written by Tim has been added to LTP, please see this below url:
> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/io/direct_io/dma_thread_diotest.c
> 
> 
> Now I tested this program in kernel 3.16.0-rc1+, it seems that the date corruption still exists. Meanwhile
> there is also such a section in open(2)'s manpage warning that O_DIRECT I/Os should never be run
> concurrently with the fork(2) system call. Please see below section:
> 
>     O_DIRECT I/Os should never be run concurrently with the fork(2) system call, if the memory buffer
>     is a private mapping (i.e., any mapping created with the mmap(2) MAP_PRIVATE flag; this includes
>     memory allocated on the heap and statically allocated buffers).  Any such I/Os, whether  submitted
>     via an asynchronous I/O interface or from another thread in the process, should be completed before
>     fork(2) is called.  Failure to do so can result in data corruption and undefined behavior in parent
>     and child processes.  This restriction does not apply when the memory buffer for  the  O_DIRECT
>     I/Os  was  created  using shmat(2) or mmap(2) with the MAP_SHARED flag.  Nor does this restriction
>     apply when the memory buffer has been advised as MADV_DONTFORK with madvise(2), ensuring that it will
>     not be available to the child after fork(2).
> 
> Hmm, so I'd like to know whether you have some plans to fix this bug, or this is not considered as a
> bug, it's just a programming specification that we should avoid doing fork() while we are having O_DIRECT
> file operation with non-page aligned IO, thanks.
> 
> Steps to run this attached program:
> 1. ./dma_thread  # create temp files
> 2. ./dma_thread -a 512 -w 8 $ alignment is 512 and create 8 threads.

I regard it, then and now, as a displeasing limitation;
but one whose fix would cause more trouble than it's worth.

I thought we settled long ago on MADV_DONTFORK as an imperfect but
good enough workaround.  Not everyone will agree.  I certainly have
no plans to go further myself.

Hugh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>