linux-kernel - Re: [PATCH] mm/zswap: remove unneeded zswap_rb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 21 Nov 2013 17:33:49 -0500
From:	Dan Streetman <ddstreet@...e.org>
To:	Weijie Yang <weijie.yang.kh@...il.com>
Cc:	Seth Jennings <sjennings@...iantweb.net>, linux-mm@...ck.org,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Bob Liu <bob.liu@...cle.com>, Minchan Kim <minchan@...nel.org>,
	Weijie Yang <weijie.yang@...sung.com>
Subject: Re: [PATCH] mm/zswap: remove unneeded zswap_rb_erase calls

On Wed, Nov 20, 2013 at 9:52 PM, Weijie Yang <weijie.yang.kh@...il.com> wrote:
> Hello Dan
>
> On Thu, Nov 21, 2013 at 3:47 AM, Dan Streetman <ddstreet@...e.org> wrote:
>> Since zswap_rb_erase was added to the final (when refcount == 0)
>> zswap_put_entry, there is no need to call zswap_rb_erase before
>> calling zswap_put_entry.
>>
>> Signed-off-by: Dan Streetman <ddstreet@...e.org>
>> ---
>>  mm/zswap.c | 5 -----
>>  1 file changed, 5 deletions(-)
>>
>> diff --git a/mm/zswap.c b/mm/zswap.c
>> index e154f1e..f4fbbd5 100644
>> --- a/mm/zswap.c
>> +++ b/mm/zswap.c
>> @@ -711,8 +711,6 @@ static int zswap_frontswap_store(unsigned type, pgoff_t offset,
>>                 ret = zswap_rb_insert(&tree->rbroot, entry, &dupentry);
>>                 if (ret == -EEXIST) {
>>                         zswap_duplicate_entry++;
>> -                       /* remove from rbtree */
>> -                       zswap_rb_erase(&tree->rbroot, dupentry);
>>                         zswap_entry_put(tree, dupentry);
>>                 }
>>         } while (ret == -EEXIST);
>
> If remove zswap_rb_erase, it would loop until free this dupentry. This
> would cause 2 proplems:

I need to get more familiar with when it's possible to hit a duplicate
entry, it seems strange to me that higher level swap code would be
trying to store a page with an already used offset.

> 1.  zswap_duplicate_entry counter is not correct
> 2. trigger BUG_ON in zswap_entry_put when this dupentry is being writeback,
>    because zswap_writeback_entry will call zswap_entry_put either.
>
> So, I don't think it is a good idea to remove zswap_rb_erase call.
>
>> @@ -787,9 +785,6 @@ static void zswap_frontswap_invalidate_page(unsigned type, pgoff_t offset)
>>                 return;
>>         }
>>
>> -       /* remove from rbtree */
>> -       zswap_rb_erase(&tree->rbroot, entry);
>> -
>>         /* drop the initial reference from entry creation */
>>         zswap_entry_put(tree, entry);
>
> I think it is better not to remove the zswap_rb_erase call.
>
> From frontswap interface view, if invalidate is called, the page(and
> entry) should never visible to upper.
> If remove the zswap_rb_erase call, it is not fit this semantic.
>
> Consider the following scenario:
> 1. thread 0: entry A is being writeback
> 2. thread 1: invalidate entry A, as refcount != 0, it will still exist
> on rbtree.
> 3. thread 1: reuse  entry A 's swp_entry_t, do a frontswap_store
>    it will conflict with the  entry A on the rbtree, it is not a
> normal duplicate store.
>
> If we place the zswap_rb_erase call in zswap_frontswap_invalidate_page,
> we can avoid the above scenario.
>
> So, I don't think it is a good idea to remove zswap_rb_erase call.

It seems to me that zswap_rb_erase shouldn't have been folded into
zswap_entry_put; if it was removed now, the only place it would need
to be added back is into the success path of writeback, i.e.:

  if (entry == zswap_rb_search(&tree->rbroot, offset)) {
   zswap_rb_erase(&tree->rbroot, entry);
   zswap_entry_put(tree, entry);
  }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/