linux-kernel - Re: [PATCH V2] dmabuf: ensure unique directory name for dmabuf stats

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <9be4ea50-4dc0-50f0-0552-e4b9e4feafa2@quicinc.com>
Date:   Thu, 12 May 2022 20:20:07 +0530
From:   Charan Teja Kalla <quic_charante@...cinc.com>
To:     Christian König <christian.koenig@....com>,
        <gregkh@...uxfoundation.org>, <sumit.semwal@...aro.org>,
        <hridya@...gle.com>, <daniel.vetter@...ll.ch>,
        <tjmercier@...gle.com>
CC:     <linux-kernel@...r.kernel.org>, <linux-media@...r.kernel.org>,
        <dri-devel@...ts.freedesktop.org>, <linaro-mm-sig@...ts.linaro.org>
Subject: Re: [PATCH V2] dmabuf: ensure unique directory name for dmabuf stats

Thanks Christian for the comments!!

On 5/11/2022 12:33 PM, Christian König wrote:
> 
>> The single number approach, generated by atomic, wouldn't break the
>> uapi, but that number won't give any meaningful information especially
>> when this is targeted just for debug purpose. And just 'inode' is not
>> usable for already stated reasons.
> 
> Well, why do you want to use the ino in the first place? This is an
> anonymous inode not associated with any filesystem, so that number is
> meaningless anyway.
> 

It is just for ease of debugging. Nothing more. I can quickly traverse
the /sys/kernel/dmabuf/buffers/* and get complete information about the
dmabuf buffers while relating to which process this buffer is allocated
by, using this inode as the 'unique' reference.

https://cs.android.com/android/platform/superproject/+/master:system/memory/libmeminfo/libdmabufinfo/tools/dmabuf_dump.cpp

>> How about using the atomic number generated it self used as inode
>> number? I see tmpfs also maintains its own inode numbers for the same
>> overflow reasons[2].
> 
> Yeah, that could potentially work as well.
> 

Thanks. Will work on the next version of this patch.

> Regards,
> Christian.