linux-kernel - Re: [PATCH AUTOSEL 4.18 24/58] Input: atakbd

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

Date:   Thu, 11 Oct 2018 17:03:33 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Sasha Levin <sashal@...nel.org>,
        Michael Schmitz <schmitzmic@...il.com>,
        stable <stable@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andreas Schwab <schwab@...ux-m68k.org>,
        Sasha Levin <alexander.levin@...rosoft.com>
Subject: Re: [PATCH AUTOSEL 4.18 24/58] Input: atakbd - fix Atari CapsLock
 behaviour

Hi Geert,

On Wed, Oct 10, 2018 at 09:04:08PM +0200, Geert Uytterhoeven wrote:
> Hi Dmitry,
> 
> On Wed, Oct 10, 2018 at 7:03 PM Dmitry Torokhov
> <dmitry.torokhov@...il.com> wrote:
> > Same goes for patches that deal with error handling in probe() functions
> > that your AUTOSEL scripts like to pick. Yes, they are fixing bugs. But
> > show me actually users affected by them? You encounter these issues with
> > probe when you do initial device bringup, but once device is stabilized
> > probes are expected to succeed. There won't be duplicate sysfs
> > attributes, memory will be allocated, and so on. Fixes to remove() might
> > be worthwhile if it is a hot-pluggable bus, but otherwise - no. Yes, the
> > box may OOPS if someone manually unbind device through sysfs, but the
> > solution is no to patch stable kernels, but simply tell user "dont to
> > that [yet]".
> 
> In modern days with -EPROBE_DEFER, bugs in probe() are much more likely
> to cause damage than before.

Yes, as usual, the real life is not quite as black-and-white as I
painted it to be ;)

If the patch handles failures that could be result of signalling
deferral I would consider it for stable. OTOH it is not very likely that
older, previously working device, will start signalling deferral where
it did not before, so if we see deferral it is likely we are dealing
with newer platform, and it is unclear how far stable backport should go
in this case. So again, choices, choices ;)

Thanks.

-- 
Dmitry