Message ID | 8d40259f863ed1a077687f3c3d5b8b3707478170.1675632296.git.geoff@infradead.org (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | net/ps3_gelic_net: DMA related fixes | expand |
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@infradead.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. > > - if (!descr->bus_addr) > - goto iommu_error; > + if (unlikely(dma_mapping_error(dev, descr->bus_addr))) { The expectation for dma_mapping_error is that the address is in cpu order. So in this case it is partially correct since bus_addr wasn't byte swapped, but generally the dma address used should be a CPU byte ordered variable. > + dev_err(dev, "%s:%d: dma_mapping_error\n", __func__, > + __LINE__); > + > + for (i--, descr--; i > 0; i--, descr--) { > + if (descr->bus_addr) { So I am pretty sure this is broken. Usually for something like this I will resort to just doing a while (i--) as "i == 0" should be a valid buffer to have to unmap. Maybe something like: while (i--) { descr--; Also I think you can get rid of the if since descr->bus_addr should be valid for all values since you populated it just a few lines above for each value of i. > + dma_unmap_single(ctodev(card), > + descr->bus_addr, > + GELIC_DESCR_SIZE, > + DMA_BIDIRECTIONAL); > + } > + } > + return -ENOMEM; > + } > > descr->next = descr + 1; > descr->prev = descr - 1; > @@ -334,8 +346,7 @@ static int gelic_card_init_chain(struct gelic_card *card, > start_descr->prev = (descr - 1); > > /* chain bus addr of hw descriptor */ > - descr = start_descr; > - for (i = 0; i < no; i++, descr++) { > + for (i = 0, descr = start_descr; i < no; i++, descr++) { > descr->next_descr_addr = cpu_to_be32(descr->next->bus_addr); > } > This seems like an unrelated change that was snuck in. > @@ -346,14 +357,6 @@ static int gelic_card_init_chain(struct gelic_card *card, > (descr - 1)->next_descr_addr = 0; > > return 0; > - > -iommu_error: > - for (i--, descr--; 0 <= i; i--, descr--) > - if (descr->bus_addr) > - dma_unmap_single(ctodev(card), descr->bus_addr, > - GELIC_DESCR_SIZE, > - DMA_BIDIRECTIONAL); > - return -ENOMEM; > } > > /** > @@ -407,19 +410,18 @@ static int gelic_descr_prepare_rx(struct gelic_card *card, > cpu_addr = dma_map_single(dev, descr->skb->data, descr->buf_size, > DMA_FROM_DEVICE); > > - descr->buf_addr = cpu_to_be32(cpu_addr); > - > - if (!descr->buf_addr) { > + if (unlikely(dma_mapping_error(dev, cpu_addr))) { > + dev_err(dev, "%s:%d: dma_mapping_error\n", __func__, __LINE__); > dev_kfree_skb_any(descr->skb); > descr->buf_addr = 0; > descr->buf_size = 0; > descr->skb = NULL; > - dev_info(dev, > - "%s:Could not iommu-map rx buffer\n", __func__); > gelic_descr_set_status(descr, GELIC_DESCR_DMA_NOT_IN_USE); > return -ENOMEM; > } > > + descr->buf_addr = cpu_to_be32(cpu_addr); > + Okay, so this addresses the comment I had in the earlier patch. > gelic_descr_set_status(descr, GELIC_DESCR_DMA_CARDOWNED); > return 0; > } > @@ -775,6 +777,7 @@ static int gelic_descr_prepare_tx(struct gelic_card *card, > struct gelic_descr *descr, > struct sk_buff *skb) > { > + struct device *dev = ctodev(card); > dma_addr_t buf; > > if (card->vlan_required) { > @@ -789,11 +792,10 @@ static int gelic_descr_prepare_tx(struct gelic_card *card, > skb = skb_tmp; > } > > - buf = dma_map_single(ctodev(card), skb->data, skb->len, DMA_TO_DEVICE); > + buf = dma_map_single(dev, skb->data, skb->len, DMA_TO_DEVICE); > > - if (!buf) { > - dev_err(ctodev(card), > - "dma map 2 failed (%p, %i). Dropping packet\n", > + if (unlikely(dma_mapping_error(dev, buf))) { > + dev_err(dev, "dma map 2 failed (%p, %i). Dropping packet\n", > skb->data, skb->len); > return -ENOMEM; > }
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@infradead.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. >> - if (!descr->bus_addr) >> - goto iommu_error; >> + if (unlikely(dma_mapping_error(dev, descr->bus_addr))) { > > The expectation for dma_mapping_error is that the address is in cpu > order. So in this case it is partially correct since bus_addr wasn't > byte swapped, but generally the dma address used should be a CPU byte > ordered variable. > >> + dev_err(dev, "%s:%d: dma_mapping_error\n", __func__, >> + __LINE__); >> + >> + for (i--, descr--; i > 0; i--, descr--) { >> + if (descr->bus_addr) { > > So I am pretty sure this is broken. Usually for something like this I > will resort to just doing a while (i--) as "i == 0" should be a valid > buffer to have to unmap. > > Maybe something like: > while (i--) { > descr--; > > Also I think you can get rid of the if since descr->bus_addr should be > valid for all values since you populated it just a few lines above for > each value of i. OK, I'll change that. >> + dma_unmap_single(ctodev(card), >> + descr->bus_addr, >> + GELIC_DESCR_SIZE, >> + DMA_BIDIRECTIONAL); >> + } >> + } >> + return -ENOMEM; >> + } >> >> descr->next = descr + 1; >> descr->prev = descr - 1; >> @@ -334,8 +346,7 @@ static int gelic_card_init_chain(struct gelic_card *card, >> start_descr->prev = (descr - 1); >> >> /* chain bus addr of hw descriptor */ >> - descr = start_descr; >> - for (i = 0; i < no; i++, descr++) { >> + for (i = 0, descr = start_descr; i < no; i++, descr++) { >> descr->next_descr_addr = cpu_to_be32(descr->next->bus_addr); >> } >> > > This seems like an unrelated change that was snuck in. I'll remove that. Once again, thanks for the review. -Geoff
On Sun, Feb 12, 2023 at 9:06 AM Geoff Levand <geoff@infradead.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@infradead.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
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); - if (!descr->bus_addr) - goto iommu_error; + if (unlikely(dma_mapping_error(dev, descr->bus_addr))) { + dev_err(dev, "%s:%d: dma_mapping_error\n", __func__, + __LINE__); + + for (i--, descr--; i > 0; i--, descr--) { + if (descr->bus_addr) { + dma_unmap_single(ctodev(card), + descr->bus_addr, + GELIC_DESCR_SIZE, + DMA_BIDIRECTIONAL); + } + } + return -ENOMEM; + } descr->next = descr + 1; descr->prev = descr - 1; @@ -334,8 +346,7 @@ static int gelic_card_init_chain(struct gelic_card *card, start_descr->prev = (descr - 1); /* chain bus addr of hw descriptor */ - descr = start_descr; - for (i = 0; i < no; i++, descr++) { + for (i = 0, descr = start_descr; i < no; i++, descr++) { descr->next_descr_addr = cpu_to_be32(descr->next->bus_addr); } @@ -346,14 +357,6 @@ static int gelic_card_init_chain(struct gelic_card *card, (descr - 1)->next_descr_addr = 0; return 0; - -iommu_error: - for (i--, descr--; 0 <= i; i--, descr--) - if (descr->bus_addr) - dma_unmap_single(ctodev(card), descr->bus_addr, - GELIC_DESCR_SIZE, - DMA_BIDIRECTIONAL); - return -ENOMEM; } /** @@ -407,19 +410,18 @@ static int gelic_descr_prepare_rx(struct gelic_card *card, cpu_addr = dma_map_single(dev, descr->skb->data, descr->buf_size, DMA_FROM_DEVICE); - descr->buf_addr = cpu_to_be32(cpu_addr); - - if (!descr->buf_addr) { + if (unlikely(dma_mapping_error(dev, cpu_addr))) { + dev_err(dev, "%s:%d: dma_mapping_error\n", __func__, __LINE__); dev_kfree_skb_any(descr->skb); descr->buf_addr = 0; descr->buf_size = 0; descr->skb = NULL; - dev_info(dev, - "%s:Could not iommu-map rx buffer\n", __func__); gelic_descr_set_status(descr, GELIC_DESCR_DMA_NOT_IN_USE); return -ENOMEM; } + descr->buf_addr = cpu_to_be32(cpu_addr); + gelic_descr_set_status(descr, GELIC_DESCR_DMA_CARDOWNED); return 0; } @@ -775,6 +777,7 @@ static int gelic_descr_prepare_tx(struct gelic_card *card, struct gelic_descr *descr, struct sk_buff *skb) { + struct device *dev = ctodev(card); dma_addr_t buf; if (card->vlan_required) { @@ -789,11 +792,10 @@ static int gelic_descr_prepare_tx(struct gelic_card *card, skb = skb_tmp; } - buf = dma_map_single(ctodev(card), skb->data, skb->len, DMA_TO_DEVICE); + buf = dma_map_single(dev, skb->data, skb->len, DMA_TO_DEVICE); - if (!buf) { - dev_err(ctodev(card), - "dma map 2 failed (%p, %i). Dropping packet\n", + if (unlikely(dma_mapping_error(dev, buf))) { + dev_err(dev, "dma map 2 failed (%p, %i). Dropping packet\n", skb->data, skb->len); return -ENOMEM; }
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@infradead.org> --- drivers/net/ethernet/toshiba/ps3_gelic_net.c | 52 ++++++++++---------- 1 file changed, 27 insertions(+), 25 deletions(-)