Skip to content
Commits on Sep 14, 2012
  1. @gregkh

    Linux 3.0.43

    gregkh committed Sep 14, 2012
  2. @tettamanti @gregkh

    hwmon: (asus_atk0110) Add quirk for Asus M5A78L

    commit 43ca6cb upstream.
    
    The old interface is bugged and reads the wrong sensor when retrieving
    the reading for the chassis fan (it reads the CPU sensor); the new
    interface works fine.
    
    Reported-by: Göran Uddeborg <goeran@uddeborg.se>
    Tested-by: Göran Uddeborg <goeran@uddeborg.se>
    Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    tettamanti committed with gregkh Aug 21, 2012
  3. @minipli @gregkh

    dccp: check ccid before dereferencing

    commit 276bdb8 upstream.
    
    ccid_hc_rx_getsockopt() and ccid_hc_tx_getsockopt() might be called with
    a NULL ccid pointer leading to a NULL pointer dereference. This could
    lead to a privilege escalation if the attacker is able to map page 0 and
    prepare it with a fake ccid_ops pointer.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    minipli committed with gregkh Aug 15, 2012
  4. @gregkh

    PARISC: Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts

    commit bba3d8c upstream.
    
    The following build error occured during a parisc build with
    swap-over-NFS patches applied.
    
    net/core/sock.c:274:36: error: initializer element is not constant
    net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
    net/core/sock.c:274:36: error: initializer element is not constant
    
    Dave Anglin says:
    > Here is the line in sock.i:
    >
    > struct static_key memalloc_socks = ((struct static_key) { .enabled =
    > ((atomic_t) { (0) }) });
    
    The above line contains two compound literals.  It also uses a designated
    initializer to initialize the field enabled.  A compound literal is not a
    constant expression.
    
    The location of the above statement isn't fully clear, but if a compound
    literal occurs outside the body of a function, the initializer list must
    consist of constant expressions.
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Mel Gorman committed with gregkh Jul 23, 2012
  5. @gregkh

    drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot

    commit c490342 upstream.
    
    This will cause udev to load vmwgfx instead of waiting for X
    to do it.
    
    Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Dave Airlie committed with gregkh Aug 28, 2012
  6. @dtor @gregkh

    Input: i8042 - add Gigabyte T1005 series netbooks to noloop table

    commit 7b125b9 upstream.
    
    They all define their chassis type as "Other" and therefore are not
    categorized as "laptops" by the driver, which tries to perform AUX IRQ
    delivery test which fails and causes touchpad not working.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42620
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    dtor committed with gregkh Aug 21, 2012
  7. @gregkh

    fuse: fix retrieve length

    commit c9e67d4 upstream.
    
    In some cases fuse_retrieve() would return a short byte count if offset was
    non-zero.  The data returned was correct, though.
    
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Miklos Szeredi committed with gregkh Sep 4, 2012
  8. @jankara @gregkh

    ext3: Fix fdatasync() for files with only i_size changes

    commit 156bddd upstream.
    
    Code tracking when transaction needs to be committed on fdatasync(2) forgets
    to handle a situation when only inode's i_size is changed. Thus in such
    situations fdatasync(2) doesn't force transaction with new i_size to disk
    and that can result in wrong i_size after a crash.
    
    Fix the issue by updating inode's i_datasync_tid whenever its size is
    updated.
    
    Reported-by: Kristian Nielsen <knielsen@knielsen-hq.org>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    jankara committed with gregkh Sep 3, 2012
  9. @jankara @gregkh

    udf: Fix data corruption for files in ICB

    commit 9c2fc0d upstream.
    
    When a file is stored in ICB (inode), we overwrite part of the file, and
    the page containing file's data is not in page cache, we end up corrupting
    file's data by overwriting them with zeros. The problem is we use
    simple_write_begin() which simply zeroes parts of the page which are not
    written to. The problem has been introduced by be021ee (udf: convert to
    new aops).
    
    Fix the problem by providing a ->write_begin function which makes the page
    properly uptodate.
    
    Reported-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    jankara committed with gregkh Sep 5, 2012
  10. @gregkh

    SCSI: Fix 'Device not ready' issue on mpt2sas

    commit 1421656 upstream.
    
    This is a particularly nasty SCSI ATA Translation Layer (SATL) problem.
    
    SAT-2 says (section 8.12.2)
    
            if the device is in the stopped state as the result of
            processing a START STOP UNIT command (see 9.11), then the SATL
            shall terminate the TEST UNIT READY command with CHECK CONDITION
            status with the sense key set to NOT READY and the additional
            sense code of LOGICAL UNIT NOT READY, INITIALIZING COMMAND
            REQUIRED;
    
    mpt2sas internal SATL seems to implement this.  The result is very confusing
    standby behaviour (using hdparm -y).  If you suspend a drive and then send
    another command, usually it wakes up.  However, if the next command is a TEST
    UNIT READY, the SATL sees that the drive is suspended and proceeds to follow
    the SATL rules for this, returning NOT READY to all subsequent commands.  This
    means that the ordering of TEST UNIT READY is crucial: if you send TUR and
    then a command, you get a NOT READY to both back.  If you send a command and
    then a TUR, you get GOOD status because the preceeding command woke the drive.
    
    This bit us badly because
    
    commit 85ef06d
    Author: Tejun Heo <tj@kernel.org>
    Date:   Fri Jul 1 16:17:47 2011 +0200
    
        block: flush MEDIA_CHANGE from drivers on close(2)
    
    Changed our ordering on TEST UNIT READY commands meaning that SATA drives
    connected to an mpt2sas now suspend and refuse to wake (because the mpt2sas
    SATL sees the suspend *before* the drives get awoken by the next ATA command)
    resulting in lots of failed commands.
    
    The standard is completely nuts forcing this inconsistent behaviour, but we
    have to work around it.
    
    The fix for this is twofold:
    
       1. Set the allow_restart flag so we wake the drive when we see it has been
          suspended
    
       2. Return all TEST UNIT READY status directly to the mid layer without any
          further error handling which prevents us causing error handling which
          may offline the device just because of a media check TUR.
    
    Reported-by: Matthias Prager <linux@matthiasprager.de>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    James Bottomley committed with gregkh Jul 25, 2012
  11. @gregkh

    SCSI: mpt2sas: Fix for Driver oops, when loading driver with max_queu…

    …e_depth command line option to a very small value
    
    commit 338b131 upstream.
    
    If the specified max_queue_depth setting is less than the
    expected number of internal commands, then driver will calculate
    the queue depth size to a negitive number. This negitive number
    is actually a very large number because variable is unsigned
    16bit integer. So, the driver will ask for a very large amount of
    memory for message frames and resulting into oops as memory
    allocation routines will not able to handle such a large request.
    
    So, in order to limit this kind of oops, The driver need to set
    the max_queue_depth to a scsi mid layer's can_queue value. Then
    the overall message frames required for IO is minimum of either
    (max_queue_depth plus internal commands) or the IOC global
    credits.
    
    Signed-off-by: Sreekanth Reddy <sreekanth.reddy@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    sreekanth.reddy@lsi.com committed with gregkh Jul 17, 2012
  12. @gregkh

    SCSI: megaraid_sas: Move poll_aen_lock initializer

    commit bd8d6dd upstream.
    
    The following patch moves the poll_aen_lock initializer from
    megasas_probe_one() to megasas_init().  This prevents a crash when a user
    loads the driver and tries to issue a poll() system call on the ioctl
    interface with no adapters present.
    
    Signed-off-by: Kashyap Desai <Kashyap.Desai@lsi.com>
    Signed-off-by: Adam Radford <aradford@gmail.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Kashyap Desai committed with gregkh Jul 17, 2012
  13. @kernelslacker @gregkh

    Remove user-triggerable BUG from mpol_to_str

    commit 80de7c3 upstream.
    
    Trivially triggerable, found by trinity:
    
      kernel BUG at mm/mempolicy.c:2546!
      Process trinity-child2 (pid: 23988, threadinfo ffff88010197e000, task ffff88007821a670)
      Call Trace:
        show_numa_map+0xd5/0x450
        show_pid_numa_map+0x13/0x20
        traverse+0xf2/0x230
        seq_read+0x34b/0x3e0
        vfs_read+0xac/0x180
        sys_pread64+0xa2/0xc0
        system_call_fastpath+0x1a/0x1f
      RIP: mpol_to_str+0x156/0x360
    
    Signed-off-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    kernelslacker committed with gregkh Sep 6, 2012
  14. @antonblanchard @gregkh

    powerpc: Restore correct DSCR in context switch

    commit 7143328 upstream.
    
    During a context switch we always restore the per thread DSCR value.
    If we aren't doing explicit DSCR management
    (ie thread.dscr_inherit == 0) and the default DSCR changed while
    the process has been sleeping we end up with the wrong value.
    
    Check thread.dscr_inherit and select the default DSCR or per thread
    DSCR as required.
    
    This was found with the following test case, when running with
    more threads than CPUs (ie forcing context switching):
    
    http://ozlabs.org/~anton/junkcode/dscr_default_test.c
    
    With the four patches applied I can run a combination of all
    test cases successfully at the same time:
    
    http://ozlabs.org/~anton/junkcode/dscr_default_test.c
    http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c
    http://ozlabs.org/~anton/junkcode/dscr_inherit_test.c
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    antonblanchard committed with gregkh Sep 3, 2012
  15. @antonblanchard @gregkh

    powerpc: Fix DSCR inheritance in copy_thread()

    commit 1021cb2 upstream.
    
    If the default DSCR is non zero we set thread.dscr_inherit in
    copy_thread() meaning the new thread and all its children will ignore
    future updates to the default DSCR. This is not intended and is
    a change in behaviour that a number of our users have hit.
    
    We just need to inherit thread.dscr and thread.dscr_inherit from
    the parent which ends up being much simpler.
    
    This was found with the following test case:
    
    http://ozlabs.org/~anton/junkcode/dscr_default_test.c
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    antonblanchard committed with gregkh Sep 3, 2012
  16. @sschnelle @gregkh

    USB: CDC ACM: Fix NULL pointer dereference

    commit 99f347c upstream.
    
    If a device specifies zero endpoints in its interface descriptor,
    the kernel oopses in acm_probe(). Even though that's clearly an
    invalid descriptor, we should test wether we have all endpoints.
    This is especially bad as this oops can be triggered by just
    plugging a USB device in.
    
    Signed-off-by: Sven Schnelle <svens@stackframe.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    sschnelle committed with gregkh Aug 17, 2012
  17. @gregkh

    USB: smsusb: remove __devinit* from the struct usb_device_id table

    commit d04dbd1 upstream.
    
    This structure needs to always stick around, even if CONFIG_HOTPLUG
    is disabled, otherwise we can oops when trying to probe a device that
    was added after the structure is thrown away.
    
    Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Reported-by: Bjørn Mork <bjorn@mork.no>
    CC: Mauro Carvalho Chehab <mchehab@infradead.org>
    CC: Michael Krufky <mkrufky@linuxtv.org>
    CC: Paul Gortmaker <paul.gortmaker@windriver.com>
    CC: Doron Cohen <doronc@siano-ms.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    gregkh committed Aug 17, 2012
  18. @gregkh

    USB: rtl8187: remove __devinit* from the struct usb_device_id table

    commit a343317 upstream.
    
    This structure needs to always stick around, even if CONFIG_HOTPLUG
    is disabled, otherwise we can oops when trying to probe a device that
    was added after the structure is thrown away.
    
    Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Reported-by: Bjørn Mork <bjorn@mork.no>
    CC: Herton Ronaldo Krzesinski <herton@canonical.com>
    CC: Hin-Tak Leung <htl10@users.sourceforge.net>
    CC: Larry Finger <Larry.Finger@lwfinger.net>
    CC: "John W. Linville" <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    gregkh committed Aug 17, 2012
  19. @gregkh

    USB: p54usb: remove __devinit* from the struct usb_device_id table

    commit b9c4167 upstream.
    
    This structure needs to always stick around, even if CONFIG_HOTPLUG
    is disabled, otherwise we can oops when trying to probe a device that
    was added after the structure is thrown away.
    
    Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Reported-by: Bjørn Mork <bjorn@mork.no>
    CC: Christian Lamparter <chunkeey@googlemail.com>
    CC: "John W. Linville" <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    gregkh committed Aug 17, 2012
  20. @gregkh

    USB: spca506: remove __devinit* from the struct usb_device_id table

    commit e694d51 upstream.
    
    This structure needs to always stick around, even if CONFIG_HOTPLUG
    is disabled, otherwise we can oops when trying to probe a device that
    was added after the structure is thrown away.
    
    Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Reported-by: Bjørn Mork <bjorn@mork.no>
    CC: Hans de Goede <hdegoede@redhat.com>
    CC: Mauro Carvalho Chehab <mchehab@infradead.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    gregkh committed Aug 17, 2012
  21. @gregkh

    block: replace __getblk_slow misfix by grow_dev_page fix

    commit 676ce6d upstream.
    
    Commit 91f68c8 ("block: fix infinite loop in __getblk_slow")
    is not good: a successful call to grow_buffers() cannot guarantee
    that the page won't be reclaimed before the immediate next call to
    __find_get_block(), which is why there was always a loop there.
    
    Yesterday I got "EXT4-fs error (device loop0): __ext4_get_inode_loc:3595:
    inode #19278: block 664: comm cc1: unable to read itable block" on console,
    which pointed to this commit.
    
    I've been trying to bisect for weeks, why kbuild-on-ext4-on-loop-on-tmpfs
    sometimes fails from a missing header file, under memory pressure on
    ppc G5.  I've never seen this on x86, and I've never seen it on 3.5-rc7
    itself, despite that commit being in there: bisection pointed to an
    irrelevant pinctrl merge, but hard to tell when failure takes between
    18 minutes and 38 hours (but so far it's happened quicker on 3.6-rc2).
    
    (I've since found such __ext4_get_inode_loc errors in /var/log/messages
    from previous weeks: why the message never appeared on console until
    yesterday morning is a mystery for another day.)
    
    Revert 91f68c8, restoring __getblk_slow() to how it was (plus
    a checkpatch nitfix).  Simplify the interface between grow_buffers()
    and grow_dev_page(), and avoid the infinite loop beyond end of device
    by instead checking init_page_buffers()'s end_block there (I presume
    that's more efficient than a repeated call to blkdev_max_block()),
    returning -ENXIO to __getblk_slow() in that case.
    
    And remove akpm's ten-year-old "__getblk() cannot fail ... weird"
    comment, but that is worrying: are all users of __getblk() really
    now prepared for a NULL bh beyond end of device, or will some oops??
    
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Hugh Dickins committed with gregkh Aug 23, 2012
  22. @rjwysocki @gregkh

    PCI: EHCI: Fix crash during hibernation on ASUS computers

    commit 0b68c8e upstream.
    
    Commit dbf0e4c (PCI: EHCI: fix crash during suspend on ASUS
    computers) added a workaround for an ASUS suspend issue related to
    USB EHCI and a bug in a number of ASUS BIOSes that attempt to shut
    down the EHCI controller during system suspend if its PCI command
    register doesn't contain 0 at that time.
    
    It turns out that the same workaround is necessary in the analogous
    hibernation code path, so add it.
    
    References: https://bugzilla.kernel.org/show_bug.cgi?id=45811
    Reported-and-tested-by: Oleksij Rempel <bug-track@fisher-privat.net>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    rjwysocki committed with gregkh Aug 12, 2012
  23. @LorenzoBianconi @gregkh

    ath9k: fix decrypt_error initialization in ath_rx_tasklet()

    commit e1352fd upstream.
    
    ath_rx_tasklet() calls ath9k_rx_skb_preprocess() and ath9k_rx_skb_postprocess()
    in a loop over the received frames. The decrypt_error flag is
    initialized to false
    just outside ath_rx_tasklet() loop. ath9k_rx_accept(), called by
    ath9k_rx_skb_preprocess(),
    only sets decrypt_error to true and never to false.
    Then ath_rx_tasklet() calls ath9k_rx_skb_postprocess() and passes
    decrypt_error to it.
    So, after a decryption error, in ath9k_rx_skb_postprocess(), we can
    have a leftover value
    from another processed frame. In that case, the frame will not be marked with
    RX_FLAG_DECRYPTED even if it is decrypted correctly.
    When using CCMP encryption this issue can lead to connection stuck
    because of CCMP
    PN corruption and a waste of CPU time since mac80211 tries to decrypt an already
    deciphered frame with ieee80211_aes_ccm_decrypt.
    Fix the issue initializing decrypt_error flag at the begging of the
    ath_rx_tasklet() loop.
    
    Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    LorenzoBianconi committed with gregkh Aug 10, 2012
  24. @gregkh

    ACPI: export symbol acpi_get_table_with_size

    commit 4f81f98 upstream.
    
    We need it in the radeon drm module to fetch
    and verify the vbios image on UEFI systems.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Alex Deucher committed with gregkh Aug 20, 2012
  25. @smcameron @gregkh

    cciss: fix incorrect scsi status reporting

    commit b0cf0b1 upstream.
    
    Delete code which sets SCSI status incorrectly as it's already been set
    correctly above this incorrect code.  The bug was introduced in 2009 by
    commit b0e15f6 ("cciss: fix typo that causes scsi status to be
    lost.")
    
    Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
    Reported-by: Roel van Meer <roel.vanmeer@bokxing.nl>
    Tested-by: Roel van Meer <roel.vanmeer@bokxing.nl>
    Cc: Jens Axboe <axboe@kernel.dk>
    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>
    smcameron committed with gregkh Aug 21, 2012
  26. @gregkh

    svcrpc: sends on closed socket should stop immediately

    commit f06f00a upstream.
    
    svc_tcp_sendto sets XPT_CLOSE if we fail to transmit the entire reply.
    However, the XPT_CLOSE won't be acted on immediately.  Meanwhile other
    threads could send further replies before the socket is really shut
    down.  This can manifest as data corruption: for example, if a truncated
    read reply is followed by another rpc reply, that second reply will look
    to the client like further read data.
    
    Symptoms were data corruption preceded by svc_tcp_sendto logging
    something like
    
    	kernel: rpc-srv/tcp: nfsd: sent only 963696 when sending 1048708 bytes - shutting down socket
    
    Reported-by: Malahal Naineni <malahal@us.ibm.com>
    Tested-by: Malahal Naineni <malahal@us.ibm.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    J. Bruce Fields committed with gregkh Aug 20, 2012
  27. @gregkh

    svcrpc: fix svc_xprt_enqueue/svc_recv busy-looping

    commit d10f27a upstream.
    
    The rpc server tries to ensure that there will be room to send a reply
    before it receives a request.
    
    It does this by tracking, in xpt_reserved, an upper bound on the total
    size of the replies that is has already committed to for the socket.
    
    Currently it is adding in the estimate for a new reply *before* it
    checks whether there is space available.  If it finds that there is not
    space, it then subtracts the estimate back out.
    
    This may lead the subsequent svc_xprt_enqueue to decide that there is
    space after all.
    
    The results is a svc_recv() that will repeatedly return -EAGAIN, causing
    server threads to loop without doing any actual work.
    
    Reported-by: Michael Tokarev <mjt@tls.msk.ru>
    Tested-by: Michael Tokarev <mjt@tls.msk.ru>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    J. Bruce Fields committed with gregkh Aug 17, 2012
  28. @gregkh

    svcrpc: fix BUG() in svc_tcp_clear_pages

    commit be1e444 upstream.
    
    Examination of svc_tcp_clear_pages shows that it assumes sk_tcplen is
    consistent with sk_pages[] (in particular, sk_pages[n] can't be NULL if
    sk_tcplen would lead us to expect n pages of data).
    
    svc_tcp_restore_pages zeroes out sk_pages[] while leaving sk_tcplen.
    This is OK, since both functions are serialized by XPT_BUSY.  However,
    that means the inconsistency must be repaired before dropping XPT_BUSY.
    
    Therefore we should be ensuring that svc_tcp_save_pages repairs the
    problem before exiting svc_tcp_recv_record on error.
    
    Symptoms were a BUG() in svc_tcp_clear_pages.
    
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    J. Bruce Fields committed with gregkh Aug 9, 2012
  29. @gregkh

    audit: fix refcounting in audit-tree

    commit a2140fc upstream.
    
    Refcounting of fsnotify_mark in audit tree is broken.  E.g:
    
                                  refcount
    create_chunk
      alloc_chunk                 1
      fsnotify_add_mark           2
    
    untag_chunk
      fsnotify_get_mark           3
      fsnotify_destroy_mark
        audit_tree_freeing_mark   2
      fsnotify_put_mark           1
      fsnotify_put_mark           0
      via destroy_list
        fsnotify_mark_destroy    -1
    
    This was reported by various people as triggering Oops when stopping auditd.
    
    We could just remove the put_mark from audit_tree_freeing_mark() but that would
    break freeing via inode destruction.  So this patch simply omits a put_mark
    after calling destroy_mark or adds a get_mark before.
    
    The additional get_mark is necessary where there's no other put_mark after
    fsnotify_destroy_mark() since it assumes that the caller is holding a reference
    (or the inode is keeping the mark pinned, not the case here AFAICS).
    
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Reported-by: Valentin Avram <aval13@gmail.com>
    Reported-by: Peter Moody <pmoody@google.com>
    Acked-by: Eric Paris <eparis@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Miklos Szeredi committed with gregkh Aug 15, 2012
  30. @gregkh

    audit: don't free_chunk() after fsnotify_add_mark()

    commit 0fe33aa upstream.
    
    Don't do free_chunk() after fsnotify_add_mark().  That one does a delayed unref
    via the destroy list and this results in use-after-free.
    
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Acked-by: Eric Paris <eparis@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Miklos Szeredi committed with gregkh Aug 15, 2012
  31. @gregkh

    NFS: Alias the nfs module to nfs4

    commit 425e776 upstream.
    
    This allows distros to remove the line from their modprobe
    configuration.
    
    Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    bjschuma@gmail.com committed with gregkh Aug 8, 2012
  32. @gregkh

    NFSv4.1: Remove a bogus BUG_ON() in nfs4_layoutreturn_done

    commit 47fbf79 upstream.
    
    Ever since commit 0a57cda (NFSv4.1 send layoutreturn to fence
    disconnected data server) we've been sending layoutreturn calls
    while there is potentially still outstanding I/O to the data
    servers. The reason we do this is to avoid races between replayed
    writes to the MDS and the original writes to the DS.
    
    When this happens, the BUG_ON() in nfs4_layoutreturn_done can
    be triggered because it assumes that we would never call
    layoutreturn without knowing that all I/O to the DS is
    finished. The fix is to remove the BUG_ON() now that the
    assumptions behind the test are obsolete.
    
    Reported-by: Boaz Harrosh <bharrosh@panasas.com>
    Reported-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Trond Myklebust committed with gregkh Aug 8, 2012
  33. @gregkh

    NFSv3: Ensure that do_proc_get_root() reports errors correctly

    commit 0866004 upstream.
    
    If the rpc call to NFS3PROC_FSINFO fails, then we need to report that
    error so that the mount fails. Otherwise we can end up with a
    superblock with completely unusable values for block sizes, maxfilesize,
    etc.
    
    Reported-by: Yuanming Chen <hikvision_linux@163.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Trond Myklebust committed with gregkh Aug 20, 2012
  34. @gregkh

    mm: hugetlbfs: correctly populate shared pmd

    commit eb48c07 upstream.
    
    Each page mapped in a process's address space must be correctly
    accounted for in _mapcount.  Normally the rules for this are
    straightforward but hugetlbfs page table sharing is different.  The page
    table pages at the PMD level are reference counted while the mapcount
    remains the same.
    
    If this accounting is wrong, it causes bugs like this one reported by
    Larry Woodman:
    
      kernel BUG at mm/filemap.c:135!
      invalid opcode: 0000 [#1] SMP
      CPU 22
      Modules linked in: bridge stp llc sunrpc binfmt_misc dcdbas microcode pcspkr acpi_pad acpi]
      Pid: 18001, comm: mpitest Tainted: G        W    3.3.0+ #4 Dell Inc. PowerEdge R620/07NDJ2
      RIP: 0010:[<ffffffff8112cfed>]  [<ffffffff8112cfed>] __delete_from_page_cache+0x15d/0x170
      Process mpitest (pid: 18001, threadinfo ffff880428972000, task ffff880428b5cc20)
      Call Trace:
        delete_from_page_cache+0x40/0x80
        truncate_hugepages+0x115/0x1f0
        hugetlbfs_evict_inode+0x18/0x30
        evict+0x9f/0x1b0
        iput_final+0xe3/0x1e0
        iput+0x3e/0x50
        d_kill+0xf8/0x110
        dput+0xe2/0x1b0
        __fput+0x162/0x240
    
    During fork(), copy_hugetlb_page_range() detects if huge_pte_alloc()
    shared page tables with the check dst_pte == src_pte.  The logic is if
    the PMD page is the same, they must be shared.  This assumes that the
    sharing is between the parent and child.  However, if the sharing is
    with a different process entirely then this check fails as in this
    diagram:
    
      parent
        |
        ------------>pmd
                     src_pte----------> data page
                                            ^
      other--------->pmd--------------------|
                      ^
      child-----------|
                     dst_pte
    
    For this situation to occur, it must be possible for Parent and Other to
    have faulted and failed to share page tables with each other.  This is
    possible due to the following style of race.
    
      PROC A                                          PROC B
      copy_hugetlb_page_range                         copy_hugetlb_page_range
        src_pte == huge_pte_offset                      src_pte == huge_pte_offset
        !src_pte so no sharing                          !src_pte so no sharing
    
      (time passes)
    
      hugetlb_fault                                   hugetlb_fault
        huge_pte_alloc                                  huge_pte_alloc
          huge_pmd_share                                 huge_pmd_share
            LOCK(i_mmap_mutex)
            find nothing, no sharing
            UNLOCK(i_mmap_mutex)
                                                          LOCK(i_mmap_mutex)
                                                          find nothing, no sharing
                                                          UNLOCK(i_mmap_mutex)
          pmd_alloc                                       pmd_alloc
          LOCK(instantiation_mutex)
          fault
          UNLOCK(instantiation_mutex)
                                                      LOCK(instantiation_mutex)
                                                      fault
                                                      UNLOCK(instantiation_mutex)
    
    These two processes are not poing to the same data page but are not
    sharing page tables because the opportunity was missed.  When either
    process later forks, the src_pte == dst pte is potentially insufficient.
    As the check falls through, the wrong PTE information is copied in
    (harmless but wrong) and the mapcount is bumped for a page mapped by a
    shared page table leading to the BUG_ON.
    
    This patch addresses the issue by moving pmd_alloc into huge_pmd_share
    which guarantees that the shared pud is populated in the same critical
    section as pmd.  This also means that huge_pte_offset test in
    huge_pmd_share is serialized correctly now which in turn means that the
    success of the sharing will be higher as the racing tasks see the pud
    and pmd populated together.
    
    Race identified and changelog written mostly by Mel Gorman.
    
    {akpm@linux-foundation.org: attempt to make the huge_pmd_share() comment comprehensible, clean up coding style]
    Reported-by: Larry Woodman <lwoodman@redhat.com>
    Tested-by: Larry Woodman <lwoodman@redhat.com>
    Reviewed-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: David Gibson <david@gibson.dropbear.id.au>
    Cc: Ken Chen <kenchen@google.com>
    Cc: Cong Wang <xiyou.wangcong@gmail.com>
    Cc: Hillf Danton <dhillf@gmail.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>
    Michal Hocko committed with gregkh Aug 21, 2012
  35. @gregkh

    USB: winbond: remove __devinit* from the struct usb_device_id table

    commit 43a3469 upstream.
    
    This structure needs to always stick around, even if CONFIG_HOTPLUG
    is disabled, otherwise we can oops when trying to probe a device that
    was added after the structure is thrown away.
    
    Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Reported-by: Bjørn Mork <bjorn@mork.no>
    CC: Pavel Machek <pavel@ucw.cz>
    CC: Paul Gortmaker <paul.gortmaker@windriver.com>
    CC: "John W. Linville" <linville@tuxdriver.com>
    CC: Eliad Peller <eliad@wizery.com>
    CC: Devendra Naga <devendra.aaru@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    gregkh committed Aug 17, 2012
Something went wrong with that request. Please try again.