mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: Infinite Loop when automounting device mounted elsewhere
Date: Fri, 27 Nov 2020 09:48:17 +0100	[thread overview]
Message-ID: <20201127084817.GD11843@pengutronix.de> (raw)
In-Reply-To: <6c3e8d1f-025c-73c6-3834-280f0a7e5633@pengutronix.de>

On Wed, Nov 25, 2020 at 10:33:45AM +0100, Ahmad Fatoum wrote:
> Hello,
> 
> I just ran into this issue:
> 
>   $ mkdir /boot
>   $ mount /dev/mmc2.0 /boot
>   $ ls /mnt/mmc2.0/
>   mounted /dev/mmc2.0 on /boot
>   mounted /dev/mmc2.0 on /boot
>   mounted /dev/mmc2.0 on /boot
>   [ Ad infinitum ]
> 
> This is more readily reproducible with barebox platforms where a separate
> boot partition is default-mounted as /boot. In that case, accessing the
> partition's corresponding /mnt entry will hang.
> 
> The hang can be traced back to fs/fs.c:follow_managed():
> 
>   while (managed = path->dentry->d_flags,
>   	managed &= DCACHE_MANAGED_DENTRY,
>   	managed != 0) {
> 	if (managed & DCACHE_MOUNTED) {
>   		struct vfsmount *mounted = lookup_mnt(path);
>   
>   		if (mounted) {
>   			dput(path->dentry);
>   			if (need_mntput)
>   				mntput(path->mnt);
>   			path->mnt = mounted;
>   			path->dentry = dget(mounted->mnt_root);
>   			need_mntput = true;
>   			continue;
>   		}
>   	}
>   
>   	/* Handle an automount point */
>   	if (managed & DCACHE_NEED_AUTOMOUNT) {
>   		ret = follow_automount(path, nd, &need_mntput);
>   		if (ret < 0)
>   			break;
>   		continue;
>   	}
>   
> 	/* We didn't change the current path point */
>   	break;
>   }
> 
> 
> The code attempts the follow_automount, which would succeed here,
> but it doesn't actually mount the current mount point, so we never
> enter the first if clause that would change path->dentry and lead
> us out of the loop.
> 
> I am unsure at what layer this should be fixed. Any suggestions?

This goes down to the command "mount mmc2.0" being executed. The mount
command then does a cdev_mount_default() which does this:

	/*
	 * If this cdev is already mounted somewhere use this path
	 * instead of mounting it again to avoid corruption on the
	 * filesystem. Note this ignores eventual fsoptions though.
	 */
	path = cdev_get_mount_path(cdev);
	if (path)
		return path;

The mount command is happy then and returns successfully. I think the
mount command should return an error when the cdev is mounted already
but the path it's mounted to is not the default path for that cdev.

Another option would be to implement bind mounts and do a bind mount
to the default path.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

      reply	other threads:[~2020-11-27  8:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-25  9:33 Ahmad Fatoum
2020-11-27  8:48 ` Sascha Hauer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201127084817.GD11843@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox