Thanks for working on this. On Mon, Aug 21, 2023 at 10:52 AM Hugh Dickins wrote: > On Tue, 15 Aug 2023, Christian Brauner wrote: > > On Tue, Aug 15, 2023 at 09:46:22AM +0200, Franklin “Snaipe” Mathieu > wrote: > > > > > > So, it's likely that there's some more work to do in that area; I'd > > > certainly expect the OOM killer to take the overall memory footprint > > > of mount namespaces into account when selecting which processes to > > > kill. It's also possible my experiment was flawed and not > > > representative of a real-life scenario, as I clearly have interacted > > > with misbehaving containers before, which got killed when they wrote > > > too much to tmpfs. But then again, my experiment also didn't take > > > memory cgroups into account. > > > > So mount namespaces are orthogonal to that and they would be the wrong > > layer to handle this. > > > > Note that an unprivileged user (regular or via containers) on the system > > can just exhaust all memory in various ways. Ultimately the container or > > user would likely be taken down by in-kernel OOM or systemd-oomd or > > similar tools under memory pressure. > > > > Of course, all that means is that untrusted workloads need to have > > cgroup memory limits. That also limits tmpfs instances and prevents > > unprivileged user from using all memory. > > > > If you don't set a memory limit then yes, the container might be able to > > exhaust all memory but that's a bug in the container runtime. Also, at > > some point the OOM killer or related userspace tools will select the > > container init process for termination at which point all the namespaces > > and mounts go away. That's probably what you experience as misbehaving > > containers. The real bug there is probably that they're allowed to run > > without memory limits in the first place. > > Thanks, this was a good reminder that I very much needed to look back at > the memory cgroup limiting of xattrs on tmpfs - I'd had the patch in the > original series, then was alarmed to find shmem_alloc_inode() using > GFP_KERNEL, so there seemed no point in accounting the xattrs if the > inodes were not being accounted: so dropped it temporarily. I had > forgotten that SLAB_ACCOUNT on the kmem_cache ensures that accounting. > > "tmpfs,xattr: GFP_KERNEL_ACCOUNT for simple xattrs" just sent to fix it: > > https://lore.kernel.org/linux-fsdevel/f6953e5a-4183-8314-38f2-40be60998615@google.com/ > > Thanks, > Hugh