From: Pavel Machek <pavel@ucw.cz>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
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: Mon, 31 Oct 2005 00:04:07 +0100 [thread overview]
Message-ID: <20051030230407.GA1655@elf.ucw.cz> (raw)
In-Reply-To: <200510302337.41526.rjw@sisk.pl>
Hi!
> > > 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 ...
Can you elaborate? resume is certainly going to get list of pbes...
> > > 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
Yes, process freezing probably needs to be separate. Suspending
devices can well be part of atomic_snapshot operation; userspace does
not need to care.
> 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 ;-) */
Why, I have it implemented? Just do not freeze the process calling you.
> - sys_create_pagedir
Ugly...
> - 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 */
Exactly. I'd like to go a
> Cleanup: /* certainly something's gone wrong */
> - sys_destroy_pagedir /* that's it */
> - sys_resume_devices
You should not need to do this one. resuming devices is going to be
integrated in atomic_restore, because suspending devices is there, too.
Here's how it looks... additionaly, I have ioctl for getting one
usable page. It is true that I did not solve error paths, yet; I'll
certainly need some way to free memory, too.
Pavel
int
do_resume(void)
{
kmem = open("/dev/kmem", O_RDWR | O_LARGEFILE);
image_fd = open(image, O_RDWR);
if (kmem < 0) {
fprintf(stderr, "Could not open /dev/kmem: %m\n");
return 1;
}
memset(&swsusp_info, 0, sizeof(swsusp_info));
read(image_fd, &swsusp_info, sizeof(swsusp_info));
resume.nr_copy_pages = swsusp_info.nr_copy_pages;
if (strcmp("swsusp3", swsusp_info.signature))
exit(0);
if (lseek(image_fd, 0, SEEK_SET) != 0) {
printf("Could not seek to kill sig: %m\n");
exit(1);
}
if (write(image_fd, &zeros, sizeof(swsusp_info)) != sizeof(swsusp_info)) {
printf("Could not write to kill sig: %m\n");
exit(1);
}
if (fsync(image_fd)) {
printf("Could not fsync to kill sig: %m\n");
exit(1);
}
printf("Got image, %d pages, signature [%s]\n", resume.nr_copy_pages, swsusp_info.signature);
alloc_pagedir(resume.nr_copy_pages);
printf("Verifying allocated pagedir: %d pages\n", walk_chain(&resume, NULL));
printf("swsusp: Reading pagedir ");
walk_pages_chain(&resume, (void *) read_pagedir_one);
printf("ok\n");
/* Need to be done twice; so that forbidden_pages comes into effect */
alloc_pagedir(resume.nr_copy_pages);
printf("Verifying allocated pagedir: %d pages\n", walk_chain(&resume, NULL));
printf("swsusp: Reading pagedir ");
walk_pages_chain(&resume, (void *) read_pagedir_one);
printf("ok\n");
printf("Verifying allocated pagedir: %d pages\n", walk_chain(&resume, NULL));
/* FIXME: Need to relocate pages */
mod = swsusp_info.nr_copy_pages / 100;
if (!mod)
mod = 1;
printf("swsusp: Reading image data (%d pages): ",
swsusp_info.nr_copy_pages);
walk_chain(&resume, data_read_one);
printf("\b\b\b\bdone\n");
if (ioctl(kmem, IOCTL_FREEZE, 0)) {
fprintf(stderr, "Could not freeze system: %m\n");
return 1;
}
if (ioctl(kmem, IOCTL_ATOMIC_RESTORE, &resume)) {
fprintf(stderr, "Could not restore system: %m\n");
}
/* Ouch, at this point we'll appear in ATOMIC_SNAPSHOT syscall, if
things went ok... */
return 0;
}
--
Thanks, Sharp!
next prev parent reply other threads:[~2005-10-30 23:04 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
2005-10-30 23:04 ` Pavel Machek [this message]
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=20051030230407.GA1655@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