Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue, 2007-03-20 at 15:21 +0100, Jan Kara wrote: > On Tue 20-03-07 14:35:10, Arjan van de Ven wrote: > > > > > > > Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex > > > being > > > acquired under dqptr_sem in quota code. But looking at the path from > > > con_close() there's another inversion with i_mutex which is also acquired > > > along the path for sysfs. And we can hardly get rid of it in the quota > > > code. > > > Now none of these is a real deadlock as quota should never call > > > print_warning() for sysfs (it doesn't use quota) but still it's nasty. I > > > suppose tty_mutex is above i_mutex because of those sysfs calls and it > > > seems sysfs must be called under tty_mutex because of races with > > > init_dev(). So it's not easy to get rid of that dependency either. > > > > maybe a far more serious option: Why on EARTH is the quota code going to > > TTY's directly? That's just WRONG. Maybe it wasn't 10 years ago, but > > nowadays most people use graphical user interfaces and the like... > We've been discussing this sometimes back in August ;) > (http://lkml.org/lkml/2006/8/8/237) and we've decided to leave the code in. > The only reason why I think it should stay in is the existence of quota > softlimits. There it's nice to warn the user and there's no other way to > propagate this information into userspace (as the write succeeds). > One solution would be to leave the warning to some userspace process > (like warnquota) run from cron but still I'm not sure we should change the > behavior. or send a uevent or something -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue 20-03-07 14:35:10, Arjan van de Ven wrote: > > > > Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being > > acquired under dqptr_sem in quota code. But looking at the path from > > con_close() there's another inversion with i_mutex which is also acquired > > along the path for sysfs. And we can hardly get rid of it in the quota code. > > Now none of these is a real deadlock as quota should never call > > print_warning() for sysfs (it doesn't use quota) but still it's nasty. I > > suppose tty_mutex is above i_mutex because of those sysfs calls and it > > seems sysfs must be called under tty_mutex because of races with > > init_dev(). So it's not easy to get rid of that dependency either. > > maybe a far more serious option: Why on EARTH is the quota code going to > TTY's directly? That's just WRONG. Maybe it wasn't 10 years ago, but > nowadays most people use graphical user interfaces and the like... We've been discussing this sometimes back in August ;) (http://lkml.org/lkml/2006/8/8/237) and we've decided to leave the code in. The only reason why I think it should stay in is the existence of quota softlimits. There it's nice to warn the user and there's no other way to propagate this information into userspace (as the write succeeds). One solution would be to leave the warning to some userspace process (like warnquota) run from cron but still I'm not sure we should change the behavior. Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue 20-03-07 14:44:46, Jarek Poplawski wrote: > On Tue, Mar 20, 2007 at 01:19:09PM +0100, Jan Kara wrote: > > On Tue 20-03-07 12:31:51, Jarek Poplawski wrote: > > > On Tue, Mar 20, 2007 at 12:22:53PM +0100, Jarek Poplawski wrote: > > > > On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote: > > > > ... > > > > > IMHO lockdep found that two locks are taken in different order: > > > > > > > > > > -> #1: 1) tty_mutex in con_console() 2) dqptr_sem (somewhere later) > > > > > -> #0: 1) dqptr_sem 2) tty_console in dquot_alloc_space() with > > > > > print_warning() > > > > > > Once more - should be: > > > -> #1: 1) tty_mutex in con_close() 2) dqptr_sem (somewhere later) > > > -> #0: 1) dqptr_sem 2) tty_mutex in dquot_alloc_space() with > > > print_warning() > > Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being > > acquired under dqptr_sem in quota code. But looking at the path from > > con_close() there's another inversion with i_mutex which is also acquired > > along the path for sysfs. And we can hardly get rid of it in the quota code. > > Now none of these is a real deadlock as quota should never call > > print_warning() for sysfs (it doesn't use quota) but still it's nasty. I > > suppose tty_mutex is above i_mutex because of those sysfs calls and it > > seems sysfs must be called under tty_mutex because of races with > > init_dev(). So it's not easy to get rid of that dependency either. > > I wonder if this cannot be done with a workqueue (message to a buffer, > maybe after try_lock on tty_mutex) and BTW isn't there any "modern" > way to queue console messages like these? I don't know about any such way... Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue, Mar 20, 2007 at 01:19:09PM +0100, Jan Kara wrote: > On Tue 20-03-07 12:31:51, Jarek Poplawski wrote: > > On Tue, Mar 20, 2007 at 12:22:53PM +0100, Jarek Poplawski wrote: > > > On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote: > > > ... > > > > IMHO lockdep found that two locks are taken in different order: > > > > > > > > -> #1: 1) tty_mutex in con_console() 2) dqptr_sem (somewhere later) > > > > -> #0: 1) dqptr_sem 2) tty_console in dquot_alloc_space() with > > > > print_warning() > > > > Once more - should be: > > -> #1: 1) tty_mutex in con_close() 2) dqptr_sem (somewhere later) > > -> #0: 1) dqptr_sem 2) tty_mutex in dquot_alloc_space() with > > print_warning() > Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being > acquired under dqptr_sem in quota code. But looking at the path from > con_close() there's another inversion with i_mutex which is also acquired > along the path for sysfs. And we can hardly get rid of it in the quota code. > Now none of these is a real deadlock as quota should never call > print_warning() for sysfs (it doesn't use quota) but still it's nasty. I > suppose tty_mutex is above i_mutex because of those sysfs calls and it > seems sysfs must be called under tty_mutex because of races with > init_dev(). So it's not easy to get rid of that dependency either. I wonder if this cannot be done with a workqueue (message to a buffer, maybe after try_lock on tty_mutex) and BTW isn't there any "modern" way to queue console messages like these? Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
> Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being > acquired under dqptr_sem in quota code. But looking at the path from > con_close() there's another inversion with i_mutex which is also acquired > along the path for sysfs. And we can hardly get rid of it in the quota code. > Now none of these is a real deadlock as quota should never call > print_warning() for sysfs (it doesn't use quota) but still it's nasty. I > suppose tty_mutex is above i_mutex because of those sysfs calls and it > seems sysfs must be called under tty_mutex because of races with > init_dev(). So it's not easy to get rid of that dependency either. maybe a far more serious option: Why on EARTH is the quota code going to TTY's directly? That's just WRONG. Maybe it wasn't 10 years ago, but nowadays most people use graphical user interfaces and the like... can we please just get rid of this instead? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue 20-03-07 12:31:51, Jarek Poplawski wrote: > On Tue, Mar 20, 2007 at 12:22:53PM +0100, Jarek Poplawski wrote: > > On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote: > > ... > > > IMHO lockdep found that two locks are taken in different order: > > > > > > -> #1: 1) tty_mutex in con_console() 2) dqptr_sem (somewhere later) > > > -> #0: 1) dqptr_sem 2) tty_console in dquot_alloc_space() with > > > print_warning() > > Once more - should be: > -> #1: 1) tty_mutex in con_close() 2) dqptr_sem (somewhere later) > -> #0: 1) dqptr_sem 2) tty_mutex in dquot_alloc_space() with print_warning() Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being acquired under dqptr_sem in quota code. But looking at the path from con_close() there's another inversion with i_mutex which is also acquired along the path for sysfs. And we can hardly get rid of it in the quota code. Now none of these is a real deadlock as quota should never call print_warning() for sysfs (it doesn't use quota) but still it's nasty. I suppose tty_mutex is above i_mutex because of those sysfs calls and it seems sysfs must be called under tty_mutex because of races with init_dev(). So it's not easy to get rid of that dependency either. Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote: ... > IMHO lockdep found that two locks are taken in different order: > > -> #1: 1) tty_mutex in con_console() 2) dqptr_sem (somewhere later) > -> #0: 1) dqptr_sem 2) tty_console in dquot_alloc_space() with print_warning() Should be: -> #0: 1) dqptr_sem 2) tty_mutex in dquot_alloc_space() with print_warning() Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote: ... IMHO lockdep found that two locks are taken in different order: - #1: 1) tty_mutex in con_console() 2) dqptr_sem (somewhere later) - #0: 1) dqptr_sem 2) tty_console in dquot_alloc_space() with print_warning() Should be: - #0: 1) dqptr_sem 2) tty_mutex in dquot_alloc_space() with print_warning() Jarek P. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue 20-03-07 12:31:51, Jarek Poplawski wrote: On Tue, Mar 20, 2007 at 12:22:53PM +0100, Jarek Poplawski wrote: On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote: ... IMHO lockdep found that two locks are taken in different order: - #1: 1) tty_mutex in con_console() 2) dqptr_sem (somewhere later) - #0: 1) dqptr_sem 2) tty_console in dquot_alloc_space() with print_warning() Once more - should be: - #1: 1) tty_mutex in con_close() 2) dqptr_sem (somewhere later) - #0: 1) dqptr_sem 2) tty_mutex in dquot_alloc_space() with print_warning() Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being acquired under dqptr_sem in quota code. But looking at the path from con_close() there's another inversion with i_mutex which is also acquired along the path for sysfs. And we can hardly get rid of it in the quota code. Now none of these is a real deadlock as quota should never call print_warning() for sysfs (it doesn't use quota) but still it's nasty. I suppose tty_mutex is above i_mutex because of those sysfs calls and it seems sysfs must be called under tty_mutex because of races with init_dev(). So it's not easy to get rid of that dependency either. Honza -- Jan Kara [EMAIL PROTECTED] SuSE CR Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being acquired under dqptr_sem in quota code. But looking at the path from con_close() there's another inversion with i_mutex which is also acquired along the path for sysfs. And we can hardly get rid of it in the quota code. Now none of these is a real deadlock as quota should never call print_warning() for sysfs (it doesn't use quota) but still it's nasty. I suppose tty_mutex is above i_mutex because of those sysfs calls and it seems sysfs must be called under tty_mutex because of races with init_dev(). So it's not easy to get rid of that dependency either. maybe a far more serious option: Why on EARTH is the quota code going to TTY's directly? That's just WRONG. Maybe it wasn't 10 years ago, but nowadays most people use graphical user interfaces and the like... can we please just get rid of this instead? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue, Mar 20, 2007 at 01:19:09PM +0100, Jan Kara wrote: On Tue 20-03-07 12:31:51, Jarek Poplawski wrote: On Tue, Mar 20, 2007 at 12:22:53PM +0100, Jarek Poplawski wrote: On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote: ... IMHO lockdep found that two locks are taken in different order: - #1: 1) tty_mutex in con_console() 2) dqptr_sem (somewhere later) - #0: 1) dqptr_sem 2) tty_console in dquot_alloc_space() with print_warning() Once more - should be: - #1: 1) tty_mutex in con_close() 2) dqptr_sem (somewhere later) - #0: 1) dqptr_sem 2) tty_mutex in dquot_alloc_space() with print_warning() Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being acquired under dqptr_sem in quota code. But looking at the path from con_close() there's another inversion with i_mutex which is also acquired along the path for sysfs. And we can hardly get rid of it in the quota code. Now none of these is a real deadlock as quota should never call print_warning() for sysfs (it doesn't use quota) but still it's nasty. I suppose tty_mutex is above i_mutex because of those sysfs calls and it seems sysfs must be called under tty_mutex because of races with init_dev(). So it's not easy to get rid of that dependency either. I wonder if this cannot be done with a workqueue (message to a buffer, maybe after try_lock on tty_mutex) and BTW isn't there any modern way to queue console messages like these? Jarek P. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue 20-03-07 14:44:46, Jarek Poplawski wrote: On Tue, Mar 20, 2007 at 01:19:09PM +0100, Jan Kara wrote: On Tue 20-03-07 12:31:51, Jarek Poplawski wrote: On Tue, Mar 20, 2007 at 12:22:53PM +0100, Jarek Poplawski wrote: On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote: ... IMHO lockdep found that two locks are taken in different order: - #1: 1) tty_mutex in con_console() 2) dqptr_sem (somewhere later) - #0: 1) dqptr_sem 2) tty_console in dquot_alloc_space() with print_warning() Once more - should be: - #1: 1) tty_mutex in con_close() 2) dqptr_sem (somewhere later) - #0: 1) dqptr_sem 2) tty_mutex in dquot_alloc_space() with print_warning() Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being acquired under dqptr_sem in quota code. But looking at the path from con_close() there's another inversion with i_mutex which is also acquired along the path for sysfs. And we can hardly get rid of it in the quota code. Now none of these is a real deadlock as quota should never call print_warning() for sysfs (it doesn't use quota) but still it's nasty. I suppose tty_mutex is above i_mutex because of those sysfs calls and it seems sysfs must be called under tty_mutex because of races with init_dev(). So it's not easy to get rid of that dependency either. I wonder if this cannot be done with a workqueue (message to a buffer, maybe after try_lock on tty_mutex) and BTW isn't there any modern way to queue console messages like these? I don't know about any such way... Honza -- Jan Kara [EMAIL PROTECTED] SuSE CR Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue 20-03-07 14:35:10, Arjan van de Ven wrote: Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being acquired under dqptr_sem in quota code. But looking at the path from con_close() there's another inversion with i_mutex which is also acquired along the path for sysfs. And we can hardly get rid of it in the quota code. Now none of these is a real deadlock as quota should never call print_warning() for sysfs (it doesn't use quota) but still it's nasty. I suppose tty_mutex is above i_mutex because of those sysfs calls and it seems sysfs must be called under tty_mutex because of races with init_dev(). So it's not easy to get rid of that dependency either. maybe a far more serious option: Why on EARTH is the quota code going to TTY's directly? That's just WRONG. Maybe it wasn't 10 years ago, but nowadays most people use graphical user interfaces and the like... We've been discussing this sometimes back in August ;) (http://lkml.org/lkml/2006/8/8/237) and we've decided to leave the code in. The only reason why I think it should stay in is the existence of quota softlimits. There it's nice to warn the user and there's no other way to propagate this information into userspace (as the write succeeds). One solution would be to leave the warning to some userspace process (like warnquota) run from cron but still I'm not sure we should change the behavior. Honza -- Jan Kara [EMAIL PROTECTED] SuSE CR Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dquot.c: possible circular locking Re: [2.6.20] BUG: workqueue leaked lock
On Tue, 2007-03-20 at 15:21 +0100, Jan Kara wrote: On Tue 20-03-07 14:35:10, Arjan van de Ven wrote: Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being acquired under dqptr_sem in quota code. But looking at the path from con_close() there's another inversion with i_mutex which is also acquired along the path for sysfs. And we can hardly get rid of it in the quota code. Now none of these is a real deadlock as quota should never call print_warning() for sysfs (it doesn't use quota) but still it's nasty. I suppose tty_mutex is above i_mutex because of those sysfs calls and it seems sysfs must be called under tty_mutex because of races with init_dev(). So it's not easy to get rid of that dependency either. maybe a far more serious option: Why on EARTH is the quota code going to TTY's directly? That's just WRONG. Maybe it wasn't 10 years ago, but nowadays most people use graphical user interfaces and the like... We've been discussing this sometimes back in August ;) (http://lkml.org/lkml/2006/8/8/237) and we've decided to leave the code in. The only reason why I think it should stay in is the existence of quota softlimits. There it's nice to warn the user and there's no other way to propagate this information into userspace (as the write succeeds). One solution would be to leave the warning to some userspace process (like warnquota) run from cron but still I'm not sure we should change the behavior. or send a uevent or something -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
