Linus Torvalds wrote: > On Wed, Jan 4, 2017 at 10:37 PM, George Spelvin > <linux@xxxxxxxxxxxxxxxxxxx> wrote: > Back in 2001, Linus had some very negative things to say about MAP_COPY. >> I'm going to try to change that opinion. > Not going to happen. Really? Because the rest of your response is a lot more encouraging. > Basically, the way you can change that opinion is if you can show some > clever zero-cost versioning model that "just work". With an actual > patch. That's the response I was hoping for! That's a change from "it's a stupid idea and crazily impractical" to "I seriously doubt it can be done cheap enough." > And without it being zero cost to all the _real_ users, I'm not adding > a MAP_COPY that absolutely nobody will ever use because it's not > standard, and it's not useful enough to them. FWIW, I was writing some code and wishing for some semantics like this, which is what led me to learn about MAP_COPY and all that. I have a big config file full of strings, which I parse and index. The vast majority of them contain no metacharacters, and I thought I could just cache a (ptr, len) into the mapped config file, and save a lot of allocation and copying. But someone could put a metacharacter into the file after I parse it. Would that constitute a security problem? Damn it, now I have to do a much more complex analysis. Moan, bitch, grumble, whinge, "there ought to be a way." And this idea popped out. The thing is, TOCTTOU is a well-known security problem. We already have custom interfaces in the kernel specifically to address this issue. So it seemed possible that this might be of broader interest. > We've had a history of failed clever interfaces that end up being very > painful to maintain (splice() being the most obvious one, but we've > had a numebr of filesystem innovations that just didn't work either, > devfs being the most spectacularly bad one). Absolutely. That's why I wanted to float the idea before I did a ton of implementation work and got emotionally attached to the result. > But the hard part is for all *other* users that might write to the > page now need to do the cow for somebody else. So it basically > requires a per-page count (possibly just flag) of "this has a copy > mapping", along with everybody who might write to it that currently > just get a ref to the page to check it, and do the rmap thing etc. Yes, that's the same thing I identified as the unsolved hard part. I'm going to need to go away and study dark MM lore for a while. I agree the implementation may run into trouble, but "now we're just haggling over the price". That's a big difference from the *idea* being stupid because no possible implementation is practical. The nice thing is that I don't care very much how expensive the COW is. It's Not Supposed To Happen unless there's a legitimate race condition bug or an illegtimate race condition explot. It just has to be less of a DoS attack than MAP_DENYWRITE. Thank you very much for your insights into the implementation practicalities. I'll direct more detailed discussions to people like Rik, Mel and Kirill. -- 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>