linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	Minchan Kim <minchan@kernel.org>, Nitin Gupta <ngupta@vflare.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCHv3 8/8] zram: correct typos
Date: Tue, 18 Oct 2022 11:10:15 +0900	[thread overview]
Message-ID: <Y04LB3/hLrG00Zln@google.com> (raw)
In-Reply-To: <20221017170844.3284c18376b16713c09b315b@linux-foundation.org>

On (22/10/17 17:08), Andrew Morton wrote:
> On Sun,  9 Oct 2022 18:07:20 +0900 Sergey Senozhatsky <senozhatsky@chromium.org> wrote:
> 
> > Trivial comment typos fixes.
> > 
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -759,7 +759,7 @@ static ssize_t writeback_store(struct device *dev,
> >  			zram_slot_unlock(zram, index);
> >  			/*
> >  			 * Return last IO error unless every IO were
> > -			 * not suceeded.
> > +			 * not succeeded.
> 
> That's a pretty awkward sentence.  Why not "unless every IO failed".
> 
> If that's indeed what we're doing here.  Sounds odd.  What do we return
> if all IOs indeed failed?

Hmm, yes, I didn't consider re-phrasing this comment but we probably
should do so. What we have there is

	while (nr_pages_to_write--) {
		err = submit_bio_wait();
		if (err) {
			ret = err;
			continue;
		}
	}
	return ret;

zram objects are independent and bio errors on individual writes are
non-fatal, if we failed to write-back a zram object (page) we just
continue and try to write the next one; at the same time we need to
signal user-space that some of those writes failed (doesn't matter
which ones or how many). That loop used to look as follows (as far
as I can tell):

	while (nr_pages_to_write--) {
		ret = submit_bio_wait();
	}
	return ret;

Notice how `ret' would get overwritten all the time, so we if we had,
say, a successful submit_bio_wait, then an unsuccessful one and a
successful one again, we would lose the track of the bio error that
happened on the second iteration and will always return 0 to user-space.
*Unless* the last (or all) submit_bio_wait() also failed, in which case
`ret' would hold the correct error code.

Will something like this look less awkward to you?

---

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index ecbc5963b5b8..23f1655b7837 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -758,8 +758,12 @@ static ssize_t writeback_store(struct device *dev,
 			zram_clear_flag(zram, index, ZRAM_IDLE);
 			zram_slot_unlock(zram, index);
 			/*
-			 * Return last IO error unless every IO were
-			 * not succeeded.
+			 * BIO errors are not fatal, we continue and simply
+			 * attempt to writeback the remaining objects (pages).
+			 * At the same time we need to signal user-space that
+			 * some writes (at least one, but also could be all of
+			 * them) were not successful and we do so by returning
+			 * the most recent BIO error.
 			 */
 			ret = err;
 			continue;


  reply	other threads:[~2022-10-18  2:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-09  9:07 [PATCHv3 0/8] zram: Support multiple compression streams Sergey Senozhatsky
2022-10-09  9:07 ` [PATCHv3 1/8] zram: Preparation for multi-zcomp support Sergey Senozhatsky
2022-10-09  9:07 ` [PATCHv3 2/8] zram: Add recompression algorithm sysfs knob Sergey Senozhatsky
2022-10-09  9:07 ` [PATCHv3 3/8] zram: Factor out WB and non-WB zram read functions Sergey Senozhatsky
2022-10-09  9:07 ` [PATCHv3 4/8] zram: Introduce recompress sysfs knob Sergey Senozhatsky
2022-10-18  0:08   ` Andrew Morton
2022-10-18  2:12     ` Sergey Senozhatsky
2022-10-18  2:42   ` Sergey Senozhatsky
2022-10-09  9:07 ` [PATCHv3 5/8] documentation: Add recompression documentation Sergey Senozhatsky
2022-10-18  2:22   ` Sergey Senozhatsky
2022-10-18  3:11     ` Andrew Morton
2022-10-18  2:50   ` Sergey Senozhatsky
2022-10-09  9:07 ` [PATCHv3 6/8] zram: Add recompression algorithm choice to Kconfig Sergey Senozhatsky
2022-10-18  3:07   ` Sergey Senozhatsky
2022-10-09  9:07 ` [PATCHv3 7/8] zram: Add recompress flag to read_block_state() Sergey Senozhatsky
2022-10-09  9:07 ` [PATCHv3 8/8] zram: correct typos Sergey Senozhatsky
2022-10-18  0:08   ` Andrew Morton
2022-10-18  2:10     ` Sergey Senozhatsky [this message]
2022-10-18  3:11 ` [PATCHv3 0/8] zram: Support multiple compression streams Sergey Senozhatsky

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=Y04LB3/hLrG00Zln@google.com \
    --to=senozhatsky@chromium.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=ngupta@vflare.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox