From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id hC2ABnB9IWB4RQAAWB0awg (envelope-from ) for ; Mon, 08 Feb 2021 13:05:36 -0500 Received: by simark.ca (Postfix, from userid 112) id 00DE11EF4F; Mon, 8 Feb 2021 13:05:35 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.lttng.org (lists.lttng.org [167.114.26.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 9DDEC1E54D for ; Mon, 8 Feb 2021 13:05:34 -0500 (EST) Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4DZDTV0DPXz19Qb; Mon, 8 Feb 2021 13:05:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1612807534; bh=Hlxn590lOzPeRNF1m2gAqBYV9aoIENOHx/7p4aCJ2l8=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=0M25xKETSEtWW0touF+T2CLes46GFQMLhVCfdJsMesDKKJ3fCegGi8VfU28Y7L4QA JBLkxC5OuM7Jd1suRag5jegmb1qeAfmTCCEeR//07D2MU9kq42IV5KEUF+0NLxSsGo oz3U5NhUBf5jKIJmIded3PPep16Oq1sBK7WgkjDwkmhuRIZ72nH+9L6sQA80k3oBIb 4uH/sAa0cdV/Yl2qMK6M3KD+EaUjqh1af8XQcoJURXpNJD6vbR83c9+wz39JQi4BE0 uLITHUahB+/ydznUbFZpVgA/LtFWtUFs1fF3NIyscMDvvlvpxLhbtoubmfoMGvbjjB 4VgZwFIDxjT8Q== Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by lists.lttng.org (Postfix) with ESMTPS id 4DZDTS2q8Lz19NQ for ; Mon, 8 Feb 2021 13:05:32 -0500 (EST) Received: by mail-lf1-x12d.google.com with SMTP id m22so23680098lfg.5 for ; Mon, 08 Feb 2021 10:05:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=mW0okUvHNb59BoEEIjzKv6qDL3pN5wtwWbBDVXcqoeU=; b=g4dYzF3UjrK8LhptCv1ZHylkTRXtO9XOWXZRSpZZ2Pr0JS5oQGTY3q3BPE4yzd1TJ4 A4Kj9kCZfmkx8h9OKyNBuMgUvmVmh17VnRuLZjIgeezDpTGihAjGLVItIf7IG9UGc5KV Jb37o6vZChYg1jIZ8eis2OeTpgXzISuxO/4lRXFlDCosDOTY8L6OfjdYFGebNRqD6nfr yRdfpwLjBMcRCs3TbqZcMk2vat81U1QxTSZPWuYHu5yHD6tmkwUR5jo9OwxE6dyOTEev wOJz5x7CtHAv1G4x7DUctDFrvp9JrTA2MRNKs2/FNAJaPA+h+CnNLT0oAyI1bS9CzCUT rd6g== X-Gm-Message-State: AOAM532jT0GBvz3ubPmF24DkfWTVJN3gC9M2N9psBBoOOw/66PPfdPHw HwK+S1R8gdqf7deuaFz0+Q9mi4mXVZDo/vpse+9KA6JymRWazduN X-Google-Smtp-Source: ABdhPJwjOCKZ4vdIXuWoA1qyVSk08A7e4ssetKkxNfCIYf2aeFzeokMhpb2QEXb7wkbGJdJHlgWFF51KOi7+g2E6B+I= X-Received: by 2002:a19:431b:: with SMTP id q27mr10867122lfa.137.1612807530391; Mon, 08 Feb 2021 10:05:30 -0800 (PST) MIME-Version: 1.0 Date: Mon, 8 Feb 2021 12:04:53 -0600 Message-ID: To: lttng-dev@lists.lttng.org Subject: [lttng-dev] LTTng Support for Network Namespace X-BeenThere: lttng-dev@lists.lttng.org X-Mailman-Version: 2.1.31 Precedence: list List-Id: LTTng development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mohammad Kavousi via lttng-dev Reply-To: Mohammad Kavousi Cc: Yan Chen , Xutong Chen Content-Type: multipart/mixed; boundary="===============8801218452634629091==" Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" --===============8801218452634629091== Content-Type: multipart/alternative; boundary="000000000000f0bf3205bad703b5" --000000000000f0bf3205bad703b5 Content-Type: text/plain; charset="UTF-8" Dear LTTng developers, I was wondering if LTTng currently (or in the future) supports network namespaces. For instance, an ambiguity in the logs would make problems for future system analysis. Taking the "bind" system call, that would help us distinguish between different local IP addresses when two or more container instances are running on the host, given that the "umyaddr" field is an address inside the memory, how would we recover the local addresses after the trace has been collected? syscall_entry_bind: { cpu_id = 1 }, { mnt_ns = 4026532553, pid = 532, tid = 532, vtid = 532, vpid = 532 }, { fd = 14, umyaddr = 93827759199256, addrlen = 12 } Thanks, we appreciate the help beforehand! Mohammad --000000000000f0bf3205bad703b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear LTTng developers,
I was wondering if LTTng currently (or in the future) sup= ports network namespaces. For instance, an ambiguity=C2=A0in the logs would= make problems for future system analysis.

Taking = the "bind" system call, that would help us distinguish between di= fferent local IP addresses when two or more container instances are running= on the host, given that the "umyaddr" field is an address inside= the memory, how would we recover the local addresses after the trace has b= een collected?

syscall_en= try_bind: { cpu_id =3D 1 }, { mnt_ns =3D 4026532553, pid =3D 532, tid =3D 5= 32, vtid =3D 532, vpid =3D 532 }, { fd =3D 14, umyaddr =3D 93827759199256, = addrlen =3D 12 }

<= /div>

Thanks, we appreciate the help beforehand!
=

Mohammad
--000000000000f0bf3205bad703b5-- --===============8801218452634629091== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev --===============8801218452634629091==--