Hi maintainers,

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

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.


Regards,
Xiaoguang Wang