[You have already started new thread with the way how to introduce a new zone and that might turn out to be useful but I think it is much more important to understand requirements for the usecase you have in mind as first] On Fri 28-04-17 09:45:40, Michal Hocko wrote: > On Fri 21-04-17 11:30:04, Igor Stoppa wrote: > > Hello, > > > > I am looking for a mechanism to protect the kernel data which is allocated > > dynamically during system initialization and is later-on accessed only for > > reads. > > > > The functionality would be, in spirit, like the __read_only modifier, which > > can be used to mark static data as read-only, in the post-init phase. Only, > > it would apply to dynamically allocated data. > > > > I couldn't find any such feature (did I miss it?), so I started looking at > > what could be the best way to introduce it. > > > > The static post-init write protection is achieved by placing all the data > > into a page-aligned segment and then protecting the page from writes, using > > the MMU, once the data is in its final state. > > > > In my case, as example, I want to protect the SE Linux policy database, > > after the set of policy has been loaded from file. > > SE Linux uses fairly complex data structures, which are allocated > > dynamically, depending on what rules/policy are loaded into it. > > > > If I knew upfront, roughly, which sizes will be requested and how many > > requests will happen, for each size, I could use multiple pools of objects. > > However, I cannot assume upfront to know these parameters, because it's very > > likely that the set of policies & rules will evolve. > > > > I would also like to extend the write protection to other data structures, > > which means I would probably end up writing another memory allocator, if I > > started to generate on-demand object pools. > > What is the expected life time of those objects? Are they ever freed? If > yes are they freed at once or some might outlive others? > > > The alternative I'm considering is that, if I were to add a new memory zone > > (let's call it LOCKABLE), I could piggy back on the existing infrastructure > > for memory allocation. > > No, please no new memory zones! This doesn't look like a good fit > anyway. I believe you need an allocator on top of the page allocator > which manages kernel page tables on top of pools of pages. You really do > not care about where the page is placed physically. I am not sure how > much you can reuse from the SL.B object management because that highly > depends on the life time of objects. -- Michal Hocko SUSE Labs -- 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>
