Permalink
Commits on Mar 3, 2013
  1. Linux 3.0.68

    gregkh committed Mar 3, 2013
  2. staging: comedi: check s->async for poll(), read() and write()

    commit cc400e1 upstream.
    
    Some low-level comedi drivers (incorrectly) point `dev->read_subdev` or
    `dev->write_subdev` to a subdevice that does not support asynchronous
    commands.  Comedi's poll(), read() and write() file operation handlers
    assume these subdevices do support asynchronous commands.  In
    particular, they assume `s->async` is valid (where `s` points to the
    read or write subdevice), which it won't be if it has been set
    incorrectly.  This can lead to a NULL pointer dereference.
    
    Check `s->async` is non-NULL in `comedi_poll()`, `comedi_read()` and
    `comedi_write()` to avoid the bug.
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    ian-abbott committed with gregkh Feb 27, 2013
  3. staging: comedi: ni_labpc: set up command4 register *after* command3

    Commit 22056e2 upstream.
    
    Tuomas <tvainikk _at_ gmail _dot_ com> reported problems getting
    meaningful output from a Lab-PC+ in differential mode for AI cmds, but
    AI insn reads gave correct readings.  He tracked it down to two
    problems, one of which is addressed by this patch.
    
    It seems that writing to the command3 register after writing to the
    command4 register in `labpc_ai_cmd()` messes up the differential
    reference bit setting in the command4 register.  Set up the command4
    register after the command3 register (as in `labpc_ai_rinsn()`) to avoid
    the problem.
    
    Thanks to Tuomas for suggesting the fix.
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    ian-abbott committed with gregkh Feb 27, 2013
  4. staging: comedi: ni_labpc: correct differential channel sequence for …

    …AI commands
    
    Commit 4c4bc25 upstream.
    
    Tuomas <tvainikk _at_ gmail _dot_ com> reported problems getting
    meaningful output from a Lab-PC+ in differential mode for AI cmds, but
    AI insn reads gave correct readings.  He tracked it down to two
    problems, one of which is addressed by this patch.
    
    It seems the setting of the channel bits for particular scanning modes
    was incorrect for differential mode.  (Only half the number of channels
    are available in differential mode; comedi refers to them as channels 0,
    1, 2 and 3, but the hardware documentation refers to them as channels 0,
    2, 4 and 6.)  In differential mode, the setting of the channel enable
    bits in the command1 register should depend on whether the scan enable
    bit is set.  Effectively, we need to double the comedi channel number
    when the scan enable bit is not set in differential mode.  The scan
    enable bit gets set when the AI scan mode is `MODE_MULT_CHAN_UP` or
    `MODE_MULT_CHAN_DOWN`, and gets cleared when the AI scan mode is
    `MODE_SINGLE_CHAN` or `MODE_SINGLE_CHAN_INTERVAL`.  The existing test
    for whether the comedi channel number needs to be doubled in
    differential mode is incorrect in `labpc_ai_cmd()`.  This patch corrects
    the test.
    
    Thanks to Tuomas for suggesting the fix.
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    ian-abbott committed with gregkh Feb 27, 2013
  5. s390/kvm: Fix store status for ACRS/FPRS fix

    In 3.0.67, commit 58c9ce6 (s390/kvm:
    Fix store status for ACRS/FPRS), upstream commit
    15bc8d8, added a call to
    save_access_regs to save ACRS. But we do not have ARCS in kvm_run in
    3.0 yet, so this results in:
    arch/s390/kvm/kvm-s390.c: In function 'kvm_s390_vcpu_store_status':
    arch/s390/kvm/kvm-s390.c:593: error: 'struct kvm_run' has no member named 's'
    
    Fix it by saving guest_acrs which is where ARCS are in 3.0.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Jiri Slaby committed with gregkh Mar 3, 2013
  6. dca: check against empty dca_domains list before unregister provider fix

    In 3.0.67, commit 7a9a20e (dca: check
    against empty dca_domains list before unregister provider), upstream
    commit c419fcf, added a fail path to
    unregister_dca_provider. It added there also a call to
    raw_spin_unlock_irqrestore. But in 3.0, the lock is not raw, so this
    results in:
    drivers/dca/dca-core.c: In function 'unregister_dca_provider':
    drivers/dca/dca-core.c:413: warning: passing argument 1 of '_raw_spin_unlock_irqrestore' from incompatible pointer type
    
    Fix it by calling spin_unlock_irqrestore properly.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Jiri Slaby committed with gregkh Mar 3, 2013
  7. cgroup: fix exit() vs rmdir() race

    commit 71b5707 upstream.
    
    In cgroup_exit() put_css_set_taskexit() is called without any lock,
    which might lead to accessing a freed cgroup:
    
    thread1                           thread2
    ---------------------------------------------
    exit()
      cgroup_exit()
        put_css_set_taskexit()
          atomic_dec(cgrp->count);
                                       rmdir();
          /* not safe !! */
          check_for_release(cgrp);
    
    rcu_read_lock() can be used to make sure the cgroup is alive.
    
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    lizf-os committed with gregkh Jan 24, 2013
  8. cpuset: fix cpuset_print_task_mems_allowed() vs rename() race

    commit 63f43f5 upstream.
    
    rename() will change dentry->d_name. The result of this race can
    be worse than seeing partially rewritten name, but we might access
    a stale pointer because rename() will re-allocate memory to hold
    a longer name.
    
    It's safe in the protection of dentry->d_lock.
    
    v2: check NULL dentry before acquiring dentry lock.
    
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    lizf-os committed with gregkh Jan 25, 2013
  9. x86/apic: Work around boot failure on HP ProLiant DL980 G7 Server sys…

    …tems
    
    commit cb214ed upstream.
    
    When a HP ProLiant DL980 G7 Server boots a regular kernel,
    there will be intermittent lost interrupts which could
    result in a hang or (in extreme cases) data loss.
    
    The reason is that this system only supports x2apic physical
    mode, while the kernel boots with a logical-cluster default
    setting.
    
    This bug can be worked around by specifying the "x2apic_phys" or
    "nox2apic" boot option, but we want to handle this system
    without requiring manual workarounds.
    
    The BIOS sets ACPI_FADT_APIC_PHYSICAL in FADT table.
    As all apicids are smaller than 255, BIOS need to pass the
    control to the OS with xapic mode, according to x2apic-spec,
    chapter 2.9.
    
    Current code handle x2apic when BIOS pass with xapic mode
    enabled:
    
    When user specifies x2apic_phys, or FADT indicates PHYSICAL:
    
    1. During madt oem check, apic driver is set with xapic logical
       or xapic phys driver at first.
    
    2. enable_IR_x2apic() will enable x2apic_mode.
    
    3. if user specifies x2apic_phys on the boot line, x2apic_phys_probe()
       will install the correct x2apic phys driver and use x2apic phys mode.
       Otherwise it will skip the driver will let x2apic_cluster_probe to
       take over to install x2apic cluster driver (wrong one) even though FADT
       indicates PHYSICAL, because x2apic_phys_probe does not check
       FADT PHYSICAL.
    
    Add checking x2apic_fadt_phys in x2apic_phys_probe() to fix the
    problem.
    
    Signed-off-by: Stoney Wang <song-bo.wang@hp.com>
    [ updated the changelog and simplified the code ]
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Zhang Lin-Bao <Linbao.zhang@hp.com>
    [ make a patch specially for 3.0.66]
    Link: http://lkml.kernel.org/r/1360263182-16226-1-git-send-email-yinghai@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stoney Wang committed with gregkh Feb 7, 2013
  10. x86: Do not leak kernel page mapping locations

    commit e575a86 upstream.
    
    Without this patch, it is trivial to determine kernel page
    mappings by examining the error code reported to dmesg[1].
    Instead, declare the entire kernel memory space as a violation
    of a present page.
    
    Additionally, since show_unhandled_signals is enabled by
    default, switch branch hinting to the more realistic
    expectation, and unobfuscate the setting of the PF_PROT bit to
    improve readability.
    
    [1] http://vulnfactory.org/blog/2013/02/06/a-linux-memory-trick/
    
    Reported-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
    Suggested-by: Brad Spengler <spender@grsecurity.net>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/20130207174413.GA12485@www.outflux.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    kees committed with gregkh Feb 7, 2013
  11. unbreak automounter support on 64-bit kernel with 32-bit userspace (v2)

    commit 4f4ffc3 upstream.
    
    automount-support is broken on the parisc architecture, because the existing
    #if list does not include a check for defined(__hppa__). The HPPA (parisc)
    architecture is similiar to other 64bit Linux targets where we have to define
    autofs_wqt_t (which is passed back and forth to user space) as int type which
    has a size of 32bit across 32 and 64bit kernels.
    
    During the discussion on the mailing list, H. Peter Anvin suggested to invert
    the #if list since only specific platforms (specifically those who do not have
    a 32bit userspace, like IA64 and Alpha) should have autofs_wqt_t as unsigned
    long type.
    
    This suggestion is probably the best way to go, since Arm64 (and maybe others?)
    seems to have a non-working automounter. So in the long run even for other new
    upcoming architectures this inverted check seem to be the best solution, since
    it will not require them to change this #if again (unless they are 64bit only).
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Acked-by: Ian Kent <raven@themaw.net>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    CC: James Bottomley <James.Bottomley@HansenPartnership.com>
    CC: Rolf Eike Beer <eike-kernel@sf-tec.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Helge Deller committed with gregkh Feb 4, 2013
  12. wake_up_process() should be never used to wakeup a TASK_STOPPED/TRACE…

    …D task
    
    Upstream commit 9067ac8.
    
    wake_up_process() should never wakeup a TASK_STOPPED/TRACED task.
    Change it to use TASK_NORMAL and add the WARN_ON().
    
    TASK_ALL has no other users, probably can be killed.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    utrace committed with gregkh Feb 19, 2013
  13. ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL

    Upstream commit 9899d11.
    
    putreg() assumes that the tracee is not running and pt_regs_access() can
    safely play with its stack.  However a killed tracee can return from
    ptrace_stop() to the low-level asm code and do RESTORE_REST, this means
    that debugger can actually read/modify the kernel stack until the tracee
    does SAVE_REST again.
    
    set_task_blockstep() can race with SIGKILL too and in some sense this
    race is even worse, the very fact the tracee can be woken up breaks the
    logic.
    
    As Linus suggested we can clear TASK_WAKEKILL around the arch_ptrace()
    call, this ensures that nobody can ever wakeup the tracee while the
    debugger looks at it.  Not only this fixes the mentioned problems, we
    can do some cleanups/simplifications in arch_ptrace() paths.
    
    Probably ptrace_unfreeze_traced() needs more callers, for example it
    makes sense to make the tracee killable for oom-killer before
    access_process_vm().
    
    While at it, add the comment into may_ptrace_stop() to explain why
    ptrace_stop() still can't rely on SIGKILL and signal_pending_state().
    
    Reported-by: Salman Qazi <sqazi@google.com>
    Reported-by: Suleiman Souhlal <suleiman@google.com>
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    utrace committed with gregkh Feb 19, 2013
  14. ptrace: introduce signal_wake_up_state() and ptrace_signal_wake_up()

    Upstream commit 910ffdb.
    
    Cleanup and preparation for the next change.
    
    signal_wake_up(resume => true) is overused. None of ptrace/jctl callers
    actually want to wakeup a TASK_WAKEKILL task, but they can't specify the
    necessary mask.
    
    Turn signal_wake_up() into signal_wake_up_state(state), reintroduce
    signal_wake_up() as a trivial helper, and add ptrace_signal_wake_up()
    which adds __TASK_TRACED.
    
    This way ptrace_signal_wake_up() can work "inside" ptrace_request()
    even if the tracee doesn't have the TASK_WAKEKILL bit set.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    utrace committed with gregkh Feb 19, 2013
  15. vhost: fix length for cross region descriptor

    commit bd97120 upstream.
    
    If a single descriptor crosses a region, the
    second chunk length should be decremented
    by size translated so far, instead it includes
    the full descriptor length.
    
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    mstsirkin committed with gregkh Nov 26, 2012
  16. svcrpc: make svc_age_temp_xprts enqueue under sv_lock

    commit e75bafb upstream.
    
    svc_age_temp_xprts expires xprts in a two-step process: first it takes
    the sv_lock and moves the xprts to expire off their server-wide list
    (sv_tempsocks or sv_permsocks) to a local list.  Then it drops the
    sv_lock and enqueues and puts each one.
    
    I see no reason for this: svc_xprt_enqueue() will take sp_lock, but the
    sv_lock and sp_lock are not otherwise nested anywhere (and documentation
    at the top of this file claims it's correct to nest these with sp_lock
    inside.)
    
    Tested-by: Jason Tibbitts <tibbs@math.uh.edu>
    Tested-by: Paweł Sikora <pawel.sikora@agmk.net>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    J. Bruce Fields committed with gregkh Feb 10, 2013
  17. ext4: fix race in ext4_mb_add_n_trim()

    commit f116700 upstream.
    
    In ext4_mb_add_n_trim(), lg_prealloc_lock should be taken when
    changing the lg_prealloc_list.
    
    Signed-off-by: Niu Yawei <yawei.niu@intel.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    NiuYawei committed with gregkh Feb 2, 2013
  18. media: rc: unlock on error in show_protocols()

    commit 30ebc5e upstream.
    
    We recently introduced a new return -ENODEV in this function but we need
    to unlock before returning.
    
    [mchehab@redhat.com: found two patches with the same fix. Merged SOB's/acks into one patch]
    Acked-by: Herton R. Krzesinski <herton.krzesinski@canonical.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Douglas Bagnall <douglas@paradise.net.nz>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Dan Carpenter committed with gregkh Nov 27, 2012
  19. sysctl: fix null checking in bin_dn_node_address()

    commit df1778b upstream.
    
    The null check of `strchr() + 1' is broken, which is always non-null,
    leading to OOB read.  Instead, check the result of strchr().
    
    Signed-off-by: Xi Wang <xi.wang@gmail.com>
    Cc: "Eric W. Biederman" <ebiederm@xmission.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>
    xiw committed with gregkh Feb 28, 2013
  20. firewire: add minor number range check to fw_device_init()

    commit 3bec60d upstream.
    
    fw_device_init() didn't check whether the allocated minor number isn't
    too large.  Fail if it goes overflows MINORBITS.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Suggested-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.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@linuxfoundation.org>
    htejun committed with gregkh Feb 28, 2013
  21. idr: fix a subtle bug in idr_get_next()

    commit 6cdae74 upstream.
    
    The iteration logic of idr_get_next() is borrowed mostly verbatim from
    idr_for_each().  It walks down the tree looking for the slot matching
    the current ID.  If the matching slot is not found, the ID is
    incremented by the distance of single slot at the given level and
    repeats.
    
    The implementation assumes that during the whole iteration id is aligned
    to the layer boundaries of the level closest to the leaf, which is true
    for all iterations starting from zero or an existing element and thus is
    fine for idr_for_each().
    
    However, idr_get_next() may be given any point and if the starting id
    hits in the middle of a non-existent layer, increment to the next layer
    will end up skipping the same offset into it.  For example, an IDR with
    IDs filled between [64, 127] would look like the following.
    
              [  0  64 ... ]
           /----/   |
           |        |
          NULL    [ 64 ... 127 ]
    
    If idr_get_next() is called with 63 as the starting point, it will try
    to follow down the pointer from 0.  As it is NULL, it will then try to
    proceed to the next slot in the same level by adding the slot distance
    at that level which is 64 - making the next try 127.  It goes around the
    loop and finds and returns 127 skipping [64, 126].
    
    Note that this bug also triggers in idr_for_each_entry() loop which
    deletes during iteration as deletions can make layers go away leaving
    the iteration with unaligned ID into missing layers.
    
    Fix it by ensuring proceeding to the next slot doesn't carry over the
    unaligned offset - ie.  use round_up(id + 1, slot_distance) instead of
    id += slot_distance.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: David Teigland <teigland@redhat.com>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.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>
    htejun committed with gregkh Feb 28, 2013
  22. xen-blkback: do not leak mode property

    commit 9d09260 upstream.
    
    "be->mode" is obtained from xenbus_read(), which does a kmalloc() for
    the message body. The short string is never released, so do it along
    with freeing "be" itself, and make sure the string isn't kept when
    backend_changed() doesn't complete successfully (which made it
    desirable to slightly re-structure that function, so that the error
    cleanup can be done in one place).
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    jbeulich committed with gregkh Dec 20, 2012
  23. ocfs2: ac->ac_allow_chain_relink=0 won't disable group relink

    commit 309a85b upstream.
    
    ocfs2_block_group_alloc_discontig() disables chain relink by setting
    ac->ac_allow_chain_relink = 0 because it grabs clusters from multiple
    cluster groups.
    
    It doesn't keep the credits for all chain relink,but
    ocfs2_claim_suballoc_bits overrides this in this call trace:
    ocfs2_block_group_claim_bits()->ocfs2_claim_clusters()->
    __ocfs2_claim_clusters()->ocfs2_claim_suballoc_bits()
    ocfs2_claim_suballoc_bits set ac->ac_allow_chain_relink = 1; then call
    ocfs2_search_chain() one time and disable it again, and then we run out
    of credits.
    
    Fix is to allow relink by default and disable it in
    ocfs2_block_group_alloc_discontig.
    
    Without this patch, End-users will run into a crash due to run out of
    credits, backtrace like this:
    
      RIP: 0010:[<ffffffffa0808b14>]  [<ffffffffa0808b14>]
      jbd2_journal_dirty_metadata+0x164/0x170 [jbd2]
      RSP: 0018:ffff8801b919b5b8  EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff88022139ddc0 RCX: ffff880159f652d0
      RDX: ffff880178aa3000 RSI: ffff880159f652d0 RDI: ffff880087f09bf8
      RBP: ffff8801b919b5e8 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000001e00 R11: 00000000000150b0 R12: ffff880159f652d0
      R13: ffff8801a0cae908 R14: ffff880087f09bf8 R15: ffff88018d177800
      FS:  00007fc9b0b6b6e0(0000) GS:ffff88022fd40000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 000000000040819c CR3: 0000000184017000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process dd (pid: 9945, threadinfo ffff8801b919a000, task ffff880149a264c0)
      Call Trace:
        ocfs2_journal_dirty+0x2f/0x70 [ocfs2]
        ocfs2_relink_block_group+0x111/0x480 [ocfs2]
        ocfs2_search_chain+0x455/0x9a0 [ocfs2]
        ...
    
    Signed-off-by: Xiaowei.Hu <xiaowei.hu@oracle.com>
    Reviewed-by: Srinivas Eeda <srinivas.eeda@oracle.com>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Cc: Joel Becker <jlbec@evilplan.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@linuxfoundation.org>
    Xiaowei.Hu committed with gregkh Feb 28, 2013
  24. target: Add missing mapped_lun bounds checking during make_mappedlun …

    …setup
    
    commit fbbf855 upstream.
    
    This patch adds missing bounds checking for the configfs provided
    mapped_lun value during target_fabric_make_mappedlun() setup ahead
    of se_lun_acl initialization.
    
    This addresses a potential OOPs when using a mapped_lun value that
    exceeds the hardcoded TRANSPORT_MAX_LUNS_PER_TPG-1 value within
    se_node_acl->device_list[].
    
    Reported-by: Jan Engelhardt <jengelh@inai.de>
    Cc: Jan Engelhardt <jengelh@inai.de>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    nablio3000 committed with gregkh Feb 19, 2013
  25. x86: Make sure we can boot in the case the BDA contains pure garbage

    commit 7c10093 upstream.
    
    On non-BIOS platforms it is possible that the BIOS data area contains
    garbage instead of being zeroed or something equivalent (firmware
    people: we are talking of 1.5K here, so please do the sane thing.)
    
    We need on the order of 20-30K of low memory in order to boot, which
    may grow up to < 64K in the future.  We probably want to avoid the
    lowest of the low memory.  At the same time, it seems extremely
    unlikely that a legitimate EBDA would ever reach down to the 128K
    (which would require it to be over half a megabyte in size.)  Thus,
    pick 128K as the cutoff for "this is insane, ignore."  We may still
    end up reserving a bunch of extra memory on the low megabyte, but that
    is not really a major issue these days.  In the worst case we lose
    512K of RAM.
    
    This code really should be merged with trim_bios_range() in
    arch/x86/kernel/setup.c, but that is a bigger patch for a later merge
    window.
    
    Reported-by: Darren Hart <dvhart@linux.intel.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Matt Fleming <matt.fleming@intel.com>
    Link: http://lkml.kernel.org/n/tip-oebml055yyfm8yxmria09rja@git.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    H. Peter Anvin committed with gregkh Feb 27, 2013
  26. doc, kernel-parameters: Document 'console=hvc<n>'

    commit a2fd641 upstream.
    
    Both the PowerPC hypervisor and Xen hypervisor can utilize the
    hvc driver.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Link: http://lkml.kernel.org/r/1361825650-14031-3-git-send-email-konrad.wilk@oracle.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Konrad Rzeszutek Wilk committed with gregkh Feb 25, 2013
  27. doc, xen: Mention 'earlyprintk=xen' in the documentation.

    commit 2482a92 upstream.
    
    The earlyprintk for Xen PV guests utilizes a simple hypercall
    (console_io) to provide output to Xen emergency console.
    
    Note that the Xen hypervisor should be booted with 'loglevel=all'
    to output said information.
    
    Reported-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Link: http://lkml.kernel.org/r/1361825650-14031-2-git-send-email-konrad.wilk@oracle.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Konrad Rzeszutek Wilk committed with gregkh Feb 25, 2013
  28. ftrace: Call ftrace cleanup module notifier after all other notifiers

    commit 8c189ea upstream.
    
    Commit: c1bf08a "ftrace: Be first to run code modification on modules"
    
    changed ftrace module notifier's priority to INT_MAX in order to
    process the ftrace nops before anything else could touch them
    (namely kprobes). This was the correct thing to do.
    
    Unfortunately, the ftrace module notifier also contains the ftrace
    clean up code. As opposed to the set up code, this code should be
    run *after* all the module notifiers have run in case a module is doing
    correct clean-up and unregisters its ftrace hooks. Basically, ftrace
    needs to do clean up on module removal, as it needs to know about code
    being removed so that it doesn't try to modify that code. But after it
    removes the module from its records, if a ftrace user tries to remove
    a probe, that removal will fail due as the record of that code segment
    no longer exists.
    
    Nothing really bad happens if the probe removal is called after ftrace
    did the clean up, but the ftrace removal function will return an error.
    Correct code (such as kprobes) will produce a WARN_ON() if it fails
    to remove the probe. As people get annoyed by frivolous warnings, it's
    best to do the ftrace clean up after everything else.
    
    By splitting the ftrace_module_notifier into two notifiers, one that
    does the module load setup that is run at high priority, and the other
    that is called for module clean up that is run at low priority, the
    problem is solved.
    
    Reported-by: Frank Ch. Eigler <fche@redhat.com>
    Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    rostedt committed with gregkh Feb 13, 2013
  29. posix-timer: Don't call idr_find() with out-of-range ID

    commit e182bb3 upstream.
    
    When idr_find() was fed a negative ID, it used to look up the ID
    ignoring the sign bit before recent ("idr: remove MAX_IDR_MASK and
    move left MAX_IDR_* into idr.c") patch. Now a negative ID triggers
    a WARN_ON_ONCE().
    
    __lock_timer() feeds timer_id from userland directly to idr_find()
    without sanitizing it which can trigger the above malfunctions.  Add a
    range check on @timer_id before invoking idr_find() in __lock_timer().
    
    While timer_t is defined as int by all archs at the moment, Andrew
    worries that it may be defined as a larger type later on.  Make the
    test cover larger integers too so that it at least is guaranteed to
    not return the wrong timer.
    
    Note that WARN_ON_ONCE() in idr_find() on id < 0 is transitional
    precaution while moving away from ignoring MSB.  Once it's gone we can
    remove the guard as long as timer_t isn't larger than int.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/20130220232412.GL3570@htj.dyndns.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    htejun committed with gregkh Feb 20, 2013
  30. iommu/amd: Initialize device table after dma_ops

    commit f528d98 upstream.
    
    When dma_ops are initialized the unity mappings are
    created. The init_device_table_dma() function makes sure DMA
    from all devices is blocked by default. This opens a short
    window in time where DMA to unity mapped regions is blocked
    by the IOMMU. Make sure this does not happen by initializing
    the device table after dma_ops.
    
    Signed-off-by: Joerg Roedel <joro@8bytes.org>
    Signed-off-by: Shuah Khan <shuah.khan@hp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    joergroedel committed with gregkh Feb 6, 2013
  31. quota: autoload the quota_v2 module for QFMT_VFS_V1 quota format

    commit c3ad83d upstream.
    
    Otherwise, ext4 file systems with the quota featured enable will get a
    very confusing "No such process" error message if the quota code is
    built as a module and the quota_v2 module has not been loaded.
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
    Acked-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    tytso committed with gregkh Jan 25, 2013
Commits on Feb 28, 2013
  1. Linux 3.0.67

    gregkh committed Feb 28, 2013
  2. USB: usb-storage: unusual_devs update for Super TOP SATA bridge

    commit 18e0331 upstream.
    
    The current entry in unusual_cypress.h for the Super TOP SATA bridge devices
    seems to be causing corruption on newer revisions of this device.  This has
    been reported in Arch Linux and Fedora.  The original patch was tested on
    devices with bcdDevice of 1.60, whereas the newer devices report bcdDevice
    as 2.20.  Limit the UNUSUAL_DEV entry to devices less than 2.20.
    
    This fixes https://bugzilla.redhat.com/show_bug.cgi?id=909591
    
    The Arch Forum post on this is here:
    	https://bbs.archlinux.org/viewtopic.php?id=152011
    
    Reported-by: Carsten S. <carsteniq@yahoo.com>
    Tested-by: Carsten S. <carsteniq@yahoo.com>
    Signed-off-by: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Josh Boyer committed with gregkh Feb 14, 2013
  3. USB: storage: properly handle the endian issues of idProduct

    commit cd06095 upstream.
    
    1. The idProduct is little endian, so make sure its value to be
    compatible with the current CPU. Make no break on big endian processors.
    
    Signed-off-by: fangxiaozhi <huananhu@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    fangxiaozhi committed with gregkh Feb 7, 2013
  4. USB: ehci-omap: Fix autoloading of module

    commit 0475352 upstream.
    
    The module alias should be "ehci-omap" and not
    "omap-ehci" to match the platform device name.
    The omap-ehci module should now autoload correctly.
    
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    rogerq committed with gregkh Feb 14, 2013