linux-kernel - Re: [PATCH v1 3/3] drivers/tty: increase priority for tty_buffer

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]

Message-ID: <CAHk-=whe72pccEAdQsp+UpjzKxXzsHbkiyaXbhG1UHnNg6uw1g@mail.gmail.com>
Date:   Mon, 28 Jan 2019 12:13:59 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Oleksij Rempel <o.rempel@...gutronix.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 3/3] drivers/tty: increase priority for tty_buffer_worker

On Mon, Jan 28, 2019 at 12:03 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> That's harder to do for reads - because incoming characters happen in
> interrupt context, but shouldn't be all that hard to do for writes.

Side note: the reason I mention this part is that "harder" may not
mean "impossible".

In particular, I wonder if we could do the tty buffer flipping in the
reader context too. Currently, what happens is that when we receive
characters, we schedule things for flipping with the workqueues. *BUT*
we could also just wake up any pending readers directly, and maybe
have the *readers* do the flip if they wake up before the workqueue.

And that would allow you to do real-time serial work simply by marking
the process *you* care about as RT, and not worry so much about the
workqueue threads at all. The workqueue threads would be fallbacks for
when there isn't an active reader at all.

I dunno. A bit handwavy, I know, but it sounds like if you care about
the read latency, that would be a better model entirely (skipping the
technically unnecessary kernel workqueue entirely).

              Linus