Re: [PATCH v3 15/16] memcg: enable accounting for tty-related objects

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Apr 23, 2021 at 01:29:53PM +0300, Vasily Averin wrote:
> On 4/23/21 11:58 AM, Michal Hocko wrote:
> > 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.
> 
> If Greg doesn't have any objections, I'll add this explanation to the next version of the patch.
> 

I object to the current text you submitted, so something has to change
in order for me to be able to accept the patch :)

Seriously, yes, the above information is great, please include that and
all should be fine.

thanks,

greg k-h



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux