lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5632059.07cB6QdEcB@vostro.rjw.lan>
Date:	Mon, 24 Jun 2013 02:40:22 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Jiang Liu <liuj97@...il.com>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"Alexander E . Patrakov" <patrakov@...il.com>,
	Jiang Liu <jiang.liu@...wei.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Yijing Wang <wangyijing@...wei.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Update][PATCH 3/3] ACPI / dock / PCI: Synchronous handling of dock events for PCI devices

On Sunday, June 23, 2013 04:04:52 PM Yinghai Lu wrote:
> On Sun, Jun 23, 2013 at 2:42 PM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> > On Sunday, June 23, 2013 01:29:19 PM Yinghai Lu wrote:
> >> On Sun, Jun 23, 2013 at 12:57 PM, Yinghai Lu <yinghai@...nel.org> wrote:
> >> > On Sun, Jun 23, 2013 at 8:54 AM, Jiang Liu <liuj97@...il.com> wrote:
> >> >> On 06/23/2013 05:25 AM, Rafael J. Wysocki wrote:
> >> >>> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >> >>>
> >> >>> The interactions between the ACPI dock driver and the ACPI-based PCI
> >> >>> hotplug (acpiphp) are currently problematic because of ordering
> >> >>> issues during hot-remove operations.
> >> >>>
> >> >>> First of all, the current ACPI glue code expects that physical
> >> >>> devices will always be deleted before deleting the companion ACPI
> >> >>> device objects.  Otherwise, acpi_unbind_one() will fail with a
> >> >>> warning message printed to the kernel log, for example:
> >> >>>
> >> >>> [  185.026073] usb usb5: Oops, 'acpi_handle' corrupt
> >> >>> [  185.035150] pci 0000:1b:00.0: Oops, 'acpi_handle' corrupt
> >> >>> [  185.035515] pci 0000:18:02.0: Oops, 'acpi_handle' corrupt
> >> >>> [  180.013656]  port1: Oops, 'acpi_handle' corrupt
> >> >>>
> >> >> [...]
> >> >>> @@ -597,15 +654,11 @@ register_hotplug_dock_device(acpi_handle
> >> >>>                * ops
> >> >>>                */
> >> >>>               dd = find_dock_dependent_device(dock_station, handle);
> >> >>> -             if (dd) {
> >> >>> -                     dd->ops = ops;
> >> >>> -                     dd->context = context;
> >> >>> -                     dock_add_hotplug_device(dock_station, dd);
> >> >>> -                     ret = 0;
> >> >>> -             }
> >> >>> +             if (dd)
> >> >>> +                     return dock_init_hotplug(dd, ops, context,
> >> >>> +                                              init, release);
> >> >> Hi Rafael,
> >> >>         Seems not an equivalent change. According to the comment just above the
> >> >> code, we shouldn't return but continue here.
> >> >> /*
> >> >>  * An ATA bay can be in a dock and itself can be ejected
> >> >>  * separately, so there are two 'dock stations' which need the
> >> >>  * ops
> >> >>  */
> >> >
> >> > two dock stations:
> >> > Do you mean two dock station has same handle?
> >> >
> >> > dock_add should add correctly flags for IS_DOCK and IS_ATA.
> >> > if one handle has _DCK and _GTF etc.
> >> >
> >> > or do you mean there are two dependent devices with same handle?
> >> > like one is for acpiphp slot and one is for ATA?
> >>
> >> related commit:
> >> commit 61b836958371c717d1e6d4fea1d2c512969ad20b
> >> Author: Shaohua Li <shaohua.li@...el.com>
> >> Date:   Thu Aug 28 10:07:14 2008 +0800
> >>
> >>     dock: fix for ATA bay in a dock station
> >>
> >>     an ATA bay can be in a dock and itself can be ejected separately.
> >>     This patch handles such eject bay. Found by Holger.
> >>
> >>     Signed-off-by: Shaohua Li <shaohua.li@...el.com>
> >>     Signed-off-by: Len Brown <len.brown@...el.com>
> >> @@ -618,16 +619,21 @@ register_hotplug_dock_device(acpi_handle handle, struct ac
> >> pi_dock_ops *ops,
> >>          * this would include the dock station itself
> >>          */
> >>         list_for_each_entry(dock_station, &dock_stations, sibiling) {
> >> +               /*
> >> +                * An ATA bay can be in a dock and itself can be ejected
> >> +                * seperately, so there are two 'dock stations' which need the
> >> +                * ops
> >> +                */
> >>                 dd = find_dock_dependent_device(dock_station, handle);
> >>                 if (dd) {
> >>                         dd->ops = ops;
> >>                         dd->context = context;
> >>                         dock_add_hotplug_device(dock_station, dd);
> >> -                       return 0;
> >> +                       ret = 0;
> >>                 }
> >>         }
> >>
> >> -       return -EINVAL;
> >> +       return ret;
> >>  }
> >>
> >> so two doc station with different handle.
> >>
> >> and dependent devices in both...
> >>
> >> looks like Rafael's change can not handle this case anymore.
> >
> > Ah, I overlooked the fact that each dock station is on its own dependent_list
> > and can also be on another dock station's dependent_list.  I'm not sure if that
> > makes sense, but let's not break the backwards compatibility here.
> 
> wonder if dock_release_hotplug with second dock_station and dd will
> have problem.
> 
> as first one dock_station/dd, could have hp_context release already,
> then second one could all release(context) again....
> 
> so looks like dock_release_hotplug should go over dock_station/dd list
> to clear hp_context in other dock_station/... if they are the same?

I'm not sure what you mean.  They are different dependent_device objects
and each of them has its own context pointer, although they both will point to
the same thing.

Both "init" and "release" will be called for each of them individually which
for for acpiphp (which is the only user of that ATM) actually means "get" and
"put", so it should be OK.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