All of lore.kernel.org
 help / color / mirror / Atom feed
From: Evan Green <evgreen@chromium.org>
To: Pavel Machek <pavel@ucw.cz>, "Rafael J . Wysocki" <rafael@kernel.org>
Cc: Evan Green <evgreen@chromium.org>,
	Len Brown <len.brown@intel.com>,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: [PATCH] PM / hibernate: Fix snapshot partial write lengths
Date: Fri, 29 Oct 2021 12:24:22 -0700	[thread overview]
Message-ID: <20211029122359.1.I1e23f382fbd8beb19fe1c06d70798b292012c57a@changeid> (raw)

snapshot_write() is inappropriately limiting the amount of data that can
be written in cases where a partial page has already been written. For
example, one would expect to be able to write 1 byte, then 4095 bytes to
the snapshot device, and have both of those complete fully (since now
we're aligned to a page again). But what ends up happening is we write 1
byte, then 4094/4095 bytes complete successfully.

The reason is that simple_write_to_buffer()'s second argument is the
total size of the buffer, not the size of the buffer minus the offset.
Since simple_write_to_buffer() accounts for the offset in its
implementation, snapshot_write() can just pass the full page size
directly down.

Signed-off-by: Evan Green <evgreen@chromium.org>
---

 kernel/power/user.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/power/user.c b/kernel/power/user.c
index 740723bb388524..ad241b4ff64c58 100644
--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -177,7 +177,7 @@ static ssize_t snapshot_write(struct file *filp, const char __user *buf,
 		if (res <= 0)
 			goto unlock;
 	} else {
-		res = PAGE_SIZE - pg_offp;
+		res = PAGE_SIZE;
 	}
 
 	if (!data_of(data->handle)) {
-- 
2.31.0


             reply	other threads:[~2021-10-29 19:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-29 19:24 Evan Green [this message]
2021-11-15 17:12 ` [PATCH] PM / hibernate: Fix snapshot partial write lengths Evan Green
2021-11-16 17:54   ` Rafael J. Wysocki
2021-11-16 20:22     ` Evan Green
2021-11-24 12:54       ` Rafael J. Wysocki
2021-11-29 16:50         ` Evan Green
2021-11-30  6:51           ` Greg KH
2021-11-30 11:46           ` Rafael J. Wysocki
2021-11-30 17:44             ` Evan Green

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=20211029122359.1.I1e23f382fbd8beb19fe1c06d70798b292012c57a@changeid \
    --to=evgreen@chromium.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rafael@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.