23 Apr, 2011

4 commits

  • Right now all RCU walks fall back to reference walk when CONFIG_SECURITY
    is enabled, even though just the standard capability module is active.
    This is because security_inode_exec_permission unconditionally fails
    RCU walks.

    Move this decision to the low level security module. This requires
    passing the RCU flags down the security hook. This way at least
    the capability module and a few easy cases in selinux/smack work
    with RCU walks with CONFIG_SECURITY=y

    Signed-off-by: Andi Kleen
    Acked-by: Eric Paris
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
    ALSA: hda - Fix unused warnings when !SND_HDA_NEEDS_RESUME
    ALSA: hda - Add a fix-up for Acer dmic with ALC271x codec
    ASoC: add a module alias to the FSI driver
    ALSA: emu10k1 - Fix "Music" controls to "Synth" controls in documents
    ARM: s3c2440: gta02; Register dfbmcs320 device for BT audio interface
    ASoC: codecs: JZ4740: Fix OOPS
    ASoC: Fix output PGA enabling in wm_hubs CODECs
    ASoC: sn95031: decorate function with __devexit_p()
    ASoC: SAMSUNG: Fix the inverted clocks handling for pcm driver
    ASoC: sst_platform: Fix lock acquring
    ASoC: fsi: driver safely remove for against irq
    ASoC: fsi: modify vague PM control on probe
    ASoC: fsi: take care in failing case of dai register
    MAINTAINERS: Update Samsung ASoC maintainer's id
    ASoC: WM8903: HP and Line out PGA/mixer DAPM fixes
    ASoC: Set left channel volume update bits for WM8994
    ASoC: fix config error path
    ASoC: check channel mismatch between cpu_dai and codec_dai
    ASoC: Tegra: Suspend/resume support

    Linus Torvalds
     
  • …/git/tip/linux-2.6-tip

    * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    perf, x86: Update/fix Intel Nehalem cache events
    perf, x86: P4 PMU - Don't forget to clear cpuc->active_mask on overflow
    x86, perf event: Turn off unstructured raw event access to offcore registers
    perf: Support Xeon E7's via the Westmere PMU driver

    Linus Torvalds
     
  • …git/tip/linux-2.6-tip

    * 'irq-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    xtensa: Fixup irq conversion fallout and nmi_count

    Linus Torvalds
     

22 Apr, 2011

