Ceph » Linux kernel client

(09:04:47 PM) dchinner: sage: ceph nests dcache_lock inside inode->i_lock in __dcache_readdir(), but it's been a long standing implicit rule that nothing should be nested inside inode->i_lock
(09:05:14 PM) dchinner: is there some other way to provide the necessary locking in this code?
(09:05:23 PM) sage: dchinner: ha, yeah, i was wondering if that was going to be a problem.
(09:06:08 PM) sage: i'm sure there's another way, but i'll have to take a close look at it
(09:06:58 PM) dchinner: Thank you.
(09:07:22 PM) sage: np
(09:08:01 PM) dchinner: I'm not sure of all the intricacies of that code, and it doesn't look like it's a simple "lift the dcache_lock outside i_lock" type of fix.
(09:08:15 PM) sage: yeah
(09:08:35 PM) sage: although actually it's d_lock now instead of dcache_lock, with the new vfs scalability stuff?
(09:08:53 PM) sage: at least that's what nick's patch did, iirc
(09:10:58 PM) dchinner: True, but I'm not sure that nesting the d_lock inside it is any better
(09:11:42 PM) sage: fair enough.  is there any specific issue with it, or just generally asking for trouble?
(09:15:43 PM) dchinner: Well, it appears that the way Ceph is ordering these locks is one of the reasons Nick has put lots of other VFS locks inside inode->i_lock
(09:15:44 PM) djwongwfh left the room (quit: Read error: Connection reset by peer).
(09:16:38 PM) dchinner: I'm trying to rework that locking so that there's nothing inside inode->i_lock, and this place in Ceph and one other place in cifs are the only places where locks have been identified as taken within the i_lock
(09:16:59 PM) djwongwfh [~djwong@c-67-188-93-145.hsd1.ca.comcast.net] entered the room.
(09:17:18 PM) dchinner: so I'm trying to work out if changing the locking in ceph is a solvable problem or not
(09:17:28 PM) dchinner: the cifs code lots pretty trivial to fix....
(09:17:36 PM) dchinner: s/lots/looks/
(09:18:30 PM) sage: ok.  i should be able to look at it in detail tomorrow.
(09:19:31 PM) dchinner: ta.