From: Pavel Machek <pavel@suse.cz>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFC] Add support to resume swsusp from initrd
Date: Tue, 7 Dec 2004 10:44:39 +0100 [thread overview]
Message-ID: <20041207094439.GC1469@elf.ucw.cz> (raw)
In-Reply-To: <1102374924.13483.9.camel@tyrosine>
Ahoj!
> Ok, how does this one look? (applies on top of the __init patch from
> last time)
It looks way better than last time :-).
> resume_device has been renamed to swsusp_resume_device to avoid
> confusion with the resume_device function in drivers/power. If a resume
> device has been set, it's assumed that userspace has been started. If
> not, it behaves as before. name_to_dev_t is only called if userspace
> hasn't been started - otherwise, we depend on the values provided by
> userspace being correct. If userspace has been started, we freeze tasks
> and free memory before starting the resume. If this looks ok, I'll merge
> it to your changes after 2.6.10.
Ugh, we probably should always stop tasks and always free memory. To
get code paths tested etc.
> @@ -28,7 +29,7 @@
> extern int swsusp_read(void);
> extern int swsusp_resume(void);
> extern int swsusp_free(void);
> -
> +extern dev_t swsusp_resume_device;
>
> static int noresume = 0;
> char resume_file[256] = CONFIG_PM_STD_PARTITION;
Move it to include/linux/suspend.h
> @@ -223,6 +224,18 @@
>
> pr_debug("PM: Reading pmdisk image.\n");
>
> + if (swsusp_resume_device) {
> + /* We want to be really sure that userspace isn't touching
> + anything at this point... */
> + if (freeze_processes()) {
> + goto Done;
> + }
> +
> + /* And then make sure that we have enough memory to do the
> + resume */
> + free_some_memory();
> + }
> +
> if ((error = swsusp_read()))
> goto Done;
>
This should not be conditional.
> @@ -327,8 +340,42 @@
>
> power_attr(disk);
>
> +static ssize_t resume_show(struct subsystem * subsys, char * buf) {
> + return sprintf(buf,"%d:%d\n", MAJOR(swsusp_resume_device),
> + MINOR(swsusp_resume_device));
> +}
> +
> +static ssize_t resume_store(struct subsystem * s, const char * buf, size_t n)
> +{
> + int error = 0;
> + int len;
> + char *p;
> + unsigned maj, min;
> + dev_t (res);
Why the ()s?
> + p = memchr(buf, '\n', n);
> + len = p ? p - buf : n;
> +
> + if (sscanf(buf, "%u:%u", &maj, &min) == 2) {
> + res = MKDEV(maj, min);
> + if (maj == MAJOR(res) && min == MINOR(res)) {
You mkdev, than test that MKDEV worked? Could you add a comment why
its needed?
I'd write it as "if (sscanf ... !=2) return -EINVAL". If (MKDEV is
broken) return -EINVAL, but Andrew would hate me then.
> @@ -1220,13 +1220,16 @@
> {
> int error;
>
> - if (!strlen(resume_file))
> - return -ENOENT;
> + if (!swsusp_resume_device) {
> + if (!strlen(resume_file))
> + return -ENOENT;
>
> - resume_device = name_to_dev_t(resume_file);
> - pr_debug("swsusp: Resume From Partition: %s\n", resume_file);
> + swsusp_resume_device = name_to_dev_t(resume_file);
> + pr_debug("swsusp: Resume From Partition: %s\n", resume_file);
> + }
So... if userspace echos "0:0" into resume file, you attempt to do the
resume, and oops the kernel? Why not doing name_to_dev_t,
unconditionally, while doing resume_setup? And probably kill
CONFIG_PM_STD_PARTITION; I do not like idea of kernel automagically
trying to resume without anything on command line anyway.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
next prev parent reply other threads:[~2004-12-07 9:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-05 20:48 [PATCH/RFC] Add support to resume swsusp from initrd Matthew Garrett
2004-12-05 21:12 ` Pavel Machek
2004-12-05 21:21 ` Matthew Garrett
2004-12-05 21:29 ` Pavel Machek
2004-12-05 21:42 ` Matthew Garrett
2004-12-05 21:49 ` Pavel Machek
2004-12-06 10:02 ` Stefan Seyfried
2004-12-05 21:18 ` Pavel Machek
2004-12-06 23:15 ` Matthew Garrett
2004-12-07 9:44 ` Pavel Machek [this message]
2004-12-07 11:39 ` Matthew Garrett
2004-12-07 11:46 ` Pavel Machek
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=20041207094439.GC1469@elf.ucw.cz \
--to=pavel@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
/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