[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK8P3a0FUL2FpF1Av47CK-9G3R9QdT3ihhA93gsFvfLVO3kC+Q@mail.gmail.com>
Date: Mon, 4 Jan 2021 23:24:59 +0100
From: Arnd Bergmann <arnd@...nel.org>
To: Phil Oester <kernel@...uxace.com>
Cc: Arnd Bergmann <arnd@...db.de>,
Kashyap Desai <kashyap.desai@...adcom.com>,
Sumit Saxena <sumit.saxena@...adcom.com>,
Shivasharan S <shivasharan.srikanteshwara@...adcom.com>,
"James E.J. Bottomley" <jejb@...ux.ibm.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Christoph Hellwig <hch@...radead.org>,
"# 3.4.x" <stable@...r.kernel.org>,
Anand Lodnoor <anand.lodnoor@...adcom.com>,
Chandrakanth Patil <chandrakanth.patil@...adcom.com>,
Hannes Reinecke <hare@...e.de>, megaraidlinux.pdl@...adcom.com,
linux-scsi <linux-scsi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/3] scsi: megaraid_sas: check user-provided offsets
On Mon, Jan 4, 2021 at 6:48 PM Phil Oester <kernel@...uxace.com> wrote:
>
> On Sun, Jan 03, 2021 at 05:26:29PM +0100, Arnd Bergmann wrote:
> > Thank you for the report and bisecting the issue, and sorry this broke
> > your system!
> >
> > Fortunately, the patch is fairly small, so there are only a limited number
> > of things that could go wrong. I haven't tried to analyze that message,
> > but I have two ideas:
> >
> > a) The added ioc->sense_off check gets triggered and the code relies
> > on the data being written outside of the structure
> >
> > b) the address actually needs to always be written as a 64-bit value
> > regardless of the instance->consistent_mask_64bit flag, as the
> > driver did before. This looked like it was done in error.
> >
> > Can you try the patch below instead of the revert and see if that
> > resolves the regression, and if it triggers the warning message I
> > add?
>
> Thanks Arnd, I tried your patch and it resolves the regression. It does not
> trigger the warning message you added.
Ok, thanks for testing! That would mean the range check is correct,
but the sense pointer must indeed be treated as a 64-bit entity
regardless of instance->consistent_mask_64bit, or at least the
upper 32 bit must be zero when the flag is unset, rather than
the recycled previous value.
I'll send a proper fix shortly, it would be nice if you could give it
another spin, but the behavior should be the same as this patch.
Arnd
Powered by blists - more mailing lists