All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yhs@fb.com>
To: carlos antonio neira bustos <cneirabustos@gmail.com>,
	Blaise Sanouillet <blez@fb.com>
Cc: Daniel Xu <dxu@dxuuu.xyz>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>
Subject: Re: Extending bpf_get_ns_current_pid_tgid()
Date: Fri, 13 Nov 2020 08:59:25 -0800	[thread overview]
Message-ID: <9067600b-f340-ec3e-2ce8-d299793c123a@fb.com> (raw)
In-Reply-To: <CACiB22i6d2skkJJa7uwVRrYy7dtYOxmLgFwzjtieW4BFn2tzLw@mail.gmail.com>



On 11/13/20 6:34 AM, carlos antonio neira bustos wrote:
> Hi Blaise and Daniel,
> 
> 
> I was following a couple of months ago how bpftrace was going to handle 
> this situation. I thought this PR 
> https://github.com/iovisor/bpftrace/pull/1602 
> <https://github.com/iovisor/bpftrace/pull/1602> was going to be merged 
> but just found today that is not working.
> 
> I agree with Yonghong Song on the approach of using the two helpers 
> (bpf_get_pid_tgid() and bpf_get_ns_current_pid_tgid()) to move forward 
> on the short term, bpf_get_ns_current_pid_tgid works as a replacement  
> to bpf_get_pid_tgid when you are instrumenting inside a container.
> 
> But the use case described by Blaise is one I would like to use bpftrace,
> 
> If nobody is against it, I could start working on a new helper to 
> address that situation as I need to have bpftrace working in that scenario.

Yes, please. Thanks!

> 
> For my understanding of the problem the new helper should be able to 
> return pid/tgid from a target namespace, is that correct?.

Yes. This way, the stack trace can correlate to target namespace for
symbolization purpose.

> 
> 
> Bests
> 
> 
[...]

  parent reply	other threads:[~2020-11-13 16:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-12 22:20 Extending bpf_get_ns_current_pid_tgid() Daniel Xu
2020-11-13  0:27 ` Yonghong Song
2020-11-13  0:57   ` Daniel Xu
2020-11-13  4:13     ` Yonghong Song
2020-11-13 12:04       ` Blaise Sanouillet
2020-11-13 16:57         ` Yonghong Song
     [not found]         ` <CACiB22i6d2skkJJa7uwVRrYy7dtYOxmLgFwzjtieW4BFn2tzLw@mail.gmail.com>
2020-11-13 16:59           ` Yonghong Song [this message]
     [not found]             ` <CACiB22iU3zk4Row=wAween=rSvHJ7j7M5T2KbyFk38arzEwQpQ@mail.gmail.com>
2021-06-16  9:54               ` Blaise Sanouillet
2021-06-16 17:02               ` Yonghong Song
2021-06-16 21:44                 ` Carlos Neira
2021-06-17  2:49                   ` Yonghong Song
2021-06-17 10:59                     ` Blaise Sanouillet

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=9067600b-f340-ec3e-2ce8-d299793c123a@fb.com \
    --to=yhs@fb.com \
    --cc=blez@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=cneirabustos@gmail.com \
    --cc=dxu@dxuuu.xyz \
    --cc=ebiederm@xmission.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.