public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@gmail.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Jiri Slaby <jslaby@suse.cz>,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linux-pm mailing list <linux-pm@lists.linux-foundation.org>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	Len Brown <lenb@kernel.org>
Subject: Re: [PATCH 1/1] PM: fix oops in suspend/hibernate code
Date: Thu, 06 Jan 2011 17:09:39 +0100	[thread overview]
Message-ID: <4D25E943.804@gmail.com> (raw)
In-Reply-To: <201101061657.39723.rjw@sisk.pl>

On 01/06/2011 04:57 PM, Rafael J. Wysocki wrote:
> On Thursday, January 06, 2011, Jiri Slaby wrote:
>> When ioremap fails (which might happen for some reason),
> 
> If it happens, something is seriously wrong (see below).

I agree that something is broken, however ioremap may fail for dozen of
reasons. Ignoring the retval is a *bad* idea and it took me a while to
sort out what is wrong. Especially if one has no console like throughout
suspend. If it was handled properly, I would know immediately. (There
should be a message printed out which I forgot to add.)

> BTW, to keep things in context, please post fixes like this in the same thread
> in which you reported the problem.  At lease please retain the CC list from
> there.

I actually did, there is:
In-Reply-To: <201101060028.43342.rjw@sisk.pl>
and it successfully threaded to the conversation for me in TB.

>> we nicely oops in suspend_nvs_save due to NULL dereference by memcpy in
>> there.  Fail gracefully instead.
>>
>> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>> Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
>> ---
>>  drivers/acpi/sleep.c    |    5 ++---
>>  include/linux/suspend.h |    4 ++--
>>  kernel/power/nvs.c      |    8 +++++++-
>>  3 files changed, 11 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
>> index c423231..f94c9a9 100644
>> --- a/drivers/acpi/sleep.c
>> +++ b/drivers/acpi/sleep.c
>> @@ -124,8 +124,7 @@ static int acpi_pm_freeze(void)
>>  static int acpi_pm_pre_suspend(void)
>>  {
>>  	acpi_pm_freeze();
>> -	suspend_nvs_save();
>> -	return 0;
>> +	return suspend_nvs_save();
>>  }
>>  
>>  /**
>> @@ -151,7 +150,7 @@ static int acpi_pm_prepare(void)
>>  {
>>  	int error = __acpi_pm_prepare();
>>  	if (!error)
>> -		acpi_pm_pre_suspend();
>> +		error = acpi_pm_pre_suspend();
>>  
>>  	return error;
>>  }
>> diff --git a/include/linux/suspend.h b/include/linux/suspend.h
>> index c1f4998..3ac2551 100644
>> --- a/include/linux/suspend.h
>> +++ b/include/linux/suspend.h
>> @@ -262,7 +262,7 @@ static inline bool system_entering_hibernation(void) { return false; }
>>  extern int suspend_nvs_register(unsigned long start, unsigned long size);
>>  extern int suspend_nvs_alloc(void);
>>  extern void suspend_nvs_free(void);
>> -extern void suspend_nvs_save(void);
>> +extern int suspend_nvs_save(void);
>>  extern void suspend_nvs_restore(void);
>>  #else /* CONFIG_SUSPEND_NVS */
>>  static inline int suspend_nvs_register(unsigned long a, unsigned long b)
>> @@ -271,7 +271,7 @@ static inline int suspend_nvs_register(unsigned long a, unsigned long b)
>>  }
>>  static inline int suspend_nvs_alloc(void) { return 0; }
>>  static inline void suspend_nvs_free(void) {}
>> -static inline void suspend_nvs_save(void) {}
>> +static inline int suspend_nvs_save(void) {}
>>  static inline void suspend_nvs_restore(void) {}
>>  #endif /* CONFIG_SUSPEND_NVS */
>>  
>> diff --git a/kernel/power/nvs.c b/kernel/power/nvs.c
>> index 1836db6..57c6fab 100644
>> --- a/kernel/power/nvs.c
>> +++ b/kernel/power/nvs.c
>> @@ -105,7 +105,7 @@ int suspend_nvs_alloc(void)
>>  /**
>>   *	suspend_nvs_save - save NVS memory regions
>>   */
>> -void suspend_nvs_save(void)
>> +int suspend_nvs_save(void)
>>  {
>>  	struct nvs_page *entry;
>>  
>> @@ -114,8 +114,14 @@ void suspend_nvs_save(void)
>>  	list_for_each_entry(entry, &nvs_list, node)
>>  		if (entry->data) {
>>  			entry->kaddr = ioremap(entry->phys_start, entry->size);
> 
> I wonder what happens if you simply change the ioremap() here to
> ioremap_nocache() without any other modifications?

ioremap *is* ioremap_nocache on x86. And that's the conflict it
complains about I guess? Don't you mean ioremap_cache?

> It _really_ shouldn't fail here, because the NVS pages are known to be present.

It fails because of conflicting maps as can be seen in the photo. At
least I think so.

regards,
-- 
js

  reply	other threads:[~2011-01-06 16:09 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-24  0:58 mmotm 2010-12-23-16-58 uploaded akpm
2010-12-24 12:15 ` Sedat Dilek
2010-12-24 13:04   ` Andrew Morton
2010-12-24 17:52 ` [PATCH -mmotm] kptr_restrict: fix build when PRINTK not enabled Randy Dunlap
2010-12-27  2:13 ` mmotm 2010-12-23-16-58 uploaded Randy Dunlap
2011-01-04 13:40 ` suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] Jiri Slaby
2011-01-04 16:49   ` Jiri Slaby
2011-01-04 22:57     ` Rafael J. Wysocki
2011-01-05 21:36       ` Jiri Slaby
2011-01-05 22:39         ` Rafael J. Wysocki
2011-01-05 22:46           ` Jiri Slaby
2011-01-05 23:28             ` Rafael J. Wysocki
2011-01-06  9:18               ` [PATCH 1/1] PM: fix oops in suspend/hibernate code Jiri Slaby
2011-01-06  9:31                 ` Jiri Slaby
2011-01-06 15:57                 ` Rafael J. Wysocki
2011-01-06 16:09                   ` Jiri Slaby [this message]
2011-01-06 16:31                     ` Jiri Slaby
2011-01-06 16:38                     ` Rafael J. Wysocki
2011-01-06 21:01                       ` Len Brown
2011-01-06  9:24               ` suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] Jiri Slaby
2011-01-06 15:45                 ` Rafael J. Wysocki
2011-01-06  8:27     ` ia64 build broken " Jiri Slaby
2011-01-06  8:31       ` [PATCH 1/1] ia64: fix build of ioremap_cache Jiri Slaby
2011-01-06 16:03         ` Len Brown
2011-01-06 16:21           ` Jiri Slaby

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=4D25E943.804@gmail.com \
    --to=jirislaby@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=jslaby@suse.cz \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=mjg59@srcf.ucam.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