linux-kernel - Re: [RFC][PATCH -mm 0/5] swsusp: Fix handling of highmem

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]

Date:	Wed, 9 Aug 2006 20:47:12 +1000
From:	Nigel Cunningham <ncunningham@...uxmail.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	LKML <linux-kernel@...r.kernel.org>, Pavel Machek <pavel@....cz>,
	Linux PM <linux-pm@...l.org>
Subject: Re: [RFC][PATCH -mm 0/5] swsusp: Fix handling of highmem

Hi.

On Wednesday 09 August 2006 19:52, Rafael J. Wysocki wrote:
> Hi,
>
> Currently swsusp handles highmem in a simplistic way, by trying to store a
> copy of each saveable highmem page in the "normal" memory before creating
> the suspend image.  These copies are then copied once again before saving,
> because they are treated as any other non-highmem pages with data.  For
> this reason, to save one highmem page swsusp needs two free pages in the
> "normal" memory, so on a system with high memory it is practically
> impossible to create a suspend image above 400 kilobytes.  Moreover, if
> there's much more highmem than the "normal" memory in the system, it may be
> impossible to suspend at all due to the lack of space for saving
> non-freeable highmem pages.
>
> This limitation may be overcome in a satisfactory way if swsusp does its
> best to store the copies of saveable highmem pages in the highmem itself. 
> However, for this purpose swsusp has to be taught to use pfns, or (struct
> page *) pointers, instead of kernel virtual addresses to identify memory
> pages. Yet, if this is to be implemented, we can also attack the minor
> problem that the current swsusp's internal data structure, the list of page
> backup entries (aka PBEs), is not very efficient as far as the memory usage
> is concerned.
>
> This issue can be addressed by replacing the list of PBEs with a pair of
> memory bitmaps.  Still, to remove the list of PBEs completely, we would
> have to make some complicated modifications to the architecture-dependent
> parts of the code which would be quite undesirable.  However, we can use
> the observation that memory is only a limiting resource during the suspend
> phase of the suspend-resume cycle, because during the resume phase
> many image pages may be loaded directly to their "original" page frames, so
> we don't need to keep a copy of each of them in the memory.  Thus the list
> of PBEs may be used safely in the last part of the resume phase without
> limitting the amount of memory we can use.
>
> The following series of patches introduces the memory bitmap data
> structure, makes swsusp use it to store its internal information and
> implements the improved handling of saveable highmem pages.
>
> Comments welcome.

Thanks for the reminder. I'd forgotten half the reason why I didn't want to 
make Suspend2 into incremental patches! You're a brave man!

Nigel
-- 
while (1) {
  size=$RANDOM * 65536 + 1
  dd if=/dev/random bs=1 count=$size | patch -p0-b
  make && break
}

Content of type "application/pgp-signature" skipped