netdev - Re: [PATCH net v4 2/2] net/ps3_gelic_net: Use dma_mapping

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] [day] [month] [year] [list]

Date:   Mon, 13 Feb 2023 07:21:27 -0800
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     Geoff Levand <geoff@...radead.org>
Cc:     netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net v4 2/2] net/ps3_gelic_net: Use dma_mapping_error

On Sun, Feb 12, 2023 at 9:06 AM Geoff Levand <geoff@...radead.org> wrote:
>
> Hi Alexander,
>
> On 2/6/23 08:37, Alexander H Duyck wrote:
> > On Sun, 2023-02-05 at 22:10 +0000, Geoff Levand wrote:
> >> The current Gelic Etherenet driver was checking the return value of its
> >> dma_map_single call, and not using the dma_mapping_error() routine.
> >>
> >> Fixes runtime problems like these:
> >>
> >>   DMA-API: ps3_gelic_driver sb_05: device driver failed to check map error
> >>   WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:1027 .check_unmap+0x888/0x8dc
> >>
> >> Fixes: 02c1889166b4 (ps3: gigabit ethernet driver for PS3, take3)
> >> Signed-off-by: Geoff Levand <geoff@...radead.org>
> >> ---
> >>  drivers/net/ethernet/toshiba/ps3_gelic_net.c | 52 ++++++++++----------
> >>  1 file changed, 27 insertions(+), 25 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
> >> index 7a8b5e1e77a6..5622b512e2e4 100644
> >> --- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
> >> +++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
> >> @@ -309,22 +309,34 @@ static int gelic_card_init_chain(struct gelic_card *card,
> >>                               struct gelic_descr_chain *chain,
> >>                               struct gelic_descr *start_descr, int no)
> >>  {
> >> -    int i;
> >> +    struct device *dev = ctodev(card);
> >>      struct gelic_descr *descr;
> >> +    int i;
> >>
> >> -    descr = start_descr;
> >> -    memset(descr, 0, sizeof(*descr) * no);
> >> +    memset(start_descr, 0, no * sizeof(*start_descr));
> >>
> >>      /* set up the hardware pointers in each descriptor */
> >> -    for (i = 0; i < no; i++, descr++) {
> >> +    for (i = 0, descr = start_descr; i < no; i++, descr++) {
> >>              gelic_descr_set_status(descr, GELIC_DESCR_DMA_NOT_IN_USE);
> >>              descr->bus_addr =
> >>                      dma_map_single(ctodev(card), descr,
> >>                                     GELIC_DESCR_SIZE,
> >>                                     DMA_BIDIRECTIONAL);
> >
> > Are bus_addr and the CPU the same byte ordering? Just wondering since
> > this is being passed raw. I would have expected it to go through a
> > cpu_to_be32.
>
> As I mentioned in my reply to the first patch, the PS3's CPU is
> big endian, so we really don't need any of the endian conversions.

My advice would be to still make use of the cpu_to_be32 macros. It
will take care of any possible byte ordering issues should you work
with a different CPU architecture in the future. Otherwise if you are
certain that the values will always be CPU ordered you might try
changing the type rather than using __be32 for your descriptor
variable types.

For example most PCIe hardware is using a little endian architecture
and on x86 we don't need to do the byte swapping since the cpu is
little endian. However we still use cpu_to_le32 throughout most
drivers.

You might read through the documentation for sparse at:
https://www.kernel.org/doc/html/latest/dev-tools/sparse.html