15 commits

  • Change the Nehalem cache events to use retired memory instruction counters
    (similar to Westmere), this greatly improves the provided stats.

    Using:

    main ()
    {
    int i;

    for (i = 0; i < 1000000000; i++) {
    asm("mov (%%rsp), %%rbx;"
    "mov %%rbx, (%%rsp);" : : : "rbx");
    }
    }

    We find:

    $ perf stat --repeat 10 -e instructions:u -e l1-dcache-loads:u -e l1-dcache-stores:u ./loop_1b_loads+stores
    Performance counter stats for './loop_1b_loads+stores' (10 runs):
    4,000,081,056 instructions:u # 0.000 IPC ( +- 0.000% )
    4,999,502,846 l1-dcache-loads:u ( +- 0.008% )
    1,000,034,832 l1-dcache-stores:u ( +- 0.000% )
    1.565184942 seconds time elapsed ( +- 0.005% )

    The 5b is surprising - we'd expect 1b:

    $ perf stat --repeat 10 -e instructions:u -e r10b:u -e l1-dcache-stores:u ./loop_1b_loads+stores
    Performance counter stats for './loop_1b_loads+stores' (10 runs):
    4,000,081,054 instructions:u # 0.000 IPC ( +- 0.000% )
    1,000,021,961 r10b:u ( +- 0.000% )
    1,000,030,951 l1-dcache-stores:u ( +- 0.000% )
    1.565055422 seconds time elapsed ( +- 0.003% )

    Which this patch thus fixes.

    Signed-off-by: Peter Zijlstra
    Cc: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Frederic Weisbecker
    Cc: Paul Mackerras
    Cc: Mike Galbraith
    Cc: Steven Rostedt
    Cc: Stephane Eranian
    Cc: Lin Ming
    Cc: Cyrill Gorcunov
    Link: http://lkml.kernel.org/n/tip-q9rtru7b7840tws75xzboapv@git.kernel.org
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     
  • It's not enough to simply disable event on overflow the
    cpuc->active_mask should be cleared as well otherwise counter
    may stall in "active" even in real being already disabled (which
    potentially may lead to the situation that user may not use this
    counter further).

    Don pointed out that:

    " I also noticed this patch fixed some unknown NMIs
    on a P4 when I stressed the box".

    Tested-by: Lin Ming
    Signed-off-by: Cyrill Gorcunov
    Acked-by: Don Zickus
    Signed-off-by: Don Zickus
    Cc: Cyrill Gorcunov
    Link: http://lkml.kernel.org/r/1303398203-2918-3-git-send-email-dzickus@redhat.com
    Signed-off-by: Ingo Molnar

    Cyrill Gorcunov
     
  • Andi Kleen pointed out that the Intel offcore support patches were merged
    without user-space tool support to the functionality:

    |
    | The offcore_msr perf kernel code was merged into 2.6.39-rc*, but the
    | user space bits were not. This made it impossible to set the extra mask
    | and actually do the OFFCORE profiling
    |

    Andi submitted a preliminary patch for user-space support, as an
    extension to perf's raw event syntax:

    |
    | Some raw events -- like the Intel OFFCORE events -- support additional
    | parameters. These can be appended after a ':'.
    |
    | For example on a multi socket Intel Nehalem:
    |
    | perf stat -e r1b7:20ff -a sleep 1
    |
    | Profile the OFFCORE_RESPONSE.ANY_REQUEST with event mask REMOTE_DRAM_0
    | that measures any access to DRAM on another socket.
    |

    But this kind of usability is absolutely unacceptable - users should not
    be expected to type in magic, CPU and model specific incantations to get
    access to useful hardware functionality.

    The proper solution is to expose useful offcore functionality via
    generalized events - that way users do not have to care which specific
    CPU model they are using, they can use the conceptual event and not some
    model specific quirky hexa number.

    We already have such generalization in place for CPU cache events,
    and it's all very extensible.

    "Offcore" events measure general DRAM access patters along various
    parameters. They are particularly useful in NUMA systems.

    We want to support them via generalized DRAM events: either as the
    fourth level of cache (after the last-level cache), or as a separate
    generalization category.

    That way user-space support would be very obvious, memory access
    profiling could be done via self-explanatory commands like:

    perf record -e dram ./myapp
    perf record -e dram-remote ./myapp

    ... to measure DRAM accesses or more expensive cross-node NUMA DRAM
    accesses.

    These generalized events would work on all CPUs and architectures that
    have comparable PMU features.

    ( Note, these are just examples: actual implementation could have more
    sophistication and more parameter - as long as they center around
    similarly simple usecases. )

    Now we do not want to revert *all* of the current offcore bits, as they
    are still somewhat useful for generic last-level-cache events, implemented
    in this commit:

    e994d7d23a0b: perf: Fix LLC-* events on Intel Nehalem/Westmere

    But we definitely do not yet want to expose the unstructured raw events
    to user-space, until better generalization and usability is implemented
    for these hardware event features.

    ( Note: after generalization has been implemented raw offcore events can be
    supported as well: there can always be an odd event that is marginally
    useful but not useful enough to generalize. DRAM profiling is definitely
    *not* such a category so generalization must be done first. )

    Furthermore, PERF_TYPE_RAW access to these registers was not intended
    to go upstream without proper support - it was a side-effect of the above
    e994d7d23a0b commit, not mentioned in the changelog.

    As v2.6.39 is nearing release we go for the simplest approach: disable
    the PERF_TYPE_RAW offcore hack for now, before it escapes into a released
    kernel and becomes an ABI.

    Once proper structure is implemented for these hardware events and users
    are offered usable solutions we can revisit this issue.

    Reported-by: Andi Kleen
    Acked-by: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Frederic Weisbecker
    Cc: Thomas Gleixner
    Cc: Linus Torvalds
    Link: http://lkml.kernel.org/r/1302658203-4239-1-git-send-email-andi@firstfloor.org
    Signed-off-by: Ingo Molnar

    Ingo Molnar
     
  • There's a new model number public, 47, for Xeon E7 (aka Westmere EX).

    Signed-off-by: Andi Kleen
    Cc: a.p.zijlstra@chello.nl
    Link: http://lkml.kernel.org/r/1303429715-10202-1-git-send-email-andi@firstfloor.org
    Signed-off-by: Ingo Molnar

    Andi Kleen
     
  • * 'for-linus' of git://git.kernel.dk/linux-2.6-block:
    ide: unexport DISK_EVENT_MEDIA_CHANGE for ide-gd and ide-cd
    block: don't propagate unlisted DISK_EVENTs to userland
    elevator: check for ELEVATOR_INSERT_SORT_MERGE in !elvpriv case too

    Linus Torvalds
     
  • check_events() implementations in both ide-gd and ide-cd are
    inadequate for in-kernel event polling. Both generate media change
    events continuously when certain conditions are met causing infinite
    event loop between the driver and userland event handler.

    As disk event now supports suppression of unlisted events, simply
    de-listing DISK_EVENT_MEDIA_CHANGE from disk->events resolves the
    problem. Internal handling around media revalidation will behave the
    same while userland will fall back to userland event polling after
    detecting the device doesn't support disk events.

    Signed-off-by: Tejun Heo
    Reported-by: Jens Axboe
    Acked-by: "David S. Miller"
    Signed-off-by: Jens Axboe

    Tejun Heo
     
  • DISK_EVENT_MEDIA_CHANGE is used for both userland visible event and
    internal event for revalidation of removeable devices. Some legacy
    drivers don't implement proper event detection and continuously
    generate events under certain circumstances. For example, ide-cd
    generates media changed continuously if there's no media in the drive,
    which can lead to infinite loop of events jumping back and forth
    between the driver and userland event handler.

    This patch updates disk event infrastructure such that it never
    propagates events not listed in disk->events to userland. Those
    events are processed the same for internal purposes but uevent
    generation is suppressed.

    This also ensures that userland only gets events which are advertised
    in the @events sysfs node lowering risk of confusion.

    Signed-off-by: Tejun Heo
    Signed-off-by: Jens Axboe

    Tejun Heo
     
  • The sort insert is the one that goes to the IO scheduler. With
    the SORT_MERGE addition, we could bypass IO scheduler setup
    but still ask the IO scheduler to insert the request. This would
    cause an oops on switching IO schedulers through the sysfs
    interface, unless the disk just happened to be idle while it
    occured.

    Signed-off-by: Jens Axboe

    Jens Axboe
     
  • * 'for-linus' of git://oss.sgi.com/xfs/xfs:
    xfs: fix duplicate message output

    Linus Torvalds
     
  • …git/tip/linux-2.6-tip

    * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    x86, numa: Fix cpu nodemasks for NUMA emulation and CONFIG_DEBUG_PER_CPU_MAPS
    Revert "x86, NUMA: Fix fakenuma boot failure"

    Linus Torvalds
     
  • Change from unsigned long long to sector_t.
    This matches its source field.

    ERROR: "__udivdi3" [drivers/md/raid456.ko] undefined!

    Signed-off-by: Randy Dunlap
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus:
    virtio: console: Enable call to hvc_remove() on console port remove
    virtio_pci: Prevent double-free of pci regions after device hot-unplug
    virtio: Decrement avail idx on buffer detach

    Linus Torvalds
     
  • * 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
    agp: fix arbitrary kernel memory writes
    agp: fix OOM and buffer overflow
    drm/radeon/kms: fix IH writeback on r6xx+ on big endian machines

    Linus Torvalds
     
  • * 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
    drm/i915: Initialise g4x watermarks for disabled pipes
    drm/i915: Sanitize the output registers after resume
    drm/i915/tv: Fix modeset flickering introduced in 7f58aabc3
    drm/i915/tv: Only poll for TV connections
    drm/i915/tv: Remember the detected TV type

    Linus Torvalds
     
  • * git://git.infradead.org/iommu-2.6:
    intel_iommu: disable all VT-d PMRs when TXT launched
    intel-iommu: Fix get_domain_for_dev() error path
    intel-iommu: Unlink domain from iommu
    intel-iommu: Fix use after release during device attach

    Linus Torvalds
     

