During the processing of headless pages in z3fold_reclaim_page(),
there was a problem that the zhdr pointed to another page
or a page was already released in z3fold_free(). So, the wrong page
is encoded in headless, or test_bit does not work properly
in z3fold_reclaim_page(). This patch fixed these problems.
Signed-off-by: Jongseok Kim <[email protected]>
---
mm/z3fold.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 4b366d1..201a8ac 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -746,6 +746,9 @@ static void z3fold_free(struct z3fold_pool *pool, unsigned long handle)
}
if (bud == HEADLESS) {
+ if (test_bit(UNDER_RECLAIM, &page->private))
+ return;
+
spin_lock(&pool->lock);
list_del(&page->lru);
spin_unlock(&pool->lock);
@@ -836,20 +839,20 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
}
list_for_each_prev(pos, &pool->lru) {
page = list_entry(pos, struct page, lru);
+ zhdr = page_address(page);
if (test_bit(PAGE_HEADLESS, &page->private))
/* candidate found */
break;
- zhdr = page_address(page);
if (!z3fold_page_trylock(zhdr))
continue; /* can't evict at this point */
kref_get(&zhdr->refcount);
list_del_init(&zhdr->buddy);
zhdr->cpu = -1;
- set_bit(UNDER_RECLAIM, &page->private);
break;
}
+ set_bit(UNDER_RECLAIM, &page->private);
list_del_init(&page->lru);
spin_unlock(&pool->lock);
@@ -898,6 +901,7 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
if (test_bit(PAGE_HEADLESS, &page->private)) {
if (ret == 0) {
free_z3fold_page(page);
+ atomic64_dec(&pool->pages_nr);
return 0;
}
spin_lock(&pool->lock);
--
2.7.4
Hi Jongseok,
Den fre 6 juli 2018 kl 07:11 skrev Jongseok Kim <[email protected]>:
>
> During the processing of headless pages in z3fold_reclaim_page(),
> there was a problem that the zhdr pointed to another page
> or a page was already released in z3fold_free(). So, the wrong page
> is encoded in headless, or test_bit does not work properly
> in z3fold_reclaim_page(). This patch fixed these problems.
thank you for your work, we've now got a more comprehensive solution:
https://lkml.org/lkml/2018/11/5/726
Would you please confirm that it works for you? Also, would you be
okay with dropping your patch in favor of the new one?
~Vitaly
> Signed-off-by: Jongseok Kim <[email protected]>
> ---
> mm/z3fold.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/mm/z3fold.c b/mm/z3fold.c
> index 4b366d1..201a8ac 100644
> --- a/mm/z3fold.c
> +++ b/mm/z3fold.c
> @@ -746,6 +746,9 @@ static void z3fold_free(struct z3fold_pool *pool, unsigned long handle)
> }
>
> if (bud == HEADLESS) {
> + if (test_bit(UNDER_RECLAIM, &page->private))
> + return;
> +
> spin_lock(&pool->lock);
> list_del(&page->lru);
> spin_unlock(&pool->lock);
> @@ -836,20 +839,20 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
> }
> list_for_each_prev(pos, &pool->lru) {
> page = list_entry(pos, struct page, lru);
> + zhdr = page_address(page);
> if (test_bit(PAGE_HEADLESS, &page->private))
> /* candidate found */
> break;
>
> - zhdr = page_address(page);
> if (!z3fold_page_trylock(zhdr))
> continue; /* can't evict at this point */
> kref_get(&zhdr->refcount);
> list_del_init(&zhdr->buddy);
> zhdr->cpu = -1;
> - set_bit(UNDER_RECLAIM, &page->private);
> break;
> }
>
> + set_bit(UNDER_RECLAIM, &page->private);
> list_del_init(&page->lru);
> spin_unlock(&pool->lock);
>
> @@ -898,6 +901,7 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
> if (test_bit(PAGE_HEADLESS, &page->private)) {
> if (ret == 0) {
> free_z3fold_page(page);
> + atomic64_dec(&pool->pages_nr);
> return 0;
> }
> spin_lock(&pool->lock);
> --
> 2.7.4
>
Den tors 8 nov. 2018 kl 13:34 skrev 김종석 <[email protected]>:
>
> Hi Vitaly,
> thank you for the reply.
>
> I agree your a new solution is more comprehensive and drop my patch is simple way.
> But, I think it's not fair.
> If my previous patch was not wrong, is (my patch -> your patch) the right way?
I could apply the new patch on top of yours but that would effectively
revert most of your changes.
Would it be ok for you if I add you to Signed-off-by for the new patch instead?
~Vitaly
> I'm sorry I sent reply twice.
>
> Best regards,
> Jongseok
>
>
> > On 6/11/2018 4:48 PM, Vitaly Wool wrote:
> > Hi Jongseok,
>
> > thank you for your work, we've now got a more comprehensive solution:
> > https://lkml.org/lkml/2018/11/5/726
>
> > Would you please confirm that it works for you? Also, would you be
> >okay with dropping your patch in favor of the new one?
>
> > ~Vitaly
Yes, you are right.
I think that's the best way to deal it.
Thank you.
Best regards,
Jongseok
> Den tors 8 nov. 2018 kl 13:34 skrev ?????? <[email protected]>:
> >
> > Hi Vitaly,
> > thank you for the reply.
> >
> > I agree your a new solution is more comprehensive and drop my patch is simple way.
> > But, I think it's not fair.
> > If my previous patch was not wrong, is (my patch -> your patch) the right way?
> I could apply the new patch on top of yours but that would effectively
> revert most of your changes.
> Would it be ok for you if I add you to Signed-off-by for the new patch instead?
> ~Vitaly
> > I'm sorry I sent reply twice.
> >
> > Best regards,
> > Jongseok
> >
> >
> > > On 6/11/2018 4:48 PM, Vitaly Wool wrote:
> > > Hi Jongseok,
> >
> > > thank you for your work, we've now got a more comprehensive solution:
> > > https://lkml.org/lkml/2018/11/5/726
> >
> > > Would you please confirm that it works for you? Also, would you be
> > >okay with dropping your patch in favor of the new one?
> >
> > > ~Vitaly
On Thu, 8 Nov 2018 22:45:40 +0900 Jongseok Kim <[email protected]> wrote:
> Yes, you are right.
> I think that's the best way to deal it.
> Thank you.
I did this:
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Vitaly Wool <[email protected]>
Signed-off-by: Jongseok Kim <[email protected]>
Reported-by-by: Jongseok Kim <[email protected]>
Reviewed-by: Snild Dolkow <[email protected]>