Hi, On 07/01/2014 12:18 PM, Hugh Dickins wrote: > On Fri, 27 Jun 2014, Xiaoguang Wang wrote: >> Hi maintainers, > > That's not me, but I'll answer with my opinion. Sure, thanks, Any opinion or suggestions will be appreciated :) > >> >> 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. Yeah, I see. Once Andrea had a patch to fix this, but it would slow down fork(). > > 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. OK, I still want to thanks for your response. Currently I don't have much knowledge about mm, sorry, so I'd like to know whether someone has some opinion or plan to fix this issue, thanks. Regards, Xiaoguang Wang > > Hugh > . > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>