From patchwork Mon Aug 10 15:20:31 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 266603 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 12675C433E0 for ; Mon, 10 Aug 2020 15:42:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E445620774 for ; Mon, 10 Aug 2020 15:42:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597074130; bh=x7ozp1mq3C1BY63eMKEcpS3peJBmk+UfyCtDfXhOuww=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=tr4EdoCaPeaH3nOnnl+uC+wTup77I28F5LJ2ei4rAM7Zz+LO6vk8/WxkeyxSML0m/ Rwal5bcz5VMtUm/wsUCqQkkro2/YmvvvtEJk30c+1i3EP1BAMi5xc+JDzEALP8WBUW ZcybwVsVwBMRGHZbs++RVoxd9nXGsMhL88lW53FM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726046AbgHJPW0 (ORCPT ); Mon, 10 Aug 2020 11:22:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:53192 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727801AbgHJPWX (ORCPT ); Mon, 10 Aug 2020 11:22:23 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 15B0F20656; Mon, 10 Aug 2020 15:22:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597072942; bh=x7ozp1mq3C1BY63eMKEcpS3peJBmk+UfyCtDfXhOuww=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0iQivmxDb+dqWeRz1jchQx76StioTKemusTc1nY2KfF5C2txFPsI+ZSqI1NVT5bNq 6VXzMgwa/7GqDd9hC6hB0mvusJgcKB1Omapa/ZGoi/VwlaQVGp2Kw6a2dRKINly1yJ BDy5gqVc9jkBsiHGK3wLBkO5JdFWC6oJijLVni9g= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+7a0d9d0b26efefe61780@syzkaller.appspotmail.com, Suren Baghdasaryan , "Joel Fernandes (Google)" Subject: [PATCH 5.7 12/79] staging: android: ashmem: Fix lockdep warning for write operation Date: Mon, 10 Aug 2020 17:20:31 +0200 Message-Id: <20200810151812.729806559@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200810151812.114485777@linuxfoundation.org> References: <20200810151812.114485777@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Suren Baghdasaryan commit 3e338d3c95c735dc3265a86016bb4c022ec7cadc upstream. syzbot report [1] describes a deadlock when write operation against an ashmem fd executed at the time when ashmem is shrinking its cache results in the following lock sequence: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&sb->s_type->i_mutex_key#13); lock(fs_reclaim); lock(&sb->s_type->i_mutex_key#13); kswapd takes fs_reclaim and then inode_lock while generic_perform_write takes inode_lock and then fs_reclaim. However ashmem does not support writing into backing shmem with a write syscall. The only way to change its content is to mmap it and operate on mapped memory. Therefore the race that lockdep is warning about is not valid. Resolve this by introducing a separate lockdep class for the backing shmem inodes. [1]: https://lkml.kernel.org/lkml/0000000000000b5f9d059aa2037f@google.com/ Reported-by: syzbot+7a0d9d0b26efefe61780@syzkaller.appspotmail.com Signed-off-by: Suren Baghdasaryan Cc: stable Reviewed-by: Joel Fernandes (Google) Link: https://lore.kernel.org/r/20200730192632.3088194-1-surenb@google.com Signed-off-by: Greg Kroah-Hartman --- drivers/staging/android/ashmem.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/drivers/staging/android/ashmem.c +++ b/drivers/staging/android/ashmem.c @@ -95,6 +95,15 @@ static DEFINE_MUTEX(ashmem_mutex); static struct kmem_cache *ashmem_area_cachep __read_mostly; static struct kmem_cache *ashmem_range_cachep __read_mostly; +/* + * A separate lockdep class for the backing shmem inodes to resolve the lockdep + * warning about the race between kswapd taking fs_reclaim before inode_lock + * and write syscall taking inode_lock and then fs_reclaim. + * Note that such race is impossible because ashmem does not support write + * syscalls operating on the backing shmem. + */ +static struct lock_class_key backing_shmem_inode_class; + static inline unsigned long range_size(struct ashmem_range *range) { return range->pgend - range->pgstart + 1; @@ -396,6 +405,7 @@ static int ashmem_mmap(struct file *file if (!asma->file) { char *name = ASHMEM_NAME_DEF; struct file *vmfile; + struct inode *inode; if (asma->name[ASHMEM_NAME_PREFIX_LEN] != '\0') name = asma->name; @@ -407,6 +417,8 @@ static int ashmem_mmap(struct file *file goto out; } vmfile->f_mode |= FMODE_LSEEK; + inode = file_inode(vmfile); + lockdep_set_class(&inode->i_rwsem, &backing_shmem_inode_class); asma->file = vmfile; /* * override mmap operation of the vmfile so that it can't be