Re: [Linux-fbdev-devel] Re: [ACPI] inappropriate use of in_atomic()
On Fri, 2005-03-11 at 16:13 -0800, Andrew Morton wrote: > (where'd my cc go?) > > Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > > On Fri, 2005-03-11 at 01:46 -0800, Andrew Morton wrote: > > > Jan Kasprzak <[EMAIL PROTECTED]> wrote: > > > > > > > > This may be the cause of > > > > > > > > http://bugme.osdl.org/show_bug.cgi?id=4150 > > > > > > Looks that way, yes. > > > > Note that it would be interesting to fix that (I mean the reliability of > > is_atomic() or an alternative). I agree it's quite bad to rely on that > > in practice, but there are a few corner cases where it's useful (like > > oops handling in fbdev's etc...) > > > > That would require that we increment current->something on every > spin/read/write_lock and decrement it in unlock, even with !CONFIG_PREEMPT. > > iirc, Anton added an option to do that to the ppc64 build, decoupled from > CONFIG_PREEMPT (which ppc64 doesn't support). ppc64 _does_ support PREEMPT nowadays :) > But it's an appreciable amount of overhead. -- Benjamin Herrenschmidt <[EMAIL PROTECTED]> - 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: [Linux-fbdev-devel] Re: [ACPI] inappropriate use of in_atomic()
(where'd my cc go?) Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Fri, 2005-03-11 at 01:46 -0800, Andrew Morton wrote: > > Jan Kasprzak <[EMAIL PROTECTED]> wrote: > > > > > > This may be the cause of > > > > > > http://bugme.osdl.org/show_bug.cgi?id=4150 > > > > Looks that way, yes. > > Note that it would be interesting to fix that (I mean the reliability of > is_atomic() or an alternative). I agree it's quite bad to rely on that > in practice, but there are a few corner cases where it's useful (like > oops handling in fbdev's etc...) > That would require that we increment current->something on every spin/read/write_lock and decrement it in unlock, even with !CONFIG_PREEMPT. iirc, Anton added an option to do that to the ppc64 build, decoupled from CONFIG_PREEMPT (which ppc64 doesn't support). But it's an appreciable amount of overhead. - 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: [Linux-fbdev-devel] Re: [ACPI] inappropriate use of in_atomic()
On Fri, 2005-03-11 at 01:46 -0800, Andrew Morton wrote: > Jan Kasprzak <[EMAIL PROTECTED]> wrote: > > > > This may be the cause of > > > > http://bugme.osdl.org/show_bug.cgi?id=4150 > > Looks that way, yes. Note that it would be interesting to fix that (I mean the reliability of is_atomic() or an alternative). I agree it's quite bad to rely on that in practice, but there are a few corner cases where it's useful (like oops handling in fbdev's etc...) Ben. - 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: [ACPI] inappropriate use of in_atomic()
Jan Kasprzak <[EMAIL PROTECTED]> wrote: > > This may be the cause of > > http://bugme.osdl.org/show_bug.cgi?id=4150 Looks that way, yes. - 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: [ACPI] inappropriate use of in_atomic()
Andrew Morton wrote: : : in_atomic() is not a reliable indication of whether it is currently safe : to call schedule(). : : This is because the lockdepth beancounting which in_atomic() uses is only : accumulated if CONFIG_PREEMPT=y. in_atomic() will return false inside : spinlocks if CONFIG_PREEMPT=n. : : Consequently the use of in_atomic() in the below files is probably : deadlocky if CONFIG_PREEMPT=n: [...] : drivers/acpi/osl.c [...] This may be the cause of http://bugme.osdl.org/show_bug.cgi?id=4150 - I have recently verified that the problem described in bug #4150 disappears when CONFIG_PREEMPT=y is used. -Yenya -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ | > Whatever the Java applications and desktop dances may lead to, Unix will < > still be pushing the packets around for a quite a while. --Rob Pike < - 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: [ACPI] inappropriate use of in_atomic()
Andrew Morton wrote:
:
: in_atomic() is not a reliable indication of whether it is currently safe
: to call schedule().
:
: This is because the lockdepth beancounting which in_atomic() uses is only
: accumulated if CONFIG_PREEMPT=y. in_atomic() will return false inside
: spinlocks if CONFIG_PREEMPT=n.
:
: Consequently the use of in_atomic() in the below files is probably
: deadlocky if CONFIG_PREEMPT=n:
[...]
: drivers/acpi/osl.c
[...]
This may be the cause of
http://bugme.osdl.org/show_bug.cgi?id=4150
- I have recently verified that the problem described in bug #4150 disappears
when CONFIG_PREEMPT=y is used.
-Yenya
--
| Jan Yenya Kasprzak kas at {fi.muni.cz - work | yenya.net - private} |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ |
Whatever the Java applications and desktop dances may lead to, Unix will
still be pushing the packets around for a quite a while. --Rob Pike
-
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: [ACPI] inappropriate use of in_atomic()
Jan Kasprzak [EMAIL PROTECTED] wrote: This may be the cause of http://bugme.osdl.org/show_bug.cgi?id=4150 Looks that way, yes. - 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: [Linux-fbdev-devel] Re: [ACPI] inappropriate use of in_atomic()
On Fri, 2005-03-11 at 01:46 -0800, Andrew Morton wrote: Jan Kasprzak [EMAIL PROTECTED] wrote: This may be the cause of http://bugme.osdl.org/show_bug.cgi?id=4150 Looks that way, yes. Note that it would be interesting to fix that (I mean the reliability of is_atomic() or an alternative). I agree it's quite bad to rely on that in practice, but there are a few corner cases where it's useful (like oops handling in fbdev's etc...) Ben. - 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: [Linux-fbdev-devel] Re: [ACPI] inappropriate use of in_atomic()
(where'd my cc go?) Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Fri, 2005-03-11 at 01:46 -0800, Andrew Morton wrote: Jan Kasprzak [EMAIL PROTECTED] wrote: This may be the cause of http://bugme.osdl.org/show_bug.cgi?id=4150 Looks that way, yes. Note that it would be interesting to fix that (I mean the reliability of is_atomic() or an alternative). I agree it's quite bad to rely on that in practice, but there are a few corner cases where it's useful (like oops handling in fbdev's etc...) That would require that we increment current-something on every spin/read/write_lock and decrement it in unlock, even with !CONFIG_PREEMPT. iirc, Anton added an option to do that to the ppc64 build, decoupled from CONFIG_PREEMPT (which ppc64 doesn't support). But it's an appreciable amount of overhead. - 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: [Linux-fbdev-devel] Re: [ACPI] inappropriate use of in_atomic()
On Fri, 2005-03-11 at 16:13 -0800, Andrew Morton wrote: (where'd my cc go?) Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Fri, 2005-03-11 at 01:46 -0800, Andrew Morton wrote: Jan Kasprzak [EMAIL PROTECTED] wrote: This may be the cause of http://bugme.osdl.org/show_bug.cgi?id=4150 Looks that way, yes. Note that it would be interesting to fix that (I mean the reliability of is_atomic() or an alternative). I agree it's quite bad to rely on that in practice, but there are a few corner cases where it's useful (like oops handling in fbdev's etc...) That would require that we increment current-something on every spin/read/write_lock and decrement it in unlock, even with !CONFIG_PREEMPT. iirc, Anton added an option to do that to the ppc64 build, decoupled from CONFIG_PREEMPT (which ppc64 doesn't support). ppc64 _does_ support PREEMPT nowadays :) But it's an appreciable amount of overhead. -- Benjamin Herrenschmidt [EMAIL PROTECTED] - 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/
