BUG? deadlock bug at generic_shutdown_

BUG? deadlock bug at generic_shutdown_

[홍신 shin hong]

Hi. I am reporting a suspected deadlock bug.

generic_shutdown_super() acquires lock_super(sb)
and then acquires lock_kernel().

However, do_remount() acquires lock_super() while
it holds lock_kernel().

Therefore, concurrent execution of generic_shutdown_super()
and do_remount() may result deadlock.

Please examine this report. Thank you.

Sincerely
Shin Hong

Re: BUG? deadlock bug at generic_shutdown_

[Matthew Wilcox]

On Thu, Jul 30, 2009 at 12:29:57PM +0900, ?????? shin hong wrote:
> Hi. I am reporting a suspected deadlock bug.
> 
> generic_shutdown_super() acquires lock_super(sb)
> and then acquires lock_kernel().

It hasn't since commit a9e220f8322e2b0e0b8903fe00265461cffad3f0.
Please work against a current kernel.

> However, do_remount() acquires lock_super() while
> it holds lock_kernel().
> 
> Therefore, concurrent execution of generic_shutdown_super()
> and do_remount() may result deadlock.

The reason this wasn't a problem before the commit above is that
generic_shutdown_super() can never execute concurrently with do_remount.
For generic_shutdown_super() to be called, there must be no remaining
references to the super_block.  do_remount() must hold a reference to
the super_block.

CONFIG_LOCKDEP finds lock inversion problems; I suspect you're wasting
your time looking for them by hand.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."