[Bug 224037] Kernel crashes when trying to mount certain USB keys reported as WriteProtected

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

Conrad Meyer <***@freebsd.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-***@FreeBSD.org |freebsd-***@FreeBSD.org

--- Comment #2 from Conrad Meyer <***@freebsd.org> ---
Hm, this is probably below FS -- CAM.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #3 from Petr Leszkow <***@leszkow.eu> ---
(In reply to Conrad Meyer from comment #2)

Hi Condrad,

I checked the bug #224009 and the only difference in my case is, the USB key
was still connected to usb port during panic and crash, therefore the device
was not missing/removed physically from computer.

Basically, if the key is present in usb port, RO mount is successfull - system
is not affected. Umount - still OK, another mount - key still phys. connected,
but with RW option, crash is almost instatnt and the result is computer reboot.

Hope that helps to clarify the crash "sequence".

Thank you.

Petr
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #4 from Conrad Meyer <***@freebsd.org> ---
Petr,

I suspect when CAM sees EROFS or EIO errors due to write requests to read only
media failing, it ejects the device. Something about the ejection path is
failing to clean up references to some internal object, which is freed before
buffers referencing it can be released.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #5 from Conrad Meyer <***@freebsd.org> ---
Sorry, I should have looked more closely at the logs. 13 = EACCES.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #6 from Petr Leszkow <***@leszkow.eu> ---
btw, just checked SCSI Asignment at http://www.t10.org/lists/asc-num.htm#ASC_27

for ASC 27,0 ...see list bellow:

so, I think it would be sufficient if kernel can instruct the cam or any upper
layer to do not attempt to mount devices with ASC 27,0 and 27,1 as RW and
handle them for example as CD/DVD asc 27,4 asc 27,5 ?

What do you think ?

Thanks.

Petr




D - Direct Access Block Device (SBC-4) Device Column key
.Z - Host Managed Zoned Block Device (ZBC) ---------------------
. T - Sequential Access Device (SSC-5) blank = code not used
. P - Processor Device (SPC-2) not blank = code used
. .R - C/DVD Device (MMC-6)
. . O - Optical Memory Block Device (SBC)
. . M - Media Changer Device (SMC-3)
. . .A - Storage Array Device (SCC-2)SBC)
. . . E - SCSI Enclosure Services device (SES-3)
. . . B - Simplified Direct-Access (Reduced Block) device (RBC)
. . . .K - Optical Card Reader/Writer device (OCRW)
. . . . V - Automation/Device Interface device (ADC-4)
. . . . F - Object-based Storage Device (OSD-2)
ASC/ . . . . .
ASCQ DZTPROMAEBKVF Description
27/00 DZT RO BK WRITE PROTECTED
27/01 DZT RO BK HARDWARE WRITE PROTECTED
27/02 DZT RO BK LOGICAL UNIT SOFTWARE WRITE PROTECTED
27/03 T R ASSOCIATED WRITE PROTECT
27/04 T R PERSISTENT WRITE PROTECT
27/05 T R PERMANENT WRITE PROTECT
27/06 R F CONDITIONAL WRITE PROTECT
27/07 DZ B SPACE ALLOCATION FAILED WRITE PROTECT
27/08 DZ ZONE IS READ ONLY
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #7 from Petr Leszkow <***@leszkow.eu> ---
btw, just checked SCSI Asignment at http://www.t10.org/lists/asc-num.htm#ASC_27

for ASC 27,0 ...see list bellow:

so, I think it would be sufficient if kernel can instruct the cam or any upper
layer to do not attempt to mount devices with ASC 27,0 and 27,1 as RW and
handle them for example as CD/DVD asc 27,4 asc 27,5 ?

What do you think ?

Thanks.

Petr




D - Direct Access Block Device (SBC-4) Device Column key
.Z - Host Managed Zoned Block Device (ZBC) ---------------------
. T - Sequential Access Device (SSC-5) blank = code not used
. P - Processor Device (SPC-2) not blank = code used
. .R - C/DVD Device (MMC-6)
. . O - Optical Memory Block Device (SBC)
. . M - Media Changer Device (SMC-3)
. . .A - Storage Array Device (SCC-2)SBC)
. . . E - SCSI Enclosure Services device (SES-3)
. . . B - Simplified Direct-Access (Reduced Block) device (RBC)
. . . .K - Optical Card Reader/Writer device (OCRW)
. . . . V - Automation/Device Interface device (ADC-4)
. . . . F - Object-based Storage Device (OSD-2)
ASC/ . . . . .
ASCQ DZTPROMAEBKVF Description
27/00 DZT RO BK WRITE PROTECTED
27/01 DZT RO BK HARDWARE WRITE PROTECTED
27/02 DZT RO BK LOGICAL UNIT SOFTWARE WRITE PROTECTED
27/03 T R ASSOCIATED WRITE PROTECT
27/04 T R PERSISTENT WRITE PROTECT
27/05 T R PERMANENT WRITE PROTECT
27/06 R F CONDITIONAL WRITE PROTECT
27/07 DZ B SPACE ALLOCATION FAILED WRITE PROTECT
27/08 DZ ZONE IS READ ONLY
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

