Commits on May 8, 2009
  1. @gregkh


    gregkh committed May 8, 2009
  2. @jkivilin @gregkh

    rndis_wlan: fix initialization order for workqueue&workers

    commit e805e4d upstream.
    rndis_wext_link_change() might be called from rndis_command() at
    initialization stage and priv->workqueue/priv->work have not been
    initialized yet. This causes invalid opcode at rndis_wext_bind on
    some brands of bcm4320.
    Fix by initializing workqueue/workers in rndis_wext_bind() before
    rndis_command is used.
    This bug has existed since 2.6.25, reported at:
    Signed-off-by: Jussi Kivilinna <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
    jkivilin committed with gregkh Apr 22, 2009
  3. @gregkh

    proc: avoid information leaks to non-privileged processes

    commit f83ce3e upstream.
    By using the same test as is used for /proc/pid/maps and /proc/pid/smaps,
    only allow processes that can ptrace() a given process to see information
    that might be used to bypass address space layout randomization (ASLR).
    These include eip, esp, wchan, and start_stack in /proc/pid/stat as well
    as the non-symbolic output from /proc/pid/wchan.
    ASLR can be bypassed by sampling eip as shown by the proof-of-concept
    code at As part of a presentation
    ( esp and wchan were
    also noted as possibly usable information leaks as well.  The
    start_stack address also leaks potentially useful information.
    Cc: Stable Team <>
    Signed-off-by: Jake Edge <>
    Acked-by: Arjan van de Ven <>
    Acked-by: "Eric W. Biederman" <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    Jake Edge committed with gregkh May 4, 2009
  4. @buytenh @gregkh

    mv643xx_eth: 64bit mib counter read fix

    commit 93af7ac upstream.
    On several mv643xx_eth hardware versions, the two 64bit mib counters
    for 'good octets received' and 'good octets sent' are actually 32bit
    counters, and reading from the upper half of the register has the same
    effect as reading from the lower half of the register: an atomic
    read-and-clear of the entire 32bit counter value.  This can under heavy
    traffic occasionally lead to small numbers being added to the upper
    half of the 64bit mib counter even though no 32bit wrap has occured.
    Since we poll the mib counters at least every 30 seconds anyway, we
    might as well just skip the reads of the upper halves of the hardware
    counters without breaking the stats, which this patch does.
    Signed-off-by: Lennert Buytenhek <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    buytenh committed with gregkh Apr 29, 2009
  5. @gormanm @gregkh

    Ignore madvise(MADV_WILLNEED) for hugetlbfs-backed regions

    commit a425a63 upstream.
    madvise(MADV_WILLNEED) forces page cache readahead on a range of memory
    backed by a file.  The assumption is made that the page required is
    order-0 and "normal" page cache.
    On hugetlbfs, this assumption is not true and order-0 pages are
    allocated and inserted into the hugetlbfs page cache.  This leaks
    hugetlbfs page reservations and can cause BUGs to trigger related to
    corrupted page tables.
    This patch causes MADV_WILLNEED to be ignored for hugetlbfs-backed
    Signed-off-by: Mel Gorman <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    gormanm committed with gregkh May 5, 2009
  6. @gregkh

    clockevents: prevent endless loop in tick_handle_periodic()

    commit 74a03b6 upstream.
    tick_handle_periodic() can lock up hard when a one shot clock event
    device is used in combination with jiffies clocksource.
    Avoid an endless loop issue by requiring that a highres valid
    clocksource be installed before we call tick_periodic() in a loop when
    using ONESHOT mode. The result is we will only increment jiffies once
    per interrupt until a continuous hardware clocksource is available.
    Without this, we can run into a endless loop, where each cycle through
    the loop, jiffies is updated which increments time by tick_period or
    more (due to clock steering), which can cause the event programming to
    think the next event was before the newly incremented time and fail
    causing tick_periodic() to be called again and the whole process loops
    [ Impact: prevent hard lock up ]
    Signed-off-by: John Stultz <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Thomas Gleixner <>
    Signed-off-by: Greg Kroah-Hartman <>
    john stultz committed with gregkh May 1, 2009
  7. @gregkh

    USB: serial: fix lifetime and locking problems

    This is commit 2d93148 back-ported to
    This patch (as1229-1) fixes a few lifetime and locking problems in the
    usb-serial driver.  The main symptom is that an invalid kevent is
    created when the serial device is unplugged while a connection is
    	Ports should be unregistered when device is disconnected,
    	not when the parent usb_serial structure is deallocated.
    	Each open file should hold a reference to the corresponding
    	port structure, and the reference should be released when
    	the file is closed.
    	serial->disc_mutex should be acquired in serial_open(), to
    	resolve the classic race between open and disconnect.
    	serial_close() doesn't need to hold both serial->disc_mutex
    	and port->mutex at the same time.
    	Release the subdriver's module reference only after releasing
    	all the other references, in case one of the release routines
    	needs to invoke some code in the subdriver module.
    	Replace a call to flush_scheduled_work() (which is prone to
    	deadlocks) with cancel_work_sync().  Also, add a call to
    	cancel_work_sync() in the disconnect routine.
    	Reduce the scope of serial->disc_mutex in serial_disconnect().
    	The only place it really needs to protect is where the
    	"disconnected" flag is set.
    	Call the shutdown method from within serial_disconnect()
    	instead of destroy_serial(), because some subdrivers expect
    	the port data structures still to be in existence when
    	their shutdown method runs.
    This fixes the bug reported in

    Signed-off-by: Alan Stern <>
    Signed-off-by: Greg Kroah-Hartman <>
    Alan Stern committed with gregkh May 4, 2009
  8. @gregkh

    MIPS: CVE-2009-0029: Enable syscall wrappers

    Backport of upstream commits by:
      Ralf Baechle <>
      Xiaotian Feng <>
    upstream commits:
    Signed-off-by: dann frazier <>
    Signed-off-by: Greg Kroah-Hartman <>
    dann frazier committed with gregkh Apr 29, 2009
  9. @zhang-rui @gregkh

    ACPI: Revert conflicting workaround for BIOS w/ mangled PRT entries

    upstream 82babbb
    backported to apply cleanly to
    and apply with offset -1 to
    in Linux-2.6.21 worked around BIOS with mangled _PRT entries:
    worked around the same issue via ACPICA, and shipped in 2.6.27.
    Unfortunately the two workarounds conflict:
    So revert the Linux specific one.
    Signed-off-by: Zhang Rui <>
    Signed-off-by: Len Brown <>
    Signed-off-by: Greg Kroah-Hartman <>
    zhang-rui committed with gregkh May 1, 2009
  10. @gregkh

    x86/PCI: don't call e820_all_mapped with -1 in the mmconfig case

    commit 044cd80 upstream.
    e820_all_mapped need end is (addr + size) instead of (addr + size - 1)
    Acked-by: Ingo Molnar <>
    Signed-off-by: Yinghai Lu <>
    Signed-off-by: Jesse Barnes <>
    Signed-off-by: Greg Kroah-Hartman <>
    Yinghai Lu committed with gregkh Apr 18, 2009
  11. @watologo1 @gregkh

    PCI quirk: disable MSI on VIA VT3364 chipsets

    commit 162dedd upstream.
    Without this patch, Broadcom BCM5906 Ethernet controllers set up via MSI
    cause the machine to hang.  Tejun agreed that the best is to blacklist
    the whole chipset and after adding it, seeing the other VIA quirks
    disabling MSI, this very much looks like the right way.
    Cc: <>
    Signed-off-by: Thomas Renninger <>
    Signed-off-by: Jesse Barnes <>
    Signed-off-by: Greg Kroah-Hartman <>
    watologo1 committed with gregkh Apr 3, 2009
  12. @vtl @gregkh

    pagemap: require aligned-length, non-null reads of /proc/pid/pagemap

    commit 0816178 upstream.
    The intention of commit aae8679
    ("pagemap: fix bug in add_to_pagemap, require aligned-length reads of
    /proc/pid/pagemap") was to force reads of /proc/pid/pagemap to be a
    multiple of 8 bytes, but now it allows to read 0 bytes, which actually
    puts some data to user's buffer.  According to POSIX, if count is zero,
    read() should return zero and has no other results.
    Signed-off-by: Vitaly Mayatskikh <>
    Cc: Thomas Tuttle <>
    Acked-by: Matt Mackall <>
    Cc: Alexey Dobriyan <>
    Cc: <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    vtl committed with gregkh Apr 30, 2009
  13. @chombourger @gregkh

    kbuild: fix Module.markers permission error under cygwin

    commit 99e3a1e upstream.
    While building the kernel, we end-up calling modpost with -K and -M
    options for the same file (Modules.markers).  This is resulting in
    modpost's main function calling read_markers() and then write_markers() on
    the same file.
    We then have read_markers() mmap'ing the file, and writer_markers()
    opening that same file for writing.
    The issue is that read_markers() exits without munmap'ing the file and is
    as a matter holding a reference on Modules.markers.  When write_markers()
    is opening that very same file for writing, we still have a reference on
    it and cygwin (Windows?) is then making fopen() fail with EPERM.
    Calling release_file() before exiting read_markers() clears that reference
    (and memory leak) and fopen() then succeeds.
    Tested on both cygwin (1.3.22) and Linux.  Also ran modpost within
    valgrind on Linux to make sure that the munmap'ed file was not accessed
    after read_markers()
    Signed-off-by: Cedric Hombourger <>
    Cc: <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Sam Ravnborg <>
    Signed-off-by: Greg Kroah-Hartman <>
    chombourger committed with gregkh Apr 25, 2009
  14. @gregkh

    b43: Refresh RX poison on buffer recycling

    upstream commit: cf68636
    The RX buffer poison needs to be refreshed, if we recycle an RX buffer,
    because it might be (partially) overwritten by some DMA operations.
    Cc: Francesco Gringoli <>
    Signed-off-by: Michael Buesch <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Chris Wright <>
    Signed-off-by: Greg Kroah-Hartman <>
    Michael Buesch committed with gregkh Apr 24, 2009
  15. @gregkh

    b43: Poison RX buffers

    upstream commit: ec9a1d8
    This patch adds poisoning and sanity checking to the RX DMA buffers.
    This is used for protection against buggy hardware/firmware that raises
    RX interrupts without doing an actual DMA transfer.
    This mechanism protects against rare "bad packets" (due to uninitialized skb data)
    and rare kernel crashes due to uninitialized RX headers.
    The poison is selected to not match on valid frames and to be cheap for checking.
    The poison check mechanism _might_ trigger incorrectly, if we are voluntarily
    receiving frames with bad PLCP headers. However, this is nonfatal, because the
    chance of such a match is basically zero and in case it happens it just results
    in dropping the packet.
    Bad-PLCP RX defaults to off, and you should leave it off unless you want to listen
    to the latest news broadcasted by your microwave oven.
    This patch also moves the initialization of the RX-header "length" field in front of
    the mapping of the DMA buffer. The CPU should not touch the buffer after we mapped it.
    Reported-by: Francesco Gringoli <>
    Signed-off-by: Michael Buesch <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Chris Wright <>
    Signed-off-by: Greg Kroah-Hartman <>
    Michael Buesch committed with gregkh Apr 24, 2009
  16. @gregkh

    forcedeth: Fix resume from hibernation regression.

    upstream commit: 35a7433
    Reset phy state on resume, fixing a regression caused by powering down
    the phy on hibernate.
    Signed-off-by: Ed Swierk <>
    Signed-off-by: David S. Miller <>
    Cc: Tvrtko Ursulin <>
    Signed-off-by: Chris Wright <>
    Signed-off-by: Greg Kroah-Hartman <>
    Ed Swierk committed with gregkh Apr 6, 2009
  17. @gregkh

    USB: Unusual Device support for Gold MP3 Player Energy

    upstream commit: 46c6e93
    Reported by Alessio Treglia on
    User was getting the following errors in dmesg:
    [ 2158.139386] sd 5:0:0:1: ioctl_internal_command return code = 8000002
    [ 2158.139390] : Current: sense key: No Sense
    [ 2158.139393] Additional sense: No additional sense information
    Adds unusual device support.
    modified:   drivers/usb/storage/unusual_devs.h
    Signed-off-by: Chuck Short <>
    Signed-off-by: Tim Gardner <>
    Signed-off-by: Stefan Bader <>
    Cc: stable <>
    Signed-off-by: Greg Kroah-Hartman <>
    Signed-off-by: Chris Wright <>
    Chuck Short committed with gregkh Apr 24, 2009
  18. @borntraeger @gregkh

    virtio-rng: Remove false BUG for spurious callbacks

    upstream commit: e5b8954
    The virtio-rng drivers checks for spurious callbacks. Since
    callbacks can be implemented via shared interrupts (e.g. PCI) this
    could lead to guest kernel oopses with lots of virtio devices.
    Signed-off-by: Christian Borntraeger <>
    Cc: Rusty Russell <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Chris Wright <>
    Signed-off-by: Greg Kroah-Hartman <>
    borntraeger committed with gregkh Apr 24, 2009
  19. @gregkh

    drm/i915: add support for G41 chipset

    commit 7202178 upstream.
    This had been delayed for some time due to failure to work on the one piece
    of G41 hardware we had, and lack of success reports from anybody else.
    Current hardware appears to be OK.
    Signed-off-by: Zhenyu Wang <>
    [anholt: hand-applied due to conflicts with IGD patches]
    Signed-off-by: Eric Anholt <>
    Signed-off-by: Greg Kroah-Hartman <>
    Zhenyu Wang committed with gregkh Nov 17, 2008
Commits on May 2, 2009
  1. @gregkh


    gregkh committed May 2, 2009
  2. @gregkh

    unreached code in selinux_ip_postroute_iptables_compat() (CVE-2009-1184)

    Not upstream in 2.6.30, as the function was removed there, making this a
    Node and port send checks can skip in the compat_net=1 case. This bug
    was introduced in commit effad8d.
    Signed-off-by: Eugene Teo <>
    Reported-by: Dan Carpenter <>
    Acked-by: James Morris <>
    Acked-by: Paul Moore <>
    Signed-off-by: Greg Kroah-Hartman <>
    Eugene Teo committed with gregkh Apr 13, 2009
  3. @hanneseder-net @gregkh

    ACPI: EC: fix compilation warning

    commit 3e54048 upstream.
    Fix the warning introduced in commit c5279de,
    and give the dummy variable a more verbose name.
      drivers/acpi/ec.c: In function 'acpi_ec_ecdt_probe':
      drivers/acpi/ec.c:1015: warning: ISO C90 forbids mixed declarations and code
    Signed-off-by: Hannes Eder <>
    Acked-by: Alexey Starikovskiy <>
    Signed-off-by: Len Brown <>
    Signed-off-by: Greg Kroah-Hartman <>
    hanneseder-net committed with gregkh Nov 29, 2008
  4. @gregkh

    ACPI: EC: Add some basic check for ECDT data

    commit c5279de upstream.
    One more ASUS comes with empty ECDT, add a guard for it...
    Signed-off-by: Alexey Starikovskiy <>
    Signed-off-by: Len Brown <>
    Signed-off-by: Greg Kroah-Hartman <>
    Alexey Starikovskiy committed with gregkh Nov 26, 2008
  5. @hmh @gregkh

    thinkpad-acpi: fix LED blinking through timer trigger

    commit 75bd3bf upstream.
    The set_blink hook code in the LED subdriver would never manage to get
    a LED to blink, and instead it would just turn it on.  The consequence
    of this is that the "timer" trigger would not cause the LED to blink
    if given default parameters.
    This problem exists since 2.6.26-rc1.
    To fix it, switch the deferred LED work handling to use the
    thinkpad-acpi-specific LED status (off/on/blink) directly.
    This also makes the code easier to read, and to extend later.
    Signed-off-by: Henrique de Moraes Holschuh <>
    Signed-off-by: Len Brown <>
    Signed-off-by: Greg Kroah-Hartman <>
    hmh committed with gregkh Apr 14, 2009
  6. @gregkh

    PCI: fix incorrect mask of PM No_Soft_Reset bit

    commit 998dd7c upstream.
    Reviewed-by: Matthew Wilcox <>
    Signed-off-by: Yu Zhao <>
    Signed-off-by: Jesse Barnes <>
    Signed-off-by: Greg Kroah-Hartman <>
    Yu Zhao committed with gregkh Feb 25, 2009
  7. @gregkh

    fs core fixes

    Please add the following 4 commits to 2.6.27-stable and 2.6.28-stable.
    However, there has been a lot of change here between 2.6.28 and 2.6.29:
    in particular, fs/exec.c's unsafe_exec() grew into the more complicated
    check_unsafe_exec().  So applying the original patches gives too many
    rejects: at the bottom is the diffstat and the combined patch required.
    Commit: 53e9309
    Author: Hugh Dickins <>
    Date: Sat, 28 Mar 2009 23:16:03 +0000 (+0000)
    Subject: compat_do_execve should unshare_files
    Commit: e426b64
    Author: Hugh Dickins <>
    Date: Sat, 28 Mar 2009 23:20:19 +0000 (+0000)
    Subject: fix setuid sometimes doesn't
    Commit: 7c2c7d9
    Author: Hugh Dickins <>
    Date: Sat, 28 Mar 2009 23:21:27 +0000 (+0000)
    Subject: fix setuid sometimes wouldn't
    Commit: f1191b5
    Author: Al Viro <>
    Date: Mon, 30 Mar 2009 11:35:18 +0000 (-0400)
    Subject: check_unsafe_exec() doesn't care about signal handlers sharing
    Signed-off-by: Hugh Dickins <>
    Signed-off-by: Greg Kroah-Hartman <>
    Hugh Dickins committed with gregkh Apr 25, 2009
  8. @gregkh

    fix ptrace slowness

    commit 53da1d9 upstream.
    This patch fixes bug #12208:
      Bug-Entry       :
      Subject         : uml is very slow on 2.6.28 host
    This turned out to be not a scheduler regression, but an already
    existing problem in ptrace being triggered by subtle scheduler
    The problem is this:
     - task A is ptracing task B
     - task B stops on a trace event
     - task A is woken up and preempts task B
     - task A calls ptrace on task B, which does ptrace_check_attach()
     - this calls wait_task_inactive(), which sees that task B is still on the runq
     - task A goes to sleep for a jiffy
     - ...
    Since UML does lots of the above sequences, those jiffies quickly add
    up to make it slow as hell.
    This patch solves this by not rescheduling in read_unlock() after
    ptrace_stop() has woken up the tracer.
    Thanks to Oleg Nesterov and Ingo Molnar for the feedback.
    Signed-off-by: Miklos Szeredi <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    Miklos Szeredi committed with gregkh Mar 23, 2009
  9. @utrace @gregkh

    exit_notify: kill the wrong capable(CAP_KILL) check (CVE-2009-1337)

    commit 432870d upstream.
    The CAP_KILL check in exit_notify() looks just wrong, kill it.
    Whatever logic we have to reset ->exit_signal, the malicious user
    can bypass it if it execs the setuid application before exiting.
    Signed-off-by: Oleg Nesterov <>
    Acked-by: Serge Hallyn <>
    Acked-by: Roland McGrath <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    utrace committed with gregkh Apr 6, 2009
  10. @gregkh

    crypto: ixp4xx - Fix handling of chained sg buffers

    commit 0d44dc5 upstream.
     - keep dma functions away from chained scatterlists.
       Use the existing scatterlist iteration inside the driver
       to call dma_map_single() for each chunk and avoid dma_map_sg().
    Signed-off-by: Christian Hohnstaedt <>
    Tested-By:  Karl Hiramoto <>
    Signed-off-by: Herbert Xu <>
    Signed-off-by: Greg Kroah-Hartman <>
    Christian Hohnstaedt committed with gregkh Mar 27, 2009
  11. @gregkh

    b44: Use kernel DMA addresses for the kernel DMA API

    commit 37efa23 upstream.
    We must not use the device DMA addresses for the kernel DMA API, because
    device DMA addresses have an additional offset added for the SSB translation.
    Use the original dma_addr_t for the sync operation.
    Signed-off-by: Michael Buesch <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Michael Buesch committed with gregkh Apr 6, 2009
  12. @gregkh

    ath9k: AR9280 PCI devices must serialize IO as well

    This is a port of:
    commit SHA1 5ec905a
    for 2.6.27
    Signed-off-by: Luis R. Rodriguez <>
    Signed-off-by: Greg Kroah-Hartman <>
    Luis R. Rodriguez committed with gregkh Mar 23, 2009
  13. @gregkh

    ath9k: implement IO serialization

    This is a port of:
    commit SHA1 6158425
    for 2.6.27
    All 802.11n PCI devices (Cardbus, PCI, mini-PCI) require
    serialization of IO when on non-uniprocessor systems. PCI
    express devices not not require this.
    This should fix our only last standing open ath9k
    bugzilla bug report:
    Signed-off-by: Luis R. Rodriguez <>
    Signed-off-by: Greg Kroah-Hartman <>
    Luis R. Rodriguez committed with gregkh Mar 23, 2009
  14. @gregkh

    powerpc: Sanitize stack pointer in signal handling code

    This has been backported to 2.6.27.x from commit efbda86 in Linus' tree.
    On powerpc64 machines running 32-bit userspace, we can get garbage bits in the
    stack pointer passed into the kernel.  Most places handle this correctly, but
    the signal handling code uses the passed value directly for allocating signal
    stack frames.
    This fixes the issue by introducing a get_clean_sp function that returns a
    sanitized stack pointer.  For 32-bit tasks on a 64-bit kernel, the stack
    pointer is masked correctly.  In all other cases, the stack pointer is simply
    Additionally, we pass an 'is_32' parameter to get_sigframe now in order to
    get the properly sanitized stack.  The callers are know to be 32 or 64-bit
    Signed-off-by: Josh Boyer <>
    Signed-off-by: Benjamin Herrenschmidt <>
    Signed-off-by: Greg Kroah-Hartman <>
    Josh Boyer committed with gregkh Apr 28, 2009
  15. @hnaz @gregkh

    mm: check for no mmaps in exit_mmap()

    commit dcd4a04 upstream.
    When dup_mmap() ooms we can end up with mm->mmap == NULL.  The error
    path does mmput() and unmap_vmas() gets a NULL vma which it
    In exit_mmap() there is nothing to do at all for this case, we can
    cancel the callpath right there.
    [ add sorely-needed comment]
    Signed-off-by: Johannes Weiner <>
    Reported-by: Akinobu Mita <>
    Cc: Nick Piggin <>
    Cc: Hugh Dickins <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Reported-by: Kir Kolyshkin <>
    Tested-by: Kir Kolyshkin <>
    Signed-off-by: Greg Kroah-Hartman <>
    hnaz committed with gregkh Jan 6, 2009
  16. @gregkh

    r8169: reset IntrStatus after chip reset

    Upstream as d78ad8c (post 2.6.29).
    Original comment (Karsten):
    On a MSI MS-6702E mainboard, when in rtl8169_init_one() for the first time
    after BIOS has run, IntrStatus reads 5 after chip has been reset.
    IntrStatus should equal 0 there, so patch changes IntrStatus reset to happen
    after chip reset instead of before.
    Remark (Francois):
    Assuming that the loglevel of the driver is increased above NETIF_MSG_INTR,
    the bug reveals itself with a typical "interrupt 0025 in poll" message
    at startup. In retrospect, the message should had been read as an hint of
    an unexpected hardware state several months ago :o(
    Fixes (at least part of)
    Signed-off-by: Karsten Wiese <>
    Signed-off-by: Francois Romieu <>
    Tested-by: Josep <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Francois Romieu committed with gregkh Apr 16, 2009