public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Chiang <achiang@canonical.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Jiri Slaby <jslaby@suse.cz>,
	linux-pci@vger.kernel.org,
	Linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Jiri Slaby <jirislaby@gmail.com>
Subject: Re: cpqphp: NULL ptr deref in cpqhpc_probe
Date: Thu, 10 Jun 2010 16:34:36 -0600	[thread overview]
Message-ID: <20100610223436.GE8257@canonical.com> (raw)
In-Reply-To: <20100608143739.192a94cd@virtuousgeek.org>

Hi,

My hp.com address is dead. This is my new address.

Luckily, I just happened to be scanning LKML and thought "who
would be crazy enough to be touching cpqphp?" :)

* Jesse Barnes <jbarnes@virtuousgeek.org>:
> Jiri Slaby <jslaby@suse.cz> wrote:
> > Hi,
> > 
> > we have a system where there is a pci hotplug class device to be handled
> > by cpqphp, but it is not a bridge. But in cpqhpc_probe there is:
> > struct pci_bus *bus;
> > ...
> > bus = pdev->subordinate;
> > ...
> > bus->max_bus_speed = PCI_SPEED_66MHz_PCIX;
> > 
> > But as it is not a bridge, subordinate is NULL and the kernel crashes.
> > 
> > Any idea what would be a correct fix here?
> > 
> > The bugzilla entry is at:
> > https://bugzilla.novell.com/show_bug.cgi?id=609338
> 
> I don't think we have anyone actively working on CPQHPC these days.
> Seems like the simple patch would be to check whether pdev->subordinate
> or bus exists before using it...  Have you poked around for specs on
> this at all?

I think Greg/Jesse's suggestion is correct - just return if it's
not a bridge.

I managed to find an ancient machine that actually had this
hardware but never had time to work on it, and then switched
jobs. As far as I know, the hardware is still there, with my old
group.

But I seriously think it's just time to rip this driver out of
the tree. If anyone is actually using this driver to do hotplug,
I will personally buy that person a full half-barrel of
Colorado's finest microbrew of choice in order to numb the pain
of making poor career decisions. Hell, we can drink it together,
during which time I'll hack on the driver. The code surely can't
get any worse.

The occasional bug report shows that it's just more of a
maintenance burden than anything else.

/ac

  parent reply	other threads:[~2010-06-10 22:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-03  9:24 cpqphp: NULL ptr deref in cpqhpc_probe Jiri Slaby
2010-06-03  9:26 ` Jiri Slaby
2010-06-08 21:37 ` Jesse Barnes
2010-06-08 22:05   ` Greg KH
2010-06-10 22:34   ` Alex Chiang [this message]
2010-06-10 23:19     ` Greg KH
2010-06-10 23:28       ` Alex Chiang

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=20100610223436.GE8257@canonical.com \
    --to=achiang@canonical.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jirislaby@gmail.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox