Weirdness of "mount -o remount,rw" with write-protected floppy

Weirdness of "mount -o remount,rw" with write-protected floppy

[Evgeny Stambulchik]

Hello,

here is what I found the hard way (having lost the configuration of a 
firewall...):

# mount /dev/fd0 /mnt/floppy/
mount: block device /dev/fd0 is write-protected, mounting read-only
# mount -o remount,rw /mnt/floppy
# echo $?
0
# touch /mnt/floppy/blabla
# ls -l  /mnt/floppy/blabla
-rwxr-xr-x  1 root root 0 Oct 27 13:18 /mnt/floppy/blabla*
# umount /mnt/floppy
# echo $?
0
# mount /dev/fd0 /mnt/floppy/
mount: block device /dev/fd0 is write-protected, mounting read-only
# ls -l  /mnt/floppy/blabla
ls: /mnt/floppy/blabla: No such file or directory

The kernel actually tries to write to the floppy - the light is blinking 
(so everything looks nice from outside). Of course, there are kernel 
errors, seen in dmesg like:

 > end_request: I/O error, dev fd0, sector 21
 > Buffer I/O error on device fd0, logical block 21
 > lost page write due to I/O error on fd0

but these don't propagate to the user space in any way.

The bug is present in both 2.4 and 2.6, and is specific to floppy 
devices. Other RO media I tried (CDROM, RO-exported NFS) are partially 
OK, in the sense that a write attempt returns an error; however, "mount 
-o remount,rw" always returns success (this might be a bug in mount).

Regards,

Evgeny

Re: Weirdness of "mount -o remount,rw" with write-protected floppy

[Jon Masters]

On 10/27/05, Evgeny Stambulchik <Evgeny.Stambulchik@weizmann.ac.il> wrote:

> # mount /dev/fd0 /mnt/floppy/
> mount: block device /dev/fd0 is write-protected, mounting read-only
> # mount -o remount,rw /mnt/floppy
> # echo $?
> 0

Oops. That looks like a bug.

> The bug is present in both 2.4 and 2.6, and is specific to floppy
> devices. Other RO media I tried (CDROM, RO-exported NFS) are partially
> OK, in the sense that a write attempt returns an error; however, "mount
> -o remount,rw" always returns success (this might be a bug in mount).

Interesting. If nobody else gets there first, I'll take a look.

Jon.

Re: Weirdness of "mount -o remount,rw" with write-protected floppy

[Jon Masters]

On 10/27/05, Jon Masters <jonmasters@gmail.com> wrote:
> On 10/27/05, Evgeny Stambulchik <Evgeny.Stambulchik@weizmann.ac.il> wrote:
>
> > # mount /dev/fd0 /mnt/floppy/
> > mount: block device /dev/fd0 is write-protected, mounting read-only
> > # mount -o remount,rw /mnt/floppy
> > # echo $?
> > 0
>
> Oops. That looks like a bug.

Callchain is:

    sys_mount -> do_mount -> do_remount

and that then calls:

    do_remount_sb

which does:

    if (!(flags & MS_RDONLY) && bdev_read_only(sb->s_bdev))
                 return -EACCES;

So I'm missing something. I'll have another look, it's failing somewhere else.

Jon.

Re: Weirdness of "mount -o remount,rw" with write-protected floppy

[Jon Masters]

Folks,

An incidental point perhaps, but mounting a read-only file with a
writeable filesystem therein via loopback should probably also fail
with a suitable error (and doesn't right now).

Jon.

Re: Weirdness of "mount -o remount,rw" with write-protected floppy

[Rob Landley]

On Thursday 27 October 2005 06:57, Evgeny Stambulchik wrote:
> The bug is present in both 2.4 and 2.6, and is specific to floppy
> devices. Other RO media I tried (CDROM, RO-exported NFS) are partially
> OK, in the sense that a write attempt returns an error; however, "mount
> -o remount,rw" always returns success (this might be a bug in mount).

Busybox "mount" maintainer's ears perk up to see if this is relevant.  (After 
all, we have a separate implementation you can try to see if it's a tool 
bug.)

