From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Pavel Machek <pavel@ucw.cz>
Cc: Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] swsusp: move snapshot-handling functions to snapshot.c
Date: Sun, 30 Oct 2005 23:37:41 +0100 [thread overview]
Message-ID: <200510302337.41526.rjw@sisk.pl> (raw)
In-Reply-To: <20051030212832.GB19284@elf.ucw.cz>
Hi,
On Sunday, 30 of October 2005 22:28, Pavel Machek wrote:
> Hi!
}-- snip --{
> > Please note that the relocating code uses the page flags to mark the allocated
> > pages as well as to avoid the pages that should not be used. In my opinion
> > no userspace process should be allowed to fiddle with the page
> > flags.
>
> Of course, userspace would have to use separate data structure. [Hash table?]
IMO a bitmap could be used. Anyway in that case the x86-64 arch code
would need to have access either to this structure or to the image metadata,
because it must figure out which pages are not safe. I don't see any simple
way of making this work ...
> > Moreover, get_safe_page() is called directly by the arch code on x86-64,
> > so it has to stay in the kernel and hence it should be in snapshot.c.
> > OTOH the relocating code is nothing more than "if the page is not safe,
> > use get_safe_page() to allocate one" kind of thing, so I don't see a point
> > in taking it out of the kernel (in the future) too.
>
> Well... for resume. If userspace does the allocation, it is:
>
> userspace reads image
> userspace relocates it
> sys_atomic_restore(image)
> if something goes wrong, userspace is clearly responsible for freeing
> it.
>
> How would you propose kernel<->user interface?
>
> userspace reads pagedir
> sys_these_pages_are_forbidden(pagedir)
> userspace reads rest
> sys_atomic_restore(image)
> if something goes wrong, userspace must dealocate pages _and_ clear
> forbidden flags?
Well, you have taken these things out of context. Namely, the userspace
process cannot freeze the other tasks, suspend devices etc., so it has to
call the kernel for these purposes anyway. Of course if something goes
wrong it has to call the kernel to revert these steps too. Similarly it
can call the kernel to allocate the image memory and to free it in case
something's wrong. For example, if the userspace initiates the resume:
- if (image not found)
exit
- sys_freeze_processes /* this one will be tricky ;-) */
- sys_create_pagedir
- while (image data) {
sys_put_this_stuff_where_appropriate(image data);
/* Here the kernel will do the relocation etc. if necessary */
if (something's wrong)
goto Cleanup; }
- sys_atomic_restore /* suspend devices, disable IRQs, restore */
Cleanup: /* certainly something's gone wrong */
- sys_destroy_pagedir /* that's it */
- sys_resume_devices
- sys_thaw_processes
> > > That should simplify error handling at least: data structures
> > > needed for relocation can be kept in userspace memory,
> >
> > Well, after the patches that are already in -mm we don't use any additional
> > data structures for this purpose, so that's not a problem, I
> > think. ;-)
>
> Until someone will want to get page flag bits back ;-), ok.
In that case we'll have to redesign the snapshot part top-down anyway.
Greetings,
Rafael
next prev parent reply other threads:[~2005-10-30 22:37 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-30 15:37 [PATCH 0/3] swsusp: code separation continued Rafael J. Wysocki
2005-10-30 15:40 ` [PATCH 1/3] swsusp: rework swsusp_suspend Rafael J. Wysocki
2005-10-30 17:54 ` Ingo Oeser
2005-10-30 21:18 ` Rafael J. Wysocki
2005-10-30 15:44 ` [PATCH 2/3] swsusp: move snapshot-handling functions to snapshot.c Rafael J. Wysocki
2005-10-30 19:52 ` Pavel Machek
2005-10-30 21:16 ` Rafael J. Wysocki
2005-10-30 21:28 ` Pavel Machek
2005-10-30 22:37 ` Rafael J. Wysocki [this message]
2005-10-30 23:04 ` Pavel Machek
2005-10-31 0:35 ` Rafael J. Wysocki
2005-10-31 21:59 ` Pavel Machek
2005-11-01 18:29 ` Rafael J. Wysocki
2005-11-01 21:04 ` Pavel Machek
2005-11-01 23:53 ` Rafael J. Wysocki
2005-11-02 21:08 ` Pavel Machek
2005-10-31 19:36 ` Rafael J. Wysocki
2005-10-31 22:02 ` Pavel Machek
2005-11-01 12:57 ` Rafael J. Wysocki
2005-11-01 17:33 ` [PATCH 1/2] swsusp: reduce code duplication (was: Re: [PATCH 2/3] swsusp: move snapshot-handling functions to snapshot.c) Rafael J. Wysocki
2005-11-01 17:37 ` [PATCH 2/2] swsusp: simplify pagedir relocation Rafael J. Wysocki
2005-11-01 21:11 ` Pavel Machek
2005-11-01 23:15 ` Rafael J. Wysocki
2005-11-01 21:09 ` [PATCH 1/2] swsusp: reduce code duplication (was: Re: [PATCH 2/3] swsusp: move snapshot-handling functions to snapshot.c) Pavel Machek
2005-10-30 15:48 ` [PATCH 3/3] swsusp: move swap check out of swsusp_suspend Rafael J. Wysocki
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=200510302337.41526.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
/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