Filesystem & mutex

Filesystem & mutex

[Joshua Hudson]

My filesystem has need of an extra mutex in the extended inode data area.
>From what I understand, the mutex can be initalized in inode_init_once, but
I cannot determine how to free it.

It looks wrong to destroy the mutex by just destroying the slab.
It is wrong to destroy the inode in destroy_inode. Badness when
an inode is reused.

I really don't want to go back to semaphores. The mutex code just *looks* so
much cleaner.

Re: Filesystem & mutex

[Pekka Enberg]

Hi,

On 4/24/06, Joshua Hudson <joshudson@gmail.com> wrote:
> My filesystem has need of an extra mutex in the extended inode data area.
> From what I understand, the mutex can be initalized in inode_init_once, but
> I cannot determine how to free it.
>
> It looks wrong to destroy the mutex by just destroying the slab.
> It is wrong to destroy the inode in destroy_inode. Badness when
> an inode is reused.

There's no need to 'release' a mutex. If the mutex is unlocked, you
can do kmem_cache_free() on the owning inode. You need to do
mutex_init() in the object cache constructor (init_once) only because
the memory given to you can be arbitrary state. After the mutex has
been initialized, it will never go into an illegal state on its own
assuming you remember to unlock it before freeing the inode.

                                            Pekka

Re: Filesystem & mutex

[Joshua Hudson]

On 4/24/06, Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> Hi,
>
> On 4/24/06, Joshua Hudson <joshudson@gmail.com> wrote:
> > My filesystem has need of an extra mutex in the extended inode data area.
> > From what I understand, the mutex can be initalized in inode_init_once, but
> > I cannot determine how to free it.
> >
> > It looks wrong to destroy the mutex by just destroying the slab.
> > It is wrong to destroy the inode in destroy_inode. Badness when
> > an inode is reused.
>
> There's no need to 'release' a mutex. If the mutex is unlocked, you
> can do kmem_cache_free() on the owning inode. You need to do
> mutex_init() in the object cache constructor (init_once) only because
> the memory given to you can be arbitrary state. After the mutex has
> been initialized, it will never go into an illegal state on its own
> assuming you remember to unlock it before freeing the inode.
>
>                                             Pekka
Tx. Your solution worked.