On Wednesday 15 September 2010, Sage Weil wrote:
> > @@ -2362,7 +2362,7 @@ static int encode_caps_cb(struct inode *inode, struct ceph_cap *cap,
> > if (recon_state->flock) {
> > int num_fcntl_locks, num_flock_locks;
> >
> > - lock_kernel();
> > + lock_flocks();
> > ceph_count_locks(inode, &num_fcntl_locks, &num_flock_locks);
> > rec.v2.flock_len = (2*sizeof(u32) +
> > (num_fcntl_locks+num_flock_locks) *
> > @@ -2373,7 +2373,7 @@ static int encode_caps_cb(struct inode *inode, struct ceph_cap *cap,
> > err = ceph_encode_locks(inode, pagelist,
> > num_fcntl_locks,
> > num_flock_locks);
> > - unlock_kernel();
> > + unlock_flocks();
> > }
>
> The Ceph code won't currently behave with lock_flocks() taking a spinlock.
> We're preparing a patch to fix that now. As long as there is a window
> between lock_flocks() being defined and the spinlock conversion, I can
> send the fix upstream then and avoid any breakage. Or send the patches
> your way to include in your tree, whatever you prefer!
I'd be happy to just integrate the fix in this patch, or as a separate patch
in the series.
I certainly don't want to break any file system in the middle of the series,
I'm sure we can find a way to do it right.
What is the problem? I just saw ceph_pagelist_addpage potentially sleeping,
is that what you are thinking of?
> > +void unlock_flocks(void)
> > +{
> > + unlock_kernel();
> > +}
>
> EXPORT_SYMBOL(unlock_flocks); ?
Right, thanks!
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
