linux-kernel - Re: [PATCH v3] auxdisplay: Remove in

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: <CANiq72mge40Uvqf3mb4uof2gi8ktvhjoodfyJY7uLW4guTnvDw@mail.gmail.com>
Date:   Tue, 16 Feb 2021 13:42:19 +0100
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Willy Tarreau <w@....eu>
Subject: Re: [PATCH v3] auxdisplay: Remove in_interrupt() usage.

On Tue, Feb 16, 2021 at 11:28 AM Sebastian Andrzej Siewior
<bigeasy@...utronix.de> wrote:
>
> Could we please avoid documenting the obvious? It is more or less common
> knowledge that the write callback (like any other) is preemptible user
> context (in which write occurs). The same is true for register/probe
> functions. The non-preemptible / atomic is mostly the exception because
> of the callback. Like from a timer or an interrupt.

It is not so much about documenting the obvious, but about stating
that 1) the precondition was properly taken into account and that 2)
nothing non-obvious is undocumented. When code is changed later on, it
is much more likely assumptions are broken if not documented.

In fact, from a quick git blame, that seems to be what happened here:
originally the function could be called from a public function
intended to be used from inside the kernel; so I assume it was the
intention to allow calls from softirq contexts. Then it was refactored
and the check never removed. In this case, the extra check is not a
big deal, but going in the opposite direction can happen too, and then
we will have a bug.

In general, when a patch for a fix is needed, it's usually a good idea
to add a comment right in the code. Even if only to avoid someone else
having to backtrack the calls to see it is only called form fs_ops
etc.

Cheers,
Miguel