24 Feb, 2012

1 commit


27 Jan, 2012

10 commits


26 Jan, 2012

26 commits

  • We've decided to provide CPU family specific container files
    (starting with CPU family 15h). E.g. for family 15h we have to
    load microcode_amd_fam15h.bin instead of microcode_amd.bin

    Rationale is that starting with family 15h patch size is larger
    than 2KB which was hard coded as maximum patch size in various
    microcode loaders (not just Linux).

    Container files which include patches larger than 2KB cause
    different kinds of trouble with such old patch loaders. Thus we
    have to ensure that the default container file provides only
    patches with size less than 2KB.

    Signed-off-by: Andreas Herrmann
    Cc: Borislav Petkov
    Cc:
    Link: http://lkml.kernel.org/r/20120120164412.GD24508@alberich.amd.com
    [ documented the naming convention and tidied the code a bit. ]
    Signed-off-by: Ingo Molnar

    Andreas Herrmann
     
  • That is the last one missing for those CPUs.

    Others were recently added with commits

    fb215366b3c7320ac25dca766a0152df16534932
    (KVM: expose latest Intel cpu new features (BMI1/BMI2/FMA/AVX2) to guest)

    and

    commit 969df4b82904a30fef19a67398a0c854d223ea67
    (x86: Report cpb and eff_freq_ro flags correctly)

    Signed-off-by: Andreas Herrmann
    Link: http://lkml.kernel.org/r/20120120163823.GC24508@alberich.amd.com
    Signed-off-by: Ingo Molnar

    Andreas Herrmann
     
  • We allocate memory with malloc(), but neglect to free it before
    the variable 'phdrs' goes out of scope --> leak.

    Signed-off-by: Jesper Juhl
    Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1201232332590.8772@swampdragon.chaosbits.net
    [ Mostly harmless. ]
    Signed-off-by: Ingo Molnar

    Jesper Juhl
     
  • EDAC detection no longer crashes multi-node systems, so don't
    conflict on it with NumaChip.

    Signed-off-by: Daniel J Blueman
    Cc: Steffen Persvold
    Link: http://lkml.kernel.org/r/1327473349-28395-1-git-send-email-daniel@numascale-asia.com
    Signed-off-by: Ingo Molnar

    Daniel J Blueman
     
  • Initialize two spinlocks in tlb_uv.c and also properly define/initialize
    the uv_irq_lock.

    The lack of explicit initialization seems to be functionally
    harmless, but it is diagnosed when these are turned on:

    CONFIG_DEBUG_SPINLOCK=y
    CONFIG_DEBUG_MUTEXES=y
    CONFIG_DEBUG_LOCK_ALLOC=y
    CONFIG_LOCKDEP=y

    Signed-off-by: Cliff Wickman
    Cc:
    Cc: Dimitri Sivanich
    Link: http://lkml.kernel.org/r/E1RnXd1-0003wU-PM@eag09.americas.sgi.com
    [ Added the uv_irq_lock initialization fix by Dimitri Sivanich ]
    Signed-off-by: Ingo Molnar

    Cliff Wickman
     
  • uv_gpa_to_soc_phys_ram() was inadvertently ignoring the
    shift values. This fix takes the shift into account.

    Signed-off-by: Russ Anderson
    Cc:
    Link: http://lkml.kernel.org/r/20120119020753.GA7228@sgi.com
    Signed-off-by: Ingo Molnar

    Russ Anderson
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
    crypto: sha512 - reduce stack usage to safe number
    crypto: sha512 - make it work, undo percpu message schedule

    Linus Torvalds
     
  • Quoth Ben Myers:
    "Please pull in the following bugfix for xfs. We forgot to drop a lock on
    error in xfs_readlink. It hasn't been through -next yet, but there is no
    -next tree tomorrow. The fix is clear so I'm sending this request today."

    * 'for-linus' of git://oss.sgi.com/xfs/xfs:
    xfs: Fix missing xfs_iunlock() on error recovery path in xfs_readlink()

    Linus Torvalds
     
  • * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
    drm/ttm: fix two regressions since move_notify changes
    drm/radeon: avoid deadlock if GPU lockup is detected in ib_pool_get
    drm/radeon: silence out possible lock dependency warning
    drm: Fix authentication kernel crash
    gma500: Fix shmem mapping
    drm/radeon/kms: refine TMDS dual link checks
    drm/radeon/kms: use drm_detect_hdmi_monitor for picking encoder mode
    drm/radeon/kms: rework modeset sequence for DCE41 and DCE5
    drm/radeon/kms: move panel mode setup into encoder mode set
    drm/radeon/kms: move disp eng pll setup to init path
    drm/radeon: finish getting bios earlier
    drm/radeon: fix invalid memory access in radeon_atrm_get_bios()
    drm/radeon/kms: add some missing semaphore init
    drm/radeon/kms: Add an MSI quirk for Dell RS690
    gpu, drm, sis: Don't return uninitialized variable from sis_driver_load()

    Linus Torvalds
     
  • * 'fix/asoc' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
    ASoC: wm2000: Fix use-after-free - don't release_firmware() twice on error
    ASoC: wm8958: Use correct format string in dev_err() call
    ASoC: wm8996: Call _POST_PMU callback for CPVDD
    ASoC: mxs: Fix mxs-saif timeout
    ASoC: Disable register synchronisation for low frequency WM8996 SYSCLK
    ASoC: Don't go through cache when applying WM5100 rev A updates
    ASoC: Mark WM5100 register map cache only when going into BIAS_OFF
    ASoC: tlv320aic32x4: always enable analouge block
    ASoC: tlv320aic32x4: always enable dividers
    ASoC: sgtl5000: Fix wrong register name in restore

    Linus Torvalds
     
  • A fairly simple bugfix for a WARN_ON() which was triggered in the cache
    reset support as a result of some subsequent work. There's only one
    mainline user for the code path that's updated right now (wm8994) so
    should be low risk.

    * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
    regmap: Reset cache status when reinitialsing the cache

    Linus Torvalds
     
  • The data encryption was moved from ecryptfs_write_end into
    ecryptfs_writepage, this patch moves the corresponding function
    comments to be consistent with the modification.

    Signed-off-by: Li Wang
    Signed-off-by: Linus Torvalds

    Li Wang
     
  • Says Tyler:
    "Tim's logging message update will be really helpful to users when
    they're trying to locate a problematic file in the lower filesystem
    with filename encryption enabled.

    You'll recognize the fix from Li, as you commented on that.

    You should also be familiar with my setattr/truncate improvements,
    since you were the one that pointed them out to us (thanks again!).
    Andrew noted the /dev/ecryptfs write count sanitization needed to be
    improved, so I've got a fix in there for that along with some other
    less important cleanups of the /dev/ecryptfs read/write code."

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs:
    eCryptfs: Fix oops when printing debug info in extent crypto functions
    eCryptfs: Remove unused ecryptfs_read()
    eCryptfs: Check inode changes in setattr
    eCryptfs: Make truncate path killable
    eCryptfs: Infinite loop due to overflow in ecryptfs_write()
    eCryptfs: Replace miscdev read/write magic numbers
    eCryptfs: Report errors in writes to /dev/ecryptfs
    eCryptfs: Sanitize write counts of /dev/ecryptfs
    ecryptfs: Remove unnecessary variable initialization
    ecryptfs: Improve metadata read failure logging
    MAINTAINERS: Update eCryptfs maintainer address

    Linus Torvalds
     
  • If pages passed to the eCryptfs extent-based crypto functions are not
    mapped and the module parameter ecryptfs_verbosity=1 was specified at
    loading time, a NULL pointer dereference will occur.

    Note that this wouldn't happen on a production system, as you wouldn't
    pass ecryptfs_verbosity=1 on a production system. It leaks private
    information to the system logs and is for debugging only.

    The debugging info printed in these messages is no longer very useful
    and rather than doing a kmap() in these debugging paths, it will be
    better to simply remove the debugging paths completely.

    https://launchpad.net/bugs/913651

    Signed-off-by: Tyler Hicks
    Reported-by: Daniel DeFreez
    Cc:

    Tyler Hicks
     
  • ecryptfs_read() has been ifdef'ed out for years now and it was
    apparently unused before then. It is time to get rid of it for good.

    Signed-off-by: Tyler Hicks

    Tyler Hicks
     
  • Most filesystems call inode_change_ok() very early in ->setattr(), but
    eCryptfs didn't call it at all. It allowed the lower filesystem to make
    the call in its ->setattr() function. Then, eCryptfs would copy the
    appropriate inode attributes from the lower inode to the eCryptfs inode.

    This patch changes that and actually calls inode_change_ok() on the
    eCryptfs inode, fairly early in ecryptfs_setattr(). Ideally, the call
    would happen earlier in ecryptfs_setattr(), but there are some possible
    inode initialization steps that must happen first.

    Since the call was already being made on the lower inode, the change in
    functionality should be minimal, except for the case of a file extending
    truncate call. In that case, inode_newsize_ok() was never being
    called on the eCryptfs inode. Rather than inode_newsize_ok() catching
    maximum file size errors early on, eCryptfs would encrypt zeroed pages
    and write them to the lower filesystem until the lower filesystem's
    write path caught the error in generic_write_checks(). This patch
    introduces a new function, called ecryptfs_inode_newsize_ok(), which
    checks if the new lower file size is within the appropriate limits when
    the truncate operation will be growing the lower file.

    In summary this change prevents eCryptfs truncate operations (and the
    resulting page encryptions), which would exceed the lower filesystem
    limits or FSIZE rlimits, from ever starting.

    Signed-off-by: Tyler Hicks
    Reviewed-by: Li Wang
    Cc:

    Tyler Hicks
     
  • ecryptfs_write() handles the truncation of eCryptfs inodes. It grabs a
    page, zeroes out the appropriate portions, and then encrypts the page
    before writing it to the lower filesystem. It was unkillable and due to
    the lack of sparse file support could result in tying up a large portion
    of system resources, while encrypting pages of zeros, with no way for
    the truncate operation to be stopped from userspace.

    This patch adds the ability for ecryptfs_write() to detect a pending
    fatal signal and return as gracefully as possible. The intent is to
    leave the lower file in a useable state, while still allowing a user to
    break out of the encryption loop. If a pending fatal signal is detected,
    the eCryptfs inode size is updated to reflect the modified inode size
    and then -EINTR is returned.

    Signed-off-by: Tyler Hicks
    Cc:

    Tyler Hicks
     
  • ecryptfs_write() can enter an infinite loop when truncating a file to a
    size larger than 4G. This only happens on architectures where size_t is
    represented by 32 bits.

    This was caused by a size_t overflow due to it incorrectly being used to
    store the result of a calculation which uses potentially large values of
    type loff_t.

    [tyhicks@canonical.com: rewrite subject and commit message]
    Signed-off-by: Li Wang
    Signed-off-by: Yunchuan Wen
    Reviewed-by: Cong Wang
    Cc:
    Signed-off-by: Tyler Hicks

    Li Wang
     
  • ecryptfs_miscdev_read() and ecryptfs_miscdev_write() contained many
    magic numbers for specifying packet header field sizes and offsets. This
    patch defines those values and replaces the magic values.

    Signed-off-by: Tyler Hicks

    Tyler Hicks
     
  • Errors in writes to /dev/ecryptfs were being incorrectly reported by
    returning 0 or the value of the original write count.

    This patch clears up the return code assignment in error paths.

    Signed-off-by: Tyler Hicks

    Tyler Hicks
     
  • A malicious count value specified when writing to /dev/ecryptfs may
    result in a a very large kernel memory allocation.

    This patch peeks at the specified packet payload size, adds that to the
    size of the packet headers and compares the result with the write count
    value. The resulting maximum memory allocation size is approximately 532
    bytes.

    Signed-off-by: Tyler Hicks
    Reported-by: Sasha Levin
    Cc:

    Tyler Hicks
     
  • Removes unneeded variable initialization in ecryptfs_read_metadata(). Also adds
    a small comment to help explain metadata reading logic.

    [tyhicks@canonical.com: Pulled out of for-stable patch and wrote commit msg]
    Signed-off-by: Tim Gardner
    Signed-off-by: Tyler Hicks

    Tim Gardner
     
  • Print inode on metadata read failure. The only real
    way of dealing with metadata read failures is to delete
    the underlying file system file. Having the inode
    allows one to 'find . -inum INODE`.

    [tyhicks@canonical.com: Removed some minor not-for-stable parts]
    Signed-off-by: Tim Gardner
    Reviewed-by: Kees Cook
    Cc: stable@vger.kernel.org
    Signed-off-by: Tyler Hicks

    Tim Gardner
     
  • Update my email address in MAINTAINERS.

    Signed-off-by: Dustin Kirkland
    Signed-off-by: Tyler Hicks

    Dustin Kirkland
     
  • Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
    regressions in the nouveau driver.

    move_notify() was originally able to presume that bo->mem is the old node,
    and new_mem is the new node. The above commit moves the call to
    move_notify() to after move() has been done, which means that now, sometimes,
    new_mem isn't the new node at all, bo->mem is, and new_mem points at a
    stale, possibly-just-been-killed-by-move node.

    This is clearly not a good situation. This patch reverts this change, and
    replaces it with a cleanup in the move() failure path instead.

    The second issue is that the call to move_notify() from cleanup_memtype_use()
    causes the TTM ghost objects to get passed into the driver. This is clearly
    bad as the driver knows nothing about these "fake" TTM BOs, and ends up
    accessing uninitialised memory.

    I worked around this in nouveau's move_notify() hook by ensuring the BO
    destructor was nouveau's. I don't particularly like this solution, and
    would rather TTM never pass the driver these objects. However, I don't
    clearly understand the reason why we're calling move_notify() here anyway
    and am happy to work around the problem in nouveau instead of breaking the
    behaviour expected by other drivers.

    Signed-off-by: Ben Skeggs
    Reviewed-by: Thomas Hellstrom
    Cc: Jerome Glisse
    Signed-off-by: Dave Airlie

    Ben Skeggs
     
  • Commit b52a360b forgot to call xfs_iunlock() when it detected corrupted
    symplink and bailed out. Fix it by jumping to 'out' instead of doing return.

    CC: stable@kernel.org
    CC: Carlos Maiolino
    Signed-off-by: Jan Kara
    Reviewed-by: Alex Elder
    Reviewed-by: Dave Chinner
    Signed-off-by: Ben Myers

    Jan Kara
     

