All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Sebastian Reichel <sebastian.reichel@collabora.co.uk>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Pavel Machek <pavel@ucw.cz>,
	Linus Walleij <linus.walleij@linaro.org>,
	Grygorii Strashko <grygorii.strashko@ti.com>
Subject: Re: [GIT pull] irq updates for 4.13
Date: Tue, 11 Jul 2017 10:39:24 -0700	[thread overview]
Message-ID: <20170711173924.GA16509@atomide.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1707111820090.1799@nanos>

* Thomas Gleixner <tglx@linutronix.de> [170711 10:17]:
> On Tue, 11 Jul 2017, Tony Lindgren wrote:
> > * Linus Torvalds <torvalds@linux-foundation.org> [170711 08:40]:
> > > On Tue, Jul 11, 2017 at 7:41 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > > >
> > > > Ah. Now that makes sense.
> > > >
> > > > Unpatched the ordering is:
> > > >
> > > >           chip_bus_lock(desc);
> > > >           irq_request_resources(desc);
> > > 
> > > I *looked* at that ordering and then went "Naah, that makes no sense".
> > > 
> > > But if that's the only issue, how about we just re-order those things
> > > - we still don't need to move the irq_request_resources() into the
> > > spinlock, we just move it to below the chip_bus_lock().
> > > 
> > > IOW, something like the (COMPLETELY UNTEESTED!) attached patch.
> > 
> > Yeah that fixes the issue:
> > 
> > Tested-by: Tony Lindgren <tony@atomide.com>
> > 
> > > This assumes that the chip_bus_lock() thing is still ok for the RT
> > > case, but it looks like it might be: the only other one I looked at
> > > (apart from the gpio-omap one) used a mutex.
> > 
> > Yeah and the ordering below makes more sense to me at least. That is
> > assuming we want to call chip_bus_lock() before we start calling the
> > chip functions :)
> 
> We can do that, just the free path is ugly and does not really work that
> way.

OK

> __free_irq()
> 	....
> 	chip_bus_sync_unlock(desc);
> 	...
> 	synchronize_irq(irq);
> 	...
> 	if (!desc->action) {
> 		irq_release_resources();
> 		irq_remove_timings();
> 	}
> 	mutex_unlock(&desc->request_mutex);
> 
> We can't release request_mutex early otherwise we run into the issue of a
> concurrent request_irq() trying to reuse stuff which we just release, but
> we can't reacquire bus_lock under request_mutex either when we change the
> lock ordering to bus_lock -> desc->request_mutex -> desc->lock.
> 
> We really want to have both the release_resources() and the
> remove_timings() calls outside of the spinlocked region. That's not only a
> RT issue, there have been requests for making the resource call 'sleepable'
> for mainline as well.
> 
> Below is a slightly different fix, which keeps the lock order
> 
>       desc->request_mutex -> bus_lock -> desc->lock
> 
> intact and conditionally reacquired the bus lock for the release call.

Yeah that fixes the issue too:

Tested-by: Tony Lindgren <tony@atomide.com>

Regards,

Tony


