mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Milton Miller <miltonm@bga.com>
Cc: linux-kernel@vger.kernel.org,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH 1/4] sparse irq: protect irq_to_desc against irq_free_descs
Date: Wed, 25 May 2011 10:14:20 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.02.1105250958380.3078@ionos> (raw)
In-Reply-To: <rcu-lock-radix-lookup-sparse-irq@mdm.bga.com>

On Wed, 25 May 2011, Milton Miller wrote:
> The radix-tree code uses call_rcu to delay freeing internal data
> elements when removing when deleting an entry.  We must protect
> against the elements being freed while we traverse the tree.
> 
> While preparing a patch to expand the contexts in which the radix
> tree optionally used by powerpc for mapping hardware irq numbers to
> linux numbers would be called, I realized that the radix tree was
> not locked when radix_tree_lookup was called.  I then realized the
> same issue applies to the generic irq code when sparse irqs are in use.
> 
> While the powerpc radix tree was only referenced from one callsite
> that was irqs_disabled and irq_enter, irq_to_desc is called from
> many more contexts including threaded irq handlers and other
> process contexts.
> 
> This does not show up in the rcu lockdep because in 2.6.34 commit
> 2676a58c98 (radix-tree: Disable RCU lockdep checking in radix tree)
> deemed it too hard to pass the condition of the protecting lock
> to the library.
> 
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Cc: <stable@kernel.org>
> ---
> I expect the relatively infrequent calls to irq_free_descs, combined
> with most calls to irq_to_desc being irqs_disabled and the fact
> merged to mainline implemntations of call_rcu requiring a cpu to
> respond to a hard irq or schedule has hidden this error to date.

The reason why nobody ever noticed is that the free happens in the
teardown path of PCI devices and at this point nothing accesses that
irq anymore.
 
> Index: work.git/kernel/irq/irqdesc.c
> ===================================================================
> --- work.git.orig/kernel/irq/irqdesc.c	2011-05-23 13:34:08.728585785 -0500
> +++ work.git/kernel/irq/irqdesc.c	2011-05-23 13:46:09.197635762 -0500
> @@ -108,7 +108,13 @@ static void irq_insert_desc(unsigned int
>  
>  struct irq_desc *irq_to_desc(unsigned int irq)
>  {
> -	return radix_tree_lookup(&irq_desc_tree, irq);
> +	struct irq_desc *desc;
> +
> +	rcu_read_lock();
> +	desc = radix_tree_lookup(&irq_desc_tree, irq);
> +	rcu_read_unlock();
> +
> +	return desc

That does not really compile :)

And it does not help at all because we unconditionally free the irq
descriptor and do not use rcu based kfree. Further you protect only
the lookup and not the complete section which uses the descriptor, so
it could go away after the rcu_read_unlock() in theory.

Thanks,

	tglx

  reply	other threads:[~2011-05-25  8:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <generic-irq-changes@mdm.bga.com>
2011-05-25  6:34 ` [PATCH 3/4] irq: remove unnecessary __ref on irq_alloc_descs Milton Miller
2011-05-25  6:34 ` [PATCH 1/4] sparse irq: protect irq_to_desc against irq_free_descs Milton Miller
2011-05-25  8:14   ` Thomas Gleixner [this message]
2011-05-25 10:49     ` Milton Miller
2011-05-25 10:54       ` Thomas Gleixner
2011-05-25  6:34 ` [PATCH 2/4] irq: radix_tree_insert can fail Milton Miller
2011-05-25  8:18   ` Thomas Gleixner
2011-05-25 10:48     ` Milton Miller
2011-05-25  6:34 ` [PATCH RFC 4/4] irq: allow a per-allocation upper limit when allocating irqs Milton Miller
2011-05-25  7:55   ` Ingo Molnar
2011-05-25  8:32   ` Thomas Gleixner
2011-05-27  3:38   ` Grant Likely

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=alpine.LFD.2.02.1105250958380.3078@ionos \
    --to=tglx@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miltonm@bga.com \
    --cc=paulmck@linux.vnet.ibm.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

all inboxes | Powered by JetHome®