From patchwork Mon Apr 30 10:31:28 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Helmut Grohne X-Patchwork-Id: 906633 X-Patchwork-Delegate: dwmw2@infradead.org Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.infradead.org (client-ip=2607:7c80:54:e::133; helo=bombadil.infradead.org; envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=intenta.de Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="RQkxGcIG"; dkim-atps=neutral Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 40ZLSq6nZ4z9s06 for ; Mon, 30 Apr 2018 20:32:11 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=hKei1V+pUBJnrLeOeFym0AfAeSIP7P7LRuLfI7gQakw=; b=RQkxGcIG4tmaAz 2oc5UD2xRDHN36vpLuBSdW/lGzykV/T/UBFEZKR8/gROEHLKWUkbMyv1WvZdAZMm/zy8sjpQ0+bt5 qidcqmbkIR7+GrV6NVUXP5fBDJs9UOEYWMJes5rNe1KVqTDZeEH/pPkzYiPPUp6N12OxpYYNJHIdY Zmkp8kFdZZ/HtHGkXnhxOxHe2CC4Goq8x3sEnLqdApi2roFjGr1DS2mq7gcgxcBzwRzBhCtpRC0tk EGVS/G6Bdv+qniRHgcfz/dWY4b6olopNi5wxw+Fn7NAtugDBP5tyO4R7dXZE4yOtXgskpfwsLHezR h/CChhG843NNhrTgL3ww==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1fD66D-0000Dy-TW; Mon, 30 Apr 2018 10:32:01 +0000 Received: from mail.intenta.de ([178.249.25.132]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fD65z-0008WN-2N for linux-mtd@lists.infradead.org; Mon, 30 Apr 2018 10:31:59 +0000 Received: from [10.10.16.42] (port=23468 helo=ICSMA001.intenta.de) by mail.intenta.de with esmtps (TLSv1.2:AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1fD65g-000258-1p; Mon, 30 Apr 2018 12:31:28 +0200 Received: from localhost (10.10.136.106) by ICSMA001.intenta.de (10.10.16.42) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 30 Apr 2018 12:31:28 +0200 X-CTCH-RefID: str=0001.0A0C0207.5AE6F080.0181, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Date: Mon, 30 Apr 2018 12:31:28 +0200 From: Helmut Grohne To: David Woodhouse , Subject: [PATCH v2] jffs2: put directories f->sem on a separate lockdep class Message-ID: <20180430103126.w44pr4u3pyjbatbp@laureti-dev> References: <1524833695.18504.36.camel@infradead.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1524833695.18504.36.camel@infradead.org> User-Agent: NeoMutt/20170113 (1.7.2) X-Originating-IP: [10.10.136.106] X-ClientProxiedBy: ICSMA001.intenta.de (10.10.16.42) To ICSMA001.intenta.de (10.10.16.42) X-EsetResult: clean, is OK X-EsetId: 47C16134FCD3353717853D X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180430_033147_308569_533F7104 X-CRM114-Status: GOOD ( 14.09 ) X-Spam-Score: -0.0 (/) X-Spam-Report: SpamAssassin version 3.4.1 on bombadil.infradead.org summary: Content analysis details: (-0.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [178.249.25.132 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Zijlstra Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org We get a lockdep warning if we read a directory (e.g. ls) and fault a page on a regular file: [ 181.206207] mmaptest/392 is trying to acquire lock: [ 181.211066] (&f->sem){+.+.}, at: [] jffs2_readpage+0x30/0x5c [ 181.217663] [ 181.217663] but task is already holding lock: [ 181.223477] (&mm->mmap_sem){++++}, at: [] do_page_fault+0xa8/0x454 [ 181.230596] [ 181.230596] which lock already depends on the new lock. [ 181.230596] [ 181.238755] [ 181.238755] the existing dependency chain (in reverse order) is: [ 181.246219] [ 181.246219] -> #1 (&mm->mmap_sem){++++}: [ 181.251614] __might_fault+0x90/0xc0 [ 181.255694] filldir+0xa4/0x1f4 [ 181.259334] jffs2_readdir+0xd8/0x1d4 [ 181.263499] iterate_dir+0x78/0x128 [ 181.267490] SyS_getdents+0x8c/0x12c [ 181.271576] ret_fast_syscall+0x0/0x28 [ 181.275818] [ 181.275818] -> #0 (&f->sem){+.+.}: [ 181.280690] lock_acquire+0xfc/0x2b0 [ 181.284763] __mutex_lock+0x8c/0xb0c [ 181.288842] mutex_lock_nested+0x2c/0x34 [ 181.293272] jffs2_readpage+0x30/0x5c [ 181.297438] filemap_fault+0x600/0x73c [ 181.301690] __do_fault+0x28/0xb8 [ 181.305510] handle_mm_fault+0x854/0xec0 [ 181.309937] do_page_fault+0x384/0x454 [ 181.314188] do_DataAbort+0x4c/0xc8 [ 181.318181] __dabt_usr+0x44/0x60 [ 181.321999] 0xb6dffb02 Like with inode->i_rwsem, we recognize that this can never result in a dead lock, because we cannot page fault directory inodes and we cannot call getdents on non-directories. Thus we need different lockdep classes depending on the mode. This mirrors what lockdep_annotate_inode_mutex_key does to inodes. Link: https://www.spinics.net/lists/linux-rt-users/msg07644.html Signed-off-by: Helmut Grohne Cc: Peter Zijlstra --- I have reworked only this last patch of the series to avoid sending three extra mails. If you prefer the full series, I can resend it. Changing lock classes after using a lock is not a common thing to do, yet this patch does exactly that. Thus I opted for performing two extra tests to gain more confidence in the correctness of this approach: * I tried adding a BUG_ON(!mutex_is_locked(&f->sem)) to before the lock class change to validate that the mutex on the I_NEW inode cannot be held. This call did not error out in my tests. * I tried adding a mutex_clear(&f->sem) to jffs2_do_clear_inode and reinitialized it before setting the mutex class to validate that it really isn't used in the relevant time frame. This did not cause lockdep to complain in my tests. Changes in v2: - Initialize the lock class on every inode initialization rather than just the initial one in jffs2_i_init_once. (Thanks to David Woodhouse for pointing at this issue.) - Properly wrap the commit message to make checkpatch.pl fully happy. --- fs/jffs2/fs.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c index 89a10b398d00..9bc3cd204732 100644 --- a/fs/jffs2/fs.c +++ b/fs/jffs2/fs.c @@ -26,6 +26,9 @@ #include #include "nodelist.h" +static struct lock_class_key jffs2_inode_info_sem_key, + jffs2_inode_info_sem_dir_key; + static int jffs2_flash_setup(struct jffs2_sb_info *c); int jffs2_do_setattr (struct inode *inode, struct iattr *iattr) @@ -277,6 +280,11 @@ struct inode *jffs2_iget(struct super_block *sb, unsigned long ino) inode->i_mode = jemode_to_cpu(latest_node.mode); + /* Mirror lock class of inode->i_rwsem, see + * lockdep_annotate_inode_mutex_key. + */ + lockdep_set_class(&f->sem, S_ISDIR(inode->i_mode) ? + &jffs2_inode_info_sem_dir_key : &jffs2_inode_info_sem_key); mutex_lock(&f->sem); i_uid_write(inode, je16_to_cpu(latest_node.uid)); @@ -439,6 +447,11 @@ struct inode *jffs2_new_inode (struct inode *dir_i, umode_t mode, struct jffs2_r f = JFFS2_INODE_INFO(inode); jffs2_init_inode_info(f); + /* Mirror lock class of inode->i_rwsem, see + * lockdep_annotate_inode_mutex_key. + */ + lockdep_set_class(&f->sem, S_ISDIR(inode->i_mode) ? + &jffs2_inode_info_sem_dir_key : &jffs2_inode_info_sem_key); mutex_lock(&f->sem); memset(ri, 0, sizeof(*ri));