1. 29 6月, 2013 1 次提交
    • A
      UBIFS: prepare to fix a horrid bug · 33f1a63a
      Artem Bityutskiy 提交于
      Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
      mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
      in the middle of 'ubifs_readdir()'.
      
      First of all, this means that 'file->private_data' can be freed while
      'ubifs_readdir()' uses it.  But this particular patch does not fix the problem.
      This patch is only a preparation, and the fix will follow next.
      
      In this patch we make 'ubifs_readdir()' stop using 'file->f_pos' directly,
      because 'file->f_pos' can be changed by '->llseek()' at any point. This may
      lead 'ubifs_readdir()' to returning inconsistent data: directory entry names
      may correspond to incorrect file positions.
      
      So here we introduce a local variable 'pos', read 'file->f_pose' once at very
      the beginning, and then stick to 'pos'. The result of this is that when
      'ubifs_dir_llseek()' changes 'file->f_pos' while we are in the middle of
      'ubifs_readdir()', the latter "wins".
      
      Cc: stable@vger.kernel.org
      Reported-by: NAl Viro <viro@zeniv.linux.org.uk>
      Tested-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      33f1a63a
  2. 22 6月, 2013 1 次提交
    • A
      aout32 coredump compat fix · 945fb136
      Al Viro 提交于
      dump_seek() does SEEK_CUR, not SEEK_SET; native binfmt_aout
      handles it correctly (seeks by PAGE_SIZE - sizeof(struct user),
      getting the current position to PAGE_SIZE), compat one seeks
      by PAGE_SIZE and ends up at PAGE_SIZE + already written...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      945fb136
  3. 20 6月, 2013 1 次提交
  4. 19 6月, 2013 1 次提交
  5. 17 6月, 2013 1 次提交
  6. 16 6月, 2013 3 次提交
    • L
      Linux 3.10-rc6 · 7d132055
      Linus Torvalds 提交于
      7d132055
    • L
      Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · e6694d98
      Linus Torvalds 提交于
      Pull ARM SoC fixes from Olof Johansson:
       "These are a little later than I planned on since I got caught up with
        handling merges for 3.11 most of the week.
      
        Another week, another batch of fixes for arm-soc platforms.
      
        Again, nothing controversial.  A few more than would be ideal, but all
        are valid fixes.  In particular the prima2 panic patch is critical
        since it fixes a problem where multiplatform kernels panic on all but
        prima2 hardware."
      
      * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        ARM: SAMSUNG: pm: Adjust for pinctrl- and DT-enabled platforms
        ARM: prima2: fix incorrect panic usage
        arm: mvebu: armada-xp-{gp,openblocks-ax3-4}: specify PCIe range
        ARM: Kirkwood: handle mv88f6282 cpu in __kirkwood_variant().
        ARM: omap3: clock: fix wrong container_of in clock36xx.c
        ARM: dts: OMAP5: Fix missing PWM capability to timer nodes
        ARM: dts: omap4-panda|sdp: Fix mux for twl6030 IRQ pin and msecure line
        ARM: dts: AM33xx: Fix properties on gpmc node
        arm: omap2: fix AM33xx hwmod infos for UART2
        ARM: OMAP3: Fix iva2_pwrdm settings for 3703
      e6694d98
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 596fa9e6
      Linus Torvalds 提交于
      Pull networking fixes from David Miller:
      
       1) Fix RTNL locking in batman-adv, from Matthias Schiffer.
      
       2) Don't allow non-passthrough macvlan devices to set NOPROMISC via
          netlink, otherwise we can end up with corrupted promisc counter
          values on the device.  From Michael S Tsirkin.
      
       3) Fix stmmac driver build with debugging defines enabled, from Dinh
          Nguyen.
      
       4) Make sure name string we give in socket address in AF_PACKET is NULL
          terminated, from Daniel Borkmann.
      
       5) Fix leaking of two uninitialized bytes of memory to userspace in
          l2tp, from Guillaume Nault.
      
       6) Clear IPCB(skb) before tunneling otherwise we touch dangling IP
          options state and crash.  From Saurabh Mohan.
      
       7) Fix suspend/resume for davinci_mdio by using suspend_late and
          resume_early.  From Mugunthan V N.
      
       8) Don't tag ip_tunnel_init_net and ip_tunnel_delete_net with
          __net_{init,exit}, they can be called outside of those contexts.
          From Eric Dumazet.
      
       9) Fix RX length error in sh_eth driver, from Yoshihiro Shimoda.
      
      10) Fix missing sctp_outq initialization in some code paths of SCTP
          stack, from Neil Horman.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (21 commits)
        sctp: fully initialize sctp_outq in sctp_outq_init
        netiucv: Hold rtnl between name allocation and device registration.
        tulip: Properly check dma mapping result
        net: sh_eth: fix incorrect RX length error if R8A7740
        ip_tunnel: remove __net_init/exit from exported functions
        drivers: net: davinci_mdio: restore mdio clk divider in mdio resume
        drivers: net: davinci_mdio: moving mdio resume earlier than cpsw ethernet driver
        net/ipv4: ip_vti clear skb cb before tunneling.
        tg3: Wait for boot code to finish after power on
        l2tp: Fix sendmsg() return value
        l2tp: Fix PPP header erasure and memory leak
        bonding: fix igmp_retrans type and two related races
        bonding: reset master mac on first enslave failure
        packet: packet_getname_spkt: make sure string is always 0-terminated
        net: ethernet: stmicro: stmmac: Fix compile error when STMMAC_XMIT_DEBUG used
        be2net: Fix 32-bit DMA Mask handling
        xen-netback: don't de-reference vif pointer after having called xenvif_put()
        macvlan: don't touch promisc without passthrough
        batman-adv: Don't handle address updates when bla is disabled
        batman-adv: forward late OGMs from best next hop
        ...
      596fa9e6
  7. 15 6月, 2013 17 次提交
    • L
      Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc · 5938930e
      Linus Torvalds 提交于
      Pull powerpc fixes from Benjamin Herrenschmidt:
       "So here are 3 fixes still for 3.10.  Fixes are simple, bugs are nasty
        (though not recent regressions, nasty enough) and all targeted at
        stable"
      
      * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
        powerpc: Fix missing/delayed calls to irq_work
        powerpc: Fix emulation of illegal instructions on PowerNV platform
        powerpc: Fix stack overflow crash in resume_kernel when ftracing
      5938930e
    • D
      smp.h: Use local_irq_{save,restore}() in !SMP version of on_each_cpu(). · f21afc25
      David Daney 提交于
      Thanks to commit f91eb62f ("init: scream bloody murder if interrupts
      are enabled too early"), "bloody murder" is now being screamed.
      
      With a MIPS OCTEON config, we use on_each_cpu() in our
      irq_chip.irq_bus_sync_unlock() function.  This gets called in early as a
      result of the time_init() call.  Because the !SMP version of
      on_each_cpu() unconditionally enables irqs, we get:
      
          WARNING: at init/main.c:560 start_kernel+0x250/0x410()
          Interrupts were enabled early
          CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0-rc5-Cavium-Octeon+ #801
          Call Trace:
            show_stack+0x68/0x80
            warn_slowpath_common+0x78/0xb0
            warn_slowpath_fmt+0x38/0x48
            start_kernel+0x250/0x410
      
      Suggested fix: Do what we already do in the SMP version of
      on_each_cpu(), and use local_irq_save/local_irq_restore.  Because we
      need a flags variable, make it a static inline to avoid name space
      issues.
      
      [ Change from v1: Convert on_each_cpu to a static inline function, add
        #include <linux/irqflags.h> to avoid build breakage on some files.
      
        on_each_cpu_mask() and on_each_cpu_cond() suffer the same problem as
        on_each_cpu(), but they are not causing !SMP bugs for me, so I will
        defer changing them to a less urgent patch. ]
      Signed-off-by: NDavid Daney <david.daney@cavium.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f21afc25
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · d0ff9348
      Linus Torvalds 提交于
      Pull VFS fixes from Al Viro:
       "Several fixes + obvious cleanup (you've missed a couple of open-coded
        can_lookup() back then)"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
        snd_pcm_link(): fix a leak...
        use can_lookup() instead of direct checks of ->i_op->lookup
        move exit_task_namespaces() outside of exit_notify()
        fput: task_work_add() can fail if the caller has passed exit_task_work()
        ncpfs: fix rmdir returns Device or resource busy
      d0ff9348
    • L
      Merge tag 'for-linus-v3.10-rc6' of git://oss.sgi.com/xfs/xfs · d58c6ff0
      Linus Torvalds 提交于
      Pull xfs fixes from Ben Myers:
       - Remove noisy warnings about experimental support which spams the logs
       - Add padding to align directory and attr structures correctly
       - Set block number on child buffer on a root btree split
       - Disable verifiers during log recovery for non-CRC filesystems
      
      * tag 'for-linus-v3.10-rc6' of git://oss.sgi.com/xfs/xfs:
        xfs: don't shutdown log recovery on validation errors
        xfs: ensure btree root split sets blkno correctly
        xfs: fix implicit padding in directory and attr CRC formats
        xfs: don't emit v5 superblock warnings on write
      d58c6ff0
    • L
      Merge tag 'char-misc-3.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc · 9bb92855
      Linus Torvalds 提交于
      Pull char / misc fixes from Greg Kroah-Hartman:
       "Here are some small mei driver fixes for 3.10-rc6 that fix some
        reported problems"
      
      * tag 'char-misc-3.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
        mei: me: clear interrupts on the resume path
        mei: nfc: fix nfc device freeing
        mei: init: Flush scheduled work before resetting the device
      9bb92855
    • L
      Merge tag 'usb-3.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb · 3ad2e318
      Linus Torvalds 提交于
      Pull USB fixes from Greg Kroah-Hartman:
       "Here are some small USB driver fixes that resolve some reported
        problems for 3.10-rc6
      
        Nothing major, just 3 USB serial driver fixes, and two chipidea fixes"
      
      * tag 'usb-3.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
        usb: chipidea: fix id change handling
        usb: chipidea: fix no transceiver case
        USB: pl2303: fix device initialisation at open
        USB: spcp8x5: fix device initialisation at open
        USB: f81232: fix device initialisation at open
      3ad2e318
    • B
      powerpc: Fix missing/delayed calls to irq_work · 230b3034
      Benjamin Herrenschmidt 提交于
      When replaying interrupts (as a result of the interrupt occurring
      while soft-disabled), in the case of the decrementer, we are exclusively
      testing for a pending timer target. However we also use decrementer
      interrupts to trigger the new "irq_work", which in this case would
      be missed.
      
      This change the logic to force a replay in both cases of a timer
      boundary reached and a decrementer interrupt having actually occurred
      while disabled. The former test is still useful to catch cases where
      a CPU having been hard-disabled for a long time completely misses the
      interrupt due to a decrementer rollover.
      
      CC: <stable@vger.kernel.org> [v3.4+]
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Tested-by: NSteven Rostedt <rostedt@goodmis.org>
      230b3034
    • P
      powerpc: Fix emulation of illegal instructions on PowerNV platform · bf593907
      Paul Mackerras 提交于
      Normally, the kernel emulates a few instructions that are unimplemented
      on some processors (e.g. the old dcba instruction), or privileged (e.g.
      mfpvr).  The emulation of unimplemented instructions is currently not
      working on the PowerNV platform.  The reason is that on these machines,
      unimplemented and illegal instructions cause a hypervisor emulation
      assist interrupt, rather than a program interrupt as on older CPUs.
      Our vector for the emulation assist interrupt just calls
      program_check_exception() directly, without setting the bit in SRR1
      that indicates an illegal instruction interrupt.  This fixes it by
      making the emulation assist interrupt set that bit before calling
      program_check_interrupt().  With this, old programs that use no-longer
      implemented instructions such as dcba now work again.
      
      CC: <stable@vger.kernel.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      bf593907
    • M
      powerpc: Fix stack overflow crash in resume_kernel when ftracing · 0e37739b
      Michael Ellerman 提交于
      It's possible for us to crash when running with ftrace enabled, eg:
      
        Bad kernel stack pointer bffffd12 at c00000000000a454
        cpu 0x3: Vector: 300 (Data Access) at [c00000000ffe3d40]
            pc: c00000000000a454: resume_kernel+0x34/0x60
            lr: c00000000000335c: performance_monitor_common+0x15c/0x180
            sp: bffffd12
           msr: 8000000000001032
           dar: bffffd12
         dsisr: 42000000
      
      If we look at current's stack (paca->__current->stack) we see it is
      equal to c0000002ecab0000. Our stack is 16K, and comparing to
      paca->kstack (c0000002ecab3e30) we can see that we have overflowed our
      kernel stack. This leads to us writing over our struct thread_info, and
      in this case we have corrupted thread_info->flags and set
      _TIF_EMULATE_STACK_STORE.
      
      Dumping the stack we see:
      
        3:mon> t c0000002ecab0000
        [c0000002ecab0000] c00000000002131c .performance_monitor_exception+0x5c/0x70
        [c0000002ecab0080] c00000000000335c performance_monitor_common+0x15c/0x180
        --- Exception: f01 (Performance Monitor) at c0000000000fb2ec .trace_hardirqs_off+0x1c/0x30
        [c0000002ecab0370] c00000000016fdb0 .trace_graph_entry+0xb0/0x280 (unreliable)
        [c0000002ecab0410] c00000000003d038 .prepare_ftrace_return+0x98/0x130
        [c0000002ecab04b0] c00000000000a920 .ftrace_graph_caller+0x14/0x28
        [c0000002ecab0520] c0000000000d6b58 .idle_cpu+0x18/0x90
        [c0000002ecab05a0] c00000000000a934 .return_to_handler+0x0/0x34
        [c0000002ecab0620] c00000000001e660 .timer_interrupt+0x160/0x300
        [c0000002ecab06d0] c0000000000025dc decrementer_common+0x15c/0x180
        --- Exception: 901 (Decrementer) at c0000000000104d4 .arch_local_irq_restore+0x74/0xa0
        [c0000002ecab09c0] c0000000000fe044 .trace_hardirqs_on+0x14/0x30 (unreliable)
        [c0000002ecab0fb0] c00000000016fe3c .trace_graph_entry+0x13c/0x280
        [c0000002ecab1050] c00000000003d038 .prepare_ftrace_return+0x98/0x130
        [c0000002ecab10f0] c00000000000a920 .ftrace_graph_caller+0x14/0x28
        [c0000002ecab1160] c0000000000161f0 .__ppc64_runlatch_on+0x10/0x40
        [c0000002ecab11d0] c00000000000a934 .return_to_handler+0x0/0x34
        --- Exception: 901 (Decrementer) at c0000000000104d4 .arch_local_irq_restore+0x74/0xa0
      
        ... and so on
      
      __ppc64_runlatch_on() is called from RUNLATCH_ON in the exception entry
      path. At that point the irq state is not consistent, ie. interrupts are
      hard disabled (by the exception entry), but the paca soft-enabled flag
      may be out of sync.
      
      This leads to the local_irq_restore() in trace_graph_entry() actually
      enabling interrupts, which we do not want. Because we have not yet
      reprogrammed the decrementer we immediately take another decrementer
      exception, and recurse.
      
      The fix is twofold. Firstly make sure we call DISABLE_INTS before
      calling RUNLATCH_ON. The badly named DISABLE_INTS actually reconciles
      the irq state in the paca with the hardware, making it safe again to
      call local_irq_save/restore().
      
      Although that should be sufficient to fix the bug, we also mark the
      runlatch routines as notrace. They are called very early in the
      exception entry and we are asking for trouble tracing them. They are
      also fairly uninteresting and tracing them just adds unnecessary
      overhead.
      
      [ This regression was introduced by fe1952fc
        "powerpc: Rework runlatch code" by myself --BenH
      ]
      
      CC: <stable@vger.kernel.org> [v3.4+]
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      0e37739b
    • A
      snd_pcm_link(): fix a leak... · dd6c5cd8
      Al Viro 提交于
      in case when snd_pcm_stream_linked(substream) is true, we end up leaking
      group.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      dd6c5cd8
    • A
      use can_lookup() instead of direct checks of ->i_op->lookup · 05252901
      Al Viro 提交于
      a couple of places got missed back when Linus has introduced that one...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      05252901
    • O
      move exit_task_namespaces() outside of exit_notify() · 8aac6270
      Oleg Nesterov 提交于
      exit_notify() does exit_task_namespaces() after
      forget_original_parent(). This was needed to ensure that ->nsproxy
      can't be cleared prematurely, an exiting child we are going to
      reparent can do do_notify_parent() and use the parent's (ours) pid_ns.
      
      However, after 32084504 "pidns: use task_active_pid_ns in
      do_notify_parent" ->nsproxy != NULL is no longer needed, we rely
      on task_active_pid_ns().
      
      Move exit_task_namespaces() from exit_notify() to do_exit(), after
      exit_fs() and before exit_task_work().
      
      This solves the problem reported by Andrey, free_ipc_ns()->shm_destroy()
      does fput() which needs task_work_add().
      
      Note: this particular problem can be fixed if we change fput(), and
      that change makes sense anyway. But there is another reason to move
      the callsite. The original reason for exit_task_namespaces() from
      the middle of exit_notify() was subtle and it has already gone away,
      now this looks confusing. And this allows us do simplify exit_notify(),
      we can avoid unlock/lock(tasklist) and we can use ->exit_state instead
      of PF_EXITING in forget_original_parent().
      Reported-by: NAndrey Vagin <avagin@openvz.org>
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: NAndrey Vagin <avagin@openvz.org>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      8aac6270
    • O
      fput: task_work_add() can fail if the caller has passed exit_task_work() · e7b2c406
      Oleg Nesterov 提交于
      fput() assumes that it can't be called after exit_task_work() but
      this is not true, for example free_ipc_ns()->shm_destroy() can do
      this. In this case fput() silently leaks the file.
      
      Change it to fallback to delayed_fput_work if task_work_add() fails.
      The patch looks complicated but it is not, it changes the code from
      
      	if (PF_KTHREAD) {
      		schedule_work(...);
      		return;
      	}
      	task_work_add(...)
      
      to
      	if (!PF_KTHREAD) {
      		if (!task_work_add(...))
      			return;
      		/* fallback */
      	}
      	schedule_work(...);
      
      As for shm_destroy() in particular, we could make another fix but I
      think this change makes sense anyway. There could be another similar
      user, it is not safe to assume that task_work_add() can't fail.
      Reported-by: NAndrey Vagin <avagin@openvz.org>
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      e7b2c406
    • D
      xfs: don't shutdown log recovery on validation errors · d302cf1d
      Dave Chinner 提交于
      Unfortunately, we cannot guarantee that items logged multiple times
      and replayed by log recovery do not take objects back in time. When
      they are taken back in time, the go into an intermediate state which
      is corrupt, and hence verification that occurs on this intermediate
      state causes log recovery to abort with a corruption shutdown.
      
      Instead of causing a shutdown and unmountable filesystem, don't
      verify post-recovery items before they are written to disk. This is
      less than optimal, but there is no way to detect this issue for
      non-CRC filesystems If log recovery successfully completes, this
      will be undone and the object will be consistent by subsequent
      transactions that are replayed, so in most cases we don't need to
      take drastic action.
      
      For CRC enabled filesystems, leave the verifiers in place - we need
      to call them to recalculate the CRCs on the objects anyway. This
      recovery problem can be solved for such filesystems - we have a LSN
      stamped in all metadata at writeback time that we can to determine
      whether the item should be replayed or not. This is a separate piece
      of work, so is not addressed by this patch.
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NBen Myers <bpm@sgi.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      
      (cherry picked from commit 9222a9cf)
      d302cf1d
    • D
      xfs: ensure btree root split sets blkno correctly · 088c9f67
      Dave Chinner 提交于
      For CRC enabled filesystems, the BMBT is rooted in an inode, so it
      passes through a different code path on root splits than the
      freespace and inode btrees. This is much less traversed by xfstests
      than the other trees. When testing on a 1k block size filesystem,
      I've been seeing ASSERT failures in generic/234 like:
      
      XFS: Assertion failed: cur->bc_btnum != XFS_BTNUM_BMAP || cur->bc_private.b.allocated == 0, file: fs/xfs/xfs_btree.c, line: 317
      
      which are generally preceded by a lblock check failure. I noticed
      this in the bmbt stats:
      
      $ pminfo -f xfs.btree.block_map
      
      xfs.btree.block_map.lookup
          value 39135
      
      xfs.btree.block_map.compare
          value 268432
      
      xfs.btree.block_map.insrec
          value 15786
      
      xfs.btree.block_map.delrec
          value 13884
      
      xfs.btree.block_map.newroot
          value 2
      
      xfs.btree.block_map.killroot
          value 0
      .....
      
      Very little coverage of root splits and merges. Indeed, on a 4k
      filesystem, block_map.newroot and block_map.killroot are both zero.
      i.e. the code is not exercised at all, and it's the only generic
      btree infrastructure operation that is not exercised by a default run
      of xfstests.
      
      Turns out that on a 1k filesystem, generic/234 accounts for one of
      those two root splits, and that is somewhat of a smoking gun. In
      fact, it's the same problem we saw in the directory/attr code where
      headers are memcpy()d from one block to another without updating the
      self describing metadata.
      
      Simple fix - when copying the header out of the root block, make
      sure the block number is updated correctly.
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NBen Myers <bpm@sgi.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      
      (cherry picked from commit ade1335a)
      088c9f67
    • D
      xfs: fix implicit padding in directory and attr CRC formats · 5170711d
      Dave Chinner 提交于
      Michael L. Semon has been testing CRC patches on a 32 bit system and
      been seeing assert failures in the directory code from xfs/080.
      Thanks to Michael's heroic efforts with printk debugging, we found
      that the problem was that the last free space being left in the
      directory structure was too small to fit a unused tag structure and
      it was being corrupted and attempting to log a region out of bounds.
      Hence the assert failure looked something like:
      
      .....
      #5 calling xfs_dir2_data_log_unused() 36 32
      #1 4092 4095 4096
      #2 8182 8183 4096
      XFS: Assertion failed: first <= last && last < BBTOB(bp->b_length), file: fs/xfs/xfs_trans_buf.c, line: 568
      
      Where #1 showed the first region of the dup being logged (i.e. the
      last 4 bytes of a directory buffer) and #2 shows the corrupt values
      being calculated from the length of the dup entry which overflowed
      the size of the buffer.
      
      It turns out that the problem was not in the logging code, nor in
      the freespace handling code. It is an initial condition bug that
      only shows up on 32 bit systems. When a new buffer is initialised,
      where's the freespace that is set up:
      
      [  172.316249] calling xfs_dir2_leaf_addname() from xfs_dir_createname()
      [  172.316346] #9 calling xfs_dir2_data_log_unused()
      [  172.316351] #1 calling xfs_trans_log_buf() 60 63 4096
      [  172.316353] #2 calling xfs_trans_log_buf() 4094 4095 4096
      
      Note the offset of the first region being logged? It's 60 bytes into
      the buffer. Once I saw that, I pretty much knew that the bug was
      going to be caused by this.
      
      Essentially, all direct entries are rounded to 8 bytes in length,
      and all entries start with an 8 byte alignment. This means that we
      can decode inplace as variables are naturally aligned. With the
      directory data supposedly starting on a 8 byte boundary, and all
      entries padded to 8 bytes, the minimum freespace in a directory
      block is supposed to be 8 bytes, which is large enough to fit a
      unused data entry structure (6 bytes in size). The fact we only have
      4 bytes of free space indicates a directory data block alignment
      problem.
      
      And what do you know - there's an implicit hole in the directory
      data block header for the CRC format, which means the header is 60
      byte on 32 bit intel systems and 64 bytes on 64 bit systems. Needs
      padding. And while looking at the structures, I found the same
      problem in the attr leaf header. Fix them both.
      
      Note that this only affects 32 bit systems with CRCs enabled.
      Everything else is just fine. Note that CRC enabled filesystems created
      before this fix on such systems will not be readable with this fix
      applied.
      Reported-by: NMichael L. Semon <mlsemon35@gmail.com>
      Debugged-by: NMichael L. Semon <mlsemon35@gmail.com>
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NBen Myers <bpm@sgi.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      
      (cherry picked from commit 8a1fd295)
      5170711d
    • D
      xfs: don't emit v5 superblock warnings on write · 47ad2fcb
      Dave Chinner 提交于
      We write the superblock every 30s or so which results in the
      verifier being called. Right now that results in this output
      every 30s:
      
      XFS (vda): Version 5 superblock detected. This kernel has EXPERIMENTAL support enabled!
      Use of these features in this kernel is at your own risk!
      
      And spamming the logs.
      
      We don't need to check for whether we support v5 superblocks or
      whether there are feature bits we don't support set as these are
      only relevant when we first mount the filesytem. i.e. on superblock
      read. Hence for the write verification we can just skip all the
      checks (and hence verbose output) altogether.
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      
      (cherry picked from commit 34510185)
      47ad2fcb
  8. 14 6月, 2013 15 次提交
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs · a2648ebb
      Linus Torvalds 提交于
      Pull btrfs fixes from Chris Mason:
       "This is an assortment of crash fixes"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
        Btrfs: stop all workers before cleaning up roots
        Btrfs: fix use-after-free bug during umount
        Btrfs: init relocate extent_io_tree with a mapping
        btrfs: Drop inode if inode root is NULL
        Btrfs: don't delete fs_roots until after we cleanup the transaction
      a2648ebb
    • T
      mei: me: clear interrupts on the resume path · 42f132fe
      Tomas Winkler 提交于
      We need to clear pending interrupts on the resume
      path. This brings the device into defined state
      before starting the reset flow
      
      This should solve suspend/resume issues:
      
      mei_me : wait hw ready failed. status = 0x0
      mei_me : version message write failed
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42f132fe
    • T
      mei: nfc: fix nfc device freeing · 2753ff53
      Tomas Winkler 提交于
      The nfc_dev is a static variable and is not cleaned properly upon reset
      mainly ndev->cl and ndev->cl_info are not set to NULL after freeing which
      
      mei_stop:198: mei_me 0000:00:16.0: stopping the device.
      [  404.253427] general protection fault: 0000 [#2] SMP
      [  404.253437] Modules linked in: mei_me(-) binfmt_misc snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device edd af_packet cpufreq_conservative cpufreq_userspace cpufreq_powersave fuse loop dm_mod hid_generic usbhid hid coretemp acpi_cpufreq mperf kvm_intel kvm crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw gf128mul snd_hda_codec_hdmi glue_helper aes_x86_64 e1000e snd_hda_intel snd_hda_codec ehci_pci iTCO_wdt iTCO_vendor_support ehci_hcd snd_hwdep xhci_hcd snd_pcm usbcore ptp mei sg microcode snd_timer pps_core i2c_i801 snd pcspkr battery rtc_cmos lpc_ich mfd_core soundcore usb_common snd_page_alloc ac ext3 jbd mbcache drm_kms_helper drm intel_agp i2c_algo_bit intel_gtt i2c_core sd_mod crc_t10dif thermal fan video button processor thermal_sys hwmon ahci libahci libata scsi_mod [last unloaded: mei_me]
      [  404.253591] CPU: 0 PID: 5551 Comm: modprobe Tainted: G      D W    3.10.0-rc3 #1
      [  404.253611] task: ffff880143cd8300 ti: ffff880144a2a000 task.ti: ffff880144a2a000
      [  404.253619] RIP: 0010:[<ffffffff81334e5d>]  [<ffffffff81334e5d>] device_del+0x1d/0x1d0
      [  404.253638] RSP: 0018:ffff880144a2bcf8  EFLAGS: 00010206
      [  404.253645] RAX: 2020302e30202030 RBX: ffff880144fdb000 RCX: 0000000000000086
      [  404.253652] RDX: 0000000000000001 RSI: 0000000000000086 RDI: ffff880144fdb000
      [  404.253659] RBP: ffff880144a2bd18 R08: 0000000000000651 R09: 0000000000000006
      [  404.253666] R10: 0000000000000651 R11: 0000000000000006 R12: ffff880144fdb000
      [  404.253673] R13: ffff880149371098 R14: ffff880144482c00 R15: ffffffffa04710e0
      [  404.253681] FS:  00007f251c59a700(0000) GS:ffff88014e200000(0000) knlGS:0000000000000000
      [  404.253689] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  404.253696] CR2: ffffffffff600400 CR3: 0000000145319000 CR4: 00000000001407f0
      [  404.253703] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  404.253710] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  404.253716] Stack:
      [  404.253720]  ffff880144fdb000 ffff880143ffe000 ffff880149371098 ffffffffa0471000
      [  404.253732]  ffff880144a2bd38 ffffffff8133502d ffff88014e20cf48 ffff880143ffe1d8
      [  404.253744]  ffff880144a2bd48 ffffffffa02a4749 ffff880144a2bd58 ffffffffa02a4ba1
      [  404.253755] Call Trace:
      [  404.253766]  [<ffffffff8133502d>] device_unregister+0x1d/0x60
      [  404.253787]  [<ffffffffa02a4749>] mei_cl_remove_device+0x9/0x10 [mei]
      [  404.253804]  [<ffffffffa02a4ba1>] mei_nfc_host_exit+0x21/0x30 [mei]
      [  404.253819]  [<ffffffffa029c2dd>] mei_stop+0x3d/0x90 [mei]
      [  404.253830]  [<ffffffffa046e220>] mei_me_remove+0x60/0xe0 [mei_me]
      [  404.253843]  [<ffffffff81278f37>] pci_device_remove+0x37/0xb0
      [  404.253855]  [<ffffffff81337c68>] __device_release_driver+0x98/0x100
      [  404.253865]  [<ffffffff81337d80>] driver_detach+0xb0/0xc0
      [  404.253876]  [<ffffffff81336b4f>] bus_remove_driver+0x8f/0x120
      [  404.253891]  [<ffffffff81075990>] ? try_to_wake_up+0x2b0/0x2b0
      [  404.253903]  [<ffffffff81338a48>] driver_unregister+0x58/0x90
      [  404.253913]  [<ffffffff8127906b>] pci_unregister_driver+0x2b/0xb0
      [  404.253924]  [<ffffffffa046f244>] mei_me_driver_exit+0x10/0xdcc [mei_me]
      [  404.253936]  [<ffffffff810a50d8>] SyS_delete_module+0x198/0x2b0
      [  404.253949]  [<ffffffff814850d9>] ? do_page_fault+0x9/0x10
      [  404.253961]  [<ffffffff81489692>] system_call_fastpath+0x16/0x1b
      [  404.253967] Code: 41 5c 41 5d 41 5e 41 5f c9 c3 0f 1f 40 00 55 48 89 e5 41 56 41 55 41 54 49 89 fc 53 48 8b 87 88 00 00 00 4c 8b 37 48 85 c0 74 18 <48> 8b 78 78 4c 89 e2 be 02 00 00 00 48 81 c7 f8 00 00 00 e8 3b
      [  404.254048] RIP  [<ffffffff81334e5d>] device_del+0x1d/0x1d0
      
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2753ff53
    • S
      mei: init: Flush scheduled work before resetting the device · 5e85b364
      Samuel Ortiz 提交于
      Flushing pending work items before resetting the device makes more
      sense than doing so afterwards. Some of them, like e.g. the NFC
      initialization one, find themselves with client IDs changed after
      the reset, eventually leading to trigger a client.c:mei_me_cl_by_id()
      warning after a few modprobe/rmmod cycles.
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e85b364
    • N
      sctp: fully initialize sctp_outq in sctp_outq_init · c5c7774d
      Neil Horman 提交于
      In commit 2f94aabd
      (refactor sctp_outq_teardown to insure proper re-initalization)
      we modified sctp_outq_teardown to use sctp_outq_init to fully re-initalize the
      outq structure.  Steve West recently asked me why I removed the q->error = 0
      initalization from sctp_outq_teardown.  I did so because I was operating under
      the impression that sctp_outq_init would properly initalize that value for us,
      but it doesn't.  sctp_outq_init operates under the assumption that the outq
      struct is all 0's (as it is when called from sctp_association_init), but using
      it in __sctp_outq_teardown violates that assumption. We should do a memset in
      sctp_outq_init to ensure that the entire structure is in a known state there
      instead.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Reported-by: N"West, Steve (NSN - US/Fort Worth)" <steve.west@nsn.com>
      CC: Vlad Yasevich <vyasevich@gmail.com>
      CC: netdev@vger.kernel.org
      CC: davem@davemloft.net
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5c7774d
    • B
      netiucv: Hold rtnl between name allocation and device registration. · aaf9522d
      Benjamin Poirier 提交于
      fixes a race condition between concurrent initializations of netiucv devices
      that try to use the same name.
      
      sysfs: cannot create duplicate filename '/devices/iucv/netiucv2'
      [...]
      Call Trace:
      ([<00000000002edea4>] sysfs_add_one+0xb0/0xdc)
       [<00000000002eecd4>] create_dir+0x80/0xfc
       [<00000000002eee38>] sysfs_create_dir+0xe8/0x118
       [<00000000003835a8>] kobject_add_internal+0x120/0x2d0
       [<00000000003839d6>] kobject_add+0x62/0x9c
       [<00000000003d9564>] device_add+0xcc/0x510
       [<000003e00212c7b4>] netiucv_register_device+0xc0/0x1ec [netiucv]
      Signed-off-by: NBenjamin Poirier <bpoirier@suse.de>
      Tested-by: NUrsula Braun <braunu@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aaf9522d
    • N
      tulip: Properly check dma mapping result · c9bfbb31
      Neil Horman 提交于
      Tulip throws an error when dma debugging is enabled, as it doesn't properly
      check dma mapping results with dma_mapping_error() durring tx ring refills.
      
      Easy fix, just add it in, and drop the frame if the mapping is bad
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Grant Grundler <grundler@parisc-linux.org>
      CC: "David S. Miller" <davem@davemloft.net>
      Reviewed-by: NGrant Grundler <grundler@parisc-linux.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c9bfbb31
    • L
      Merge tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux · 33c929c0
      Linus Torvalds 提交于
      Pull device tree bug fixes from Grant Likely:
       "This branch contains the following bug fixes:
         - Fix locking vs. interrupts. Bug caught by lockdep checks
         - Fix parsing of cpp #line directive output by dtc
         - Fix 'make clean' for dtc temporary files.
      
        There is also a commit that regenerates the dtc lexer and parser files
        with Bison 2.5.  The only purpose of this commit is to separate the
        functional change in the dtc bug fix from the code generation change
        caused by a different Bison version"
      
      * tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux:
        dtc: ensure #line directives don't consume data from the next line
        dtc: Update generated files to output from Bison 2.5
        of: Fix locking vs. interrupts
        kbuild: make sure we clean up DTB temporary files
      33c929c0
    • G
      dtc: ensure #line directives don't consume data from the next line · 706b78f3
      Grant Likely 提交于
      Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
      could match line-break characters. If the #line directive did not contain
      the optional flags field at the end, this could cause any integer data on
      the next line to be consumed as part of the #line directive parsing. This
      could cause syntax errors (i.e. #line parsing consuming the leading 0
      from a hex literal 0x1234, leaving x1234 to be parsed as cell data,
      which is a syntax error), or invalid compilation results (i.e. simply
      consuming literal 1234 as part of the #line processing, thus removing it
      from the cell data).
      
      Fix this by replacing {WS} with [ \t] so that it can't match line-breaks.
      
      Convert all instances of {WS}, even though the other instances should be
      irrelevant for any well-formed #line directive. This is done for
      consistency and ultimate safety.
      
      [Cherry picked from DTC commit a1ee6f068e1c8dbc62873645037a353d7852d5cc]
      Reported-by: NIan Campbell <Ian.Campbell@citrix.com>
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      706b78f3
    • G
      dtc: Update generated files to output from Bison 2.5 · 2a6a08ca
      Grant Likely 提交于
      This patch merely updates the generated dtc parser and lexer files to
      the output generated by Bison 2.5. The previous versions were generated
      from version 2.4.1. The only reason for this commit is to minimize the
      diff on the next commit which fixes a bug in the DTC #line directive
      parsing. Otherwise the Bison changes would be intermingled with the
      functional changes.
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      2a6a08ca
    • B
      of: Fix locking vs. interrupts · d25d8694
      Benjamin Herrenschmidt 提交于
      The OF code uses irqsafe locks everywhere except in a handful of functions
      for no obvious reasons. Since the conversion from the old rwlocks, this
      now triggers lockdep warnings when used at interrupt time. At least one
      driver (ibmvscsi) seems to be doing that from softirq context.
      
      This converts the few non-irqsafe locks into irqsafe ones, making them
      consistent with the rest of the code.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      d25d8694
    • I
      kbuild: make sure we clean up DTB temporary files · b0a4d8b3
      Ian Campbell 提交于
      Various temporary files used when building DTB files were not suffixed with
      .tmp and therefore were not cleaned up by "make clean".
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Reviewed-by: NStephen Warren <swarren@nvidia.com>
      Tested-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      b0a4d8b3
    • L
      Merge tag 'acpi-3.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 25e33ed9
      Linus Torvalds 提交于
      Pull ACPI fix from Rafael Wysocki:
       "This is an alternative fix for the regression introduced in 3.9 whose
        previous fix had to be reverted right before 3.10-rc5, because it
        broke one of the Tony's machines.
      
        In this one the check is confined to the ACPI video driver (which is
        the only one causing the problem to happen in the first place) and the
        Tony's box shouldn't even notice it.
      
         - ACPI fix for an issue causing ACPI video driver to attempt to bind
           to devices it shouldn't touch from Rafael J Wysocki."
      
      * tag 'acpi-3.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        ACPI / video: Do not bind to device objects with a scan handler
      25e33ed9
    • L
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · cb03dc09
      Linus Torvalds 提交于
      Pull x86 fixes from Peter Anvin:
       "Another set of fixes, the biggest bit of this is yet another tweak to
        the UEFI anti-bricking code; apparently we finally got some feedback
        from Samsung as to what makes at least their systems fail.  This set
        should actually fix the boot regressions that some other systems (e.g.
        SGI) have exhibited.
      
        Other than that, there is a patch to avoid a panic with particularly
        unhappy memory layouts and two minor protocol fixes which may or may
        not be manifest bugs"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86: Fix typo in kexec register clearing
        x86, relocs: Move __vvar_page from S_ABS to S_REL
        Modify UEFI anti-bricking code
        x86: Fix adjust_range_size_mask calling position
      cb03dc09
    • L
      Merge branch 'rcu/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu · cb7e9704
      Linus Torvalds 提交于
      Pull RCU fixes from Paul McKenney:
       "I must confess that this past merge window was not RCU's best showing.
        This series contains three more fixes for RCU regressions:
      
         1.   A fix to __DECLARE_TRACE_RCU() that causes it to act as an
              interrupt from idle rather than as a task switch from idle.
              This change is needed due to the recent use of _rcuidle()
              tracepoints that can be invoked from interrupt handlers as well
              as from idle.  Without this fix, invoking _rcuidle() tracepoints
              from interrupt handlers results in splats and (more seriously)
              confusion on RCU's part as to whether a given CPU is idle or not.
              This confusion can in turn result in too-short grace periods and
              therefore random memory corruption.
      
         2.   A fix to a subtle deadlock that could result due to RCU doing
              a wakeup while holding one of its rcu_node structure's locks.
              Although the probability of occurrence is low, it really
              does happen.  The fix, courtesy of Steven Rostedt, uses
              irq_work_queue() to avoid the deadlock.
      
         3.   A fix to a silent deadlock (invisible to lockdep) due to the
              interaction of timeouts posted by RCU debug code enabled by
              CONFIG_PROVE_RCU_DELAY=y, grace-period initialization, and CPU
              hotplug operations.  This will not occur in production kernels,
              but really does occur in randconfig testing.  Diagnosis courtesy
              of Steven Rostedt"
      
      * 'rcu/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu:
        rcu: Fix deadlock with CPU hotplug, RCU GP init, and timer migration
        rcu: Don't call wakeup() with rcu_node structure ->lock held
        trace: Allow idle-safe tracepoints to be called from irq
      cb7e9704