[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH 3/3] savevm: Convert loadvm handlers list to LIS
From: |
Luiz Capitulino |
Subject: |
[Qemu-devel] Re: [PATCH 3/3] savevm: Convert loadvm handlers list to LIST |
Date: |
Mon, 31 Aug 2009 19:27:55 -0300 |
On Tue, 01 Sep 2009 00:08:43 +0200
Juan Quintela <address@hidden> wrote:
> Luiz Capitulino <address@hidden> wrote:
> > On Fri, 28 Aug 2009 22:31:57 +0200
> > Juan Quintela <address@hidden> wrote:
> >
> >>
> >> Signed-off-by: Juan Quintela <address@hidden>
> >> ---
> >> savevm.c | 20 +++++++++++---------
> >> 1 files changed, 11 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/savevm.c b/savevm.c
> >> index baef277..9836c60 100644
> >> --- a/savevm.c
> >> +++ b/savevm.c
> >> @@ -1260,10 +1260,10 @@ static SaveStateEntry *find_se(const char *idstr,
> >> int instance_id)
> >> }
> >>
> >> typedef struct LoadStateEntry {
> >> + LIST_ENTRY(LoadStateEntry) entry;
> >> SaveStateEntry *se;
> >> int section_id;
> >> int version_id;
> >> - struct LoadStateEntry *next;
> >> } LoadStateEntry;
> >>
> >> static int qemu_loadvm_state_v2(QEMUFile *f)
> >> @@ -1309,7 +1309,8 @@ static int qemu_loadvm_state_v2(QEMUFile *f)
> >>
> >> int qemu_loadvm_state(QEMUFile *f)
> >> {
> >> - LoadStateEntry *first_le = NULL;
> >> + LIST_HEAD(, LoadStateEntry) loadvm_handlers;
> >
> > You're missing the initialization here, spot this while
> > testing staging.
>
> I looked at aio.c and guess what :) No LIST_INIT() either.
As we talked by irc, if you are referring to 'aio_handlers' it's
global, so it will be initialized to 0 by the kernel.
> My understanding is that it is not needed (but it is better to add it,
> just in case the implementation change).
I'm getting a segfault when I try to loadvm, I can write a recipe
to reproduce if needed.
> #define LIST_HEAD_INITIALIZER(head) \
> { NULL }
>
> #define LIST_INIT(head) do { \
> (head)->lh_first = NULL; \
> } while (/*CONSTCOND*/0)
>
>
> This should be what it does without puting it. Perhaps we should
> "correct" also the other users?
Yes, IMHO. Not because it's a fix, but it's good practice to use the API
w/o making assumptions on its internals.