From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [BUG] Rewriting backing_dev_info in MTD Date: Thu, 15 Apr 2010 19:23:00 +0200 Message-ID: <20100415172300.GF3561@quack.suse.cz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexander Viro , David Woodhouse , linux-fsdevel@vger.kernel.org, linux-mtd@lists.infradead.org, David Howells , Bernd Schmidt , Alexander Shishkin To: "Kirill A. Shutemov" Return-path: Received: from cantor2.suse.de ([195.135.220.15]:39007 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755309Ab0DORW4 (ORCPT ); Thu, 15 Apr 2010 13:22:56 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue 13-04-10 14:33:01, Kirill A. Shutemov wrote: > I've got NULL-pointer dereference in __mark_inode_dirty() on chmod() > for MTD device node. wb->bdi was NULL in this case. > > During investigation I've found that MTD subsystem rewrites > file->f_mapping->backing_dev_info on openning to get mmap() work on > MMU-less systems. But in fact it rewrites > inode->i_mapping->backing_dev_info too, since inode->i_mapping == > file->f_mapping (see __dentry_open() in fs/open.c). It breaks > writeback of inode changes. I think the right trick is to not overwrite file->f_mapping->backing_dev_info but rather change already file->f_mapping. For example drivers/char/raw.c does this. Then you'll stop having problems with writeback code going wild. > I guess the right way to fix this is changing of __dentry_open() to > create _copy_ of i_mapping to assign to f_mapping since in common case > f_mapping != i_mapping. But I'm not sure were the copy should be > freed. No, in most cases we will leave f_mapping == i_mapping so copying i_mapping would be an overkill. Honza -- Jan Kara SUSE Labs, CR