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

["Christian König" <christian.koenig@amd.com>]

Am 11.05.22 um 08:49 schrieb Charan Teja Kalla:
> 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.

I don't want to open up the can of worms discussing under which cases an 
UAPI breakage is acceptable and under which cases it's not.

So to make it short: When this causes a regression for Android it's a 
clear NAK.

> 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.

> 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.

Regards,
Christian.


>   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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fproject%2Flinux-mm%2Fpatch%2F4f091776142f2ebf7b94018146de72318474e686.1647008754.git.quic_charante%40quicinc.com%2F%2324780139&data=05%7C01%7Cchristian.koenig%40amd.com%7C62c0b07ffb084635dcbe08da331a6830%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637878485789848020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=V4QdoKGL8Ifuq2gvhNcP8oPJt%2FI%2BPkhzVDhSYShCS2M%3D&reserved=0
>
> [2]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.git%2Fpatch%2F%3Fid%3De809d5f0b5c912fe981dce738f3283b2010665f0&data=05%7C01%7Cchristian.koenig%40amd.com%7C62c0b07ffb084635dcbe08da331a6830%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637878485789848020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Vid4T1njdOMZv%2B1ADKfjiiuzt8z6%2FiFP%2BcbUwNcZmdw%3D&reserved=0
>
> Thanks,
> Charan