On Thu, Jan 05, 2023 at 06:08:28PM -0800, Linus Torvalds wrote: > (although honestly, we should solve the 32-bit > problem first - ignoring it isn't fine for anything that is supposed > to be widely useful). Yea, the 64-bit aspect of that patch is pretty gnarly. I would hope that if converting the field to be 64-bit everywhere, the compiler would still generate good code for most cases, when testing against common-case constant bit masks that are half unset, but I didn't look into it. Indeed if this is to become something real, that'd be a worthwhile pre-requisite project. > And I think VM_DROPPABLE matches (a), and would be fine if it had some > other non-made-up use (although honestly, we should solve the 32-bit > problem first - ignoring it isn't fine for anything that is supposed > to be widely useful). > > We *have* talked about features kind of like it before, for people > doing basically caches in user space that they can re-create on demand > and are ok with just going away under memory pressure. > > But those people almost invariably want dropped pages to cause a > SIGSEGV or SIGBUS, not to come back as zeroes. Yea it seems intuitively like that would be a useful thing. Rather than trying to heuristically monitor memory pressure from inside uncoordinated userspace apps, just have the kernel nuke pages when it makes sense to do. The thing is -- and this is what I was trying to express to Yann -- while I have some theoretical notion of how it /might/ be useful, that's mainly just a guess from me. But one could run around discussing the idea with actual potential users of it, and see if anyone's eyes light up. And then once, for example, the Chrome renderer team is clamoring for it, then hey, there'd be a good use that wouldn't be bound up with security models not everybody cares about. > So you were insulting when you said kernel people don't care about > security issues. And I'm just telling you that's not true, but it Maybe you read that without looking at the end of the sentence which read: ", assuming that the concerns are unreal or niche or paranoid or whatever." Because the email you sent in response pretty much described the concerns as either unreal or niche. So I didn't mean to be insulting. I actually think we agree with each other on the nature of your position. > *is* 100% true that kernel people are often really fed up with > security people who have their blinders on, focus on some small thing, > and think nothing else ever matters. > > So yes, the way to get something like VM_DROPPABLE accepted is to > remove the blinders, and have it be something more widely useful, and > not be a "for made up bad code". I get this part. Either the implementation is trivial/convenient/ unintrusive/unnoticeable, or it really needs to be motivated by something you find compelling and preferably has wide application. No objection from me there. If you ignore the instruction decoder part, though -- which I mentioned to Ingo could be nixed anyway -- my initial estimation of this patch here was that it wasn't /that/ bad, being +32/-3, and I didn't buy the arguments that it'd be rarely used code paths and that nobody OOMs and nobody swaps, because it doesn't match my own experience of seeing OOMing regularly and the fact that if this is in glibc, it'll wind up being used. So the initial arguments against it were not compelling. But then you and others elaborated that VM_* flags really ought to be for general things, and that as a matter of taste and cleanliness, sticking things into the *core* of mm/ is just really a sensitive thing not to be done lightly and without a really compelling reason. And so I also get that. So, I'm playing around with other technical solutions to the mlock() limitation thing that started all of this (amidst other things in my end-of-the-year backlog), and I'll post results if I can get something working. Jason
