From: Oleksandr Tymoshenko <ovt@google.com>
To: Hugh Dickins <hughd@google.com>
Cc: "Christian Brauner" <brauner@kernel.org>,
"Franklin “Snaipe” Mathieu" <snaipe@arista.com>,
corbet@lwn.net, akpm@linux-foundation.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH] shmem: add support for user extended attributes
Date: Tue, 22 Aug 2023 10:50:38 -0700 [thread overview]
Message-ID: <CACGj0Ci3pCim9Kr3+NMi8YdyoO1fRyprezLg1G4mPQQCP5cxjg@mail.gmail.com> (raw)
In-Reply-To: <924ed61c-5681-aa8b-d943-7f73694d159@google.com>
[-- Attachment #1: Type: text/plain, Size: 2528 bytes --]
Thanks for working on this.
On Mon, Aug 21, 2023 at 10:52 AM Hugh Dickins <hughd@google.com> 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
[-- Attachment #2: Type: text/html, Size: 3244 bytes --]
prev parent reply other threads:[~2023-08-22 17:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-20 6:54 [PATCH] shmem: add support for user extended attributes Oleksandr Tymoshenko
2023-07-20 16:56 ` Hugh Dickins
2023-07-20 17:09 ` Oleksandr Tymoshenko
2023-07-20 17:42 ` Hugh Dickins
2023-08-14 8:23 ` Snaipe
2023-08-15 3:51 ` Hugh Dickins
2023-08-15 7:46 ` Franklin “Snaipe” Mathieu
2023-08-15 8:23 ` Christian Brauner
2023-08-21 17:52 ` Hugh Dickins
2023-08-22 9:01 ` Christian Brauner
2023-08-22 17:50 ` Oleksandr Tymoshenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACGj0Ci3pCim9Kr3+NMi8YdyoO1fRyprezLg1G4mPQQCP5cxjg@mail.gmail.com \
--to=ovt@google.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=corbet@lwn.net \
--cc=hughd@google.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=snaipe@arista.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).