linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Moyer <jmoyer@redhat.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
	Vishnu Pratap Singh <vishnu.ps@samsung.com>,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	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
Subject: Re: [PATCH 1/8] block/genhd.c: Add error handling
Date: Tue, 10 Nov 2015 09:11:27 -0500	[thread overview]
Message-ID: <x49mvumlzao.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <5641674A.6080707@kernel.dk> (Jens Axboe's message of "Mon, 9 Nov 2015 20:40:58 -0700")

Jens Axboe <axboe@kernel.dk> writes:

> 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.

That's my fault, I asked Vishnu to repost.  I had also asked whether he
had seen this in the real world, and this was the response:

  Actually while working with zram I found that during zram
  initialization it uses the add_disk function and during that time i
  have seen sometimes under low mem condition when we enable swap (zram)
  there was kzalloc fail to allocate he memory, since there is no error
  handling it took good amount of time to debug.

Cheers,
Jeff

      reply	other threads:[~2015-11-10 14:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <437969438-9181-1-git-send-email-vishnu.ps@samsung.com>
2015-11-06 12:22 ` [PATCH 1/8] block/genhd.c: Add error handling Vishnu Pratap Singh
2015-11-06 12:22   ` [PATCH 2/8] mmc: handle add_disk() return value Vishnu Pratap Singh
2015-11-06 16:03     ` Ulf Hansson
2015-11-09  5:11     ` Vishnu Pratap Singh
2015-11-06 12:22   ` [PATCH 3/8] block/floppy.c: handle blk_register_region() " Vishnu Pratap Singh
2015-11-06 12:50     ` kbuild test robot
2015-11-09 23:44     ` Grant Grundler
2015-11-06 12:22   ` [PATCH 4/8] block/loop.c: handle add_disk() & " Vishnu Pratap Singh
2015-11-06 12:22   ` [PATCH 5/8] zram: " Vishnu Pratap Singh
2015-11-09  1:07     ` Sergey Senozhatsky
2015-11-06 12:22   ` [PATCH 6/8] md/md.c: handle " Vishnu Pratap Singh
2015-11-06 12:22   ` [PATCH 7/8] cdrom/gdrom.c: handle add_disk() " Vishnu Pratap Singh
2015-11-06 12:22   ` [PATCH 8/8] ide/ide-probe.c: handle blk_register_region() " Vishnu Pratap Singh
2015-11-10  3:33   ` [PATCH 1/8] block/genhd.c: Add error handling Al Viro
2015-11-10  3:40     ` Jens Axboe
2015-11-10 14:11       ` Jeff Moyer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=x49mvumlzao.fsf@segfault.boston.devel.redhat.com \
    --to=jmoyer@redhat.com \
    --cc=adrian.hunter@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=cpgs@samsung.com \
    --cc=davem@davemloft.net \
    --cc=grundler@chromium.org \
    --cc=hare@suse.de \
    --cc=jarod@redhat.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=minchan@kernel.org \
    --cc=ming.lei@canonical.com \
    --cc=neilb@suse.com \
    --cc=ngupta@vflare.org \
    --cc=pintu.k@samsung.com \
    --cc=rohit.kr@samsung.com \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=tiwai@suse.de \
    --cc=tj@kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=viro@ZenIV.linux.org.uk \
    --cc=vishnu.ps@samsung.com \
    --cc=vishu13285@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).