view Documentation/SecurityBugs @ 897:329ea0ccb344

balloon: try harder to balloon up under memory pressure.

Currently if the balloon driver is unable to increase the guest's
reservation it assumes the failure was due to reaching its full
allocation, gives up on the ballooning operation and records the limit
it reached as the "hard limit". The driver will not try again until
the target is set again (even to the same value).

However it is possible that ballooning has in fact failed due to
memory pressure in the host and therefore it is desirable to keep
attempting to reach the target in case memory becomes available. The
most likely scenario is that some guests are ballooning down while
others are ballooning up and therefore there is temporary memory
pressure while things stabilise. You would not expect a well behaved
toolstack to ask a domain to balloon to more than its allocation nor
would you expect it to deliberately over-commit memory by setting
balloon targets which exceed the total host memory.

This patch drops the concept of a hard limit and causes the balloon
driver to retry increasing the reservation on a timer in the same
manner as when decreasing the reservation.

Also if we partially succeed in increasing the reservation
(i.e. receive less pages than we asked for) then we may as well keep
those pages rather than returning them to Xen.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
author Keir Fraser <keir.fraser@citrix.com>
date Fri Jun 05 14:01:20 2009 +0100 (2009-06-05)
parents 831230e53067
line source
1 Linux kernel developers take security very seriously. As such, we'd
2 like to know when a security bug is found so that it can be fixed and
3 disclosed as quickly as possible. Please report security bugs to the
4 Linux kernel security team.
6 1) Contact
8 The Linux kernel security team can be contacted by email at
9 <security@kernel.org>. This is a private list of security officers
10 who will help verify the bug report and develop and release a fix.
11 It is possible that the security team will bring in extra help from
12 area maintainers to understand and fix the security vulnerability.
14 As it is with any bug, the more information provided the easier it
15 will be to diagnose and fix. Please review the procedure outlined in
16 REPORTING-BUGS if you are unclear about what information is helpful.
17 Any exploit code is very helpful and will not be released without
18 consent from the reporter unless it has already been made public.
20 2) Disclosure
22 The goal of the Linux kernel security team is to work with the
23 bug submitter to bug resolution as well as disclosure. We prefer
24 to fully disclose the bug as soon as possible. It is reasonable to
25 delay disclosure when the bug or the fix is not yet fully understood,
26 the solution is not well-tested or for vendor coordination. However, we
27 expect these delays to be short, measurable in days, not weeks or months.
28 A disclosure date is negotiated by the security team working with the
29 bug submitter as well as vendors. However, the kernel security team
30 holds the final say when setting a disclosure date. The timeframe for
31 disclosure is from immediate (esp. if it's already publically known)
32 to a few weeks. As a basic default policy, we expect report date to
33 disclosure date to be on the order of 7 days.
35 3) Non-disclosure agreements
37 The Linux kernel security team is not a formal body and therefore unable
38 to enter any non-disclosure agreements.