From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suresh Siddha Subject: Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state changes Date: Sat, 9 Aug 2008 11:14:06 -0700 Message-ID: <20080809181406.GG13158@linux-os.sc.intel.com> References: <200807171653.59177.wolfgang.walter@stwm.de> <20080806201401.GA607@linux-os.sc.intel.com> <200808071823.02364.wolfgang.walter@stwm.de> <200808081236.55172.wolfgang.walter@stwm.de> <20080808185356.GC607@linux-os.sc.intel.com> <489C97FB.2030408@zytor.com> <20080808231121.GA13158@linux-os.sc.intel.com> <20080809143727.GA30499@gondor.apana.org.au> <489DC05E.2080901@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Herbert Xu , "Siddha, Suresh B" , Wolfgang Walter , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Ingo Molnar , "viro@ZenIV.linux.org.uk" , "vegard.nossum@gmail.com" To: "H. Peter Anvin" Return-path: Received: from mga02.intel.com ([134.134.136.20]:27559 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751586AbYHISOI (ORCPT ); Sat, 9 Aug 2008 14:14:08 -0400 Content-Disposition: inline In-Reply-To: <489DC05E.2080901@zytor.com> Sender: netdev-owner@vger.kernel.org List-ID: On Sat, Aug 09, 2008 at 09:05:50AM -0700, H. Peter Anvin wrote: > Herbert Xu wrote: > > On Fri, Aug 08, 2008 at 04:11:21PM -0700, Suresh Siddha wrote: > >> With out the recent dynamic fpu allocation changes, while we don't see oops, > >> there is a possible race still present in older kernels(for example, > >> while kernel is using kernel_fpu_begin() in some optimized clear/copy > >> page and an interrupt/softirq happens which uses these padlock > >> instructions generating DNA fault). > > > > No this wasn't a problem because kernel_fpu_begin clears TS and > > therefore we don't get faults on SSE instructions. > > > > However, with your patch it will become a problem due to the > > fact that it wasn't designed to be nested. > > > > We're invoking this code from interrupt handlers? Yes. Padlock/ipsec usage seems to be happening in the interrupt context and this triggered the bug that started this thread. thanks, suresh