A new DIO flag is added into our distribution (2.6.9 based) to work around the problem by moving the inode semaphore acquiring within __blockdev_direct_IO() (patch attached) into GFS code path (so lock order can be re-arranged). The new lock granularity is not ideal but it gets us out of this deadlock.
Could you help me understand in a little more detail why DIO_OWN_LOCKING
does not work for you ? Is the releasing of i_sem during READ a problem ?
Doesn't holding i_sem for the entire duration of IO for read slow down
concurrent DIO reads to different parts of the file ?
One of the things I wanted to achieve in the proposal was to avoidThat's a good news - these DIO locking flags are all last-minute bandaids anyway.
the need for these various locking mode flag checks in the DIO code,
leaving it to the higher level to just select the right entry points,
i.e. the _nolock or lock versions of generic_file_aio_write et al.
Would appreciate your thoughts on this, once you've had a chance toOn the road all next week but will get to it when I'm back to office. On the other hand, thank you for looking into this.
go throught it.