(da1:umass-sim1:1:0:0): CAM status: SCSI Status Error

Indicates CAM_SCSI_STATUS_ERROR.

(da1:umass-sim1:1:0:0): SCSI status: Check Condition

Indicates SCSI_STATUS_CHECK_COND -> camperiphscsisenseerror().

I don't have time right now to chase it below there and confirm my suspicion.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #9 from Conrad Meyer <***@freebsd.org> ---
(In reply to Petr Leszkow from comment #7)
It's more complicated than that :-). Filesystems will blindly try to mount R/W
and CAM needs to report an appropriate error, but not kill the device.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #10 from Andriy Gapon <***@FreeBSD.org> ---
I reported a similar, if not the same, problem in bug 210316.
If in this case it is also about msdosfs, then there is my analysis of the
issue in that bug.

Also, many years ago I made this proposal:
https://lists.freebsd.org/pipermail/freebsd-scsi/2011-April/004864.html
I still use that patch locally.
But it wouldn't help in this situation because of the initial r/w mount
attempt.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #11 from Petr Leszkow <***@leszkow.eu> ---
yes, the other OS'es report the fs on usb key as msdos too.

Just to confirm the hw "health" of the usb key, I just mounted it successfully
on mac os and linux boxes, both OS'es detected WriteProtect mode and mounted
key Read Only. Therefore I think imho we are missing proper SCSI/mode/CAM/etc
"sort of workflow or handling"

Basically as Andryi mentioned, correctly deteceted RO SCSI mode should be used
for or instruct "upper layers" to override default RW mode...



Petr(In reply to Andriy Gapon from comment #10)
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #12 from Conrad Meyer <***@freebsd.org> ---
(In reply to Andriy Gapon from comment #10)
Given it is a windows key, msdosfs seems likely. That may be the common thing
theme. Feel free to dupe this PR to that one.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #13 from Conrad Meyer <***@freebsd.org> ---
(In reply to Andriy Gapon from comment #10)
I have no objection to the concept of the patch proposed, but wouldn’t squash
EACCES or whatever to ENODEV.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #14 from Petr Leszkow <***@leszkow.eu> ---
(In reply to Conrad Meyer from comment #9)

yes, I can imagine that :) I am no developer, ....just a humble Isilon TA :)

Thumbs up for you for on FreeBSD and OneFS work!

I hope the bug can be fixed, it's not problem to avoid it, but it can be a bit
annoying especially for desktop users, where just "simple" key can crash your
desktop/laptop etc.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

Conrad Meyer <***@freebsd.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|New |Closed
Resolution|--- |DUPLICATE

--- Comment #15 from Conrad Meyer <***@freebsd.org> ---


*** This bug has been marked as a duplicate of bug 210316 ***
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #16 from Andriy Gapon <***@FreeBSD.org> ---
(In reply to Conrad Meyer from comment #13)
Call me stubborn, but to me EACCESS is from the realm of software (logical)
permissions, not from the realm of hardware access. I consider EACCESS and
EPERM as two confusing twins.
But my opinion is moot.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #17 from Andriy Gapon <***@FreeBSD.org> ---
(In reply to Petr Leszkow from comment #7)
I actually like the idea in this comment.
I think that we need to fix a bug that leads to the geom_vfs / buffer-cache
crash in any case.
It might be also nice to add the r/o mount fallback mechanism.

But on top of those things we could modify g_disk_access() to prevent the write
access altogether if a disk is in the write-protected mode. We could either
add a new flag to flags in struct disk or, perhaps, a new parameter (open mode)
to d_open.
scsi_da could then use either WP bit (0x80) in the device-specific byte of the
mode parameter header (dev_spec field of scsi_mode_header_6 /
scsi_mode_header_10) or SWP bit (SCP_SWP) in the Control mode page (0x0A) that
we query at PROBE_MODE_SENSE stage.

I am not sufficiently fluent with CAM to implement the CAM (scsi_da) part. The
geom_disk part is rather trivial, of course.

P.S.
It seems that scsi_sa.c already queries bit 7 in dev_spec, so that's an
example.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #18 from Conrad Meyer <***@freebsd.org> ---
(In reply to Andriy Gapon from comment #17)

Post by b***@freebsd.org
I think that we need to fix a bug that leads to the geom_vfs / buffer-cache
crash in any case.

Agreed. That's my focus with this chain of duplicated bugs.

Post by b***@freebsd.org
It might be also nice to add the r/o mount fallback mechanism.

Yes, although that is an orthogonal enhancement, IMO, and met some resistance
in the earlier attempt. If mount fails with EROFS or EACCES or whatever and
dmesg contains the same CAM errors they do now, I think sysamdmins will figure
it out.

Post by b***@freebsd.org
But on top of those things we could modify g_disk_access() to prevent the write
access altogether if a disk is in the write-protected mode.

Yeah, that makes sense too. It would reduce the complexity required in higher
level layers. Instead of having to wait for the first IO to fail (probably
whatever sets the dirty flag on a superblock), filesystems that rely on the
underlying device to be a GEOM object (e.g., msdosfs) will encounter an error
trying to g_access() (via g_vfs_open(..., 1)) the underlying disk writable.

That would also solve the initial bug without having to change the filesystem
level at all.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #19 from Conrad Meyer <***@freebsd.org> ---
So for (3), what is the right way to expose media readonly status to GEOM from
CAM?
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #20 from Conrad Meyer <***@freebsd.org> ---
(In reply to Conrad Meyer from comment #19)
We could export it via the d_getattr method, which for SCSI is dagetattr(). Or
more simply, we could put it in d_flags, set via e.g. daregister (again, for
SCSI).
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #21 from Andriy Gapon <***@FreeBSD.org> ---
(In reply to Conrad Meyer from comment #20)
Please see my proof of concept based on the second approach:
https://reviews.freebsd.org/D13360
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

Scott Long <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@FreeBSD.org

--- Comment #22 from Scott Long <***@FreeBSD.org> ---
Please use getattr, don't use flags. For things like this that are used only
at initialization, it's fine to use a slow path method like getattr. Save
flags for things that are more critical.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #23 from Andriy Gapon <***@FreeBSD.org> ---
(In reply to Scott Long from comment #22)

Scott,

I envisioned that g_disk_access would act on the WP bit and I am not sure if
using d_getattr there would be really convenient as it requires setting up a
bio, etc.
On the other hand, I think that it would be nice to expose the write-protect
status via a GEOM attribute for other uses.

Another question is whether it should scsi_da code that queries the WP bit or
whether it should be scsi_xpt. Right now dagetattr is short-circuited to
xpt_getattr. But it doesn't have to be, of course.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #24 from commit-***@freebsd.org ---
A commit references this bug:

Author: avg
Date: Mon Jan 15 11:20:01 UTC 2018
New revision: 327996
URL: https://svnweb.freebsd.org/changeset/base/327996

Log:
geom_disk / scsi_da: deny opening write-protected disks for writing

Ths change consists of two parts.

geom_disk: deny opening a disk for writing if it's marked as
write-protected. A new disk(9) flag is added to mark write protected
disks. A possible alternative could be to add another parameter to d_open,
so that the open mode could be passed to it and the disk drivers could
make the decision internally, but the flag required less churn.

scsi_da: add a new phase of disk probing to query the all pages mode
sense page. We can determine if the disk is write protected using bit 7
of the device specific field in the mode parameter header returned by
MODE SENSE.

PR: 224037
Reviewed by: mav
MFC after: 4 weeks
Differential Revision: https://reviews.freebsd.org/D13360

Changes:
head/sys/cam/scsi/scsi_da.c
head/sys/geom/geom_disk.c
head/sys/geom/geom_disk.h
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #25 from commit-***@freebsd.org ---
A commit references this bug:

Author: avg
Date: Thu Feb 15 15:33:18 UTC 2018
New revision: 329316
URL: https://svnweb.freebsd.org/changeset/base/329316

Log:
MFC r327996: geom_disk / scsi_da: deny opening write-protected disks for
writing

Ths change consists of two parts.

geom_disk: deny opening a disk for writing if it's marked as
write-protected. A new disk(9) flag is added to mark write protected
disks. A possible alternative could be to add another parameter to d_open,
so that the open mode could be passed to it and the disk drivers could
make the decision internally, but the flag required less churn.

scsi_da: add a new phase of disk probing to query the all pages mode
sense page. We can determine if the disk is write protected using bit 7
of the device specific field in the mode parameter header returned by
MODE SENSE.

PR: 224037

Changes:
_U stable/11/
stable/11/sys/cam/scsi/scsi_da.c
stable/11/sys/geom/geom_disk.c
stable/11/sys/geom/geom_disk.h
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037

--- Comment #26 from commit-***@freebsd.org ---
A commit references this bug:

Author: avg
Date: Thu Feb 15 16:31:36 UTC 2018
New revision: 329319
URL: https://svnweb.freebsd.org/changeset/base/329319

Log:
MFC r327996: geom_disk / scsi_da: deny opening write-protected disks for
writing

Ths change consists of two parts.

geom_disk: deny opening a disk for writing if it's marked as
write-protected. A new disk(9) flag is added to mark write protected
disks. A possible alternative could be to add another parameter to d_open,
so that the open mode could be passed to it and the disk drivers could
make the decision internally, but the flag required less churn.

scsi_da: add a new phase of disk probing to query the all pages mode
sense page. We can determine if the disk is write protected using bit 7
of the device specific field in the mode parameter header returned by
MODE SENSE.

PR: 224037

Changes:
_U stable/10/
stable/10/sys/cam/scsi/scsi_da.c
stable/10/sys/geom/geom_disk.c
stable/10/sys/geom/geom_disk.h
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de