When balloon batching is not supported by the hypervisor, the guest frame number (GFN) must fit in 32-bit. However, due to a bug, this check was mistakenly ignored. In practice, when total RAM is greater than 16TB, the balloon does not work currently, making this bug unlikely to happen.
Fixes: ef0f8f112984 ("VMware balloon: partially inline vmballoon_reserve_page.")
Cc: stable@vger.kernel.org Reviewed-by: Xavier Deguillard xdeguillard@vmware.com Signed-off-by: Nadav Amit namit@vmware.com --- drivers/misc/vmw_balloon.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c index efd733472a35..28e77ab1e136 100644 --- a/drivers/misc/vmw_balloon.c +++ b/drivers/misc/vmw_balloon.c @@ -450,7 +450,7 @@ static int vmballoon_send_lock_page(struct vmballoon *b, unsigned long pfn,
pfn32 = (u32)pfn; if (pfn32 != pfn) - return -1; + return -EINVAL;
STATS_INC(b->stats.lock[false]);
@@ -460,7 +460,7 @@ static int vmballoon_send_lock_page(struct vmballoon *b, unsigned long pfn,
pr_debug("%s - ppn %lx, hv returns %ld\n", __func__, pfn, status); STATS_INC(b->stats.lock_fail[false]); - return 1; + return -EIO; }
static int vmballoon_send_batched_lock(struct vmballoon *b, @@ -597,11 +597,12 @@ static int vmballoon_lock_page(struct vmballoon *b, unsigned int num_pages,
locked = vmballoon_send_lock_page(b, page_to_pfn(page), &hv_status, target); - if (locked > 0) { + if (locked) { STATS_INC(b->stats.refused_alloc[false]);
- if (hv_status == VMW_BALLOON_ERROR_RESET || - hv_status == VMW_BALLOON_ERROR_PPN_NOTNEEDED) { + if (locked == -EIO && + (hv_status == VMW_BALLOON_ERROR_RESET || + hv_status == VMW_BALLOON_ERROR_PPN_NOTNEEDED)) { vmballoon_free_page(page, false); return -EIO; } @@ -617,7 +618,7 @@ static int vmballoon_lock_page(struct vmballoon *b, unsigned int num_pages, } else { vmballoon_free_page(page, false); } - return -EIO; + return locked; }
/* track allocated page */
On Wed, Jun 13, 2018 at 06:54:06AM -0700, Nadav Amit wrote:
When balloon batching is not supported by the hypervisor, the guest frame number (GFN) must fit in 32-bit. However, due to a bug, this check was mistakenly ignored. In practice, when total RAM is greater than 16TB, the balloon does not work currently, making this bug unlikely to happen.
Fixes: ef0f8f112984 ("VMware balloon: partially inline vmballoon_reserve_page.")
Cc: stable@vger.kernel.org
Again, no blank line between these things.
Also, please break this up into two different patch series. One for 4.18-final and one for 4.19-rc1. You should always split up bugfixes from new features/cleanups as that is what I have to do when sending them to Linus.
thanks,
greg k-h
at 10:23 PM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Wed, Jun 13, 2018 at 06:54:06AM -0700, Nadav Amit wrote:
When balloon batching is not supported by the hypervisor, the guest frame number (GFN) must fit in 32-bit. However, due to a bug, this check was mistakenly ignored. In practice, when total RAM is greater than 16TB, the balloon does not work currently, making this bug unlikely to happen.
Fixes: ef0f8f112984 ("VMware balloon: partially inline vmballoon_reserve_page.")
Cc: stable@vger.kernel.org
Again, no blank line between these things.
Also, please break this up into two different patch series. One for 4.18-final and one for 4.19-rc1. You should always split up bugfixes from new features/cleanups as that is what I have to do when sending them to Linus.
I have only sent what I thought is appropriate for 4.18 (cleanup/features will be sent separately):
* 5 bug fixes (1-5/7) * 1 update the maintainer list (7/7) * 1 update to the comment to prevent checkpatch from complaining (6/7)
If you think any patch is unsuitable to 4.18 - please say which.
Thanks, Nadav
On Thu, Jun 14, 2018 at 05:41:01AM +0000, Nadav Amit wrote:
at 10:23 PM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Wed, Jun 13, 2018 at 06:54:06AM -0700, Nadav Amit wrote:
When balloon batching is not supported by the hypervisor, the guest frame number (GFN) must fit in 32-bit. However, due to a bug, this check was mistakenly ignored. In practice, when total RAM is greater than 16TB, the balloon does not work currently, making this bug unlikely to happen.
Fixes: ef0f8f112984 ("VMware balloon: partially inline vmballoon_reserve_page.")
Cc: stable@vger.kernel.org
Again, no blank line between these things.
Also, please break this up into two different patch series. One for 4.18-final and one for 4.19-rc1. You should always split up bugfixes from new features/cleanups as that is what I have to do when sending them to Linus.
I have only sent what I thought is appropriate for 4.18 (cleanup/features will be sent separately):
- 5 bug fixes (1-5/7)
- 1 update the maintainer list (7/7)
- 1 update to the comment to prevent checkpatch from complaining (6/7)
If you think any patch is unsuitable to 4.18 - please say which.
How do I know which patch goes to which branch? Please make it so obvious I can not get it wrong. Remember, I get 1000 emails a day, you don't want me to have to make a judgement call about anything, as I will mess it up :)
thanks,
greg k-h
at 10:50 PM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Thu, Jun 14, 2018 at 05:41:01AM +0000, Nadav Amit wrote:
at 10:23 PM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Wed, Jun 13, 2018 at 06:54:06AM -0700, Nadav Amit wrote:
When balloon batching is not supported by the hypervisor, the guest frame number (GFN) must fit in 32-bit. However, due to a bug, this check was mistakenly ignored. In practice, when total RAM is greater than 16TB, the balloon does not work currently, making this bug unlikely to happen.
Fixes: ef0f8f112984 ("VMware balloon: partially inline vmballoon_reserve_page.")
Cc: stable@vger.kernel.org
Again, no blank line between these things.
Also, please break this up into two different patch series. One for 4.18-final and one for 4.19-rc1. You should always split up bugfixes from new features/cleanups as that is what I have to do when sending them to Linus.
I have only sent what I thought is appropriate for 4.18 (cleanup/features will be sent separately):
- 5 bug fixes (1-5/7)
- 1 update the maintainer list (7/7)
- 1 update to the comment to prevent checkpatch from complaining (6/7)
If you think any patch is unsuitable to 4.18 - please say which.
How do I know which patch goes to which branch? Please make it so obvious I can not get it wrong. Remember, I get 1000 emails a day, you don't want me to have to make a judgement call about anything, as I will mess it up :)
I appreciate your time, and understand you even need to read students’ dissertations. ;-)
I will write it clearly in the cover-letter in the next version, and move the license changes to 4.19.
Thanks, Nadav
linux-stable-mirror@lists.linaro.org
-
Greg Kroah-Hartman -
Nadav Amit