From: Ian Campbell <Ian.Campbell@citrix•com>
To: "Eric W. Biederman" <ebiederm@xmission•com>
Cc: Jeremy Fitzhardinge <jeremy@goop•org>,
"x86@kernel•org" <x86@kernel•org>,
"linux-kernel@vger•kernel.org" <linux-kernel@vger•kernel.org>,
"linuxppc-dev@ozlabs•org" <linuxppc-dev@ozlabs•org>,
Ingo Molnar <mingo@redhat•com>, Paul Mackerras <paulus@samba•org>,
"H. Peter Anvin" <hpa@zytor•com>,
Thomas Gleixner <tglx@linutronix•de>,
Yinghai Lu <yinghai@kernel•org>
Subject: Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
Date: Tue, 16 Mar 2010 08:50:12 +0000 [thread overview]
Message-ID: <1268729412.8652.4254.camel@localhost.localdomain> (raw)
In-Reply-To: <m1ocit5aj1.fsf@fess.ebiederm.org>
On Sat, 2010-03-13 at 00:29 +0000, Eric W. Biederman wrote:
> [...]
> > after that xen could use
> > irq_to_desc_alloc_node_f(irq, node, xen_init_chip_data);
> >
> > as need...
> >
> > at last we don't need to call x86_init_chip_data everywhere.
This was one of the things I was considering. It seems like one of the
easiest solutions to make work correctly with the current locking in
e.g. irq_to_desc_alloc_node since the callback would always happen under
the lock taken in that function.
> So trying to evaluate races. The worse case for this particular piece
> of code appears to be create_irq_nr. As this is the only place where
> we are setting up irqs and possibly repurposing the structure.
Yes, create_irq_nr was one of the functions I was struggling to solve
cleanly. There is a similar construct in the Xen code as well.
Part of the problem I'm having is the combination of lookup and allocate
in irq_to_desc_alloc_node but also the kind of "implicit" repurposing is
tricky to deal with. (by implicit I just mean that I can't find where
the previous user explicitly says they are finished with it, if you see
what I mean)
What do you think of adding an explicit free operation for the irq_desc
structs? (does one already exist? I couldn't find it). This would go
along with some tracking of allocation state, trivial in the sparse case
where you can treat a NULL node in the radix tree as unallocated, I
guess a flag would suffice in the static array non-sparse case?
Going further could we split the alloc and lookup functions into
separate operations instead of combining them in irq_to_desc_alloc_node?
We already have irq_to_desc for the lookup portion so this would largely
involve changes to the semantics of irq_to_desc_alloc_node, perhaps
returning ERR_PTR(-EBUSY) if the node was already allocated.
Having a variant which found a free IRQ rather than operating on a
specific requested IRQ could also be useful for create_irq_nr as well as
find_unbound_irq on the Xen side. I'm not convinced irq_alloc_virt on
powerpc isn't implementing broadly the same concept as well, although it
seems to work very differently from the other two.
> Today
> we figure out if an irq has been assigned by looking at irq_cfg->vector,
> and if it is non-zero the irq has been assigned.
Which is tricky to move into generic code hence my suggestions of
explicitly freeing the irq_desc and tracking the allocation status in
the generic code.
> The logic in x86_init_chip_data is correct we only assign desc->chip_data
> if the generic layers are above it. However we need a lock to ensure that
> two paths don't race in that comparison and that assignment. There is
> no lock in x86_init_chip_data. Which unfortunately means as it stands
> this patchset is buggy.
Yes, unfortunately I think you are right. The callback idea fixes this.
I'll respin with that.
Ian.
next prev parent reply other threads:[~2010-03-16 8:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-12 9:44 [GITPULL+PATCH 0/2] irq: move some interrupt arch_* functions into struct irq_chip Ian Campbell
2010-03-12 9:45 ` [PATCH] " Ian Campbell
2010-03-12 19:26 ` Yinghai Lu
2010-03-13 0:29 ` Eric W. Biederman
2010-03-16 8:50 ` Ian Campbell [this message]
2010-03-16 9:18 ` Eric W. Biederman
[not found] <1268218524.11737.68547.camel@zakaz.uk.xensource.com>
2010-03-10 10:55 ` ijc
2010-03-10 11:00 ` Ian Campbell
2010-03-10 17:18 ` Eric W. Biederman
2010-03-10 17:41 ` Ian Campbell
2010-03-10 18:11 ` Eric W. Biederman
2010-03-10 12:06 ` Yinghai Lu
2010-03-10 12:51 ` Ian Campbell
2010-03-10 17:42 ` Eric W. Biederman
2010-03-10 17:50 ` Ian Campbell
2010-03-10 18:15 ` Eric W. Biederman
2010-03-10 18:28 ` Ian Campbell
2010-03-10 18:27 ` Jeremy Fitzhardinge
2010-03-10 18:59 ` Yinghai Lu
2010-03-10 19:15 ` Eric W. Biederman
2010-03-10 22:07 ` Michael Ellerman
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=1268729412.8652.4254.camel@localhost.localdomain \
--to=ian.campbell@citrix$(echo .)com \
--cc=ebiederm@xmission$(echo .)com \
--cc=hpa@zytor$(echo .)com \
--cc=jeremy@goop$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=mingo@redhat$(echo .)com \
--cc=paulus@samba$(echo .)org \
--cc=tglx@linutronix$(echo .)de \
--cc=x86@kernel$(echo .)org \
--cc=yinghai@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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