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 <[email protected]>
The trest robot did not say that the dmabuf stat name was being
duplicated, did it?
> Signed-off-by: Charan Teja Kalla <[email protected]>
> ---
> 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/[email protected]/
>
> 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/[email protected]/
>
> 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 <[email protected]>
On 5/13/2022 3:41 PM, Greg KH wrote:
>> Reported-by: kernel test robot <[email protected]>
> The trest robot did not say that the dmabuf stat name was being
> duplicated, did it?
>
It reported a printk warning on V2[1]. Should we remove this on V3?
@Christian: Could you please drop this tag while merging?
[1] https://lore.kernel.org/all/[email protected]/
>> 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 <[email protected]>
Thanks for the ACK.
--Charan
On Fri, May 13, 2022 at 03:48:23PM +0530, Charan Teja Kalla wrote:
>
> On 5/13/2022 3:41 PM, Greg KH wrote:
> >> Reported-by: kernel test robot <[email protected]>
> > The trest robot did not say that the dmabuf stat name was being
> > duplicated, did it?
> >
>
> It reported a printk warning on V2[1]. Should we remove this on V3?
Yes, that's different.
> @Christian: Could you please drop this tag while merging?
>
> [1] https://lore.kernel.org/all/[email protected]/
Never ask a maintainer to hand-edit a patch, it increases their workload
:(
thanks,
greg k-h