From: Anisse Astier <anisse@astier.eu> To: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mgorman@suse.de>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, David Rientjes <rientjes@google.com>, Alan Cox <gnomes@lxorguk.ukuu.org.uk>, Linus Torvalds <torvalds@linux-foundation.org>, Peter Zijlstra <peterz@infradead.org>, PaX Team <pageexec@freemail.hu>, Brad Spengler <spender@grsecurity.net>, Kees Cook <keescook@chromium.org>, Andi Kleen <andi@firstfloor.org>, Pavel Machek <pavel@ucw.cz>, Len Brown <len.brown@intel.com>, linux-mm@kvack.org, Linux PM list <linux-pm@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v4 1/3] PM / Hibernate: prepare for SANITIZE_FREED_PAGES Date: Wed, 20 May 2015 13:57:18 +0200 [thread overview] Message-ID: <CALUN=qKYyzxRJNiEN9LC4YuzsQCUdJtc5-q6poGCfCg4791=gg@mail.gmail.com> (raw) In-Reply-To: <1526358.9aMpXL2Hv2@vostro.rjw.lan> On Wed, May 20, 2015 at 1:46 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > On Monday, May 18, 2015 12:23:00 PM Anisse Astier wrote: >> Hi Rafael, >> >> Thanks for taking the time to review this. >> >> On Sat, May 16, 2015 at 2:28 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: >> > On Thursday, May 14, 2015 04:19:46 PM Anisse Astier wrote: >> >> SANITIZE_FREED_PAGES feature relies on having all pages going through >> >> the free_pages_prepare path in order to be cleared before being used. In >> >> the hibernate use case, free pages will automagically appear in the >> >> system without being cleared, left there by the loading kernel. >> >> >> >> This patch will make sure free pages are cleared on resume; when we'll >> >> enable SANITIZE_FREED_PAGES. We free the pages just after resume because >> >> we can't do it later: going through any device resume code might >> >> allocate some memory and invalidate the free pages bitmap. >> >> >> >> Signed-off-by: Anisse Astier <anisse@astier.eu> >> >> --- >> >> kernel/power/hibernate.c | 4 +++- >> >> kernel/power/power.h | 2 ++ >> >> kernel/power/snapshot.c | 22 ++++++++++++++++++++++ >> >> 3 files changed, 27 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c >> >> index 2329daa..0a73126 100644 >> >> --- a/kernel/power/hibernate.c >> >> +++ b/kernel/power/hibernate.c >> >> @@ -305,9 +305,11 @@ static int create_image(int platform_mode) >> >> error); >> >> /* Restore control flow magically appears here */ >> >> restore_processor_state(); >> >> - if (!in_suspend) >> >> + if (!in_suspend) { >> >> events_check_enabled = false; >> >> >> >> + clear_free_pages(); >> > >> > Again, why don't you do that at the swsusp_free() time? >> >> Because it's too late, the kernel has already been through device >> resume code, and the free pages bitmap isn't valid anymore; device >> resume code might allocate memory, and we'd be clearing those pages as >> well. > > Are we both talking about the same thing? I think we aren't talking about the same thing. The free_pages_map is used for all free pages, plus the memory used for suspend (when it intersects with forbidden_page_map). We don't need to clear the memory in swsusp_free, because it already calls the __free_page code path that clears free pages. What we need, is to clear pages left by the loader kernel before it jumped into the resumed kernel. > > swsusp_free() is *the* function that, well, frees all the pages allocated > by the hibernate core, so how isn't the free pages bitmap valid when it is > called? Because swsusp_free will only free the intersection of free_pages_map and forbidden_pages_map. This intersection is the set of pages used for suspend, and they are in fact allocated, not free. The rest of free_pages_map are the real free pages, but as I said, once we resume, it will also include the pages left hanging by the loading kernel. In addition, the free_pages_map contains a reference to all the free pages at the moment of suspend, but this reference isn't valid by the time we reach swsusp_free(), because we've been through many drivers' resume by then, and those can allocate memory; they might even want already zeroed memory, which they won't get because of the __GFP_ZERO optimization in the next patch; we just expect all free pages to be already cleared, but pages from the loading kernel aren't. > > Why don't you add the clearing in there, right at the spot when the pages > are actually freed? > > Moreover, why is the resume code path the only one where freed pages need to > be sanitized? Because all pages in the system go through the page freeing path (which clears them) when leaving the (no)bootmem allocator. It's a bit long, so I hope that I'm clear in my explanation. Regards, Anisse
WARNING: multiple messages have this Message-ID (diff)
From: Anisse Astier <anisse@astier.eu> To: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mgorman@suse.de>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, David Rientjes <rientjes@google.com>, Alan Cox <gnomes@lxorguk.ukuu.org.uk>, Linus Torvalds <torvalds@linux-foundation.org>, Peter Zijlstra <peterz@infradead.org>, PaX Team <pageexec@freemail.hu>, Brad Spengler <spender@grsecurity.net>, Kees Cook <keescook@chromium.org>, Andi Kleen <andi@firstfloor.org>, Pavel Machek <pavel@ucw.cz>, Len Brown <len.brown@intel.com>, linux-mm@kvack.org, Linux PM list <linux-pm@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v4 1/3] PM / Hibernate: prepare for SANITIZE_FREED_PAGES Date: Wed, 20 May 2015 13:57:18 +0200 [thread overview] Message-ID: <CALUN=qKYyzxRJNiEN9LC4YuzsQCUdJtc5-q6poGCfCg4791=gg@mail.gmail.com> (raw) In-Reply-To: <1526358.9aMpXL2Hv2@vostro.rjw.lan> On Wed, May 20, 2015 at 1:46 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > On Monday, May 18, 2015 12:23:00 PM Anisse Astier wrote: >> Hi Rafael, >> >> Thanks for taking the time to review this. >> >> On Sat, May 16, 2015 at 2:28 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: >> > On Thursday, May 14, 2015 04:19:46 PM Anisse Astier wrote: >> >> SANITIZE_FREED_PAGES feature relies on having all pages going through >> >> the free_pages_prepare path in order to be cleared before being used. In >> >> the hibernate use case, free pages will automagically appear in the >> >> system without being cleared, left there by the loading kernel. >> >> >> >> This patch will make sure free pages are cleared on resume; when we'll >> >> enable SANITIZE_FREED_PAGES. We free the pages just after resume because >> >> we can't do it later: going through any device resume code might >> >> allocate some memory and invalidate the free pages bitmap. >> >> >> >> Signed-off-by: Anisse Astier <anisse@astier.eu> >> >> --- >> >> kernel/power/hibernate.c | 4 +++- >> >> kernel/power/power.h | 2 ++ >> >> kernel/power/snapshot.c | 22 ++++++++++++++++++++++ >> >> 3 files changed, 27 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c >> >> index 2329daa..0a73126 100644 >> >> --- a/kernel/power/hibernate.c >> >> +++ b/kernel/power/hibernate.c >> >> @@ -305,9 +305,11 @@ static int create_image(int platform_mode) >> >> error); >> >> /* Restore control flow magically appears here */ >> >> restore_processor_state(); >> >> - if (!in_suspend) >> >> + if (!in_suspend) { >> >> events_check_enabled = false; >> >> >> >> + clear_free_pages(); >> > >> > Again, why don't you do that at the swsusp_free() time? >> >> Because it's too late, the kernel has already been through device >> resume code, and the free pages bitmap isn't valid anymore; device >> resume code might allocate memory, and we'd be clearing those pages as >> well. > > Are we both talking about the same thing? I think we aren't talking about the same thing. The free_pages_map is used for all free pages, plus the memory used for suspend (when it intersects with forbidden_page_map). We don't need to clear the memory in swsusp_free, because it already calls the __free_page code path that clears free pages. What we need, is to clear pages left by the loader kernel before it jumped into the resumed kernel. > > swsusp_free() is *the* function that, well, frees all the pages allocated > by the hibernate core, so how isn't the free pages bitmap valid when it is > called? Because swsusp_free will only free the intersection of free_pages_map and forbidden_pages_map. This intersection is the set of pages used for suspend, and they are in fact allocated, not free. The rest of free_pages_map are the real free pages, but as I said, once we resume, it will also include the pages left hanging by the loading kernel. In addition, the free_pages_map contains a reference to all the free pages at the moment of suspend, but this reference isn't valid by the time we reach swsusp_free(), because we've been through many drivers' resume by then, and those can allocate memory; they might even want already zeroed memory, which they won't get because of the __GFP_ZERO optimization in the next patch; we just expect all free pages to be already cleared, but pages from the loading kernel aren't. > > Why don't you add the clearing in there, right at the spot when the pages > are actually freed? > > Moreover, why is the resume code path the only one where freed pages need to > be sanitized? Because all pages in the system go through the page freeing path (which clears them) when leaving the (no)bootmem allocator. It's a bit long, so I hope that I'm clear in my explanation. Regards, Anisse -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-05-20 11:57 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-05-14 14:19 [PATCH v4 0/3] Sanitizing freed pages Anisse Astier 2015-05-14 14:19 ` Anisse Astier 2015-05-14 14:19 ` Anisse Astier 2015-05-14 14:19 ` [PATCH v4 1/3] PM / Hibernate: prepare for SANITIZE_FREED_PAGES Anisse Astier 2015-05-14 14:19 ` Anisse Astier 2015-05-16 0:28 ` Rafael J. Wysocki 2015-05-16 0:28 ` Rafael J. Wysocki 2015-05-18 10:23 ` Anisse Astier 2015-05-18 10:23 ` Anisse Astier 2015-05-19 23:46 ` Rafael J. Wysocki 2015-05-19 23:46 ` Rafael J. Wysocki 2015-05-20 11:45 ` PaX Team 2015-05-20 11:45 ` PaX Team 2015-05-20 12:07 ` Anisse Astier 2015-05-20 12:07 ` Anisse Astier 2015-05-21 1:11 ` Rafael J. Wysocki 2015-05-21 1:11 ` Rafael J. Wysocki 2015-05-20 11:57 ` Anisse Astier [this message] 2015-05-20 11:57 ` Anisse Astier 2015-05-14 14:19 ` [PATCH v4 2/3] mm/page_alloc.c: add config option to sanitize freed pages Anisse Astier 2015-05-14 14:19 ` Anisse Astier 2015-05-18 11:21 ` Pavel Machek 2015-05-18 11:21 ` Pavel Machek 2015-05-18 12:41 ` Anisse Astier 2015-05-18 12:41 ` Anisse Astier 2015-05-18 13:02 ` Pavel Machek 2015-05-18 13:02 ` Pavel Machek 2015-05-18 13:04 ` Anisse Astier 2015-05-18 13:04 ` Anisse Astier 2015-05-19 1:58 ` yalin wang 2015-05-20 12:27 ` Anisse Astier 2015-05-20 12:27 ` Anisse Astier 2015-05-14 14:19 ` [PATCH v4 3/3] mm: Add debug code for SANITIZE_FREED_PAGES Anisse Astier 2015-05-14 14:19 ` Anisse Astier 2015-05-19 12:46 ` [PATCH v4 0/3] Sanitizing freed pages Mel Gorman 2015-05-19 12:46 ` Mel Gorman 2015-05-19 13:35 ` One Thousand Gnomes 2015-05-19 13:35 ` One Thousand Gnomes 2015-05-19 13:56 ` Mel Gorman 2015-05-19 13:56 ` Mel Gorman 2015-05-19 20:59 ` PaX Team 2015-05-19 20:59 ` PaX Team 2015-05-20 12:24 ` Anisse Astier 2015-05-20 12:24 ` Anisse Astier
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='CALUN=qKYyzxRJNiEN9LC4YuzsQCUdJtc5-q6poGCfCg4791=gg@mail.gmail.com' \ --to=anisse@astier.eu \ --cc=akpm@linux-foundation.org \ --cc=andi@firstfloor.org \ --cc=gnomes@lxorguk.ukuu.org.uk \ --cc=keescook@chromium.org \ --cc=kirill.shutemov@linux.intel.com \ --cc=len.brown@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-pm@vger.kernel.org \ --cc=mgorman@suse.de \ --cc=pageexec@freemail.hu \ --cc=pavel@ucw.cz \ --cc=peterz@infradead.org \ --cc=rientjes@google.com \ --cc=rjw@rjwysocki.net \ --cc=spender@grsecurity.net \ --cc=torvalds@linux-foundation.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.