[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 |