From: Kashyap Desai <kashyap.desai@broadcom.com>
To: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: out of range LBA using sg_raw
Date: Wed, 8 Mar 2017 19:51:54 +0530 [thread overview]
Message-ID: <cf343e80707394b8945cd7643f7beecd@mail.gmail.com> (raw)
Hi -
Need help to understand if below is something we should consider to be
fixed in megaraid_sas driver or call as unreal exposure.
I have created slice VD of size 10GB (raid 1) using 2 drives. Each
Physical Drive size is 256GB.
Last LBA of the VD and actual Physical disk associated with that VD is
different. Actual Physical disk has larger range of LBA compare VD.
Below is readcap detail of VD0
# sg_readcap /dev/sdu
Read Capacity results:
Last logical block address=20971519 (0x13fffff), Number of
blocks=20971520
Logical block length=512 bytes
Hence:
Device size: 10737418240 bytes, 10240.0 MiB, 10.74 GB
Using below sg_raw command, we should see "LBA out of range" sense. In
CDB 0x28, pass LBA beyond last lba of VD 0x13fffff.
sg_raw -r 4k /dev/sdx 28 00 01 4f ff ff 00 00 08 00
It works if VD created behind MR controller does not support Fast Path
Write.
In case of Fast Path Write, driver convert LBA of VD to underlying
Physical disk and send IO direct to the physical disk. Since Physical disk
has enough LBA range to respond, it will not send "LBA out of range
sense".
Megaraid_Sas driver never validate range of LBA for VD as it assume to be
validated by upper layer in scsi stack. Other sg_tool method like sg_dd,
sg_write, dd etc has checks of LBA range and driver never receive out of
range LBA.
What is a suggestion ? Shall I add check in megaraid_sas driver or it is
not a valid scenario as "sg_raw" tool can send any type of command which
does not require multiple sanity in driver.
Thanks, Kashyap
next reply other threads:[~2017-03-08 14:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-08 14:21 Kashyap Desai [this message]
2017-03-08 15:11 ` out of range LBA using sg_raw Christoph Hellwig
2017-03-08 15:59 ` Kashyap Desai
2017-03-08 16:04 ` Bart Van Assche
2017-03-08 16:15 ` Kashyap Desai
2017-03-08 16:06 ` Christoph Hellwig
2017-03-08 16:11 ` Kashyap Desai
2017-03-08 16:32 ` Martin K. Petersen
2017-03-08 16:49 ` Kashyap Desai
2017-03-09 0:40 ` Martin K. Petersen
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=cf343e80707394b8945cd7643f7beecd@mail.gmail.com \
--to=kashyap.desai@broadcom.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/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