- 13 Aug, 2010 40 commits
-
-
Eric Sandeen authored
commit 437f88cc upstream. Commit 6b0310fb caused a regression resulting in deadlocks when freezing a filesystem which had active IO; the vfs_check_frozen level (SB_FREEZE_WRITE) did not let the freeze-related IO syncing through. Duh. Changing the test to FREEZE_TRANS should let the normal freeze syncing get through the fs, but still block any transactions from starting once the fs is completely frozen. I tested this by running fsstress in the background while periodically snapshotting the fs and running fsck on the result. I ran into occasional deadlocks, but different ones. I think this is a fine fix for the problem at hand, and the other deadlocky things will need more investigation. Reported-by:
Phillip Susi <psusi@cfl.rr.com> Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alexander Shishkin authored
commit 0b767f96 upstream. By default, CONFIG_CRYPTO_MANAGER_TESTS will be enabled and thus self-tests will still run, but it is now possible to disable them to gain some time during bootup. Signed-off-by:
Alexander Shishkin <virtuoso@slind.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Ian Campbell authored
commit 4877c737 upstream. In general the semantics of IPIs are that they are are expected to continue functioning after dpm_suspend_noirq(). Specifically I have seen a deadlock between the callfunc IPI and the stop machine used by xen's do_suspend() routine. If one CPU has already called dpm_suspend_noirq() then there is a window where it can be sent a callfunc IPI before all the other CPUs have entered stop_cpu(). If this happens then the first CPU ends up spinning in stop_cpu() waiting for the other to rendezvous in state STOPMACHINE_PREPARE while the other is spinning in csd_lock_wait(). Signed-off-by:
Ian Campbell <ian.campbell@citrix.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: xen-devel@lists.xensource.com LKML-Reference: <1280398595-29708-4-git-send-email-ian.campbell@citrix.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Ian Campbell authored
commit 685fd0b4 upstream. A small number of users of IRQF_TIMER are using it for the implied no suspend behaviour on interrupts which are not timer interrupts. Therefore add a new IRQF_NO_SUSPEND flag, rename IRQF_TIMER to __IRQF_TIMER and redefine IRQF_TIMER in terms of these new flags. Signed-off-by:
-
David S. Miller authored
commit 38117d14 upstream. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Dave Kleikamp authored
commit aca0fa34 upstream. It's currently possible to bypass xattr namespace access rules by prefixing valid xattr names with "os2.", since the os2 namespace stores extended attributes in a legacy format with no prefix. This patch adds checking to deny access to any valid namespace prefix following "os2.". Signed-off-by:
Dave Kleikamp <shaggy@linux.vnet.ibm.com> Reported-by:
Sergey Vlasov <vsu@altlinux.ru> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
James Chapman authored
commit 4565956d upstream. The header file l2tp.h should be exported to the installed include/linux/ tree for userspace programs. This patch fixes compilation errors in L2TP userspace apps which want to use the new L2TP support introduced in 2.6.35. Signed-off-by:
James Chapman <jchapman@katalix.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Marek Vasut authored
commit 81cbb0b1 upstream. This patch corrects a problem where gen_nand driver assumed there can be only one chip and ignored the pdata->chip.nr_chips value. Signed-off-by:
Marek Vasut <marek.vasut@gmail.com> Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
Eric Bénard authored
commit 6a8cfcfb upstream. * preset should be done before sending the reset command * without this, I get the following error on an i.MX35 : [ 0.900000] ------------[ cut here ]------------ [ 0.900000] WARNING: at kernel/irq/manage.c:290 __enable_irq+0x4c/0x88() [ 0.900000] Unbalanced enable for IRQ 33 [ 0.900000] Modules linked in: [ 0.900000] [<c002ffb8>] (unwind_backtrace+0x0/0xf0) from [<c02f7d0c>] (dump_stack+0x18/0x1c) [ 0.900000] [<c02f7d0c>] (dump_stack+0x18/0x1c) from [<c0049a44>] (warn_slowpath_common+0x54/0x6c) [ 0.900000] [<c0049a44>] (warn_slowpath_common+0x54/0x6c) from [<c0049b00>] (warn_slowpath_fmt+0x38/0x40) [ 0.900000] [<c0049b00>] (warn_slowpath_fmt+0x38/0x40) from [<c008f65c>] (__enable_irq+0x4c/0x88) [ 0.900000] [<c008f65c>] (__enable_irq+0x4c/0x88) from [<c008fca0>] (enable_irq+0x54/0x98) [ 0.900000] [<c008fca0>] (enable_irq+0x54/0x98) from [<c021e618>] (wait_op_done+0x40/0x134) [ 0.900000] [<c021e618>] (wait_op_done+0x40/0x134) from [<c021e808>] (send_cmd+0x30/0x38) [ 0.900000] [<c021e808>] (send_cmd+0x30/0x38) from [<c021eb8c>] (mxc_nand_command+0x26c/0x328) [ 0.900000] [<c021eb8c>] (mxc_nand_command+0x26c/0x328) from [<c021aa60>] (nand_scan_ident+0x188/0x6c0) [ 0.900000] [<c021aa60>] (nand_scan_ident+0x188/0x6c0) from [<c001a9cc>] (mxcnd_probe+0x2b8/0x3d0) [ 0.900000] [<c001a9cc>] (mxcnd_probe+0x2b8/0x3d0) from [<c01f9e88>] (platform_drv_probe+0x20/0x24) [ 0.900000] [<c01f9e88>] (platform_drv_probe+0x20/0x24) from [<c01f8c38>] (driver_probe_device+0xb0/0x164) [ 0.900000] [<c01f8c38>] (driver_probe_device+0xb0/0x164) from [<c01f8d54>] (__driver_attach+0x68/0x8c) [ 0.900000] [<c01f8d54>] (__driver_attach+0x68/0x8c) from [<c01f8348>] (bus_for_each_dev+0x50/0x84) [ 0.900000] [<c01f8348>] (bus_for_each_dev+0x50/0x84) from [<c01f8a9c>] (driver_attach+0x20/0x28) [ 0.900000] [<c01f8a9c>] (driver_attach+0x20/0x28) from [<c01f7c00>] (bus_add_driver+0x144/0x2dc) [ 0.900000] [<c01f7c00>] (bus_add_driver+0x144/0x2dc) from [<c01f906c>] (driver_register+0xb0/0x13c) [ 0.900000] [<c01f906c>] (driver_register+0xb0/0x13c) from [<c01fa13c>] (platform_driver_register+0x4c/0x60) [ 0.900000] [<c01fa13c>] (platform_driver_register+0x4c/0x60) from [<c01fa170>] (platform_driver_probe+0x20/0xa0) [ 0.900000] [<c01fa170>] (platform_driver_probe+0x20/0xa0) from [<c001a708>] (mxc_nd_init+0x18/0x24) [ 0.900000] [<c001a708>] (mxc_nd_init+0x18/0x24) from [<c002938c>] (do_one_initcall+0x64/0x1bc) [ 0.900000] [<c002938c>] (do_one_initcall+0x64/0x1bc) from [<c00084c4>] (kernel_init+0xe8/0x1ac) [ 0.900000] [<c00084c4>] (kernel_init+0xe8/0x1ac) from [<c002aee8>] (kernel_thread_exit+0x0/0x8) [ 0.900000] ---[ end trace 8bf72ac6ba089a19 ]--- [ 1.140000] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron NAND 256MiB 3,3V 8-bit) Signed-off-by:
Eric Bénard <eric@eukrea.com> Signed-off-by:
-
Peter Zijlstra authored
commit 396e894d upstream. Norbert reported that nohz_ratelimit() causes his laptop to burn about 4W (40%) extra. For now back out the change and see if we can adjust the power management code to make better decisions. Reported-by:
Norbert Preining <preining@logic.at> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by:
Mike Galbraith <efault@gmx.de> Cc: Arjan van de Ven <arjan@infradead.org> LKML-Reference: <new-submission> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Cyril Lacoux authored
commit 0a79f674 upstream. Device class is ff(vend.) instead of e0(wlcon). Output from command `usb-devices`: T: Bus=01 Lev=03 Prnt=03 Port=00 Cnt=01 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=05ac ProdID=8215 Rev=01.82 S: Manufacturer=Apple Inc. S: Product=Bluetooth USB Host Controller S: SerialNumber=7C6D62936607 C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none) Signed-off-by:
Cyril Lacoux <clacoux@ifeelgood.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Johan Hovold authored
commit b58af406 upstream. As David VomLehn points out, it was possible to receive an interrupt before clearing the free-urb flag which could lead to the urb being incorrectly marked as busy. For the same reason, move tx_bytes accounting so that it will never be negative. Note that the free-flags set and clear operations do not need any additional locking as they are manipulated while USB_SERIAL_WRITE_BUSY is set. Reported-by:
David VomLehn <dvomlehn@cisco.com> Tested-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Christian Lamparter authored
commit b3e67044 upstream. This patch fixes a race condition in two utility routines related to the removal/unlinking of urbs from an anchor. If two threads are concurrently accessing the same anchor, both could end up with the same urb - thinking they are the exclusive owner. Alan Stern pointed out a related issue in usb_unlink_anchored_urbs: "The URB isn't removed from the anchor until it completes (as a by-product of completion, in fact), which might not be for quite some time after the unlink call returns. In the meantime, the subroutine will keep trying to unlink it, over and over again." Cc: Oliver Neukum <oneukum@suse.de> Cc: Greg Kroah-Hartman <greg@kroah.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Ming Lei authored
commit e10e1bec upstream. This patch fixes the warning below: [30753.755998] ------------[ cut here ]------------ [30753.755998] WARNING: at /home/tom/git/linux-2.6/linux-2.6-next/arch/x86/include/asm/dma-mapping.h:155 hcd_buffer_free+0xb1/0xd4 [usbcore]() [30753.755998] Hardware name: 6475EK2 [30753.755998] Modules linked in: uvcvideo ehci_hcd usbtest cdc_ether usbnet vfat fat usb_storage nfsd lockd nfs_acl auth_rpcgss exportfs mii tun videodev v4l1_compat v4l2_compat_ioctl32 fuse bridge stp llc sunrpc ipv6 cpufreq_ondemand acpi_cpufreq freq_table mperf kvm_intel kvm arc4 ecb ath5k usbhid mac80211 snd_hda_codec_conexant ch341 usbserial ath cfg80211 thinkpad_acpi snd_hda_intel pcspkr wmi hwmon yenta_socket iTCO_wdt iTCO_vendor_support i2c_i801 e1000e snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc pata_acpi uhci_hcd ohci_hcd usbcore i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: uvcvideo] [30753.755998] Pid: 0, comm: swapper Tainted: G W 2.6.35-rc6-gkh-wl+ #49 [30753.755998] Call Trace: [30753.755998] <IRQ> [<ffffffff8104478a>] warn_slowpath_common+0x80/0x98 [30753.755998] [<ffffffff810447b7>] warn_slowpath_null+0x15/0x17 [30753.755998] [<ffffffffa00ce02d>] hcd_buffer_free+0xb1/0xd4 [usbcore] [30753.755998] [<ffffffffa00c1345>] usb_free_coherent+0x1c/0x1e [usbcore] [30753.755998] [<ffffffffa00b13e4>] simple_free_urb+0x23/0x2f [usbtest] [30753.755998] [<ffffffffa00b210b>] iso_callback+0xbb/0x10f [usbtest] [30753.755998] [<ffffffffa00c7390>] usb_hcd_giveback_urb+0x8c/0xc0 [usbcore] [30753.755998] [<ffffffffa0449b35>] ehci_urb_done+0x84/0x95 [ehci_hcd] [30753.755998] [<ffffffffa044b5a5>] ehci_work+0x41a/0x7dd [ehci_hcd] [30753.755998] [<ffffffffa044e298>] ehci_irq+0x33b/0x370 [ehci_hcd] [30753.755998] [<ffffffff8100fb05>] ? sched_clock+0x9/0xd [30753.755998] [<ffffffff8105e641>] ? sched_clock_local+0x1c/0x82 [30753.755998] [<ffffffff8105e76a>] ? sched_clock_cpu+0xc3/0xce [30753.755998] [<ffffffff81067c7e>] ? trace_hardirqs_off+0xd/0xf [30753.755998] [<ffffffff8105e7b8>] ? cpu_clock+0x43/0x5e [30753.755998] [<ffffffffa00c6999>] usb_hcd_irq+0x45/0xa1 [usbcore] [30753.755998] [<ffffffff81092e02>] handle_IRQ_event+0x20/0xa5 [30753.755998] [<ffffffff81094cea>] handle_fasteoi_irq+0x92/0xd2 [30753.755998] [<ffffffff8100c0ed>] handle_irq+0x1f/0x2a [30753.755998] [<ffffffff8100b75d>] do_IRQ+0x57/0xbe [30753.755998] [<ffffffff8136a693>] ret_from_intr+0x0/0x16 [30753.755998] <EOI> [<ffffffff81223baa>] ? acpi_idle_enter_bm+0x231/0x269 [30753.755998] [<ffffffff81223ba3>] ? acpi_idle_enter_bm+0x22a/0x269 [30753.755998] [<ffffffff812c4b6b>] cpuidle_idle_call+0x99/0xce [30753.755998] [<ffffffff81008dd5>] cpu_idle+0x61/0xaa [30753.755998] [<ffffffff8136374b>] start_secondary+0x1c2/0x1c6 [30753.755998] ---[ end trace 904cfaf7ab4cb1a2 ]--- Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
-
Alessio Igor Bogani authored
commit 356c5a48 upstream. Signed-off-by:
Alessio Igor Bogani <abogani@texware.it> Signed-off-by:
-
dranch@trinnet.net authored
commit b6180ef7 upstream. This patch is to add a US Interface, Inc. "Navigator" USB device. Specifically, it's a HAM Radio USB sound modem that also incorporates three pairs of unique FTDI serial ports. The standard Linux FTDI serial driver will only recognize the first two serial ports of an unknown FDTI derived device and this patch adds in recognition to these specific new IDs. Signed-off-by:
David A. Ranch <dranch@trinnet.net> Signed-off-by:
-
Andrew Bird authored
commit 0372a754 upstream. This patch adds the product IDs of Huawei's K3765 and K4505 mobile broadband usb modems to option.c. It also adds a quirk to the option probe function so that binding to the device's network interface(class 0xff) is avoided. This is necessary to allow another driver to bind to that, and to avoid programs like wvdial opening a nonfunctioning tty during modem discovery. Signed-off-by:
Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by:
-
Pavel Kazlou authored
commit b972302b upstream. The patch adds Huawei ETS 1220 product id into the list of supported devices in 'option' usb serial driver. Signed-off-by:
Pavel Kazlou <p.i.kazlou@gmail.com> Signed-off-by:
-
John G. Rogers authored
commit afad1964 upstream. I have added the ProductID=0xe729 VendorID=FTDI_VID=0x0403 which will enable support for the Segway Robotic Mobility Platform (RMP200) in the ftdi_sio kernel module. Currently, users of the Segway RMP200 must use a RUN+="/sbin/modprobe -q ftdi-sio product=0xe729 vendor=0x0403 in a udev rule to get the ftdi_sio module to handle the usb interface and mount it on /dev/ttyXXX. This is not a good solution because some users will have multiple USB to Serial converters which will use the ftdi_sio module. Signed-off-by:
John Rogers <jgrogers@gmail.com> Signed-off-by:
-
Phil Dibowitz authored
commit 93362a87 upstream. The Logitech Harmony 700 series needs an extra delay during initialization. This patch adds a USB quirk which enables such a delay and adds the device to the quirks list. Signed-off-by:
Phil Dibowitz <phil@ipom.com> Signed-off-by:
-
Steven Robertson authored
commit 33d973ad upstream. Enlarging the buffer size via the MON_IOCT_RING_SIZE ioctl causes general protection faults. It appears the culprit is an incorrect argument to mon_free_buff: instead of passing the size of the current buffer being freed, the size of the new buffer is passed. Use the correct size argument to mon_free_buff when changing the size of the buffer. Signed-off-by:
Steven Robertson <steven@strobe.cc> Acked-by:
Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
-
Alan Stern authored
commit ae68a83b upstream. This patch (as1405) fixes a small bug in ehci-hcd's isochronous scheduler. Not all EHCI controllers are PCI, and the code shouldn't assume that they are. Instead, introduce a special flag for controllers which need to delay iso scheduling for full-speed devices beyond the scheduling threshold. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Anand Gadiyar authored
commit 0936fb5e upstream. DMA_ADDR and DMA_COUNT are 32-bit registers, not 16-bit. Marking them as 16-bit in the table causes only the lower 16-bits to be dumped and this is misleading. Signed-off-by:
Anand Gadiyar <gadiyar@ti.com> Acked-by:
Felipe Balbi <felipe.balbi@nokia.com> Signed-off-by:
Ajay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by:
-
Uwe Kleine-König authored
commit 868003ca upstream. This is a follow up to 14cb0deb (arm/imx/gpio: add spinlock protection) and fixes the following build failure: CC arch/arm/mach-imx/pcm970-baseboard.o In file included from arch/arm/include/asm/gpio.h:6, from include/linux/gpio.h:8, from arch/arm/mach-imx/pcm970-baseboard.c:20: arch/arm/plat-mxc/include/mach/gpio.h:40: error: expected specifier-qualifier-list before 'spinlock_t' Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Will Deacon authored
commit cdf357f1 upstream. On versions of the Cortex-A9 prior to r2p0, performing TLB invalidations by ASID match can result in the incorrect ASID being broadcast to other CPUs. As a consequence of this, the targetted TLB entries are not invalidated across the system. This workaround changes the TLB flushing routines to invalidate entries regardless of the ASID. Tested-by:
Rob Clark <rob@ti.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Catalin Marinas authored
commit 492c5d94 upstream. On SMP systems, the SMSC911x registers may be accessed by multiple CPUs and this seems to put the chip in an inconsistent state. The patch adds spinlocks to the smsc911x_reg_read, smsc911x_reg_write, smsc911x_rx_readfifo and smsc911x_tx_writefifo functions. Signed-off-by:
-
Igor Grinberg authored
commit a6cd7eb3 upstream. ffuart is available on cm-x300 only with pxa300. Signed-off-by:
Igor Grinberg <grinberg@compulab.co.il> Signed-off-by:
Eric Miao <eric.y.miao@gmail.com> Signed-off-by:
-
Nathan Lynch authored
commit a2a20c41 upstream. If signalfd is used to consume a signal generated by a POSIX interval timer or POSIX message queue, the ssi_int field does not reflect the data (sigevent->sigev_value) supplied to timer_create(2) or mq_notify(3). (The ssi_ptr field, however, is filled in.) This behavior differs from signalfd's treatment of sigqueue-generated signals -- see the default case in signalfd_copyinfo. It also gives results that differ from the case when a signal is handled conventionally via a sigaction-registered handler. So, set signalfd_siginfo->ssi_int in the remaining cases (__SI_TIMER, __SI_MESGQ) where ssi_ptr is set. akpm: a non-back-compatible change. Merge into -stable to minimise the number of kernels which are in the field and which miss this feature. Signed-off-by:
Nathan Lynch <ntl@pobox.com> Acked-by:
Davide Libenzi <davidel@xmailserver.org> Signed-off-by:
-
Tejun Heo authored
commit aca27ba9 upstream. Commit a82afdfc (block: use the same failfast bits for bio and request) moved BIO_RW_* bits around such that they match up with REQ_* bits. Unfortunately, fs.h hard coded RW_MASK, RWA_MASK, READ, WRITE, READA and SWRITE as 0, 1, 2 and 3, and expected them to match with BIO_RW_* bits. READ/WRITE didn't change but BIO_RW_AHEAD was moved to bit 4 instead of bit 1, breaking RWA_MASK, READA and SWRITE. This patch updates RWA_MASK, READA and SWRITE such that they match the BIO_RW_* bits again. A follow up patch will update the definitions to directly use BIO_RW_* bits so that this kind of breakage won't happen again. Neil also spotted missing RWA_MASK conversion. Stable: The offending commit a82afdfc was released with v2.6.32, so this patch should be applied to all kernels since then but it must _NOT_ be applied to kernels earlier than that. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-and-bisected-by:
Vladislav Bolkhovitin <vst@vlnb.net> Root-caused-by:
Neil Brown <neilb@suse.de> Signed-off-by:
Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
-
Philipp Reisner authored
commit 6710a576 upstream. Signed-off-by:
Philipp Reisner <philipp.reisner@linbit.com> Signed-off-by:
Lars Ellenberg <lars.ellenberg@linbit.com> Signed-off-by:
-
Philipp Reisner authored
commit 85f4cc17 upstream. Signed-off-by:
-
Julia Lawall authored
commit ceeab929 upstream. The comments in the code indicate that file_info should be released if the function fails. This releasing is done at the label out_free, not out. The semantic match that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @r exists@ local idexpression x; statement S; expression E; identifier f,f1,l; position p1,p2; expression *ptr != NULL; @@ x@p1 = kmem_cache_zalloc(...); ... if (x == NULL) S <... when != x when != if (...) { <+...x...+> } ( x->f1 = E | (x->f1 == NULL || ...) | f(...,x->f1,...) ) ...> ( return <+...x...+>; | return@p2 ...; ) @script:python@ p1 << r.p1; p2 << r.p2; @@ print "* file: %s kmem_cache_zalloc %s" % (p1[0].file,p1[0].line) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by:
-
Lino Sanfilippo authored
commit 31f73bee upstream. In ecryptfs_lookup_and_interpose_lower() the lower mount is not decremented if allocation of a dentry info struct failed. As a result the lower filesystem cant be unmounted any more (since it is considered busy). This patch corrects the reference counting. Signed-off-by:
Lino Sanfilippo <LinoSanfilippo@gmx.de> Signed-off-by:
-
Tyler Hicks authored
commit c43f7b8f upstream. Lower filesystems that only implemented unlocked_ioctl weren't being passed ioctl calls because eCryptfs only checked for lower_file->f_op->ioctl and returned -ENOTTY if it was NULL. eCryptfs shouldn't implement ioctl(), since it doesn't require the BKL. This patch introduces ecryptfs_unlocked_ioctl() and ecryptfs_compat_ioctl(), which passes the calls on to the lower file system. https://bugs.launchpad.net/ecryptfs/+bug/469664Reported-by:
James Dupin <james.dupin@gmail.com> Signed-off-by:
-
Chris Wright authored
commit b7300b78 upstream. The cgroup device whitelist code gets confused when trying to grant permission to a disk partition that is not currently open. Part of blkdev_open() includes __blkdev_get() on the whole disk. Basically, the only ways to reliably allow a cgroup access to a partition on a block device when using the whitelist are to 1) also give it access to the whole block device or 2) make sure the partition is already open in a different context. The patch avoids the cgroup check for the whole disk case when opening a partition. Addresses https://bugzilla.redhat.com/show_bug.cgi?id=589662Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Acked-by:
Serge E. Hallyn <serue@us.ibm.com> Tested-by:
Vivek Goyal <vgoyal@redhat.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Christoph Hellwig <hch@infradead.org> Cc: "Daniel P. Berrange" <berrange@redhat.com> Signed-off-by:
-
Al Viro authored
commit 7a4dec53 upstream. If sget() finds a matching superblock being set up, it'll grab an active reference to it and grab s_umount. That's fine - we'll wait for completion of foofs_get_sb() that way. However, if said foofs_get_sb() fails we'll end up holding the halfway-created superblock. deactivate_locked_super() called by foofs_get_sb() will just unlock the sucker since we are holding another active reference to it. What we need is a way to tell if superblock has been successfully set up. Unfortunately, neither ->s_root nor the check for MS_ACTIVE quite fit. Cheap and easy way, suitable for backport: new flag set by the (only) caller of ->get_sb(). If that flag isn't present by the time sget() grabbed s_umount on preexisting superblock it has found, it's seeing a stillborn and should just bury it with deactivate_locked_super() (and repeat the search). Longer term we want to set that flag in ->get_sb() instances (and check for it to distinguish between "sget() found us a live sb" and "sget() has allocated an sb, we need to set it up" in there, instead of checking ->s_root as we do now). Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Dan Williams authored
commit 556ab45f upstream. On some platforms (MacPro3,1) the BIOS assigns the ioatdma device to the incorrect iommu causing faults when the driver initializes. Add a quirk to catch this misconfiguration and try falling back to untranslated operation (which works in the MacPro3,1 case). Assuming there are other platforms with misconfigured iommus teach the ioatdma driver to treat initialization failures as non-fatal (just fail the driver load and emit a warning instead of triggering a BUG_ON). This can be classified as a boot regression since 2.6.32 on affected platforms since the ioatdma module did not autoload prior to that kernel. Acked-by:
Chris Li <lkml@chrisli.org> Tested-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Jeff Kirsher authored
commit 2d0bb1c1 upstream. Based on patches from Sonny Rao and Milton Miller... Combined the patches to fix up clean_tx_irq and clean_rx_irq. The PowerPC architecture does not require loads to independent bytes to be ordered without adding an explicit barrier. In ixgbe_clean_rx_irq we load the status bit then load the packet data. With packet split disabled if these loads go out of order we get a stale packet, but we will notice the bad sequence numbers and drop it. The problem occurs with packet split enabled where the TCP/IP header and data are in different descriptors. If the reads go out of order we may have data that doesn't match the TCP/IP header. Since we use hardware checksumming this bad data is never verified and it makes it all the way to the application. This bug was found during stress testing and adding this barrier has been shown to fix it. The bug can manifest as a data integrity issue (bad payload data) or as a BUG in skb_pull(). This was a nasty bug to hunt down, if people agree with the fix I think it's a candidate for stable. Previously Submitted to e1000-devel only for ixgbe http://marc.info/?l=e1000-devel&m=126593062701537&w=3 We've now seen this problem hit with other device drivers (e1000e mostly) So I'm resubmitting with fixes for other Intel Device Drivers with similar issues. CC: Milton Miller <miltonm@bga.com> CC: Anton Blanchard <anton@samba.org> CC: Sonny Rao <sonnyrao@us.ibm.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
NeilBrown authored
commit 51e9ac77 upstream. If the 'bio_split' path in raid10-read is used while resync/recovery is happening it is possible to deadlock. Fix this be elevating ->nr_waiting for the duration of both parts of the split request. This fixes a bug that has been present since 2.6.22 but has only started manifesting recently for unknown reasons. It is suitable for and -stable since then. Reported-by:
Justin Bronder <jsbronder@gentoo.org> Tested-by:
-
NeilBrown authored
commit bb4f1e9d upstream. Move the deletion of sysfs attributes from reconfig_mutex to open_mutex didn't really help as a process can try to take open_mutex while holding reconfig_mutex, so the same deadlock can happen, just requiring one more process to be involved in the chain. I looks like I cannot easily use locking to wait for the sysfs deletion to complete, so don't. The only things that we cannot do while the deletions are still pending is other things which can change the sysfs namespace: run, takeover, stop. Each of these can fail with -EBUSY. So set a flag while doing a sysfs deletion, and fail run, takeover, stop if that flag is set. This is suitable for 2.6.35.x Signed-off-by:
-
