Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp171635pxv; Thu, 15 Jul 2021 01:26:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx8bvbHKlEVB8BKWLve+p8bHZKIPWdDDowF697Wq4BrUlrS8uBxIaj+avxjoWYTUBFClhDT X-Received: by 2002:a17:906:28d1:: with SMTP id p17mr4014283ejd.130.1626337594963; Thu, 15 Jul 2021 01:26:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626337594; cv=none; d=google.com; s=arc-20160816; b=jUzhyznFMH7ZZ8H6TyqBa090hmWFodzsMGdtJPZkQCBt8OlLodyPl0Tl4FRsiHT3kD d4xVB9gMEL4s69NPM4IjT4Mu80upBSRi7V95lsWYOrCl/aU7MQASqyyODuiN876PhZuI Wiwn1rE4haDduIMyYPZ1AsWgpqIybyJydBfxFkxc/HKW6qYG7ky6XJeEp9Z0SE5vN37P 6jMsr2d3TDqgmxq+/IIU6VtwfD2N7HHgdUkVwz9nQhlJIqLP77KE7wY/CJAQJvpk9Cxz mcpUgXpS2As6GNePVIeagVERNlqqEPiv+K1tSM1czobvQFiQ96/MIWCYL4m8e0iWgGSx IPJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Nthw7+H9DsL3CqcVPXgloMpkXopb6k/WOK6hCfAUI9E=; b=mWxcmCNJWsUEQ2YmXNhBozWjw2CEucsNoJ+lCqENz4tG9QR6y2DP9TN54VTN7pq8lm 54C7VrIu+10NVSiez0THe+kcynKQY98g4r2K+O277v/LxK2oCUWEPJcNBVCOFX5wx8Ta O7kUNaV9Ce+sG0t5nTqBaYVgbe25dqHT4ojg3We5hpCntgZtX8Uqdf24PTxvIUyUQhdm Xd7lJMl66la8MMjbgUw6CsvpMPr5eN3lRAPoGG7sE3v7Kg81cLnzbKJSWO4r2zozov59 3BidEJr73otw+jAPBGOCoT8tEw9z78X+NHgiOEov3mvllOUmiP4fH144Yt8uz7LSbF+v 1+dg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="Yf5fDEh/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hk6si6582821ejb.587.2021.07.15.01.26.11; Thu, 15 Jul 2021 01:26:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="Yf5fDEh/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239447AbhGOHRH (ORCPT + 99 others); Thu, 15 Jul 2021 03:17:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38072 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236350AbhGOHRH (ORCPT ); Thu, 15 Jul 2021 03:17:07 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C0C2C06175F; Thu, 15 Jul 2021 00:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Nthw7+H9DsL3CqcVPXgloMpkXopb6k/WOK6hCfAUI9E=; b=Yf5fDEh/TbD3agyP0vCxl08zZk VxIVuUOtkRIotrEii4sjruD/CK52P0fMofWhTiSQF0W9GJbjsKHc7xMT4Hxyt8UbMJynwnmza9AIa uSnR+JA68HQ1w1H4nWotj1TORoXTli9/2s4yiDMkD4c0We/pLGidninGkJBsCBt3t7wIMtFgDjtGX LgwFgGoR18bggom19evLRe+N0KYCqoqcZgwclLF21d09GnyJX8UU9VPAgADErdMiVwsfSMSMc82AW GcalPNYUjjyHY9/xqgzKCEMfVmnJJoolCIyLmCm5V7aq2Va9owd6CnSHY/kVOKJGPD0uNeUajGpiM 6o6mztkw==; Received: from hch by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1m3vXJ-0035SQ-FE; Thu, 15 Jul 2021 07:12:26 +0000 Date: Thu, 15 Jul 2021 08:11:57 +0100 From: Christoph Hellwig To: Luis Chamberlain Cc: axboe@kernel.dk, hare@suse.de, bvanassche@acm.org, ming.lei@redhat.com, hch@infradead.org, jack@suse.cz, osandov@fb.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 6/6] block: skip queue if NULL on blk_cleanup_queue() Message-ID: References: <20210715045531.420201-1-mcgrof@kernel.org> <20210715045531.420201-7-mcgrof@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210715045531.420201-7-mcgrof@kernel.org> X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 14, 2021 at 09:55:31PM -0700, Luis Chamberlain wrote: > Now that error handling for add_disk*() calls is added, we must > accept a common form for when errors are detected on the the > add_disk*() calls, and that is to call blk_cleanup_disk() on > error always. One of the corner cases possible is a driver bug > where the queue is already gone and we cannot blk_get_queue(), > and so may be NULL. When blk_cleanup_disk() is called in this > case blk_cleanup_queue() will crash with a null dereference. > > Make this an accepted condition and just skip it. This allows us > to also test for it safely with error injection. So you plan to call blk_cleanup_disk when add_disk fails? For all drivers using blk_alloc_disk/blk_mq_alloc_disk there should always be a queue. The others ones aren't ready to handle errors from add_disk yet in any way I think (and I plan to fix this up ASAP).