> 
> 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

Reply via email to