public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: LKML <linux-kernel@vger.kernel.org>, Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH 3/3][Fix] swsusp: prevent swsusp from failing if there's too many pagedir pages
Date: Mon, 26 Sep 2005 12:33:36 +0200	[thread overview]
Message-ID: <20050926103336.GA3693@elf.ucw.cz> (raw)
In-Reply-To: <200509252044.00928.rjw@sisk.pl>

Hi!

> There's a silent assumption in swsusp that always
> sizeof(struct swsusp_info) <= PAGE_SIZE, which is wrong, because
> eg. on x86-64 sizeof(swp_entry_t) = 8.  This causes swsusp to skip some pagedir
> pages while reading the image if there are too many of them (depending on the
> architecture, approx. 500 on x86-64).

Last time I did the math, swsusp_info could cover a *lot* of
memory. It was wrong not to check for overflow, but I do not think we
want to introduce *yet another* linklist.

Lets see...

for i386, we have 768 pagedir entries. Each pagedir entry points to
page with 1023 pointers to pages. That means that up-to 768*1023*4096
bytes image can be saved to swap ~= 768 * 1K * 4K ~= 3 GB. That's more
than enough for i386.

for x86-64, we can have 128 pagedir entries (could not we fit more
there? 384 entries should fit, no?). Each pagedir entry has 511
pointers to pages (IIRC)... that is up-to 128*511*4K ~= 64*1K*4K = 256
MB image. Hmm, that should still be enough for any 512MB machine, and
probably okay for much bigger machines, too...

We can still get to 768 MB image (good enough for any 1.5GB machine,
and probably for anything else, too).

If that is not good enough for you, can you simply allocate more than
1 page for swsusp_info? No need for linklists yet.

Andrew, please drop this one. It is too complex solution for quite a
simple problem.
								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address

  reply	other threads:[~2005-09-26 10:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-25 18:18 [PATCH 0/3] swsusp: fix some obscure bugs Rafael J. Wysocki
2005-09-25 18:24 ` [PATCH 1/3][Fix] swsusp: remove wrong code from data_free Rafael J. Wysocki
2005-09-25 18:30 ` [PATCH 2/3][Fix] swsusp: prevent possible memory leak Rafael J. Wysocki
2005-09-25 18:44 ` [PATCH 3/3][Fix] swsusp: prevent swsusp from failing if there's too many pagedir pages Rafael J. Wysocki
2005-09-26 10:33   ` Pavel Machek [this message]
2005-09-26 11:11     ` Rafael J. Wysocki
2005-09-26 11:20       ` Pavel Machek
2005-09-26 12:54         ` Rafael J. Wysocki
2005-09-26 14:26           ` Pavel Machek
2005-09-26 19:19             ` Rafael J. Wysocki
2005-09-26 23:22               ` Pavel Machek
2005-09-26 19:29             ` [PATCH][Fix] swsusp: avoid problems if there are too many pages to save Rafael J. Wysocki
2005-09-26 23:14               ` Pavel Machek
2005-09-25 21:47 ` [PATCH 0/3] swsusp: fix some obscure bugs Pavel Machek
2005-09-25 21:59   ` Andrew Morton

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=20050926103336.GA3693@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@sisk.pl \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox