On 9/22/23 15:20, Halil Pasic wrote:
Author of 2ec2298412e1 here. If I don't completely misremember things,
this was for the orphanage stuff (i.e. ccw devices that were still kept
as disconnected, like dasd still in use, that had to be moved from their
old subchannel object because a different device appeared on that
subchannel.) That orphanage used a single dummy subchannel for all ccw
devices moved there.
I have no idea how the current common I/O layer works, but that might
give you a hint about what to look for 😄
Yes, that is what the commit states and what the series is about. I hope
Vineeth can give us some answers 😄 maybe even out of the top of his
head... If not, I would trust his judgment on whether figuring things
out is worthwhile or not.
As Corny mentioned, orphanage is the only case i remember where
this scenario of dynamically allocated sch->lock being used. I hope
you remember the cdev->ccwlock, which is nothing but the copy of
sch->lock pointer. This is rather a tricky design, where we are using
the sch->lock and cdev->ccwlock, which are same pointers.
Because this sch is exclusively for the cdev ops. But at the same time,
a CC3 code in the stsch can make the attached device an orphanage and
remove the sch.
We have already seen an issue with this approach and had couple of
discussions about avoiding this pointer usage without using an extra
lock but do not have a right solution for this now.
