From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751584AbdCBM4F (ORCPT ); Thu, 2 Mar 2017 07:56:05 -0500 Received: from mx2.suse.de ([195.135.220.15]:42431 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750768AbdCBM4D (ORCPT ); Thu, 2 Mar 2017 07:56:03 -0500 Date: Thu, 2 Mar 2017 13:20:49 +0100 From: Jan Kara To: Al Viro Cc: Jan Kara , Dmitry Vyukov , "linux-fsdevel@vger.kernel.org" , LKML , Jens Axboe , Andrew Morton , Tejun Heo , Johannes Weiner , "linux-mm@kvack.org" , Andrey Ryabinin , syzkaller Subject: Re: mm: GPF in bdi_put Message-ID: <20170302122049.GA23354@quack2.suse.cz> References: <20170227182755.GR29622@ZenIV.linux.org.uk> <20170301142909.GG20512@quack2.suse.cz> <20170302114453.GX29622@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170302114453.GX29622@ZenIV.linux.org.uk> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 02-03-17 11:44:53, Al Viro wrote: > On Wed, Mar 01, 2017 at 03:29:09PM +0100, Jan Kara wrote: > > > The problem is writeback code (from flusher work or through sync(2) - > > generally inode_to_bdi() users) can be looking at bdev inode independently > > from it being open. So if they start looking while the bdev is open but the > > dereference happens after it is closed and device removed, we oops. We have > > seen oopses due to this for quite a while. And all the stuff that is done > > in __blkdev_put() is not enough to prevent writeback code from having a > > look whether there is not something to write. > > Um. What's to prevent the queue/device/module itself from disappearing > from under you? IOW, what are you doing that is safe to do in face of > driver going rmmoded? So BDI does not have direct relation to the device itself. It is an abstraction for some of the device properties / functionality and thus it can live even after the device itself went away and the module got removed. The only thing users of bdi want is to tell them whether the device is congested or various statistics and dirty inode tracking for writeback purposes and that is all independent of the particular device or whether it still exists. Technically there may be pointers bdi->dev, bdi->owner to the device which are properly refcounted (so the device structure or module cannot be removed under us). These references get dropped & cleared in bdi_unregister() generally called from blk_cleanup_queue() (will be moved to del_gendisk() soon) when the device is going away. This can happen while e.g. bdev still references the bdi so users of bdi->dev or bdi->owner have to be careful to sychronize against device removal and bdi_unregister() but there are only very few such users. Honza -- Jan Kara SUSE Labs, CR