[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <x49mvumlzao.fsf@segfault.boston.devel.redhat.com>
Date: Tue, 10 Nov 2015 09:11:27 -0500
From: Jeff Moyer <jmoyer@...hat.com>
To: Jens Axboe <axboe@...nel.dk>
Cc: Al Viro <viro@...IV.linux.org.uk>,
Vishnu Pratap Singh <vishnu.ps@...sung.com>,
akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
minchan@...nel.org, ngupta@...are.org,
sergey.senozhatsky.work@...il.com, davem@...emloft.net,
neilb@...e.com, ulf.hansson@...aro.org, tiwai@...e.de,
hare@...e.de, ming.lei@...onical.com, jarod@...hat.com,
tj@...nel.org, adrian.hunter@...el.com, jonathanh@...dia.com,
grundler@...omium.org, linux-ide@...r.kernel.org,
linux-raid@...r.kernel.org, linux-mmc@...r.kernel.org,
cpgs@...sung.com, vishu13285@...il.com, pintu.k@...sung.com,
rohit.kr@...sung.com
Subject: Re: [PATCH 1/8] block/genhd.c: Add error handling
Jens Axboe <axboe@...nel.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists