This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: xenpm fail

On Fri, 2010-10-29 at 09:32 +0100, Zhang, Yang Z wrote:
> Hi ian
> I find Cs 22292 cause xenpm broken. When run "xenpm start" or "xenpm
> get-cpuidle-states" and other xenmpm command, it will get segment
> fault. 
> After do some investigation, I find call xc_pm_get_cxstat() will free
> the cxstat->tiggers, 
> For example:
> Here is some code form my test.c.
> struct xc_cx_stat cxstatinfo, *cxstat = &cxstatinfo;
> cxstat->triggers = malloc(max_cx_num * sizeof(uint64_t)); 
> if ( !cxstat->triggers ) {
>       printf("get memory fail");
>       return NOMEM;
> }
> ret = xc_pm_get_cxstat(xc_handle, cpu, cxstat);

what is ret at this point?

> printf("triggers=%lx \n", cxstat->triggers[0]);
> Run it, and it will show segment fault at print the cxtat->tiggers[0].
> It seems that xc_pm_get_cxstat() will free cxstat->triggers which we
> allocate memory before, and then when try to touch cxstat->tiggers[0],
> the issue raised.

I can't see any code which frees cxstat->triggers in xc_pm_get_cxstat,
there is only code which frees the bounce buffer.

Perhaps the issue you are seeing is with get_cxstat_by_cpuid from
xenpm.c rather than xc_pm_get_cxstat directly? I notice that
get_cxstat_by_cpuid is called on one occasion without checking the
return code and that it frees the trigger array when xc_pm_get_cxstat
fails so a new failure introduced by 22292 could cause this?

What hardware is this on? What is max_cx_num and max_cpu_nr for you?

> If remove the patch 22292, everything is ok.
> best regards
> yang

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>