Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Aug 29, 2011
  1. @gregkh

    Linux 3.0.4

    gregkh authored
  2. @gregkh

    Add a personality to report 2.6.x version numbers

    Andi Kleen authored gregkh committed
    commit be27425 upstream.
    
    I ran into a couple of programs which broke with the new Linux 3.0
    version.  Some of those were binary only.  I tried to use LD_PRELOAD to
    work around it, but it was quite difficult and in one case impossible
    because of a mix of 32bit and 64bit executables.
    
    For example, all kind of management software from HP doesnt work, unless
    we pretend to run a 2.6 kernel.
    
      $ uname -a
      Linux svivoipvnx001 3.0.0-08107-g97cd98f #1062 SMP Fri Aug 12 18:11:45 CEST 2011 i686 i686 i386 GNU/Linux
    
      $ hpacucli ctrl all show
    
      Error: No controllers detected.
    
      $ rpm -qf /usr/sbin/hpacucli
      hpacucli-8.75-12.0
    
    Another notable case is that Python now reports "linux3" from
    sys.platform(); which in turn can break things that were checking
    sys.platform() == "linux2":
    
      https://bugzilla.mozilla.org/show_bug.cgi?id=664564
    
    It seems pretty clear to me though it's a bug in the apps that are using
    '==' instead of .startswith(), but this allows us to unbreak broken
    programs.
    
    This patch adds a UNAME26 personality that makes the kernel report a
    2.6.40+x version number instead.  The x is the x in 3.x.
    
    I know this is somewhat ugly, but I didn't find a better workaround, and
    compatibility to existing programs is important.
    
    Some programs also read /proc/sys/kernel/osrelease.  This can be worked
    around in user space with mount --bind (and a mount namespace)
    
    To use:
    
      wget ftp://ftp.kernel.org/pub/linux/kernel/people/ak/uname26/uname26.c
      gcc -o uname26 uname26.c
      ./uname26 program
    
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @gregkh

    igb: Fix lack of flush after register write and before delay

    Carolyn Wyborny authored gregkh committed
    commit 064b433 upstream.
    
    Register writes followed by a delay are required to have a flush
    before the delay in order to commit the values to the register.  Without
    the flush, the code following the delay may not function correctly.
    
    Reported-by: Tong Ho <tong.ho@ericsson.com>
    Reported-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
    Tested-by:  Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @gregkh

    mmc: sdhci: fix retuning timer wrongly deleted in sdhci_tasklet_finish

    Aaron Lu authored gregkh committed
    commit 7886961 upstream.
    
    Currently, the retuning timer for retuning mode 1 will be deleted in
    function sdhci_tasklet_finish after a mmc request done, which will make
    retuning timing never trigger again. This patch fixed this problem.
    
    Signed-off-by: Aaron Lu <Aaron.Lu@amd.com>
    Reviewed-by: Philip Rakity <prakity@marvell.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @sgruszka @gregkh

    rt2x00: fix order of entry flags modification

    sgruszka authored gregkh committed
    commit df71c9c upstream.
    
    In rt2800usb_work_txdone we check flags in order:
    
    - ENTRY_OWNER_DEVICE_DATA
    - ENTRY_DATA_STATUS_PENDING
    - ENTRY_DATA_IO_FAILED
    
    Modify flags in separate order in rt2x00usb_interrupt_txdone, to avoid
    processing entries in _txdone with wrong flags or skip processing
    ready entries.
    
    Reported-by: Justin Piszcz <jpiszcz@lucidpixels.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @gregkh

    fuse: check size of FUSE_NOTIFY_INVAL_ENTRY message

    Miklos Szeredi authored gregkh committed
    commit c2183d1 upstream.
    
    FUSE_NOTIFY_INVAL_ENTRY didn't check the length of the write so the
    message processing could overrun and result in a "kernel BUG at
    fs/fuse/dev.c:629!"
    
    Reported-by: Han-Wen Nienhuys <hanwenn@gmail.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @gregkh

    drm/radeon: Extended DDC Probing for Toshiba L300D Radeon Mobility X1…

    Thomas Reim authored gregkh committed
    …100 HDMI-A Connector
    
    commit f2b6071 upstream.
    
    Toshiba Satellite L300D with ATI Mobility Radeon X1100 sends data
       to i2c bus for a HDMI connector that is not implemented/existent
       on the notebook's board.
    
       Fix by applying extented DDC probing for this connector.
    
       Requires [PATCH] drm/radeon: Extended DDC Probing for Connectors
       with Improperly Wired DDC Lines
    
       Tested for kernel 2.6.38 on Toshiba Satellite L300D notebook
    
       BugLink: http://bugs.launchpad.net/bugs/826677
    
    Signed-off-by: Thomas Reim <reimth@gmail.com>
    Acked-by: Chris Routh <routhy@gmail.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @mslusarz @gregkh

    drm/ttm: fix ttm_bo_add_ttm(user) failure path

    mslusarz authored gregkh committed
    commit 7c4c396 upstream.
    
    ttm_tt_destroy kfrees passed object, so we need to nullify
    a reference to it.
    
    Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @gregkh

    x86, UV: Remove UV delay in starting slave cpus

    Jack Steiner authored gregkh committed
    commit 05e33fc upstream.
    
    Delete the 10 msec delay between the INIT and SIPI when starting
    slave cpus. I can find no requirement for this delay. BIOS also
    has similar code sequences without the delay.
    
    Removing the delay reduces boot time by 40 sec. Every bit helps.
    
    Signed-off-by: Jack Steiner <steiner@sgi.com>
    Link: http://lkml.kernel.org/r/20110805140900.GA6774@sgi.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @gregkh

    x86-32, vdso: On system call restart after SYSENTER, use int $0x80

    H. Peter Anvin authored gregkh committed
    commit 7ca0758 upstream.
    
    When we enter a 32-bit system call via SYSENTER or SYSCALL, we shuffle
    the arguments to match the int $0x80 calling convention.  This was
    probably a design mistake, but it's what it is now.  This causes
    errors if the system call as to be restarted.
    
    For SYSENTER, we have to invoke the instruction from the vdso as the
    return address is hardcoded.  Accordingly, we can simply replace the
    jump in the vdso with an int $0x80 instruction and use the slower
    entry point for a post-restart.
    
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Link: http://lkml.kernel.org/r/CA%2B55aFztZ=r5wa0x26KJQxvZOaQq8s2v3u50wCyJcA-Sc4g8gQ@mail.gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @gregkh

    x86, olpc: Wait for last byte of EC command to be accepted

    Paul Fox authored gregkh committed
    commit a3ea14d upstream.
    
    When executing EC commands, only waiting when there are still
    more bytes to write is usually fine. However, if the system
    suspends very quickly after a call to olpc_ec_cmd(), the last
    data byte may not yet be transferred to the EC, and the command
    will not complete.
    
    This solves a bug where the SCI wakeup mask was not correctly
    written when going into suspend.
    
    It means that sometimes, on XO-1.5 (but not XO-1), the
    devices that were marked as wakeup sources can't wake up
    the system. e.g. you ask for wifi wakeups, suspend, but then
    incoming wifi frames don't wake up the system as they should.
    
    Signed-off-by: Paul Fox <pgf@laptop.org>
    Signed-off-by: Daniel Drake <dsd@laptop.org>
    Acked-by: Andres Salomon <dilinger@queued.net>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @sstabellini @gregkh

    xen: Do not enable PV IPIs when vector callback not present

    sstabellini authored gregkh committed
    commit 3c05c4b upstream.
    
    Fix regression for HVM case on older (<4.1.1) hypervisors caused by
    
      commit 99bbb3a
      Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
      Date:   Thu Dec 2 17:55:10 2010 +0000
    
        xen: PV on HVM: support PV spinlocks and IPIs
    
    This change replaced the SMP operations with event based handlers without
    taking into account that this only works when the hypervisor supports
    callback vectors. This causes unexplainable hangs early on boot for
    HVM guests with more than one CPU.
    
    BugLink: http://bugs.launchpad.net/bugs/791850
    
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Tested-and-Reported-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @gregkh

    xen/x86: replace order-based range checking of M2P table by linear one

    Jan Beulich authored gregkh committed
    commit ccbcdf7 upstream.
    
    The order-based approach is not only less efficient (requiring a shift
    and a compare, typical generated code looking like this
    
    	mov	eax, [machine_to_phys_order]
    	mov	ecx, eax
    	shr	ebx, cl
    	test	ebx, ebx
    	jnz	...
    
    whereas a direct check requires just a compare, like in
    
    	cmp	ebx, [machine_to_phys_nr]
    	jae	...
    
    ), but also slightly dangerous in the 32-on-64 case - the element
    address calculation can wrap if the next power of two boundary is
    sufficiently far away from the actual upper limit of the table, and
    hence can result in user space addresses being accessed (with it being
    unknown what may actually be mapped there).
    
    Additionally, the elimination of the mistaken use of fls() here (should
    have been __fls()) fixes a latent issue on x86-64 that would trigger
    if the code was run on a system with memory extending beyond the 44-bit
    boundary.
    
    Signed-off-by: Jan Beulich <jbeulich@novell.com>
    [v1: Based on Jeremy's feedback]
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @gregkh

    xen-blkfront: Fix one off warning about name clash

    Stefan Bader authored gregkh committed
    commit 89153b5 upstream.
    
    Avoid telling users to use xvde and onwards when using xvde.
    
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @gregkh

    xen-blkfront: Drop name and minor adjustments for emulated scsi devices

    Stefan Bader authored gregkh committed
    commit 196cfe2 upstream.
    
    These were intended to avoid the namespace clash when representing
    emulated IDE and SCSI devices. However that seems to confuse users
    more than expected (a disk defined as sda becomes xvde).
    So for now go back to the scheme which does no adjustments. This
    will break when mixing IDE and SCSI names in the configuration of
    guests but should be by now expected.
    
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @tytso @gregkh

    ext4: fix nomblk_io_submit option so it correctly converts uninit blocks

    tytso authored gregkh committed
    commit 9dd75f1 upstream.
    
    Bug discovered by Jan Kara:
    
    Finally, commit 1449032 returned back
    the old IO submission code but apparently it forgot to return the old
    handling of uninitialized buffers so we unconditionnaly call
    block_write_full_page() without specifying end_io function. So AFAICS
    we never convert unwritten extents to written in some cases. For
    example when I mount the fs as: mount -t ext4 -o
    nomblk_io_submit,dioread_nolock /dev/ubdb /mnt and do
            int fd = open(argv[1], O_RDWR | O_CREAT | O_TRUNC, 0600);
            char buf[1024];
            memset(buf, 'a', sizeof(buf));
            fallocate(fd, 0, 0, 16384);
            write(fd, buf, sizeof(buf));
    
    I get a file full of zeros (after remounting the filesystem so that
    pagecache is dropped) instead of seeing the first KB contain 'a's.
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @taoma-tm @gregkh

    ext4: Resolve the hang of direct i/o read in handling EXT4_IO_END_UNW…

    taoma-tm authored gregkh committed
    …RITTEN.
    
    commit 32c80b3 upstream.
    
    EXT4_IO_END_UNWRITTEN flag set and the increase of i_aiodio_unwritten
    should be done simultaneously since ext4_end_io_nolock always clear
    the flag and decrease the counter in the same time.
    
    We don't increase i_aiodio_unwritten when setting
    EXT4_IO_END_UNWRITTEN so it will go nagative and causes some process
    to wait forever.
    
    Part of the patch came from Eric in his e-mail, but it doesn't fix the
    problem met by Michael actually.
    
    http://marc.info/?l=linux-ext4&m=131316851417460&w=2
    
    Reported-and-Tested-by: Michael Tokarev<mjt@tls.msk.ru>
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Tao Ma <boyu.mt@taobao.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @gregkh

    ext4: call ext4_ioend_wait and ext4_flush_completed_IO in ext4_evict_…

    Jiaying Zhang authored gregkh committed
    …inode
    
    commit 2581fdc upstream.
    
    Flush inode's i_completed_io_list before calling ext4_io_wait to
    prevent the following deadlock scenario: A page fault happens while
    some process is writing inode A. During page fault,
    shrink_icache_memory is called that in turn evicts another inode
    B. Inode B has some pending io_end work so it calls ext4_ioend_wait()
    that waits for inode B's i_ioend_count to become zero. However, inode
    B's ioend work was queued behind some of inode A's ioend work on the
    same cpu's ext4-dio-unwritten workqueue. As the ext4-dio-unwritten
    thread on that cpu is processing inode A's ioend work, it tries to
    grab inode A's i_mutex lock. Since the i_mutex lock of inode A is
    still hold before the page fault happened, we enter a deadlock.
    
    Also moves ext4_flush_completed_IO and ext4_ioend_wait from
    ext4_destroy_inode() to ext4_evict_inode(). During inode deleteion,
    ext4_evict_inode() is called before ext4_destroy_inode() and in
    ext4_evict_inode(), we may call ext4_truncate() without holding
    i_mutex lock. As a result, there is a race between flush_completed_IO
    that is called from ext4_ext_truncate() and ext4_end_io_work, which
    may cause corruption on an io_end structure. This change moves
    ext4_flush_completed_IO and ext4_ioend_wait from ext4_destroy_inode()
    to ext4_evict_inode() to resolve the race between ext4_truncate() and
    ext4_end_io_work during inode deletion.
    
    Signed-off-by: Jiaying Zhang <jiayingz@google.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @gregkh

    ext4: Fix ext4_should_writeback_data() for no-journal mode

    Curt Wohlgemuth authored gregkh committed
    commit 441c850 upstream.
    
    ext4_should_writeback_data() had an incorrect sequence of
    tests to determine if it should return 0 or 1: in
    particular, even in no-journal mode, 0 was being returned
    for a non-regular-file inode.
    
    This meant that, in non-journal mode, we would use
    ext4_journalled_aops for directories, symlinks, and other
    non-regular files.  However, calling journalled aop
    callbacks when there is no valid handle, can cause problems.
    
    This would cause a kernel crash with Jan Kara's commit
    2d859db ("ext4: fix data corruption in inodes with
    journalled data"), because we now dereference 'handle' in
    ext4_journalled_write_end().
    
    I also added BUG_ONs to check for a valid handle in the
    obviously journal-only aops callbacks.
    
    I tested this running xfstests with a scratch device in
    these modes:
    
       - no-journal
       - data=ordered
       - data=writeback
       - data=journal
    
    All work fine; the data=journal run has many failures and a
    crash in xfstests 074, but this is no different from a
    vanilla kernel.
    
    Signed-off-by: Curt Wohlgemuth <curtw@google.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. @crimsun @gregkh

    ALSA: ac97: Add HP Compaq dc5100 SFF(PT003AW) to Headphone Jack Sense…

    crimsun authored gregkh committed
    … whitelist
    
    commit eade7b2 upstream.
    
    BugLink: https://bugs.launchpad.net/bugs/826081
    
    The original reporter needs 'Headphone Jack Sense' enabled to have
    audible audio, so add his PCI SSID to the whitelist.
    
    Reported-and-tested-by: Muhammad Khurram Khan
    Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. @zonque @gregkh

    ALSA: snd_usb_caiaq: track submitted output urbs

    zonque authored gregkh committed
    commit da6094e upstream.
    
    The snd_usb_caiaq driver currently assumes that output urbs are serviced
    in time and doesn't track when and whether they are given back by the
    USB core. That usually works fine, but due to temporary limitations of
    the XHCI stack, we faced that urbs were submitted more than once with
    this approach.
    
    As it's no good practice to fire and forget urbs anyway, this patch
    introduces a proper bit mask to track which requests have been submitted
    and given back.
    
    That alone however doesn't make the driver work in case the host
    controller is broken and doesn't give back urbs at all, and the output
    stream will stop once all pre-allocated output urbs are consumed. But
    it does prevent crashes of the controller stack in such cases.
    
    See http://bugzilla.kernel.org/show_bug.cgi?id=40702 for more details.
    
    Signed-off-by: Daniel Mack <zonque@gmail.com>
    Reported-and-tested-by: Matej Laitl <matej@laitl.cz>
    Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. @tiwai @gregkh

    ALSA: usb-audio - Fix missing mixer dB information

    tiwai authored gregkh committed
    commit 38b6519 upstream.
    
    The recent fix for testing dB range at the mixer creation time seems
    to cause regressions in some devices.  In such devices, reading the dB
    info at probing time gives an error, thus both dBmin and dBmax are still
    zero, and TLV flag isn't set although the later read of dB info succeeds.
    
    This patch adds a workaround for such a case by assuming that the later
    read will succeed.  In future, a similar test should be performed in a
    case where a wrong dB range is seen even in the later read.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @liub @gregkh

    Btrfs: fix an oops of log replay

    liub authored gregkh committed
    commit 34f3e4f upstream.
    
    When btrfs recovers from a crash, it may hit the oops below:
    
    ------------[ cut here ]------------
    kernel BUG at fs/btrfs/inode.c:4580!
    [...]
    RIP: 0010:[<ffffffffa03df251>]  [<ffffffffa03df251>] btrfs_add_link+0x161/0x1c0 [btrfs]
    [...]
    Call Trace:
     [<ffffffffa03e7b31>] ? btrfs_inode_ref_index+0x31/0x80 [btrfs]
     [<ffffffffa04054e9>] add_inode_ref+0x319/0x3f0 [btrfs]
     [<ffffffffa0407087>] replay_one_buffer+0x2c7/0x390 [btrfs]
     [<ffffffffa040444a>] walk_down_log_tree+0x32a/0x480 [btrfs]
     [<ffffffffa0404695>] walk_log_tree+0xf5/0x240 [btrfs]
     [<ffffffffa0406cc0>] btrfs_recover_log_trees+0x250/0x350 [btrfs]
     [<ffffffffa0406dc0>] ? btrfs_recover_log_trees+0x350/0x350 [btrfs]
     [<ffffffffa03d18b2>] open_ctree+0x1442/0x17d0 [btrfs]
    [...]
    
    This comes from that while replaying an inode ref item, we forget to
    check those old conflicting DIR_ITEM and DIR_INDEX items in fs/file tree,
    then we will come to conflict corners which lead to BUG_ON().
    
    Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com>
    Tested-by: Andy Lutomirski <luto@mit.edu>
    Signed-off-by: Chris Mason <chris.mason@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. @kaysievers @gregkh

    loop: fix deadlock when sysfs and LOOP_CLR_FD race against each other

    kaysievers authored gregkh committed
    commit 05eb0f2 upstream.
    
    LOOP_CLR_FD takes lo->lo_ctl_mutex and tries to remove the loop sysfs
    files. Sysfs calls show() and waits for lo->lo_ctl_mutex. LOOP_CLR_FD
    waits for show() to finish to remove the sysfs file.
    
      cat /sys/class/block/loop0/loop/backing_file
        mutex_lock_nested+0x176/0x350
        ? loop_attr_do_show_backing_file+0x2f/0xd0 [loop]
        ? loop_attr_do_show_backing_file+0x2f/0xd0 [loop]
        loop_attr_do_show_backing_file+0x2f/0xd0 [loop]
        dev_attr_show+0x1b/0x60
        ? sysfs_read_file+0x86/0x1a0
        ? __get_free_pages+0x12/0x50
        sysfs_read_file+0xaf/0x1a0
    
      ioctl(LOOP_CLR_FD):
        wait_for_common+0x12c/0x180
        ? try_to_wake_up+0x2a0/0x2a0
        wait_for_completion+0x18/0x20
        sysfs_deactivate+0x178/0x180
        ? sysfs_addrm_finish+0x43/0x70
        ? sysfs_addrm_start+0x1d/0x20
        sysfs_addrm_finish+0x43/0x70
        sysfs_hash_and_remove+0x85/0xa0
        sysfs_remove_group+0x59/0x100
        loop_clr_fd+0x1dc/0x3f0 [loop]
        lo_ioctl+0x223/0x7a0 [loop]
    
    Instead of taking the lo_ctl_mutex from sysfs code, take the inner
    lo->lo_lock, to protect the access to the backing_file data.
    
    Thanks to Tejun for help debugging and finding a solution.
    
    Cc: Milan Broz <mbroz@redhat.com>
    Cc: Tejun Heo <tj@kernel.org>
    Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
    Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  25. @gregkh

    Btrfs: detect wether a device supports discard

    Josef Bacik authored gregkh committed
    commit d5e2003 upstream.
    
    We have a problem where if a user specifies discard but doesn't actually support
    it we will return EOPNOTSUPP from btrfs_discard_extent.  This is a problem
    because this gets called (in a fashion) from the tree log recovery code, which
    has a nice little BUG_ON(ret) after it, which causes us to fail the tree log
    replay.  So instead detect wether our devices support discard when we're adding
    them and then don't issue discards if we know that the device doesn't support
    it.  And just for good measure set ret = 0 in btrfs_issue_discard just in case
    we still get EOPNOTSUPP so we don't screw anybody up like this again.  Thanks,
    
    Signed-off-by: Josef Bacik <josef@redhat.com>
    Signed-off-by: Chris Mason <chris.mason@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. @gregkh

    x86, mtrr: lock stop machine during MTRR rendezvous sequence

    Suresh Siddha authored gregkh committed
    commit 6d3321e upstream.
    
    MTRR rendezvous sequence using stop_one_cpu_nowait() can potentially
    happen in parallel with another system wide rendezvous using
    stop_machine(). This can lead to deadlock (The order in which
    works are queued can be different on different cpu's. Some cpu's
    will be running the first rendezvous handler and others will be running
    the second rendezvous handler. Each set waiting for the other set to join
    for the system wide rendezvous, leading to a deadlock).
    
    MTRR rendezvous sequence is not implemented using stop_machine() as this
    gets called both from the process context aswell as the cpu online paths
    (where the cpu has not come online and the interrupts are disabled etc).
    stop_machine() works with only online cpus.
    
    For now, take the stop_machine mutex in the MTRR rendezvous sequence that
    gets called from an online cpu (here we are in the process context
    and can potentially sleep while taking the mutex). And the MTRR rendezvous
    that gets triggered during cpu online doesn't need to take this stop_machine
    lock (as the stop_machine() already ensures that there is no cpu hotplug
    going on in parallel by doing get_online_cpus())
    
        TBD: Pursue a cleaner solution of extending the stop_machine()
             infrastructure to handle the case where the calling cpu is
             still not online and use this for MTRR rendezvous sequence.
    
    fixes: https://bugzilla.novell.com/show_bug.cgi?id=672008
    
    Reported-by: Vadim Kotelnikov <vadimuzzz@inbox.ru>
    Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
    Link: http://lkml.kernel.org/r/20110623182056.807230326@sbsiddha-MOBL3.sc.intel.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. @gregkh

    NFSv4.1: Return NFS4ERR_BADSESSION to callbacks during session resets

    Trond Myklebust authored gregkh committed
    commit 910ac68 upstream.
    
    If the client is in the process of resetting the session when it receives
    a callback, then returning NFS4ERR_DELAY may cause a deadlock with the
    DESTROY_SESSION call.
    
    Basically, if the client returns NFS4ERR_DELAY in response to the
    CB_SEQUENCE call, then the server is entitled to believe that the
    client is busy because it is already processing that call. In that
    case, the server is perfectly entitled to respond with a
    NFS4ERR_BACK_CHAN_BUSY to any DESTROY_SESSION call.
    
    Fix this by having the client reply with a NFS4ERR_BADSESSION in
    response to the callback if it is resetting the session.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  28. @gregkh

    NFSv4.1: Fix the callback 'highest_used_slotid' behaviour

    Trond Myklebust authored gregkh committed
    commit 55a6739 upstream.
    
    Currently, there is no guarantee that we will call nfs4_cb_take_slot() even
    though nfs4_callback_compound() will consistently call
    nfs4_cb_free_slot() provided the cb_process_state has set the 'clp' field.
    The result is that we can trigger the BUG_ON() upon the next call to
    nfs4_cb_take_slot().
    
    This patch fixes the above problem by using the slot id that was taken in
    the CB_SEQUENCE operation as a flag for whether or not we need to call
    nfs4_cb_free_slot().
    It also fixes an atomicity problem: we need to set tbl->highest_used_slotid
    atomically with the check for NFS4_SESSION_DRAINING, otherwise we end up
    racing with the various tests in nfs4_begin_drain_session().
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  29. @bharrosh @gregkh

    pnfs-obj: Bug when we are running out of bio

    bharrosh authored gregkh committed
    commit 20618b2 upstream.
    
    When we have a situation that the number of pages we want
    to encode is bigger then the size of the bio. (Which can
    currently happen only when all IO is going to a single device
    .e.g group_width==1) then the IO is submitted short and we
    report back only the amount of bytes we actually wrote/read
    and all is fine. BUT ...
    
    There was a bug that the current length counter was advanced
    before the fail to add the extra page, and we come to a situation
    that the CDB length was one-page longer then the actual bio size,
    which is of course rejected by the osd-target.
    
    While here also fix the bio size calculation, in the case
    that we received more then one group of devices.
    
    Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  30. @bharrosh @gregkh

    pnfs-obj: Fix the comp_index != 0 case

    bharrosh authored gregkh committed
    commit 9af7db3 upstream.
    
    There were bugs in the case of partial layout where olo_comp_index
    is not zero. This used to work and was tested but one of the later
    cleanup SQUASHMEs broke it and was not tested since.
    
    Also add a dprint that specify those received layout parameters.
    Everything else was already printed.
    
    Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  31. @lenb @gregkh

    x86, intel, power: Correct the MSR_IA32_ENERGY_PERF_BIAS message

    lenb authored gregkh committed
    commit 17edf2d upstream.
    
    Fix the printk_once() so that it actually prints (didn't print before
    due to a stray comma.)
    
    [ hpa: changed to an incremental patch and adjusted the description
      accordingly. ]
    
    Signed-off-by: Len Brown <len.brown@intel.com>
    Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107151732480.18606@x980
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  32. @gregkh

    possible memory corruption on mount

    Steve French authored gregkh committed
    commit 13589c4 upstream.
    
    CIFS cleanup_volume_info_contents() looks like having a memory
    corruption problem.
    When UNCip is set to "&vol->UNC[2]" in cifs_parse_mount_options(), it
    should not be kfree()-ed in cleanup_volume_info_contents().
    
    Introduced in commit b946845
    
    Signed-off-by: J.R. Okajima <hooanon05@yahoo.co.jp>
    Reviewed-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  33. @minipli @gregkh

    i7core_edac: fixed typo in error count calculation

    minipli authored gregkh committed
    commit 8cf2d23 upstream.
    
    Based on a patch from the PaX Team, found during a clang analysis pass.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Cc: PaX Team <pageexec@freemail.hu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  34. @gregkh

    befs: Validate length of long symbolic links.

    Timo Warns authored gregkh committed
    commit 338d0f0 upstream.
    
    Signed-off-by: Timo Warns <warns@pre-sense.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  35. @gregkh

    cifs: demote cERROR in build_path_from_dentry to cFYI

    Jeff Layton authored gregkh committed
    commit fa71f44 upstream.
    
    Running the cthon tests on a recent kernel caused this message to pop
    occasionally:
    
        CIFS VFS: did not end path lookup where expected namelen is 0
    
    Some added debugging showed that namelen and dfsplen were both 0 when
    this occurred. That means that the read_seqretry returned true.
    
    Assuming that the comment inside the if statement is true, this should
    be harmless and just means that we raced with a rename. If that is the
    case, then there's no need for alarm and we can demote this to cFYI.
    
    While we're at it, print the dfsplen too so that we can see what
    happened here if the message pops during debugging.
    
    Cc: Al Viro <viro@ZenIV.linux.org.uk>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.