qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 01/47] acpi: introduce AML composer aml_appen


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH v2 01/47] acpi: introduce AML composer aml_append()
Date: Thu, 29 Jan 2015 09:42:28 +0100

On Thu, 29 Jan 2015 15:46:32 +0800
Shannon Zhao <address@hidden> wrote:

> On 2015/1/28 18:00, Igor Mammedov wrote:
> > On Wed, 28 Jan 2015 09:56:26 +0200
> > "Michael S. Tsirkin" <address@hidden> wrote:
> > 
> >>> I've tried redo series with passing alloc list as first argument,
> >>> looks ugly as hell
> >>
> >> I tried too. Not too bad at all. See below:
> >>
> >> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> >> index f66da5d..820504a 100644
> >> --- a/hw/i386/acpi-build.c
> >> +++ b/hw/i386/acpi-build.c
> >> @@ -491,14 +491,14 @@ static void acpi_set_pci_info(void)
> >>      }
> >>  }
> >>  
> >> -static void build_append_pcihp_notify_entry(AcpiAml *method, int slot)
> >> +static void build_append_pcihp_notify_entry(AmlPool *p, AcpiAml *method, 
> >> int slot)
> >>  {
> >> -    AcpiAml if_ctx;
> >> +    AcpiAml *if_ctx;
> >>      int32_t devfn = PCI_DEVFN(slot, 0);
> >>  
> >> -    if_ctx = acpi_if(acpi_and(acpi_arg0(), acpi_int(0x1U << slot)));
> >> -    aml_append(&if_ctx, acpi_notify(acpi_name("S%.02X", devfn), 
> >> acpi_arg1()));
> >> -    aml_append(method, if_ctx);
> >> +    if_ctx = acpi_if(p, acpi_and(p, acpi_arg0(), acpi_int(p, 0x1U << 
> >> slot)));
> >> +    aml_append(p, if_ctx, acpi_notify(p, acpi_name(p, "S%.02X", devfn), 
> >> acpi_arg1(p)));
> >> +    aml_append(p, method, if_ctx);
> >>  }
> >>  
> >>  static void build_append_pci_bus_devices(AcpiAml *parent_scope, PCIBus 
> >> *bus,
> >>
> >> What exactly is the problem?  A tiny bit more verbose but the lifetime
> >> of all objects is now explicit.
> > every usage of aml_foo()/build_append_pcihp_notify_entry() tags along
> > extra pointer which is not really necessary for user to know. If possible
> > user shouldn't care about it and concentrate on composing AML instead.
> > 
> > Whole point of passing AmlPool and record every allocation is to avoid
> > mistakes like:
> > 
> > acpi_if(acpi_and(acpi_arg0(), acpi_int(0x1U << slot)));
> > 
> > and forgetting to assign object returned by call anywhere,
> > it's basically the same as calling malloc() without
> > using result anywhere, however neither libc nor glib
> > force user to pass allocator (in our case garbage collector)
> > in every call that allocates memory. Let's just follow common
> > convention here (#4) where an object is allocated by API call
> > (i.e like object_new(FOO), gtk_widget_foo()).
> > 
> > Hence is suggesting at least to hide AmlPool internally in API
> > without exposing it to user. We can provide for user
> > init/free API to manage internal AmlPool manually, allowing
> > him to select when to do initialization and cleanup.
> > 
> > Claudio, Marcel, Shannon,
> > As the first API users, could you give your feedback on the topic.
> > 
> 
> In my opinion, it's good to make users focused on ACPI table construction 
> through
> auto memory management. And it makes the code clear.
> 
> PS:
> We're talking about use-after-free, like below example. But this example 
> really exist?
> During generating ACPI tables for virt machine, I don't encounter this case.
> 
> For example:
>       aml_append(&a, b);
>       aml_append(&a, b);
Thanks for your reply,

yesterday we've came to a compromise, where API will stay as it is externally
only it will take all AML arguments by pointer. And we would introduce
allocation list internally inside API, User only would need to initialize it
before using API and free it after using API.

> 
> Thanks,
> Shannon
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]