linux-kernel - Re: [Pv-drivers] [PATCH 08/12] VMCI: resource object implementation.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 30 Oct 2012 08:51:59 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Dmitry Torokhov <dtor@...are.com>
Cc:	George Zhang <georgezhang@...are.com>, pv-drivers@...are.com,
	linux-kernel@...r.kernel.org,
	virtualization@...ts.linux-foundation.org
Subject: Re: [Pv-drivers] [PATCH 08/12] VMCI: resource object implementation.

On Mon, Oct 29, 2012 at 10:20:16PM -0700, Dmitry Torokhov wrote:
> On Mon, Oct 29, 2012 at 07:29:05PM -0700, Greg KH wrote:
> > On Mon, Oct 29, 2012 at 06:04:58PM -0700, George Zhang wrote:
> > > +static struct vmci_resource *vmci_resource_lookup(struct vmci_handle handle)
> > > +{
> > > +	struct vmci_resource *r, *resource = NULL;
> > > +	struct hlist_node *node;
> > > +	unsigned int idx = vmci_resource_hash(handle);
> > > +
> > > +	BUG_ON(VMCI_HANDLE_EQUAL(handle, VMCI_INVALID_HANDLE));
> > 
> > You just crashed a machine, with no chance for recovery.  Not a good
> > idea.  Never a good idea.  Customers just lost data, and now they are
> > mad.  Make sure you at least print out your email address so they know
> > who to blame :)
> > 
> > Seriously, never BUG() in a driver, warn, sure, but this just looks like
> > a debugging assert().  Please remove all of these, they are sprinkled
> > all over the driver code here, I'm only responding to one of them here.
> > 
> > Even better yet, properly handle the error and keep on going, that's
> > what the rest of the kernel does.  Or should :)
> 
> For public APIs it certainly makes sense to check and handle erroneous input;

It's not "public", it's an in-kernel api.  See the static up there?  :)

> internally it often makes sense to simply enforce invariants, because if
> we managed to get into that state that we consider impossible we can't really
> trust anything.

Then error out, don't crash the box.  Again, this really looks like an
ASSERT() you are trying to catch, which you know how well we like those
in kernel code...

> FWIW:
> [dtor@...r-ws kernel]$ grep -r BUG_ON . | wc -l
> 11269

I'm not saying that those are acceptable either, I just don't want to
add any more to the kernel.

greg k-h
--
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/