linux-kernel - Re: [PATCH] printk: stop spining waiter when console resume to flush prb

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 for Android: free password hash cracker in your pocket

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

Message-ID: <YJkcVOfuSBFjI1Bt@google.com>
Date:   Mon, 10 May 2021 20:43:16 +0900
From:   Sergey Senozhatsky <senozhatsky@...omium.org>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Sergey Senozhatsky <senozhatsky@...omium.org>,
        Luo Jiaxing <luojiaxing@...wei.com>,
        sergey.senozhatsky@...il.com, rostedt@...dmis.org,
        john.ogness@...utronix.de, linux-kernel@...r.kernel.org,
        linuxarm@...wei.com, bobo.shaobowang@...wei.com
Subject: Re: [PATCH] printk: stop spining waiter when console resume to flush
 prb

On (21/05/10 12:17), Petr Mladek wrote:
> > 	rcu_read_lock();
> > 	...
> > 	console_unlock_preemptible();
> > 	...
> > 	rcu_read_unlock();
> > 
> > lockdep_assert_preemption_enabled() is not entirely reliable - it
> > depends on __lockdep_enabled, provided that system in question has
> > CONFIG_PROVE_LOCKING set.
>
> I understand the concern. I think that I would be able to sleep with
> this. I believe that such problems would be discovered soon.
>
> Also I doubt that it would spread that quickly. It is the same as
> with printk_deferred(). It is just a workaround for a problem
> that only few people are aware of.
>
> If it is still a concern, we could make it static and block
> any patches that would make it public.
>
> But it does not make sense to fight over this now.

Is any attempt to have alternative fixup solutions and discussions is
going to be labeled as a fight? Up to you, I'm personally not having
any fights.

> I am not sure that console_unlock_preemptible() is worth it after all.
> Luo has to prove that it might fix a real life problem.

Good point.

> I am sorry but I am not going to continue in this discussion.
[..]
> The current plan is to move console work to kthreads (separate
> preemptive context). Using IRQ is a complete opposite way.

I'm not objecting future directions.

I'm discussing current fixup proposals. And I'm not very super comfortable
with the approach that introduces dynamic duality to printk behaviour: new
printk behaviour or the old one, and that API is system wide available. That
IRQ thing is not beautiful, bit it's already there and it's working and we
now how it behaves. That's it.