obscure read-only file system remount bug with 2.4 kernel

["Michael J. Accetta" <mja@laurelnetworks.com>]

With a 2.4.17 (MontaVista 2.1) kernel using ext3, we began seeing errors
of

EXT3-fs error (device ide1(22,1)) in start_transaction: Readonly filesystem
EXT3-fs error (device ide1(22,1)) in ext3_delete_inode: Readonly filesystem

after a change to a custom system install/reinstall procedure we've
written in house.

I believe I have traced the cause to a kernel bug with the
fs_may_remount_ro() call in fs/file_table.c which is used to verify
that a file system may be remounted RO.  It checks the open file list
of the super block for any deleted files and any regular files open
for writing.  However, tty_open() in drivers/char/ttyio.c moves tty
files from this list onto a tty_files list maintained per tty_struct
immediately on open.  So any open terminal devices files on the device
which get deleted (/dev/console in our case which is being replaced
by the reinstall process) are not considered in the remount RO test
and the remount is permitted when our reinstall completes.  This then
eventually gives at least ext3 indigestion when it goes to release the
deleted file on a now RO file system which should not yet have been allowed
to be remounted RO.

I've put together a fix which seems to work.  It calls into tty_io.c
from fs_may_remount_ro() and has it iterate over the open tty files in
all processes, following the pattern of __do_SAK() there, and looking
for deleted files with the same device number as the remounting device,
but this approach seems rather heavyweight to me.  However, it does do
minimal violence to existing file and tty data structures.

Caveats about this approach or alternative fix suggestions would be
quite welcome if anyone has them.  The problem appears to still exist
in 2.4.20 and I'd also be happy to package this as a patch against an
official 2.4.20 kernel release if there is interest.

Mike