2.6.21-rc7-mm1 + sysfs-oops-workaround.patch -- INFO: possible recursive locking detected

2.6.21-rc7-mm1 + sysfs-oops-workaround.patch -- INFO: possible recursive locking detected

[Miles Lane]

[   59.677312] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state
recovery directory
[   59.688633] NFSD: starting 90-second grace period
[   60.221454]
[   60.221456] =============================================
[   60.221461] [ INFO: possible recursive locking detected ]
[   60.221464] 2.6.21-rc7-mm1 #53
[   60.221466] ---------------------------------------------
[   60.221469] S20powernowd/3584 is trying to acquire lock:
[   60.221472]  (&sd->s_active){----}, at: [<c01a2436>]
sysfs_hash_and_remove+0x91/0x10e
[   60.221486]
[   60.221487] but task is already holding lock:
[   60.221489]  (&sd->s_active){----}, at: [<c01a2a20>]
sysfs_write_file+0xb9/0x14a
[   60.221496]
[   60.221497] other info that might help us debug this:
[   60.221499] 4 locks held by S20powernowd/3584:
[   60.221501]  #0:  (&sd->s_active){----}, at: [<c01a2a20>]
sysfs_write_file+0xb9/0x14a
[   60.221508]  #1:  (&sd->s_active){----}, at: [<c01a2a32>]
sysfs_write_file+0xcb/0x14a
[   60.221515]  #2:  (&per_cpu(cpu_policy_rwsem, cpu)){--..}, at:
[<c024081b>] lock_policy_rwsem_write+0x20/0x37
[   60.221524]  #3:  (userspace_mutex){--..}, at: [<c0299dfe>]
mutex_lock+0x1f/0x23
[   60.221534]
[   60.221535] stack backtrace:
[   60.221538]  [<c0104e0f>] show_trace_log_lvl+0x1a/0x30
[   60.221543]  [<c0105a26>] show_trace+0x12/0x14
[   60.221547]  [<c0105ab3>] dump_stack+0x16/0x18
[   60.221551]  [<c0134d63>] __lock_acquire+0x12e/0xb4c
[   60.221557]  [<c01357e9>] lock_acquire+0x68/0x82
[   60.221561]  [<c012ddda>] down_write+0x3a/0x53
[   60.221567]  [<c01a2436>] sysfs_hash_and_remove+0x91/0x10e
[   60.221571]  [<c01a2bb0>] sysfs_remove_file+0x10/0x12
[   60.221575]  [<c0241756>] cpufreq_governor_userspace+0x10c/0x1dc
[   60.221579]  [<c023fd2b>] __cpufreq_governor+0x9c/0xd0
[   60.221583]  [<c023fed0>] __cpufreq_set_policy+0x171/0x209
[   60.221587]  [<c02400b5>] store_scaling_governor+0x14d/0x184
[   60.221591]  [<c0240bee>] store+0x3e/0x60
[   60.221594]  [<c01a2a85>] sysfs_write_file+0x11e/0x14a
[   60.221599]  [<c01699fb>] vfs_write+0x90/0x119
[   60.221605]  [<c0169eef>] sys_write+0x3d/0x61
[   60.221609]  [<c0103e66>] sysenter_past_esp+0x5f/0x99
[   60.221613]  =======================
[   60.763809] Clocksource tsc unstable (delta = -75646443 ns)

Re: 2.6.21-rc7-mm1 + sysfs-oops-workaround.patch -- INFO: possible recursive locking detected

[Tejun Heo]

