From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] x86: prevent call to xfree() in dump_irqs() while in an irq context Date: Tue, 22 May 2012 15:09:51 +0100 Message-ID: References: <4FBB6502020000780008505C@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4FBB6502020000780008505C@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Andrew Cooper Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 22/05/2012 09:05, "Jan Beulich" wrote: >>>> Rather than using the non-obvious conditional around an xfree() that >>>> would be passed NULL only in the inverse case (which could easily get >>>> removed by a future change on the basis that calling xfree(NULL) is >>>> benign), switch the order of checks in xfree() itself and only suppress >>>> the call to XSM that could potentially call xmalloc(). >>>> >>>> Signed-off-by: Jan Beulich >>> >>> Acked-by: Andrew Cooper >> >> I'm a bit dubious about having a function that can be called in irq context >> for some input values but not others. I suppose this trivial case for >> xfree() is obvious enough, so I'm okay with it. If it was anything more >> subtle, I would probably nack. > > I did ask that in the original thread, but you never responded > either way. Is your above reply an ack then, or should I commit > Andy's original patch instead? It's an Ack :)