[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130712201703.GB7729@decadent.org.uk>
Date: Fri, 12 Jul 2013 21:17:03 +0100
From: Ben Hutchings <ben@...adent.org.uk>
To: "K. Y. Srinivasan" <kys@...rosoft.com>
Cc: gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
devel@...uxdriverproject.org, olaf@...fle.de, apw@...onical.com,
jasowang@...hat.com, Stable <stable@...r.kernel.org>
Subject: Re: [PATCH 1/2] Drivers: hv: balloon: Fix a bug in the hot-add code
On Fri, Jul 12, 2013 at 06:56:14AM -0700, K. Y. Srinivasan wrote:
> As we hot-add 128 MB chunks of memory, we wait to ensure that the memory
> is onlined before attempting to hot-add the next chunk. If the udev rule for
> memory hot-add is not executed within the allowed time, we would rollback the
> state and abort further hot-add. Since the hot-add has succeeded and the only
> failure is that the memory is not onlined within the allowed time, we should not
> be rolling back the state. Fix this bug.
[...]
> /*
> * Wait for the memory block to be onlined.
> */
> - t = wait_for_completion_timeout(&dm_device.ol_waitevent, 5*HZ);
> - if (t == 0) {
> - pr_info("hot_add memory timedout\n");
> - has->ha_end_pfn -= HA_CHUNK;
> - has->covered_end_pfn -= processed_pfn;
> - break;
> - }
> + wait_for_completion_timeout(&dm_device.ol_waitevent, 5*HZ);
>
> }
>
Well now it might look like a bug that you don't test the result
of wait_for_completion_timeout(). Maybe update the comment to
explain why it's OK to continue anyway?
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
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