But no, this one's clearly a kernel error.  If the kernel is giving write 
errors against the device afterwards, than the kernel's internal state 
toggled successfully, which is all the mount syscall was trying to do.  Mount 
is just reporting whether or not the syscall succeeded, not whether or not it 
should have. :)

Rob

Re: Weirdness of "mount -o remount,rw" with write-protected floppy

[Evgeny Stambulchik]

Rob Landley wrote:

> But no, this one's clearly a kernel error.  If the kernel is giving write 
> errors against the device afterwards, than the kernel's internal state 
> toggled successfully, which is all the mount syscall was trying to do.  Mount 
> is just reporting whether or not the syscall succeeded, not whether or not it 
> should have. :)

OK, so there are actually two separate bugs, it seems: one that 
remounting a RO media in the RW mode succeeds (this "works" for any RO 
media, as far as I can tell) and the second (this one is specific to the 
floppy driver only) that a further write to such a falsely rw-remounted 
media doesn't return (in the user space) an error.

Regards,

Evgeny

Re: Weirdness of "mount -o remount,rw" with write-protected floppy

[Rob Landley]

On Friday 28 October 2005 06:55, Evgeny Stambulchik wrote:
> Rob Landley wrote:
> > But no, this one's clearly a kernel error.  If the kernel is giving write
> > errors against the device afterwards, than the kernel's internal state
> > toggled successfully, which is all the mount syscall was trying to do. 
> > Mount is just reporting whether or not the syscall succeeded, not whether
> > or not it should have. :)
>
> OK, so there are actually two separate bugs, it seems: one that
> remounting a RO media in the RW mode succeeds (this "works" for any RO
> media, as far as I can tell) and the second (this one is specific to the
> floppy driver only) that a further write to such a falsely rw-remounted
> media doesn't return (in the user space) an error.

