[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.