Re: s390 common I/O layer locking

Vineeth Vijayan
2021-08-03T14:27:27Z

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