Re: suspend-to-{RAM,disk} for 2.5.17

[William Lee Irwin III <wli@holomorphy.com>]

At some point in the past, Pavel Machek wrote:
>>> I had to add
>>> 	if (!curr) break; 
>>> to fix the oops. It now looks way nicer. Thanx.

At some point in the past, I wrote:
>> It's pretty odd that this happens to the buddy lists. I guess if it's
>> needed as a stopgap measure, I can't complain too much, but I'd suspect
>> something's corrupting it or you're catching a buddy list operation in
>> progress. I might be interested in taking a stab at finding out where
>> the corruption happens if you also think that's what's going on.

On Tue, May 28, 2002 at 11:11:20PM +0200, Pavel Machek wrote:
> I think it is not a coruption, but something like
> "not all list are valid on non-himem machine", or something like that.
> 								Pavel

d'oh! Sorry about that, I forgot about free_area_init_core() not fixing
up zeroed-out list_heads for ZONE_HIGHMEM. I don't see any harm in
doing INIT_LIST_HEAD() on them in free_area_init_core(), and it would
seem to fix this boundary case, no? Alternatively, highmem zones on non-
highmem machines can be skipped by the caller as well. Do you think
either of these might be good ideas, or is it going too far out of one's
way for marginal code prettiness benefits?

Actually, I just thought of something that might be useful in addition,
which is that it would probably only be necessary to search inside of
page_zone(page), do you agree?


Cheers,
Bill