On Tue 11-08-15 19:04:04, Oleg Nesterov wrote:
> 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 <o...@redhat.com>
Looks good. You can add:
Reviewed-by: Jan Kara <j...@suse.com>
Honza
> ---
> 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
>
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
