[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z3vDLcq9kWL4ueq7@ryzen>
Date: Mon, 6 Jan 2025 12:49:01 +0100
From: Niklas Cassel <cassel@...nel.org>
To: Hans Zhang <18255117159@....com>
Cc: manivannan.sadhasivam@...aro.org, kw@...ux.com, kishon@...nel.org,
arnd@...db.de, gregkh@...uxfoundation.org,
linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
rockswang7@...il.com
Subject: Re: [v8] misc: pci_endpoint_test: Fix overflow of bar_size
On Sat, Jan 04, 2025 at 11:16:52PM +0800, Hans Zhang wrote:
> With 8GB BAR2, running pcitest -b 2 fails with "TEST FAILED".
>
> The return value of the `pci_resource_len` interface is not an integer.
> Using `pcitest` with an 8GB BAR2, the bar_size of integer type will
> overflow.
>
> Change the data type of bar_size from integer to resource_size_t, to fix
> the above issue.
>
> Signed-off-by: Hans Zhang <18255117159@....com>
> Reviewed-by: Niklas Cassel <cassel@...nel.org>
> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
When significantly changing the patch from one version to another,
(as in this case), you are supposed to drop the Reviewed-by tags.
Doing a:
$ git grep -A 10 "IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT"
does not show very many hits, which suggests that this is not the proper
way to solve this.
I don't know the proper solution to this. How is resource_size_t handled
in other PCI driver when being built on with 32-bit PHYS_ADDR_T ?
Can't you just cast the resource_size_t to u64 before doing the division?
> ---
> Changes since v8:
>
> - Add reviewer.
>
> Changes since v4-v7:
> https://lore.kernel.org/linux-pci/20250102120222.1403906-1-18255117159@163.com/
> https://lore.kernel.org/linux-pci/20250101151509.570341-1-18255117159@163.com/
>
> - Fix 32-bit OS warnings and errors.
> - Fix undefined reference to `__udivmoddi4`
>
> Changes since v3:
> https://lore.kernel.org/linux-pci/20241221141009.27317-1-18255117159@163.com/
>
> - The patch subject were modified.
>
> Changes since v2:
> https://lore.kernel.org/linux-pci/20241220075253.16791-1-18255117159@163.com/
>
> - Fix "changes" part goes below the --- line
> - The patch commit message were modified.
>
> Changes since v1:
> https://lore.kernel.org/linux-pci/20241217121220.19676-1-18255117159@163.com/
>
> - The patch subject and commit message were modified.
> ---
> drivers/misc/pci_endpoint_test.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
> index 3aaaf47fa4ee..50d4616119af 100644
> --- a/drivers/misc/pci_endpoint_test.c
> +++ b/drivers/misc/pci_endpoint_test.c
> @@ -280,10 +280,11 @@ static int pci_endpoint_test_bar_memcmp(struct pci_endpoint_test *test,
> static bool pci_endpoint_test_bar(struct pci_endpoint_test *test,
> enum pci_barno barno)
> {
> - int j, bar_size, buf_size, iters, remain;
> void *write_buf __free(kfree) = NULL;
> void *read_buf __free(kfree) = NULL;
> struct pci_dev *pdev = test->pdev;
> + int j, buf_size, iters, remain;
> + resource_size_t bar_size;
>
> if (!test->bar[barno])
> return false;
> @@ -307,13 +308,18 @@ static bool pci_endpoint_test_bar(struct pci_endpoint_test *test,
> if (!read_buf)
> return false;
>
> - iters = bar_size / buf_size;
> + if (IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT)) {
> + remain = do_div(bar_size, buf_size);
> + iters = bar_size;
> + } else {
> + iters = bar_size / buf_size;
> + remain = bar_size % buf_size;
> + }
> for (j = 0; j < iters; j++)
> if (pci_endpoint_test_bar_memcmp(test, barno, buf_size * j,
> write_buf, read_buf, buf_size))
> return false;
>
> - remain = bar_size % buf_size;
> if (remain)
> if (pci_endpoint_test_bar_memcmp(test, barno, buf_size * iters,
> write_buf, read_buf, remain))
>
> base-commit: ccb98ccef0e543c2bd4ef1a72270461957f3d8d0
> --
> 2.25.1
>
Powered by blists - more mailing lists