We are looking at this. It might also help if you could send a full acpidump for the machine. Thanks. > -----Original Message----- > From: João Paulo Rechi Vita [mailto:jprvita@xxxxxxxxx] > Sent: Monday, February 6, 2017 6:46 AM > To: Zheng, Lv <lv.zheng@xxxxxxxxx> > Cc: Moore, Robert <robert.moore@xxxxxxxxx>; Wysocki, Rafael J > <rafael.j.wysocki@xxxxxxxxx>; Len Brown <lenb@xxxxxxxxxx>; Lin Ming > <ming.m.lin@xxxxxxxxx>; linux-acpi@xxxxxxxxxxxxxxx; devel@xxxxxxxxxx; > linux-kernel@xxxxxxxxxxxxxxx; Daniel Drake <drake@xxxxxxxxxxxx>; > linux@xxxxxxxxxxxx; Jo?o Paulo Rechi Vita <jprvita@xxxxxxxxxxxx>; Box, > David E <david.e.box@xxxxxxxxx>; Schmauss, Erik > <erik.schmauss@xxxxxxxxx> > Subject: Re: [PATCH] acpica: Fix double-free in acpi_ns_repair_CID() > > On 5 February 2017 at 20:44, Zheng, Lv <lv.zheng@xxxxxxxxx> wrote: > >> From: Moore, Robert > >> Subject: RE: [PATCH] acpica: Fix double-free in acpi_ns_repair_CID() > >> > >> Here's the sequence of events as I see it: > >> > >> Repair_HID is a standalone function that removes one reference on the > >> incoming object. For simple _HID objects, this in fact deletes the > object. > >> > >> For _CID, all elements of the package are examined. If a repair was > >> made on a _HID within the _CID function, one reference on the > >> original object was removed by Repair_HID. However, since the object > >> is part of a package, it has an extra reference to reflect this fact. > >> Thus, in the case in question, the elements of the package all have > >> at least two references. Repair_HID removes one reference, thus the > extra RemoveReference is needed in Repair_CID to bring the reference > count down to zero actually delete the object (in the typical case where > the object had two references). > >> > > This is not what is happening on this machine. Bellow you can see some > printks I've added in acpi_ns_repair_CID(), right before and after > acpi_ns_repair_HID() is called: > > [ 0.244942] acpi_ns_repair_CID: calling acpi_ns_repair_HID for > element ffff9a67b3a44f30, refcount=1 [\_SB.PCI0.I2C1.TPL1._CID] > [ 0.245072] acpi_ns_repair_CID: returned from acpi_ns_repair_HID > for element ffff9a67b3a44f30, refcount=0 [\_SB.PCI0.I2C1.TPL1._CID] > [ 0.245202] acpi_ns_repair_CID: element was replaced by element_ptr > ffff9a67b3a44828, refcount=1 [\_SB.PCI0.I2C1.TPL1._CID] > > Here we would call > acpi_ut_remove_reference(original_element==ffff9a67b3a44f30), which > already has refcount==0. Maybe there is a refcount increment missing > from somewhere else? > > > Hi, > > > > So if a real problem related to package reference counting is > triggered, the problem should be fixed elsewhere IMO. > > Yes, the real problem is i2c_hid not being probed for the touchpad > device on this platform (sorry, should have added this information to > the commit message as well). What brought me to this unref was following > messages on the kernel log: > > [ 0.317002] ACPI Warning: Obj ffffa00472a445e8, Reference Count is > already zero, cannot decrement > [ 0.317178] (20160422/utdelete-442) > > > See this bug for reference: > > https://bugs.acpica.org/show_bug.cgi?id=1336 > > > > Looks like it could be the same problem, indeed. I'm attaching a kernel > log with acpi.trace_debug_layer=0x10091 acpi.trace_debug_level=0x107FFF > acpi.trace_method_name=_SB.PCI0.I2C1.TPL1._CID > acpi.trace_state=opcode, which is what I was using to investigate the > problem, and the machine's DSDT. Please let me know if there is any > other information I can provide to help clarify this issue. > > Thanks, > > -- > João Paulo Rechi Vita > http://about.me/jprvita ��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
