[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZCaUXHxYiPolI/lu@alley>
Date: Fri, 31 Mar 2023 10:05:48 +0200
From: Petr Mladek <pmladek@...e.com>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Luis Chamberlain <mcgrof@...nel.org>, david@...hat.com,
patches@...ts.linux.dev, linux-modules@...r.kernel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
petr.pavlu@...e.com, prarit@...hat.com, gregkh@...uxfoundation.org,
rafael@...nel.org, christophe.leroy@...roup.eu, tglx@...utronix.de,
song@...nel.org, rppt@...nel.org, willy@...radead.org,
vbabka@...e.cz, mhocko@...e.com, dave.hansen@...ux.intel.com
Subject: Re: [PATCH 4/7] sempahore: add a helper for a concurrency limiter
On Fri 2023-03-31 12:42:09, Sergey Senozhatsky wrote:
> On (23/03/30 09:23), Linus Torvalds wrote:
> > Although we also do have some other issues - I think down_trylock() is
> > ok in irq contexts, but mutex_trylock() is not. Maybe that's why
> > printk uses semaphores? I forget.
>
> Yes, correct. IIRC we also cannot safely call mutex_unlock() from IRQ
> context because it takes some internal mutex spin_lock in a non-IRQ-safe
> manner. Semaphore is OK in this regard, both semaphore try_lock() and
> unlock() can be called from IRQ.
One more reason is that mutex must be released in the same context
that took it. And printk() tries to pass console_sem() to another context.
It was added by the commit dbdda842fe96 ("printk: Add console owner
and waiter logic to load balance console writes"). It was relatively
effective in reducing the risk of soft lockups.
Best Regards,
Petr
Powered by blists - more mailing lists