From: Christoph Hellwig <hch@lst.de>
To: Jan Kara <jack@suse.cz>
Cc: Dan Williams <dan.j.williams@intel.com>,
Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>,
Jens Axboe <axboe@kernel.dk>, Rabin Vincent <rabinv@axis.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-block@vger.kernel.org, Andi Kleen <andi@firstfloor.org>,
Wei Fang <fangwei1@huawei.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [RFC PATCH v2 0/2] block: fix backing_dev_info lifetime
Date: Thu, 26 Jan 2017 14:17:56 +0100 [thread overview]
Message-ID: <20170126131756.GA18649@lst.de> (raw)
In-Reply-To: <20170126100653.GB17099@quack2.suse.cz>
On Thu, Jan 26, 2017 at 11:06:53AM +0100, Jan Kara wrote:
> Yeah, so my patches (and I suspect your as well), have a problem when the
> backing_device_info stays around because blkdev inode still exists, device
> gets removed (e.g. USB disk gets unplugged) but blkdev inode still stays
> around (there doesn't appear to be anything that would be forcing blkdev
> inode out of cache on device removal and there cannot be because different
> processes may hold inode reference) and then some other device gets plugged
> in and reuses the same MAJOR:MINOR combination. Things get awkward there, I
> think we need to unhash blkdev inode on device removal but so far I didn't
> make this work...
The other option is to simply not release the dev_t until the backing_dev
is gone.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Jan Kara <jack@suse.cz>
Cc: Jens Axboe <axboe@kernel.dk>, Rabin Vincent <rabinv@axis.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-block@vger.kernel.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Andi Kleen <andi@firstfloor.org>, Wei Fang <fangwei1@huawei.com>,
Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [RFC PATCH v2 0/2] block: fix backing_dev_info lifetime
Date: Thu, 26 Jan 2017 14:17:56 +0100 [thread overview]
Message-ID: <20170126131756.GA18649@lst.de> (raw)
In-Reply-To: <20170126100653.GB17099@quack2.suse.cz>
On Thu, Jan 26, 2017 at 11:06:53AM +0100, Jan Kara wrote:
> Yeah, so my patches (and I suspect your as well), have a problem when the
> backing_device_info stays around because blkdev inode still exists, device
> gets removed (e.g. USB disk gets unplugged) but blkdev inode still stays
> around (there doesn't appear to be anything that would be forcing blkdev
> inode out of cache on device removal and there cannot be because different
> processes may hold inode reference) and then some other device gets plugged
> in and reuses the same MAJOR:MINOR combination. Things get awkward there, I
> think we need to unhash blkdev inode on device removal but so far I didn't
> make this work...
The other option is to simply not release the dev_t until the backing_dev
is gone.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Jan Kara <jack@suse.cz>
Cc: Dan Williams <dan.j.williams@intel.com>,
Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>,
Jens Axboe <axboe@kernel.dk>, Rabin Vincent <rabinv@axis.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-block@vger.kernel.org, Andi Kleen <andi@firstfloor.org>,
Wei Fang <fangwei1@huawei.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [RFC PATCH v2 0/2] block: fix backing_dev_info lifetime
Date: Thu, 26 Jan 2017 14:17:56 +0100 [thread overview]
Message-ID: <20170126131756.GA18649@lst.de> (raw)
In-Reply-To: <20170126100653.GB17099@quack2.suse.cz>
On Thu, Jan 26, 2017 at 11:06:53AM +0100, Jan Kara wrote:
> Yeah, so my patches (and I suspect your as well), have a problem when the
> backing_device_info stays around because blkdev inode still exists, device
> gets removed (e.g. USB disk gets unplugged) but blkdev inode still stays
> around (there doesn't appear to be anything that would be forcing blkdev
> inode out of cache on device removal and there cannot be because different
> processes may hold inode reference) and then some other device gets plugged
> in and reuses the same MAJOR:MINOR combination. Things get awkward there, I
> think we need to unhash blkdev inode on device removal but so far I didn't
> make this work...
The other option is to simply not release the dev_t until the backing_dev
is gone.
next prev parent reply other threads:[~2017-01-26 13:17 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-07 1:02 [RFC PATCH v2 0/2] block: fix backing_dev_info lifetime Dan Williams
2017-01-07 1:02 ` Dan Williams
2017-01-07 1:02 ` Dan Williams
2017-01-07 1:02 ` [RFC PATCH v2 1/2] block: fix lifetime of request_queue / backing_dev_info relative to bdev Dan Williams
2017-01-07 1:02 ` Dan Williams
2017-01-07 1:02 ` Dan Williams
2017-01-09 2:39 ` [lkp-developer] [block] 1442488925: WARNING:at_mm/backing-dev.c:#bdi_exit kernel test robot
2017-01-09 2:39 ` kernel test robot
2017-01-09 2:39 ` kernel test robot
2017-01-09 2:39 ` kernel test robot
2017-01-07 1:03 ` [RFC PATCH v2 2/2] block: fix blk_get_backing_dev_info() crash, use bdev->bd_queue Dan Williams
2017-01-07 1:03 ` Dan Williams
2017-01-07 1:03 ` Dan Williams
2017-01-23 21:17 ` [RFC PATCH v2 0/2] block: fix backing_dev_info lifetime Thiago Jung Bauermann
2017-01-23 21:17 ` Thiago Jung Bauermann
2017-01-23 21:17 ` Thiago Jung Bauermann
2017-01-25 21:43 ` Dan Williams
2017-01-25 21:43 ` Dan Williams
2017-01-25 21:43 ` Dan Williams
2017-01-26 10:06 ` Jan Kara
2017-01-26 10:06 ` Jan Kara
2017-01-26 10:06 ` Jan Kara
2017-01-26 13:17 ` Christoph Hellwig [this message]
2017-01-26 13:17 ` Christoph Hellwig
2017-01-26 13:17 ` Christoph Hellwig
2017-01-26 16:39 ` Dan Williams
2017-01-26 16:39 ` Dan Williams
2017-01-26 16:39 ` Dan Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170126131756.GA18649@lst.de \
--to=hch@lst.de \
--cc=andi@firstfloor.org \
--cc=axboe@kernel.dk \
--cc=bauerman@linux.vnet.ibm.com \
--cc=dan.j.williams@intel.com \
--cc=fangwei1@huawei.com \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=rabinv@axis.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.