Re: + convert-cpu-hotplug-notifiers-to-use-raw_notifier-instead-of-blocking_notifier.patchadded to -mm tree

[Michal Piotrowski]

Andrew Morton wrote:
> On Fri, 13 Oct 2006 22:13:43 +0200
> "Michal Piotrowski" <michal.k.k.piotrowski@xxxxxxxxx> wrote:
> 
>> On 13/10/06, Andrew Morton <akpm@xxxxxxxx> wrote:
>>> On Fri, 13 Oct 2006 17:19:16 +0200
>>> Michal Piotrowski <michal.k.k.piotrowski@xxxxxxxxx> wrote:
>>>
>>>> There is something really wrong with this patch (or my hardware).
>>>>
>>>> echo shutdown > /sys/power/disk; echo disk > /sys/power/state
>>>> works fine for me on 2.6.19-rc1-g8770c018.
>>>>
>>>> On 2.6.19-rc1-mm1 +
>>>> convert-cpu-hotplug-notifiers-to-use-raw_notifier-instead-of-blocking_notifier.patch
>>>> + Neil's avoid_lockdep_warning_in_md.patch
>>>> (http://www.ussg.iu.edu/hypermail/linux/kernel/0610.1/0642.html)
>>>> I get a lot of "end_request: I/O error, dev sda, sector 31834343" messages.
>>> That's not exactly an expected result.  What makes you think it's due to
>>> this patch?  Does 2.6.19-rc1-mm1 run OK?
>> Yes. (the only one issue is
>> http://www.stardust.webpages.pl/files/tbf/euridica/2.6.19-rc1-mm1/mm-dmesg)
>>
>> I get many "random" bugs that avoid hibernation with this patch.
> 
> As predicted, it works for me.  In fact it makes a string of nasty SMP-only
> warnings go away.
> 

I reverted Neil's avoid_lockdep_warning_in_md.patch and everything works fine.

2.6.19-rc1-mm1 + avoid_lockdep_warning_in_md.patch works well for me.
2.6.19-rc1-mm1 + convert-cpu-hotplug-notifiers-to-use-raw_notifier-instead-of-blocking_notifier.patch also works well.

2.6.19-rc1-mm1 + both patches = crashing hibernation.

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

-----------------------
Avoid lockdep warning in md.

md_open takes ->reconfig_mutex which causes lockdep to complain.
This (normally) doesn't have deadlock potential as the possible
conflict is with a reconfig_mutex in a different device.

I say "normally" because if a loop were created in the array->member
hierarchy a deadlock could happen.  However that causes bigger
problems than a deadlock and should be fixed independently.

So we flag the lock in md_open as a nested lock.  This requires
defining mutex_lock_interruptible_nested.

Signed-off-by: Neil Brown <neilb@xxxxxxx>

### Diffstat output
 ./drivers/md/md.c       |    2 +-
 ./include/linux/mutex.h |    3 ++-
 ./kernel/mutex.c        |    8 ++++++++
 3 files changed, 11 insertions(+), 2 deletions(-)

diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c	2006-10-09 14:25:11.000000000 +1000
+++ ./drivers/md/md.c	2006-10-10 12:28:35.000000000 +1000
@@ -4422,7 +4422,7 @@ static int md_open(struct inode *inode,
 	mddev_t *mddev = inode->i_bdev->bd_disk->private_data;
 	int err;

-	if ((err = mddev_lock(mddev)))
+	if ((err = mutex_lock_interruptible_nested(&mddev->reconfig_mutex, 1)))
 		goto out;

 	err = 0;

diff .prev/include/linux/mutex.h ./include/linux/mutex.h
--- .prev/include/linux/mutex.h	2006-10-10 12:37:04.000000000 +1000
+++ ./include/linux/mutex.h	2006-10-10 12:40:20.000000000 +1000
@@ -125,8 +125,9 @@ extern int fastcall mutex_lock_interrupt

 #ifdef CONFIG_DEBUG_LOCK_ALLOC
 extern void mutex_lock_nested(struct mutex *lock, unsigned int subclass);
+extern int mutex_lock_interruptible_nested(struct mutex *lock, unsigned int subclass);
 #else
-# define mutex_lock_nested(lock, subclass) mutex_lock(lock)
+# define mutex_lock_interruptible_nested(lock, subclass) mutex_interruptible_lock(lock)
 #endif

 /*

diff .prev/kernel/mutex.c ./kernel/mutex.c
--- .prev/kernel/mutex.c	2006-10-10 12:35:54.000000000 +1000
+++ ./kernel/mutex.c	2006-10-10 13:20:04.000000000 +1000
@@ -206,6 +206,14 @@ mutex_lock_nested(struct mutex *lock, un
 }

 EXPORT_SYMBOL_GPL(mutex_lock_nested);
+int __sched
+mutex_lock_interruptible_nested(struct mutex *lock, unsigned int subclass)
+{
+	might_sleep();
+	return __mutex_lock_common(lock, TASK_INTERRUPTIBLE, subclass);
+}
+
+EXPORT_SYMBOL_GPL(mutex_lock_interruptible_nested);
 #endif

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