- 09 Jan, 2014 27 commits
-
-
Fabio Estevam authored
commit cc5c9eb6 upstream. Commit 40ed51a4 (usb: chipidea: host: add vbus regulator control) introduced a smatch complaint because regulator_disable() is called without checking whether ci->platdata->reg_vbus is not NULL. Fix this by adding the check. This patch is needed for 3.12 stable Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bjørn Mork authored
commit 4144bc86 upstream. Reported-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Acked-by:
-
Marc Kleine-Budde authored
commit 20fb4eb9 upstream. This patch fixes a memory leak in pcan_usb_pro_init(). In patch f14e2243 net: can: peak_usb: Do not do dma on the stack the struct pcan_usb_pro_fwinfo *fi and struct pcan_usb_pro_blinfo *bi were converted from stack to dynamic allocation va kmalloc(). However the corresponding kfree() was not introduced. This patch adds the missing kfree(). Reported-by:
Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Takashi Iwai authored
commit 6962d914 upstream. We've got regression reports that my previous fix for spurious wakeups after S5 on HP Haswell machines leads to the automatic reboot at shutdown on some machines. It turned out that the fix for one side triggers another BIOS bug in other side. So, it's exclusive. Since the original S5 wakeups have been confirmed only on HP machines, it'd be safer to apply it only to limited machines. As a wild guess, limiting to machines with HP PCI SSID should suffice. This patch should be backported to kernels as old as 3.12, that contain the commit 638298dc "xhci: Fix spurious wakeups after S5 on Haswell". Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: <dashing.meng@gmail.com> Reported-by:
Niklas Schnelle <niklas@komani.de> Reported-by:
Giorgos <ganastasiouGR@gmail.com> Reported-by: <art1@vhex.net> Signed-off-by:
-
Dmitry Kunilov authored
commit 52d0dc75 upstream. ZTE AC2726 EVDO modem drops ppp connection every minute when driven by zte_ev but works fine when driven by option. Move the support for AC2726 back to option driver. Signed-off-by:
Dmitry Kunilov <dmitry.kunilov@gmail.com> Signed-off-by:
-
Mika Westerberg authored
commit d24c195f upstream. Newer Intel PCHs with LPSS have the same Designware controllers than Haswell but ACPI IDs are different. Add these IDs to the driver list. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Jonathan Cameron authored
commit e39d9905 upstream. Note this also sets the endianness to big endian whereas it would previously have defaulted to the cpu endian. Hence technically this is a bug fix on LE platforms. Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Acked-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Jonathan Cameron authored
commit 3425c0f7 upstream. A single channel in this driver was using the IIO_ST macro. This does not provide a parameter for setting the endianness of the channel. Thus this channel will have been reported as whatever is the native endianness of the cpu rather than big endian. This means it would be incorrect on little endian platforms. Signed-off-by:
-
Hui Wang authored
commit c29cb5eb upstream. On the Dell machines with codec whose Subsystem Id is 0x10280610, 0x10280629 or 0x1028063e, no external microphone can be detected when plugging a 3-ring headset. If we add "model=dell-headset-multi" for the snd-hda-intel.ko, the problem will disappear. The codecs on these machines belong to alc_269 family. BugLink: https://bugs.launchpad.net/bugs/1260303 Cc: David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
David Henningsson authored
commit 693e0cb0 upstream. While enabling these machines, we found we would sometimes lose an interrupt if we change hardware volume during playback, and that disabling msi fixed this issue. (Losing the interrupt caused underruns and crackling audio, as the one second timeout is usually bigger than the period size.) The machines were all machines from HP, running AMD Hudson controller, and Realtek ALC282 codec. BugLink: https://bugs.launchpad.net/bugs/1260225Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
JongHo Kim authored
commit ed697e1a upstream. When the process is sleeping at the SNDRV_PCM_STATE_PAUSED state from the wait_for_avail function, the sleep process will be woken by timeout(10 seconds). Even if the sleep process wake up by timeout, by this patch, the process will continue with sleep and wait for the other state. Signed-off-by:
JongHo Kim <furmuwon@gmail.com> Signed-off-by:
-
Charles Keepax authored
commit 280484e7 upstream. Reported-by:
Kyung-Kwee Ryu <kyung-kwee.ryu@wolfsonmicro.com> Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Charles Keepax authored
commit 939fd1e8 upstream. Some devices are getting very close to the limit whilst polling the RAM start, this patch adds a small delay to this loop to give a longer startup timeout. Signed-off-by:
-
Bo Shen authored
commit f0199bc5 upstream. When wm8904 work in DSP mode B, we still need to configure it to work in DSP mode. Or else, it will work in Right Justified mode. Signed-off-by:
Bo Shen <voice.shen@atmel.com> Acked-by:
-
Stephen Warren authored
commit 241bf433 upstream. In tegra*_i2s_set_fmt(), in the (fmt == SND_SOC_DAIFMT_CBM_CFM) case, "val" is never assigned to, but left uninitialized. The other case does initialized it. Fix this by initializing val at the start of the function, and only ever ORing into it. Update the handling of "mask" so it works the same way for consistency. Update tegra20_spdif.c to use the same code-style for consistency, even though it doesn't happen to suffer from the same problem at present. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Reviewed-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Vivek Goyal authored
commit c97102ba upstream. Commit 1b3a5d02 ("reboot: move arch/x86 reboot= handling to generic kernel") moved reboot= handling to generic code. In the process it also removed the code in native_machine_shutdown() which are moving reboot process to reboot_cpu/cpu0. I guess that thought must have been that all reboot paths are calling migrate_to_reboot_cpu(), so we don't need this special handling. But kexec reboot path (kernel_kexec()) is not calling migrate_to_reboot_cpu() so above change broke kexec. Now reboot can happen on non-boot cpu and when INIT is sent in second kerneo to bring up BP, it brings down the machine. So start calling migrate_to_reboot_cpu() in kexec reboot path to avoid this problem. Bisected by WANG Chao. Reported-by:
Matthew Whitehead <mwhitehe@redhat.com> Reported-by:
Dave Young <dyoung@redhat.com> Signed-off-by:
Vivek Goyal <vgoyal@redhat.com> Tested-by:
Baoquan He <bhe@redhat.com> Tested-by:
WANG Chao <chaowang@redhat.com> Acked-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
H Hartley Sweeten authored
commit c6236c0c upstream. Some of the callback functions that upload the firmware in the comedi drivers return a positive value indicating the number of bytes sent to the device. Detect this condition and just return '0' to indicate a successful upload. Reported-by:
Bernd Porr <mail@berndporr.me.uk> Signed-off-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Acked-by:
Ian Abbott <abbotti@mev.co.uk> Acked-by:
-
Ian Abbott authored
commit 0283f7a1 upstream. At some point, Measurement Computing / ComputerBoards redesigned the PCI-DIO48H to use a PLX PCI interface chip instead of an AMCC chip. This meant they had to put their hardware registers in the PCI BAR 2 region instead of PCI BAR 1. Unfortunately, they kept the same PCI device ID for the new design. This means the driver recognizes the newer cards, but doesn't work (and is likely to screw up the local configuration registers of the PLX chip) because it's using the wrong region. Since the PCI subvendor and subdevice IDs were both zero on the old design, but are the same as the vendor and device on the new design, we can tell the old design and new design apart easily enough. Split the existing entry for the PCI-DIO48H in `pci_8255_boards[]` into two new entries, referenced by different entries in the PCI device ID table `pci_8255_pci_table[]`. Use the same board name for both entries. Signed-off-by:
-
Geert Uytterhoeven authored
commit dc1dc2f8 upstream. When booting a multi-platform m68k kernel on a non-Mac with "console=ttyS0" on the kernel command line, it crashes with: Unable to handle kernel NULL pointer dereference at virtual address (null) Oops: 00000000 PC: [<0013ad28>] __pmz_startup+0x32/0x2a0 ... Call Trace: [<002c5d3e>] pmz_console_setup+0x64/0xe4 The normal tty driver doesn't crash, because init_pmz() checks pmz_ports_count again after calling pmz_probe(). In the serial console initialization path, pmz_console_init() doesn't do this, causing the driver to crash later. Add a check for pmz_ports_count to fix this. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: Finn Thain <fthain@telegraphics.com.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Peter Hurley authored
commit 1075a6e2 upstream. With block processing of echoed output, observed output order is still required. Push completed echoes and echo commands prior to output. Introduce echo_mark echo buffer index, which tracks completed echo commands; ie., those submitted via commit_echoes but which may not have been committed. Ensure that completed echoes are output prior to subsequent terminal writes in process_echoes(). Fixes newline/prompt output order in cooked mode shell. Reported-by:
Karl Dahlke <eklhad@comcast.net> Reported-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Tested-by:
-
Peter Hurley authored
commit cf872776 upstream. When a controlling tty is being hung up and the hang up is waiting for a just-signalled tty reader or writer to exit, and a new tty reader/writer tries to acquire an ldisc reference concurrently with the ldisc reference release from the signalled reader/writer, the hangup can hang. The new reader/writer is sleeping in ldsem_down_read() and the hangup is sleeping in ldsem_down_write() [1]. The new reader/writer fails to wakeup the waiting hangup because the wrong lock count value is checked (the old lock count rather than the new lock count) to see if the lock is unowned. Change helper function to return the new lock count if the cmpxchg was successful; document this behavior. [1] edited dmesg log from reporter SysRq : Show Blocked State task PC stack pid father systemd D ffff88040c4f0000 0 1 0 0x00000000 ffff88040c49fbe0 0000000000000046 ffff88040c4a0000 ffff88040c49ffd8 00000000001d3980 00000000001d3980 ffff88040c4a0000 ffff88040593d840 ffff88040c49fb40 ffffffff810a4cc0 0000000000000006 0000000000000023 Call Trace: [<ffffffff810a4cc0>] ? sched_clock_cpu+0x9f/0xe4 [<ffffffff810a4cc0>] ? sched_clock_cpu+0x9f/0xe4 [<ffffffff810a4cc0>] ? sched_clock_cpu+0x9f/0xe4 [<ffffffff810a4cc0>] ? sched_clock_cpu+0x9f/0xe4 [<ffffffff817a6649>] schedule+0x24/0x5e [<ffffffff817a588b>] schedule_timeout+0x15b/0x1ec [<ffffffff810a4cc0>] ? sched_clock_cpu+0x9f/0xe4 [<ffffffff817aa691>] ? _raw_spin_unlock_irq+0x24/0x26 [<ffffffff817aa10c>] down_read_failed+0xe3/0x1b9 [<ffffffff817aa26d>] ldsem_down_read+0x8b/0xa5 [<ffffffff8142b5ca>] ? tty_ldisc_ref_wait+0x1b/0x44 [<ffffffff8142b5ca>] tty_ldisc_ref_wait+0x1b/0x44 [<ffffffff81423f5b>] tty_write+0x7d/0x28a [<ffffffff814241f5>] redirected_tty_write+0x8d/0x98 [<ffffffff81424168>] ? tty_write+0x28a/0x28a [<ffffffff8115d03f>] do_loop_readv_writev+0x56/0x79 [<ffffffff8115e604>] do_readv_writev+0x1b0/0x1ff [<ffffffff8116ea0b>] ? do_vfs_ioctl+0x32a/0x489 [<ffffffff81167d9d>] ? final_putname+0x1d/0x3a [<ffffffff8115e6c7>] vfs_writev+0x2e/0x49 [<ffffffff8115e7d3>] SyS_writev+0x47/0xaa [<ffffffff817ab822>] system_call_fastpath+0x16/0x1b bash D ffffffff81c104c0 0 5469 5302 0x00000082 ffff8800cf817ac0 0000000000000046 ffff8804086b22a0 ffff8800cf817fd8 00000000001d3980 00000000001d3980 ffff8804086b22a0 ffff8800cf817a48 000000000000b9a0 ffff8800cf817a78 ffffffff81004675 ffff8800cf817a44 Call Trace: [<ffffffff81004675>] ? dump_trace+0x165/0x29c [<ffffffff810a4cc0>] ? sched_clock_cpu+0x9f/0xe4 [<ffffffff8100edda>] ? save_stack_trace+0x26/0x41 [<ffffffff817a6649>] schedule+0x24/0x5e [<ffffffff817a588b>] schedule_timeout+0x15b/0x1ec [<ffffffff810a4cc0>] ? sched_clock_cpu+0x9f/0xe4 [<ffffffff817a9f03>] ? down_write_failed+0xa3/0x1c9 [<ffffffff817aa691>] ? _raw_spin_unlock_irq+0x24/0x26 [<ffffffff817a9f0b>] down_write_failed+0xab/0x1c9 [<ffffffff817aa300>] ldsem_down_write+0x79/0xb1 [<ffffffff817aada3>] ? tty_ldisc_lock_pair_timeout+0xa5/0xd9 [<ffffffff817aada3>] tty_ldisc_lock_pair_timeout+0xa5/0xd9 [<ffffffff8142bf33>] tty_ldisc_hangup+0xc4/0x218 [<ffffffff81423ab3>] __tty_hangup+0x2e2/0x3ed [<ffffffff81424a76>] disassociate_ctty+0x63/0x226 [<ffffffff81078aa7>] do_exit+0x79f/0xa11 [<ffffffff81086bdb>] ? get_signal_to_deliver+0x206/0x62f [<ffffffff810b4bfb>] ? lock_release_holdtime.part.8+0xf/0x16e [<ffffffff81079b05>] do_group_exit+0x47/0xb5 [<ffffffff81086c16>] get_signal_to_deliver+0x241/0x62f [<ffffffff810020a7>] do_signal+0x43/0x59d [<ffffffff810f2af7>] ? __audit_syscall_exit+0x21a/0x2a8 [<ffffffff810b4bfb>] ? lock_release_holdtime.part.8+0xf/0x16e [<ffffffff81002655>] do_notify_resume+0x54/0x6c [<ffffffff817abaf8>] int_signal+0x12/0x17 Reported-by:
Sami Farin <sami.farin@gmail.com> Signed-off-by:
-
pingfan liu authored
commit 91648ec0 upstream. Since kvmppc_hv_find_lock_hpte() is called from both virtmode and realmode, so it can trigger the deadlock. Suppose the following scene: Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of vcpus. If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is switched out, and on cpuN, vcpu_A_2 try to lock X in realmode, then cpuN will be caught in realmode for a long time. What makes things even worse if the following happens, On cpuM, bitlockX is hold, on cpuN, Y is hold. vcpu_B_2 try to lock Y on cpuM in realmode vcpu_A_2 try to lock X on cpuN in realmode Oops! deadlock happens Signed-off-by:
Liu Ping Fan <pingfank@linux.vnet.ibm.com> Reviewed-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
Alexander Graf <agraf@suse.de> Signed-off-by:
-
Li Wang authored
commit ff638b7d upstream. ceph_osdc_readpages() returns number of bytes read, currently, the code only allocate full-zero page into fscache, this patch fixes this. Signed-off-by:
Li Wang <liwang@ubuntukylin.com> Reviewed-by:
Milosz Tanski <milosz@adfin.com> Reviewed-by:
Sage Weil <sage@inktank.com> Signed-off-by:
-
Yan, Zheng authored
commit fc55d2c9 upstream. We also need to wake up 'safe' waiters if error occurs or request aborted. Otherwise sync(2)/fsync(2) may hang forever. Signed-off-by:
Yan, Zheng <zheng.z.yan@intel.com> Signed-off-by:
-
Yan, Zheng authored
commit eb1b8af3 upstream. Aborted requests usually get cleared when the reply is received. If MDS crashes, no reply will be received. So we need to cleanup aborted requests when re-sending requests. Signed-off-by:
Greg Farnum <greg@inktank.com> Signed-off-by:
-
Milosz Tanski authored
commit ffc79664 upstream. In some cases I'm on my ceph client cluster I'm seeing hunk kernel tasks in the invalidate page code path. This is due to the fact that we don't check if the page is marked as cache before calling fscache_wait_on_page_write(). This is the log from the hang INFO: task XXXXXX:12034 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. ... Call Trace: [<ffffffff81568d09>] schedule+0x29/0x70 [<ffffffffa01d4cbd>] __fscache_wait_on_page_write+0x6d/0xb0 [fscache] [<ffffffff81083520>] ? add_wait_queue+0x60/0x60 [<ffffffffa029a3e9>] ceph_invalidate_fscache_page+0x29/0x50 [ceph] [<ffffffffa027df00>] ceph_invalidatepage+0x70/0x190 [ceph] [<ffffffff8112656f>] ? delete_from_page_cache+0x5f/0x70 [<ffffffff81133cab>] truncate_inode_page+0x8b/0x90 [<ffffffff81133ded>] truncate_inode_pages_range.part.12+0x13d/0x620 [<ffffffff8113431d>] truncate_inode_pages_range+0x4d/0x60 [<ffffffff811343b5>] truncate_inode_pages+0x15/0x20 [<ffffffff8119bbf6>] evict+0x1a6/0x1b0 [<ffffffff8119c3f3>] iput+0x103/0x190 ... Signed-off-by:
-
Johan Hovold authored
commit 6f648546 upstream. Fix race in generic write implementation, which could lead to temporarily degraded throughput. The current generic write implementation introduced by commit 27c7acf2 ("USB: serial: reimplement generic fifo-based writes") has always had this bug, although it's fairly hard to trigger and the consequences are not likely to be noticed. Specifically, a write() on one CPU while the completion handler is running on another could result in only one of the two write urbs being utilised to empty the remainder of the write fifo (unless there is a second write() that doesn't race during that time). Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
- 20 Dec, 2013 13 commits
-
-
Greg Kroah-Hartman authored
-
Roger Quadros authored
commit 313a76ee upstream. In _ocp_softreset(), after _set_softreset() + write_sysconfig(), the hwmod's sysc_cache will always contain SOFTRESET bit set so all further writes to sysconfig using this cache will initiate a repeated SOFTRESET e.g. enable_sysc(). This is true for OMAP3 like platforms that have RESET_DONE status in the SYSSTATUS register and so the the SOFTRESET bit in SYSCONFIG is not automatically cleared. It is not a problem for OMAP4 like platforms that indicate RESET completion by clearing the SOFTRESET bit in the SYSCONFIG register. This repeated SOFTRESET is undesired and was the root cause of USB host issues on OMAP3 platforms when hwmod was allowed to do the SOFTRESET for the USB Host module. To fix this we clear the SOFTRESET bit and update the sysconfig register + sysc_cache using write_sysconfig(). Signed-off-by:
Roger Quadros <rogerq@ti.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> # Panda, BeagleXM [paul@pwsan.com: renamed _clr_softreset() to _clear_softreset()] Signed-off-by:
Paul Walmsley <paul@pwsan.com> Signed-off-by:
-
Chris Wilson authored
commit 662c6ecb upstream. With some divider values we end up with the wrong result. So remove the intermediates (like Ville suggested in the first place) to get the right answer. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jesse Barnes authored
commit acbec814 upstream. Calculation is a little different than other platforms. v2: update to use port_clock instead rebase on top of Ville's changes v3: update to new port_clock semantics - don't divide by pixel_multiplier (Ville) References: https://bugs.freedesktop.org/show_bug.cgi?id=67345Signed-off-by:
-
Jesse Barnes authored
commit f6071166 upstream. The global integrated clock source bit resides in DPLL B on VLV, but we were treating it as a per-pipe resource. It needs to be set whenever any PLL is active, so pull setting the bit out of vlv_update_pll and into vlv_enable_pll. Also add a vlv_disable_pll to prevent disabling it when pipe B shuts down. I'm guessing on the references here, I expect this to bite any config where multiple displays are active or displays are moved from pipe to pipe. v2: re-add bits in vlv_update_pll to keep from confusing the state checker v3: use enum pipe checks (Daniel) set CRI clock source early (Ville) consistently set CRI clock source everywhere (Ville) v4: drop unnecessary setting of bit in vlv enable pll (Ville) References: https://bugs.freedesktop.org/show_bug.cgi?id=67245 References: https://bugs.freedesktop.org/show_bug.cgi?id=69693Signed-off-by:
-
Liu Bo authored
commit b1a06a4b upstream. Lockdep complains about btrfs's async commit: [ 2372.462171] [ BUG: bad unlock balance detected! ] [ 2372.462191] 3.12.0+ #32 Tainted: G W [ 2372.462209] ------------------------------------- [ 2372.462228] ceph-osd/14048 is trying to release lock (sb_internal) at: [ 2372.462275] [<ffffffffa022cb10>] btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs] [ 2372.462305] but there are no more locks to release! [ 2372.462324] [ 2372.462324] other info that might help us debug this: [ 2372.462349] no locks held by ceph-osd/14048. [ 2372.462367] [ 2372.462367] stack backtrace: [ 2372.462386] CPU: 2 PID: 14048 Comm: ceph-osd Tainted: G W 3.12.0+ #32 [ 2372.462414] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080015 11/09/2011 [ 2372.462455] ffffffffa022cb10 ffff88007490fd28 ffffffff816f094a ffff8800378aa320 [ 2372.462491] ffff88007490fd50 ffffffff810adf4c ffff8800378aa320 ffff88009af97650 [ 2372.462526] ffffffffa022cb10 ffff88007490fd88 ffffffff810b01ee ffff8800898c0000 [ 2372.462562] Call Trace: [ 2372.462584] [<ffffffffa022cb10>] ? btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs] [ 2372.462619] [<ffffffff816f094a>] dump_stack+0x45/0x56 [ 2372.462642] [<ffffffff810adf4c>] print_unlock_imbalance_bug+0xec/0x100 [ 2372.462677] [<ffffffffa022cb10>] ? btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs] [ 2372.462710] [<ffffffff810b01ee>] lock_release+0x18e/0x210 [ 2372.462742] [<ffffffffa022cb36>] btrfs_commit_transaction_async+0x1d6/0x2a0 [btrfs] [ 2372.462783] [<ffffffffa025a7ce>] btrfs_ioctl_start_sync+0x3e/0xc0 [btrfs] [ 2372.462822] [<ffffffffa025f1d3>] btrfs_ioctl+0x4c3/0x1f70 [btrfs] [ 2372.462849] [<ffffffff812c0321>] ? avc_has_perm+0x121/0x1b0 [ 2372.462873] [<ffffffff812c0224>] ? avc_has_perm+0x24/0x1b0 [ 2372.462897] [<ffffffff8107ecc8>] ? sched_clock_cpu+0xa8/0x100 [ 2372.462922] [<ffffffff8117b145>] do_vfs_ioctl+0x2e5/0x4e0 [ 2372.462946] [<ffffffff812c19e6>] ? file_has_perm+0x86/0xa0 [ 2372.462969] [<ffffffff8117b3c1>] SyS_ioctl+0x81/0xa0 [ 2372.462991] [<ffffffff817045a4>] tracesys+0xdd/0xe2 ==================================================== It's because that we don't do the right thing when checking if it's ok to tell lockdep that we're trying to release the rwsem. If the trans handle's type is TRANS_ATTACH, we won't acquire the freeze rwsem, but as TRANS_ATTACH fits the check (trans < TRANS_JOIN_NOLOCK), we'll release the freeze rwsem, which makes lockdep complains a lot. Reported-by:
Ma Jianpeng <majianpeng@gmail.com> Signed-off-by:
Liu Bo <bo.li.liu@oracle.com> Signed-off-by:
Miao Xie <miaox@cn.fujitsu.com> Signed-off-by:
Josef Bacik <jbacik@fusionio.com> Signed-off-by:
Chris Mason <chris.mason@fusionio.com> Signed-off-by:
-
Liu Bo authored
commit 48ec4736 upstream. Running balance and defrag concurrently can end up with a crash: kernel BUG at fs/btrfs/relocation.c:4528! RIP: 0010:[<ffffffffa01ac33b>] [<ffffffffa01ac33b>] btrfs_reloc_cow_block+ 0x1eb/0x230 [btrfs] Call Trace: [<ffffffffa01398c1>] ? update_ref_for_cow+0x241/0x380 [btrfs] [<ffffffffa0180bad>] ? copy_extent_buffer+0xad/0x110 [btrfs] [<ffffffffa0139da1>] __btrfs_cow_block+0x3a1/0x520 [btrfs] [<ffffffffa013a0b6>] btrfs_cow_block+0x116/0x1b0 [btrfs] [<ffffffffa013ddad>] btrfs_search_slot+0x43d/0x970 [btrfs] [<ffffffffa0153c57>] btrfs_lookup_file_extent+0x37/0x40 [btrfs] [<ffffffffa0172a5e>] __btrfs_drop_extents+0x11e/0xae0 [btrfs] [<ffffffffa013b3fd>] ? generic_bin_search.constprop.39+0x8d/0x1a0 [btrfs] [<ffffffff8117d14a>] ? kmem_cache_alloc+0x1da/0x200 [<ffffffffa0138e7a>] ? btrfs_alloc_path+0x1a/0x20 [btrfs] [<ffffffffa0173ef0>] btrfs_drop_extents+0x60/0x90 [btrfs] [<ffffffffa016b24d>] relink_extent_backref+0x2ed/0x780 [btrfs] [<ffffffffa0162fe0>] ? btrfs_submit_bio_hook+0x1e0/0x1e0 [btrfs] [<ffffffffa01b8ed7>] ? iterate_inodes_from_logical+0x87/0xa0 [btrfs] [<ffffffffa016b909>] btrfs_finish_ordered_io+0x229/0xac0 [btrfs] [<ffffffffa016c3b5>] finish_ordered_fn+0x15/0x20 [btrfs] [<ffffffffa018cbe5>] worker_loop+0x125/0x4e0 [btrfs] [<ffffffffa018cac0>] ? btrfs_queue_worker+0x300/0x300 [btrfs] [<ffffffff81075ea0>] kthread+0xc0/0xd0 [<ffffffff81075de0>] ? insert_kthread_work+0x40/0x40 [<ffffffff8164796c>] ret_from_fork+0x7c/0xb0 [<ffffffff81075de0>] ? insert_kthread_work+0x40/0x40 ---------------------------------------------------------------------- It turns out to be that balance operation will bump root's @last_snapshot, which enables snapshot-aware defrag path, and backref walking stuff will find data reloc tree as refs' parent, and hit the BUG_ON() during COW. As data reloc tree's data is just for relocation purpose, and will be deleted right after relocation is done, it's unnecessary to walk those refs belonged to data reloc tree, it'd be better to skip them. Signed-off-by:
-
Liu Bo authored
commit 6f519564 upstream. If something wrong happens in write endio, running snapshot-aware defragment can end up with undefined results, maybe a crash, so we should avoid it. In order to share similar code, this also adds a helper to free the struct for snapshot-aware defrag. Signed-off-by:
-
Josef Bacik authored
commit 93858769 upstream. A user reported a list corruption warning from btrfs_remove_ordered_extent, it is because we aren't taking the ordered_root_lock when we remove the inode from the ordered operations list. Thanks, Signed-off-by:
-
Josef Bacik authored
commit ed259095 upstream. Apparently we don't actually close the files until we return to userspace, so stop using vfs_read in send. This is actually better for us since we can avoid all the extra logic of holding the file we're sending open and making sure to clean it up. This will fix people who have been hitting too many files open errors when trying to send. Thanks, Signed-off-by:
-
Filipe David Borba Manana authored
commit 8185554d upstream. When a directory has a default ACL and a subdirectory is created under that directory, btrfs_init_acl() is called when the subdirectory's inode is created to initialize the inode's ACL (inherited from the parent directory) but it was clearing the ACL from the inode after setting it if posix_acl_create() returned success, instead of clearing it only if it returned an error. To reproduce this issue: $ mkfs.btrfs -f /dev/loop0 $ mount /dev/loop0 /mnt $ mkdir /mnt/acl $ setfacl -d --set u::rwx,g::rwx,o::- /mnt/acl $ getfacl /mnt/acl user::rwx group::rwx other::r-x default:user::rwx default:group::rwx default:other::--- $ mkdir /mnt/acl/dir1 $ getfacl /mnt/acl/dir1 user::rwx group::rwx other::--- After unmounting and mounting again the filesystem, fgetacl returned the expected ACL: $ umount /mnt/acl $ mount /dev/loop0 /mnt $ getfacl /mnt/acl/dir1 user::rwx group::rwx other::--- default:user::rwx default:group::rwx default:other::--- Meaning that the underlying xattr was persisted. Reported-by:
Giuseppe Fierro <giuseppe@fierro.org> Signed-off-by:
Filipe David Borba Manana <fdmanana@gmail.com> Signed-off-by:
-
Josef Bacik authored
commit ed9e8af8 upstream. I added an assert to make sure we were looking up aligned offsets for csums and I tripped it when running xfstests. This is because log_one_extent was checking if block_start == 0 for a hole instead of EXTENT_MAP_HOLE. This worked out fine in practice it seems, but it adds a lot of extra work that is uneeded. With this fix I'm no longer tripping my assert. Thanks, Signed-off-by:
-
Liu Bo authored
commit 7d3d1744 upstream. As we're hold a ref on looking up the extent map, we need to drop the ref before returning to callers. Signed-off-by:
-
