From: Toshi Kani <toshi.kani@hp.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linux-acpi@vger.kernel.org,
Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>,
Wen Congyang <wency@cn.fujitsu.com>,
Wen Congyang <wencongyang@gmail.com>,
isimatu.yasuaki@jp.fujitsu.com, lenb@kernel.org,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [RFC PATCH v3 3/3] acpi_memhotplug: Allow eject to proceed on rebind scenario
Date: Thu, 29 Nov 2012 09:43:17 -0700 [thread overview]
Message-ID: <1354207397.26955.417.camel@misato.fc.hp.com> (raw)
In-Reply-To: <2315811.arm7RJr4ey@vostro.rjw.lan>
On Thu, 2012-11-29 at 11:03 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 28, 2012 06:15:42 PM Toshi Kani wrote:
> > On Wed, 2012-11-28 at 18:02 -0700, Toshi Kani wrote:
> > > On Thu, 2012-11-29 at 00:49 +0100, Rafael J. Wysocki wrote:
> > > > On Wednesday, November 28, 2012 02:02:48 PM Toshi Kani wrote:
> > > > If we disabled exposing
> > > > acpi_eject_store() for memory devices, then the only way would be from the
> > > > notify handler. So I wonder if driver_unbind() shouldn't just uninstall the
> > > > notify handler for memory (so that memory eject events are simply dropped on
> > > > the floor after unbinding the driver)?
> > >
> > > If driver_unbind() happens before an eject request, we do not have a
> > > problem. acpi_eject_store() fails if a driver is not bound to the
> > > device. acpi_memory_device_notify() fails as well.
> > >
> > > The race condition Wen pointed out (see the top of this email) is that
> > > driver_unbind() may come in while eject operation is in-progress. This
> > > is why I mentioned the following in previous email.
> > >
> > > > So, we basically need to either 1) serialize
> > > > acpi_bus_hot_remove_device() and driver_unbind(), or 2) make
> > > > acpi_bus_hot_remove_device() to fail if driver_unbind() is run
> > > > during the operation.
> >
> > Forgot to mention. The 3rd option is what Greg said -- use the
> > suppress_bind_attrs field. I think this is a good option to address
> > this race condition for now. For a long term solution, we should have a
> > better infrastructure in place to address such issue in general.
>
> Well, in the meantime I've had a look at acpi_bus_hot_remove_device() and
> friends and I think there's a way to address all of these problems
> without big redesign (for now).
>
> First, why don't we introduce an ACPI device flag (in the flags field of
> struct acpi_device) called eject_forbidden or something like this such that:
>
> (1) It will be clear by default.
> (2) It may only be set by a driver's .add() routine if necessary.
> (3) Once set, it may only be cleared by the driver's .remove() routine if
> it's safe to physically remove the device after the .remove().
>
> Then, after the .remove() (which must be successful) has returned, and the
> flag is set, it will tell acpi_bus_remove() to return a specific error code
> (such as -EBUSY or -EAGAIN). It doesn't matter if .remove() was called
> earlier, because if it left the flag set, there's no way to clear it afterward
> and acpi_bus_remove() will see it set anyway. I think the struct acpi_device
> should be unregistered anyway if that error code is to be returned.
I like the idea! It's a good intermediate solution if we need to keep
the bind/unbind interface. That said, I still prefer to go with option
3) for now. I do not see much reason to keep the bind/unbind interface
for ACPI hotplug drivers, and it seems that the semantics of .remove()
is .remove_driver(), not .remove_device() for driver_unbind(). So, I
think we should disable the bind/unbind interface until we settle this
issue.
> [By the way, do you know where we free the memory allocated for struct
> acpi_device objects?]
device_release() -> acpi_device_release().
> Now if acpi_bus_trim() gets that error code from acpi_bus_remove(), it should
> store it, but continue the trimming normally and finally it should return that
> error code to acpi_bus_hot_remove_device().
>
> Now, if acpi_bus_hot_remove_device() gets that error code, it should just
> reverse the whole trimming (i.e. trigger acpi_bus_scan() from the device
> we attempted to eject) and notify the firmware about the failure.
>
> If we have that, then the memory hotplug driver would only need to set
> flags.eject_forbidden in its .add() routine and make its .remove() routine
> only clear that flag if it is safe to actually remove the memory.
>
> Does this make sense to you?
In high-level, yes. Rollback strategy, such as we should continue the
trimming after an error, is something we need to think about along with
the framework design. I think we need a good framework before
implementing rollback.
> [BTW, using _PS3 in acpi_bus_hot_remove_device() directly to power off the
> device is a nonsense, because this method is not guaranteed to turn the power
> off in the first place (it may just put the device into D3hot). If anything,
> acpi_device_set_power() should be used for that, but even that is not
> guaranteed to actually remove the power (power resources may be shared with
> other devices, so in fact that operation should be done by acpi_bus_trim()
> for each of the trimmed devices.]
I agree. I cannot tell for other vendor's implementation, but I expect
that _EJ0 takes care of the power state after it is ejected.
Thanks,
-Toshi
next prev parent reply other threads:[~2012-11-29 16:51 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-23 17:50 [RFC PATCH v3 0/3] acpi: Introduce prepare_remove device operation Vasilis Liaskovitis
2012-11-23 17:50 ` [RFC PATCH v3 1/3] acpi: Introduce prepare_remove operation in acpi_device_ops Vasilis Liaskovitis
2012-11-27 0:10 ` Toshi Kani
2012-11-27 18:36 ` Vasilis Liaskovitis
2012-11-27 23:18 ` Rafael J. Wysocki
2012-11-23 17:50 ` [RFC PATCH v3 2/3] acpi_memhotplug: Add prepare_remove operation Vasilis Liaskovitis
2012-11-24 16:23 ` Wen Congyang
2012-11-23 17:50 ` [RFC PATCH v3 3/3] acpi_memhotplug: Allow eject to proceed on rebind scenario Vasilis Liaskovitis
2012-11-24 16:20 ` Wen Congyang
2012-11-26 8:36 ` Vasilis Liaskovitis
2012-11-26 9:11 ` Wen Congyang
2012-11-27 0:19 ` Toshi Kani
2012-11-27 18:32 ` Vasilis Liaskovitis
2012-11-27 22:03 ` Toshi Kani
2012-11-27 23:41 ` Rafael J. Wysocki
2012-11-28 16:01 ` Toshi Kani
2012-11-28 18:40 ` Rafael J. Wysocki
2012-11-28 21:02 ` Toshi Kani
2012-11-28 21:40 ` Rafael J. Wysocki
2012-11-28 21:40 ` Toshi Kani
2012-11-28 22:01 ` Rafael J. Wysocki
2012-11-28 22:04 ` Toshi Kani
2012-11-28 22:21 ` Rafael J. Wysocki
2012-11-28 22:16 ` Toshi Kani
2012-11-28 22:39 ` Rafael J. Wysocki
2012-11-28 22:46 ` Greg KH
2012-11-28 23:05 ` Rafael J. Wysocki
2012-11-28 23:10 ` Greg KH
2012-11-28 23:31 ` Rafael J. Wysocki
2012-11-28 23:49 ` Rafael J. Wysocki
2012-11-29 1:02 ` Toshi Kani
2012-11-29 1:15 ` Toshi Kani
2012-11-29 10:03 ` Rafael J. Wysocki
2012-11-29 11:30 ` Vasilis Liaskovitis
2012-11-29 16:57 ` Rafael J. Wysocki
2012-11-29 17:56 ` Toshi Kani
2012-11-29 20:25 ` Rafael J. Wysocki
2012-11-29 20:38 ` Toshi Kani
2012-11-29 21:23 ` Rafael J. Wysocki
2012-11-29 21:46 ` Toshi Kani
2012-11-29 22:11 ` Rafael J. Wysocki
2012-11-29 23:17 ` Toshi Kani
2012-11-30 0:13 ` Rafael J. Wysocki
2012-11-30 1:09 ` Toshi Kani
2012-11-29 16:43 ` Toshi Kani [this message]
2012-11-29 11:04 ` Vasilis Liaskovitis
2012-11-29 17:44 ` Toshi Kani
2012-12-06 9:30 ` Vasilis Liaskovitis
2012-12-06 12:50 ` Rafael J. Wysocki
2012-12-06 15:41 ` Toshi Kani
2012-12-06 20:32 ` Rafael J. Wysocki
2012-11-28 11:05 ` [RFC PATCH v3 0/3] acpi: Introduce prepare_remove device operation Hanjun Guo
2012-11-28 18:41 ` Toshi Kani
2012-11-29 4:48 ` Hanjun Guo
2012-11-29 22:27 ` Toshi Kani
2012-12-03 4:25 ` Hanjun Guo
2012-12-04 0:10 ` Toshi Kani
2012-12-04 9:16 ` Hanjun Guo
2012-12-04 23:23 ` Toshi Kani
2012-12-05 12:10 ` Hanjun Guo
2012-12-05 22:31 ` Toshi Kani
2012-12-06 16:47 ` Jiang Liu
2012-12-07 2:25 ` Toshi Kani
2012-12-06 16:40 ` Jiang Liu
2012-12-06 20:30 ` Rafael J. Wysocki
2012-12-07 2:57 ` Toshi Kani
2012-12-07 5:57 ` Jiang Liu
2012-12-08 1:08 ` Toshi Kani
2012-12-11 14:34 ` Jiang Liu
2012-12-13 14:42 ` Toshi Kani
2012-12-13 15:15 ` Jiang Liu
2012-12-15 1:19 ` Toshi Kani
2012-11-29 10:15 ` Rafael J. Wysocki
2012-11-29 11:36 ` Vasilis Liaskovitis
2012-12-06 16:59 ` Jiang Liu
2012-11-29 17:03 ` Toshi Kani
2012-11-29 20:30 ` Rafael J. Wysocki
2012-11-29 20:39 ` Toshi Kani
2012-11-29 20:56 ` Toshi Kani
2012-11-29 21:25 ` Rafael J. Wysocki
2012-12-06 17:10 ` Jiang Liu
2012-12-06 17:07 ` Jiang Liu
2012-12-06 17:01 ` Jiang Liu
2012-12-06 16:56 ` Jiang Liu
2012-12-06 16:00 ` Jiang Liu
2012-12-06 16:03 ` Toshi Kani
2012-12-06 16:25 ` Jiang Liu
2012-12-06 16:31 ` Toshi Kani
2012-12-06 16:52 ` Jiang Liu
2012-12-06 17:09 ` Toshi Kani
2012-12-06 17:30 ` Jiang Liu
2012-12-06 17:28 ` Toshi Kani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1354207397.26955.417.camel@misato.fc.hp.com \
--to=toshi.kani@hp.com \
--cc=gregkh@linuxfoundation.org \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rjw@sisk.pl \
--cc=vasilis.liaskovitis@profitbricks.com \
--cc=wencongyang@gmail.com \
--cc=wency@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).