public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Pavel Machek <pavel@suse.cz>
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: Sun, 30 Oct 2005 22:16:16 +0100	[thread overview]
Message-ID: <200510302216.17413.rjw@sisk.pl> (raw)
In-Reply-To: <20051030195254.GA1729@openzaurus.ucw.cz>

Hi,

On Sunday, 30 of October 2005 20:52, Pavel Machek wrote:
> Hi!
> 
> > This patch moves the snapshot-handling functions remaining in swsusp.c
> > to snapshot.c (ie. it moves the code without changing the functionality).
> >
> I'm sorry, but I acked this one too quickly. I'd prefer to keep "relocate" code where
> it is, and define "must not collide" as a part of interface.

That's doable, but frankly I don't like the idea.

> That will keep snapshot.c smaller/simpler, and I plan to
> eventually put responsibility for relocation to userspace.

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.

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.

> That should simplify error handling at least: data structures
> needed for relocation can be kept in userspace memory,

Well, after the patches that are already in -mm we don't use any additional
data structures for this purpose, so that's not a problem, I think. ;-)

> and therefore we do not risk memory leak in case something goes wrong.

We don't.  All memory allocated with either get_image_page() or
get_safe_page() will eventually be released by swsusp_free(), no matter
what happens.

Greetings,
Rafael

  reply	other threads:[~2005-10-30 21:15 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 [this message]
2005-10-30 21:28       ` Pavel Machek
2005-10-30 22:37         ` Rafael J. Wysocki
2005-10-30 23:04           ` Pavel Machek
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=200510302216.17413.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    /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