v3.
But to remind, this particular patch depends on Dave's fixes, so I will
send it later.
And I forgot to mention that I have another patch which removes the
trylock hack from __sb_start_write() as Dave suggested, it passed the
tests. But again, I'd really like to send it separately so that it ca
Jan, you seem to agree with these patches. How should we route
> this all?
Regarding the routing, ideally Al Viro should take these as a VFS
maintainer.
> -------------------
> Subject: [PATCH v2 9/8] don't fool lock
?
Regarding the routing, ideally Al Viro should take these as a VFS
maintainer.
---
Subject: [PATCH v2 9/8] don't fool lockdep in freeze_super() and thaw_super()
paths
sb_wait_write()-percpu_rwsem_release() fools
hack from __sb_start_write() as Dave suggested, it passed the
tests. But again, I'd really like to send it separately so that it can
be reverted in (unlikely) case something else does recursive read_lock().
Subject: [PATCH v2 9/8] don't fool lockdep in freeze_super() and
thaw_super() paths
ute
this all?
---
Subject: [PATCH v2 9/8] don't fool lockdep in freeze_super() and thaw_super()
paths
sb_wait_write()->percpu_rwsem_release() fools lockdep to avoid the
false-positives. Now that xfs was fixed by Dave we can remove it and
change freeze_super() and thaw
?
---
Subject: [PATCH v2 9/8] don't fool lockdep in freeze_super() and thaw_super()
paths
sb_wait_write()-percpu_rwsem_release() fools lockdep to avoid the
false-positives. Now that xfs was fixed by Dave we can remove it and
change freeze_super() and thaw_super() to run
6 matches
Mail list logo
