All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gu Zheng <guz.fnst@cn.fujitsu.com>
To: Chao Yu <chao2.yu@samsung.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH 2/2] f2fs: use list_for_each_entry{_safe} for simplyfying code
Date: Tue, 01 Apr 2014 10:15:32 +0800	[thread overview]
Message-ID: <533A2144.8040607@cn.fujitsu.com> (raw)
In-Reply-To: <000001cf4d4c$374e5f10$a5eb1d30$@samsung.com>

Hi Yu,
On 04/01/2014 09:45 AM, Chao Yu wrote:

> Hi Gu,
> 
>> -----Original Message-----
>> From: Gu Zheng [mailto:guz.fnst@cn.fujitsu.com]
>> Sent: Monday, March 31, 2014 6:07 PM
>> To: Chao Yu
>> Cc: ???; linux-f2fs-devel@lists.sourceforge.net; linux-fsdevel@vger.kernel.org;
>> linux-kernel@vger.kernel.org
>> Subject: Re: [f2fs-dev] [PATCH 2/2] f2fs: use list_for_each_entry{_safe} for simplyfying code
>>
>> Hi Yu,
>> On 03/29/2014 11:33 AM, Chao Yu wrote:
>>
>>> This patch use list_for_each_entry{_safe} instead of list_for_each{_safe} for
>>> simplfying code.
>>>
>>> Signed-off-by: Chao Yu <chao2.yu@samsung.com>
>>> ---
>>>  fs/f2fs/checkpoint.c |   37 ++++++++++++++-----------------------
>>>  fs/f2fs/node.c       |   16 ++++++----------
>>>  fs/f2fs/recovery.c   |    6 ++----
>>>  fs/f2fs/segment.c    |    6 ++----
>>>  4 files changed, 24 insertions(+), 41 deletions(-)
>>>
>>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>>> index d877f46..4aa521a 100644
>>> --- a/fs/f2fs/checkpoint.c
>>> +++ b/fs/f2fs/checkpoint.c
>>> @@ -308,16 +308,15 @@ void release_orphan_inode(struct f2fs_sb_info *sbi)
>>>
>>>  void add_orphan_inode(struct f2fs_sb_info *sbi, nid_t ino)
>>>  {
>>> -	struct list_head *head, *this;
>>> -	struct orphan_inode_entry *new = NULL, *orphan = NULL;
>>> +	struct list_head *head;
>>> +	struct orphan_inode_entry *new, *orphan;
>>>
>>>  	new = f2fs_kmem_cache_alloc(orphan_entry_slab, GFP_ATOMIC);
>>>  	new->ino = ino;
>>>
>>>  	spin_lock(&sbi->orphan_inode_lock);
>>>  	head = &sbi->orphan_inode_list;
>>> -	list_for_each(this, head) {
>>> -		orphan = list_entry(this, struct orphan_inode_entry, list);
>>> +	list_for_each_entry(orphan, head, list) {
>>>  		if (orphan->ino == ino) {
>>>  			spin_unlock(&sbi->orphan_inode_lock);
>>>  			kmem_cache_free(orphan_entry_slab, new);
>>> @@ -326,14 +325,10 @@ void add_orphan_inode(struct f2fs_sb_info *sbi, nid_t ino)
>>>
>>>  		if (orphan->ino > ino)
>>>  			break;
>>> -		orphan = NULL;
>>>  	}
>>>
>>> -	/* add new_oentry into list which is sorted by inode number */
>>> -	if (orphan)
>>> -		list_add(&new->list, this->prev);
>>> -	else
>>> -		list_add_tail(&new->list, head);
>>> +	/* add new orphan entry into list which is sorted by inode number */
>>> +	list_add_tail(&new->list, &orphan->list);
>>
>> It seems that the logic can not be changed here, otherwise the orphan list will not be in order
>> if
>> the new ino is bigger than all the in-list ones.
>> E.g.
>> ino:5
>> 1-->2-->3-->4
>> ==>
>> 1-->2-->3-->5-->4
> 
> As I checked, if new ino is bigger than all, it will break from list_for_each_entry because
> &orphan->list is pointing to head. So list_add_tail can add the new entry before head to make
> this list in order.

Oh...Yes, you are right.
Thanks for correcting me.

Regards,
Gu

> 
> Thanks.
> 
>>
>> Regards,
>> Gu
>>
> 
> [snip]
> 
> 



------------------------------------------------------------------------------

WARNING: multiple messages have this Message-ID (diff)
From: Gu Zheng <guz.fnst@cn.fujitsu.com>
To: Chao Yu <chao2.yu@samsung.com>
Cc: "'???'" <jaegeuk.kim@samsung.com>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH 2/2] f2fs: use list_for_each_entry{_safe} for simplyfying code
Date: Tue, 01 Apr 2014 10:15:32 +0800	[thread overview]
Message-ID: <533A2144.8040607@cn.fujitsu.com> (raw)
In-Reply-To: <000001cf4d4c$374e5f10$a5eb1d30$@samsung.com>

Hi Yu,
On 04/01/2014 09:45 AM, Chao Yu wrote:

> Hi Gu,
> 
>> -----Original Message-----
>> From: Gu Zheng [mailto:guz.fnst@cn.fujitsu.com]
>> Sent: Monday, March 31, 2014 6:07 PM
>> To: Chao Yu
>> Cc: ???; linux-f2fs-devel@lists.sourceforge.net; linux-fsdevel@vger.kernel.org;
>> linux-kernel@vger.kernel.org
>> Subject: Re: [f2fs-dev] [PATCH 2/2] f2fs: use list_for_each_entry{_safe} for simplyfying code
>>
>> Hi Yu,
>> On 03/29/2014 11:33 AM, Chao Yu wrote:
>>
>>> This patch use list_for_each_entry{_safe} instead of list_for_each{_safe} for
>>> simplfying code.
>>>
>>> Signed-off-by: Chao Yu <chao2.yu@samsung.com>
>>> ---
>>>  fs/f2fs/checkpoint.c |   37 ++++++++++++++-----------------------
>>>  fs/f2fs/node.c       |   16 ++++++----------
>>>  fs/f2fs/recovery.c   |    6 ++----
>>>  fs/f2fs/segment.c    |    6 ++----
>>>  4 files changed, 24 insertions(+), 41 deletions(-)
>>>
>>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>>> index d877f46..4aa521a 100644
>>> --- a/fs/f2fs/checkpoint.c
>>> +++ b/fs/f2fs/checkpoint.c
>>> @@ -308,16 +308,15 @@ void release_orphan_inode(struct f2fs_sb_info *sbi)
>>>
>>>  void add_orphan_inode(struct f2fs_sb_info *sbi, nid_t ino)
>>>  {
>>> -	struct list_head *head, *this;
>>> -	struct orphan_inode_entry *new = NULL, *orphan = NULL;
>>> +	struct list_head *head;
>>> +	struct orphan_inode_entry *new, *orphan;
>>>
>>>  	new = f2fs_kmem_cache_alloc(orphan_entry_slab, GFP_ATOMIC);
>>>  	new->ino = ino;
>>>
>>>  	spin_lock(&sbi->orphan_inode_lock);
>>>  	head = &sbi->orphan_inode_list;
>>> -	list_for_each(this, head) {
>>> -		orphan = list_entry(this, struct orphan_inode_entry, list);
>>> +	list_for_each_entry(orphan, head, list) {
>>>  		if (orphan->ino == ino) {
>>>  			spin_unlock(&sbi->orphan_inode_lock);
>>>  			kmem_cache_free(orphan_entry_slab, new);
>>> @@ -326,14 +325,10 @@ void add_orphan_inode(struct f2fs_sb_info *sbi, nid_t ino)
>>>
>>>  		if (orphan->ino > ino)
>>>  			break;
>>> -		orphan = NULL;
>>>  	}
>>>
>>> -	/* add new_oentry into list which is sorted by inode number */
>>> -	if (orphan)
>>> -		list_add(&new->list, this->prev);
>>> -	else
>>> -		list_add_tail(&new->list, head);
>>> +	/* add new orphan entry into list which is sorted by inode number */
>>> +	list_add_tail(&new->list, &orphan->list);
>>
>> It seems that the logic can not be changed here, otherwise the orphan list will not be in order
>> if
>> the new ino is bigger than all the in-list ones.
>> E.g.
>> ino:5
>> 1-->2-->3-->4
>> ==>
>> 1-->2-->3-->5-->4
> 
> As I checked, if new ino is bigger than all, it will break from list_for_each_entry because
> &orphan->list is pointing to head. So list_add_tail can add the new entry before head to make
> this list in order.

Oh...Yes, you are right.
Thanks for correcting me.

Regards,
Gu

> 
> Thanks.
> 
>>
>> Regards,
>> Gu
>>
> 
> [snip]
> 
> 



  reply	other threads:[~2014-04-01  2:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-29  3:33 [PATCH 2/2] f2fs: use list_for_each_entry{_safe} for simplyfying code Chao Yu
2014-03-29  3:33 ` [f2fs-dev] " Chao Yu
2014-03-31 10:07 ` Gu Zheng
2014-03-31 10:07   ` [f2fs-dev] " Gu Zheng
2014-04-01  1:45   ` Chao Yu
2014-04-01  1:45     ` [f2fs-dev] " Chao Yu
2014-04-01  2:15     ` Gu Zheng [this message]
2014-04-01  2:15       ` Gu Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=533A2144.8040607@cn.fujitsu.com \
    --to=guz.fnst@cn.fujitsu.com \
    --cc=chao2.yu@samsung.com \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.