From: Niklas Cassel <cassel@kernel.org>
To: Hans Zhang <18255117159@163.com>
Cc: manivannan.sadhasivam@linaro.org, kw@linux.com,
kishon@kernel.org, arnd@arndb.de, gregkh@linuxfoundation.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
rockswang7@gmail.com
Subject: Re: [v8] misc: pci_endpoint_test: Fix overflow of bar_size
Date: Mon, 6 Jan 2025 12:49:01 +0100 [thread overview]
Message-ID: <Z3vDLcq9kWL4ueq7@ryzen> (raw)
In-Reply-To: <20250104151652.1652181-1-18255117159@163.com>
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@163.com>
> Reviewed-by: Niklas Cassel <cassel@kernel.org>
> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.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
>
next prev parent reply other threads:[~2025-01-06 11:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-04 15:16 [v8] misc: pci_endpoint_test: Fix overflow of bar_size Hans Zhang
2025-01-06 11:49 ` Niklas Cassel [this message]
2025-01-06 13:56 ` Hans Zhang
2025-01-06 15:32 ` Hans Zhang
2025-01-07 10:32 ` Niklas Cassel
2025-01-07 11:27 ` Hans Zhang
2025-01-07 11:33 ` Niklas Cassel
2025-01-07 11:43 ` Hans Zhang
2025-01-07 11:47 ` Niklas Cassel
2025-01-07 12:09 ` Hans Zhang
2025-01-07 13:36 ` Niklas Cassel
2025-01-07 15:44 ` Hans Zhang
2025-01-07 15:57 ` Niklas Cassel
2025-01-07 16:12 ` Hans Zhang
2025-01-08 14:10 ` Arnd Bergmann
2025-01-08 14:13 ` Niklas Cassel
2025-01-09 2:59 ` Hans Zhang
2025-01-09 6:29 ` Arnd Bergmann
2025-01-09 9:19 ` Hans Zhang
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=Z3vDLcq9kWL4ueq7@ryzen \
--to=cassel@kernel.org \
--cc=18255117159@163.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=kishon@kernel.org \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=rockswang7@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox