public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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!

  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