Re: s390 common I/O layer locking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 7/24/21 3:24 PM, Christoph Hellwig wrote:
On Tue, May 04, 2021 at 05:10:42PM +0200, Vineeth Vijayan wrote:
...snip...
I just had a quick glance on the CIO layer drivers. And at first look, you
are right.
It looks likewe need modifications in the event callbacks (referring css
here)
Let me go thoughthis thoroughly and update.
Did this go anywhere?
Hello Christoph,

Thank you for this reminder. Also, my apologies for the slow reply; This was one of those item which really needed this reminder :-)

Coming to the point, The event-callbacks  are under sch->lock, which i think is the right thing to do. But i also agree on your feedback about the sch->driver accesses in the css_evaluate_known_subchannel() call. My first impression was to add them under device_lock(). As Conny mentioned, most of the drivers on the css-bus remained-stable during the lifetime of the devices, and we never got this racy scenario.  And then having this change with device_lock(), as you mentioned,this code-base would need significant change in the sch_event callbacks. I am not sure if there is a straight forward solution for this locking-issue scenario.

Currently, i am trying to see the "minimal" change i can work on on the event-callbacks and the css_evaluate_known_subchannel() call, to make sure that, this racy condition can never occur.

Conny,

Please do let me know if you think i am missing something here. I would like to concentrate more on the sch->driver() access scenario first and would like to see how it can have minimal impact on the event-callbacks. especially io_subchannel_sch_event.


Vineeth



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux