On 02/24/2016 01:23 AM, Dan Williams wrote: > On Tue, Feb 23, 2016 at 3:07 PM, Boaz Harrosh <boaz@xxxxxxxxxxxxx> wrote: >> On 02/24/2016 12:33 AM, Dan Williams wrote: > >>> The crux of the problem, in my opinion, is that we're asking for an "I >>> know what I'm doing" flag, and I expect that's an impossible statement >>> for a filesystem to trust generically. If you can get MAP_PMEM_AWARE >>> in, great, but I'm more and more of the opinion that the "I know what >>> I'm doing" interface should be something separate from today's trusted >>> filesystems. >>> >> >> I disagree. I'm not saying any "trust me I know what I'm doing" flag. >> the FS reveals nothing and trusts nothing. >> All I'm saying is that the libc library I'm using as the new pmem_memecpy() >> and I'm using that instead of the old memecpy(). So the FS does not need to >> wipe my face after I eat. Failing to do so just means a bug in the application > > "just means a bug in the application" > > Who gets the bug report when an app gets its cache syncing wrong and > data corruption ensues, and why isn't the fix for that bug that the > filesystem simply stops trusting MAP_PMEM_AWARE and synching > cachelines on behalf of the app when it calls sync as it must for > metadata consistency. Problem solved globally for all broken usages > of MAP_PMEM_AWARE and the flag loses all meaning as a result. > Because this will not fix the application's bugs. Because if the application is broken then you do not know that this will fix it. It is broken it failed to uphold the contract it had with the Kernel. It is like saying lets call fsync on file close because broken apps keep forgetting to call fsync(). And file close is called even if the app crashes. Will Dave do that? No if an app has a bug like this falling to call the proper pmem_xxx routine in the proper work flow, it might has just forgotten to call fsync, or maybe still modifying memory after fsync was called. And your babysitting the app will not help. > This is the takeaway I've internalized from Dave's pushback of these > new mmap flags. > We are already used to tell the firefox guys, you did not call fsync and you lost data on a crash. We will have a new mantra, "You did not use pmem_memcpy() but used MAP_PMEM_AWARE" We have contracts like that between Kernel and apps all the time. I fail to see why this one crossed the line for you? Again the question is: Can an app do something so stupid that it can break other apps? Cheers Boaz -- 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>