linux-kernel - Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 14 Dec 2017 15:27:09 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>, Jan Kara <jack@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Rafael Wysocki <rjw@...ysocki.net>,
        Pavel Machek <pavel@....cz>,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

On Mon 2017-12-04 22:48:13, Sergey Senozhatsky wrote:
> Hello,
> 
> 	RFC
> 
> 	A new version, yet another rework. Lots of changes, e.g. hand off
> control based on Steven's patch. Another change is that this time around
> we finally have a kernel module to test printk offloading (YAYY!). The
> module tests a bunch use cases; we also have trace printk events to...
> trace offloading.

Ah, I know that it was me who was pessimistic about Steven's approach[1]
and persuaded you that offloading idea was still alive. But I am less
sure now.

My three main concerns about Steven's approach were:

1. I was afraid that it might introduce new type of deadlocks.

   But it seems that it is quite safe after all.

2. Steven's code, implementing the hand shake, is far from trivial.
   Few people were confused and reported false bugs.

   But the basic idea is pretty simple and straightforward. If
   we manage to encapsulate it into few helpers, it might become
   rather self-contained and maintainable. In each case, the needed
   changes are much smaller than I expected.

3. Soft-lockups are still theoretically possible with Steven's
   approach.

   But it seems to be quite efficient in many real life scenarios,
   including Tetsuo's stress testing. Or am I wrong?

Therefore I tend to give Steven's solution a chance before this
combined approach.

In each case, I do not feel comfortable with this combined solution.
I know that it might work much better that the two approaches
alone. But it has the complexity and possible risks of both
implementations. I would prefer to go with smaller steps.

[1] https://lkml.kernel.org/r/20171108102723.602216b1@gandalf.local.home

> I'll post the testing script and test module in reply
> to this mail. So... let's have some progress ;) The code is not completely
> awesome, but not tremendously difficult at the same time. We can verify
> the approach/design (we have tests and traces now) first and then start
> improving the code.

The testing module and code is great. Thanks a lot for posting it.

Best Regards,
Petr