From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [Pv-ops][PATCH] Netback multiple tasklet support Date: Fri, 11 Dec 2009 08:34:07 +0000 Message-ID: <4B22120F02000078000251EF@vpn.id2.novell.com> References: <4FA716B1526C7C4DB0375C6DADBC4EA342A7A7E951@LONPMAILBOX01.citrite.net> <4FA716B1526C7C4DB0375C6DADBC4EA342A7A7E95E@LONPMAILBOX01.citrite.net> <4B182D87.6030901@goop.org> <4B187513.80003@goop.org> <4B200727.8040000@goop.org> <1260436078.23698.45463.camel@zakaz.uk.xensource.com> <4B2135CC.6000004@goop.org> <1260468444.3057.7.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1260468444.3057.7.camel@localhost.localdomain> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell , Jeremy Fitzhardinge Cc: Steven Smith , Ian Pratt , "xen-devel@lists.xensource.com" , Dongxiao Xu List-Id: xen-devel@lists.xenproject.org >>> Ian Campbell 10.12.09 19:07 >>> >On Thu, 2009-12-10 at 17:54 +0000, Jeremy Fitzhardinge wrote:=20 >> On 12/10/09 01:07, Ian Campbell wrote: >> > Subject: xen: ensure locking gnttab_copy_grant_page is safe against = interrupts. >> > >> > Now that netback processing occurs in a thread instead of a tasklet >> > gnttab_copy_grant_page needs to be safe against interrupts. >> > >> > The code is currently commented out in this tree but on 2.6.18 we = observed a >> > deadlock where the netback thread called gnttab_copy_grant_page, = locked >> > gnttab_dma_lock for writing, was interrupted and on return from = interrupt the >> > network stack's TX tasklet ended up calling __gnttab_dma_map_page via = the >> > hardware driver->swiotlb and tries to take gnttab_dma_lock for = reading. >> > >> > Correct the commented code so we don't get bitten if/when it is = re-enabled. >> > =20 >>=20 >> What's the issue here? > >a deadlock if someone naively uncomments the existing code. Btw., can any of you explain why 2.6.18 needs this (and the related) code, but pv-ops doesn't? Thanks, Jan