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
