Skip to content
Commits on Mar 4, 2012
  1. @gregkh

    Linux 2.6.32.58

    gregkh committed Mar 4, 2012
  2. @gregkh

    PM / Sleep: Fix read_unlock_usermodehelper() call.

    [ Upstream commit e4c89a5 ]
    
    Commit b298d28
     "PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()"
    added read_unlock_usermodehelper() but read_unlock_usermodehelper() is called
    without read_lock_usermodehelper() when kmalloc() failed.
    
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Acked-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Tetsuo Handa committed with gregkh Feb 29, 2012
  3. @gregkh

    PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabl…

    …ed()
    
    [ Upstream commit b298d28 ]
    
    Commit a144c6a (PM: Print a warning if firmware is requested when tasks
    are frozen) introduced usermodehelper_is_disabled() to warn and exit
    immediately if firmware is requested when usermodehelpers are disabled.
    
    However, it is racy. Consider the following scenario, currently used in
    drivers/base/firmware_class.c:
    
    ...
    if (usermodehelper_is_disabled())
            goto out;
    
    /* Do actual work */
    ...
    
    out:
            return err;
    
    Nothing prevents someone from disabling usermodehelpers just after the check
    in the 'if' condition, which means that it is quite possible to try doing the
    "actual work" with usermodehelpers disabled, leading to undesirable
    consequences.
    
    In particular, this race condition in _request_firmware() causes task freezing
    failures whenever suspend/hibernation is in progress because, it wrongly waits
    to get the firmware/microcode image from userspace when actually the
    usermodehelpers are disabled or userspace has been frozen.
    Some of the example scenarios that cause freezing failures due to this race
    are those that depend on userspace via request_firmware(), such as x86
    microcode module initialization and microcode image reload.
    
    Previous discussions about this issue can be found at:
    http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591
    
    This patch adds proper synchronization to fix this issue.
    
    It is to be noted that this patchset fixes the freezing failures but doesn't
    remove the warnings. IOW, it does not attempt to add explicit synchronization
    to x86 microcode driver to avoid requesting microcode image at inopportune
    moments. Because, the warnings were introduced to highlight such cases, in the
    first place. And we need not silence the warnings, since we take care of the
    *real* problem (freezing failure) and hence, after that, the warnings are
    pretty harmless anyway.
    
    Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Srivatsa S. Bhat committed with gregkh Feb 29, 2012
  4. @torvalds @gregkh

    firmware loader: allow builtin firmware load even if usermodehelper i…

    …s disabled
    
    [ Upstream commit caca951 ]
    
    In commit a144c6a ("PM: Print a warning if firmware is requested
    when tasks are frozen") we not only printed a warning if somebody tried
    to load the firmware when tasks are frozen - we also failed the load.
    
    But that check was done before the check for built-in firmware, and then
    when we disallowed usermode helpers during bootup (commit 288d5ab:
    "Boot up with usermodehelper disabled"), that actually means that
    built-in modules can no longer load their firmware even if the firmware
    is built in too.  Which used to work, and some people depended on it for
    the R100 driver.
    
    So move the test for usermodehelper_is_disabled() down, to after
    checking the built-in firmware.
    
    This should fix:
    
    	https://bugzilla.kernel.org/show_bug.cgi?id=40952
    
    Reported-by: James Cloos <cloos@hjcloos.com>
    Bisected-by: Elimar Riesebieter <riesebie@lxtec.de>
    Cc: Michel Dänzer <michel@daenzer.net>
    Cc: Rafael Wysocki <rjw@sisk.pl>
    Cc: Valdis Kletnieks <valdis.kletnieks@vt.edu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    torvalds committed with gregkh Feb 29, 2012
  5. @rjwysocki @gregkh

    PM: Print a warning if firmware is requested when tasks are frozen

    [ Upstream commit a144c6a ]
    
    Some drivers erroneously use request_firmware() from their ->resume()
    (or ->thaw(), or ->restore()) callbacks, which is not going to work
    unless the firmware has been built in.  This causes system resume to
    stall until the firmware-loading timeout expires, which makes users
    think that the resume has failed and reboot their machines
    unnecessarily.  For this reason, make _request_firmware() print a
    warning and return immediately with error code if it has been called
    when tasks are frozen and it's impossible to start any new usermode
    helpers.
    
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
    Reviewed-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
    Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    rjwysocki committed with gregkh Feb 29, 2012
  6. @gregkh

    compat: fix compile breakage on s390

    commit 048cd4e upstream.
    
    The new is_compat_task() define for the !COMPAT case in
    include/linux/compat.h conflicts with a similar define in
    arch/s390/include/asm/compat.h.
    
    This is the minimal patch which fixes the build issues.
    
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Heiko Carstens committed with gregkh Feb 27, 2012
  7. @torvalds @gregkh

    Fix autofs compile without CONFIG_COMPAT

    commit 3c761ea upstream.
    
    The autofs compat handling fix caused a compile failure when
    CONFIG_COMPAT isn't defined.
    
    Instead of adding random #ifdef'fery in autofs, let's just make the
    compat helpers earlier to use: without CONFIG_COMPAT, is_compat_task()
    just hardcodes to zero.
    
    We could probably do something similar for a number of other cases where
    we have #ifdef's in code, but this is the low-hanging fruit.
    
    Reported-and-tested-by: Andreas Schwab <schwab@linux-m68k.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    torvalds committed with gregkh Feb 26, 2012
  8. @raven-au @gregkh

    autofs: work around unhappy compat problem on x86-64

    commit a32744d upstream.
    
    When the autofs protocol version 5 packet type was added in commit
    5c0a32f ("autofs4: add new packet type for v5 communications"), it
    obvously tried quite hard to be word-size agnostic, and uses explicitly
    sized fields that are all correctly aligned.
    
    However, with the final "char name[NAME_MAX+1]" array at the end, the
    actual size of the structure ends up being not very well defined:
    because the struct isn't marked 'packed', doing a "sizeof()" on it will
    align the size of the struct up to the biggest alignment of the members
    it has.
    
    And despite all the members being the same, the alignment of them is
    different: a "__u64" has 4-byte alignment on x86-32, but native 8-byte
    alignment on x86-64.  And while 'NAME_MAX+1' ends up being a nice round
    number (256), the name[] array starts out a 4-byte aligned.
    
    End result: the "packed" size of the structure is 300 bytes: 4-byte, but
    not 8-byte aligned.
    
    As a result, despite all the fields being in the same place on all
    architectures, sizeof() will round up that size to 304 bytes on
    architectures that have 8-byte alignment for u64.
    
    Note that this is *not* a problem for 32-bit compat mode on POWER, since
    there __u64 is 8-byte aligned even in 32-bit mode.  But on x86, 32-bit
    and 64-bit alignment is different for 64-bit entities, and as a result
    the structure that has exactly the same layout has different sizes.
    
    So on x86-64, but no other architecture, we will just subtract 4 from
    the size of the structure when running in a compat task.  That way we
    will write the properly sized packet that user mode expects.
    
    Not pretty.  Sadly, this very subtle, and unnecessary, size difference
    has been encoded in user space that wants to read packets of *exactly*
    the right size, and will refuse to touch anything else.
    
    Reported-and-tested-by: Thomas Meyer <thomas@m3y3r.de>
    Signed-off-by: Ian Kent <raven@themaw.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    raven-au committed with gregkh Feb 22, 2012
  9. @gregkh

    cdrom: use copy_to_user() without the underscores

    commit 822bfa5 upstream.
    
    "nframes" comes from the user and "nframes * CD_FRAMESIZE_RAW" can wrap
    on 32 bit systems.  That would have been ok if we used the same wrapped
    value for the copy, but we use a shifted value.  We should just use the
    checked version of copy_to_user() because it's not going to make a
    difference to the speed.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Dan Carpenter committed with gregkh Feb 6, 2012
  10. @gregkh

    eCryptfs: Clear i_nlink in rmdir

    commit 0785055 upstream.
    
    eCryptfs wasn't clearing the eCryptfs inode's i_nlink after a successful
    vfs_rmdir() on the lower directory. This resulted in the inode evict and
    destroy paths to be missed.
    
    https://bugs.launchpad.net/ecryptfs/+bug/723518
    
    Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
    Signed-off-by: Colin King <colin.king@canonical.com>
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Tyler Hicks committed with gregkh Apr 29, 2011
  11. @gregkh

    eCryptfs: Remove extra d_delete in ecryptfs_rmdir

    commit 35ffa94 upstream.
    
    vfs_rmdir() already calls d_delete() on the lower dentry. That was being
    duplicated in ecryptfs_rmdir() and caused a NULL pointer dereference
    when NFSv3 was the lower filesystem.
    
    BugLink: http://bugs.launchpad.net/bugs/723518
    Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
    Signed-off-by: Colin King <colin.king@canonical.com>
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Tyler Hicks committed with gregkh Apr 12, 2011
  12. @gregkh

    eCryptfs: Use notify_change for truncating lower inodes

    commit 5f3ef64 upstream.
    
    When truncating inodes in the lower filesystem, eCryptfs directly
    invoked vmtruncate(). As Christoph Hellwig pointed out, vmtruncate() is
    a filesystem helper function, but filesystems may need to do more than
    just a call to vmtruncate().
    
    This patch moves the lower inode truncation out of ecryptfs_truncate()
    and renames the function to truncate_upper().  truncate_upper() updates
    an iattr for the lower inode to indicate if the lower inode needs to be
    truncated upon return.  ecryptfs_setattr() then calls notify_change(),
    using the updated iattr for the lower inode, to complete the truncation.
    
    For eCryptfs functions needing to truncate, ecryptfs_truncate() is
    reintroduced as a simple way to truncate the upper inode to a specified
    size and then truncate the lower inode accordingly.
    
    https://bugs.launchpad.net/bugs/451368
    
    Reported-by: Christoph Hellwig <hch@lst.de>
    Acked-by: Dustin Kirkland <kirkland@canonical.com>
    Cc: ecryptfs-devel@lists.launchpad.net
    Cc: linux-fsdevel@vger.kernel.org
    Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Tyler Hicks committed with gregkh Oct 14, 2009
  13. @jannau @gregkh

    hdpvr: fix race conditon during start of streaming

    commit afa1595 upstream.
    
    status has to be set to STREAMING before the streaming worker is
    queued. hdpvr_transmit_buffers() will exit immediately otherwise.
    
    Reported-by: Joerg Desch <vvd.joede@googlemail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    jannau committed with gregkh Feb 2, 2012
  14. @gregkh

    xhci: Fix encoding for HS bulk/control NAK rate.

    commit 340a350 upstream.
    
    The xHCI 0.96 spec says that HS bulk and control endpoint NAK rate must
    be encoded as an exponent of two number of microframes.  The endpoint
    descriptor has the NAK rate encoded in number of microframes.  We were
    just copying the value from the endpoint descriptor into the endpoint
    context interval field, which was not correct.  This lead to the VIA
    host rejecting the add of a bulk OUT endpoint from any USB 2.0 mass
    storage device.
    
    The fix is to use the correct encoding.  Refactor the code to convert
    number of frames to an exponential number of microframes, and make sure
    we convert the number of microframes in HS bulk and control endpoints to
    an exponent.
    
    This should be back ported to kernels as old as 2.6.31, that contain the
    commit dfa49c4 "USB: xhci - fix math
    in xhci_get_endpoint_interval"
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Tested-by: Felipe Contreras <felipe.contreras@gmail.com>
    Suggested-by: Andiry Xu <andiry.xu@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Sarah Sharp committed with gregkh Feb 13, 2012
  15. @gregkh

    USB: Fix handoff when BIOS disables host PCI device.

    commit cab928e upstream.
    
    On some systems with an Intel Panther Point xHCI host controller, the
    BIOS disables the xHCI PCI device during boot, and switches the xHCI
    ports over to EHCI.  This allows the BIOS to access USB devices without
    having xHCI support.
    
    The downside is that the xHCI BIOS handoff mechanism will fail because
    memory mapped I/O is not enabled for the disabled PCI device.
    Jesse Barnes says this is expected behavior.  The PCI core will enable
    BARs before quirks run, but it will leave it in an undefined state, and
    it may not have memory mapped I/O enabled.
    
    Make the generic USB quirk handler call pci_enable_device() to re-enable
    MMIO, and call pci_disable_device() once the host-specific BIOS handoff
    is finished.  This will balance the ref counts in the PCI core.  When
    the PCI probe function is called, usb_hcd_pci_probe() will call
    pci_enable_device() again.
    
    This should be back ported to kernels as old as 2.6.31.  That was the
    first kernel with xHCI support, and no one has complained about BIOS
    handoffs failing due to memory mapped I/O being disabled on other hosts
    (EHCI, UHCI, or OHCI).
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Acked-by: Oliver Neukum <oneukum@suse.de>
    Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Sarah Sharp committed with gregkh Feb 7, 2012
  16. @baxeno @gregkh

    USB: Added Kamstrup VID/PIDs to cp210x serial driver.

    commit c6c1e44 upstream.
    
    Signed-off-by: Bruno Thomsen <bruno.thomsen@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    baxeno committed with gregkh Feb 21, 2012
  17. @rabinv @gregkh

    ARM: 7325/1: fix v7 boot with lockdep enabled

    commit 8e43a90 upstream.
    
    Bootup with lockdep enabled has been broken on v7 since b46c0f7
    ("ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR").
    
    This is because v7_setup (which is called very early during boot) calls
    v7_flush_dcache_all, and the save_and_disable_irqs added by that patch
    ends up attempting to call into lockdep C code (trace_hardirqs_off())
    when we are in no position to execute it (no stack, MMU off).
    
    Fix this by using a notrace variant of save_and_disable_irqs.  The code
    already uses the notrace variant of restore_irqs.
    
    Reviewed-by: Nicolas Pitre <nico@linaro.org>
    Acked-by: Stephen Boyd <sboyd@codeaurora.org>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Rabin Vincent <rabin@rab.in>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    rabinv committed with gregkh Feb 15, 2012
  18. @bebarino @gregkh

    ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR

    commit b46c0f7 upstream.
    
    armv7's flush_cache_all() flushes caches via set/way. To
    determine the cache attributes (line size, number of sets,
    etc.) the assembly first writes the CSSELR register to select a
    cache level and then reads the CCSIDR register. The CSSELR register
    is banked per-cpu and is used to determine which cache level CCSIDR
    reads. If the task is migrated between when the CSSELR is written and
    the CCSIDR is read the CCSIDR value may be for an unexpected cache
    level (for example L1 instead of L2) and incorrect cache flushing
    could occur.
    
    Disable interrupts across the write and read so that the correct
    cache attributes are read and used for the cache flushing
    routine. We disable interrupts instead of disabling preemption
    because the critical section is only 3 instructions and we want
    to call v7_dcache_flush_all from __v7_setup which doesn't have a
    full kernel stack with a struct thread_info.
    
    This fixes a problem we see in scm_call() when flush_cache_all()
    is called from preemptible context and sometimes the L2 cache is
    not properly flushed out.
    
    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Reviewed-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    bebarino committed with gregkh Feb 7, 2012
  19. @gregkh

    SCSI: 3w-9xxx fix bug in sgl loading

    commit 53ca353 upstream.
    
    This small patch fixes a bug in the 3w-9xxx driver where it would load
    an invalid sgl address in the ioctl path even if request length was zero.
    
    Signed-off-by: Adam Radford <aradford@gmail.com>
    Signed-off-by: James Bottomley <James.Bottomley@suse.de>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    adam radford committed with gregkh Dec 10, 2009
  20. @gregkh

    ecryptfs: read on a directory should return EISDIR if not supported

    commit 323ef68 upstream.
    
    read() calls against a file descriptor connected to a directory are
    incorrectly returning EINVAL rather than EISDIR:
    
      [EISDIR]
        [XSI] [Option Start] The fildes argument refers to a directory and the
        implementation does not allow the directory to be read using read()
        or pread(). The readdir() function should be used instead. [Option End]
    
    This occurs because we do not have a .read operation defined for
    ecryptfs directories.  Connect this up to generic_read_dir().
    
    BugLink: http://bugs.launchpad.net/bugs/719691
    Signed-off-by: Andy Whitcroft <apw@canonical.com>
    Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
    Andy Whitcroft committed with gregkh Feb 16, 2011
  21. @gregkh

    drm/radeon/kms: fix MSI re-arm on rv370+

    commit b7f5b7d upstream.
    
    MSI_REARM_EN register is a write only trigger register.
    There is no need RMW when re-arming.
    
    May fix:
    https://bugs.freedesktop.org/show_bug.cgi?id=41668
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Alex Deucher committed with gregkh Feb 13, 2012
  22. @gregkh

    crypto: sha512 - use standard ror64()

    commit f2ea0f5 upstream.
    
    Use standard ror64() instead of hand-written.
    There is no standard ror64, so create it.
    
    The difference is shift value being "unsigned int" instead of uint64_t
    (for which there is no reason). gcc starts to emit native ROR instructions
    which it doesn't do for some reason currently. This should make the code
    faster.
    
    Patch survives in-tree crypto test and ping flood with hmac(sha512) on.
    
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Alexey Dobriyan committed with gregkh Jan 14, 2012
  23. @gregkh

    Add mount option to check uid of device being mounted = expect uid, C…

    …VE-2011-1833
    
    (backported from commit 7643554)
    
    Close a TOCTOU race for mounts done via ecryptfs-mount-private.  The mount
    source (device) can be raced when the ownership test is done in userspace.
    Provide Ecryptfs a means to force the uid check at mount time.
    
    BugLink: http://bugs.launchpad.net/bugs/732628
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Tyler Hicks <tyler.hicks@canonical.com>
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    John Johansen committed with gregkh Feb 15, 2012
  24. @gregkh

    Ban ecryptfs over ecryptfs

    (cherry picked from commit 4403158)
    
    This is a seriously simplified patch from Eric Sandeen; copy of
    rationale follows:
    ===
      mounting stacked ecryptfs on ecryptfs has been shown to lead to bugs
      in testing.  For crypto info in xattr, there is no mechanism for handling
      this at all, and for normal file headers, we run into other trouble:
    
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      IP: [<ffffffffa015b0b3>] ecryptfs_d_revalidate+0x43/0xa0 [ecryptfs]
      ...
    
      There doesn't seem to be any good usecase for this, so I'd suggest just
      disallowing the configuration.
    
      Based on a patch originally, I believe, from Mike Halcrow.
    ===
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Al Viro committed with gregkh Feb 15, 2012
  25. @gregkh

    eCryptfs: Remove mmap from directory operations

    backported from 38e3eae
    
    Adrian reported that mkfontscale didn't work inside of eCryptfs mounts.
    Strace revealed the following:
    
    open("./", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
    fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
    open("./fonts.scale", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
    getdents(3, /* 80 entries */, 32768) = 2304
    open("./.", O_RDONLY) = 5
    fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
    fstat64(5, {st_mode=S_IFDIR|0755, st_size=16384, ...}) = 0
    mmap2(NULL, 16384, PROT_READ, MAP_PRIVATE, 5, 0) = 0xb7fcf000
    close(5) = 0
     --- SIGBUS (Bus error) @ 0 (0) ---
     +++ killed by SIGBUS +++
    
    The mmap2() on a directory was successful, resulting in a SIGBUS
    signal later.  This patch removes mmap() from the list of possible
    ecryptfs_dir_fops so that mmap() isn't possible on eCryptfs directory
    files.
    
    http://bugs.launchpad.net/bugs/400443
    
    Reported-by: Adrian C. <anrxc@sysphere.org>
    Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Tyler Hicks committed with gregkh Feb 15, 2012
  26. @herbertx @gregkh

    crypto: sha512 - Avoid stack bloat on i386

    commit 3a92d68 upstream.
    
    Unfortunately in reducing W from 80 to 16 we ended up unrolling
    the loop twice.  As gcc has issues dealing with 64-bit ops on
    i386 this means that we end up using even more stack space (>1K).
    
    This patch solves the W reduction by moving LOAD_OP/BLEND_OP
    into the loop itself, thus avoiding the need to duplicate it.
    
    While the stack space still isn't great (>0.5K) it is at least
    in the same ball park as the amount of stack used for our C sha1
    implementation.
    
    Note that this patch basically reverts to the original code so
    the diff looks bigger than it really is.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    herbertx committed with gregkh Feb 5, 2012
  27. @herbertx @gregkh

    crypto: sha512 - Use binary and instead of modulus

    commit 58d7d18 upstream.
    
    The previous patch used the modulus operator over a power of 2
    unnecessarily which may produce suboptimal binary code.  This
    patch changes changes them to binary ands instead.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    herbertx committed with gregkh Jan 26, 2012
  28. @gregkh

    hwmon: (f75375s) Fix automatic pwm mode setting for F75373 & F75375

    commit 09e87e5 upstream.
    
    In order to enable temperature mode aka automatic mode for the F75373 and
    F75375 chips, the two FANx_MODE bits in the fan configuration register
    need be set to 01, not 10.
    
    Signed-off-by: Nikolaus Schulz <mail@microschulz.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Nikolaus Schulz committed with gregkh Feb 8, 2012
  29. @OGAWAHirofumi @gregkh

    printk_ratelimited(): fix uninitialized spinlock

    commit d8521fc upstream.
    
    ratelimit_state initialization of printk_ratelimited() seems broken.  This
    fixes it by using DEFINE_RATELIMIT_STATE() to initialize spinlock
    properly.
    
    Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
    Cc: Joe Perches <joe@perches.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Sven-Haegar Koch <haegar@sdinet.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    OGAWAHirofumi committed with gregkh May 24, 2010
  30. @gregkh

    kernel.h: fix wrong usage of __ratelimit()

    commit bb1dc0b upstream.
    
    When __ratelimit() returns 1 this means that we can go ahead.
    
    Signed-off-by: Yong Zhang <yong.zhang@windriver.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Joe Perches <joe@perches.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Yong Zhang committed with gregkh Apr 6, 2010
  31. @elp @gregkh

    mac80211: timeout a single frame in the rx reorder buffer

    commit 07ae2df upstream.
    
    The current code checks for stored_mpdu_num > 1, causing
    the reorder_timer to be triggered indefinitely, but the
    frame is never timed-out (until the next packet is received)
    
    Signed-off-by: Eliad Peller <eliad@wizery.com>
    Acked-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    elp committed with gregkh Feb 1, 2012
  32. @gregkh

    relay: prevent integer overflow in relay_open()

    commit f6302f1 upstream.
    
    "subbuf_size" and "n_subbufs" come from the user and they need to be
    capped to prevent an integer overflow.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Dan Carpenter committed with gregkh Feb 10, 2012
  33. @fengguang @gregkh

    lib: proportion: lower PROP_MAX_SHIFT to 32 on 64-bit kernel

    commit 3310225 upstream.
    
    PROP_MAX_SHIFT should be set to <=32 on 64-bit box. This fixes two bugs
    in the below lines of bdi_dirty_limit():
    
    	bdi_dirty *= numerator;
    	do_div(bdi_dirty, denominator);
    
    1) divide error: do_div() only uses the lower 32 bit of the denominator,
       which may trimmed to be 0 when PROP_MAX_SHIFT > 32.
    
    2) overflow: (bdi_dirty * numerator) could easily overflow if numerator
       used up to 48 bits, leaving only 16 bits to bdi_dirty
    
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Reported-by: Ilya Tumaykin <librarian_rus@yahoo.com>
    Tested-by: Ilya Tumaykin <librarian_rus@yahoo.com>
    Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    fengguang committed with gregkh Jan 9, 2012
  34. @gregkh

    hwmon: (f75375s) Fix bit shifting in f75375_write16

    commit eb2f255 upstream.
    
    In order to extract the high byte of the 16-bit word, shift the word to
    the right, not to the left.
    
    Signed-off-by: Nikolaus Schulz <mail@microschulz.de>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Nikolaus Schulz committed with gregkh Feb 8, 2012
  35. @danvet @gregkh

    drm/i915: no lvds quirk for AOpen MP45

    commit e57b688 upstream.
    
    According to a bug report, it doesn't have one.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44263
    Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    danvet committed with gregkh Feb 8, 2012
Something went wrong with that request. Please try again.