> On Oct 5, 2019, at 8:44 PM, Andrew Morton wrote:
>
> There is no "console_lock". Please be much more specific.
>
>> It is easier to avoid,
>>
>> zone_lock -> console_lock
>>
>> rather than fixing the opposite.
>
> "ease" isn't the main objective. A more important question is "what
> ma
> On Oct 5, 2019, at 7:29 PM, Andrew Morton wrote:
>
>> -> #2 (&(&zone->lock)->rlock){-.-.}:
>> lock_acquire+0x21a/0x468
>> _raw_spin_lock+0x54/0x68
>> get_page_from_freelist+0x8b6/0x2d28
>> __alloc_pages_nodemask+0x246/0x658
>> __get_free_pages+0x34/0x78
>>
On Sat, 5 Oct 2019 20:10:47 -0400 Qian Cai wrote:
>
>
> >> the existing dependency chain (in reverse order) is:
> >>
> >> -> #2 (&(&zone->lock)->rlock){-.-.}:
> >> lock_acquire+0x21a/0x468
> >> _raw_spin_lock+0x54/0x68
> >> get_page_from_freelist+0x8b6/0x2d28
> >> __all
On Fri, 4 Oct 2019 12:42:26 -0400 Qian Cai wrote:
> It is unsafe to call printk() while zone->lock was held, i.e.,
>
> zone->lock --> console_sem
>
> because the console could always allocate some memory in different code
> paths and form locking chains in an opposite order,
>
> console_sem -
On Fri, 2019-10-04 at 19:47 +0200, David Hildenbrand wrote:
> On 04.10.19 18:42, Qian Cai wrote:
> > It is unsafe to call printk() while zone->lock was held, i.e.,
> >
> > zone->lock --> console_sem
> >
> > because the console could always allocate some memory in different code
> > paths and form
On 04.10.19 18:42, Qian Cai wrote:
> It is unsafe to call printk() while zone->lock was held, i.e.,
>
> zone->lock --> console_sem
>
> because the console could always allocate some memory in different code
> paths and form locking chains in an opposite order,
>
> console_sem --> * --> zone->loc
It is unsafe to call printk() while zone->lock was held, i.e.,
zone->lock --> console_sem
because the console could always allocate some memory in different code
paths and form locking chains in an opposite order,
console_sem --> * --> zone->lock
As the result, it triggers lockdep splats like b
7 matches
Mail list logo
