Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on May 20, 2009
  1. @gregkh

    Linux 2.6.27.24

    gregkh authored
  2. @gregkh

    ocfs2: fix i_mutex locking in ocfs2_splice_to_file()

    Miklos Szeredi authored gregkh committed
    commit 328eaab upstream.
    
    Rearrange locking of i_mutex on destination and call to
    ocfs2_rw_lock() so locks are only held while buffers are copied with
    the pipe_to_file() actor, and not while waiting for more data on the
    pipe.
    
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @gregkh

    splice: fix i_mutex locking in generic_splice_write()

    Miklos Szeredi authored gregkh committed
    commit eb443e5 upstream.
    
    Rearrange locking of i_mutex on destination so it's only held while
    buffers are copied with the pipe_to_file() actor, and not while
    waiting for more data on the pipe.
    
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @gregkh

    splice: remove i_mutex locking in splice_from_pipe()

    Miklos Szeredi authored gregkh committed
    commit 2933970 upstream.
    
    splice_from_pipe() is only called from two places:
    
      - generic_splice_sendpage()
      - splice_write_null()
    
    Neither of these require i_mutex to be taken on the destination inode.
    
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @gregkh

    splice: split up __splice_from_pipe()

    Miklos Szeredi authored gregkh committed
    commit b3c2d2d upstream.
    
    Split up __splice_from_pipe() into four helper functions:
    
      splice_from_pipe_begin()
      splice_from_pipe_next()
      splice_from_pipe_feed()
      splice_from_pipe_end()
    
    splice_from_pipe_next() will wait (if necessary) for more buffers to
    be added to the pipe.  splice_from_pipe_feed() will feed the buffers
    to the supplied actor and return when there's no more data available
    (or if all of the requested data has been copied).
    
    This is necessary so that implementations can do locking around the
    non-waiting splice_from_pipe_feed().
    
    This patch should not cause any change in behavior.
    
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @gregkh

    powerpc/5200: Don't specify IRQF_SHARED in PSC UART driver

    Grant Likely authored gregkh committed
    commit d9f0c5f upstream.
    
    The MPC5200 PSC device is wired up to a dedicated interrupt line
    which is never shared.  This patch removes the IRQF_SHARED flag
    from the request_irq() call which eliminates the "IRQF_DISABLED
    is not guaranteed on shared IRQs" warning message from the console
    output.
    
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
    Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @gregkh

    ehea: fix invalid pointer access

    Hannes Hering authored gregkh committed
    commit 0b2febf upstream.
    
    This patch fixes an invalid pointer access in case the receive queue
    holds no pointer to the next skb when the queue is empty.
    
    Signed-off-by: Hannes Hering <hering2@de.ibm.com>
    Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @gregkh

    NFS: Fix the notifications when renaming onto an existing file

    Trond Myklebust authored gregkh committed
    commit b1e4adf upstream.
    
    NFS appears to be returning an unnecessary "delete" notification when
    we're doing an atomic rename. See
    
      http://bugzilla.gnome.org/show_bug.cgi?id=575684
    
    The fix is to get rid of the redundant call to d_delete().
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @gregkh

    nfsd4: check for negative dentry before use in nfsv4 readdir

    J. Bruce Fields authored gregkh committed
    commit b2c0cea upstream.
    
    After 2f9092e "Fix i_mutex vs.  readdir
    handling in nfsd" (and 14f7dd6 "Copy XFS readdir hack into nfsd code"),
    an entry may be removed between the first mutex_unlock and the second
    mutex_lock. In this case, lookup_one_len() will return a negative
    dentry.  Check for this case to avoid a NULL dereference.
    
    Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
    Reviewed-by: J. R. Okajima <hooanon05@yahoo.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @davidel @gregkh

    epoll: fix size check in epoll_create()

    davidel authored gregkh committed
    commit bfe3891 upstream.
    
    Fix a size check WRT the manual pages.  This was inadvertently broken by
    commit 9fe5ad9 ("flag parameters
    add-on: remove epoll_create size param").
    
    Signed-off-by: Davide Libenzi <davidel@xmailserver.org>
    Cc: <Hiroyuki.Mach@gmail.com>
    Cc: rohit verma <rohit.170309@gmail.com>
    Cc: Ulrich Drepper <drepper@redhat.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@suse.de>
  11. @gregkh

    cifs: Fix unicode string area word alignment in session setup

    Jeff Layton authored gregkh committed
    commit 27b87fe refreshed.
    
    cifs: fix unicode string area word alignment in session setup
    
    The handling of unicode string area alignment is wrong.
    decode_unicode_ssetup improperly assumes that it will always be preceded
    by a pad byte. This isn't the case if the string area is already
    word-aligned.
    
    This problem, combined with the bad buffer sizing for the serverDomain
    string can cause memory corruption. The bad alignment can make it so
    that the alignment of the characters is off. This can make them
    translate to characters that are greater than 2 bytes each. If this
    happens we can overflow the allocation.
    
    Fix this by fixing the alignment in CIFS_SessSetup instead so we can
    verify it against the head of the response. Also, clean up the
    workaround for improperly terminated strings by checking for a
    odd-length unicode buffers and then forcibly terminating them.
    
    Finally, resize the buffer for serverDomain. Now that we've fixed
    the alignment, it's probably fine, but a malicious server could
    overflow it.
    
    A better solution for handling these strings is still needed, but
    this should be a suitable bandaid.
    
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Cc: Suresh Jayaraman <sjayaraman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @gregkh

    cifs: Fix buffer size in cifs_convertUCSpath

    Suresh Jayaraman authored gregkh committed
    Relevant commits 7fabf0c and
    f588416. The upstream commits adds
    cifs_from_ucs2 that includes functionality of cifs_convertUCSpath and
    does cleanup.
    
    Reported-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
    Acked-by: Steve French <sfrench@us.ibm.com>
    Acked-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @gregkh

    cifs: Fix incorrect destination buffer size in cifs_strncpy_to_host

    Suresh Jayaraman authored gregkh committed
    Relevant commits 968460e and 
    066ce68. Minimal hunks to fix buffer
    size and fix an existing problem pointed out by Guenter Kukuk that length
    of src is used for NULL termination of dst. 
    
    cifs: Rename cifs_strncpy_to_host and fix buffer size
    
    There is a possibility for the path_name and node_name buffers to
    overflow if they contain charcters that are >2 bytes in the local
    charset. Resize the buffer allocation so to avoid this possibility.
    
    Also, as pointed out by Jeff Layton, it would be appropriate to
    rename the function to cifs_strlcpy_to_host to reflect the fact
    that the copied string is always NULL terminated.
    
    Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
    Acked-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @gregkh

    cifs: Increase size of tmp_buf in cifs_readdir to avoid potential ove…

    Suresh Jayaraman authored gregkh committed
    …rflows
    
    Commit 7b0c8fc refreshed and use
    a #define from commit f588416.
    
    cifs: Increase size of tmp_buf in cifs_readdir to avoid potential overflows
    
    Increase size of tmp_buf to possible maximum to avoid potential
    overflows. Also moved UNICODE_NAME_MAX definition so that it can be used
    elsewhere.
    
    Pointed-out-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
    Acked-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @gregkh

    cifs: Fix buffer size for tcon->nativeFileSystem field

    Jeff Layton authored gregkh committed
    Commit f083def refreshed.
    
    cifs: fix buffer size for tcon->nativeFileSystem field
    
    The buffer for this was resized recently to fix a bug. It's still
    possible however that a malicious server could overflow this field
    by sending characters in it that are >2 bytes in the local charset.
    Double the size of the buffer to account for this possibility.
    
    Also get rid of some really strange and seemingly pointless NULL
    termination. It's NULL terminating the string in the source buffer,
    but by the time that happens, we've already copied the string.
    
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Cc: Suresh Jayaraman <sjayaraman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @gregkh

    NFS: Close page_mkwrite() races

    Trond Myklebust authored gregkh committed
    commit 7fdf523 upstream
    
    Follow up to Nick Piggin's patches to ensure that nfs_vm_page_mkwrite
    returns with the page lock held, and sets the VM_FAULT_LOCKED flag.
    
    See http://bugzilla.kernel.org/show_bug.cgi?id=12913
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Nick Piggin <npiggin@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @gregkh

    NFS: Fix the return value in nfs_page_mkwrite()

    Trond Myklebust authored gregkh committed
    commit 2b2ec75 upstream
    
    Commit c2ec175 ("mm: page_mkwrite
    change prototype to match fault") exposed a bug in the NFS
    implementation of page_mkwrite.  We should be returning 0 on success...
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Nick Piggin <npiggin@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @gregkh

    GFS2: Fix page_mkwrite() return code

    Steven Whitehouse authored gregkh committed
    commit e56985d upstream
    
    This allows for the possibility of returning VM_FAULT_OOM as
    well as VM_FAULT_SIGBUS. This ensures that the correct action
    is taken.
    
    Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
    Cc: Nick Piggin <npiggin@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @gregkh

    mm: close page_mkwrite races

    Nick Piggin authored gregkh committed
    commit b827e49 upstream
    
    mm: close page_mkwrite races
    
    Change page_mkwrite to allow implementations to return with the page
    locked, and also change it's callers (in page fault paths) to hold the
    lock until the page is marked dirty.  This allows the filesystem to have
    full control of page dirtying events coming from the VM.
    
    Rather than simply hold the page locked over the page_mkwrite call, we
    call page_mkwrite with the page unlocked and allow callers to return with
    it locked, so filesystems can avoid LOR conditions with page lock.
    
    The problem with the current scheme is this: a filesystem that wants to
    associate some metadata with a page as long as the page is dirty, will
    perform this manipulation in its ->page_mkwrite.  It currently then must
    return with the page unlocked and may not hold any other locks (according
    to existing page_mkwrite convention).
    
    In this window, the VM could write out the page, clearing page-dirty.  The
    filesystem has no good way to detect that a dirty pte is about to be
    attached, so it will happily write out the page, at which point, the
    filesystem may manipulate the metadata to reflect that the page is no
    longer dirty.
    
    It is not always possible to perform the required metadata manipulation in
    ->set_page_dirty, because that function cannot block or fail.  The
    filesystem may need to allocate some data structure, for example.
    
    And the VM cannot mark the pte dirty before page_mkwrite, because
    page_mkwrite is allowed to fail, so we must not allow any window where the
    page could be written to if page_mkwrite does fail.
    
    This solution of holding the page locked over the 3 critical operations
    (page_mkwrite, setting the pte dirty, and finally setting the page dirty)
    closes out races nicely, preventing page cleaning for writeout being
    initiated in that window.  This provides the filesystem with a strong
    synchronisation against the VM here.
    
    - Sage needs this race closed for ceph filesystem.
    - Trond for NFS (http://bugzilla.kernel.org/show_bug.cgi?id=12913).
    - I need it for fsblock.
    - I suspect other filesystems may need it too (eg. btrfs).
    - I have converted buffer.c to the new locking. Even simple block allocation
      under dirty pages might be susceptible to i_size changing under partial page
      at the end of file (we also have a buffer.c-side problem here, but it cannot
      be fixed properly without this patch).
    - Other filesystems (eg. NFS, maybe btrfs) will need to change their
      page_mkwrite functions themselves.
    
    [ This also moves page_mkwrite another step closer to fault, which should
      eventually allow page_mkwrite to be moved into ->fault, and thus avoiding a
      filesystem calldown and page lock/unlock cycle in __do_fault. ]
    
    [akpm@linux-foundation.org: fix derefs of NULL ->mapping]
    Cc: Sage Weil <sage@newdream.net>
    Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
    Signed-off-by: Nick Piggin <npiggin@suse.de>
    Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
    Cc: <stable@kernel.org>
    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@suse.de>
  20. @gregkh

    fs: fix page_mkwrite error cases in core code and btrfs

    Nick Piggin authored gregkh committed
    commit 56a76f8 upstream
    
    
    fs: fix page_mkwrite error cases in core code and btrfs
    
    page_mkwrite is called with neither the page lock nor the ptl held.  This
    means a page can be concurrently truncated or invalidated out from
    underneath it.  Callers are supposed to prevent truncate races themselves,
    however previously the only thing they can do in case they hit one is to
    raise a SIGBUS.  A sigbus is wrong for the case that the page has been
    invalidated or truncated within i_size (eg.  hole punched).  Callers may
    also have to perform memory allocations in this path, where again, SIGBUS
    would be wrong.
    
    The previous patch ("mm: page_mkwrite change prototype to match fault")
    made it possible to properly specify errors.  Convert the generic buffer.c
    code and btrfs to return sane error values (in the case of page removed
    from pagecache, VM_FAULT_NOPAGE will cause the fault handler to exit
    without doing anything, and the fault will be retried properly).
    
    This fixes core code, and converts btrfs as a template/example.  All other
    filesystems defining their own page_mkwrite should be fixed in a similar
    manner.
    
    Acked-by: Chris Mason <chris.mason@oracle.com>
    Signed-off-by: Nick Piggin <npiggin@suse.de>
    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@suse.de>
  21. @gregkh

    mm: page_mkwrite change prototype to match fault

    Nick Piggin authored gregkh committed
    commit c2ec175 upstream
    
    
    mm: page_mkwrite change prototype to match fault
    
    Change the page_mkwrite prototype to take a struct vm_fault, and return
    VM_FAULT_xxx flags.  There should be no functional change.
    
    This makes it possible to return much more detailed error information to
    the VM (and also can provide more information eg.  virtual_address to the
    driver, which might be important in some special cases).
    
    This is required for a subsequent fix.  And will also make it easier to
    merge page_mkwrite() with fault() in future.
    
    Signed-off-by: Nick Piggin <npiggin@suse.de>
    Cc: Chris Mason <chris.mason@oracle.com>
    Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
    Cc: Miklos Szeredi <miklos@szeredi.hu>
    Cc: Steven Whitehouse <swhiteho@redhat.com>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Cc: Joel Becker <joel.becker@oracle.com>
    Cc: Artem Bityutskiy <dedekind@infradead.org>
    Cc: Felix Blyakher <felixb@sgi.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@suse.de>
  22. @gregkh

    i2c-algo-pca: Let PCA9564 recover from unacked data byte (state 0x30)

    Enrik Berkhan authored gregkh committed
    commit 2196d1c upstream
    
    Currently, the i2c-algo-pca driver does nothing if the chip enters state
    0x30 (Data byte in I2CDAT has been transmitted; NOT ACK has been
    received).  Thus, the i2c bus connected to the controller gets stuck
    afterwards.
    
    I have seen this kind of error on a custom board in certain load
    situations most probably caused by interference or noise.
    
    A possible reaction is to let the controller generate a STOP condition.
    This is documented in the PCA9564 data sheet (2006-09-01) and the same
    is done for other NACK states as well.
    
    Further, state 0x38 isn't handled completely, either. Try to do another
    START in this case like the data sheet says. As this couldn't be tested,
    I've added a comment to try to reset the chip if the START doesn't help
    as suggested by Wolfram Sang.
    
    Signed-off-by: Enrik Berkhan <Enrik.Berkhan@ge.com>
    Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @gregkh

    i2c-algo-bit: Fix timeout test

    Dave Airlie authored gregkh committed
    commit 0cdba07 upstream
    
    When fetching DDC using i2c algo bit, we were often seeing timeouts
    before getting valid EDID on a retry. The VESA spec states 2ms is the
    DDC timeout, so when this translates into 1 jiffie and we are close
    to the end of the time period, it could return with a timeout less than
    2ms.
    
    Change this code to use time_after instead of time_after_eq.
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. @jeffmahoney @gregkh

    dup2: Fix return value with oldfd == newfd and invalid fd

    jeffmahoney authored gregkh committed
    commit 2b79bc4 upstream.
    
    The return value of dup2 when oldfd == newfd and the fd isn't valid is
    not getting properly sign extended.  We end up with 4294967287 instead
    of -EBADF.
    
    I've reproduced this on SLE11 (2.6.27.21), openSUSE Factory
    (2.6.29-rc5), and Ubuntu 9.04 (2.6.28).
    
    This patch uses a signed int for the error value so it is properly
    extended.
    
    Commit 6c5d051 introduced this
    regression.
    
    Reported-by: Jiri Dluhos <jdluhos@novell.com>
    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  25. @gregkh

    USB: Gadget: fix UTF conversion in the usbstring library

    Alan Stern authored gregkh committed
    commit 0f43158 upstream.
    
    This patch (as1234) fixes a bug in the UTF8 -> UTF-16 conversion
    routine in the gadget/usbstring library.  In a UTF-8 multi-byte
    sequence, all bytes after the first should have their high-order
    two bits set to 10, not 11.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Acked-by: David Brownell <dbrownell@users.sourceforge.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. @neilbrown @gregkh

    md: remove ability to explicit set an inactive array to 'clean'.

    neilbrown authored gregkh committed
    commit 5bf2959 upstream.
    
    Being able to write 'clean' to an 'array_state' of an inactive array
    to activate it in 'clean' mode is both unnecessary and inconvenient.
    
    It is unnecessary because the same can be achieved by writing
    'active'.  This activates and array, but it still remains 'clean'
    until the first write.
    
    It is inconvenient because writing 'clean' is more often used to
    cause an 'active' array to revert to 'clean' mode (thus blocking
    any writes until a 'write-pending' is promoted to 'active').
    
    Allowing 'clean' to both activate an array and mark an active array as
    clean can lead to races:  One program writes 'clean' to mark the
    active array as clean at the same time as another program writes
    'inactive' to deactivate (stop) and active array.  Depending on which
    writes first, the array could be deactivated and immediately
    reactivated which isn't what was desired.
    
    So just disable the use of 'clean' to activate an array.
    
    This avoids a race that can be triggered with mdadm-3.0 and external
    metadata, so it suitable for -stable.
    
    Reported-by: Rafal Marszewski <rafal.marszewski@intel.com>
    Acked-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. @neilbrown @gregkh

    md/raid10: don't clear bitmap during recovery if array will still be …

    neilbrown authored gregkh committed
    …degraded.
    
    commit 1805556 upstream.
    
    If we have a raid10 with multiple missing devices, and we recover just
    one of these to a spare, then we risk (depending on the bitmap and
    array chunk size) clearing bits of the bitmap for which recovery isn't
    complete (because a device is still missing).
    
    This can lead to a subsequent "re-add" being recovered without
    any IO happening, which would result in loss of data.
    
    This patch takes the safe approach of not clearing bitmap bits
    if the array will still be degraded.
    
    This patch is suitable for all active -stable kernels.
    
    Cc: stable@kernel.org
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  28. @neilbrown @gregkh

    md: fix some (more) errors with bitmaps on devices larger than 2TB.

    neilbrown authored gregkh committed
    commit db305e5 upstream.
    
    If a write intent bitmap covers more than 2TB, we sometimes work with
    values beyond 32bit, so these need to be sector_t.  This patches
    add the required casts to some unsigned longs that are being shifted
    up.
    
    This will affect any raid10 larger than 2TB, or any raid1/4/5/6 with
    member devices that are larger than 2TB.
    
    Signed-off-by: NeilBrown <neilb@suse.de>
    Reported-by: "Mario 'BitKoenig' Holbe" <Mario.Holbe@TU-Ilmenau.DE>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  29. @neilbrown @gregkh

    md: fix loading of out-of-date bitmap.

    neilbrown authored gregkh committed
    commit b74fd28 upstream.
    
    When md is loading a bitmap which it knows is out of date, it fills
    each page with 1s and writes it back out again.  However the
    write_page call makes used of bitmap->file_pages and
    bitmap->last_page_size which haven't been set correctly yet.  So this
    can sometimes fail.
    
    Move the setting of file_pages and last_page_size to before the call
    to write_page.
    
    This bug can cause the assembly on an array to fail, thus making the
    data inaccessible.  Hence I think it is a suitable candidate for
    -stable.
    
    Reported-by: Vojtech Pavlik <vojtech@suse.cz>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commits on May 8, 2009
  1. @gregkh

    Linux 2.6.27.23

    gregkh authored
  2. @jkivilin @gregkh

    rndis_wlan: fix initialization order for workqueue&workers

    jkivilin authored gregkh committed
    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:
    	http://bugzilla.kernel.org/show_bug.cgi?id=12794
    
    Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @gregkh

    proc: avoid information leaks to non-privileged processes

    Jake Edge authored gregkh committed
    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 http://code.google.com/p/fuzzyaslr/ As part of a presentation
    (http://www.cr0.org/paper/to-jt-linux-alsr-leak.pdf) 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 <stable@kernel.org>
    Signed-off-by: Jake Edge <jake@lwn.net>
    Acked-by: Arjan van de Ven <arjan@linux.intel.com>
    Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @buytenh @gregkh

    mv643xx_eth: 64bit mib counter read fix

    buytenh authored gregkh committed
    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 <buytenh@marvell.com>
    Cc: stable@kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @gormanm @gregkh

    Ignore madvise(MADV_WILLNEED) for hugetlbfs-backed regions

    gormanm authored gregkh committed
    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
    regions.
    
    Signed-off-by: Mel Gorman <mel@csn.ul.ie>
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @gregkh

    clockevents: prevent endless loop in tick_handle_periodic()

    john stultz authored gregkh committed
    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
    forever.
    
    [ Impact: prevent hard lock up ]
    
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.