From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cornelia Huck Subject: Re: Possible problem with device_move() Date: Mon, 30 Jul 2007 08:42:29 +0200 Message-ID: <20070730084229.1df8757c@gondolin.boeblingen.de.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: Alan Stern Cc: Marcel Holtmann , Linux-pm mailing list List-Id: linux-pm@vger.kernel.org On Sat, 28 Jul 2007 11:36:42 -0400 (EDT), Alan Stern wrote: > Can you tell whether this will ever cause a problem? Or is it known to > be safe because whenever you call device_move(), the new parent was > registered before the device being moved? Unfortunately, we can't make any assumptions in cio whether the new parent was registered before the moving device. (A little background: We have each ccw_device as parent of a subchannel as discovered during initial sense. In the case of z/VM (a hypervisor), all subchannels are always consecutively numbered. Now the following may happen: A dasd on subchannel 0 is detached and a new device, say a ctc, is defined. As subchannel 0 was free from z/VMs perspective, the ctc ccw_device now sits on subchannel 0 and the dasd ccw_device is moved to the artificial 'defunct' subchannel. When the dasd is attached again, z/VM will hand out the next free subchannel, which we allocate a subchannel structure for and move the dasd ccw_device to. And here's the case where the child is older than the parent...) While we don't do suspend/resume yet on s390, I don't want to rule it out for the future...