Miles Lane wrote:
> [   59.677312] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state
> recovery directory
> [   59.688633] NFSD: starting 90-second grace period
> [   60.221454]
> [   60.221456] =============================================
> [   60.221461] [ INFO: possible recursive locking detected ]
> [   60.221464] 2.6.21-rc7-mm1 #53
> [   60.221466] ---------------------------------------------
> [   60.221469] S20powernowd/3584 is trying to acquire lock:
> [   60.221472]  (&sd->s_active){----}, at: [<c01a2436>]
> sysfs_hash_and_remove+0x91/0x10e
> [   60.221486]
> [   60.221487] but task is already holding lock:
> [   60.221489]  (&sd->s_active){----}, at: [<c01a2a20>]
> sysfs_write_file+0xb9/0x14a
> [   60.221496]
> [   60.221497] other info that might help us debug this:
> [   60.221499] 4 locks held by S20powernowd/3584:
> [   60.221501]  #0:  (&sd->s_active){----}, at: [<c01a2a20>]
> sysfs_write_file+0xb9/0x14a
> [   60.221508]  #1:  (&sd->s_active){----}, at: [<c01a2a32>]
> sysfs_write_file+0xcb/0x14a
> [   60.221515]  #2:  (&per_cpu(cpu_policy_rwsem, cpu)){--..}, at:
> [<c024081b>] lock_policy_rwsem_write+0x20/0x37
> [   60.221524]  #3:  (userspace_mutex){--..}, at: [<c0299dfe>]
> mutex_lock+0x1f/0x23

Thanks for reporting.  We need to separate s_active users into two
classes - one for r/w the other for deleting for nodes which delete
other nodes when written to.  Will post a patch soon.

-- 
tejun

Re: 2.6.21-rc7-mm1 + sysfs-oops-workaround.patch -- INFO: possible recursive locking detected

[Antonino A. Daplas]

On Wed, 2007-04-25 at 14:18 +0900, Tejun Heo wrote:
> Miles Lane wrote:
> > [   59.677312] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state
> > recovery directory
> > [   59.688633] NFSD: starting 90-second grace period
> > [   60.221454]
> > [   60.221456] =============================================
> > [   60.221461] [ INFO: possible recursive locking detected ]
> > [   60.221464] 2.6.21-rc7-mm1 #53
> > [   60.221466] ---------------------------------------------
> > [   60.221469] S20powernowd/3584 is trying to acquire lock:
> > [   60.221472]  (&sd->s_active){----}, at: [<c01a2436>]
> > sysfs_hash_and_remove+0x91/0x10e
> > [   60.221486]
> > [   60.221487] but task is already holding lock:
> > [   60.221489]  (&sd->s_active){----}, at: [<c01a2a20>]
> > sysfs_write_file+0xb9/0x14a
> > [   60.221496]
> > [   60.221497] other info that might help us debug this:
> > [   60.221499] 4 locks held by S20powernowd/3584:
> > [   60.221501]  #0:  (&sd->s_active){----}, at: [<c01a2a20>]
> > sysfs_write_file+0xb9/0x14a
> > [   60.221508]  #1:  (&sd->s_active){----}, at: [<c01a2a32>]
> > sysfs_write_file+0xcb/0x14a
> > [   60.221515]  #2:  (&per_cpu(cpu_policy_rwsem, cpu)){--..}, at:
> > [<c024081b>] lock_policy_rwsem_write+0x20/0x37
> > [   60.221524]  #3:  (userspace_mutex){--..}, at: [<c0299dfe>]
> > mutex_lock+0x1f/0x23
> 
> Thanks for reporting.  We need to separate s_active users into two
> classes - one for r/w the other for deleting for nodes which delete
> other nodes when written to.  Will post a patch soon.
> 

I'm still getting this, with or without this patch applied. After this,
none of the ethernet cards work.

eth0 renamed to eth54
BUG: atomic counter underflow at:
 [<c0104378>] show_trace_log_lvl+0x1a/0x30
 [<c0104ec9>] show_trace+0x12/0x14
 [<c0104f22>] dump_stack+0x16/0x18
 [<c01bd575>] _atomic_dec_and_lock+0x29/0x4c
 [<c0174388>] dput+0x34/0x103
 [<c019d181>] sysfs_drop_dentry+0x141/0x149
 [<c019d212>] sysfs_hash_and_remove+0x89/0x10e
 [<c019f1fc>] sysfs_remove_link+0xe/0x10
 [<c0221839>] device_rename+0x110/0x181
 [<c025420a>] dev_change_name+0x11e/0x1ca
 [<c02545e6>] dev_ifsioc+0x330/0x3d7
 [<c0254d25>] dev_ioctl+0x350/0x46e
 [<c0249792>] sock_ioctl+0x1be/0x1ca
 [<c016f3c0>] do_ioctl+0x1c/0x53
 [<c016f5e3>] vfs_ioctl+0x1ec/0x203
 [<c016f643>] sys_ioctl+0x49/0x62
 [<c0103cde>] sysenter_past_esp+0x5f/0x99
 =======================
