From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: [PATCH 7/7] dm-mpath: Fix a race condition in __multipath_map() Date: Tue, 15 Nov 2016 20:01:17 -0500 Message-ID: <20161116010117.GE19059@redhat.com> References: <81bc399e-df90-099d-1b25-bdb0fda3f27c@sandisk.com> <20161116003720.GA19059@redhat.com> <8af6b1c0-3513-8a13-5ebb-8bdf90bf43e0@sandisk.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <8af6b1c0-3513-8a13-5ebb-8bdf90bf43e0@sandisk.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: Bart Van Assche Cc: device-mapper development List-Id: dm-devel.ids On Tue, Nov 15 2016 at 7:40pm -0500, Bart Van Assche wrote: > On 11/15/2016 04:37 PM, Mike Snitzer wrote: > >On Tue, Nov 15 2016 at 6:35pm -0500, > >Bart Van Assche wrote: > >>If a single-queue dm device is stacked on top of multi-queue block > >>devices and map_tio_request() is called while there are no paths then > >>the request will be prepared for a single-queue path. If a path is > >>added after a request was prepared and before __multipath_map() is > >>called return DM_MAPIO_REQUEUE such that it gets unprepared and > >>reprepared as a blk-mq request. > > > >This patch makes little sense to me. There isn't a scenario that I'm > >aware of that would allow the request_queue to transition between old > >.request_fn and new blk-mq. > > > >The dm-table code should prevent this. > > Hello Mike, > > Are you aware that dm_table_determine_type() sets "all_blk_mq" to > false if there are no paths, even if the dm device is in blk-mq > mode? That shouldn't matter. Once the type is established, it is used to initialize the DM device's request_queue, the type cannot change across different table loads.