On 10.10.19 20:06, Michal Hocko wrote:
On Thu 10-10-19 13:48:06, Qian Cai wrote:
On Thu, 2019-10-10 at 19:30 +0200, Michal Hocko wrote:
On Thu 10-10-19 10:47:38, Qian Cai wrote:
On Thu, 2019-10-10 at 16:18 +0200, Michal Hocko wrote:
On Thu 10-10-19 09:11:52, Qian Cai wrote:
On Thu, 2019-10-1
On Thu 10-10-19 13:48:06, Qian Cai wrote:
> On Thu, 2019-10-10 at 19:30 +0200, Michal Hocko wrote:
> > On Thu 10-10-19 10:47:38, Qian Cai wrote:
> > > On Thu, 2019-10-10 at 16:18 +0200, Michal Hocko wrote:
> > > > On Thu 10-10-19 09:11:52, Qian Cai wrote:
> > > > > On Thu, 2019-10-10 at 12:59 +0200
On Thu, 2019-10-10 at 19:30 +0200, Michal Hocko wrote:
> On Thu 10-10-19 10:47:38, Qian Cai wrote:
> > On Thu, 2019-10-10 at 16:18 +0200, Michal Hocko wrote:
> > > On Thu 10-10-19 09:11:52, Qian Cai wrote:
> > > > On Thu, 2019-10-10 at 12:59 +0200, Michal Hocko wrote:
> > > > > On Thu 10-10-19 05:0
On Thu 10-10-19 10:47:38, Qian Cai wrote:
> On Thu, 2019-10-10 at 16:18 +0200, Michal Hocko wrote:
> > On Thu 10-10-19 09:11:52, Qian Cai wrote:
> > > On Thu, 2019-10-10 at 12:59 +0200, Michal Hocko wrote:
> > > > On Thu 10-10-19 05:01:44, Qian Cai wrote:
> > > > >
> > > > >
> > > > > > On Oct 9,
On Thu, 2019-10-10 at 16:18 +0200, Michal Hocko wrote:
> On Thu 10-10-19 09:11:52, Qian Cai wrote:
> > On Thu, 2019-10-10 at 12:59 +0200, Michal Hocko wrote:
> > > On Thu 10-10-19 05:01:44, Qian Cai wrote:
> > > >
> > > >
> > > > > On Oct 9, 2019, at 12:23 PM, Michal Hocko wrote:
> > > > >
> >
On Thu 10-10-19 09:11:52, Qian Cai wrote:
> On Thu, 2019-10-10 at 12:59 +0200, Michal Hocko wrote:
> > On Thu 10-10-19 05:01:44, Qian Cai wrote:
> > >
> > >
> > > > On Oct 9, 2019, at 12:23 PM, Michal Hocko wrote:
> > > >
> > > > If this was only about the memory offline code then I would agree
On Thu, 2019-10-10 at 12:59 +0200, Michal Hocko wrote:
> On Thu 10-10-19 05:01:44, Qian Cai wrote:
> >
> >
> > > On Oct 9, 2019, at 12:23 PM, Michal Hocko wrote:
> > >
> > > If this was only about the memory offline code then I would agree. But
> > > we are talking about any printk from the zon
On Thu 2019-10-10 17:39:08, Sergey Senozhatsky wrote:
> On (10/10/19 10:21), Petr Mladek wrote:
> [..]
> > > > Considering that console.write is called from essentially arbitrary code
> > > > path IIUC then all the locks used in this path should be pretty much
> > > > tail locks or console internal
On Thu 10-10-19 05:01:44, Qian Cai wrote:
>
>
> > On Oct 9, 2019, at 12:23 PM, Michal Hocko wrote:
> >
> > If this was only about the memory offline code then I would agree. But
> > we are talking about any printk from the zone->lock context and that is
> > a bigger deal. Besides that it is qui
> On Oct 9, 2019, at 12:23 PM, Michal Hocko wrote:
>
> If this was only about the memory offline code then I would agree. But
> we are talking about any printk from the zone->lock context and that is
> a bigger deal. Besides that it is quite natural that the printk code
> should be more univer
On (10/10/19 10:21), Petr Mladek wrote:
[..]
> > > Considering that console.write is called from essentially arbitrary code
> > > path IIUC then all the locks used in this path should be pretty much
> > > tail locks or console internal ones without external dependencies.
> >
> > That's a good expe
On Thu 10-10-19 17:16:29, Sergey Senozhatsky wrote:
> On (10/10/19 09:40), Michal Hocko wrote:
> [..]
> > > > Considering that console.write is called from essentially arbitrary code
> > > > path IIUC then all the locks used in this path should be pretty much
> > > > tail locks or console internal
On Thu 2019-10-10 14:12:01, Sergey Senozhatsky wrote:
> On (10/09/19 16:26), Michal Hocko wrote:
> > On Wed 09-10-19 15:56:32, Peter Oberparleiter wrote:
> > [...]
> > > A generic solution would be preferable from my point of view though,
> > > because otherwise each console driver owner would need
On (10/10/19 09:40), Michal Hocko wrote:
[..]
> > > Considering that console.write is called from essentially arbitrary code
> > > path IIUC then all the locks used in this path should be pretty much
> > > tail locks or console internal ones without external dependencies.
> >
> > That's a good exp
On Wed 2019-10-09 10:46:14, Qian Cai wrote:
> On Wed, 2019-10-09 at 16:24 +0200, Petr Mladek wrote:
> > On Wed 2019-10-09 09:43:13, Qian Cai wrote:
> > > On Wed, 2019-10-09 at 15:27 +0200, Michal Hocko wrote:
> > > > On Wed 09-10-19 09:06:42, Qian Cai wrote:
> > > > [...]
> > > > > https://lore.ker
On Thu 10-10-19 14:12:01, Sergey Senozhatsky wrote:
> On (10/09/19 16:26), Michal Hocko wrote:
> > On Wed 09-10-19 15:56:32, Peter Oberparleiter wrote:
> > [...]
> > > A generic solution would be preferable from my point of view though,
> > > because otherwise each console driver owner would need t
On (10/09/19 16:26), Michal Hocko wrote:
> On Wed 09-10-19 15:56:32, Peter Oberparleiter wrote:
> [...]
> > A generic solution would be preferable from my point of view though,
> > because otherwise each console driver owner would need to ensure that any
> > lock taken in their console.write implem
On Wed 09-10-19 11:08:35, Qian Cai wrote:
> On Wed, 2019-10-09 at 16:34 +0200, Michal Hocko wrote:
> > On Wed 09-10-19 10:19:44, Qian Cai wrote:
> > > On Wed, 2019-10-09 at 15:51 +0200, Michal Hocko wrote:
> >
> > [...]
> > > > Can you paste the full lock chain graph to be sure we are on the same
On Wed, 2019-10-09 at 15:56 +0200, Peter Oberparleiter wrote:
> On 08.10.2019 18:08, Qian Cai wrote:
> > On Tue, 2019-10-08 at 14:56 +0200, Christian Borntraeger wrote:
> > > Adding Peter Oberparleiter.
> > > Peter, can you have a look?
> > >
> > > On 08.10.19 10:27, Michal Hocko wrote:
> > > > On
On Wed, 2019-10-09 at 16:34 +0200, Michal Hocko wrote:
> On Wed 09-10-19 10:19:44, Qian Cai wrote:
> > On Wed, 2019-10-09 at 15:51 +0200, Michal Hocko wrote:
>
> [...]
> > > Can you paste the full lock chain graph to be sure we are on the same
> > > page?
> >
> > WARNING: possible circular lockin
On Wed, 2019-10-09 at 16:24 +0200, Petr Mladek wrote:
> On Wed 2019-10-09 09:43:13, Qian Cai wrote:
> > On Wed, 2019-10-09 at 15:27 +0200, Michal Hocko wrote:
> > > On Wed 09-10-19 09:06:42, Qian Cai wrote:
> > > [...]
> > > > https://lore.kernel.org/linux-mm/1570460350.5576.290.ca...@lca.pw/
> > >
On Wed 09-10-19 10:19:44, Qian Cai wrote:
> On Wed, 2019-10-09 at 15:51 +0200, Michal Hocko wrote:
[...]
> > Can you paste the full lock chain graph to be sure we are on the same
> > page?
>
> WARNING: possible circular locking dependency detected
> 5.3.0-next-20190917 #8 Not tainted
> ---
On 08.10.2019 18:08, Qian Cai wrote:
> On Tue, 2019-10-08 at 14:56 +0200, Christian Borntraeger wrote:
>> Adding Peter Oberparleiter.
>> Peter, can you have a look?
>>
>> On 08.10.19 10:27, Michal Hocko wrote:
>>> On Tue 08-10-19 09:43:57, Petr Mladek wrote:
On Mon 2019-10-07 16:49:37, Michal
On Wed 09-10-19 15:56:32, Peter Oberparleiter wrote:
[...]
> A generic solution would be preferable from my point of view though,
> because otherwise each console driver owner would need to ensure that any
> lock taken in their console.write implementation is never held while
> memory is allocated/
On Wed 2019-10-09 09:43:13, Qian Cai wrote:
> On Wed, 2019-10-09 at 15:27 +0200, Michal Hocko wrote:
> > On Wed 09-10-19 09:06:42, Qian Cai wrote:
> > [...]
> > > https://lore.kernel.org/linux-mm/1570460350.5576.290.ca...@lca.pw/
> > >
> > > [ 297.425964] -> #1 (&port_lock_key){-.-.}:
> > > [ 29
On Wed, 2019-10-09 at 15:51 +0200, Michal Hocko wrote:
> On Wed 09-10-19 09:43:13, Qian Cai wrote:
> > On Wed, 2019-10-09 at 15:27 +0200, Michal Hocko wrote:
> > > On Wed 09-10-19 09:06:42, Qian Cai wrote:
> > > [...]
> > > > https://lore.kernel.org/linux-mm/1570460350.5576.290.ca...@lca.pw/
> > >
On Wed 09-10-19 09:43:13, Qian Cai wrote:
> On Wed, 2019-10-09 at 15:27 +0200, Michal Hocko wrote:
> > On Wed 09-10-19 09:06:42, Qian Cai wrote:
> > [...]
> > > https://lore.kernel.org/linux-mm/1570460350.5576.290.ca...@lca.pw/
> > >
> > > [ 297.425964] -> #1 (&port_lock_key){-.-.}:
> > > [ 297.
On Wed, 2019-10-09 at 15:27 +0200, Michal Hocko wrote:
> On Wed 09-10-19 09:06:42, Qian Cai wrote:
> [...]
> > https://lore.kernel.org/linux-mm/1570460350.5576.290.ca...@lca.pw/
> >
> > [ 297.425964] -> #1 (&port_lock_key){-.-.}:
> > [ 297.425967]__lock_acquire+0x5b3/0xb40
> > [ 297.425
On Wed 09-10-19 09:06:42, Qian Cai wrote:
[...]
> https://lore.kernel.org/linux-mm/1570460350.5576.290.ca...@lca.pw/
>
> [ 297.425964] -> #1 (&port_lock_key){-.-.}:
> [ 297.425967]__lock_acquire+0x5b3/0xb40
> [ 297.425967]lock_acquire+0x126/0x280
> [ 297.425968]_raw_spi
On Wed, 2019-10-09 at 13:49 +0200, Petr Mladek wrote:
> On Tue 2019-10-08 15:35:24, Qian Cai wrote:
> > On Tue, 2019-10-08 at 21:17 +0200, Michal Hocko wrote:
> > > On Tue 08-10-19 15:06:13, Qian Cai wrote:
> > > > On Tue, 2019-10-08 at 20:35 +0200, Michal Hocko wrote:
> > >
> > > [...]
> > > > >
On Tue 2019-10-08 15:35:24, Qian Cai wrote:
> On Tue, 2019-10-08 at 21:17 +0200, Michal Hocko wrote:
> > On Tue 08-10-19 15:06:13, Qian Cai wrote:
> > > On Tue, 2019-10-08 at 20:35 +0200, Michal Hocko wrote:
> >
> > [...]
> > > > I fully agree that this class of lockdep splats are annoying especia
On Tue 2019-10-08 15:06:13, Qian Cai wrote:
> On Tue, 2019-10-08 at 20:35 +0200, Michal Hocko wrote:
> > On Tue 08-10-19 12:08:37, Qian Cai wrote:
> > > On Tue, 2019-10-08 at 14:56 +0200, Christian Borntraeger wrote:
> > > > Adding Peter Oberparleiter.
> > > > Peter, can you have a look?
> > > >
>
On Tue, 2019-10-08 at 21:17 +0200, Michal Hocko wrote:
> On Tue 08-10-19 15:06:13, Qian Cai wrote:
> > On Tue, 2019-10-08 at 20:35 +0200, Michal Hocko wrote:
>
> [...]
> > > I fully agree that this class of lockdep splats are annoying especially
> > > when they make the lockdep unusable but please
On Tue 08-10-19 15:06:13, Qian Cai wrote:
> On Tue, 2019-10-08 at 20:35 +0200, Michal Hocko wrote:
[...]
> > I fully agree that this class of lockdep splats are annoying especially
> > when they make the lockdep unusable but please discuss this with lockdep
> > maintainers and try to find some solu
On Tue, 2019-10-08 at 20:35 +0200, Michal Hocko wrote:
> On Tue 08-10-19 12:08:37, Qian Cai wrote:
> > On Tue, 2019-10-08 at 14:56 +0200, Christian Borntraeger wrote:
> > > Adding Peter Oberparleiter.
> > > Peter, can you have a look?
> > >
> > > On 08.10.19 10:27, Michal Hocko wrote:
> > > > On T
On Tue 08-10-19 12:08:37, Qian Cai wrote:
> On Tue, 2019-10-08 at 14:56 +0200, Christian Borntraeger wrote:
> > Adding Peter Oberparleiter.
> > Peter, can you have a look?
> >
> > On 08.10.19 10:27, Michal Hocko wrote:
> > > On Tue 08-10-19 09:43:57, Petr Mladek wrote:
> > > > On Mon 2019-10-07 16
On Tue, 2019-10-08 at 14:56 +0200, Christian Borntraeger wrote:
> Adding Peter Oberparleiter.
> Peter, can you have a look?
>
> On 08.10.19 10:27, Michal Hocko wrote:
> > On Tue 08-10-19 09:43:57, Petr Mladek wrote:
> > > On Mon 2019-10-07 16:49:37, Michal Hocko wrote:
> > > > [Cc s390 maintainers
On Tue 08-10-19 10:03:01, Qian Cai wrote:
[..]
> I don't think there is "removing useful messages" in this patch. That one
> printk() in __offline_isolated_pages() basically as Michal mentioned it is
> that
> useful, but could be converted to printk_deferred() if anyone objected.
"remove from fre
On Tue, 2019-10-08 at 15:42 +0200, Petr Mladek wrote:
> On Tue 2019-10-08 09:23:52, Qian Cai wrote:
> > On Tue, 2019-10-08 at 09:13 -0400, Steven Rostedt wrote:
> > > On Tue, 8 Oct 2019 10:15:10 +0200
> > > Petr Mladek wrote:
> > >
> > > > There are basically three possibilities:
> > > >
> > > >
On Tue 08-10-19 15:42:56, Petr Mladek wrote:
[...]
> I am not -mm maintainer so I could not guarantee that a patch
> using printk_deferred() will get accepted. But it will have much
> bigger chance than the original patch.
I am not going to ack any such patch until it is clear what is the
actual p
On Tue 2019-10-08 09:23:52, Qian Cai wrote:
> On Tue, 2019-10-08 at 09:13 -0400, Steven Rostedt wrote:
> > On Tue, 8 Oct 2019 10:15:10 +0200
> > Petr Mladek wrote:
> >
> > > There are basically three possibilities:
> > >
> > > 1. Do crazy exercises with locks all around the kernel to
> > >av
On Tue 08-10-19 09:06:29, Qian Cai wrote:
> On Tue, 2019-10-08 at 14:39 +0200, Michal Hocko wrote:
> > On Tue 08-10-19 08:00:43, Qian Cai wrote:
> > >
> > >
> > > > On Oct 8, 2019, at 6:39 AM, Michal Hocko wrote:
> > > >
> > > > Have you actually triggered any real deadlock? With a zone->lock i
On Tue, 08 Oct 2019 09:23:52 -0400
Qian Cai wrote:
> I feel like that is what I trying to do, but there seems a lot of resistances
> with that approach where pragmatism met with perfectionism.
It's the way it came across. It sounded as if you were proposing
"the solution". I'm coming out and exp
On Tue, 2019-10-08 at 15:08 +0200, Petr Mladek wrote:
> On Mon 2019-10-07 10:59:10, Qian Cai wrote:
> > It is almost impossible to eliminate all the indirect call chains from
> > console_sem/console_owner_lock to zone->lock because it is too normal that
> > something later needs to allocate some me
On Tue, 2019-10-08 at 09:13 -0400, Steven Rostedt wrote:
> On Tue, 8 Oct 2019 10:15:10 +0200
> Petr Mladek wrote:
>
> > There are basically three possibilities:
> >
> > 1. Do crazy exercises with locks all around the kernel to
> >avoid the deadlocks. It is usually not worth it. And
> >it
On Tue, 8 Oct 2019 10:15:10 +0200
Petr Mladek wrote:
> There are basically three possibilities:
>
> 1. Do crazy exercises with locks all around the kernel to
>avoid the deadlocks. It is usually not worth it. And
>it is a "whack a mole" approach.
>
> 2. Use printk_deferred() in problemat
On Mon 2019-10-07 10:59:10, Qian Cai wrote:
> It is almost impossible to eliminate all the indirect call chains from
> console_sem/console_owner_lock to zone->lock because it is too normal that
> something later needs to allocate some memory dynamically, so as long as it
> directly call printk() wi
On Tue, 2019-10-08 at 14:39 +0200, Michal Hocko wrote:
> On Tue 08-10-19 08:00:43, Qian Cai wrote:
> >
> >
> > > On Oct 8, 2019, at 6:39 AM, Michal Hocko wrote:
> > >
> > > Have you actually triggered any real deadlock? With a zone->lock in
> > > place it would be pretty clear with hard lockups
Adding Peter Oberparleiter.
Peter, can you have a look?
On 08.10.19 10:27, Michal Hocko wrote:
> On Tue 08-10-19 09:43:57, Petr Mladek wrote:
>> On Mon 2019-10-07 16:49:37, Michal Hocko wrote:
>>> [Cc s390 maintainers - the lockdep is
>>> http://lkml.kernel.org/r/1570228005-24979-1-git-send-email
On Tue 08-10-19 08:00:43, Qian Cai wrote:
>
>
> > On Oct 8, 2019, at 6:39 AM, Michal Hocko wrote:
> >
> > Have you actually triggered any real deadlock? With a zone->lock in
> > place it would be pretty clear with hard lockups detected.
>
> Yes, I did trigger here and there, and those lockdep
> On Oct 8, 2019, at 6:39 AM, Michal Hocko wrote:
>
> Have you actually triggered any real deadlock? With a zone->lock in
> place it would be pretty clear with hard lockups detected.
Yes, I did trigger here and there, and those lockdep splats are especially
useful to figure out why.
On Tue 08-10-19 06:04:32, Qian Cai wrote:
>
>
> > On Oct 8, 2019, at 4:40 AM, Michal Hocko wrote:
> >
> > Does this tip point to a real deadlock or merely a class of lockdep
> > false dependencies?
>
> I lean towards it is a real deadlock given how trivial to generate those lock
> orders ever
> On Oct 8, 2019, at 4:40 AM, Michal Hocko wrote:
>
> Does this tip point to a real deadlock or merely a class of lockdep
> false dependencies?
I lean towards it is a real deadlock given how trivial to generate those lock
orders everywhere. On the other hand, it make a little different to sp
> On Oct 8, 2019, at 4:15 AM, Petr Mladek wrote:
>
> I am curious about CPU2. Does scheduler need to allocate memory?
It happens before with debug objects. It might not 100% necessary but it could
easily end up with this way in the current code. Moreover, this is just an
example of how thin
On Mon 07-10-19 11:33:27, Qian Cai wrote:
> On Mon, 2019-10-07 at 17:12 +0200, Michal Hocko wrote:
> > On Mon 07-10-19 10:59:10, Qian Cai wrote:
> > [...]
> > > It is almost impossible to eliminate all the indirect call chains from
> > > console_sem/console_owner_lock to zone->lock because it is to
On Tue 08-10-19 09:43:57, Petr Mladek wrote:
> On Mon 2019-10-07 16:49:37, Michal Hocko wrote:
> > [Cc s390 maintainers - the lockdep is
> > http://lkml.kernel.org/r/1570228005-24979-1-git-send-email-...@lca.pw
> > Petr has explained it is a false positive
> > http://lkml.kernel.org/r/2019100714
On Mon 2019-10-07 11:33:27, Qian Cai wrote:
> On Mon, 2019-10-07 at 17:12 +0200, Michal Hocko wrote:
> > On Mon 07-10-19 10:59:10, Qian Cai wrote:
> > [...]
> > > It is almost impossible to eliminate all the indirect call chains from
> > > console_sem/console_owner_lock to zone->lock because it is
On Mon 2019-10-07 16:49:37, Michal Hocko wrote:
> [Cc s390 maintainers - the lockdep is
> http://lkml.kernel.org/r/1570228005-24979-1-git-send-email-...@lca.pw
> Petr has explained it is a false positive
> http://lkml.kernel.org/r/20191007143002.l37bt2lzqtnqj...@pathway.suse.cz]
> On Mon 07-10-1
On Mon, 2019-10-07 at 17:12 +0200, Michal Hocko wrote:
> On Mon 07-10-19 10:59:10, Qian Cai wrote:
> [...]
> > It is almost impossible to eliminate all the indirect call chains from
> > console_sem/console_owner_lock to zone->lock because it is too normal that
> > something later needs to allocate
On Mon 07-10-19 10:59:10, Qian Cai wrote:
[...]
> It is almost impossible to eliminate all the indirect call chains from
> console_sem/console_owner_lock to zone->lock because it is too normal that
> something later needs to allocate some memory dynamically, so as long as it
> directly call printk(
On Mon, 2019-10-07 at 16:30 +0200, Petr Mladek wrote:
> On Fri 2019-10-04 18:26:45, Qian Cai wrote:
> > It is unsafe to call printk() while zone->lock was held, i.e.,
> >
> > zone->lock --> console_lock
> >
> > because the console could always allocate some memory in different code
> > paths and
[Cc s390 maintainers - the lockdep is
http://lkml.kernel.org/r/1570228005-24979-1-git-send-email-...@lca.pw
Petr has explained it is a false positive
http://lkml.kernel.org/r/20191007143002.l37bt2lzqtnqj...@pathway.suse.cz]
On Mon 07-10-19 16:30:02, Petr Mladek wrote:
[...]
> I believe that it c
On Fri 2019-10-04 18:26:45, Qian Cai wrote:
> It is unsafe to call printk() while zone->lock was held, i.e.,
>
> zone->lock --> console_lock
>
> because the console could always allocate some memory in different code
> paths and form locking chains in an opposite order,
>
> console_lock --> * --
On Mon 2019-10-07 09:07:02, Qian Cai wrote:
> On Mon, 2019-10-07 at 14:43 +0200, Michal Hocko wrote:
> > On Mon 07-10-19 08:11:44, Qian Cai wrote:
> > > On Mon, 2019-10-07 at 13:37 +0200, Michal Hocko wrote:
> > > > On Mon 07-10-19 07:04:00, Qian Cai wrote:
> > > > >
> > > > >
> > > > > > On Oct
On Mon, 2019-10-07 at 14:43 +0200, Michal Hocko wrote:
> On Mon 07-10-19 08:11:44, Qian Cai wrote:
> > On Mon, 2019-10-07 at 13:37 +0200, Michal Hocko wrote:
> > > On Mon 07-10-19 07:04:00, Qian Cai wrote:
> > > >
> > > >
> > > > > On Oct 7, 2019, at 4:07 AM, Michal Hocko wrote:
> > > > >
> > >
On Mon 07-10-19 08:11:44, Qian Cai wrote:
> On Mon, 2019-10-07 at 13:37 +0200, Michal Hocko wrote:
> > On Mon 07-10-19 07:04:00, Qian Cai wrote:
> > >
> > >
> > > > On Oct 7, 2019, at 4:07 AM, Michal Hocko wrote:
> > > >
> > > > I do not think that removing the printk is the right long term sol
On Mon, 2019-10-07 at 11:05 +0200, Petr Mladek wrote:
> On Mon 2019-10-07 10:07:42, Michal Hocko wrote:
> > On Fri 04-10-19 18:26:45, Qian Cai wrote:
> > > It is unsafe to call printk() while zone->lock was held, i.e.,
> > >
> > > zone->lock --> console_lock
> > >
> > > because the console could
On Mon, 2019-10-07 at 13:37 +0200, Michal Hocko wrote:
> On Mon 07-10-19 07:04:00, Qian Cai wrote:
> >
> >
> > > On Oct 7, 2019, at 4:07 AM, Michal Hocko wrote:
> > >
> > > I do not think that removing the printk is the right long term solution.
> > > While I do agree that removing the debuggin
On Mon 07-10-19 07:04:00, Qian Cai wrote:
>
>
> > On Oct 7, 2019, at 4:07 AM, Michal Hocko wrote:
> >
> > I do not think that removing the printk is the right long term solution.
> > While I do agree that removing the debugging printk __offline_isolated_pages
> > does make sense because it is e
On Mon 07-10-19 11:05:53, Petr Mladek wrote:
> On Mon 2019-10-07 10:07:42, Michal Hocko wrote:
> > On Fri 04-10-19 18:26:45, Qian Cai wrote:
> > > It is unsafe to call printk() while zone->lock was held, i.e.,
> > >
> > > zone->lock --> console_lock
> > >
> > > because the console could always al
On Mon 2019-10-07 10:07:42, Michal Hocko wrote:
> On Fri 04-10-19 18:26:45, Qian Cai wrote:
> > It is unsafe to call printk() while zone->lock was held, i.e.,
> >
> > zone->lock --> console_lock
> >
> > because the console could always allocate some memory in different code
> > paths and form loc
On Fri 04-10-19 18:26:45, Qian Cai wrote:
> It is unsafe to call printk() while zone->lock was held, i.e.,
>
> zone->lock --> console_lock
>
> because the console could always allocate some memory in different code
> paths and form locking chains in an opposite order,
>
> console_lock --> * -->
It is unsafe to call printk() while zone->lock was held, i.e.,
zone->lock --> console_lock
because the console could always allocate some memory in different code
paths and form locking chains in an opposite order,
console_lock --> * --> zone->lock
As the result, it triggers lockdep splats like
73 matches
Mail list logo
