|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] [v3] libxl: Add API to retrieve domain console tty
Ian Campbell writes ("Re: [PATCH] [v3] libxl: Add API to retrieve domain
console tty"):
> On Fri, 2012-06-01 at 08:21 +0100, Bamvor Jian Zhang wrote:
> > BUT, NOT update strdup to libxl__strdup. bacause libxl__strdup(0,
> > tty) will lead to null pointer access in CTX maco.
>
> I haven't looked at the rest of the patch you but thought I'd pick up on
> this now since we have at least one existing libxl__strdup(0, ..) in
> b_info->blkdev_start = libxl__strdup(0, "xvda");
>
> so we need to decide what to do in general. libxl__strdup wants the CTX
> so it can complain via the logs on malloc failure.
Damn. I shouldn't have let you talk me into adding the extra
ctx-based logging, evidently. I had forgotten the reason for the lack
of that. (Because it was in the next patch.)
> This looks like a problem even with the functions which take a
> "gc_opt" (i.e. where gc==NULL is explicitly supposed to be allowed).
Yes.
> libxl__alloc_failed() could take a gc_opt instead of a ctx and only log
> if it is non-null. It already also logs via stderr, since this is a
> catastrophic failure from which we won't return.
Yes.
> We could also have a process-global libxl_alloc_failure_hook(const char
> *argh) to allow the calling application to have some chance to log via
> its own routines...
Yes.
> IanJ -- you added all this, what do you think?
I think the above is a good proposal.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |