All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: Artem Bityutskiy <dedekind@infradead.org>
Cc: akpm <akpm@linux-foundation.org>, linux-mtd@lists.infradead.org
Subject: Re: [PATCH -mm] UBI: one less BUG usage
Date: Wed, 27 Jun 2007 22:13:34 -0700	[thread overview]
Message-ID: <4683437E.50109@oracle.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0706272244470.22935@pentafluge.infradead.org>

Artem Bityutskiy wrote:
> On Tue, 26 Jun 2007, Randy Dunlap wrote:
> 
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> Eliminate one BUG() usage.  The callers of major_to_device() already
>> handle and report errors.  This is just another error to return.
> 
> Why is this just an error? It must never happen unles there is a bug in 
> the code. Or is there a campaign against BUG() calls?
> 
> Artem.

There's always a campaign against unneeded BUG() calls.
However, if you say this one is needed, then so be it.

However(2), ubi_cdev_ioctl() calls major_to_device() and allows it
to return an error [although major_to_device() currently cannot
return such an error]:

	ubi = major_to_device(imajor(inode));
	if (IS_ERR(ubi))
		return PTR_ERR(ubi);

so part of cdev.c allows and handles error returns from major_to_device().

All my patch does is allow and handle error returns from major_to_device()
in vol_cdev_open().  vol_cdev_open() already handles errors by returning
the error to its caller.

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

  reply	other threads:[~2007-06-28  5:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-26 22:30 [PATCH -mm] UBI: one less BUG usage Randy Dunlap
2007-06-27 21:47 ` Artem Bityutskiy
2007-06-28  5:13   ` Randy Dunlap [this message]
2007-06-28 16:36     ` Artem Bityutskiy

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=4683437E.50109@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=dedekind@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.