[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86: prevent call to xfree() in dump_irqs() while in an irq context

  • To: Jan Beulich <JBeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Keir Fraser <keir.xen@xxxxxxxxx>
  • Date: Tue, 22 May 2012 15:09:51 +0100
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Tue, 22 May 2012 14:10:10 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac04JI2lmgJNeKimrESQK5veUbEqfg==
  • Thread-topic: [Xen-devel] [PATCH] x86: prevent call to xfree() in dump_irqs() while in an irq context

On 22/05/2012 09:05, "Jan Beulich" <JBeulich@xxxxxxxx> 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 <jbeulich@xxxxxxxx>
>>> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> 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 :)

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.