25 Jan, 2012

3 commits

  • If GPU lockup is detected in ib_pool get we are holding the ib_pool
    mutex that will be needed by the GPU reset code. As ib_pool code is
    safe to be reentrant from GPU reset code we should not block if we
    are trying to get the ib pool lock on the behalf of the same userspace
    caller, thus use the radeon_mutex_lock helper.

    Signed-off-by: Jerome Glisse
    Signed-off-by: Dave Airlie

    Jerome Glisse
     
  • Silence out the lock dependency warning by moving bo allocation out
    of ib mutex protected section. Might lead to useless temporary
    allocation but it's not harmful as such things only happen at
    initialization.

    Signed-off-by: Jerome Glisse
    Signed-off-by: Dave Airlie

    Jerome Glisse
     
  • If the master tries to authenticate a client using drm_authmagic and
    that client has already closed its drm file descriptor,
    either wilfully or because it was terminated, the
    call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
    and corrupt it.

    Typically this results in a hard system hang.

    This patch fixes that problem by removing any authentication tokens
    (struct drm_magic_entry) open for a file descriptor when that file
    descriptor is closed.

    Signed-off-by: Thomas Hellstrom
    Reviewed-by: Daniel Vetter
    Cc: stable@vger.kernel.org
    Signed-off-by: Dave Airlie

    Thomas Hellstrom