eth1 renamed to eth44
BUG: atomic counter underflow at:
 [<c0104378>] show_trace_log_lvl+0x1a/0x30
 [<c0104ec9>] show_trace+0x12/0x14
 [<c0104f22>] dump_stack+0x16/0x18
 [<c01bd575>] _atomic_dec_and_lock+0x29/0x4c
 [<c0174388>] dput+0x34/0x103
 [<c019d181>] sysfs_drop_dentry+0x141/0x149
 [<c019d212>] sysfs_hash_and_remove+0x89/0x10e
 [<c019f1fc>] sysfs_remove_link+0xe/0x10
 [<c0221839>] device_rename+0x110/0x181
 [<c025420a>] dev_change_name+0x11e/0x1ca
 [<c02545e6>] dev_ifsioc+0x330/0x3d7
 [<c0254d25>] dev_ioctl+0x350/0x46e
 [<c0249792>] sock_ioctl+0x1be/0x1ca
 [<c016f3c0>] do_ioctl+0x1c/0x53
 [<c016f5e3>] vfs_ioctl+0x1ec/0x203
 [<c016f643>] sys_ioctl+0x49/0x62
 [<c0103cde>] sysenter_past_esp+0x5f/0x99
 =======================
ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [LNKC] -> GSI 10 (level,
low) -> IRQ 10
PCI: Setting latency timer of device 0000:00:11.5 to 64
eth2 renamed to eth1
BUG: atomic counter underflow at:
 [<c0104378>] show_trace_log_lvl+0x1a/0x30
 [<c0104ec9>] show_trace+0x12/0x14
 [<c0104f22>] dump_stack+0x16/0x18
 [<c01bd575>] _atomic_dec_and_lock+0x29/0x4c
 [<c0174388>] dput+0x34/0x103
 [<c019d181>] sysfs_drop_dentry+0x141/0x149
 [<c019d212>] sysfs_hash_and_remove+0x89/0x10e
 [<c019f1fc>] sysfs_remove_link+0xe/0x10
 [<c0221839>] device_rename+0x110/0x181
 [<c025420a>] dev_change_name+0x11e/0x1ca
 [<c02545e6>] dev_ifsioc+0x330/0x3d7
 [<c0254d25>] dev_ioctl+0x350/0x46e
 [<c0249792>] sock_ioctl+0x1be/0x1ca
 [<c016f3c0>] do_ioctl+0x1c/0x53
 [<c016f5e3>] vfs_ioctl+0x1ec/0x203
 [<c016f643>] sys_ioctl+0x49/0x62
 [<c0103cde>] sysenter_past_esp+0x5f/0x99
 =======================

Tony

Nonfunctional ethernet (was Re: 2.6.21-rc7-mm1 + sysfs-oops-workaround.patch -- INFO: possible recursive locking detected)

[Antonino A. Daplas]

On Wed, 2007-04-25 at 22:48 +0800, Antonino A. Daplas wrote:
> On Wed, 2007-04-25 at 14:18 +0900, Tejun Heo wrote:
> > Miles Lane wrote:

> eth0 renamed to eth54
> BUG: atomic counter underflow at:
>  [<c0104378>] show_trace_log_lvl+0x1a/0x30
>  [<c0104ec9>] show_trace+0x12/0x14
>  [<c0104f22>] dump_stack+0x16/0x18
>  [<c01bd575>] _atomic_dec_and_lock+0x29/0x4c
>  [<c0174388>] dput+0x34/0x103
>  [<c019d181>] sysfs_drop_dentry+0x141/0x149
>  [<c019d212>] sysfs_hash_and_remove+0x89/0x10e
>  [<c019f1fc>] sysfs_remove_link+0xe/0x10
>  [<c0221839>] device_rename+0x110/0x181
>  [<c025420a>] dev_change_name+0x11e/0x1ca
>  [<c02545e6>] dev_ifsioc+0x330/0x3d7
>  [<c0254d25>] dev_ioctl+0x350/0x46e
>  [<c0249792>] sock_ioctl+0x1be/0x1ca
>  [<c016f3c0>] do_ioctl+0x1c/0x53
>  [<c016f5e3>] vfs_ioctl+0x1ec/0x203
>  [<c016f643>] sys_ioctl+0x49/0x62
>  [<c0103cde>] sysenter_past_esp+0x5f/0x99
>  =======================

