lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 14 Dec 2016 00:37:52 +0530
From:   Hari Bathini <hbathini@...ux.vnet.ibm.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     ast@...com, peterz@...radead.org,
        lkml <linux-kernel@...r.kernel.org>, acme@...nel.org,
        alexander.shishkin@...ux.intel.com, mingo@...hat.com,
        daniel@...earbox.net, rostedt@...dmis.org,
        Ananth N Mavinakayanahalli <ananth@...ux.vnet.ibm.com>,
        sargun@...gun.me, Aravinda Prasad <aravinda@...ux.vnet.ibm.com>,
        brendan.d.gregg@...il.com
Subject: Re: [PATCH v3 3/3] perf tool: add cgroup identifier entry in perf
 report

Hi Eric,


On Tuesday 13 December 2016 03:36 AM, Eric W. Biederman wrote:
> Hari Bathini <hbathini@...ux.vnet.ibm.com> writes:
>
>> This patch introduces a cgroup identifier entry field in perf report to
>> identify or distinguish data of different cgroups. It uses the unique
>> inode number of cgroup namespace, included in perf data with the new
>> PERF_RECORD_NAMESPACES event, as cgroup identifier. With the assumption
>> that each container is created with it's own cgroup namespace, this
>> allows assessment/analysis of multiple containers at once.
> In the large this sounds reasonable.
>
> The details are wrong.  The cgroup id needs to be device
> number + inode number, not just inode number.
>

As the assumption that device number is going to be the same for
all namespaces may not stand the test of time, the inode number is
not going to be unique, to use as an identifier..

I am thinking of an identifier like the below. This may be OK for now
as dev_num & inode_num are 32bit each.

     identifier = (dev_num << 32 | inode_num)

But this may leave us with identifiers that are not unique if dev_num
& inode_num are changed to 64bit. Should that be of concern? Do
you have any alternate suggestions to come up with unique identifier
in such scenario too..?

Thanks
Hari

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