linux-kernel - Re: Deadlock on concurrent remount-ro and mdadm --stop (2.6.37)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110123161500.GB4108@nn.nn>
Date:	Sun, 23 Jan 2011 17:15:00 +0100
From:	Harald Braumann <harry@...eit.net>
To:	linux-kernel@...r.kernel.org
Subject: Re: Deadlock on concurrent remount-ro and mdadm --stop (2.6.37)

On Fri, Jan 21, 2011 at 01:47:54PM +0100, Harald Braumann wrote:
> On shutdown `umountroot' and `mdadm-raid'  are executed concurrently. The 
> actual commands are:
> mount -o remount,ro /
> mdadm --stop --scan
> 
> This seems to trigger a deadlock in the kernel. Dumping blocked tasks (sysrq-W)
> gives:
> 
> md126_raid5: call trace:
>   md_super_wait
>   autoremove_wake_function
>   bitmap_unplug
>   ...
> 
> mount: call trace:
>   sync_page
>   io_schedule
>   sync_page

I've now disable parallel boot in my system, so umountroot and mdadm
shouldn't be called cuncurrently anymore. But I still get lock-ups on
mdadm --stop. Umountroot is called before mdadm --stop, and all other
filesystems are unmounted before that, so I guess
there should be no `sync_page' in progress anymore. But I also have
swap on the raid, so maybe there's a problem?

As not even the magic SysRQ keys work, I can't provide any more
details. Any suggestions how I could debug this problem?

Cheers,
harry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/