The above tracing was caused by CONFIG_SYSFS_DEPRECATED=y and by setting
this to n, the tracing disappeared..  Still, all my network cards are
non-functional.  Entries in /sys/class/net are bogus:

/ # cd /sys/class/net/
/sys/class/net # ls
eth1  eth44  eth54  lo

/sys/class/net # cd eth1
-bash: cd: eth1: No such file or directory

/sys/class/net # ls -l eth1
lrwxrwxrwx 1 root root 0 Apr 26 07:15 eth1 ->
../../devices/pci0000:00/0000:00:12.0/net/eth0

/sys/class/net # cd ../../devices/pci0000\:00/0000\:00\:12.0/net/eth0
-bash: cd: ../../devices/pci0000:00/0000:00:12.0/net/eth0: No such file
or directory

Do you know of any patches I need to revert/apply?  Anyway, I have to
boot back to this kernel and find out more what's going on.

Tony

Re: Nonfunctional ethernet (was Re: 2.6.21-rc7-mm1 + sysfs-oops-workaround.patch -- INFO: possible recursive locking detected)

[Antonino A. Daplas]

On Thu, 2007-04-26 at 07:45 +0800, Antonino A. Daplas wrote:
> On Wed, 2007-04-25 at 22:48 +0800, Antonino A. Daplas wrote:
> > On Wed, 2007-04-25 at 14:18 +0900, Tejun Heo wrote:
> > > Miles Lane wrote:
> 
> > eth0 renamed to eth54
> > BUG: atomic counter underflow at:
> >  [<c0104378>] show_trace_log_lvl+0x1a/0x30
> >  [<c0104ec9>] show_trace+0x12/0x14
> >  [<c0104f22>] dump_stack+0x16/0x18
> >  [<c01bd575>] _atomic_dec_and_lock+0x29/0x4c
> >  [<c0174388>] dput+0x34/0x103
> >  [<c019d181>] sysfs_drop_dentry+0x141/0x149
> >  [<c019d212>] sysfs_hash_and_remove+0x89/0x10e
> >  [<c019f1fc>] sysfs_remove_link+0xe/0x10
> >  [<c0221839>] device_rename+0x110/0x181
> >  [<c025420a>] dev_change_name+0x11e/0x1ca
> >  [<c02545e6>] dev_ifsioc+0x330/0x3d7
> >  [<c0254d25>] dev_ioctl+0x350/0x46e
> >  [<c0249792>] sock_ioctl+0x1be/0x1ca
> >  [<c016f3c0>] do_ioctl+0x1c/0x53
> >  [<c016f5e3>] vfs_ioctl+0x1ec/0x203
> >  [<c016f643>] sys_ioctl+0x49/0x62
> >  [<c0103cde>] sysenter_past_esp+0x5f/0x99
> >  =======================
> 
> The above tracing was caused by CONFIG_SYSFS_DEPRECATED=y and by setting
> this to n, the tracing disappeared..  Still, all my network cards are
> non-functional.  Entries in /sys/class/net are bogus:
> 
> / # cd /sys/class/net/
> /sys/class/net # ls
> eth1  eth44  eth54  lo
> 
> /sys/class/net # cd eth1
> -bash: cd: eth1: No such file or directory
> 
> /sys/class/net # ls -l eth1
> lrwxrwxrwx 1 root root 0 Apr 26 07:15 eth1 ->
> ../../devices/pci0000:00/0000:00:12.0/net/eth0
> 
> /sys/class/net # cd ../../devices/pci0000\:00/0000\:00\:12.0/net/eth0
> -bash: cd: ../../devices/pci0000:00/0000:00:12.0/net/eth0: No such file
> or directory
> 
> Do you know of any patches I need to revert/apply?  Anyway, I have to
> boot back to this kernel and find out more what's going on.
> 

