Re: 2.6.21-rc suspend regression: sysfs deadlock

On Thu, 15 Mar 2007, Hugh Dickins wrote: > > sysfs_access_in_other_task() left me wondering what this "other" task > was, and what kind of "access" it's trying to get - or is the calling > task the other, and it's trying to access something it wouldn't > directly have access to? For naming

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Thu, 15 Mar 2007, Alan Stern wrote: > > Personally I don't understand what was wrong with my name. What's weird > or unintuitive about doing something in a different task's context? The only thing wrong with sysfs_do_something_in_a_different_task_context() is the length of the name. "do",

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Thu, 15 Mar 2007 10:27:19 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote: > Fair enough. One use of "delay" is in a comment you wrote; I'll change it > as well. Fine with me. > Would people be happier with sysfs_schedule_callback() and > device_schedule_callback()? At least the

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Thu, 15 Mar 2007, Cornelia Huck wrote: > > > The naming seems a bit unintuitive, but I don't have a good > > > alternative idea. Perhaps sysfs_work_struct, sysfs_delayed_work()? > > > > sysfs_work_struct is too generic; other parts of sysfs might also want to > > use workqueues for different

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Thu, 15 Mar 2007, Dmitry Torokhov wrote: > > How about sysfs_schedule_work? That is what it does - schedules a work > on a sysfs object and everyone here knows what schedule_work() does. I'm ashamed to have suggested anything else: certainly gets my vote. Hugh - To unsubscribe from this

Re: 2.6.21-rc suspend regression: sysfs deadlock

On 3/15/07, Oliver Neukum <[EMAIL PROTECTED]> wrote: Am Donnerstag, 15. März 2007 13:31 schrieb Hugh Dickins: > Quite apart from this mysterious "other task", I don't understand > "access" either. > > Perhaps "defer" would best capture the idea of another-task and > maybe-delay?

Re: 2.6.21-rc suspend regression: sysfs deadlock

Am Donnerstag, 15. März 2007 13:31 schrieb Hugh Dickins: > Quite apart from this mysterious "other task", I don't understand > "access" either. > > Perhaps "defer" would best capture the idea of another-task and > maybe-delay?  sysfs_defer_work(), struct sysfs_deferred_work? But we do not wish

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Thu, 15 Mar 2007, Cornelia Huck wrote: > On Wed, 14 Mar 2007 15:23:10 -0400 (EDT), > Alan Stern <[EMAIL PROTECTED]> wrote: > > > > sysfs_work_struct is too generic; other parts of sysfs might also want to > > use workqueues for different purposes. > > > I don't like calling it

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Wed, 14 Mar 2007 15:23:10 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote: > > > +struct other_task_struct { > > > + struct kobject *kobj; > > > + void(*func)(void *); > > > + void*data; > > > + struct work_struct work; > > > +}; > > > +

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Wed, 14 Mar 2007 15:23:10 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: +struct other_task_struct { + struct kobject *kobj; + void(*func)(void *); + void*data; + struct work_struct work; +}; + +static void

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Thu, 15 Mar 2007, Cornelia Huck wrote: On Wed, 14 Mar 2007 15:23:10 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: sysfs_work_struct is too generic; other parts of sysfs might also want to use workqueues for different purposes. I don't like calling it delayed-anything, because

Re: 2.6.21-rc suspend regression: sysfs deadlock

Am Donnerstag, 15. März 2007 13:31 schrieb Hugh Dickins: Quite apart from this mysterious other task, I don't understand access either. Perhaps defer would best capture the idea of another-task and maybe-delay?  sysfs_defer_work(), struct sysfs_deferred_work? But we do not wish to defer or

Re: 2.6.21-rc suspend regression: sysfs deadlock

