Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4568344pxj; Wed, 12 May 2021 08:21:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyis1mWS2MoJ96gotGZo5DodQFcCjrW5NcpHA92UpoWeyyEy2yACThfN928KYrtZ3c2RazA X-Received: by 2002:aca:ba09:: with SMTP id k9mr26071308oif.178.1620832897134; Wed, 12 May 2021 08:21:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620832897; cv=none; d=google.com; s=arc-20160816; b=RymvsgQ3dUKHamjRtr3nrqfjzd7rgDJGvJTgXpmt7n+UEQZoorM3DfWD6/KK6lUoQc 8gQL6gmLBXgAJvl3f4jVqfM/R3st6eHSFSnt+0nIz11590UUALdrfh/GEdqxcznmQFco Ci4n0qJM8UuAg7z0/jjK8VMm7mB7gx1Y9nTMcLUtbW2WykewCWyN2YrozZASKjwv01pt 9Hj9DNfpKMV5trLQApK4mB29pCxzPxCqlEK/q7c3bApJvoe71gvx9EtW6sYavWDwzHCr QvP5BV0cFN8e0/7FmrDdNbujmG9P/nto8oEYiof5kDzqK05bqXcl5WPMjlObcOdx7x/7 JSWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=LFq3tqame5YBSFGlYLM7Glpc0SKwSoix38KeYKM+8eM=; b=xzxWO5yg0wpzmxYM2CqZ0swTrh4t24j6+OMgCFke9uw/uMkXT3vM5AFs+MV8eCJ3jO FuHVhEcjKob8/G+j/XogJuqvYOn46VaOc9ZJv9tPuhchscS/o7iqbHMLXuWvbajTjlPK s6LIeekPbYR6SGcX29rzopsMspzi1dKVr5hYuBGwUicAxlwrPqbFoVO6V0LuAqY9XgE2 +/zeVTFZJVWC/vM8h91gkogLX33pqY/WukQtrIbCbEP0+Gz3CnNB+6fHE7/Z4wrVgcJB 3v6RL0NA4Y9HA5Orutu0fSX56Nv3dRxcdbG5K0kWuJXymT4vLp0cRpf1IuGObYxkuwpt XR9A== ARC-Authentication-Results: i=1; mx.google.com; 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 p11si129193ota.273.2021.05.12.08.21.24; Wed, 12 May 2021 08:21:37 -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; 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 S234111AbhELPTS (ORCPT + 99 others); Wed, 12 May 2021 11:19:18 -0400 Received: from mx2.suse.de ([195.135.220.15]:36010 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232981AbhELPJG (ORCPT ); Wed, 12 May 2021 11:09:06 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 13903AFCD; Wed, 12 May 2021 15:07:57 +0000 (UTC) Subject: Re: [PATCH v1 1/8] block: refcount the request_queue early in __device_add_disk() To: Luis Chamberlain , axboe@kernel.dk Cc: 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 References: <20210512064629.13899-1-mcgrof@kernel.org> <20210512064629.13899-2-mcgrof@kernel.org> From: Hannes Reinecke Message-ID: Date: Wed, 12 May 2021 17:07:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <20210512064629.13899-2-mcgrof@kernel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/12/21 8:46 AM, Luis Chamberlain wrote: > We refcount the request_queue right now towards the end of the > __device_add_disk(), however when we add error handling on this > function we'll want to refcount the request_queue first, to help > make less complicated changes on drivers on their error paths. > > For instance, today a driver may call add_disk without error handling > but still handle other errors: > > int foo_block_add(...) > { > ... > queue = blk_mq_init_queue(...); > ... > disk->queue = queue; > disk = alloc_disk(...); > if (!disk) > goto out_free_queue; > ... > add_disk(disk); > ... > return 0; > > out_free_queue: > blk_cleanup_queue(queue); > /* Note: we never call put_disk() as add_disk() never failed */ > ... > } > > We want drivers to cleanup with put_disk() on the error path if > add_disk() fails. However, calling blk_cleanup_queue() will already > put the queue, and so the last put_disk() on the error path will > be extra. This can be simplified later if once error handling is > added to __device_add_disk(), if refcounting the request_queue > fails right away on __device_add_disk() we just return early and > set disk->NULL for the driver. That would ensure driver error > paths chug on with their error paths, and all they'd need to > expand with is the missing put_disk(). > > The collateral evolution for adding error paths for add_disk() becomes > larger with the alternative of replacing the blk_cleanup_queue() with > a put_disk(). We'd still need to sprinkle then some blk_cleanup_queue() > calls on the driver paths up above prior to add_disk(). And how would > we know we reached a part of add_disk() which did refcount then? > > A related commit is 5a0ec388ef0 ("pktcdvd: Fix pkt_setup_dev() error > path") which *had* to take the approach of removing the blk_cleanup_queue() > because otherwise the driver crashes. > > Moving this to the top ensure our future error path can easily just > handle this itself. For instance, if it was not able to refcount the > request_queue it can disk->queue to NULL, that way allowing a > blk_cleanup_queue() call followed but a put_disk(). And if the > refcount was incremented, we'd still be able to keep the same error > path of blk_cleanup_queue() followed by put_disk(). > > Signed-off-by: Luis Chamberlain > --- > block/genhd.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer