On Fri 23-04-21 10:53:55, Vasily Averin wrote: > On 4/22/21 4:59 PM, Vasily Averin wrote: > > On 4/22/21 2:50 PM, Greg Kroah-Hartman wrote: > >> On Thu, Apr 22, 2021 at 01:44:59PM +0200, Michal Hocko wrote: > >>> On Thu 22-04-21 13:23:21, Greg KH wrote: > >>>> On Thu, Apr 22, 2021 at 01:37:53PM +0300, Vasily Averin wrote: > >>>>> At each login the user forces the kernel to create a new terminal and > >>>>> allocate up to ~1Kb memory for the tty-related structures. > >>>> > >>>> Does this tiny amount of memory actually matter? > >>> > >>> The primary question is whether an untrusted user can trigger an > >>> unbounded amount of these allocations. > >> > >> Can they? They are not bounded by some other resource limit? > > > > I'm not ready to provide usecase right now, > > but on the other hand I do not see any related limits. > > Let me take time out to dig this question. > > By default it's allowed to create up to 4096 ptys with 1024 reserve for initns only > and the settings are controlled by host admin. It's OK. > Though this default is not enough for hosters with thousands of containers per node. > Host admin can be forced to increase it up to NR_UNIX98_PTY_MAX = 1<<20. > > By default container is restricted by pty mount_opt.max = 1024, but admin inside container > can change it via remount. In result one container can consume almost all allowed ptys > and allocate up to 1Gb of unaccounted memory. > > It is not enough per-se to trigger OOM on host, however anyway, it allows to significantly > exceed the assigned memcg limit and leads to troubles on the over-committed node. > So I still think it makes sense to account this memory. This is a very valuable information to have in the changelog. It is not my call but if all the above is correct then the accounting is worth IMO. Thanks! -- Michal Hocko SUSE Labs
