Unless I am totally blind the fix is pass sbi-s_data as third
parameter
to do_remount_sb in subfs_remount. Currently it is
retval = do_remount_sb (subsb, real_flags, NULL);
change it into
retval = do_remount_sb (subsb, real_flags, sbi-s_data);
Well, after my poor system was busy all day long to recompile kernel, I
found the problem. It was not the above line (also it probably does not
harm as well) but the following in
fs/isofs/inode.c: parse_options()
...
if ((value = strchr(this_char,'=')) != NULL)
*value++ = 0;
...
i.e. what happens is
- we store fs-specific arguments in sbi-s_data
- then we pass it to subfs
- it (in our case, isofs) puts 0 in the middle that trashes value for
the next time
- next time the option does not work anymore:
[super.c:subfs_mount:199] type=iso9660, dev=/dev/hdc, data=iocharset
^^^
oops!
This smells as memory leak in any case. This may be discussed on lkml
probably. But quick fix for supermount is to copy options immediately
before passing them to do_kern_mount. I.e. something like
super_operations.c:parse_options.c:
if (*this_char == ',') {
/* An empty option, or the option --,
introduces options to be passed through to
the subfs */
supermount_debug (assigning remainder);
Newoptptr = allocate_strlen(this_char);
return copy_option (sbi-s_data, ++this_char);
in super.c:subfs_mount():
copy(sbi-s_data, optptr) = for every do_kern_mount
mnt = do_kern_mount (sbi-s_type,
sb-s_flags | MS_MGC_VAL,
sbi-s_devname, optptr);
and may be the same do_remount_sb in subfs_remount. Unfortunately, I am
not familiar with kernel memory allocation to quickly do it :(
-andrej
