Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Nix <nix@esperi.org.uk>
To:     "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc:     Khalid Aziz <khalid@gonehiking.org>,
        "James E.J. Bottomley" <jejb@linux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@oracle.com>,
        Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>,
        Christoph Hellwig <hch@lst.de>, linux-scsi@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] scsi: Set allocation length to 255 for ATA Information VPD page
References: <alpine.DEB.2.21.2104141244520.44318@angie.orcam.me.uk>
        <alpine.DEB.2.21.2104141306130.44318@angie.orcam.me.uk>
Emacs:  a compelling argument for pencil and paper.
Date:   Thu, 15 Apr 2021 13:42:02 +0100
In-Reply-To: <alpine.DEB.2.21.2104141306130.44318@angie.orcam.me.uk> (Maciej
        W. Rozycki's message of "Thu, 15 Apr 2021 00:39:28 +0200 (CEST)")
Message-ID: <878s5joh2d.fsf@esperi.org.uk>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On 14 Apr 2021, Maciej W. Rozycki stated:

> Set the allocation length to 255 for the ATA Information VPD page 
> requested in the WRITE SAME handler, so as not to limit information 
> examined by `scsi_get_vpd_page' in the supported vital product data 
> pages unnecessarily.
>
> Originally it was thought that Areca hardware may have issues with a 
> valid allocation length supplied for a VPD inquiry, however older SCSI 
> standard revisions[1] consider 255 the maximum length allowed and what 

Aaaah. That explains a lot! (Not that I can remember what SCSI standard
rev that Areca firmware claimed to implement. I know I never updated the
firmware, so it's going to be something no newer than mid-2009 and
probably quite a bit older.)

> Nix,
>
>  I can see you're still around.  Would you therefore please be so kind 
> as to verify this change with your Areca hardware if you still have it?

It's been up in the loft for years, but I'll get it out this weekend and
give it a spin :) this'll let me make sure the disks still spin as well,
which matters for an in-case-of-lightning-strike disaster-recovery
backup box.

(I just hope this kernel boots on it at all. It's about three years
since I retired it... let's see!)

>  It looks to me like you were thinking in the right direction with: 
> <https://lore.kernel.org/linux-scsi/87vc3nuipg.fsf@spindle.srvr.nix/>. 

It's the sort of mistake I could see myself making: an easy mistake to
make when so many things in C require buffer size - 1 or you get a
disastrous security hole...

-- 
NULL && (void)