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.