On 3/15/07, Oliver Neukum [EMAIL PROTECTED] wrote: Am Donnerstag, 15. März 2007 13:31 schrieb Hugh Dickins: Quite apart from this mysterious other task, I don't understand access either. Perhaps defer would best capture the idea of another-task and maybe-delay? sysfs_defer_work(), struct

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Thu, 15 Mar 2007, Dmitry Torokhov wrote: How about sysfs_schedule_work? That is what it does - schedules a work on a sysfs object and everyone here knows what schedule_work() does. I'm ashamed to have suggested anything else: certainly gets my vote. Hugh - To unsubscribe from this list:

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Thu, 15 Mar 2007, Cornelia Huck wrote: The naming seems a bit unintuitive, but I don't have a good alternative idea. Perhaps sysfs_work_struct, sysfs_delayed_work()? sysfs_work_struct is too generic; other parts of sysfs might also want to use workqueues for different purposes.

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Thu, 15 Mar 2007 10:27:19 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: Fair enough. One use of delay is in a comment you wrote; I'll change it as well. Fine with me. Would people be happier with sysfs_schedule_callback() and device_schedule_callback()? At least the functions do

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Thu, 15 Mar 2007, Alan Stern wrote: Personally I don't understand what was wrong with my name. What's weird or unintuitive about doing something in a different task's context? The only thing wrong with sysfs_do_something_in_a_different_task_context() is the length of the name. do,

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Thu, 15 Mar 2007, Hugh Dickins wrote: sysfs_access_in_other_task() left me wondering what this other task was, and what kind of access it's trying to get - or is the calling task the other, and it's trying to access something it wouldn't directly have access to? For naming clashes, I'd

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Wed, 14 Mar 2007, Cornelia Huck wrote: > On Wed, 14 Mar 2007 12:12:37 -0400 (EDT), > Alan Stern <[EMAIL PROTECTED]> wrote: > > > This seems more elegant (not yet tested). Cornelia, does it look okay to > > you? > > Works for me (grouping & ungrouping ctc) and looks sane. Some more >

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Wed, 14 Mar 2007 12:12:37 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote: > This seems more elegant (not yet tested). Cornelia, does it look okay to > you? Works for me (grouping & ungrouping ctc) and looks sane. Some more comments below. > +struct other_task_struct { > + struct

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue, 13 Mar 2007, Linus Torvalds wrote: > Could we please make this easier to use by having some common sysfs helper > routine for this kind of "delayed_store()" functionality. > > I'm not a huge fan of delayed work at all, but if we have to have it, at > least make it one generic function

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue, 13 Mar 2007, Linus Torvalds wrote: Could we please make this easier to use by having some common sysfs helper routine for this kind of delayed_store() functionality. I'm not a huge fan of delayed work at all, but if we have to have it, at least make it one generic function rather

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Wed, 14 Mar 2007 12:12:37 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: This seems more elegant (not yet tested). Cornelia, does it look okay to you? Works for me (grouping ungrouping ctc) and looks sane. Some more comments below. +struct other_task_struct { + struct kobject

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Wed, 14 Mar 2007, Cornelia Huck wrote: On Wed, 14 Mar 2007 12:12:37 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: This seems more elegant (not yet tested). Cornelia, does it look okay to you? Works for me (grouping ungrouping ctc) and looks sane. Some more comments below.

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue, 13 Mar 2007, Hugh Dickins wrote: > On Tue, 13 Mar 2007, Alan Stern wrote: > > > > On the other hand, a quick survey of the kernel source shows that > > DEVICE_ATTR is used over 1500 times. Auditing all of them is not a job > > for the faint-of-heart! > > Indeed, and faint-hearted Hugh

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue, 13 Mar 2007, Cornelia Huck wrote: > > Another call that deadlocked with Oliver's patch is ungroup for s390 > ccwgroup devices. It can be made to work again with a similar patch. Could we please make this easier to use by having some common sysfs helper routine for this kind of

Re: 2.6.21-rc suspend regression: sysfs deadlock

On 3/13/07, Hugh Dickins <[EMAIL PROTECTED]> wrote: On Tue, 13 Mar 2007, Alan Stern wrote: > > On the other hand, a quick survey of the kernel source shows that > DEVICE_ATTR is used over 1500 times. Auditing all of them is not a job > for the faint-of-heart! Indeed, and faint-hearted Hugh

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue, 13 Mar 2007, Alan Stern wrote: > > On the other hand, a quick survey of the kernel source shows that > DEVICE_ATTR is used over 1500 times. Auditing all of them is not a job > for the faint-of-heart! Indeed, and faint-hearted Hugh wasn't intending to do so: but stout-hearted Alan will

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue, 13 Mar 2007, Hugh Dickins wrote: > On Tue, 13 Mar 2007, Alan Stern wrote: > > > > The consensus is that we would be better off keeping Oliver's original > > patch without your silly change, and instead fixing the particular method > > call that deadlocked. Can you please try out the

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue, 13 Mar 2007, Alan Stern wrote: > > The consensus is that we would be better off keeping Oliver's original > patch without your silly change, and instead fixing the particular method > call that deadlocked. Can you please try out the patch below with > everything else as it was before?

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue, 13 Mar 2007 11:00:21 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote: > The consensus is that we would be better off keeping Oliver's original > patch without your silly change, and instead fixing the particular method > call that deadlocked. Another call that deadlocked with

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue. 6 Mar 2007, Hugh Dickins wrote: > But suspend to RAM still hanging, unless I "chmod a-x /usr/sbin/docker" > on SuSE 10.2: docker undock tries to unregister /sys/block/sr0 and hangs: > > 60x60 D B0415080 0 10778 10771 (NOTLB) >e8227e04 0086

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue. 6 Mar 2007, Hugh Dickins wrote: But suspend to RAM still hanging, unless I chmod a-x /usr/sbin/docker on SuSE 10.2: docker undock tries to unregister /sys/block/sr0 and hangs: 60x60 D B0415080 0 10778 10771 (NOTLB) e8227e04 0086 e80c60b0

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue, 13 Mar 2007 11:00:21 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: The consensus is that we would be better off keeping Oliver's original patch without your silly change, and instead fixing the particular method call that deadlocked. Another call that deadlocked with Oliver's

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue, 13 Mar 2007, Alan Stern wrote: The consensus is that we would be better off keeping Oliver's original patch without your silly change, and instead fixing the particular method call that deadlocked. Can you please try out the patch below with everything else as it was before? It

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue, 13 Mar 2007, Hugh Dickins wrote: On Tue, 13 Mar 2007, Alan Stern wrote: The consensus is that we would be better off keeping Oliver's original patch without your silly change, and instead fixing the particular method call that deadlocked. Can you please try out the patch

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue, 13 Mar 2007, Alan Stern wrote: On the other hand, a quick survey of the kernel source shows that DEVICE_ATTR is used over 1500 times. Auditing all of them is not a job for the faint-of-heart! Indeed, and faint-hearted Hugh wasn't intending to do so: but stout-hearted Alan will need

Re: 2.6.21-rc suspend regression: sysfs deadlock

On 3/13/07, Hugh Dickins [EMAIL PROTECTED] wrote: On Tue, 13 Mar 2007, Alan Stern wrote: On the other hand, a quick survey of the kernel source shows that DEVICE_ATTR is used over 1500 times. Auditing all of them is not a job for the faint-of-heart! Indeed, and faint-hearted Hugh wasn't

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue, 13 Mar 2007, Hugh Dickins wrote: On Tue, 13 Mar 2007, Alan Stern wrote: On the other hand, a quick survey of the kernel source shows that DEVICE_ATTR is used over 1500 times. Auditing all of them is not a job for the faint-of-heart! Indeed, and faint-hearted Hugh wasn't

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue, 13 Mar 2007, Cornelia Huck wrote: Another call that deadlocked with Oliver's patch is ungroup for s390 ccwgroup devices. It can be made to work again with a similar patch. Could we please make this easier to use by having some common sysfs helper routine for this kind of

Re: 2.6.21-rc suspend regression: sysfs deadlock

[For the start of this thread, see .] On Wed, 7 Mar 2007, Linus Torvalds wrote: > So you just pointed to *another* data structure that apparently violates > the "you MUST use refcounting" rule. > > What is it with you people?

Re: 2.6.21-rc suspend regression: sysfs deadlock

[For the start of this thread, see http://marc.theaimsgroup.com/?l=linux-kernelm=117320893726621w=2.] On Wed, 7 Mar 2007, Linus Torvalds wrote: So you just pointed to *another* data structure that apparently violates the you MUST use refcounting rule. What is it with you people? It's

Fwd: Re: 2.6.21-rc suspend regression: sysfs deadlock

To let you hear the verdict. Regards Oliver -- Weitergeleitete Nachricht -- Subject: Re: 2.6.21-rc suspend regression: sysfs deadlock Date: Mittwoch, 7. März 2007 19:02 From: Linus Torvalds <[EMAIL PROTECTED]> To: Oliver Neukum <[EMAIL PROTE

Fwd: Re: 2.6.21-rc suspend regression: sysfs deadlock

To let you hear the verdict. Regards Oliver -- Weitergeleitete Nachricht -- Subject: Re: 2.6.21-rc suspend regression: sysfs deadlock Date: Mittwoch, 7. März 2007 19:02 From: Linus Torvalds [EMAIL PROTECTED] To: Oliver Neukum [EMAIL PROTECTED] Cc

Re: 2.6.21-rc suspend regression: sysfs deadlock

Am Mittwoch, 7. März 2007 19:02 schrieb Linus Torvalds: > > On Wed, 7 Mar 2007, Oliver Neukum wrote: > > > > The problem also exists with unplugging devices. Drivers get no feedback > > to tell them when it is safe to free the data structures associated with > > an attribute. > > So you just

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Wed, 7 Mar 2007, Oliver Neukum wrote: > > The problem also exists with unplugging devices. Drivers get no feedback > to tell them when it is safe to free the data structures associated with > an attribute. So you just pointed to *another* data structure that apparently violates the "you

Re: 2.6.21-rc suspend regression: sysfs deadlock

Am Mittwoch, 7. März 2007 17:52 schrieb Linus Torvalds: > > On Wed, 7 Mar 2007, Dmitry Torokhov wrote: > > > > ... with the exception that it will again make data associated with > > sysfs attributes accessible past the point of returning from > > sysfs_remove_file. And that was the point so

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Wed, 7 Mar 2007, Dmitry Torokhov wrote: > > ... with the exception that it will again make data associated with > sysfs attributes accessible past the point of returning from > sysfs_remove_file. And that was the point so drivers would not have to > care about handling access to extra data

Re: 2.6.21-rc suspend regression: sysfs deadlock

On 3/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: - removing the buffer is now just mutex_lock(>i_mutex); buffer = inode->i_private; inode->i_private = NULL; mutex_unlock(>i_mutex); put_sysfs_buffer(buffer); - everybody is happy! ... with the

Re: 2.6.21-rc suspend regression: sysfs deadlock

Am Mittwoch, 7. März 2007 02:56 schrieb Linus Torvalds: > Anyway, I'm unable to revert the broken commit, since there are now other > changes that depend on it, but can somebody *please* do that? I'll apply > Hugh's silly patch in the meantime, just to avoid the lockup. As you like it. This

Re: 2.6.21-rc suspend regression: sysfs deadlock

Am Mittwoch, 7. März 2007 02:56 schrieb Linus Torvalds: Anyway, I'm unable to revert the broken commit, since there are now other changes that depend on it, but can somebody *please* do that? I'll apply Hugh's silly patch in the meantime, just to avoid the lockup. As you like it. This patch

Re: 2.6.21-rc suspend regression: sysfs deadlock

On 3/6/07, Linus Torvalds [EMAIL PROTECTED] wrote: - removing the buffer is now just mutex_lock(inode-i_mutex); buffer = inode-i_private; inode-i_private = NULL; mutex_unlock(inode-i_mutex); put_sysfs_buffer(buffer); - everybody is happy! ... with the

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Wed, 7 Mar 2007, Dmitry Torokhov wrote: ... with the exception that it will again make data associated with sysfs attributes accessible past the point of returning from sysfs_remove_file. And that was the point so drivers would not have to care about handling access to extra data (such

Re: 2.6.21-rc suspend regression: sysfs deadlock

Am Mittwoch, 7. März 2007 17:52 schrieb Linus Torvalds: On Wed, 7 Mar 2007, Dmitry Torokhov wrote: ... with the exception that it will again make data associated with sysfs attributes accessible past the point of returning from sysfs_remove_file. And that was the point so drivers would

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue, 6 Mar 2007, Hugh Dickins wrote: > > This comes from Oliver's commit 94bebf4d1b8e7719f0f3944c037a21cfd99a4af7 > Driver core: fix race in sysfs between sysfs_remove_file() and read()/write() > in 2.6.21-rc1. It looks to me like sysfs_write_file downs buffer->sem > while calling

Re: 2.6.21-rc suspend regression: sysfs deadlock

Am Dienstag, 6. März 2007 20:20 schrieb Hugh Dickins: > This comes from Oliver's commit 94bebf4d1b8e7719f0f3944c037a21cfd99a4af7 > Driver core: fix race in sysfs between sysfs_remove_file() and read()/write() > in 2.6.21-rc1.  It looks to me like sysfs_write_file downs buffer->sem > while calling

2.6.21-rc suspend regression: sysfs deadlock

Resume from RAM on a ThinkPad T43p is now happy with Thomas' periodic tick fix - the most unusable aspect of that for me had been how slow repeat keys were to start repeating, but that's all fine now. But suspend to RAM still hanging, unless I "chmod a-x /usr/sbin/docker" on SuSE 10.2: docker

2.6.21-rc suspend regression: sysfs deadlock

Resume from RAM on a ThinkPad T43p is now happy with Thomas' periodic tick fix - the most unusable aspect of that for me had been how slow repeat keys were to start repeating, but that's all fine now. But suspend to RAM still hanging, unless I chmod a-x /usr/sbin/docker on SuSE 10.2: docker

Re: 2.6.21-rc suspend regression: sysfs deadlock

Am Dienstag, 6. März 2007 20:20 schrieb Hugh Dickins: This comes from Oliver's commit 94bebf4d1b8e7719f0f3944c037a21cfd99a4af7 Driver core: fix race in sysfs between sysfs_remove_file() and read()/write() in 2.6.21-rc1.  It looks to me like sysfs_write_file downs buffer-sem while calling

Re: 2.6.21-rc suspend regression: sysfs deadlock

On Tue, 6 Mar 2007, Hugh Dickins wrote: This comes from Oliver's commit 94bebf4d1b8e7719f0f3944c037a21cfd99a4af7 Driver core: fix race in sysfs between sysfs_remove_file() and read()/write() in 2.6.21-rc1. It looks to me like sysfs_write_file downs buffer-sem while calling