[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87dc535f-609f-040a-5c47-5b6bb5b17b59@huawei.com>
Date: Tue, 25 Jan 2022 14:38:51 +0000
From: John Garry <john.garry@...wei.com>
To: Matthew Wilcox <willy@...radead.org>
CC: <jejb@...ux.ibm.com>, <martin.petersen@...cle.com>,
<artur.paszkiewicz@...el.com>, <jinpu.wang@...ud.ionos.com>,
<chenxiang66@...ilicon.com>, <Ajish.Koshy@...rochip.com>,
<yanaijie@...wei.com>, <linux-doc@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-scsi@...r.kernel.org>,
<linuxarm@...wei.com>, <liuqi115@...wei.com>,
<Viswas.G@...rochip.com>, <damien.lemoal@...nsource.wdc.com>
Subject: Re: [PATCH 05/16] scsi: libsas: Add struct sas_tmf_task
On 25/01/2022 14:15, Matthew Wilcox wrote:
>> Sure, but the pm8001 HW does has a 32b field, which is strange as the SAS
>> spec defines a 16b field in the task management Function information unit
>> "tag of task to be managed" field.
> My point is that it's only safe because the pm8001 driver already limits
> it to smaller than u16.
> Seeing language like "should be enough" made
> me think you'd just assumed that it would be.
I can update that wording to be confident that u16 is enough.
> Seeing a line like:
> u32 tag = 0xdeadbeef, rc = 0, n_elem = 0;
> made me think it might not be; perhaps 0xdeadbeef was being used as
> a flag value somewhere in the driver.
>
> For example ...
>
> drivers/scsi/pm8001/pm8001_hwi.c: int rc, tag = 0xdeadbeef;
> drivers/scsi/pm8001/pm8001_sas.c: u32 tag = 0xdeadbeef, rc = 0, n_elem = 0;
> drivers/scsi/pm8001/pm8001_sas.c: u32 tag = 0xdeadbeef;
> drivers/scsi/pm8001/pm80xx_hwi.c: if (ibutton0 == 0xdeadbeef && ibutton1 == 0xdeadbeef) {
> drivers/scsi/pm8001/pm80xx_hwi.c: int rc, tag = 0xdeadbeef;
>
> That doesn't seem to be the case though; as far as I can tell the
> tag value is never checked against 0xdeadbeef.
> .
Right, 0xdeadbeef is initially assigned just as a safety measure.
Thanks,
John
Powered by blists - more mailing lists