linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Toshi Kani <toshi.kani@hp.com>,
	lenb@kernel.org, akpm@linux-foundation.org,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, bhelgaas@google.com,
	isimatu.yasuaki@jp.fujitsu.com, jiang.liu@huawei.com,
	wency@cn.fujitsu.com, guohanjun@huawei.com, yinghai@kernel.org,
	srivatsa.bhat@linux.vnet.ibm.com
Subject: Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
Date: Mon, 4 Feb 2013 16:04:47 -0800	[thread overview]
Message-ID: <20130205000447.GA21782@kroah.com> (raw)
In-Reply-To: <7003418.onqVlaaHJS@vostro.rjw.lan>

On Tue, Feb 05, 2013 at 12:52:30AM +0100, Rafael J. Wysocki wrote:
> You'd probably never try to hot-remove a disk before unmounting filesystems
> mounted from it or failing it as a RAID component and nobody sane wants the
> kernel to do things like that automatically when the user presses the eject
> button.  In my opinion we should treat memory eject, or CPU package eject, or
> PCI host bridge eject in exactly the same way: Don't eject if it is not
> prepared for ejecting in the first place.

Bad example, we have disks hot-removed all the time without any
filesystems being unmounted, and have supported this since the 2.2 days
(although we didn't get it "right" until 2.6.)

PCI Host bridge eject is the same as PCI eject today, the user asks us
to do it, and we can not fail it from happening.  We also can have them
removed without us being told about it in the first place, and can
properly clean up from it all.

> And if you think about it, that makes things *massively* simpler, because now
> the kernel doesn't heed to worry about all of those "synchronous removal"
> scenarions that very well may involve every single device in the system and
> the whole problem is nicely split into several separate "implement
> offline/online" problems that are subsystem-specific and a single
> "eject if everything relevant is offline" problem which is kind of trivial.
> Plus the one of exposing information to user space, which is separate too.
> 
> Now, each of them can be worked on separately, *tested* separately and
> debugged separately if need be and it is much easier to isolate failures
> and so on.

So you are agreeing with me in that we can not fail hot removing any
device, nice :)

greg k-h

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2013-02-05  0:02 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-10 23:40 [RFC PATCH v2 00/12] System device hot-plug framework Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework Toshi Kani
2013-01-11 21:23   ` Rafael J. Wysocki
2013-01-14 15:33     ` Toshi Kani
2013-01-14 18:48       ` Rafael J. Wysocki
2013-01-14 19:02         ` Toshi Kani
2013-01-30  4:48           ` Greg KH
2013-01-31  1:15             ` Toshi Kani
2013-01-31  5:24               ` Greg KH
2013-01-31 14:42                 ` Toshi Kani
2013-01-30  4:53   ` Greg KH
2013-01-31  1:46     ` Toshi Kani
2013-01-30  4:58   ` Greg KH
2013-01-31  2:57     ` Toshi Kani
2013-01-31 20:54       ` Rafael J. Wysocki
2013-02-01  1:32         ` Toshi Kani
2013-02-01  7:30           ` Greg KH
2013-02-01 20:40             ` Toshi Kani
2013-02-01 22:21               ` Rafael J. Wysocki
2013-02-01 23:12                 ` Toshi Kani
2013-02-02 15:01               ` Greg KH
2013-02-04  0:28                 ` Toshi Kani
2013-02-04 12:46                   ` Greg KH
2013-02-04 16:46                     ` Toshi Kani
2013-02-04 19:45                       ` Rafael J. Wysocki
2013-02-04 20:59                         ` Toshi Kani
2013-02-04 23:23                           ` Rafael J. Wysocki
2013-02-04 23:33                             ` Toshi Kani
2013-02-01  7:23         ` Greg KH
2013-02-01 22:12           ` Rafael J. Wysocki
2013-02-02 14:58             ` Greg KH
2013-02-02 20:15               ` Rafael J. Wysocki
2013-02-02 22:18                 ` [PATCH?] Move ACPI device nodes under /sys/firmware/acpi (was: Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework) Rafael J. Wysocki
2013-02-04  1:24                   ` Greg KH
2013-02-04 12:34                     ` Rafael J. Wysocki
2013-02-03 20:44                 ` [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework Rafael J. Wysocki
2013-02-04 12:48                   ` Greg KH
2013-02-04 14:21                     ` Rafael J. Wysocki
2013-02-04 14:33                       ` Greg KH
2013-02-04 20:07                         ` Rafael J. Wysocki
2013-02-04 22:13                           ` Toshi Kani
2013-02-04 23:52                             ` Rafael J. Wysocki
2013-02-05  0:04                               ` Greg KH [this message]
2013-02-05  1:02                                 ` Rafael J. Wysocki
2013-02-05 11:11                                 ` Rafael J. Wysocki
2013-02-05 18:39                                   ` Greg KH
2013-02-05 21:13                                     ` Rafael J. Wysocki
2013-02-05  0:55                               ` Toshi Kani
2013-02-04 16:19                       ` Toshi Kani
2013-02-04 19:43                         ` Rafael J. Wysocki
2013-02-04  1:23                 ` Greg KH
2013-02-04 13:41                   ` Rafael J. Wysocki
2013-02-04 16:02                     ` Toshi Kani
2013-02-04 19:48                       ` Rafael J. Wysocki
2013-02-04 19:46                         ` Toshi Kani
2013-02-04 20:12                           ` Rafael J. Wysocki
2013-02-04 20:34                             ` Toshi Kani
2013-02-04 23:19                               ` Rafael J. Wysocki
2013-01-10 23:40 ` [RFC PATCH v2 02/12] ACPI: " Toshi Kani
2013-01-11 21:25   ` Rafael J. Wysocki
2013-01-14 15:53     ` Toshi Kani
2013-01-14 18:47       ` Rafael J. Wysocki
2013-01-14 18:42         ` Toshi Kani
2013-01-14 19:07           ` Rafael J. Wysocki
2013-01-14 19:21             ` Toshi Kani
2013-01-30  4:51               ` Greg KH
2013-01-31  1:38                 ` Toshi Kani
2013-01-14 19:21             ` Greg KH
2013-01-14 19:29               ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 03/12] drivers/base: Add " Toshi Kani
2013-01-30  4:54   ` Greg KH
2013-01-31  1:48     ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 04/12] cpu: Add cpu hotplug handlers Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 05/12] mm: Add memory " Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 06/12] ACPI: Add ACPI bus " Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 07/12] ACPI: Add ACPI resource hotplug handler Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 08/12] ACPI: Update processor driver for hotplug framework Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 09/12] ACPI: Update memory " Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 10/12] ACPI: Update container " Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 11/12] cpu: Update sysfs cpu/online " Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 12/12] ACPI: Update sysfs eject " Toshi Kani
2013-01-17  0:50 ` [RFC PATCH v2 00/12] System device hot-plug framework Rafael J. Wysocki
2013-01-17 17:59   ` 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=20130205000447.GA21782@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=bhelgaas@google.com \
    --cc=guohanjun@huawei.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=jiang.liu@huawei.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=rjw@sisk.pl \
    --cc=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=toshi.kani@hp.com \
    --cc=wency@cn.fujitsu.com \
    --cc=yinghai@kernel.org \
    /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