linux-kernel - Re: [GIT PULL] first round of SCSI updates for the 5.13+ merge window

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-=wiErhCUj8tGjcZS9mA7Efnv4JO1aMg06GfSqL8nacG4xA@mail.gmail.com>
Date:   Fri, 2 Jul 2021 15:46:45 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     James Bottomley <James.Bottomley@...senpartnership.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        linux-scsi <linux-scsi@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] first round of SCSI updates for the 5.13+ merge window

On Fri, Jul 2, 2021 at 1:11 AM James Bottomley
<James.Bottomley@...senpartnership.com> wrote:
>
> This series consists of the usual driver updates (ufs, ibmvfc,
> megaraid_sas, lpfc, elx, mpi3mr, qedi, iscsi, storvsc, mpt3sas) with
> elx and mpi3mr being new drivers.  The major core change is a rework to
> drop the status byte handling macros and the old bit shifted
> definitions and the rest of the updates are minor fixes.

Grr. I noticed this too late.

Why do we have that

        default y

for "config FC_APPID".

That makes absolutely zero sense to me. Not only don't we do "default
y" for new features _anyway_, but something like this is certainly
much too specialized to warrant it.

To make matters worse, it actually asks for this stupid thing *TWICE*.
Even if you say no the first time, it will then later on ask about
BLK_CGROUP_FC_APPID, and if you make the mistake to say 'y' on that
second try to push this feature, that will then do a "select FC_APPID"
to turn it on.

So honestly, it feels like

 (a) the "default y" is just completely wrong in all ways

 (b) this "config FC_APPID" shouldn't be a question AT ALL

IOW, it should likely purely be enabled by that 'select' for people
who decide they want BLK_CGROUP_FC_APPID (which properly defaults to
'n').

Pls advise. Or just send me a patch to fix it. Because the current
situation is most definitely not ok.

            Linus