[CRIU] [RFC PATCH 3/6] introduce mnt_entry->fsname for FSTYPE__AUTO filesystems

[Oleg Nesterov]

On 03/31, Pavel Emelyanov wrote:
>
> On 03/31/2015 03:56 PM, Oleg Nesterov wrote:
>
> > No. Well yes, de-duplication is good too, but this is minor.
> >
> > The main problem is that (I think) we need (or at least want) to re-create the
> > FSTYPE__AUTO entries asap, before collect_mnt_from_image().
>
> Why?! And how, at restore time all entries are read from image, how can we
> recreate anything before we read them?
>
> > See above, parse_mountinfo() is called before this stage. Again, iiuc currently
> > this doesn't matter correctness wise, but this looks unsafe. At least inconsistent.
> > It would be better to ensure that "restore" never sees (say) hugetlbfs as
> > FSTYPE__UNSUPPORTED if it was dumped as FSTYPE__AUTO. Even if (iiuc) collect_mntinfo()
> > is called to umount everything and thus FSTYPE__UNSUPPORTED is fine.
>
> But if the entry in the image _is_ auto, how can restore see it as unsupported?

Sorry for confusion. I didn't mean collect_mnt_from_image(), of course it
will see FSTYPE__AUTO with the patches I sent.

But note that prepare_mnt_ns() calls collect_mntinfo() to umount everything
before we start to restore the mnt namespace.

And collect_mntinfo() paths can see the same fsnames as UNSUPPORTED. Again,
I do not really think this can make any harm, just this doesn't look good.

> > OK. If we can abuse inventory_entry, I'll try to do this. We will see if this
> > looks better or not. If not, we can return to mnt_entry->fsname.
>
> I didn't tell we could abuse inventory :) I told we could add new stuff to
> mnt entry. But since I still don't understand what the problem is, you can
> try to abuse inventory and see how it goes.

Yes, yes, this will be RFC anyway. I can always switch back to the new field
in mnt entry.

Oleg.