1. 22 Apr, 2015 5 commits
  2. 21 Apr, 2015 10 commits
  3. 16 Apr, 2015 4 commits
  4. 14 Apr, 2015 15 commits
  5. 10 Apr, 2015 6 commits
    • Oleg Nesterov's avatar
      make resolve_source() more friendly to FSTYPE__AUTO mounts · 323726b7
      Oleg Nesterov authored
      resolve_source() insists on kdev_major() == 0, and this makes sense.
      However, at least FSTYPE__AUTO can try to use mi->source as a block
      device and pray it will work.
      
      [ Also bout this change from Oleg:
      
      Let me send another (last) functional change before the promised
      cleanups we discussed.
      
      To remind, without this patch I still can't dump/restore /home and
      /boot on my testing machine. --enable-fs xfs "works" in a sense that
      "dump" succeeds. But "restore" fails.
      
      However. Lets forget this for the moment. To me resolve_source() looks
      just wrong. Sure, I agree, it is not safe to blindly use mi->source if
      kdev_major() != 0. But this means that we should not have dumped this
      mountpoint, simply because we can't restore it.
      
      Yes, currently this works because fstypes[] contains only the diskless
      filesystems, but still.
      
      So this probably needs more cleanups too, and this patch doesn't make
      this logic look better.
      
      To me, we should do something like
      
      	static char *resolve_source(struct mount_info *mi)
      	{
      		if (kdev_major(mi->s_dev) == 0)
      			/*
      			 * Anonymous block device. Kernel creates them for
      			 * diskless mounts.
      			 */
      			return mi->source;
      
      		if (mi->fstype->code != FSTYPE__AUTO) {
      			pr_err("OOPS! something is wrong!!!\n");
      			return NULL;
      		}
      
      		// OK, this is FSTYPE__AUTO, it should "just work"
      		// by definition. Or the user should blame himself.
      
      		struct stat st;
      
      		if (stat(mi->source, &st) || !S_ISBLK(st.st_mode) ||
      		    major(st.st_rdev) != kdev_major(mi->s_dev) ||
      		    minor(st.st_rdev) != kdev_minor(mi->s_dev))
      			pr_warn("Hmm, can't verify blkdev. Lets see if mount will work...\n");
      
      		return mi->source;
      	}
      
      But this patch only does a minimal change to make FSTYPE__AUTO work
      with blkdev.
      
      ]
      Signed-off-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      323726b7
    • Pavel Emelyanov's avatar
      test: Add test for ext-mount-map option · 2085e078
      Pavel Emelyanov authored
      It mostly reuses the infrastructure for plugin testing.
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      2085e078
    • Pavel Emelyanov's avatar
      test: Rework the ext mount plugin test · ec5b0d84
      Pavel Emelyanov authored
      The existing set of shell scripts do hard-to-debug things and mess
      with the root filesystem. We can make it better.
      
      First, not to play with the system / the process that will be run in
      a new mount namespace is statically compiled .c file. And this "init"
      does a very simple thing -- waits for SIGTERM and check that the
      given filepath contains the given string.
      
      Second, the namespace's root will be some subdir, instead of system
      / bind-mount-ed into a subdir. This makes it easier to keep things
      together and makes 100% sure the external bind mount cannot be
      accessed by custom path.
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      ec5b0d84
    • Tycho Andersen's avatar
      b508ebcb
    • Tycho Andersen's avatar
    • Tycho Andersen's avatar
      mnt: add --enable-external-masters option · fcae4f39
      Tycho Andersen authored
      This option enables external (slave) bind mounts to be resolved.
      
      v2: don't always assume that when the master id matches, the mounts match
      Signed-off-by: 's avatarTycho Andersen <tycho.andersen@canonical.com>
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      fcae4f39