Hello, On 10/05/17 18:45, Dave Hansen wrote: > On 05/10/2017 08:19 AM, Igor Stoppa wrote: >> So I'd like to play a little what-if scenario: >> what if I was to support exclusively virtual memory and convert to it >> everything that might need sealing? > > Because of the issues related to fracturing large pages, you might have > had to go this route eventually anyway. Changing the kernel linear map > isn't nice. > > FWIW, you could test this scheme by just converting all the users to > vmalloc() and seeing what breaks. They'd all end up rounding up all > their allocations to PAGE_SIZE, but that'd be fine for testing. Apologies for the long hiatus, it took me some time to figure out a solution that could somehow address all the comments I got till this point. It's here [1], I preferred to start one new thread, since the proposal has in practice changed significantly, even if in spirit it's still the same. It should also take care of the potential waste of space you mentioned wrt the round up to PAGE_SIZE. > Could you point out 5 or 10 places in the kernel that you want to convert? Right now I can only repeat what I said initially: - the linked list used to implement LSM hooks - SE linux structures used to implement the policy DB, it should be about 5 data types Next week, I'll address the 2 cases I listed, then I'll look for more, but I think it should not be difficult to find customers for this. BTW, I forgot to mention that I tested the code against both SLAB and SLUB and it seems to work fine. So far I've used QEMU x86-64 as test environment. -- igor [1] https://marc.info/?l=linux-mm&m=149519044015956&w=2 -- 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>
