linux-kernel - Re: [PATCH v17 3/3] vfio/nvgrace-gpu: Add vfio pci variant module for grace hopper

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 9 Feb 2024 09:24:44 +0000
From: Ankit Agrawal <ankita@...dia.com>
To: Alex Williamson <alex.williamson@...hat.com>, "Tian, Kevin"
	<kevin.tian@...el.com>
CC: Zhi Wang <zhi.wang.linux@...il.com>, Jason Gunthorpe <jgg@...dia.com>,
	Yishai Hadas <yishaih@...dia.com>, "mst@...hat.com" <mst@...hat.com>,
	"shameerali.kolothum.thodi@...wei.com"
	<shameerali.kolothum.thodi@...wei.com>, "clg@...hat.com" <clg@...hat.com>,
	"oleksandr@...alenko.name" <oleksandr@...alenko.name>, "K V P, Satyanarayana"
	<satyanarayana.k.v.p@...el.com>, "eric.auger@...hat.com"
	<eric.auger@...hat.com>, "brett.creeley@....com" <brett.creeley@....com>,
	"horms@...nel.org" <horms@...nel.org>, Rahul Rameshbabu
	<rrameshbabu@...dia.com>, Aniket Agashe <aniketa@...dia.com>, Neo Jia
	<cjia@...dia.com>, Kirti Wankhede <kwankhede@...dia.com>, "Tarun Gupta
 (SW-GPU)" <targupta@...dia.com>, Vikram Sethi <vsethi@...dia.com>, Andy
 Currid <acurrid@...dia.com>, Alistair Popple <apopple@...dia.com>, John
 Hubbard <jhubbard@...dia.com>, Dan Williams <danw@...dia.com>, "Anuj Aggarwal
 (SW-GPU)" <anuaggarwal@...dia.com>, Matt Ochs <mochs@...dia.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "virtualization@...ts.linux-foundation.org"
	<virtualization@...ts.linux-foundation.org>
Subject: Re: [PATCH v17 3/3] vfio/nvgrace-gpu: Add vfio pci variant module for
 grace hopper

>> >
>> > IMO, this seems like adding too much code to reduce the call length for a
>> > very specific case. If there aren't any strong opinion on this, I'm planning to
>> > leave this code as it is.
>>
>> a slight difference. if mem_count==0 the result should always succeed
>> no matter nvgrace_gpu_map_device_mem() succeeds or not. Of course
>> if it fails it's already a big problem probably nobody cares about the subtle
>> difference when reading non-exist range.
>>
>> but regarding to readability it's still clearer:
>>
>> if (mem_count)
>>       nvgrace_gpu_map_and_read();
>>
>
> The below has better flow imo vs conditionalizing the call to
> map_and_read/write and subsequent error handling, but I don't think
> either adds too much code.  Thanks,
>
> Alex
>
> --- a/drivers/vfio/pci/nvgrace-gpu/main.c
> +++ b/drivers/vfio/pci/nvgrace-gpu/main.c
> @@ -429,6 +429,9 @@ nvgrace_gpu_map_and_read(struct nvgrace_gpu_vfio_pci_core_device *nvdev,
>         u64 offset = *ppos & VFIO_PCI_OFFSET_MASK;
>         int ret;
>
> +       if (!mem_count)
> +               return 0;
> +
>         /*
>         * Handle read on the BAR regions. Map to the target device memory
>          * physical address and copy to the request read buffer.
> @@ -547,6 +550,9 @@ nvgrace_gpu_map_and_write(struct nvgrace_gpu_vfio_pci_core_device *nvdev,
>         loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
>         int ret;
>
> +       if (!mem_count)
> +               return 0;
> +
>         ret = nvgrace_gpu_map_device_mem(index, nvdev);
>         if (ret)
>                return ret;

Sure, will update it as mentioned above.