On Fri, May 13, 2022 at 03:08:09PM +0530, Charan Teja Kalla wrote: > The dmabuf file uses get_next_ino()(through dma_buf_getfile() -> > alloc_anon_inode()) to get an inode number and uses the same as a > directory name under /sys/kernel/dmabuf/buffers/<ino>. This directory is > used to collect the dmabuf stats and it is created through > dma_buf_stats_setup(). At current, failure to create this directory > entry can make the dma_buf_export() to fail. > > Now, as the get_next_ino() can definitely give a repetitive inode no > causing the directory entry creation to fail with -EEXIST. This is a > problem on the systems where dmabuf stats functionality is enabled on > the production builds can make the dma_buf_export(), though the dmabuf > memory is allocated successfully, to fail just because it couldn't > create stats entry. > > This issue we are able to see on the snapdragon system within 13 days > where there already exists a directory with inode no "122602" so > dma_buf_stats_setup() failed with -EEXIST as it is trying to create > the same directory entry. > > To make the dentry name as unique, use the dmabuf fs specific inode > which is based on the simple atomic variable increment. There is tmpfs > subsystem too which relies on its own inode generation rather than > relying on the get_next_ino() for the same reason of avoiding the > duplicate inodes[1]. > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/?id=e809d5f0b5c912fe981dce738f3283b2010665f0 > > Reported-by: kernel test robot <lkp@xxxxxxxxx> The trest robot did not say that the dmabuf stat name was being duplicated, did it? > Signed-off-by: Charan Teja Kalla <quic_charante@xxxxxxxxxxx> > --- > Changes in V3: > -- Used the atomic64 variable to have dmabuf files its own inodes. > -- Ensured no UAPI breakage as suggested by Christian. > > Changes in V2: > -- Used the atomic64_t variable to generate a unique_id to be appended to inode > to have an unique directory with name <inode_number-unique_id> -- Suggested by christian > -- Updated the ABI documentation -- Identified by Greg. > -- Massaged the commit log. > -- https://lore.kernel.org/all/1652191562-18700-1-git-send-email-quic_charante@xxxxxxxxxxx/ > > Changes in V1: > -- Used the inode->i_ctime->tv_secs as an id appended to inode to create the > unique directory with name <inode_number-time_in_secs>. > -- https://lore.kernel.org/all/1652178212-22383-1-git-send-email-quic_charante@xxxxxxxxxxx/ > > drivers/dma-buf/dma-buf.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index a6fc96e..0ad5039 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -407,6 +407,7 @@ static inline int is_dma_buf_file(struct file *file) > > static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags) > { > + static atomic64_t dmabuf_inode = ATOMIC64_INIT(0); > struct file *file; > struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb); > > @@ -416,6 +417,13 @@ static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags) > inode->i_size = dmabuf->size; > inode_set_bytes(inode, dmabuf->size); > > + /* > + * The ->i_ino acquired from get_next_ino() is not unique thus > + * not suitable for using it as dentry name by dmabuf stats. > + * Override ->i_ino with the unique and dmabuffs specific > + * value. > + */ > + inode->i_ino = atomic64_add_return(1, &dmabuf_inode); > file = alloc_file_pseudo(inode, dma_buf_mnt, "dmabuf", > flags, &dma_buf_fops); > if (IS_ERR(file)) > -- > 2.7.4 > Reviewed-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
