- 03 Oct, 2011 15 commits
-
-
Andrew Bird authored
commit 0e69d75c upstream. This patch adds the product ID of Huawei's Vodafone K3806 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by cdc_ether. Signed-off-by:
Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by:
Alex Chiang <achiang@canonical.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Yulgon Kim authored
commit e5d3d446 upstream. This patch fixes a NULL pointer deference. A NULL pointer dereference happens since s5p_ehci->hcd field is not initialized yet in probe function. [jg1.han@samsung.com: edit commit message] Signed-off-by:
Yulgon Kim <yulgon.kim@samsung.com> Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Jean-Christophe PLAGNIOL-VILLARD authored
commit c96fbdd0 upstream. Calao use on there dev kits a FT2232 where the port 0 is used for the JTAG and port 1 for the UART They use the same VID and PID as FTDI Chip but they program the manufacturer name in the eeprom So use this information to detect it Signed-off-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Cc: Gregory Hermant <gregory.hermant@calao-systems.com> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Jiri Slaby authored
commit 24d406a6 upstream. tty_operations->remove is normally called like: queue_release_one_tty ->tty_shutdown ->tty_driver_remove_tty ->tty_operations->remove However tty_shutdown() is called from queue_release_one_tty() only if tty_operations->shutdown is NULL. But for pty, it is not. pty_unix98_shutdown() is used there as ->shutdown. So tty_operations->remove of pty (i.e. pty_unix98_remove()) is never called. This results in invalid pty_count. I.e. what can be seen in /proc/sys/kernel/pty/nr. I see this was already reported at: https://lkml.org/lkml/2009/11/5/370 But it was not fixed since then. This patch is kind of a hackish way. The problem lies in ->install. We allocate there another tty (so-called tty->link). So ->install is called once, but ->remove twice, for both tty and tty->link. The fix here is to count both tty and tty->link and divide the count by 2 for user. And to have ->remove called, let's make tty_driver_remove_tty() global and call that from pty_unix98_shutdown() (tty_operations->shutdown). While at it, let's document that when ->shutdown is defined, tty_shutdown() is not called. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
-
Axel Lin authored
commit 8c4074cd upstream. Since commit e0626e38 (spi: prefix modalias with "spi:"), the spi modalias is prefixed with "spi:". This patch adds "spi:" prefix and removes "-spi" suffix in the modalias. Signed-off-by:
Axel Lin <axel.lin@gmail.com> Signed-off-by:
-
Al Cooper authored
commit dbb3b1ca upstream. This is to fix an issue where output will suddenly become very slow. The problem occurs on 8250 UARTS with the hardware bug UART_BUG_THRE. BACKGROUND For normal UARTs (without UART_BUG_THRE): When the serial core layer gets new transmit data and the transmitter is idle, it buffers the data and calls the 8250s' serial8250_start_tx() routine which will simply enable the TX interrupt in the IER register and return. This should immediately fire a THRE interrupt and begin transmitting the data. For buggy UARTs (with UART_BUG_THRE): merely enabling the TX interrupt in IER does not necessarily generate a new THRE interrupt. Therefore, a background timer periodically checks to see if there is pending data, and starts transmission if that is the case. The bug happens on SMP systems when the system has nothing to transmit, the transmit interrupt is disabled and the following sequence occurs: - CPU0: The background timer routine serial8250_backup_timeout() starts and saves the state of the interrupt enable register (IER) and then disables all interrupts in IER. NOTE: The transmit interrupt (TI) bit is saved as disabled. - CPU1: The serial core gets data to transmit, grabs the port lock and calls serial8250_start_tx() which enables the TI in IER. - CPU0: serial8250_backup_timeout() waits for the port lock. - CPU1: finishes (with TI enabled) and releases the port lock. - CPU0: serial8250_backup_timeout() calls the interrupt routine which will transmit the next fifo's worth of data and then restores the IER from the previously saved value (TI disabled). At this point, as long as the serial core has more transmit data buffered, it will not call serial8250_start_tx() again and the background timer routine will slowly transmit the data. The fix is to have serial8250_start_tx() get the port lock before it saves the IER state and release it after restoring IER. This will prevent serial8250_start_tx() from running in parallel. Signed-off-by:
Al Cooper <alcooperx@gmail.com> Signed-off-by:
-
Eric Smith authored
commit 44178176 upstream. This patch adds support for the Rosewill RC-305 four-port PCI serial card, and probably any other four-port serial cards based on the Moschip MCS9865 chip, assuming that the EEPROM on the card was programmed in accordance with Table 6 of the MCS9865 EEPROM Application Note version 0.3 dated 16-May-2008, available from the Moschip web site (registration required). This patch is based on an earlier patch [1] for the SYBA 6x serial port card by Ira W. Snyder. [1]: http://www.gossamer-threads.com/lists/linux/kernel/1162435Signed-off-by:
Eric Smith <eric@brouhaha.com> Signed-off-by:
-
Bjorn Helgaas authored
commit ab8ba3a2 upstream. It would have been nice if Intermec had supplied a PNP0501 _CID for the COM3 device, but they didn't, so we have to recognize it explicitly. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=40612 CC: Jeff Chua <jeff.chua.linux@gmail.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Nick Pelly authored
commit b280a97d upstream. Fixes logic bug that software flow control cannot be disabled, because serial_omap_configure_xonxoff() is not called if both IXON and IXOFF bits are cleared. Signed-off-by:
Nick Pelly <npelly@google.com> Acked-by:
Govindraj.R <govindraj.raja@ti.com> Tested-by:
-
Scott Jiang authored
commit 95c93d85 upstream. dac word len value should left shift before setting Signed-off-by:
Scott Jiang <scott.jiang.linux@gmail.com> Acked-by:
Barry Song <21cnbao@gmail.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Scott Jiang authored
commit bf545ed7 upstream. fix dac word len mask and adc tdm fmt shift value Signed-off-by:
-
Axel Lin authored
commit d2b4c7bd upstream. request_any_context_irq() returns a negative value on failure. On success, it returns either IRQC_IS_HARDIRQ or IRQC_IS_NESTED. Signed-off-by:
-
Liu Gang-B34182 authored
commit 671ee7f0 upstream. This bug causes the IECSR register clear failure. In this case, the RETE (retry error threshold exceeded) interrupt will be generated and cannot be cleared. So the related ISR may be called persistently. The RETE bit in IECSR is cleared by writing a 1 to it. Signed-off-by:
Liu Gang <Gang.Liu@freescale.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Kumar Gala <galak@kernel.crashing.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Alexandre Bounine authored
commit 284fb68d upstream. Replace/remove use of RIO v.1.2 registers/bits that are not forward-compatible with newer versions of RapidIO specification. RapidIO specification v.1.3 removed Write Port CSR, Doorbell CSR, Mailbox CSR and Mailbox and Doorbell bits of the PEF CAR. Use of removed (since RIO v.1.3) register bits affects users of currently available 1.3 and 2.x compliant devices who may use not so recent kernel versions. Removing checks for unsupported bits makes corresponding routines compatible with all versions of RapidIO specification. Therefore, backporting makes stable kernel versions compliant with RIO v.1.3 and later as well. Signed-off-by:
Alexandre Bounine <alexandre.bounine@idt.com> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Li Yang <leoli@freescale.com> Cc: Thomas Moll <thomas.moll@sysgo.com> Cc: Chul Kim <chul.kim@idt.com> Signed-off-by:
-
Nishanth Aravamudan authored
commit 4c30c6f5 upstream. It seems that 7bf69395 ("console: allow to retain boot console via boot option keep_bootcon") doesn't always achieve what it aims, as when printk_late_init() runs it unconditionally turns off all boot consoles. With this patch, I am able to see more messages on the boot console in KVM guests than I can without, when keep_bootcon is specified. I think it is appropriate for the relevant -stable trees. However, it's more of an annoyance than a serious bug (ideally you don't need to keep the boot console around as console handover should be working -- I was encountering a situation where the console handover wasn't working and not having the boot console available meant I couldn't see why). Signed-off-by:
Nishanth Aravamudan <nacc@us.ibm.com> Cc: David S. Miller <davem@davemloft.net> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Greg KH <gregkh@suse.de> Acked-by:
Fabio M. Di Nitto <fdinitto@redhat.com> Signed-off-by:
-
- 29 Aug, 2011 25 commits
-
-
Greg Kroah-Hartman authored
-
Andi Kleen authored
commit be27425d upstream. I ran into a couple of programs which broke with the new Linux 3.0 version. Some of those were binary only. I tried to use LD_PRELOAD to work around it, but it was quite difficult and in one case impossible because of a mix of 32bit and 64bit executables. For example, all kind of management software from HP doesnt work, unless we pretend to run a 2.6 kernel. $ uname -a Linux svivoipvnx001 3.0.0-08107-g97cd98f #1062 SMP Fri Aug 12 18:11:45 CEST 2011 i686 i686 i386 GNU/Linux $ hpacucli ctrl all show Error: No controllers detected. $ rpm -qf /usr/sbin/hpacucli hpacucli-8.75-12.0 Another notable case is that Python now reports "linux3" from sys.platform(); which in turn can break things that were checking sys.platform() == "linux2": https://bugzilla.mozilla.org/show_bug.cgi?id=664564 It seems pretty clear to me though it's a bug in the apps that are using '==' instead of .startswith(), but this allows us to unbreak broken programs. This patch adds a UNAME26 personality that makes the kernel report a 2.6.40+x version number instead. The x is the x in 3.x. I know this is somewhat ugly, but I didn't find a better workaround, and compatibility to existing programs is important. Some programs also read /proc/sys/kernel/osrelease. This can be worked around in user space with mount --bind (and a mount namespace) To use: wget ftp://ftp.kernel.org/pub/linux/kernel/people/ak/uname26/uname26.c gcc -o uname26 uname26.c ./uname26 program Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Carolyn Wyborny authored
commit 064b4330 upstream. Register writes followed by a delay are required to have a flush before the delay in order to commit the values to the register. Without the flush, the code following the delay may not function correctly. Reported-by:
Tong Ho <tong.ho@ericsson.com> Reported-by:
Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by:
Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Aaron Lu authored
commit 78869618 upstream. Currently, the retuning timer for retuning mode 1 will be deleted in function sdhci_tasklet_finish after a mmc request done, which will make retuning timing never trigger again. This patch fixed this problem. Signed-off-by:
Aaron Lu <Aaron.Lu@amd.com> Reviewed-by:
Philip Rakity <prakity@marvell.com> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
Stanislaw Gruszka authored
commit df71c9cf upstream. In rt2800usb_work_txdone we check flags in order: - ENTRY_OWNER_DEVICE_DATA - ENTRY_DATA_STATUS_PENDING - ENTRY_DATA_IO_FAILED Modify flags in separate order in rt2x00usb_interrupt_txdone, to avoid processing entries in _txdone with wrong flags or skip processing ready entries. Reported-by:
Justin Piszcz <jpiszcz@lucidpixels.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Miklos Szeredi authored
commit c2183d1e upstream. FUSE_NOTIFY_INVAL_ENTRY didn't check the length of the write so the message processing could overrun and result in a "kernel BUG at fs/fuse/dev.c:629!" Reported-by:
Han-Wen Nienhuys <hanwenn@gmail.com> Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
-
Thomas Reim authored
commit f2b60717 upstream. Toshiba Satellite L300D with ATI Mobility Radeon X1100 sends data to i2c bus for a HDMI connector that is not implemented/existent on the notebook's board. Fix by applying extented DDC probing for this connector. Requires [PATCH] drm/radeon: Extended DDC Probing for Connectors with Improperly Wired DDC Lines Tested for kernel 2.6.38 on Toshiba Satellite L300D notebook BugLink: http://bugs.launchpad.net/bugs/826677Signed-off-by:
Thomas Reim <reimth@gmail.com> Acked-by:
Chris Routh <routhy@gmail.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Marcin Slusarz authored
commit 7c4c3960 upstream. ttm_tt_destroy kfrees passed object, so we need to nullify a reference to it. Signed-off-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
-
Jack Steiner authored
commit 05e33fc2 upstream. Delete the 10 msec delay between the INIT and SIPI when starting slave cpus. I can find no requirement for this delay. BIOS also has similar code sequences without the delay. Removing the delay reduces boot time by 40 sec. Every bit helps. Signed-off-by:
Jack Steiner <steiner@sgi.com> Link: http://lkml.kernel.org/r/20110805140900.GA6774@sgi.comSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
H. Peter Anvin authored
commit 7ca0758c upstream. When we enter a 32-bit system call via SYSENTER or SYSCALL, we shuffle the arguments to match the int $0x80 calling convention. This was probably a design mistake, but it's what it is now. This causes errors if the system call as to be restarted. For SYSENTER, we have to invoke the instruction from the vdso as the return address is hardcoded. Accordingly, we can simply replace the jump in the vdso with an int $0x80 instruction and use the slower entry point for a post-restart. Suggested-by:
H. Peter Anvin <hpa@linux.intel.com> Link: http://lkml.kernel.org/r/CA%2B55aFztZ=r5wa0x26KJQxvZOaQq8s2v3u50wCyJcA-Sc4g8gQ@mail.gmail.comSigned-off-by:
-
Paul Fox authored
commit a3ea14df upstream. When executing EC commands, only waiting when there are still more bytes to write is usually fine. However, if the system suspends very quickly after a call to olpc_ec_cmd(), the last data byte may not yet be transferred to the EC, and the command will not complete. This solves a bug where the SCI wakeup mask was not correctly written when going into suspend. It means that sometimes, on XO-1.5 (but not XO-1), the devices that were marked as wakeup sources can't wake up the system. e.g. you ask for wifi wakeups, suspend, but then incoming wifi frames don't wake up the system as they should. Signed-off-by:
Paul Fox <pgf@laptop.org> Signed-off-by:
Daniel Drake <dsd@laptop.org> Acked-by:
Andres Salomon <dilinger@queued.net> Signed-off-by:
-
Stefano Stabellini authored
commit 3c05c4be upstream. Fix regression for HVM case on older (<4.1.1) hypervisors caused by commit 99bbb3a8 Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Date: Thu Dec 2 17:55:10 2010 +0000 xen: PV on HVM: support PV spinlocks and IPIs This change replaced the SMP operations with event based handlers without taking into account that this only works when the hypervisor supports callback vectors. This causes unexplainable hangs early on boot for HVM guests with more than one CPU. BugLink: http://bugs.launchpad.net/bugs/791850Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Stefano Stabellini <stefano.stabellini@eu.citrix.com> Tested-and-Reported-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Jan Beulich authored
commit ccbcdf7c upstream. The order-based approach is not only less efficient (requiring a shift and a compare, typical generated code looking like this mov eax, [machine_to_phys_order] mov ecx, eax shr ebx, cl test ebx, ebx jnz ... whereas a direct check requires just a compare, like in cmp ebx, [machine_to_phys_nr] jae ... ), but also slightly dangerous in the 32-on-64 case - the element address calculation can wrap if the next power of two boundary is sufficiently far away from the actual upper limit of the table, and hence can result in user space addresses being accessed (with it being unknown what may actually be mapped there). Additionally, the elimination of the mistaken use of fls() here (should have been __fls()) fixes a latent issue on x86-64 that would trigger if the code was run on a system with memory extending beyond the 44-bit boundary. Signed-off-by:
Jan Beulich <jbeulich@novell.com> [v1: Based on Jeremy's feedback] Signed-off-by:
-
Stefan Bader authored
commit 89153b5c upstream. Avoid telling users to use xvde and onwards when using xvde. Acked-by:
-
Stefan Bader authored
commit 196cfe2a upstream. These were intended to avoid the namespace clash when representing emulated IDE and SCSI devices. However that seems to confuse users more than expected (a disk defined as sda becomes xvde). So for now go back to the scheme which does no adjustments. This will break when mixing IDE and SCSI names in the configuration of guests but should be by now expected. Acked-by:
-
Theodore Ts'o authored
commit 9dd75f1f upstream. Bug discovered by Jan Kara: Finally, commit 1449032b returned back the old IO submission code but apparently it forgot to return the old handling of uninitialized buffers so we unconditionnaly call block_write_full_page() without specifying end_io function. So AFAICS we never convert unwritten extents to written in some cases. For example when I mount the fs as: mount -t ext4 -o nomblk_io_submit,dioread_nolock /dev/ubdb /mnt and do int fd = open(argv[1], O_RDWR | O_CREAT | O_TRUNC, 0600); char buf[1024]; memset(buf, 'a', sizeof(buf)); fallocate(fd, 0, 0, 16384); write(fd, buf, sizeof(buf)); I get a file full of zeros (after remounting the filesystem so that pagecache is dropped) instead of seeing the first KB contain 'a's. Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Tao Ma authored
commit 32c80b32 upstream. EXT4_IO_END_UNWRITTEN flag set and the increase of i_aiodio_unwritten should be done simultaneously since ext4_end_io_nolock always clear the flag and decrease the counter in the same time. We don't increase i_aiodio_unwritten when setting EXT4_IO_END_UNWRITTEN so it will go nagative and causes some process to wait forever. Part of the patch came from Eric in his e-mail, but it doesn't fix the problem met by Michael actually. http://marc.info/?l=linux-ext4&m=131316851417460&w=2 Reported-and-Tested-by: Michael Tokarev<mjt@tls.msk.ru> Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
Tao Ma <boyu.mt@taobao.com> Signed-off-by:
-
Jiaying Zhang authored
commit 2581fdc8 upstream. Flush inode's i_completed_io_list before calling ext4_io_wait to prevent the following deadlock scenario: A page fault happens while some process is writing inode A. During page fault, shrink_icache_memory is called that in turn evicts another inode B. Inode B has some pending io_end work so it calls ext4_ioend_wait() that waits for inode B's i_ioend_count to become zero. However, inode B's ioend work was queued behind some of inode A's ioend work on the same cpu's ext4-dio-unwritten workqueue. As the ext4-dio-unwritten thread on that cpu is processing inode A's ioend work, it tries to grab inode A's i_mutex lock. Since the i_mutex lock of inode A is still hold before the page fault happened, we enter a deadlock. Also moves ext4_flush_completed_IO and ext4_ioend_wait from ext4_destroy_inode() to ext4_evict_inode(). During inode deleteion, ext4_evict_inode() is called before ext4_destroy_inode() and in ext4_evict_inode(), we may call ext4_truncate() without holding i_mutex lock. As a result, there is a race between flush_completed_IO that is called from ext4_ext_truncate() and ext4_end_io_work, which may cause corruption on an io_end structure. This change moves ext4_flush_completed_IO and ext4_ioend_wait from ext4_destroy_inode() to ext4_evict_inode() to resolve the race between ext4_truncate() and ext4_end_io_work during inode deletion. Signed-off-by:
Jiaying Zhang <jiayingz@google.com> Signed-off-by:
-
Curt Wohlgemuth authored
commit 441c8508 upstream. ext4_should_writeback_data() had an incorrect sequence of tests to determine if it should return 0 or 1: in particular, even in no-journal mode, 0 was being returned for a non-regular-file inode. This meant that, in non-journal mode, we would use ext4_journalled_aops for directories, symlinks, and other non-regular files. However, calling journalled aop callbacks when there is no valid handle, can cause problems. This would cause a kernel crash with Jan Kara's commit 2d859db3 ("ext4: fix data corruption in inodes with journalled data"), because we now dereference 'handle' in ext4_journalled_write_end(). I also added BUG_ONs to check for a valid handle in the obviously journal-only aops callbacks. I tested this running xfstests with a scratch device in these modes: - no-journal - data=ordered - data=writeback - data=journal All work fine; the data=journal run has many failures and a crash in xfstests 074, but this is no different from a vanilla kernel. Signed-off-by:
Curt Wohlgemuth <curtw@google.com> Signed-off-by:
-
Daniel T Chen authored
commit eade7b28 upstream. BugLink: https://bugs.launchpad.net/bugs/826081 The original reporter needs 'Headphone Jack Sense' enabled to have audible audio, so add his PCI SSID to the whitelist. Reported-and-tested-by: Muhammad Khurram Khan Signed-off-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Daniel Mack authored
commit da6094ea upstream. The snd_usb_caiaq driver currently assumes that output urbs are serviced in time and doesn't track when and whether they are given back by the USB core. That usually works fine, but due to temporary limitations of the XHCI stack, we faced that urbs were submitted more than once with this approach. As it's no good practice to fire and forget urbs anyway, this patch introduces a proper bit mask to track which requests have been submitted and given back. That alone however doesn't make the driver work in case the host controller is broken and doesn't give back urbs at all, and the output stream will stop once all pre-allocated output urbs are consumed. But it does prevent crashes of the controller stack in such cases. See http://bugzilla.kernel.org/show_bug.cgi?id=40702 for more details. Signed-off-by:
Daniel Mack <zonque@gmail.com> Reported-and-tested-by:
Matej Laitl <matej@laitl.cz> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Takashi Iwai authored
commit 38b65190 upstream. The recent fix for testing dB range at the mixer creation time seems to cause regressions in some devices. In such devices, reading the dB info at probing time gives an error, thus both dBmin and dBmax are still zero, and TLV flag isn't set although the later read of dB info succeeds. This patch adds a workaround for such a case by assuming that the later read will succeed. In future, a similar test should be performed in a case where a wrong dB range is seen even in the later read. Signed-off-by:
-
liubo authored
commit 34f3e4f2 upstream. When btrfs recovers from a crash, it may hit the oops below: ------------[ cut here ]------------ kernel BUG at fs/btrfs/inode.c:4580! [...] RIP: 0010:[<ffffffffa03df251>] [<ffffffffa03df251>] btrfs_add_link+0x161/0x1c0 [btrfs] [...] Call Trace: [<ffffffffa03e7b31>] ? btrfs_inode_ref_index+0x31/0x80 [btrfs] [<ffffffffa04054e9>] add_inode_ref+0x319/0x3f0 [btrfs] [<ffffffffa0407087>] replay_one_buffer+0x2c7/0x390 [btrfs] [<ffffffffa040444a>] walk_down_log_tree+0x32a/0x480 [btrfs] [<ffffffffa0404695>] walk_log_tree+0xf5/0x240 [btrfs] [<ffffffffa0406cc0>] btrfs_recover_log_trees+0x250/0x350 [btrfs] [<ffffffffa0406dc0>] ? btrfs_recover_log_trees+0x350/0x350 [btrfs] [<ffffffffa03d18b2>] open_ctree+0x1442/0x17d0 [btrfs] [...] This comes from that while replaying an inode ref item, we forget to check those old conflicting DIR_ITEM and DIR_INDEX items in fs/file tree, then we will come to conflict corners which lead to BUG_ON(). Signed-off-by:
Liu Bo <liubo2009@cn.fujitsu.com> Tested-by:
Andy Lutomirski <luto@mit.edu> Signed-off-by:
Chris Mason <chris.mason@oracle.com> Signed-off-by:
-
Kay Sievers authored
commit 05eb0f25 upstream. LOOP_CLR_FD takes lo->lo_ctl_mutex and tries to remove the loop sysfs files. Sysfs calls show() and waits for lo->lo_ctl_mutex. LOOP_CLR_FD waits for show() to finish to remove the sysfs file. cat /sys/class/block/loop0/loop/backing_file mutex_lock_nested+0x176/0x350 ? loop_attr_do_show_backing_file+0x2f/0xd0 [loop] ? loop_attr_do_show_backing_file+0x2f/0xd0 [loop] loop_attr_do_show_backing_file+0x2f/0xd0 [loop] dev_attr_show+0x1b/0x60 ? sysfs_read_file+0x86/0x1a0 ? __get_free_pages+0x12/0x50 sysfs_read_file+0xaf/0x1a0 ioctl(LOOP_CLR_FD): wait_for_common+0x12c/0x180 ? try_to_wake_up+0x2a0/0x2a0 wait_for_completion+0x18/0x20 sysfs_deactivate+0x178/0x180 ? sysfs_addrm_finish+0x43/0x70 ? sysfs_addrm_start+0x1d/0x20 sysfs_addrm_finish+0x43/0x70 sysfs_hash_and_remove+0x85/0xa0 sysfs_remove_group+0x59/0x100 loop_clr_fd+0x1dc/0x3f0 [loop] lo_ioctl+0x223/0x7a0 [loop] Instead of taking the lo_ctl_mutex from sysfs code, take the inner lo->lo_lock, to protect the access to the backing_file data. Thanks to Tejun for help debugging and finding a solution. Cc: Milan Broz <mbroz@redhat.com> Cc: Tejun Heo <tj@kernel.org> Signed-off-by:
Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
-
Josef Bacik authored
commit d5e2003c upstream. We have a problem where if a user specifies discard but doesn't actually support it we will return EOPNOTSUPP from btrfs_discard_extent. This is a problem because this gets called (in a fashion) from the tree log recovery code, which has a nice little BUG_ON(ret) after it, which causes us to fail the tree log replay. So instead detect wether our devices support discard when we're adding them and then don't issue discards if we know that the device doesn't support it. And just for good measure set ret = 0 in btrfs_issue_discard just in case we still get EOPNOTSUPP so we don't screw anybody up like this again. Thanks, Signed-off-by:
Josef Bacik <josef@redhat.com> Signed-off-by:
-
