Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d262e97cea0b9c32065ee8e02354a0aa0134c8ab.camel@linux.ibm.com>
Subject: Re: [syzbot] possible deadlock in mnt_want_write (2)
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     Hillf Danton <hdanton@sina.com>
Cc:     syzbot <syzbot+b42fe626038981fb7bfa@syzkalhler.appspotmail.com>,
        linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
        linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org,
        miklos@szeredi.hu, syzkaller-bugs@googlegroups.com,
        syzbot <syzbot+b42fe626038981fb7bfa@syzkaller.appspotmail.com>,
        Amir Goldstein <amir73il@gmail.com>
Date:   Wed, 06 Jul 2022 18:24:30 -0400
In-Reply-To: <20220706121038.2045-1-hdanton@sina.com>
References: <000000000000466f0d05e2d5d1d1@google.com>
         <20220706121038.2045-1-hdanton@sina.com>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Precedence: bulk

Hi Hillf,g

On Wed, 2022-07-06 at 20:10 +0800, Hillf Danton wrote:
> On Tue, 05 Jul 2022 08:53:15 -0400 Mimi Zohar wrote:
> > 
> > Thank you for the reproducer.  This seems to be a similar false
> > positive as was discussed:
> > https://lore.kernel.org/linux-unionfs/000000000000c5b77105b4c3546e@google.com/
> > 
> > thanks,
> > 
> 
> Hi Mimi
> 
> Please pick up the patch attached if it makes sense to you.

The patch itself looks good, but missing from the patch description is
an indication that the lockdep warning is a false positive.  Perhaps
add a "Suggested-by" line crediting Amir.   I'd appreciate your posting
the patch on the mailing list.

thanks!

Mimi

> From: Hillf Danton <hdanton@sina.com>
> Subject: [PATCH] integrity: lockdep annotate of iint->mutex
> 
> This fixes a reported lockdep splat
> 
>         CPU0                    CPU1
>         ----                    ----
> 	lock(&iint->mutex);
> 				lock(sb_writers#4);
> 				lock(&iint->mutex);
> 	lock(sb_writers#4);
>  
> 	*** DEADLOCK ***
> 
> using the method in 4eae06de482b annotating OVL_I(inode)->lock.
> 
> Links: https://lore.kernel.org/linux-unionfs/CAOQ4uxjk4XYuwz5HCmN-Ge=Ld=tM1f7ZxVrd5U1AC2Wisc9MTA@mail.gmail.com/
> Reported-and-tested-by: syzbot <syzbot+b42fe626038981fb7bfa@syzkaller.appspotmail.com>
> Cc: Mimi Zohar <zohar@linux.ibm.com>
> Cc: Amir Goldstein <amir73il@gmail.com>
> Signed-off-by: Hillf Danton <hdanton@sina.com>
> ---
> 
> --- a/security/integrity/iint.c 
> +++ b/security/integrity/iint.c 
> @@ -85,6 +85,17 @@ static void iint_free(struct integrity_i
>  	kmem_cache_free(iint_cache, iint);
>  }
>  
> +static void iint_annotate_mutex_key(struct integrity_iint_cache *iint, struct inode *inode)
> +{
> +#ifdef CONFIG_LOCKDEP
> +	static struct lock_class_key iint_mutex_key[FILESYSTEM_MAX_STACK_DEPTH];
> +
> +	int depth = inode->i_sb->s_stack_depth;
> +
> +	lockdep_set_class(&iint->mutex, &iint_mutex_key[depth]);
> +#endif
> +}
> +
>  /**
>   * integrity_inode_get - find or allocate an iint associated with an inode
>   * @inode: pointer to the inode
> @@ -114,6 +125,8 @@ struct integrity_iint_cache *integrity_i
>  	if (!iint)
>  		return NULL;
>  
> +	iint_annotate_mutex_key(iint, inode);
> +
>  	write_lock(&integrity_iint_lock);
>  
>  	p = &integrity_iint_tree.rb_node;
> --