linux-kernel - Re: [PATCH] mm/page_isolation: fix a deadlock with printk()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sat, 5 Oct 2019 21:10:11 -0400
From:   Qian Cai <cai@....pw>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     mhocko@...nel.org, sergey.senozhatsky.work@...il.com,
        pmladek@...e.com, rostedt@...dmis.org, peterz@...radead.org,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/page_isolation: fix a deadlock with printk()



> On Oct 5, 2019, at 8:44 PM, Andrew Morton <akpm@...ux-foundation.org> 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
> makes sense".  We should be able to call printk() from anywhere, any
> time under any conditions.  That can't be done 100% but it is the
> objective.  printk() should be robust and not being able to call
> printk() while holding zone->lock isn't robust!
> 
> btw, this:
> 
> : It is unsafe to call printk() while zone->lock was held, i.e.,
> :
> :    zone->lock --> console_sem
> 
> doesn't make a lot of sense.  console_sem is a sleeping lock so
> attempting to acquire it (with down()!) under spinlock is a huge bug. 
> Again, please be careful with the descriptions.

Sorry, It is console_owner_lock.