Thanks Christian for the inputs!!
On 5/10/2022 10:52 PM, Christian König wrote:
if (!dmabuf || !dmabuf->file) return -EINVAL; @@ -192,7 +193,8 @@ int dma_buf_stats_setup(struct dma_buf *dmabuf) /* create the directory for buffer stats */ ret = kobject_init_and_add(&sysfs_entry->kobj, &dma_buf_ktype, NULL, - "%lu", file_inode(dmabuf->file)->i_ino); + "%lu-%lu", file_inode(dmabuf->file)->i_ino,
Why not just use the unique value here? Or is the inode number necessary for something?
This will ease the debugging a lot. Given the dump, I can easily map which dmabuf buffer to the process. On the crashutilty I just have to search for this inode in the files output, just one example.
T.J. Mercier just confirmed my suspicion that this would break the UAPI. So that won't work.
This needs to be a single number, preferable documented as such.
Usually, What are the chances that a patch breaking UAPI will get accepted. IMO, If there are few users, I had learnt that it is allowed to merge. (Eg: In [1] where Andrew, -mm maintainer, mentioned that: "I think we should just absorb any transitory damage which this causes people." for the patch posted breaking the UAPI). Even the patch c715def51591 ("dma-buf: Delete the DMA-BUF attachment sysfs statistics") deleted the sysfs entries which also comes under the UAPI breakage but still allowed to merge. On those lines, Is it fair to say If few users are there, uapi breakage changes are allowed to merge on the assumption that userspace code needs to be aligned with the new uapi changes? To my knowledge, Android is the only user which is just getting the dmabuf stats as part of the debug code.
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.
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]. The code will be like below(untested):
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index a6fc96e..eeed770 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -408,11 +408,17 @@ static inline int is_dma_buf_file(struct file *file) static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags) { struct file *file; + static atomic64_t unique_id = ATOMIC64_INIT(0); struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb);
if (IS_ERR(inode)) return ERR_CAST(inode);
+ /* + * Override the inode->i_no number with the unique + * dmabuf specific value + */ + inode->i_no = atomic64_add_return(1, &unique_id); inode->i_size = dmabuf->size; inode_set_bytes(inode, dmabuf->size);
[1] https://patchwork.kernel.org/project/linux-mm/patch/4f091776142f2ebf7b940181...
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/?id=e...
Thanks, Charan