NAK, we don't need to do this.
There is no relationship between kmem_cache_* and free_nid_list_lock.
Moreover, IMO, it would be better unlock free_nid_list_lock as quickly
as possible in order to reduce lock contention.

2012-12-30 (일), 14:52 +0900, Namjae Jeon:
> From: Namjae Jeon <namjae.j...@samsung.com>
> 
> Cache entry for free NID, is not getting removed under proper
> lock in case of error in add_free_nid. So, free the cache entry
> first before releasing the spinlock.
> 
> Signed-off-by: Namjae Jeon <namjae.j...@samsung.com>
> Signed-off-by: Amit Sahrawat <a.sahra...@samsung.com>
> ---
>  fs/f2fs/node.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 5066bfd..09139fb 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1227,8 +1227,8 @@ retry:
>  
>       spin_lock(&nm_i->free_nid_list_lock);
>       if (__lookup_free_nid_list(nid, &nm_i->free_nid_list)) {
> -             spin_unlock(&nm_i->free_nid_list_lock);
>               kmem_cache_free(free_nid_slab, i);
> +             spin_unlock(&nm_i->free_nid_list_lock);
>               return 0;
>       }
>       list_add_tail(&i->list, &nm_i->free_nid_list);

-- 
Jaegeuk Kim
Samsung

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to