It looks like one bug to me.  The initial mount figures out that it's read 
only, and the actual writes fail correctly, but remount isn't checking for 
read only (and thus isn't failing).

Rob

Re: Weirdness of "mount -o remount,rw" with write-protected floppy

[Evgeny Stambulchik]

Rob Landley wrote:

> It looks like one bug to me.  The initial mount figures out that it's read 
> only, and the actual writes fail correctly, but remount isn't checking for 
> read only (and thus isn't failing).

Right, but even after remount seemingly succeeds, an attempt to write to 
  an unwritable media should return an error nevertheless, as the 
corresponding syscall should fail, obviously. And it indeed happens for 
e.g. CDROM or an NFS volume (if you repeat all the steps from my 
original post, "touch" will return an error). Yet for floppy, it 
doesn't. I suspect that a "readonly-ness" is defined at a different 
level for floppy (e.g. status of the device itself, not media). This is 
just a wild guess.

Regards,

Evgeny

Re: Weirdness of "mount -o remount,rw" with write-protected floppy

[Rob Landley]

On Friday 28 October 2005 08:15, Evgeny Stambulchik wrote:
> Rob Landley wrote:
> > It looks like one bug to me.  The initial mount figures out that it's
> > read only, and the actual writes fail correctly, but remount isn't
> > checking for read only (and thus isn't failing).
>
> Right, but even after remount seemingly succeeds, an attempt to write to
>   an unwritable media should return an error nevertheless, as the
> corresponding syscall should fail, obviously.

You're forgetting the cacheing (dentry and page caches).

We have a writeable filesystem mounted on a read-only block device.  This is 
an impossible situation we should never have gotten into in the first place.  
That's the bug.

For performance reasons, the write stuffs the data into the page cache, and 
returns long before the system even attempts to write the data to disk.  
(Unless you mount the filesystem O_SYNC, which will kill performance.)

So the write happily succeeds, and by the time the later attempt to flush data 
to the underlying block device is made (by memory pressure or pdflush) 
there's nobody to report it to anymore.  So it logs it.

Incidentally, this is why checking the return value of close() is silly.  If 
you want to fsync the data, call fsync (which blocks until we've hit the disk 
and can thus report whether or not it actually made it).  close() is just as 
cached as anything else, it updates an in-memory dentry that may nor may not 
successfully be flushed to disk later on, depending on whether or not the 
disk got hotplugged away out from under us before then...

Rob

Re: Weirdness of "mount -o remount,rw" with write-protected floppy

[Evgeny Stambulchik]

Rob Landley wrote:

> You're forgetting the cacheing (dentry and page caches).
> 
> We have a writeable filesystem mounted on a read-only block device.  This is 
> an impossible situation we should never have gotten into in the first place.  
> That's the bug.
> 
> For performance reasons, the write stuffs the data into the page cache, and 
> returns long before the system even attempts to write the data to disk.  
> (Unless you mount the filesystem O_SYNC, which will kill performance.)

You're right, when I mount the floppy with "-o sync", touch fails 
immediately (I did try earlier sync(1), as somebody suggested, and it 
didn't matter; yes, I know about the difference between sync(2) and 
fsync(2)). On the other hand, umount is supposed to flush all the data 
by the time it returns yet still it succeeded.

But overall I agree that we're discussing a situation which should never 
happen in the first place, i.e. remount should fail.

Regards,

Evgeny

Re: Weirdness of "mount -o remount,rw" with write-protected floppy

[Rob Landley]

On Friday 28 October 2005 09:52, Evgeny Stambulchik wrote:
> You're right, when I mount the floppy with "-o sync", touch fails
> immediately (I did try earlier sync(1), as somebody suggested, and it
> didn't matter; yes, I know about the difference between sync(2) and
> fsync(2)). On the other hand, umount is supposed to flush all the data
> by the time it returns yet still it succeeded.

Is that guaranteed?  Or do you need to pass some weird flag to umount?  (I 
know there's lazy unmounts, for example.  I don't know what the guarantees 
are for standard unmounts...)

Rob

Re: Weirdness of "mount -o remount,rw" with write-protected floppy

[Evgeny Stambulchik]

Rob Landley wrote:

> On the other hand, umount is supposed to flush all the data
>> by the time it returns yet still it succeeded.
> 
> Is that guaranteed?  Or do you need to pass some weird flag to umount?

I believe this is the default behavior. How otherwise do you know when 
it's safe to eject/disconnect a removable media (floppy, USB 
disk-on-key,...)?

Regards,

Evgeny

Re: Weirdness of "mount -o remount,rw" with write-protected floppy

[Jon Masters]

On 10/27/05, Evgeny Stambulchik <Evgeny.Stambulchik@weizmann.ac.il> wrote:

> # mount /dev/fd0 /mnt/floppy/
> mount: block device /dev/fd0 is write-protected, mounting read-only
> # mount -o remount,rw /mnt/floppy
> # echo $?
> 0

Ok. The problem is in the remounting. Both cases rely on the mount
syscall doing the work and the "fault" is that it is returning
successfully in both cases.

When remounting, Linux /does/ check if the corresponding block device
is read-only and won't remount rw onto that (so if the permissions of
the bdev corresponded to the real state of the floppy then all would
be good) but it will if the block dev is writeable but the device is
not. There isn't a generic VFS way to ask if a backing device is
writeable (or do_remount_sb would be using it) - or is there?

The /only/ way I can see to "fix" this is to do a pointless open on
the block device and see if that returns EROFS before allowing a
remount. But I don't know what other hassle that will cause - I'll
make the hack, but someone (Al?) who knows the code will need to
comment because this might completely fuck up a lock somewhere.

Jon.

Re: Weirdness of "mount -o remount,rw" with write-protected floppy

[Jon Masters]

On 10/29/05, Jon Masters <jonmasters@gmail.com> wrote:

> The /only/ way I can see to "fix" this is to do a pointless open on
> the block device and see if that returns EROFS before allowing a
> remount. But I don't know what other hassle that will cause - I'll
> make the hack, but someone (Al?) who knows the code will need to
> comment because this might completely fuck up a lock somewhere.

Or change the policy for the underlying gendisk in floppy.c according
to what we find when we do an floppy_open on the device. Which is what
I'm looking at as a workaround.

Jon.