From: "Guilherme G. Piccoli" <gpiccoli@linux.vnet.ibm.com>
To: Ram Pai <linuxram@us.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
linux-scsi@vger.kernel.org, MPT-FusionLinux.pdl@broadcom.com,
sathya.prakash@broadcom.com, chaitra.basappa@broadcom.com,
suganath-prabu.subramani@broadcom.com,
sreekanth.reddy@broadcom.com, brking@linux.vnet.ibm.com,
mauricfo@linux.vnet.ibm.com
Subject: Re: [PATCH v2] mpt3sas: Force request partial completion alignment
Date: Thu, 26 Jan 2017 16:37:46 -0200 [thread overview]
Message-ID: <588A41FA.5030302@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170126170234.GD5657@ram.oc3035372033.ibm.com>
On 01/26/2017 03:02 PM, Ram Pai wrote:
> On Thu, Jan 26, 2017 at 11:31:53AM -0200, Guilherme G. Piccoli wrote:
>> On 01/25/2017 09:46 PM, Martin K. Petersen wrote:
>>>>>>>> "Guilherme" == Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com> writes:
>>>
>>> Hi Guilherme,
>>
>> Hi Martin, thanks for the review!
>>
>>
>>>
>>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>>> index 75f3fce..e52c942 100644
>>> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>>> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>>> @@ -4657,6 +4657,8 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 msix_index, u32 reply)
>>> struct MPT3SAS_DEVICE *sas_device_priv_data;
>>> u32 response_code = 0;
>>> unsigned long flags;
>>> + unsigned int sector_sz;
>>> + struct request *req;
>>>
>>> mpi_reply = mpt3sas_base_get_reply_virt_addr(ioc, reply);
>>> scmd = _scsih_scsi_lookup_get_clear(ioc, smid);
>>> @@ -4715,6 +4717,21 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 msix_index, u32 reply)
>>> }
>>>
>>> xfer_cnt = le32_to_cpu(mpi_reply->TransferCount);
>>> +
>>> + /* In case of bogus fw or device, we could end up having
>>> + * unaligned partial completion. We can force alignment here,
>>> + * then scsi-ml does not need to handle this misbehavior.
>>> + */
>>> + sector_sz = scmd->device->sector_size;
>>> + req = scmd->request;
>>> + if (unlikely(sector_sz && req && (req->cmd_type == REQ_TYPE_FS) &&
>>> + (xfer_cnt % sector_sz))) {
>>>
>>> Maybe a bit zealous on the sanity checking...
>>
>> A bit...? heheh
>> Too much I'd say. Since this is dealing with a bogus FW scenario, I
>> found more safe to check everything...of course we can remove checks if
>> it's sure req isn't NULL ever. The sector_sz check is avoiding
>> degenerate cases, since our division below.
>>
>>
>>>
>>> + sdev_printk(KERN_INFO, scmd->device,
>>> + "unaligned partial completion avoided (xfer_cnt=%u, sector_sz=%u)\n",
>>> + xfer_cnt, sector_sz);
>>> + xfer_cnt = (xfer_cnt / sector_sz) * sector_sz;
>>>
>>> Not so keen on divisions. xfer_cnt = round_down(xfer_cnt, sector_sz), maybe?
>>>
>>
>> Martin, I might be completely wrong here (please correct me if this is
>> the case), but isn't C standard integer division a truncation that acts
>> like a round down? I checked (what I think is) the specification of C
>> language (ISO/IEC 9899:1999), and it seems the division proposed by Ram
>> Pai is accurate in this case. Also, both variables are unsigned.
>
> Guilherme, Its better to use round_down() instead of division. Among
> other things it saves a few nanoseconds.
Thanks Ram and Martin for the suggestion and explanation. I just sent a V3.
Cheers,
Guilherme
>
> RP
>
prev parent reply other threads:[~2017-01-26 18:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-24 15:47 [PATCH v2] mpt3sas: Force request partial completion alignment Guilherme G. Piccoli
2017-01-25 4:46 ` Sreekanth Reddy
2017-01-25 23:46 ` Martin K. Petersen
2017-01-26 13:31 ` Guilherme G. Piccoli
2017-01-26 17:02 ` Ram Pai
2017-01-26 18:37 ` Guilherme G. Piccoli [this message]
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=588A41FA.5030302@linux.vnet.ibm.com \
--to=gpiccoli@linux.vnet.ibm.com \
--cc=MPT-FusionLinux.pdl@broadcom.com \
--cc=brking@linux.vnet.ibm.com \
--cc=chaitra.basappa@broadcom.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=martin.petersen@oracle.com \
--cc=mauricfo@linux.vnet.ibm.com \
--cc=sathya.prakash@broadcom.com \
--cc=sreekanth.reddy@broadcom.com \
--cc=suganath-prabu.subramani@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).