linux-kernel - Re: [visorchipset] invalid opcode: 0000 [#1] PREEMPT SMP

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20140407192347.GA8272@kroah.com>
Date:	Mon, 7 Apr 2014 12:23:47 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Ken Cox <jkc@...hat.com>
Cc:	Fengguang Wu <fengguang.wu@...el.com>, devel@...verdev.osuosl.org,
	sparmaintainer@...sys.com, linux-kernel@...r.kernel.org,
	Jet Chen <jet.chen@...el.com>
Subject: Re: [visorchipset] invalid opcode: 0000 [#1] PREEMPT SMP

On Mon, Apr 07, 2014 at 09:24:37AM -0500, Ken Cox wrote:
> 
> On 04/07/2014 09:09 AM, Greg Kroah-Hartman wrote:
> >On Mon, Apr 07, 2014 at 07:17:25PM +0800, Fengguang Wu wrote:
> >>Hi Ken,
> >>
> >>I got the below dmesg and the first bad commit is
> >>
> >>git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> >>
> >>commit 12e364b9f08aa335dc7716ce74113e834c993765
> >>Author:     Ken Cox <jkc@...hat.com>
> >>AuthorDate: Tue Mar 4 07:58:07 2014 -0600
> >>Commit:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> >>CommitDate: Tue Mar 4 16:58:21 2014 -0800
> >>
> >>     staging: visorchipset driver to provide registration and other services
> >I think Sasha has already sent a fix to resolve this issue that I'll be
> >sending to Linus in a day or so.
> >
> >Ken, is Sasha's patch going to resolve this issue as well?  It looks
> >like people haven't tested what happens when the module is loaded
> >without the hardware present in the system :(
> You are exactly right.  The driver needs to check for hardware early on
> before trying to use it.  Unfortunately, Sasha's patch will not resolve this
> one.  I'll work with Ben Romer to get a patch out ASAP.

Wait, in looking at this closer, I don't see any of the "normal"
hardware checks to determine that this really is a valid piece of
hardware present, before it starts to just go and initialize a whole
bunch of things (sysfs busses, proc files and directories, and other
things.)

That's not ok, and it's obvious it's starting to affect people's work
systems.

How about I just mark the whole thing BROKEN for now, disabling the
build, until "correct" hardware probing can be added to the driver, so
no one else gets hurt by this?

thanks,

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/