From mboxrd@z Thu Jan 1 00:00:00 1970 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=-7.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 CD9B1C433E2 for ; Thu, 16 Jul 2020 03:30:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8D9FF2071B for ; Thu, 16 Jul 2020 03:30:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ftG/dT0u" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8D9FF2071B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 156C76B000D; Wed, 15 Jul 2020 23:30:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1082E6B0022; Wed, 15 Jul 2020 23:30:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01D4F6B0023; Wed, 15 Jul 2020 23:30:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0084.hostedemail.com [216.40.44.84]) by kanga.kvack.org (Postfix) with ESMTP id DD48B6B000D for ; Wed, 15 Jul 2020 23:30:51 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 65298824805A for ; Thu, 16 Jul 2020 03:30:51 +0000 (UTC) X-FDA: 77042512302.29.pull15_560cc7426eff Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id 3CC2F18086E42 for ; Thu, 16 Jul 2020 03:30:51 +0000 (UTC) X-HE-Tag: pull15_560cc7426eff X-Filterd-Recvd-Size: 3014 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Thu, 16 Jul 2020 03:30:50 +0000 (UTC) Received: from sol.localdomain (c-107-3-166-239.hsd1.ca.comcast.net [107.3.166.239]) (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 9433220663; Thu, 16 Jul 2020 03:30:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594870250; bh=ikmPWI8MAxfltvRswHekPbDid18TOw8D1FrTV++qoHM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ftG/dT0uCBDXZCXsbDz6ZLWmgFVO5Hfu9oCpJ2P2Hj7t/8PO1Ihi5lbTIw/yHzMhN Cx7YZn51zJpKNDe8bRLO52+Ejg07its1yEMp+il9Z4IInXDhsqoPlOQVrN1Slv3jfX u5zEiFR3ssQIcAWgDq8v4Kj4oD4wtwQMDxncESco= Date: Wed, 15 Jul 2020 20:30:48 -0700 From: Eric Biggers To: Suren Baghdasaryan Cc: gregkh@linuxfoundation.org, arve@android.com, tkjos@android.com, maco@android.com, joel@joelfernandes.org, christian@brauner.io, hridya@google.com, mhocko@kernel.org, hdanton@sina.com, devel@driverdev.osuosl.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH 1/1] staging: android: ashmem: Fix lockdep warning for write operation Message-ID: <20200716033048.GG1167@sol.localdomain> References: <20200716024527.4009170-1-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200716024527.4009170-1-surenb@google.com> X-Rspamd-Queue-Id: 3CC2F18086E42 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jul 15, 2020 at 07:45:27PM -0700, Suren Baghdasaryan wrote: > 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/ > > Signed-off-by: Suren Baghdasaryan Please add proper tags: Reported-by: syzbot+7a0d9d0b26efefe61780@syzkaller.appspotmail.com Fixes: ... Cc: stable@vger.kernel.org The Reported-by tag to use was given in the original syzbot report. - Eric