From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752088AbbKJDlH (ORCPT ); Mon, 9 Nov 2015 22:41:07 -0500 Received: from mail-pa0-f43.google.com ([209.85.220.43]:32849 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751033AbbKJDlD (ORCPT ); Mon, 9 Nov 2015 22:41:03 -0500 Subject: Re: [PATCH 1/8] block/genhd.c: Add error handling To: Al Viro , Vishnu Pratap Singh References: <437969438-9181-1-git-send-email-vishnu.ps@samsung.com> <1446812535-10567-1-git-send-email-vishnu.ps@samsung.com> <20151110033322.GB22011@ZenIV.linux.org.uk> Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, jmoyer@redhat.com, minchan@kernel.org, ngupta@vflare.org, sergey.senozhatsky.work@gmail.com, davem@davemloft.net, neilb@suse.com, ulf.hansson@linaro.org, tiwai@suse.de, hare@suse.de, ming.lei@canonical.com, jarod@redhat.com, tj@kernel.org, adrian.hunter@intel.com, jonathanh@nvidia.com, grundler@chromium.org, linux-ide@vger.kernel.org, linux-raid@vger.kernel.org, linux-mmc@vger.kernel.org, cpgs@samsung.com, vishu13285@gmail.com, pintu.k@samsung.com, rohit.kr@samsung.com From: Jens Axboe Message-ID: <5641674A.6080707@kernel.dk> Date: Mon, 9 Nov 2015 20:40:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151110033322.GB22011@ZenIV.linux.org.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/09/2015 08:33 PM, Al Viro wrote: > On Fri, Nov 06, 2015 at 05:52:08PM +0530, Vishnu Pratap Singh wrote: > > Have you even tried to trigger the failure exits you've added? The > more you've successfully set up, the _less_ your cleanup code ends > up undoing; that simply can't be right. > > That aside, as soon as we'd done register_disk(), the damn thing is > available for open(), so bailing out is _really_ not something for > faint-hearted - it's essentially equivalent to removal of device under > somebody who'd opened it and might've started IO, etc. Going there > simply because some sysfs shite didn't get created doesn't look sane > as far as I'm concerned... > > Especially since these failure exits are not going to be tested on > a regular basis, so the amount of bitrot will be pretty high ;-/ I'd greatly prefer it we just leave it alone. Much better to have a disk that does actually work and with some sysfs spew in the logs, than bail out for fairly vague reasons. The road to hell is paved with good intentions. It's a noble thought to want to clean this up, but I think it does more harm than good. -- Jens Axboe