archive mirror
 help / color / mirror / Atom feed
From: Axel Rasmussen <>
To: Vlastimil Babka <>
Cc: Shakeel Butt <>,
	Steven Rostedt <>, Tejun Heo <>,
	Greg Thelen <>,
	Andrew Morton <>,
	Chinwen Chang <>,
	Daniel Jordan <>,
	David Rientjes <>,
	Davidlohr Bueso <>, Ingo Molnar <>,
	Jann Horn <>,
	Laurent Dufour <>,
	Michel Lespinasse <>,
	Stephen Rothwell <>,
	Yafang Shao <>,
	"David S . Miller" <>,,
	Greg Kroah-Hartman <>,
	Jakub Kicinski <>,, LKML <>,
	Linux MM <>
Subject: Re: [PATCH] mm: mmap_lock: fix use-after-free race and css ref leak in tracepoints
Date: Fri, 4 Dec 2020 09:46:33 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Dec 4, 2020 at 8:36 AM Vlastimil Babka <> wrote:
> On 12/2/20 2:11 AM, Shakeel Butt wrote:
> > On Tue, Dec 1, 2020 at 5:07 PM Steven Rostedt <> wrote:
> >>
> >> On Tue, 1 Dec 2020 16:36:32 -0800
> >> Shakeel Butt <> wrote:
> >>
> >> > SGTM but note that usually Andrew squash all the patches into one
> >> > before sending to Linus. If you plan to replace the path buffer with
> >> > integer IDs then no need to spend time fixing buffer related bug.
> >>
> >> I don't think Andrew squashes all the patches. I believe he sends Linus
> >> a patch series.
> >
> > I am talking about the patch and the following fixes to that patch.
> > Those are usually squashed into one patch.
> Yeah, if there's a way forward that doesn't need to construct full path on each
> event and the associated complexity and just use an ID, let's convert to the ID
> and squash it, for less churn. Especially if there are other existing
> tracepoints that use the ID.

The thing I worry about is that it being inconvenient will prevent
folks from using it to send us data on how mmap_lock behaves under
their workloads. Anecdotally, I talked to a few teams within Google,
and it seems those using containers use paths instead of IDs to refer
to them, and they don't have existing infrastructure to keep track of
the mapping. So to collect data from those workloads, we'd have to
wait for them to build such a thing, vs. just asking them to run a
bash one-liner. I haven't done a wider survey, but I suspect the same
is true for users of e.g. Docker or Kubernetes.

> If there's further (somewhat orthogonal) work to make the IDs easier for
> userspace, it can be added on top later, but really shouldn't need to add the
> current complex solution only to remove it later?

I'm on board with Shakeel's idea to export this on cgroup
creation/deletion instead, since it lets us keep the complexity in
exactly one place. I think such a thing would use the same code I'm
proposing now, though, so we wouldn't just be deleting it if we merge
it. Also, before doing that I think it's worth identifying a second
user within the kernel (maybe the writeback tracepoint mentioned
earlier in the thread?), so doing it incrementally seems reasonable to

This plan is also in-line with existing stuff we provide. Histogram
triggers provide utilities like ".execname" (PID -> execname) or
".sym" (address -> symbol) for convenience. Sure, userspace could
figure these things out for itself, but it's convenient to provide
them directly, and it's not so bad since we have exactly one place in
the tracing infrastructure that knows how to do these translations.

Actually, maybe a ".cgpath" variant would be better than a separate
tracepoint. I haven't looked at what either approach would require in
detail; maybe another reason to do this iteratively. :)

> Thanks,
> Vlastimil

  reply	other threads:[~2020-12-04 17:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30 23:35 [PATCH] mm: mmap_lock: fix use-after-free race and css ref leak in tracepoints Axel Rasmussen
2020-12-01  1:33 ` Shakeel Butt
2020-12-01 17:36   ` Axel Rasmussen
2020-12-01 17:56     ` Greg Thelen
2020-12-01 18:42       ` Shakeel Butt
2020-12-01 19:13         ` Axel Rasmussen
2020-12-01 20:53           ` Shakeel Butt
2020-12-02  0:15             ` Axel Rasmussen
2020-12-02  0:36               ` Shakeel Butt
2020-12-02  1:07                 ` Steven Rostedt
2020-12-02  1:11                   ` Shakeel Butt
2020-12-04 16:36                     ` Vlastimil Babka
2020-12-04 17:46                       ` Axel Rasmussen [this message]
2020-12-02 19:00             ` Tejun Heo
2020-12-02 23:23               ` Shakeel Butt
2020-12-02 23:30                 ` Tejun Heo
2020-12-01  3:57 ` Steven Rostedt

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).