Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <771f293d-9972-7176-aed3-04e63ef3014d@amd.com>
Date:   Tue, 10 May 2022 14:20:17 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: [PATCH] dmabuf: ensure unique directory name for dmabuf stats
Content-Language: en-US
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
References: <1652178212-22383-1-git-send-email-quic_charante@quicinc.com>
 <YnpF1XP1tH83uBlM@kroah.com> <039e1acc-8688-2e06-1b2a-1acbe813b91e@amd.com>
 <cf3a80e3-301d-7c61-54ab-d63fd355dd48@quicinc.com>
From:   =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>
In-Reply-To: <cf3a80e3-301d-7c61-54ab-d63fd355dd48@quicinc.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aWhNQWJGWDUzeEZaL3laaWY5bTN2dlZJSGtDS2lXNHpKVFpIVnRNcE1kbisy?=
 =?utf-8?B?MDVTYUVxcU5Jb2cyeUk5RDY5MzE3bjAvcnpwWU10ODdsQ1pxRkJCMXVlWFBp?=
 =?utf-8?B?STFjYkY5ZElCTHRhVTlSbzgxMnFOYW9CQzBCRXFPbGtWcEJraUVaUWtGT0xu?=
 =?utf-8?B?bFhIQVVMdjJWYUtiS3FPUERleDhMVWNKb283WWFsYnNoT2p1Tmd3QzFRTDNr?=
 =?utf-8?B?OEoyUFZwK00zT0tMYVgrcVAzcVhHcXFwRzZFVkdZWWphb05zS0RRWkhLZGJE?=
 =?utf-8?B?OS96N3RkN1RVVGE1RVBYL1h1K0RYN0h1czJkVlBEUWdHTU9xZENXV0hzQ3FD?=
 =?utf-8?B?ZmVxNnYya0lpMXRWc01sQWF1b1VlcE93c2loQjg2OU5GNm5jUCtjMG5MTmVP?=
 =?utf-8?B?VXRZcXJSNkFnclU5NXI1UWV4bjdSUjBLMUpNM2J4OVRPSWU1R2Q1VzdqakJO?=
 =?utf-8?B?OExsYmRFZVZZd0s5OGZvOW9BU3Q4QnpxSEoxTE9SdERtUzVrRnZVSWhyUmky?=
 =?utf-8?B?MkhoY3czNU1yNkZWbjZFNmZlYW5veHhEVHZVeTNEa3BlVDZnRjNpd0M2dTIr?=
 =?utf-8?B?djBxUlYveExHckdHRi9teHdIUzdncTBnQ2VMLzdxMi8xRy9PLzJkZmZyVGVM?=
 =?utf-8?B?dGVCQUt1L05KeXZjd1lCSHpqaE1PSG5jV3Fvc3ZoUU9RRDJzaUo1cm02cE0w?=
 =?utf-8?B?TmZKQzEyUk9sdHFsZVJqKzBtMm9CcFNGK0NwWGJMVHdqaWRjampiZTA0eFc4?=
 =?utf-8?B?T2NuYksxczd6RTFwWnZ2cFFBQUJRMFVOcG1JbXplaFBpRlU5d0VzY1grY1RQ?=
 =?utf-8?B?SjBRTERFcE1iSVNBWjlzNVFPZEpGSWRkMUdzaGkwNDYrOWpkT2IrWnozL2ZP?=
 =?utf-8?B?d2wvRDhFVEdCQlJQN0JLZFAwL3U5NHlPSUR3NjJ6bmoveFdIR2VQUitHbWpR?=
 =?utf-8?B?eHVLZjlrUmV4dlNBMUo0bk9Db3ViQVlZUVgwUDNoc25lTE1OZ2lKTDhqQ3kv?=
 =?utf-8?B?dVlkam40S0svWTF4c2NrazIxbjE2VGEyaFVKOVhrZEM0UGN0UW53RVFQdHUz?=
 =?utf-8?B?UWV6L1pTc2JVYnN6WjlVOWFEMWlWbjIrMGN6ZER6T0ZIclNISVpnT1VoSjVp?=
 =?utf-8?B?QTgvN2M1N3k1Y0hUMWFzMFl4WU9rRnJKYXVjNDdPV00wZ0RzRHg2Tmx4N05i?=
 =?utf-8?B?d0xTVTNPOWJkTHh4bE04Sk50U0N6N0tnUjRjQ0hoTlE4emc4ekdjRHdFMUJI?=
 =?utf-8?B?QU1FeTV4cTZHTU5qSUZMc0Q3MmhjZUVDckxuUVhOSDNqSzA4d20xNW03aTJ3?=
 =?utf-8?B?aVllSHppUG10TXVrcmR3U2l6Unp4dkhtZm9iQjFlTjdTSkE4YkNjRTNuZnl0?=
 =?utf-8?B?SXRTMFRKMzhRYmNxRGo1bXhiZ0QvdXdKWGhRYUZxaFdwL3BSd01KZFptbkhW?=
 =?utf-8?B?blpOMDh5blZzaWUrZksvVFNyZ1lRZTk3QWdBU1REOEF0NGw2MUNSR05ZVlVa?=
 =?utf-8?B?cGpFUjJkaUtueGNiekdaOHc3TkVidHNia0V3WG1mZEZDQXQyemcvWENJa040?=
 =?utf-8?B?YW9EaERqc1pKT3VmNmo0aSthZk9Gd0Q2NmhYMzNSMFBwTGpGNWprVWxzZ1V2?=
 =?utf-8?B?UWNBbGxKYzBNdmRTS3cydG5BZ2dNZStJMC90VGtMaUZBVXQ5eXZEQVYwdVRH?=
 =?utf-8?B?WG1JSkRJZjlTVzZDVElBeFZLZlpuaUZNVEZzM3Jpd1RwS0tPVnBpNm5HcTVX?=
 =?utf-8?B?ZGZqWU9sYVBIRHNORFhDZEZhS1BsR0hLSGZyVStwSVlFenMvNDJxeFFJY3cw?=
 =?utf-8?B?K3ZwK1FESU9GeXM1SWlwZ0sxcENlclhZdnRwaFhqSENQNm5zejRZbExLVklz?=
 =?utf-8?B?RHVTM09ER0JjU3hOVW5XbXZYUzBBZWlsbFN6WjFtM2JnUnZWdVpUYWFBQUFa?=
 =?utf-8?B?bnNNM1Bpbm1SUlhGWStONmk1K0J2a2pqZGFBS2V1WXNtMVJ6dTF6OXdlejdU?=
 =?utf-8?B?MHFKaFZtQUJBbnpYNmV5Y1kzWlNiWG5FaEk1QnZWaWRGbWxjSXFvRHQ2eFZw?=
 =?utf-8?B?R09yUGhUUVhFWTVORE0xVDFOZTF4NTdWSitUa0ZaVGtrYU1nYVlwbUt6QmRs?=
 =?utf-8?B?ZXh4Umo3eHZ2SjlTeUo2bFE4dWFOSHZrRGFtbGI0SGlJVzhoOVEvOWRRSjJY?=
 =?utf-8?B?UnNwTjBvcGI0cFU2Z2hieUFjbmp5KzkrcEFKM2RaaUo3cDV0YmJGbS9ENnpL?=
 =?utf-8?B?ckh5V2dkbEhHWFFoUnBpTG4rbk1BMGpESmJ1NlNUWEgrdEhnSFFpN3VuQUtP?=
 =?utf-8?B?MmlqTUlSdXNVSTlmb1NqL1d0RTV6UXZsNWRTdHRtYVhPQ2hZeGJCZ0VsQ0dt?=
 =?utf-8?Q?/n+rhBWsgDHYWhgKEbhsMn0n59v7Hze6OrnHb6m7DRp3T?=
X-MS-Exchange-AntiSpam-MessageData-1: /XdL2OJ76UJPIg==
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 370a1dd6-b620-4e3d-510e-08da327f74c2
X-MS-Exchange-CrossTenant-AuthSource: BN8PR12MB3587.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2022 12:20:22.9192
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: /cs3awLV7/eBCmrMFKgXVaNQ0ZLxFVI9JSMekGh4zNifE8aQ7kNJT/hkX9G5+zk9
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4714
X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE,
        URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.