Re: [BUG]? xfrm: INFO: inconsistent lock state

[Yury Polyanskiy <ypolyans@princeton.edu>]

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

On Tue, 2 Feb 2010 18:49:14 +1100
Herbert Xu <herbert@gondor.apana.org.au> wrote:

> On Mon, Feb 01, 2010 at 06:01:20PM +0800, Wei Yongjun wrote:
> > I got following lock INFO in my Fedora12 box uner 2.6.33-rc6.
> > Is this a BUG?
> 
> Apparently.
> 
> This is introduced by
> 
> commit 9e0d57fd6dad37d72a3ca6db00ca8c76f2215454
> Author: Yury Polyanskiy <polyanskiy@gmail.com>
> Date:   Sun Nov 8 20:58:41 2009 -0800
> 
>     xfrm: SAD entries do not expire correctly after suspend-resume
>  
> Whether this is a real dead-lock depends on whether hrtimers
> behave as real hard IRQs.  If they do then yes it can deadlock.

If hrtimer_tasklet interface functions properly, the
xfrm_timer_handler should be called in softirq context (and thus is
never in parallel with xfrm_input()). The deadlock isn't possible then.

In this case it seems that for some reason xfrm_timer_handler() is
called in the hardirq context. The relevant code in hrtimer_tasklet:

static enum hrtimer_restart __hrtimer_tasklet_trampoline(struct hrtimer *timer)
{
	struct tasklet_hrtimer *ttimer =
		container_of(timer, struct tasklet_hrtimer, timer);

	if (hrtimer_is_hres_active(timer)) {
		tasklet_hi_schedule(&ttimer->tasklet);
		return HRTIMER_NORESTART;
	}
	return ttimer->function(timer);
}

I am copying Peter on this. Peter, how is it possible that
ttimer->function() is called in hardirq?

Could it be that switch from hres_active happened after the call to
trampoline and before the if() above?

Best,
Yury

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]