21 Apr, 2011

18 commits

  • For some reason generic_setxattr() did not pass flags (XATTR_CREATE,
    XATTR_REPLACE) to the filesystem specific helper. This caused that
    setxattr(2) syscall just ignored these flags.

    Fix the bug by passing flags correctly.

    Signed-off-by: Jan Kara
    Acked-by: Christoph Hellwig
    Signed-off-by: Linus Torvalds

    Jan Kara
     
  • This call was disabled as hot-unplugging one virtconsole port led to
    another virtconsole port freezing.

    Upon testing it again, this now works, so enable it.

    In addition, a bug was found in qemu wherein removing a port of one type
    caused the guest output from another port to stop working. I doubt it
    was just this bug that caused it (since disabling the hvc_remove() call
    did allow other ports to continue working), but since it's all solved
    now, we're fine with hot-unplugging of virtconsole ports.

    Signed-off-by: Amit Shah
    Signed-off-by: Rusty Russell

    Amit Shah
     
  • In the case where a virtio-console port is in use (opened by a program)
    and a virtio-console device is removed, the port is kept around but all
    the virtio-related state is assumed to be gone.

    When the port is finally released (close() called), we call
    device_destroy() on the port's device. This results in the parent
    device's structures to be freed as well. This includes the PCI regions
    for the virtio-console PCI device.

    Once this is done, however, virtio_pci_release_dev() kicks in, as the
    last ref to the virtio device is now gone, and attempts to do

    pci_iounmap(pci_dev, vp_dev->ioaddr);
    pci_release_regions(pci_dev);
    pci_disable_device(pci_dev);

    which results in a double-free warning.

    Move the code that releases regions, etc., to the virtio_pci_remove()
    function, and all that's now left in release_dev is the final freeing of
    the vp_dev.

    Signed-off-by: Amit Shah
    Signed-off-by: Rusty Russell

    Amit Shah
     
  • When detaching a buffer from a vq, the avail.idx value should be
    decremented as well.

    This was noticed by hot-unplugging a virtio console port and then
    plugging in a new one on the same number (re-using the vqs which were
    just 'disowned'). qemu reported

    'Guest moved used index from 0 to 256'

    when any IO was attempted on the new port.

    CC: stable@kernel.org
    Reported-by: juzhang
    Signed-off-by: Amit Shah
    Signed-off-by: Rusty Russell

    Amit Shah
     
  • Intel VT-d Protected Memory Regions (PMRs) are supposed to be disabled,
    on each VT-d engine, after DMA remapping is enabled on the engines.
    This is because the behavior of having both enabled is not deterministic
    and because, if TXT has been used to launch the kernel, the PMRs may be
    programmed to cover memory regions that will be used for DMA.

    Under some circumstances (certain quirks detected, lack of multiple
    devices, etc.), the current code does not set up DMA remapping on some
    VT-d engines. In such cases it also skips disabling the PMRs. This
    causes failures when the kernel is launched with TXT (most often this
    occurs on the graphics engine and results in colored vertical bars on
    the display).

    This patch detects when the kernel has been launched with TXT and then
    disables the PMRs on all VT-d engines. In some cases where the reason
    that remapping is not being enabled is due to possible ACPI DMAR table
    errors, the VT-d engine addresses may not be correct and thus not able
    to be safely programmed even to disable PMRs. Because part of the TXT
    launch process is the verification of these addresses, it will always be
    safe to disable PMRs if the TXT launch has succeeded and hence only
    doing this in such cases.

    Signed-off-by: Joseph Cihula
    Signed-off-by: David Woodhouse

    Joseph Cihula
     
  • Takashi Iwai
     
  • The cpunode mappings under CONFIG_DEBUG_PER_CPU_MAPS=y
    when NUMA emulation is enabled is currently broken because it does
    not iterate through every emulated node and bind cpus that have
    affinity to it.

    NUMA emulation should bind each cpu to every local node to
    accurately represent the true NUMA topology of the underlying
    machine.

    debug_cpumask_set_cpu() needs to be fixed at the same time so
    that the debugging information that it emits shows the new
    cpumask of the node being assigned when the cpu is being added
    or removed.

    It can now take responsibility of setting or clearing the cpu
    itself to remove the need for duplicate code.

    Also change its last parameter, "enable", to have the correct bool
    type since it can only be true or false.

    -v2: Fix the return statements, by Kosaki Motohiro

    Acked-and-Tested-by: KOSAKI Motohiro
    Signed-off-by: David Rientjes
    Cc: Andreas Herrmann
    Cc: Tejun Heo
    Cc: Linus Torvalds
    Link: http://lkml.kernel.org/r/alpine.DEB.2.00.1104201918470.12634@chino.kir.corp.google.com
    Signed-off-by: Ingo Molnar

    David Rientjes
     
  • Andreas Herrmann reported that 7d6b46707f24 ("x86, NUMA: Fix fakenuma
    boot failure") causes certain physical NUMA topologies (for example
    AMD Magny-Cours) to move sibling cpus to a single node when in reality
    they are in separate domains.

    This may result in some nodes being completely void of cpus, which
    doesn't accurately represent the correct topology. The system will
    boot, but will have suboptimal NUMA performance.

    This commit was intended as a fix for NUMA emulation, but should
    not cause a regression for real NUMA machines as a side effect.

    ( There will be a separate fix for the numa-debug code, which
    will not affect physical topologies. )

    Reported-by: Andreas Herrmann
    Signed-off-by: David Rientjes
    Acked-by: KOSAKI Motohiro
    Cc: Tejun Heo
    Cc: Linus Torvalds
    Link: http://lkml.kernel.org/r/alpine.DEB.2.00.1104201918110.12634@chino.kir.corp.google.com
    Signed-off-by: Ingo Molnar

    David Rientjes
     
  • pg_start is copied from userspace on AGPIOC_BIND and AGPIOC_UNBIND ioctl
    cmds of agp_ioctl() and passed to agpioc_bind_wrap(). As said in the
    comment, (pg_start + mem->page_count) may wrap in case of AGPIOC_BIND,
    and it is not checked at all in case of AGPIOC_UNBIND. As a result, user
    with sufficient privileges (usually "video" group) may generate either
    local DoS or privilege escalation.

    Signed-off-by: Vasiliy Kulikov
    Signed-off-by: Dave Airlie

    Vasiliy Kulikov
     
  • page_count is copied from userspace. agp_allocate_memory() tries to
    check whether this number is too big, but doesn't take into account the
    wrap case. Also agp_create_user_memory() doesn't check whether
    alloc_size is calculated from num_agp_pages variable without overflow.
    This may lead to allocation of too small buffer with following buffer
    overflow.

    Another problem in agp code is not addressed in the patch - kernel memory
    exhaustion (AGPIOC_RESERVE and AGPIOC_ALLOCATE ioctls). It is not checked
    whether requested pid is a pid of the caller (no check in agpioc_reserve_wrap()).
    Each allocation is limited to 16KB, though, there is no per-process limit.
    This might lead to OOM situation, which is not even solved in case of the
    caller death by OOM killer - the memory is allocated for another (faked) process.

    Signed-off-by: Vasiliy Kulikov
    Signed-off-by: Dave Airlie

    Vasiliy Kulikov
     
  • * 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/staging:
    hwmon: (max34440) Add driver documentation
    hwmon: (max16064) Add driver documentation
    hwmon: (max8688) Add driver documentation
    hwmon: (pmbus) Documentation updates
    hwmon: (smm665) Fix spelling error in driver documentation
    hwmon: (pmbus) Removed unused variable from struct pmbus_data
    hwmon: Add submitting-patches checklist to documentation

    Linus Torvalds
     
  • * 'for-2.6.39' of git://linux-nfs.org/~bfields/linux:
    Open with O_CREAT flag set fails to open existing files on non writable directories
    nfsd4: Fix filp leak
    nfsd4: fix struct file leak on delegation

    Linus Torvalds
     
  • * 'fixes' of master.kernel.org:/home/rmk/linux-2.6-arm:
    ARM: 6881/1: cputype.h uses __attribute_const__ which requires including kernel.h
    ARM: Add new syscalls

    Linus Torvalds
     
  • * 'stable/bug-fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
    xen: mask_rw_pte: do not apply the early_ioremap checks on x86_32
    xen: do not create the extra e820 region at an addr lower than 4G

    Linus Torvalds
     
  • * 'for-linus' of git://neil.brown.name/md:
    md: Update documentation for sync_min and sync_max entries
    md: Cleanup after raid45->raid0 takeover
    md: Fix dev_sectors on takeover from raid0 to raid4/5
    md/raid5: remove setting of ->queue_lock

    Linus Torvalds
     
  • When SND_HDA_NEEDS_RESUME is not defined, the compiler identifies that
    the following symbols are static but not used:

    restore_shutup_pins
    hda_cleanup_all_streams

    Fix warnings by adding SND_HDA_NEEDS_RESUME guards.

    Signed-off-by: Mike Waychison
    Signed-off-by: Takashi Iwai

    Mike Waychison
     
  • * 'for-linus' of git://git.kernel.dk/linux-2.6-block:
    block: Remove the extra check in queue_requests_store
    block, blk-sysfs: Fix an err return path in blk_register_queue()
    block: remove stale kerneldoc member from __blk_run_queue()
    block: get rid of QUEUE_FLAG_REENTER
    cfq-iosched: read_lock() does not always imply rcu_read_lock()
    block: kill blk_flush_plug_list() export

    Linus Torvalds
     
  • Commit 957935dc ("xfs: fix xfs_debug warnings" broke the logic in
    __xfs_printk(). Instead of only printing one of two possible output
    strings based on whether the fs has a name or not, it outputs both.
    Fix it to only output one message again.

    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig
    Signed-off-by: Alex Elder

    Dave Chinner
     

20 Apr, 2011

3 commits

  • An open on a NFS4 share using the O_CREAT flag on an existing file for
    which we have permissions to open but contained in a directory with no
    write permissions will fail with EACCES.

    A tcpdump shows that the client had set the open mode to UNCHECKED which
    indicates that the file should be created if it doesn't exist and
    encountering an existing flag is not an error. Since in this case the
    file exists and can be opened by the user, the NFS server is wrong in
    attempting to check create permissions on the parent directory.

    The patch adds a conditional statement to check for create permissions
    only if the file doesn't exist.

    Signed-off-by: Sachin S. Prabhu
    Signed-off-by: J. Bruce Fields

    Sachin Prabhu
     
  • The two "is_early_ioremap_ptep" checks in mask_rw_pte are only used on
    x86_64, in fact early_ioremap is not used at all to setup the initial
    pagetable on x86_32.
    Moreover on x86_32 the two checks are wrong because the range
    pgt_buf_start..pgt_buf_end initially should be mapped RW because
    the pages in the range are not pagetable pages yet and haven't been
    cleared yet. Afterwards considering the pgt_buf_start..pgt_buf_end is
    part of the initial mapping, xen_alloc_pte is capable of turning
    the ptes RO when they become pagetable pages.

    Fix the issue and improve the readability of the code providing two
    different implementation of mask_rw_pte for x86_32 and x86_64.

    Signed-off-by: Stefano Stabellini
    Signed-off-by: Konrad Rzeszutek Wilk

    Stefano Stabellini
     
  • Do not add the extra e820 region at a physical address lower than 4G
    because it breaks e820_end_of_low_ram_pfn().

    It is OK for us to move the xen_extra_mem_start up and down because this
    is the index of the memory that can be ballooned in/out - it is memory
    not available to the kernel during bootup.

    Signed-off-by: Stefano Stabellini
    Signed-off-by: Konrad Rzeszutek Wilk

    Stefano Stabellini