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.jeon@xxxxxxxxxxx>
>
> 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.jeon@xxxxxxxxxxx>
> Signed-off-by: Amit Sahrawat <a.sahrawat@xxxxxxxxxxx>
> ---
> 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
