lkml.org 
[lkml]   [2022]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V3] dma-buf: ensure unique directory name for dmabuf stats
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@intel.com>

The trest robot did not say that the dmabuf stat name was being
duplicated, did it?

> Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
> ---
> 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@quicinc.com/
>
> 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@quicinc.com/
>
> 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@linuxfoundation.org>

\
 
 \ /
  Last update: 2022-05-13 12:12    [W:0.053 / U:1.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site