From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oleg Nesterov Subject: [PATCH v3 3/8] document rwsem_release() in sb_wait_write() Date: Fri, 14 Aug 2015 19:19:54 +0200 Message-ID: <20150814171954.GA15066@redhat.com> References: <20150814171935.GA15042@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dave Chinner , Dave Hansen , Jan Kara , "Paul E. McKenney" , Peter Zijlstra , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Al Viro Return-path: Content-Disposition: inline In-Reply-To: <20150814171935.GA15042@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Not only we need to avoid the warning from lockdep_sys_exit(), the caller of freeze_super() can never release this lock. Another thread can do this, so there is another reason for rwsem_release(). Plus the comment should explain why we have to fool lockdep. Signed-off-by: Oleg Nesterov Reviewed-by: Jan Kara --- fs/super.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/fs/super.c b/fs/super.c index d0fdd49..89b58fb 100644 --- a/fs/super.c +++ b/fs/super.c @@ -1236,11 +1236,17 @@ static void sb_wait_write(struct super_block *sb, int level) { s64 writers; + rwsem_acquire(&sb->s_writers.lock_map[level-1], 0, 0, _THIS_IP_); /* - * We just cycle-through lockdep here so that it does not complain - * about returning with lock to userspace + * We are going to return to userspace and forget about this lock, the + * ownership goes to the caller of thaw_super() which does unlock. + * + * FIXME: we should do this before return from freeze_super() after we + * called sync_filesystem(sb) and s_op->freeze_fs(sb), and thaw_super() + * should re-acquire these locks before s_op->unfreeze_fs(sb). However + * this leads to lockdep false-positives, so currently we do the early + * release right after acquire. */ - rwsem_acquire(&sb->s_writers.lock_map[level-1], 0, 0, _THIS_IP_); rwsem_release(&sb->s_writers.lock_map[level-1], 1, _THIS_IP_); do { -- 1.5.5.1