From: Douglas Gilbert <dougg@torque.net>
To: Sumant Patro <sumantp@lsil.com>
Cc: Christoph Hellwig <hch@lst.de>,
Sreenivas.Bagalkote@lsil.com, Chandra_Nelogal@Dell.com,
linux-scsi@vger.kernel.org
Subject: Re: [PATCH] megaraid_sas: fix physical disk handling
Date: Fri, 10 Feb 2006 08:55:57 +1000 [thread overview]
Message-ID: <43EBC87D.3040205@torque.net> (raw)
In-Reply-To: <1139509820.4220.2.camel@dhcp80-31.lsil.com>
Sumant Patro wrote:
> Hello Christoph,
>
> Thank you for the patch.
>
> As you mentioned this patch allows scsi generic access to the
> physical disks. I see this as potential data integrity issue if someone
> does a write operation on a disk that belongs to a Logical RAID volume.
> I would rather prevent all access to the disks using slave_alloc(). I
> will be sending a patch shortly for review that implements
> megasas_slave_alloc to block all direct access to the physical disks.
Sumant,
Typically a non-root user would not have write (or read)
permissions on a sg device node. A root user (or perhaps
a user with CAP_SYS_RAWIO) could send a SCSI WRITE command
to a physical disk, but that is no different from the
current situation.
IMO The main reason to allow access to the physical "logical"
units is for tools like smartmontools and access for commands
like LOG SENSE and MODE SENSE (and perhaps the SELECT variants
of those commands used carefully). Add INQUIRY to that list ...
With FC and SAS dual ported disks one could also think about
taking a persistent reservation on one I_T nexus (e.g. the
active port) and only allow access to the physical disk via
the secondary port. That way the finer graded command
filtering of PERSISTENT RESERVATION could be used to guard
the integrity of the disk.
Doug Gilbert
next prev parent reply other threads:[~2006-02-09 22:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-06 14:05 [PATCH] megaraid_sas: fix physical disk handling Christoph Hellwig
2006-02-09 18:30 ` Sumant Patro
2006-02-09 22:55 ` Douglas Gilbert [this message]
2006-02-17 11:13 ` Christoph Hellwig
2006-02-18 3:02 ` Sumant Patro
-- strict thread matches above, loose matches on Subject: below --
2006-02-09 20:44 Salyzyn, Mark
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=43EBC87D.3040205@torque.net \
--to=dougg@torque.net \
--cc=Chandra_Nelogal@Dell.com \
--cc=Sreenivas.Bagalkote@lsil.com \
--cc=hch@lst.de \
--cc=linux-scsi@vger.kernel.org \
--cc=sumantp@lsil.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).