Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

[PATCH] e100: Do pci_dma_sync after skb_alloc for proper operation on ixp4xx

 

 

Linux kernel RSS feed   Index | Next | Previous | View Threaded


kexin.hao at windriver

Jun 21, 2008, 3:20 AM

Post #1 of 3 (387 views)
Permalink
[PATCH] e100: Do pci_dma_sync after skb_alloc for proper operation on ixp4xx

Hi,

The E100 device can't work on current kernel (2.6.26-rc6) and will cause
kernel corruption on intel ixdp4xx. This patch fix this regression.

---
commit c1f24812b9de182a4272724a2e84ea1ae5dd4659
Author: Kevin Hao <kexin.hao[at]windriver.com>
Date: Sat Jun 21 16:50:50 2008 +0800

e100: Do pci_dma_sync after skb_alloc for proper operation on ixp4xx

Do a DMA sync after we've allocated a new skb and link it with the previous
RFD. Otherwise the previous RFD may reference the previously freed skb
and cause kernel corruption.

Previously there was such a DMA sync at this place, but it was removed
by commit 7734f6e6bcd7ba78b00e93e74a4ddafd9886cdea.
Restoring this sync operation eliminates the regression.

Signed-off-by: Kevin Hao <kexin.hao[at]windriver.com>

diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index f3cba5e..1037b13 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -1803,6 +1803,8 @@ static int e100_rx_alloc_skb(struct nic *nic, struct rx *rx)
if (rx->prev->skb) {
struct rfd *prev_rfd = (struct rfd *)rx->prev->skb->data;
put_unaligned_le32(rx->dma_addr, &prev_rfd->link);
+ pci_dma_sync_single_for_device(nic->pdev, rx->prev->dma_addr,
+ sizeof(struct rfd), PCI_DMA_TODEVICE);
}

return 0;
---

Best Regards,
Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


dacker at roinet

Jun 21, 2008, 6:51 PM

Post #2 of 3 (334 views)
Permalink
Re: [PATCH] e100: Do pci_dma_sync after skb_alloc for proper operation on ixp4xx [In reply to]

Kevin Hao wrote:
> Hi,
>
> The E100 device can't work on current kernel (2.6.26-rc6) and will cause
> kernel corruption on intel ixdp4xx. This patch fix this regression.
>
Hello, this is pretty much the same patch that Anders Grafström sent on
6/18. I think it looks good; I am sorry I missed this. I think this
can be ok'ed if folks can test it on a few different ARM platforms and
of course x86.

I am getting sinus surgery this Monday but I should be back in the
office within a week. I will give it a try then. I will test it on an
ixp425 board and an PXA255 board. Just so you know, I found the
in-kernel packet generator to be a good test. I also found using the
board as a router between wired and wireless devices to catch issues
that led me to posting patches for this driver in the first place.

-ack

> ---
> commit c1f24812b9de182a4272724a2e84ea1ae5dd4659
> Author: Kevin Hao <kexin.hao[at]windriver.com>
> Date: Sat Jun 21 16:50:50 2008 +0800
>
> e100: Do pci_dma_sync after skb_alloc for proper operation on ixp4xx
>
> Do a DMA sync after we've allocated a new skb and link it with the previous
> RFD. Otherwise the previous RFD may reference the previously freed skb
> and cause kernel corruption.
>
> Previously there was such a DMA sync at this place, but it was removed
> by commit 7734f6e6bcd7ba78b00e93e74a4ddafd9886cdea.
> Restoring this sync operation eliminates the regression.
>
> Signed-off-by: Kevin Hao <kexin.hao[at]windriver.com>
>
> diff --git a/drivers/net/e100.c b/drivers/net/e100.c
> index f3cba5e..1037b13 100644
> --- a/drivers/net/e100.c
> +++ b/drivers/net/e100.c
> @@ -1803,6 +1803,8 @@ static int e100_rx_alloc_skb(struct nic *nic, struct rx *rx)
> if (rx->prev->skb) {
> struct rfd *prev_rfd = (struct rfd *)rx->prev->skb->data;
> put_unaligned_le32(rx->dma_addr, &prev_rfd->link);
> + pci_dma_sync_single_for_device(nic->pdev, rx->prev->dma_addr,
> + sizeof(struct rfd), PCI_DMA_TODEVICE);
> }
>
> return 0;
> ---
>
> Best Regards,
> Kevin
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jeff at garzik

Jun 26, 2008, 10:32 PM

Post #3 of 3 (314 views)
Permalink
Re: [PATCH] e100: Do pci_dma_sync after skb_alloc for proper operation on ixp4xx [In reply to]

Kevin Hao wrote:
> Hi,
>
> The E100 device can't work on current kernel (2.6.26-rc6) and will cause
> kernel corruption on intel ixdp4xx. This patch fix this regression.
>
> ---
> commit c1f24812b9de182a4272724a2e84ea1ae5dd4659
> Author: Kevin Hao <kexin.hao[at]windriver.com>
> Date: Sat Jun 21 16:50:50 2008 +0800
>
> e100: Do pci_dma_sync after skb_alloc for proper operation on ixp4xx
>
> Do a DMA sync after we've allocated a new skb and link it with the previous
> RFD. Otherwise the previous RFD may reference the previously freed skb
> and cause kernel corruption.
>
> Previously there was such a DMA sync at this place, but it was removed
> by commit 7734f6e6bcd7ba78b00e93e74a4ddafd9886cdea.
> Restoring this sync operation eliminates the regression.
>
> Signed-off-by: Kevin Hao <kexin.hao[at]windriver.com>
>
> diff --git a/drivers/net/e100.c b/drivers/net/e100.c
> index f3cba5e..1037b13 100644
> --- a/drivers/net/e100.c
> +++ b/drivers/net/e100.c
> @@ -1803,6 +1803,8 @@ static int e100_rx_alloc_skb(struct nic *nic, struct rx *rx)
> if (rx->prev->skb) {
> struct rfd *prev_rfd = (struct rfd *)rx->prev->skb->data;
> put_unaligned_le32(rx->dma_addr, &prev_rfd->link);
> + pci_dma_sync_single_for_device(nic->pdev, rx->prev->dma_addr,
> + sizeof(struct rfd), PCI_DMA_TODEVICE);

applied


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.