retry mounting with ro when rw fails

[Garrett Cooper]

On Thu, Apr 7, 2011 at 5:00 PM, Jeremy Chadwick
<freebsd at jdc.parodius.com> wrote:
> On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote:
>> On Thu, Apr 7, 2011 at 10:25 AM, Andriy Gapon <avg at freebsd.org> wrote:
>> >
>> > [sorry for double post, it should have been "hackers" not "hardware"]
>> >
>> > Guys,
>> > could you please review and comment on the following patch?
>> > http://people.freebsd.org/~avg/mount-retry-ro.diff
>> > Thank you!
>> >
>> > The patch consists of two parts.
>> >
>> > The first part is in CAM/SCSI to make sure that ENODEV is consistently returned to
>> > signal that an operation is not supported by a device (in accordance to intro(2))
>> > and specifically to return ENODEV on write attempt to a read-only or
>> > write-protected media. ?Making this change in SCSI should cover real SCSI devices,
>> > as well as ATAPI through ahci/siis/atapicam or similar, plus majority (all?) of
>> > USB Mass Storage devices.
>> >
>> > The second part is in vfs_mount code. ?The idea is to re-try a mount call if we
>> > get the ENODEV error, and mounting was not already in read-only mode, and there
>> > was no explicit rw or noro option; the second try is changed to ro.
>> >
>> > I did only basic testing with an SD card in write-protected mode and a USB
>> > card-reader. ?Since I am not very familiar with vfs_mount code I might have missed
>> > some important details.
>>
>>     As a generic question / observation, maybe we should just
>> implement 'errors=remount-ro' (or a reasonable facsimile) like Linux
>> has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or
>> [Open]Solaris sported similar functionality.
>
> I was going to recommend exactly this.  :-)
>
> I like the idea of Andriy's patch, but would feel more comfortable if it
> were only used if a mount option was specified (-o errors=remount-ro").
> Why:
>
> Are there any conditions where ENODEV is returned to the underlying vfs
> layer for things like unexpected hardware issues?  I would imagine the
> latter would be ENXIO, but I'm not certain.  An example situation:
>
> 1. User inserts USB flash drive/etc.
> 2. User tries to mount disk R/W manually
> 3. Weird/bizarre hardware issue happens mid-mount (drive falling off
>   the bus, or maybe even the user yanking the drive right in the
>   middle) -- could this ever return ENODEV?
> 4. Kernel attempts re-mount, which also fails, or possibly panics
>   due to some underlying condition which nobody predicted
> 5. User mails mailing list
>
> If I'm worrying over nothing, then perfect.  :-)  My other concern is
> whether or not this mechanism change could caused some sort of "infinite
> loop" within devd(8)/devctl(4) where the daemon gets very confused as to
> what's going on or some automated commands get run when they shouldn't.

    Yeah. It seems like something else like EINVAL (just an example --
probably a bad one) would be better. Also, please be careful as
returning ENODEV seems to be UFS-specific:

     The following errors can occur for a ufs file system mount:

     [ENODEV]           A component of ufs_args fspec does not exist.

    Also, Tom Rhodes has a similar change to what I suggested on the
backburner, but it hasn't been 100% fleshed out yet.
Thanks,
-Garrett