From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org, mingo@elte.hu,
xen-devel@lists.xensource.com, tglx@linutronix.de
Subject: Re: [PATCH 4/5] xen: events: dynamically allocate irq info structures
Date: Tue, 26 Oct 2010 09:37:57 -0700 [thread overview]
Message-ID: <4CC703E5.6000009@goop.org> (raw)
In-Reply-To: <20101026143027.GB9557@dumpdata.com>
On 10/26/2010 07:30 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 25, 2010 at 05:23:32PM +0100, Ian Campbell wrote:
>> Removes nr_irq sized array allocation at start of day.
>>
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> ---
>> drivers/xen/events.c | 50 +++++++++++++++++++++++++++++++++++++++++---------
>> 1 files changed, 41 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
>> index 94055ea..9b58505 100644
>> --- a/drivers/xen/events.c
>> +++ b/drivers/xen/events.c
>> @@ -56,6 +56,8 @@
>> */
>> static DEFINE_SPINLOCK(irq_mapping_update_lock);
>>
>> +static LIST_HEAD(xen_irq_list_head);
>> +
>> /* IRQ <-> VIRQ mapping. */
>> static DEFINE_PER_CPU(int [NR_VIRQS], virq_to_irq) = {[0 ... NR_VIRQS-1] = -1};
>>
>> @@ -85,6 +87,7 @@ enum xen_irq_type {
>> */
>> struct irq_info
>> {
>> + struct list_head list;
>> enum xen_irq_type type; /* type */
>> unsigned short evtchn; /* event channel */
>> unsigned short cpu; /* cpu bound */
>> @@ -103,7 +106,6 @@ struct irq_info
>> #define PIRQ_NEEDS_EOI (1 << 0)
>> #define PIRQ_SHAREABLE (1 << 1)
>>
>> -static struct irq_info *irq_info;
>> static int *pirq_to_irq;
>> static int nr_pirqs;
>>
>> @@ -132,7 +134,7 @@ static struct irq_chip xen_pirq_chip;
>> /* Get info for IRQ */
>> static struct irq_info *info_for_irq(unsigned irq)
>> {
>> - return &irq_info[irq];
>> + return get_irq_data(irq);
>> }
>>
>> /* Constructors for packed IRQ information. */
>> @@ -315,7 +317,7 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
>> __clear_bit(chn, cpu_evtchn_mask(cpu_from_irq(irq)));
>> __set_bit(chn, cpu_evtchn_mask(cpu));
>>
>> - irq_info[irq].cpu = cpu;
>> + info_for_irq(irq)->cpu = cpu;
>> }
>>
>> static void init_evtchn_cpu_bindings(void)
>> @@ -428,6 +430,21 @@ static int find_unbound_pirq(void)
>> return -1;
>> }
>>
>> +static void xen_irq_init(unsigned irq)
>> +{
>> + struct irq_info *info;
>> +
>> + info = kmalloc(sizeof(*info), GFP_KERNEL);
>> + if (info == NULL)
>> + panic("Unable to allocate metadata for IRQ%d\n", irq);
> There is a bunch of panic around allocating IRQs. There is one earlier
> in xen_irq_alloc too, and I was wondering - would it make sense to
> perhaps print an error to both the hypervisor and the kernel and
> just return -1 as an IRQ and let the kernel continue with its normal
> failure path?
>
> I am thinking just in terms of making the system still be able to
> work even if parts of it are busted, instead of just crashing the system.
>
> Not sure which philosophy is domiant in the Linux kernel?
Normally to print something and struggle on, rather than crash over
every little thing. There's been a general tendency to convert BUG into
WARN, for example.
J
next prev parent reply other threads:[~2010-10-26 16:38 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <tip-77dff1c755c3218691e95e7e38ee14323b35dbdb@git.kernel.org>
2010-10-16 0:15 ` [tip:irq/core] x86: xen: Sanitise sparse_irq handling Jeremy Fitzhardinge
2010-10-16 0:17 ` [Xen-devel] " Jeremy Fitzhardinge
2010-10-16 2:01 ` H. Peter Anvin
2010-10-25 16:22 ` [PATCH 00/05] xen: events: cleanups after irq core improvements (Was: Re: [Xen-devel] Re: [tip:irq/core] x86: xen: Sanitise sparse_irq handling) Ian Campbell
2010-10-25 16:23 ` [PATCH 1/5] xen: events: use irq_alloc_desc(_at) instead of open-coding an IRQ allocator Ian Campbell
2010-10-25 17:35 ` Konrad Rzeszutek Wilk
2010-10-25 18:02 ` Ian Campbell
2010-10-26 8:15 ` [Xen-devel] " Ian Campbell
2010-10-26 19:49 ` Stefano Stabellini
2010-10-26 20:20 ` Jeremy Fitzhardinge
2010-10-25 23:03 ` Jeremy Fitzhardinge
2010-10-25 23:05 ` H. Peter Anvin
2010-10-25 23:21 ` Jeremy Fitzhardinge
2010-10-26 14:17 ` [Xen-devel] " Konrad Rzeszutek Wilk
2010-10-26 16:44 ` Jeremy Fitzhardinge
2010-10-26 17:08 ` Konrad Rzeszutek Wilk
2010-10-28 12:43 ` Stefano Stabellini
2010-10-28 16:22 ` Jeremy Fitzhardinge
2010-10-25 16:23 ` [PATCH 2/5] xen: events: turn irq_info constructors into initialiser functions Ian Campbell
2010-10-25 16:23 ` [PATCH 3/5] xen: events: push setup of irq<->{evtchn,pirq} maps into irq_info init functions Ian Campbell
2010-10-26 14:31 ` Konrad Rzeszutek Wilk
2010-10-25 16:23 ` [PATCH 4/5] xen: events: dynamically allocate irq info structures Ian Campbell
2010-10-26 14:30 ` Konrad Rzeszutek Wilk
2010-10-26 16:37 ` Jeremy Fitzhardinge [this message]
2010-10-25 16:23 ` [PATCH 5/5] xen: events: use per-cpu variable for cpu_evtchn_mask Ian Campbell
2010-10-26 14:36 ` Konrad Rzeszutek Wilk
2010-10-26 14:50 ` Ian Campbell
2010-10-25 23:03 ` [PATCH 00/05] xen: events: cleanups after irq core improvements (Was: Re: [Xen-devel] Re: [tip:irq/core] x86: xen: Sanitise sparse_irq handling) Jeremy Fitzhardinge
2010-10-26 7:25 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CC703E5.6000009@goop.org \
--to=jeremy@goop.org \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=hpa@zytor.com \
--cc=ian.campbell@citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox