- 18 6月, 2013 14 次提交
-
-
由 Tomas Winkler 提交于
Driver can work properly if device support driver HBM version or driver can downgrade its supported HBM version level Signed-off-by: NTomas Winkler <tomas.winkler@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Joe Perches 提交于
This typedef is unnecessary and should just be removed. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Martyn Welch 提交于
The tsi148 driver can be configured to reserve a window for internal use (as part of the error checking routine). The intialisation of this window currently configures a set of attributes that are never used as these are only ever used by the VME core and this window is not advertised to the core. Remove configuration of these attributes. Signed-off-by: NMartyn Welch <martyn.welch@ge.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Martyn Welch 提交于
The logic in the init routine for the TSI148 is inverted. It isn't switching on the CR/CSR space when it should be and is reporting it's on when its not. Correct the logic to do the right thing. Reported-by: NDe Roo, Steven <steven.deroo@arcelormittal.com> Signed-off-by: NMartyn Welch <martyn.welch@ge.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Martyn Welch 提交于
The TSI148 driver provides an optional mechanism for ensuring that errors resulting from posted transfers are caught whilst still relevant. To do this errors are stored in a link list. If bus errors are not checked, this list would grow until available memory had been exhausted. Only store the errors in a link list if error detection is switched on. Reported-by: NDe Roo, Steven <steven.deroo@arcelormittal.com> Signed-off-by: NMartyn Welch <martyn.welch@ge.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alexander Shiyan 提交于
Patch removes unneeded check for resource since devm_ioremap_resource do all for us. Signed-off-by: NAlexander Shiyan <shc_work@mail.ru> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alexander Shiyan 提交于
No dependencies of PCMCIA and ARCH_CLPS711X. Signed-off-by: NAlexander Shiyan <shc_work@mail.ru> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alessandro Rubini 提交于
This set of headers comes from commit ab23167f (current master of the project on ohwr.org). They define the basic data structures for FMC and its SDB support. Signed-off-by: NAlessandro Rubini <rubini@gnudd.com> Acked-by: NJuan David Gonzalez Cobas <dcobas@cern.ch> Acked-by: NEmilio G. Cota <cota@braap.org> Acked-by: NSamuel Iglesias Gonsalvez <siglesias@igalia.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alessandro Rubini 提交于
This commit creates the drivers/fmc directory and puts the necessary hooks for kbuild and kconfig. The code is currently a placeholder that only registers an empty bus. Signed-off-by: NAlessandro Rubini <rubini@gnudd.com> Acked-by: NJuan David Gonzalez Cobas <dcobas@cern.ch> Acked-by: NEmilio G. Cota <cota@braap.org> Acked-by: NSamuel Iglesias Gonsalvez <siglesias@igalia.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Graeme Gregory 提交于
This is the driver for the USB comparator built into the palmas chip. It handles the various USB OTG events that can be generated by cable insertion/removal. Signed-off-by: NGraeme Gregory <gg@slimlogic.co.uk> Signed-off-by: NMoiz Sonasath <m-sonasath@ti.com> Signed-off-by: NRuchika Kharwar <ruchika@ti.com> Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com> Signed-off-by: NGeorge Cherian <george.cherian@ti.com> [kishon@ti.com: adapted palmas usb driver to use the extcon framework] Signed-off-by: NSebastien Guiriec <s-guiriec@ti.com> Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com> Signed-off-by: NMyungjoo Ham <myungjoo.ham@samsung.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Kishon Vijay Abraham I 提交于
Added EXPORT_SYMBOL_GPL() for extcon_register_interest and extcon_register_notifier in order to avoid undefined reference error when building the consumer modules of extcon as _modules_. Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com> Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com> Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com> Signed-off-by: NMyungjoo Ham <myungjoo.ham@samsung.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Chanwoo Choi 提交于
This patch change permission from read/write to only read. The specific process in the user-space couldn't change the state of cable when cable is attached or detached. - /sys/class/extcon/[devine name]/state Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com> Signed-off-by: NMyungjoo Ham <myungjoo.ham@samsung.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Tomas Hozza 提交于
Use errno and strerror() when logging errors to provide more information. Signed-off-by: NTomas Hozza <thozza@redhat.com> Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
We want the fixes in here.
-
- 16 6月, 2013 3 次提交
-
-
由 Linus Torvalds 提交于
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc由 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
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net由 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 ...
-
- 15 6月, 2013 17 次提交
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc由 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
-
由 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>
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs由 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
-
git://oss.sgi.com/xfs/xfs由 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
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc由 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
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb由 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
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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)
-
由 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)
-
由 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)
-
由 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)
-
- 14 6月, 2013 6 次提交
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs由 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
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-