Re: [Xen-devel] [PATCH] [v3] libxl: Add API to retrieve domain console tty

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-06-01 at 11:37 +0100, Ian Jackson wrote:
> 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.

Who's going to do it then ;-)

(FWIW I think libxl_alloc_failure_hook is an optional nice to have)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel