Ravindra Khati

As you wrote, if a task can acquire mmap_sem multiple times, then it will be safe and I'd agree with you. mmap_sem before si_rwsem is worth to try. Yes, I have tried this for the race between aufs_read and mmap, this seems to fix the issue. but I think I would have to put this fix in all the calls where si_read_lock is being called and there are chances of page fault being raised raised in that flow. And if you know the detail about 4.9 RT kernel, would you tell me how to reproduce the problem on...

"read-lock" for rwsem (aka. "shared-lock"), it is possible for TWO thread to acquire the single rwsem, isn't it? Or your RT kernel doesn't allow such shared-lock? That's the whole point, rwsem is unfortunately implemented as a recursive mutex in standard RT kernel. One thread can lock it multiple times but no two threads can have the lock simultaneously (not even read-lock :( ). This is done deliberatley in RT kernel so that the writers do not starve on readers. Since it's a typical issue of RT kernel...

si_rwsem protects au_sbinfo members. The typical case is a branch management such as to add/del/mod branches. I am afraid that you don't use such feature. We do have branches added which we do during boot up, but yes we don't delete or modify later and do not plan to do so. Do you mean read(2) systemcall issues mmap(2) internally? I am not sure there such path exists... But I thought page-fault will call address_space_operations instead of file_operations. And I didn't mean disturbing page_fault....

Sorry, my bad, we are certainly based on f78f003 2013-03-12 Merge branch 'aufs3.0/10static' into aufs3.0/11proc_map and it does have security_mmap_file(), probably I grepped a wrong string earlier. We have some trivial patches i.e spin_lock calls changed with seq_spin_lock. 1) Pardon me for my knowledge on aufs code, I haven't digged in to it much. As you said taking mmap_sem lock before si_rwsem in IO calls would be bad: is that only from a perspective that it's going to delay the mmap calls(i.e...

Sorry, my bad, we are certainly based on f78f003 2013-03-12 Merge branch 'aufs3.0/10static' into aufs3.0/11proc_map and it does have security_mmap_file(), probably I grepped a wrong string earlier. We have some trivial patches i.e spin_lock calls changed with seq_spin_lock. 1) Pardon me for my knowledge on aufs code, I haven't digged in to it much. As you said taking mmap_sem lock before si_rwsem in IO calls would be bad: is that only from a perspective that it's going to delay the mmap calls(i.e...

Hi, Thanks for a quick reply. We are on a quite old aufs code, aufs3.0 branch commit:f78f003f542dcade8e9fe70c1cc9e1bb39a1c8d5 and this is what I can only share from info requested in README file: /sys/module/aufs/version: 3.0 It doesn't have the 7aac34b commit in it and it no where calls security_mmap_file(). I believe that this may be an issue with aufs4 as well, on a RT kernel (with rwsem reader restriction i.e kernels prior to 4.9) . The AB-BA locking order becomes a problem if following happens...

Hi, Thanks for a quick reply. We are on a quite old aufs code, aufs3.0 branch commit:f78f003f542dcade8e9fe70c1cc9e1bb39a1c8d5 and this is what I can only share from info requested in README file: /sys/module/aufs/version: 3.0 It doesn't have the 7aac34b commit in it and it no where calls security_mmap_file(). I believe that this may be an issue with aufs4 as well, on a RT kernel (with rwsem reader restriction i.e kernels prior to 4.9) . The AB-BA locking order becomes a problem if following happens...

RT System (deadlocks) hangs because of locking order in case of aufs_read/aufs_mmap.