All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	Dmitry Vyukov <dvyukov@google.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH v2] acct: fix possible deadlock in acct_pin_kill
Date: Thu, 4 Apr 2019 20:05:07 +0100	[thread overview]
Message-ID: <20190404190506.GE2217@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20190404184944.GD2217@ZenIV.linux.org.uk>

On Thu, Apr 04, 2019 at 07:49:44PM +0100, Al Viro wrote:
> On Thu, Apr 04, 2019 at 07:44:48PM +0100, Al Viro wrote:
> 
> > Huh?  sb_writers is taken when we *open* the new file.  Then we replace
> > its ->path.mnt with a clone and transfer the write count from the original
> > to new one.  And close the old file while we are at it.
> > 
> > >From sb_writers POV mainline has
> > 	sb_start_write(new_sb)	// in open
> > 	sb_start_write(new_sb)	// mnt_want_write() on clone
> > 	last write to old_sb, then sb_end_write(old_sb) // acct_pin_kill()
> > 	sb_end_write(new_sb)	// mnt_drop_write(mnt)
> > and you flip the order of the last two lines.
> > 
> > Could you explain how exactly does your patch help whatever
> > problem overlayfs has?
> 
> Ow...  Sorry, -ENOCOFFEE...
> 
> Let me wake up properly and look at that thing again.

OK, so...  My first reaction had been complete BS.  However, the
same goes for your analysis - it's not an ordering problem at all.
What happens is that we are replacing file->path.mnt with a clone
and we want the write count contribution (file is opened for write)
to be transferred.  That's it.  We do *NOT* want any kind of
freeze protection for the duration of switchover.

IOW, the solution is to switch to __mnt_{want,drop}_write() for that
switchover; we don't want to mess with freeze protection at all.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/fs/internal.h b/fs/internal.h
index 6a8b71643af4..2e7362837a6e 100644
--- a/fs/internal.h
+++ b/fs/internal.h
@@ -89,9 +89,7 @@ extern int sb_prepare_remount_readonly(struct super_block *);
 
 extern void __init mnt_init(void);
 
-extern int __mnt_want_write(struct vfsmount *);
 extern int __mnt_want_write_file(struct file *);
-extern void __mnt_drop_write(struct vfsmount *);
 extern void __mnt_drop_write_file(struct file *);
 
 /*
diff --git a/include/linux/mount.h b/include/linux/mount.h
index 9197ddbf35fb..bf8cc4108b8f 100644
--- a/include/linux/mount.h
+++ b/include/linux/mount.h
@@ -87,6 +87,8 @@ extern bool mnt_may_suid(struct vfsmount *mnt);
 
 struct path;
 extern struct vfsmount *clone_private_mount(const struct path *path);
+extern int __mnt_want_write(struct vfsmount *);
+extern void __mnt_drop_write(struct vfsmount *);
 
 struct file_system_type;
 extern struct vfsmount *fc_mount(struct fs_context *fc);
diff --git a/kernel/acct.c b/kernel/acct.c
index addf7732fb56..81f9831a7859 100644
--- a/kernel/acct.c
+++ b/kernel/acct.c
@@ -227,7 +227,7 @@ static int acct_on(struct filename *pathname)
 		filp_close(file, NULL);
 		return PTR_ERR(internal);
 	}
-	err = mnt_want_write(internal);
+	err = __mnt_want_write(internal);
 	if (err) {
 		mntput(internal);
 		kfree(acct);
@@ -252,7 +252,7 @@ static int acct_on(struct filename *pathname)
 	old = xchg(&ns->bacct, &acct->pin);
 	mutex_unlock(&acct->lock);
 	pin_kill(old);
-	mnt_drop_write(mnt);
+	__mnt_drop_write(mnt);
 	mntput(mnt);
 	return 0;
 }

  reply	other threads:[~2019-04-04 19:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-04 10:52 [PATCH v2] acct: fix possible deadlock in acct_pin_kill Amir Goldstein
2019-04-04 18:44 ` Al Viro
2019-04-04 18:49   ` Al Viro
2019-04-04 19:05     ` Al Viro [this message]
2019-04-04 19:33       ` Amir Goldstein
2019-04-11 19:10         ` Amir Goldstein
2019-04-04 19:19 ` Al Viro

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=20190404190506.GE2217@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=amir73il@gmail.com \
    --cc=dvyukov@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=syzkaller-bugs@googlegroups.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.