[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F441998.5080600@garzik.org>
Date: Tue, 21 Feb 2012 17:24:24 -0500
From: Jeff Garzik <jeff@...zik.org>
To: Holger Macht <holger@...ac.de>
CC: Hugh Dickins <hughd@...gle.com>, Hillf Danton <dhillf@...il.com>,
Matthew Garrett <mjg@...hat.com>,
Jeff Garzik <jgarzik@...hat.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: linux-next: dock_link_device is oopsy
On 02/18/2012 02:57 PM, Holger Macht wrote:
> On Sa 18. Feb - 10:46:04, Hugh Dickins wrote:
>> On Sat, 18 Feb 2012, Holger Macht wrote:
>>> How about that one?
>>
>> It's more broken than that. Here's my attempt. It boots on the
>> systems with dock_station_count 0, and it boots on my laptop with
>> dock_station_count 2; but I don't actually have any docking station,
>> so it still doesn't test very much (dock is 0 after the loop).
>
> Well, there doesn't have to actually exist a physical dock station (or
> bay device) for dock_station_count to be> 0. It just tells that the
> ACPI objects are present and thus the system is capable of it.
>
> So does this function actually also break on your laptop and you're
> getting the oops there, too?
>
>> I have no idea if what goes on in the loop is correct, but it looks
>> to me as if (as predicted) there's further breakage, that it would
>> have been writing beyond the end of what it allocated if I did have
>> a docking station.
>>
>> Hugh
>>
>> [PATCH] dock: fix bootup oops and other dock_link breakage
>>
>> dock_link_device() and dock_unlink_device() should bail out early
>> to avoid oops on zero-length kmalloc() when dock_station_count is 0.
>>
>> But isn't there an off-by-one in that kmalloc() length anyway?
>> An extra NULL appended at the end suggests so.
>>
>> Rework the ordering with gotos on failure to fix several issues.
>>
>> And presumably dock_unlink_device() should be presenting the same
>> interface as dock_link_device(), with NULL returned when none found.
>>
>> Signed-off-by: Hugh Dickins<hughd@...gle.com>
>
> Fine with me.
So, just to be clear, the preferred patch is Hugh's, and I should drop
your earlier proposed fix found in this thread?
And what about that warning?
Need to fix up linux-next or temporarily drop this patchset from linux-next.
Jeff
--
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/
Powered by blists - more mailing lists