> 8<------------------------
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -1036,13 +1036,20 @@ static int irq_request_resources(struct
>  	return c->irq_request_resources ? c->irq_request_resources(d) : 0;
>  }
>  
> -static void irq_release_resources(struct irq_desc *desc)
> +static void irq_release_resources(struct irq_desc *desc, bool buslock)
>  {
>  	struct irq_data *d = &desc->irq_data;
>  	struct irq_chip *c = d->chip;
>  
> -	if (c->irq_release_resources)
> -		c->irq_release_resources(d);
> +	if (!c->irq_release_resources)
> +		return;
> +	if (buslock)
> +		chip_bus_lock(desc);
> +
> +	c->irq_release_resources(d);
> +
> +	if (buslock)
> +		chip_bus_sync_unlock(desc);
>  }
>  
>  static int
> @@ -1168,17 +1175,16 @@ static int
>  		new->flags &= ~IRQF_ONESHOT;
>  
>  	mutex_lock(&desc->request_mutex);
> +	chip_bus_lock(desc);
>  	if (!desc->action) {
>  		ret = irq_request_resources(desc);
>  		if (ret) {
>  			pr_err("Failed to request resources for %s (irq %d) on irqchip %s\n",
>  			       new->name, irq, desc->irq_data.chip->name);
> -			goto out_mutex;
> +			goto out_bus;
>  		}
>  	}
>  
> -	chip_bus_lock(desc);
> -
>  	/*
>  	 * The following block of code has to be executed atomically
>  	 */
> @@ -1286,10 +1292,8 @@ static int
>  			ret = __irq_set_trigger(desc,
>  						new->flags & IRQF_TRIGGER_MASK);
>  
> -			if (ret) {
> -				irq_release_resources(desc);
> +			if (ret)
>  				goto out_unlock;
> -			}
>  		}
>  
>  		desc->istate &= ~(IRQS_AUTODETECT | IRQS_SPURIOUS_DISABLED | \
> @@ -1385,12 +1389,10 @@ static int
>  out_unlock:
>  	raw_spin_unlock_irqrestore(&desc->lock, flags);
>  
> -	chip_bus_sync_unlock(desc);
> -
>  	if (!desc->action)
> -		irq_release_resources(desc);
> -
> -out_mutex:
> +		irq_release_resources(desc, false);
> +out_bus:
> +	chip_bus_sync_unlock(desc);
>  	mutex_unlock(&desc->request_mutex);
>  
>  out_thread:
> @@ -1472,6 +1474,7 @@ static struct irqaction *__free_irq(unsi
>  			WARN(1, "Trying to free already-free IRQ %d\n", irq);
>  			raw_spin_unlock_irqrestore(&desc->lock, flags);
>  			chip_bus_sync_unlock(desc);
> +			mutex_unlock(&desc->request_mutex);
>  			return NULL;
>  		}
>  
> @@ -1531,7 +1534,7 @@ static struct irqaction *__free_irq(unsi
>  	}
>  
>  	if (!desc->action) {
> -		irq_release_resources(desc);
> +		irq_release_resources(desc, true);
>  		irq_remove_timings(desc);
>  	}
>  
> 
> 
> 
> 
> 
> 

  reply	other threads:[~2017-07-11 17:39 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-09  8:49 [GIT pull] irq updates for 4.13 Thomas Gleixner
2017-07-10 13:35 ` Sebastian Reichel
2017-07-10 17:01   ` Linus Torvalds
2017-07-10 19:38     ` Pavel Machek
2017-07-10 20:15     ` Sebastian Reichel
2017-07-10 21:29       ` Linus Torvalds
2017-07-11  6:55     ` Thomas Gleixner
2017-07-11  9:26       ` Sebastian Reichel
2017-07-11  9:55         ` Thomas Gleixner
2017-07-11 10:52           ` Thomas Gleixner
2017-07-11 11:21             ` Sebastian Reichel
2017-07-11 13:27               ` Thomas Gleixner
2017-07-11 13:51               ` Marc Zyngier
2017-07-11 14:39                 ` Sebastian Reichel
2017-07-11  9:47       ` Thomas Gleixner
2017-07-11 13:51         ` Tony Lindgren
2017-07-11 14:41           ` Thomas Gleixner
2017-07-11 15:07             ` Thomas Gleixner
2017-07-11 15:43               ` Tony Lindgren
2017-07-11 15:39             ` Grygorii Strashko
2017-07-11 16:17               ` Tony Lindgren
2017-07-12  8:00               ` Geert Uytterhoeven
2017-07-11 15:40             ` Linus Torvalds
2017-07-11 16:14               ` Sebastian Reichel
2017-07-11 16:15               ` Tony Lindgren
2017-07-11 17:17                 ` Thomas Gleixner
2017-07-11 17:39                   ` Tony Lindgren [this message]
2017-07-11 16:19               ` Thomas Gleixner
2017-07-11 16:31                 ` Linus Torvalds
2017-07-11 17:52                   ` Thomas Gleixner
2017-07-11 18:16                     ` Linus Torvalds
2017-07-11 21:30                       ` Sebastian Reichel
2017-07-11 21:41                       ` Thomas Gleixner
2017-07-11 22:04                         ` Linus Torvalds
2017-07-11 22:51                         ` Sebastian Reichel
2017-07-12  5:29                           ` Tony Lindgren
2017-07-15 20:24                             ` Pavel Machek
2017-07-17  6:21                               ` Tony Lindgren
2017-07-17 20:01                               ` Linus Torvalds
2017-07-17 21:33                                 ` Pavel Machek
2017-07-11 16:34                 ` Tony Lindgren
2017-07-11 14:41           ` Sebastian Reichel
2017-07-11 16:20             ` Tony Lindgren
2017-07-11 16:34               ` Sebastian Reichel
  -- strict thread matches above, loose matches on Subject: below --
2017-07-03  7:42 Thomas Gleixner
2017-07-04  0:00 ` Linus Torvalds
2017-07-04  8:12   ` Thomas Gleixner
2017-07-04 10:29     ` Thomas Gleixner
2017-07-04 15:17   ` Jens Axboe
2017-07-04 18:34     ` Linus Torvalds
2017-07-04 19:10       ` Thomas Gleixner
2017-07-04 20:48         ` Max Gurtovoy
2017-07-06 13:58           ` Max Gurtovoy
2017-07-04 21:56       ` Jens Axboe
2017-07-05 15:14   ` Christoph Hellwig

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=20170711173924.GA16509@atomide.com \
    --to=tony@atomide.com \
    --cc=akpm@linux-foundation.org \
    --cc=grygorii.strashko@ti.com \
    --cc=hpa@zytor.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=pavel@ucw.cz \
    --cc=sebastian.reichel@collabora.co.uk \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.