All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@kernel.org>
To: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: Phil Oester <kernel@linuxace.com>, Arnd Bergmann <arnd@arndb.de>,
	Kashyap Desai <kashyap.desai@broadcom.com>,
	Sumit Saxena <sumit.saxena@broadcom.com>,
	Shivasharan S <shivasharan.srikanteshwara@broadcom.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Christoph Hellwig <hch@infradead.org>,
	"# 3.4.x" <stable@vger.kernel.org>,
	Anand Lodnoor <anand.lodnoor@broadcom.com>,
	Chandrakanth Patil <chandrakanth.patil@broadcom.com>,
	Hannes Reinecke <hare@suse.de>,
	megaraidlinux.pdl@broadcom.com,
	linux-scsi <linux-scsi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] scsi: megaraid_sas: check user-provided offsets
Date: Sun, 3 Jan 2021 19:49:39 +0100	[thread overview]
Message-ID: <CAK8P3a1kmoBeBM3Nk=VigR-CnN8c2HKC8eubrvLt1TpD7gsAHw@mail.gmail.com> (raw)
In-Reply-To: <739a3639944f099a76d145eb119b77701f13444d.camel@linux.ibm.com>

On Sun, Jan 3, 2021 at 6:00 PM James Bottomley <jejb@linux.ibm.com> wrote:
> On Sun, 2021-01-03 at 17:26 +0100, Arnd Bergmann wrote:
> [...]
> > @@ -8209,7 +8208,7 @@ megasas_mgmt_fw_ioctl(struct megasas_instance
> > *instance,
> >                 if (instance->consistent_mask_64bit)
> >                         put_unaligned_le64(sense_handle, sense_ptr);
> >                 else
> > -                       put_unaligned_le32(sense_handle, sense_ptr);
> > +                       put_unaligned_le64(sense_handle, sense_ptr);
> >         }
>
> This hunk can't be right.  It effectively means removing the if.

I'm just trying to restore the state before the regression introduced
in my 381d34e376e3 ("scsi: megaraid_sas: Check user-provided offsets").

The old code always stored 'sizeof(long)' bytes into sense_ptr,
regardless of instance->consistent_mask_64bit, but it would truncate
the address to 32 bit if that was cleared. This was clearly bogus
and I tried to make it do something more meaningful, only storing
8 bytes into the structure if it was configured for 64-bit DMA, regardless
of the capabilities of the kernel.

> However, the if is needed because sense_handle is a dma_addr_t which
> can be either 32 or 64 bit.  What about changing the if to
>
> if (sizeof(dma_addr_t) == 8)
>
> instead?

That would not be useful either, the device surely does not care
if the kernel supports 64-bit DMA. What we'd really need here is
someone with access to the interface specifications to see how
many bytes should be stored in the structure. I suspect always
storing 64 bits (as my patch does) is correct, and would send a
proper patch to remove the if() if Phil confirms that my test
patch fixes the regression.

        Arnd

  reply	other threads:[~2021-01-03 18:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-08 21:36 [PATCH 1/3] scsi: aacraid: improve compat_ioctl handlers Arnd Bergmann
2020-09-08 21:36 ` [PATCH 2/3] scsi: megaraid_sas: check user-provided offsets Arnd Bergmann
2020-09-10 16:34   ` Sasha Levin
2020-09-12  7:20   ` Christoph Hellwig
2020-09-12 17:03     ` Arnd Bergmann
2020-12-31  0:15   ` Phil Oester
2021-01-03 16:26     ` Arnd Bergmann
2021-01-03 17:00       ` James Bottomley
2021-01-03 18:49         ` Arnd Bergmann [this message]
2021-01-03 20:12           ` James Bottomley
2021-01-04 17:48       ` Phil Oester
2021-01-04 22:24         ` Arnd Bergmann
2020-09-08 21:36 ` [PATCH 3/3] scsi: megaraid_sas: simplify compat_ioctl handling Arnd Bergmann
2020-09-12  7:47   ` Christoph Hellwig
2020-09-12 12:49     ` Arnd Bergmann
2020-09-13  6:50       ` compat_alloc_user_space removal, was " Christoph Hellwig
2020-09-13 11:46         ` Arnd Bergmann
2020-09-17 14:55           ` Arnd Bergmann
2020-09-17 14:57             ` Christoph Hellwig
2020-09-12  7:09 ` [PATCH 1/3] scsi: aacraid: improve compat_ioctl handlers Christoph Hellwig
2020-09-17 15:02   ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK8P3a1kmoBeBM3Nk=VigR-CnN8c2HKC8eubrvLt1TpD7gsAHw@mail.gmail.com' \
    --to=arnd@kernel.org \
    --cc=anand.lodnoor@broadcom.com \
    --cc=arnd@arndb.de \
    --cc=chandrakanth.patil@broadcom.com \
    --cc=hare@suse.de \
    --cc=hch@infradead.org \
    --cc=jejb@linux.ibm.com \
    --cc=kashyap.desai@broadcom.com \
    --cc=kernel@linuxace.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=megaraidlinux.pdl@broadcom.com \
    --cc=shivasharan.srikanteshwara@broadcom.com \
    --cc=stable@vger.kernel.org \
    --cc=sumit.saxena@broadcom.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.