From: Alex Vainman <alexonlists-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Roland Dreier <rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
Cc: alexv-smomgflXvOZWk0Htik3J/w@public.gmane.org,
roland <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] libibverbs: Undo changes in memory range tree when madvise() fails
Date: Sun, 17 Jan 2010 10:15:41 +0200 [thread overview]
Message-ID: <4B52C72D.1000708@gmail.com> (raw)
In-Reply-To: <adad41bi4g5.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
Hi Roland,
Thanks for the review.
I would break the patch as you requested and make the changes
according to your comments.
Currently I am working on another assignment, so I would send
you the fixed patches till the beginning of the next week.
Thanks,
AlexV
Roland Dreier Wrote:
> This looks pretty good overall -- thanks for taking this on, I've been
> meaning to fix this for a long time, but never got around to it.
>
> However, I'm having a bit of a hard time following the cleanups vs. real
> changes in this patch -- could you break it up into (at least) two
> steps? ie one patch that just factors code out into merge_ranges()
> etc. and then a second patch that makes the fixes for handling madvise
> failures? I think that would make the second patch much easier to
> understand. And if you can split the second patch further, that might
> make it even easier to review.
>
> Also some specific comments:
>
> > +static struct ibv_mem_node *merge_ranges(struct ibv_mem_node *node,
> > + struct ibv_mem_node *prev)
> > +{
> > + struct ibv_mem_node *new_node = NULL;
> > +
> > + prev->end = node->end;
> > + prev->refcnt = node->refcnt;
> > + __mm_remove(node);
> > + new_node = prev;
> > +
> > + return new_node;
> > +}
>
> why do you have the new_node variable at all? why can't this just be
> written as:
>
> +static struct ibv_mem_node *merge_ranges(struct ibv_mem_node *node,
> + struct ibv_mem_node *prev)
> +{
> + prev->end = node->end;
> + prev->refcnt = node->refcnt;
> + __mm_remove(node);
> + return prev;
> +}
>
> > + else{
>
> should be a space after the "else" -- please make sure all the
> trivial formatting is OK.
>
> > + /*
> > + * This condition can be true only if we merged node which begins at start
> > + * and ends at node->end with previous node which begins at node->start
> > + * and ends at start - 1
> > + */
>
> these and a few other comments make pretty long lines for no really good
> reason -- please try to end comments before, say, column 75.
>
> > + uintptr_t *p_end,
> > + int *p_inc,
> > + int *p_advice)
>
> I prefer not to use hungarian notation for variable names.
>
> > + node = prepare_to_roll_back(node, start, &end, &inc, &advice);
>
> I'm OK with lines over 80 characters, but 110 is a bit too
> much... please try to split the function up a bit so this isn't indented
> by 6 tabs. (This over-long line is a symptom of the fact that things
> are too deeply nested here)
>
> > @@ -568,3 +665,5 @@ int ibv_dofork_range(void *base, size_t size)
> > return 0;
> > }
> > }
> > +
> > +
>
> extra chunk, just get rid of this change.
>
> Thanks,
> Roland
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2010-01-17 8:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-29 16:51 [PATCH] libibverbs: Undo changes in memory range tree when madvise() fails Alex Vainman
[not found] ` <4B12A679.3000800-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-01-15 18:54 ` Roland Dreier
[not found] ` <adad41bi4g5.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2010-01-17 8:15 ` Alex Vainman [this message]
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=4B52C72D.1000708@gmail.com \
--to=alexonlists-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=alexv-smomgflXvOZWk0Htik3J/w@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org \
--cc=rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.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 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.