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
On 10/27/05, Evgeny Stambulchik <[email protected]> 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.
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
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
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
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
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
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
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
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
On 10/27/05, Jon Masters <[email protected]> wrote:
> On 10/27/05, Evgeny Stambulchik <[email protected]> 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.
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.
On 10/27/05, Evgeny Stambulchik <[email protected]> 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.
On 10/29/05, Jon Masters <[email protected]> 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.