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] [thread-next>] [day] [month] [year] [list]
Message-id: <005201cfb611$97362100$c5a26300$@samsung.com>
Date:	Tue, 12 Aug 2014 17:40:32 +0800
From:	Chao Yu <chao2.yu@...sung.com>
To:	'Minchan Kim' <minchan@...nel.org>
Cc:	ngupta@...are.org, linux-kernel@...r.kernel.org,
	'Jerome Marchand' <jmarchan@...hat.com>,
	'Sergey Senozhatsky' <sergey.senozhatsky@...il.com>,
	'Andrew Morton' <akpm@...ux-foundation.org>
Subject: RE: [PATCH] zram: fix incorrectly stat with failed_reads

Hi Minchan,

> -----Original Message-----
> From: Minchan Kim [mailto:minchan@...nel.org]
> Sent: Tuesday, August 12, 2014 3:38 PM
> To: Chao Yu
> Cc: ngupta@...are.org; linux-kernel@...r.kernel.org; Jerome Marchand; Sergey Senozhatsky;
> Andrew Morton
> Subject: Re: [PATCH] zram: fix incorrectly stat with failed_reads
> 
> On Mon, Aug 11, 2014 at 04:39:17PM +0800, Chao Yu wrote:
> > Since we allocate a temporary buffer in zram_bvec_read to handle partial page
> > operations in this commit 924bd88d703e53d30f393fac6117f8f1bc79aab6 (Staging:
> > zram: allow partial page operations), our ->failed_reads value may be incorrect
> > as we do not increase its value when failed to allocate the temporary buffer.
> >
> > Let's fix this issue and correct the annotation of failed_reads.
> 
> Good catch.
> Just out of curiosity.
> 
> Did you catch it by code review or real workload?

I found this one by code review.

> 
> >
> > Signed-off-by: Chao Yu <chao2.yu@...sung.com>
> > ---
> >  drivers/block/zram/zram_drv.c | 1 +
> >  drivers/block/zram/zram_drv.h | 2 +-
> >  2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index dfa4024..bf8ea1b 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -413,6 +413,7 @@ static int zram_bvec_read(struct zram *zram, struct bio_vec *bvec,
> >
> >  	if (!uncmem) {
> >  		pr_info("Unable to allocate temp memory\n");
> > +		atomic64_inc(&zram->stats.failed_reads);
> >  		ret = -ENOMEM;
> >  		goto out_cleanup;
> >  	}
> > diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
> > index 5b0afde..e0f725c 100644
> > --- a/drivers/block/zram/zram_drv.h
> > +++ b/drivers/block/zram/zram_drv.h
> > @@ -84,7 +84,7 @@ struct zram_stats {
> >  	atomic64_t compr_data_size;	/* compressed size of pages stored */
> >  	atomic64_t num_reads;	/* failed + successful */
> >  	atomic64_t num_writes;	/* --do-- */
> > -	atomic64_t failed_reads;	/* should NEVER! happen */
> > +	atomic64_t failed_reads;	/* can happen when memory is too low */
> >  	atomic64_t failed_writes;	/* can happen when memory is too low */
> >  	atomic64_t invalid_io;	/* non-page-aligned I/O requests */
> >  	atomic64_t notify_free;	/* no. of swap slot free notifications */
> > --
> > 2.0.1.474.g72c7794
> 
> How abouting moving failed_reads/writes in zram_bvec_rw?

I think this implementation of yours is pretty clean and simple because this one
hides every error paths inside zram_bvec_{read,write}, so we do not need to
consider covering the stat code to everywhere of inside.

IMHO, your implementation also fixed the issue in following call chain:
->zram_bvec_rw
  ->zram_bvec_write
    ->zram_decompress_page
      ->atomic64_inc(failed_reads)    ---at perspective of user, this kind of
      failure should be regarded as the write one's, because user pay fewer
      attention to inner error of zram.

Please correct me if I'm wrong, and thanks for your review and suggestion. :)

Regards,
Yu

> 
> int zram_bvec_rw(..)
> {
>         if (rw == READ) {
>                 atomic64_inc(num_reads);
>                 ret = zram_bvec_read(xxx);
>         } else {
>                 atomic64_inc(&num_writes);
>                 ret = zram_bvec_write(xxx);
>         }
> 
>         if (unlikely(ret)) {
>                 if (rw == READ)
>                         atomic64_inc(failed_reads);
>                 else
>                         atomic64_inc(failed_writes);
>         }
> }
> 
> >
> >
> > --
> > 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/
> 
> --
> Kind regards,
> Minchan Kim

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