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-next>] [day] [month] [year] [list]
Message-Id: <200608091152.49094.rjw@sisk.pl>
Date:	Wed, 9 Aug 2006 11:52:49 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Pavel Machek <pavel@....cz>, Linux PM <linux-pm@...l.org>
Subject: [RFC][PATCH -mm 0/5] swsusp: Fix handling of highmem

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.

Greetings,
Rafael

-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