On Wed, Mar 10, 2021 at 11:00 PM Vasily Averin <vvs@xxxxxxxxxxxxx> wrote: > > On 3/10/21 1:41 PM, Michal Hocko wrote: > > On Wed 10-03-21 13:17:19, Vasily Averin wrote: > >> On 3/10/21 12:12 AM, Shakeel Butt wrote: > >>> On Tue, Mar 9, 2021 at 12:04 AM Vasily Averin <vvs@xxxxxxxxxxxxx> wrote: > >>>> > >>>> OpenVZ many years accounted memory of few kernel objects, > >>>> this helps us to prevent host memory abuse from inside memcg-limited container. > >>> > >>> The text is cryptic but I am assuming you wanted to say that OpenVZ > >>> has remained on a kernel which was still on opt-out kmem accounting > >>> i.e. <4.5. Now OpenVZ wants to move to a newer kernel and thus these > >>> patches are needed, right? > >> > >> Something like this. > >> Frankly speaking I badly understand which arguments should I provide to upstream > >> to enable accounting for some new king of objects. > >> > >> OpenVZ used own accounting subsystem since 2001 (i.e. since v2.2.x linux kernels) > >> and we have accounted all required kernel objects by using our own patches. > >> When memcg was added to upstream Vladimir Davydov added accounting of some objects > >> to upstream but did not skipped another ones. > >> Now OpenVZ uses RHEL7-based kernels with cgroup v1 in production, and we still account > >> "skipped" objects by our own patches just because we accounted such objects before. > >> We're working on rebase to new kernels and we prefer to push our old patches to upstream. > > > > 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? > Could you please specify some edge rules? > Should I push such patches trough this list? > 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" > I think the above reasoning is good enough. Just resend your patches with the corresponding details.
