From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Reinecke Subject: Re: [PATCH 5/7] dm core: reject I/O violating new queue limits Date: Fri, 24 Apr 2009 10:59:32 +0200 Message-ID: <49F17F74.6010307@suse.de> References: <49F17409.4060201@ct.jp.nec.com> <49F17510.7010805@ct.jp.nec.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <49F17510.7010805@ct.jp.nec.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: device-mapper development Cc: Alasdair Kergon List-Id: dm-devel.ids Hi Kiyoshi, Kiyoshi Ueda wrote: > This patch detects requests violating the queue limitations > and rejects them. >=20 > The same limitation checks are done when requests are submitted > to the queue by blk_insert_cloned_request(). > However, such violation can happen if a table is swapped and > the queue limitations are shrunk while some requests are > in the queue. >=20 > Since struct request is a reliable one in the block layer and > device drivers, dispatching such requests is pretty dangerous. > (e.g. it may cause kernel panic easily.) > So avoid to dispatch such problematic requests in request-based dm. >=20 This patch actually triggers accidentally during a no-paths scenario; multipathing seems to flush all device details once all paths are gone, so it'll fall back to the system defaults. And then this check will trigger and kill all queued I/Os. Not good. So either we fix device-mapper to keep the device details even for the all-paths down scenario (basically we'd have to copy the device details into the target_io structures and use that for comparison) or we should rather not check here. Cheers, Hannes --=20 Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg GF: Markus Rex, HRB 16746 (AG N=C3=BCrnberg)