On Thu 11-03-21 10:00:17, Vasily Averin wrote: > On 3/10/21 1:41 PM, Michal Hocko wrote: [...] > > That is certainly an interesting information. But for a changelog it > > would be more appropriate to provide information about how much memory > > user can induce and whether there is any way to limit that memory by > > other means. How practical those other means are and which usecases will > > benefit from the containment. > > Right now I would like to understand how should I argument my requests about > accounting of new kind of objects. > > Which description it enough to enable object accounting? Doesn't the above paragraph give you a hint? > Could you please specify some edge rules? There are no strong rules AFAIK. I would say that it is important is that the user can trigger a lot of or unbound amount of objects. > Should I push such patches trough this list? yes linux-mm and ccing memcg maintainers is the proper way. It would be great to CC maintainers of the affected subsystem as well. > Is it probably better to send them to mailing lists of according subsystems? > Should I notify them somehow at least? > > "untrusted netadmin inside memcg-limited container can create unlimited number of routing entries, trigger OOM on host that will be unable to find the reason of memory shortage and kill huge" > > "each mount inside memcg-limited container creates non-accounted mount object, > but new mount namespace creation consumes huge piece of non-accounted memory for cloned mounts" > > "unprivileged user inside memcg-limited container can create non-accounted multi-page per-thread kernel objects for LDT" > > "non-accounted multi-page tty objects can be created from inside memcg-limited container" > > "unprivileged user inside memcg-limited container can trigger creation of huge number of non-accounted fasync_struct objects" OK, that sounds better to me. It would be also great if you can mention whether there are any other means to limit those objects if there are any. Thanks! -- Michal Hocko SUSE Labs