More info.

I can bring up the network manually using ifconfig.  It's opensuse's
rcnetwork script that fails to bring the network up. Entries
in /sys/class/net are still bogus.

This kernel is now usable to me, I'll start bisection later today if
nobody has an answer.

Tony 

Re: Nonfunctional ethernet (was Re: 2.6.21-rc7-mm1 + sysfs-oops-workaround.patch -- INFO: possible recursive locking detected)

[Andrew Morton]

On Thu, 26 Apr 2007 09:02:02 +0800 "Antonino A. Daplas" <adaplas@gmail.com> wrote:

> I can bring up the network manually using ifconfig.  It's opensuse's
> rcnetwork script that fails to bring the network up. Entries
> in /sys/class/net are still bogus.
> 
> This kernel is now usable to me, I'll start bisection later today if
> nobody has an answer.

rc7-mm1 is hardly worth bothering with.  Quite a few really bad ones have
now been fixed and I'll try to get rc7-mm2 out within the next 12 hours (I
assume a 76-hour debug session won't be needed this time).

But I don't think the sysfs changes in Greg's tree have been updated, so
things will probably still fail in that area.  A suitable bisection
starting pair would be around gregkh-driver-*

Re: Nonfunctional ethernet (was Re: 2.6.21-rc7-mm1 + sysfs-oops-workaround.patch -- INFO: possible recursive locking detected)

[Tejun Heo]

Hello, Antonino, Andrew.

Andrew Morton wrote:
> On Thu, 26 Apr 2007 09:02:02 +0800 "Antonino A. Daplas" <adaplas@gmail.com> wrote:
> 
>> I can bring up the network manually using ifconfig.  It's opensuse's
>> rcnetwork script that fails to bring the network up. Entries
>> in /sys/class/net are still bogus.
>>
>> This kernel is now usable to me, I'll start bisection later today if
>> nobody has an answer.
> 
> rc7-mm1 is hardly worth bothering with.  Quite a few really bad ones have
> now been fixed and I'll try to get rc7-mm2 out within the next 12 hours (I
> assume a 76-hour debug session won't be needed this time).
> 
> But I don't think the sysfs changes in Greg's tree have been updated, so
> things will probably still fail in that area.  A suitable bisection
> starting pair would be around gregkh-driver-*

This is the rename bug I wrote about in the other thread.  Can you hold
-mm2 off a bit?  I'm almost done here.

Thanks.

-- 
tejun

Re: Nonfunctional ethernet (was Re: 2.6.21-rc7-mm1 + sysfs-oops-workaround.patch -- INFO: possible recursive locking detected)

[Andrew Morton]

On Thu, 26 Apr 2007 11:26:36 +0900 Tejun Heo <htejun@gmail.com> wrote:

> Hello, Antonino, Andrew.
> 
> Andrew Morton wrote:
> > On Thu, 26 Apr 2007 09:02:02 +0800 "Antonino A. Daplas" <adaplas@gmail.com> wrote:
> > 
> >> I can bring up the network manually using ifconfig.  It's opensuse's
> >> rcnetwork script that fails to bring the network up. Entries
> >> in /sys/class/net are still bogus.
> >>
> >> This kernel is now usable to me, I'll start bisection later today if
> >> nobody has an answer.
> > 
> > rc7-mm1 is hardly worth bothering with.  Quite a few really bad ones have
> > now been fixed and I'll try to get rc7-mm2 out within the next 12 hours (I
> > assume a 76-hour debug session won't be needed this time).
> > 
> > But I don't think the sysfs changes in Greg's tree have been updated, so
> > things will probably still fail in that area.  A suitable bisection
> > starting pair would be around gregkh-driver-*
> 
> This is the rename bug I wrote about in the other thread.

ok.

>  Can you hold -mm2 off a bit?  I'm almost done here.

sure.  I'm having much fun with all the obviously-wont-compile patches
which have been checked into various subsystem trees in the past 24 hours.

