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: <CAADWXX_G7X6QkNuqnpMyr+MGP+nUhqPaifJrfC=m57mhJu2jdg@mail.gmail.com>
Date:   Thu, 10 Jan 2019 04:54:53 -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 Thu, Jan 10, 2019 at 2:12 AM Oleksij Rempel <o.rempel@...gutronix.de> wrote:
>
> sched_priority = 1 is enough to dramatically reduce latency
> on have system load produced by tasks with default user space prio.

.. and is this perhaps a way for a user to then make the system spend
inordinate amounts of time in the tty layer, and hurting other people?
I'm thinking threads using pty's etc as a way to make the system
unresponsive.

We have *never* had good results with random priority modifications.
People used to do this for the X server, and it helped in very
specific cases, and hurt enormously in others.

Why would anybody use a tty interface with a l;oopback adapter and
care about latency?

I can kind of see why you want to do this from a theoretical point,
but from a *practical* point of view it seems pointless. Why not use
more appropriate models like networking or pipes etc. IOW, I think you
should describe what you *really* are doing much more.

"hackbench with a loopback serial adapter" really doesn't sound like
something that should worry a lot of people.

My gut feel is that if somebody still cares deeply about serial line
latency, they should look at trying to see if they can do some of the
work directly without the bounce to the workqueue. We use workqueues
for a reason, but it's possible that some of it could be avoided at
least in special cases... And yours sounds like a special case.

                Linus