All of lore.kernel.org
 help / color / mirror / Atom feed
From: Holger Macht <holger@homac.de>
To: Hugh Dickins <hughd@google.com>
Cc: Matthew Garrett <mjg@redhat.com>,
	Jeff Garzik <jgarzik@redhat.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: linux-next: dock_link_device is oopsy
Date: Sat, 18 Feb 2012 12:14:19 +0100	[thread overview]
Message-ID: <20120218111419.GA2488@homac.suse.de> (raw)
In-Reply-To: <alpine.LSU.2.00.1202171541040.3155@eggly.anvils>

On Fr 17. Feb - 15:49:02, Hugh Dickins wrote:
> On Sat, 18 Feb 2012, Holger Macht wrote:
> > On Fr 17. Feb - 14:42:31, Hugh Dickins wrote:
> > > On Fri, 17 Feb 2012, Holger Macht wrote:
> > > > On Fr 17. Feb - 13:46:04, Hugh Dickins wrote:
> > > > > Matthew,
> > > > > 
> > > > > A linux-next oops at bootup in dock_link_device() tells me that you
> > > > > were not feeling well when you wrote that and dock_unlink_device():
> > > > > I hope you're feeling better now and can rewrite them soon.
> > > > 
> > > > Andrew Morton experienced a similar problem. What system are you using?
> > > > I didn't encounter this problem with the systems I tested with.
> > > 
> > > The two systems I got that on were both 4-year-old Core2 Duo systems,
> > > one an HP quad desktop, one a Fujitsu-Siemens laptop.
> > 
> > Thanks for the information I think this is really independent from the
> > fact if a laptop, or more precicely if a system with dock station/bay is
> > used.
> > 
> > > 
> > > > 
> > > > Do you actually have a /sys/devices/platform/dock.?/ directory with a
> > > > file 'type' that contains 'dock_station'?
> > > 
> > > I'll have to report back on that this evening, I'm away from them now.
> > 
> > I actually guess that those systems don't have a
> > /sys/devices/platform/dock.? directory at all, which is fine.
> > 
> > I also think this will fix it, would be great if you could confirm this:
> > 
> > acpi: Bail out when linking devices and there are no dock stations
> > 
> > If dock_station_count is zero, we allocate zero memory and don't check
> > this at future references. So bail out if there are actually no dock
> > stations.
> > 
> > Signed-off-by: Holger Macht <holger@homac.de>
> 
> Certainly won't fix it as is (well, it shifts the crash over into kfree).
> This function is expected to return a pointer, not an error or success
> code.

Oh well, too late for me yesterday...

> 
> I've little doubt that returning NULL rather than -ENODEV there would fix
> the boot crash; and if you're in a hurry to fix up booting (understandable)
> then I suppose that would do for the moment.

I really think this will basically do the trick. dock_(un)link_device()
is called by ata_acpi_(un)bind_dock(), which in turn is called by
ata_scsi_scan_host() unconditionally, thus not depending on the presence
of a dock device. And dock_(un)link_device() simply misses the check if
there is a dock/bay device.

So how about that?

acpi: Bail out when linking devices and there are no dock stations

If dock_station_count is zero, we allocate zero memory and don't check
this at future references. So bail out if there are actually no dock
stations.

Signed-off-by: Holger Macht <holger@homac.de>
---
 drivers/acpi/dock.c |   19 ++++++++++++++-----
 1 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/dock.c b/drivers/acpi/dock.c
index b5e4142..0b3072c 100644
--- a/drivers/acpi/dock.c
+++ b/drivers/acpi/dock.c
@@ -281,11 +281,15 @@ EXPORT_SYMBOL_GPL(is_dock_device);
  */
 struct device **dock_link_device(acpi_handle handle)
 {
-	struct device *dev = acpi_get_physical_device(handle);
+	struct device *dev;
 	struct dock_station *dock_station;
 	int ret, dock = 0;
 	struct device **devices;
 
+	if (!dock_station_count)
+		return NULL;
+
+	dev = acpi_get_physical_device(handle);
 	devices = kmalloc(dock_station_count * sizeof(struct device *),
 			  GFP_KERNEL);
 
@@ -320,12 +324,17 @@ EXPORT_SYMBOL_GPL(dock_link_device);
  */
 struct device **dock_unlink_device(acpi_handle handle)
 {
-	struct device *dev = acpi_get_physical_device(handle);
+	struct device *dev;
 	struct dock_station *dock_station;
 	int dock = 0;
-	struct device **devices =
-		kmalloc(dock_station_count * sizeof(struct device *),
-			GFP_KERNEL);
+	struct device **devices;
+
+	if (!dock_station_count)
+		return NULL;
+
+	dev = acpi_get_physical_device(handle);
+	devices = kmalloc(dock_station_count * sizeof(struct device *),
+			  GFP_KERNEL);
 
 	if (!dev)
 		return NULL;
-- 
1.7.7


  reply	other threads:[~2012-02-18 11:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-17 21:46 linux-next: dock_link_device is oopsy Hugh Dickins
2012-02-17 22:29 ` Holger Macht
2012-02-17 22:42   ` Hugh Dickins
2012-02-17 23:01     ` Holger Macht
2012-02-17 23:49       ` Hugh Dickins
2012-02-18 11:14         ` Holger Macht [this message]
2012-02-18 13:05           ` Hillf Danton
2012-02-18 13:26             ` Holger Macht
2012-02-18 13:37               ` Hillf Danton
2012-02-18 14:04                 ` Holger Macht
2012-02-18 14:35                   ` Hillf Danton
2012-02-18 18:46                   ` Hugh Dickins
2012-02-18 19:57                     ` Holger Macht
2012-02-18 21:03                       ` Hugh Dickins
2012-02-18 21:50                         ` Holger Macht
2012-02-21 22:24                       ` Jeff Garzik
2012-02-21 22:30                         ` Holger Macht
2012-02-18  7:52       ` Hugh Dickins

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=20120218111419.GA2488@homac.suse.de \
    --to=holger@homac.de \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=jgarzik@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg@redhat.com \
    --cc=sfr@canb.auug.org.au \
    /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.