Please include simple instructions about which gregkh patches I should drop
when this new set comes in.

[PATCH] sysfs: use different lockdep subclass for s_active deactivation

[Tejun Heo]

A sysfs node can delete other sysfs files when accessed.  This results
in recursive s_active locking - read lock for file access, down lock
of the vicitim for deactivation.  Tell lockdep that it's okay.

Signed-off-by: Tejun Heo <htejun@gmail.com>
---
Miles, please test this patch.  It should remove the lockdep warning.
Fixes for the other two problems will soon follow.

Greg, Andrew, after all the fixes are verified, I'll merge the fixes
into the original patches and resend all the sysfs updates in better
shape.  Sorry about all the trouble.

Thanks.

diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 8f7b65e..4a418bd 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -60,7 +60,8 @@ void release_sysfs_dirent(struct sysfs_dirent * sd)
 	 * previous lie.
 	 */
 	if (!down_write_trylock(&sd->s_active))
-		rwsem_acquire(&sd->s_active.dep_map, 0, 0, _RET_IP_);
+		rwsem_acquire(&sd->s_active.dep_map,
+			      SYSFS_S_ACTIVE_DEACTIVATE, 0, _RET_IP_);
 	up_write(&sd->s_active);
 
 	sysfs_free_ino(sd->s_ino);
diff --git a/fs/sysfs/sysfs.h b/fs/sysfs/sysfs.h
index 4ed6f77..add2725 100644
--- a/fs/sysfs/sysfs.h
+++ b/fs/sysfs/sysfs.h
@@ -41,6 +41,17 @@ struct sysfs_dirent {
 	atomic_t		s_event;
 };
 
+/*
+ * A sysfs file which deletes another file when written to need to
+ * write lock the s_active of the victim while its s_active is read
+ * locked for the write operation.  Tell lockdep that this is okay.
+ */
+enum sysfs_s_active_class
+{
+	SYSFS_S_ACTIVE_NORMAL,		/* file r/w access, etc - default */
+	SYSFS_S_ACTIVE_DEACTIVATE,	/* file deactivation */
+};
+
 extern struct vfsmount * sysfs_mount;
 extern struct kmem_cache *sysfs_dir_cachep;
 
@@ -172,7 +183,7 @@ static inline void sysfs_put_active_two(struct sysfs_dirent *sd)
  */
 static inline void sysfs_deactivate(struct sysfs_dirent *sd)
 {
-	down_write(&sd->s_active);
+	down_write_nested(&sd->s_active, SYSFS_S_ACTIVE_DEACTIVATE);
 
 	/* s_active will be unlocked by the thread doing the final put
 	 * on @sd.  Lie to lockdep.

Re: [PATCH] sysfs: use different lockdep subclass for s_active deactivation

[Greg KH]

On Thu, Apr 26, 2007 at 11:50:47PM +0900, Tejun Heo wrote:
> A sysfs node can delete other sysfs files when accessed.  This results
> in recursive s_active locking - read lock for file access, down lock
> of the vicitim for deactivation.  Tell lockdep that it's okay.
> 
> Signed-off-by: Tejun Heo <htejun@gmail.com>
> ---
> Miles, please test this patch.  It should remove the lockdep warning.
> Fixes for the other two problems will soon follow.
> 
> Greg, Andrew, after all the fixes are verified, I'll merge the fixes
> into the original patches and resend all the sysfs updates in better
> shape.  Sorry about all the trouble.

Thanks, that will make it easier for me, as I've seen a lot of them go
floating by recently :)

greg k-h

Re: [PATCH] sysfs: use different lockdep subclass for s_active deactivation

[Miles Lane]

On 4/26/07, Tejun Heo <htejun@gmail.com> wrote:
> A sysfs node can delete other sysfs files when accessed.  This results
> in recursive s_active locking - read lock for file access, down lock
> of the vicitim for deactivation.  Tell lockdep that it's okay.
>
> Signed-off-by: Tejun Heo <htejun@gmail.com>
> ---
> Miles, please test this patch.  It should remove the lockdep warning.
> Fixes for the other two problems will soon follow.
>
> Greg, Andrew, after all the fixes are verified, I'll merge the fixes
> into the original patches and resend all the sysfs updates in better
> shape.  Sorry about all the trouble.

Should I test this with 2.6.21-rc7-mm2?
It doesn't apply cleanly.

# patch -p1 -l --dry-run < tejun.patch
patching file fs/sysfs/dir.c
Hunk #1 succeeded at 31 with fuzz 1 (offset -29 lines).
patching file fs/sysfs/sysfs.h
Hunk #1 succeeded at 40 (offset -1 lines).
Hunk #2 succeeded at 182 with fuzz 1 (offset -1 lines).

Re: [PATCH] sysfs: use different lockdep subclass for s_active deactivation

[Tejun Heo]

Miles Lane wrote:
> On 4/26/07, Tejun Heo <htejun@gmail.com> wrote:
>> A sysfs node can delete other sysfs files when accessed.  This results
>> in recursive s_active locking - read lock for file access, down lock
>> of the vicitim for deactivation.  Tell lockdep that it's okay.
>>
>> Signed-off-by: Tejun Heo <htejun@gmail.com>
>> ---
>> Miles, please test this patch.  It should remove the lockdep warning.
>> Fixes for the other two problems will soon follow.
>>
>> Greg, Andrew, after all the fixes are verified, I'll merge the fixes
>> into the original patches and resend all the sysfs updates in better
>> shape.  Sorry about all the trouble.
> 
> Should I test this with 2.6.21-rc7-mm2?
> It doesn't apply cleanly.
> 
> # patch -p1 -l --dry-run < tejun.patch
> patching file fs/sysfs/dir.c
> Hunk #1 succeeded at 31 with fuzz 1 (offset -29 lines).
> patching file fs/sysfs/sysfs.h
> Hunk #1 succeeded at 40 (offset -1 lines).
> Hunk #2 succeeded at 182 with fuzz 1 (offset -1 lines).

It's in the middle of gregkh patch series but you can safely ignore the
fuzzes.

-- 
tejun

Re: [PATCH] sysfs: use different lockdep subclass for s_active deactivation

[Miles Lane]

On 4/26/07, Tejun Heo <htejun@gmail.com> wrote:
> Miles Lane wrote:
> > On 4/26/07, Tejun Heo <htejun@gmail.com> wrote:
> >> A sysfs node can delete other sysfs files when accessed.  This results
> >> in recursive s_active locking - read lock for file access, down lock
> >> of the vicitim for deactivation.  Tell lockdep that it's okay.
> >>
> >> Signed-off-by: Tejun Heo <htejun@gmail.com>
> >> ---
> >> Miles, please test this patch.  It should remove the lockdep warning.
> >> Fixes for the other two problems will soon follow.
> >>
> >> Greg, Andrew, after all the fixes are verified, I'll merge the fixes
> >> into the original patches and resend all the sysfs updates in better
> >> shape.  Sorry about all the trouble.
> >
> > Should I test this with 2.6.21-rc7-mm2?
> > It doesn't apply cleanly.
> >
> > # patch -p1 -l --dry-run < tejun.patch
> > patching file fs/sysfs/dir.c
> > Hunk #1 succeeded at 31 with fuzz 1 (offset -29 lines).
> > patching file fs/sysfs/sysfs.h
> > Hunk #1 succeeded at 40 (offset -1 lines).
> > Hunk #2 succeeded at 182 with fuzz 1 (offset -1 lines).
>
> It's in the middle of gregkh patch series but you can safely ignore the
> fuzzes.

WIth this patch applied to 2.6.21-rc7-mm2, I am not seeing any of the
problems I reported against 2.6.21-mm1, except for one.  The first
time I tried to suspend from the Gnome Quit dialog, I heard the pop
associated with unloading the sound module, but all the buttons stayed
lit up until I touched the Synaptics mousepad.  Then the machine
entered the suspend state.  Subsequent attempts to suspend worked
without a hitch (no mousepad events required).  Another problem I
noticed is that the lib switch is not triggering a suspend.  I tried
repeatedly.

Thanks,
           Miles