All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Charan Teja Kalla <quic_charante@quicinc.com>,
	Greg KH <gregkh@linuxfoundation.org>
Cc: sumit.semwal@linaro.org, daniel.vetter@ffwll.ch,
	tjmercier@google.com, linux-media@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dmabuf: ensure unique directory name for dmabuf stats
Date: Tue, 10 May 2022 14:20:17 +0200	[thread overview]
Message-ID: <771f293d-9972-7176-aed3-04e63ef3014d@amd.com> (raw)
In-Reply-To: <cf3a80e3-301d-7c61-54ab-d63fd355dd48@quicinc.com>

Am 10.05.22 um 14:16 schrieb Charan Teja Kalla:
> Thanks Christian for the inputs!!
>
> On 5/10/2022 5:05 PM, Christian König wrote:
>>> And what's to keep the seconds field from also being the same?
>> Well exporting two DMA-bufs with the same ino in the same nanosecond
>> should be basically impossible, but I would rather opt for using a 64bit
>> atomic in that function.
>>
>> This should be 100% UAPI compatible and even if we manage to create one
>> buffer ever ns we need ~500years to wrap around.
> I see that the inode->i_ctime->tv_sec is already defined as
> 64bit(time64_t tv_sec), hence used it. This way we don't need extra
> static atomic_t variable just to get a unique name.
>
> Just pasting excerpt from the reply posted to Greg about why this secs
> will always be a unique: with secs field added, to get the same
> inode-secs string, the uint should overflow in the same second which is
> impossible.
>
> Let me know If you still opt for atomic variable only.

I think just using a static atomic variable here would be cleaner, that 
is 100% unique.

Your approach should probably work as well, but it looks quite constructed.

Regards,
Christian.

WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: Charan Teja Kalla <quic_charante@quicinc.com>,
	Greg KH <gregkh@linuxfoundation.org>
Cc: daniel.vetter@ffwll.ch, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, tjmercier@google.com,
	linaro-mm-sig@lists.linaro.org, sumit.semwal@linaro.org,
	linux-media@vger.kernel.org
Subject: Re: [PATCH] dmabuf: ensure unique directory name for dmabuf stats
Date: Tue, 10 May 2022 14:20:17 +0200	[thread overview]
Message-ID: <771f293d-9972-7176-aed3-04e63ef3014d@amd.com> (raw)
In-Reply-To: <cf3a80e3-301d-7c61-54ab-d63fd355dd48@quicinc.com>

Am 10.05.22 um 14:16 schrieb Charan Teja Kalla:
> Thanks Christian for the inputs!!
>
> On 5/10/2022 5:05 PM, Christian König wrote:
>>> And what's to keep the seconds field from also being the same?
>> Well exporting two DMA-bufs with the same ino in the same nanosecond
>> should be basically impossible, but I would rather opt for using a 64bit
>> atomic in that function.
>>
>> This should be 100% UAPI compatible and even if we manage to create one
>> buffer ever ns we need ~500years to wrap around.
> I see that the inode->i_ctime->tv_sec is already defined as
> 64bit(time64_t tv_sec), hence used it. This way we don't need extra
> static atomic_t variable just to get a unique name.
>
> Just pasting excerpt from the reply posted to Greg about why this secs
> will always be a unique: with secs field added, to get the same
> inode-secs string, the uint should overflow in the same second which is
> impossible.
>
> Let me know If you still opt for atomic variable only.

I think just using a static atomic variable here would be cleaner, that 
is 100% unique.

Your approach should probably work as well, but it looks quite constructed.

Regards,
Christian.

  reply	other threads:[~2022-05-10 12:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-10 10:23 [PATCH] dmabuf: ensure unique directory name for dmabuf stats Charan Teja Kalla
2022-05-10 10:23 ` Charan Teja Kalla
2022-05-10 11:00 ` Greg KH
2022-05-10 11:00   ` Greg KH
2022-05-10 11:35   ` Christian König
2022-05-10 11:35     ` Christian König
2022-05-10 12:10     ` Greg KH
2022-05-10 12:10       ` Greg KH
2022-05-10 12:52       ` [Linaro-mm-sig] " Christian König
2022-05-10 12:52         ` Christian König
2022-05-10 12:16     ` Charan Teja Kalla
2022-05-10 12:16       ` Charan Teja Kalla
2022-05-10 12:20       ` Christian König [this message]
2022-05-10 12:20         ` Christian König
2022-05-10 11:55   ` Charan Teja Kalla
2022-05-10 11:55     ` Charan Teja Kalla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=771f293d-9972-7176-aed3-04e63ef3014d@amd.com \
    --to=christian.koenig@amd.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=quic_charante@quicinc.com \
    --cc=sumit.semwal@linaro.org \
    --cc=tjmercier@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.