>
> 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");
New >>> optptr = 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