linux-kernel - [PATCH][RT] 2.6.24-rc5-rt1 drivers/dma/ioat

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

Message-Id: <1197690973.12832.12.camel@sx.thebigcorporation.com>
Date:	Fri, 14 Dec 2007 19:56:13 -0800
From:	Sven-Thorsten Dietrich <sven@...bigcorporation.com>
To:	Steven Rostedt <rostedt@...dmis.org>, shannon.nelson@...el.com
Cc:	linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org,
	trem <tremyfr@...oo.fr>
Subject: [PATCH][RT] 2.6.24-rc5-rt1 drivers/dma/ioat_dma.c compile fix

Hi Steve, 

looks like this patch didn't make it into 2.6.23-rc5-rt1.

I refreshed Trem's final version - please review and include in the next
RT release.

Thanks 

Sven 



On Tue, 2007-11-20 at 23:09 +0100, trem wrote:
> Steven Rostedt wrote:
> > On Fri, 16 Nov 2007, Nelson, Shannon wrote:
> >> first->async_tx.phys;
> >>> -       __list_splice(&new_chain, ioat_chan->used_desc.prev);
> >>> +       list_splice_tail(&new_chain, ioat_chan->used_desc.prev);
> >>>
> >> NAK.
> >>
> >> These functions do insertions differently.  The 'prev' is pointing
> to
> >> the last valid descriptor in the queue and you really want to get
> the
> >> new_chain stuck on after this.  Your list_splice_tail() will insert
> the
> >> new_chain just before it which will muck up the order of the DMA
> >> requests.
> >>
> >> You might have more success with
> >> 	list_splice_tail(&new_chain, ioat_chan->used_desc);
> >> where used_desc points to the whole list, rather than using
> the .prev
> >> pointer to a specific node.
> >>
> >> Please copy me on future ioatdma related comments.
> >>
> > 

> Hi
> 
> I've tried this change, but it still don't compile. So I propose this patch.
> 
> regards,
> trem


From: trem <tremyfr@...oo.fr>
Subject:  Re: [PATCH][RT] 2.6.24-rc2-rt1 drivers/dma/ioat_dma.c compile fix

Steven Rostedt wrote:
> On Fri, 16 Nov 2007, Nelson, Shannon wrote:
>> first->async_tx.phys;
>>> -       __list_splice(&new_chain, ioat_chan->used_desc.prev);
>>> +       list_splice_tail(&new_chain, ioat_chan->used_desc.prev);
>>>
>> NAK.
>>
>> These functions do insertions differently.  The 'prev' is pointing to
>> the last valid descriptor in the queue and you really want to get the
>> new_chain stuck on after this.  Your list_splice_tail() will insert the
>> new_chain just before it which will muck up the order of the DMA
>> requests.
>>
>> You might have more success with
>> 	list_splice_tail(&new_chain, ioat_chan->used_desc);
>> where used_desc points to the whole list, rather than using the .prev
>> pointer to a specific node.
>>
>> Please copy me on future ioatdma related comments.
>>
> 
> And people wonder why we post RT related patches to LKML. This is exactly
> why!
> 
> Thanks for the response Shannon!
> 
> -- Steve
> 

Hi

I've tried this change, but it still don't compile. So I propose this patch.

regards,
trem

Acked-by: Sven-Thorsten Dietrich <sdietrich@...e.de>

------------------------

---
 drivers/dma/ioat_dma.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.23/drivers/dma/ioat_dma.c
===================================================================
--- linux-2.6.23.orig/drivers/dma/ioat_dma.c
+++ linux-2.6.23/drivers/dma/ioat_dma.c
@@ -260,7 +260,7 @@ static dma_cookie_t ioat1_tx_submit(stru
 	/* write address into NextDescriptor field of last desc in chain */
 	to_ioat_desc(ioat_chan->used_desc.prev)->hw->next =
 							first->async_tx.phys;
-	__list_splice(&new_chain, ioat_chan->used_desc.prev);
+	list_splice(&new_chain, &ioat_chan->used_desc);
 
 	ioat_chan->dmacount += desc_count;
 	ioat_chan->pending += desc_count;



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